Round #129Score 4.5/5Transport: rail

Yesterday's component found its way into today's refund flow

Route: /ticket-refund
Desktop preview
Mobile preview

Captured at a 375px viewport. Long pages scroll inside the frame.

The screenshots stay in Japanese. Every round is a real screen for a real Japanese industry, so an English re-render would no longer be the screen the agent actually produced.

Write-up

Yesterday's component found its way into today's refund flow

⁠Build log series⁠: I give an AI that has never seen Gunjo (@gunjo/ui) only the public npm package and the gunjo.jp docs, then ask it to build a real screen. ⁠This closed out the deeper passenger-facing rail run⁠ with a ⁠ticket refund and delay certificate flow⁠ covering eligible items, fees and refund amount, the application steps, and the certificate. Air and rail passenger coverage are now both complete.

Result: 4.5/5, the highest score in the series

The screen passed tsc and held together in a 375px mobile-first layout. The agent reported:

⁠The three hardest parts were not approximate substitutes. The library has components built for them.⁠ AmountBreakdown handled fare total minus refund fee equals refund amount as ⁠one component⁠, with the deduction in a destructive tone, a sign glyph, and a formula caption. TicketStub made the QR delay certificate ⁠nearly free⁠. PageHeader supplied the mobile app bar. ⁠Almost nothing substantial was hand-rolled.⁠

The first core observation: built yesterday, discovered today

⁠I had built TicketStub only one day earlier in .⁠ Then this agent found it here:

⁠The QR delay certificate dropped straight into TicketStub format="qr". No friction. It was built for this.⁠

The pattern of a new foundation being independently found by another agent on the next screen repeated at its fastest possible pace. AmountBreakdown, built in for staff-facing warehouse and accounting work, was also rated ⁠the most valuable component in the library⁠ for a passenger refund. A foundation settled on the staff side carried directly to the passenger side.

The second core observation: the agent hit a real PageHeader bug

An agent with no prior context ran into a real defect:

leading and onBack were mutually exclusive in the PageHeader source:⁠ back = leading ? leading : onBack ? <button/> : null. Passing a decorative chevron through leading alongside onBack meant ⁠the chevron silently replaced the real back button, dropping both the click handler and the ARIA label.⁠ tsc remained green. ⁠A developer who trusted the types could ship a broken and inaccessible back button.⁠

I fixed it immediately in PR#380: both now render, with the onBack button and leading next to each other in a fragment. ⁠A new agent exposed a hidden accessibility defect in PageHeader two days after I built it in .⁠ Independent discovery across contexts does more than validate a component. Sustained use reveals its rough edges.

New gaps logged

  • 🟠 CheckboxCard and CheckboxCardGroup, the multi-select twin of RadioCard from . Choosing separate fare and limited-express items for refund required a hand-rolled checkbox and label card. ⁠Choosing which line items to refund is the first step in refunds, returns, and line-item operations of every kind.⁠ I recorded it on issue #378.
  • 🟡 ⁠A success or accepted variant for StatusScreen.⁠ It was limited to error pages such as 404 and 500, with min-60vh, so it could not represent completion inside a flow. I recorded it on issue #379.
  • ✅ I added Stepper to the by-use-case catalog, which had no entry for multistep wizard or form progress.

⁠What changed under src this round: the PageHeader bug fix.⁠ A component built two days earlier was repaired after real use found its defect.

What I took away: sustained use validates, transfers, and repairs at once

This final passenger-facing rail screen did three things together:

  1. ⁠Validation:⁠ another agent independently found the TicketStub built the day before.
  2. ⁠Transfer:⁠ AmountBreakdown, settled on staff screens, worked as-is for a passenger refund.
  3. ⁠Repair:⁠ sustained use exposed and immediately fixed the hidden PageHeader trap.

The value of going deep is not limited to producing new components. ⁠Using them hard in new contexts drives validation, cross-industry transfer, and defect discovery at the same time.⁠ Across staff screens in 14 industries and this deeper passenger run, that compound effect had a chance to complete its cycle.

📊 Component scoreboard (⁠11 built⁠, plus shipped fixes)

AmountBreakdown / ActionQueue / ListCard / Gantt-segments / SeatMap / LoyaltySummaryCard / RadioCard / FilterChips / PageHeader / Itinerary / TicketStub In progress: CheckboxCard, a success variant on StatusScreen, StatusLevel, BottomActionBar, and AmenityRow.

📋 Passenger-facing backlog: air and rail complete

  • ✈️ Air: all six screens complete ✅
  • 🚆 ⁠Rail: all six screens complete⁠ ✅ (commuter pass, station guide, tickets, station recommendations, refund, plus the four existing flows)

Next up: build log

  • Move to the next mode with a staff-facing bus operations screen or a passenger route, timetable, and booking screen. The question is how much of the rail and air foundation carries into bus.

The run

A component built yesterday was discovered today, a staff foundation worked for passengers, and sustained use exposed a hidden bug. Going deep kept component building, validation, and repair moving together.

This series is co-created with AI (Claude and Codex). A human designs the experiments, makes the calls, and fact-checks before publishing; the AI does the hands-on work and drafting.

Components from @gunjo/ui

The components this screen's source imports directly.

The code the agent actually wrote

Click a file to expand its source.

業界別「AI指示書パック」、先行登録を受付中です。