A season-ticket flow lacked the smallest building block for buying
/commuter-passCaptured 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
A season-ticket flow lacked the smallest building block for buying
Build log series: The series gives an AI with no prior Gunjo (
@gunjo/ui) experience only the public npm package and the gunjo.jp docs, then asks it to build a real screen. This was the first deeper passenger-flow brief from the backlog before moving beyond rail and air. It covered buying or renewing a commuter pass by choosing a route, pass type and duration, start date, price, and payment method.
I decided to cover rail and air passenger needs properly before moving to other transportation modes, created a passenger-facing backlog, and started at the top. This was its first screen.
Result: 3.5/5
A price-bearing choice card emerged as the central missing piece in an otherwise well-covered five-step purchase flow. The screen passed tsc and fit a mobile-first 375px layout. The agent reported:
AmountBreakdownlooked made for this task: base commuter fare plus connecting segment minus renewal discount produced the payment amount directly, making it the best fit in the library. Stepperworked without friction: its 375px support and comment about a five-step mobile checkout reflected the fix from PR#355.DatePicker,MetadataList,Select, andBadgealso worked straight away. But the center of consumer purchasing, a selectable card with a price, had no component.
What it flagged: purchasing lacks its smallest building block (RadioCard)
The agent hand-rolled the choices for type, duration, and route as option cards with prices. This was the largest gap.
ToggleGroupsupports text only, with no slot for a right-aligned price or badge.RadioGroupfixes its label and description to the left, leaving no place for ¥8,960 per month and a "recommended" badge on the right, while its 4px radio dot is too small on mobile. There is no price-bearing choice card. "RadioCardorSelectableCard, with a title, subtitle, trailing price or cue, and a badge slot, is the smallest building block in any consumer purchase, plan selection, or delivery-options screen. It would be the single most valuable addition."
#109 found that RadioGroup had no card-style selection tile for limited-express booking. Together with #119, that puts RadioCard at two of three (issue #370, related to issue #135 and issue #365). The same RadioCard covers the payment-method picker, which the table currently marks as having no component. A station-swap control (RouteSelect) has also recurred in #109, #115, and #119. One more purchase or plan screen would trigger the rule of three and a real build.
No new component was added under src this round. The 3.5/5 result moved RadioCard to two of three. AmountBreakdown crossed into another use case for the seventh time, now for a commuter fare.
What I took away: going deeper collects different evidence for the same gaps
The first screen after I chose to deepen rail and air passenger coverage produced the second piece of evidence for RadioCard, the smallest building block in consumer purchasing. Deeper passenger work confirms the reach of foundations already shared across industries, including ListCard, AmountBreakdown, SeatMap, and LoyaltySummaryCard. It also steadily accumulates cases for components not yet built, including RadioCard, TicketStub, SegmentedControl, and RouteSelect. Staying with rail and air long enough to close their passenger gaps fills the rule of three more reliably than jumping straight to a new mode. The decision to go deeper first is also the faster route to well-supported components.
Next up: build log #120
- I will continue through the passenger backlog with rail station navigation or ticket purchase, or air travel such as an international e-ticket for a second
TicketStubcase or baggage tracking. Another purchase or plan screen may supply the thirdRadioCardcase.
The run
- gunjo.jp / AmountBreakdown / the by-use-case table /docs/by-use-case / npm
@gunjo/ui/ GitHub / previous rounds #1 through #118 - GunjoUI by UIXHERO
The first screen from the deeper passenger backlog supplied RadioCard's second case: a price-bearing choice card for commuter-pass options.
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.