Itinerary found a second life in bus routes, but its transit depth ran out
/bus-route-searchCaptured 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
Itinerary found a second life in bus routes, but its transit depth ran out
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 third passenger-facing bus round covered route search and fare guidance from Shibuya to Todoroki: route options, transfers, duration, fares, and route details.
Result: 4/5. Itinerary was independently found in another mode
The screen passed tsc and fit a 375px mobile-first layout. The agent reported:
Several components could only have been designed for passengers in Japanese transportation.
PageHeader,FilterChipsfor fastest, cheapest, and fewest transfers,ListCardfor route options,AmountBreakdownfor fares, andItineraryfor route details covered about 85 percent of the screen without custom CSS, with touch targets and accessibility included. The by-use-case catalog correctly led to both difficult pieces: option cards and a route broken into legs.
The core observation: Itinerary moved from air travel to a bus route
I built Itinerary in #126 for an air itinerary of flights, hotels, and activities. Here another agent found it for bus route details with walking, riding, and transfers:
I used
Itineraryfor each leg of the route. It fit better than anything else in the library. Its docstring even warned me away fromRouteStops, whose language is fixed to delivery.
Almost 30 rounds after it settled in air, a different agent independently found Itinerary for bus routes. The guidance added in #126 about delivery-specific vocabulary in RouteStops worked here too. A component settled in one mode found its own way into a similar pattern in another.
But useful was not the same as purpose-built
Itineraryrepresented bus, walking, and transfers adequately, but it was not designed specifically for them. A bus leg needs boarding stop, route and destination, ride time and number of intermediate stops, alighting stop, transfer wait, and walking.Itineraryoffers only one icon, time, title, description, content slot, and trailing slot, so the agent hand-rolled the internal layout. The largest gap was the uniform connector. It could not draw walking as a dashed line and riding as a solid one, a distinction every major journey planner uses.
I reopened issue #358, which I had closed when Itinerary was built in #126. The generic foundation was correct and covered about 80 percent. The remaining transit-specific 20 percent was a legs[] mode with a walking, riding, or transfer kind; boarding and alighting stops; number of intermediate stops; dashed walking and solid riding connectors; and route plus fare per leg. The journey planner in #110 and bus route here made two of three.
What I took away: discovery proves direction, not completeness
When I built Itinerary in #126, I treated issue #358 for TransitItinerary as solved. This agent showed that the component was sound enough to be discovered without prompting, but did not reach the transit-specific details.
- Independent discovery proves that a component points in the right direction.
Itineraryfit and the agent found it. - Depth is a separate question. A useful generic foundation is not the same as a purpose-built transport mode, just as the general grid in
SeatMapcrossed into bus while its attributes remained airline-shaped in #139.
Independently discovered does not mean finished. Discovery validated the foundation; a future legs[] mode can supply the depth. The test loop also corrected my own early decision to close issue #358. It inspects past design judgments as readily as new work.
What it flagged
- 🟡
LineChiporRouteBadge. Route numbers such as 66 and 98 needed another hand-rolled colored chip after #138. I recorded the second of three cases on issue #392, separate fromBadge, which represents state. - 🟡 There was no composition for an origin and destination search bar with a swap control. I added it to issue #392.
- 🟡
PageHeaderwithalign=center, actions, and noonBacksat slightly left of center.
Nothing new was added under src this round. The 4/5 brought independent discovery for Itinerary, reopened issue #358, and put LineChip at two of three.
📊 Component scoreboard (12 built)
AmountBreakdown / ActionQueue / ListCard / Gantt-segments / SeatMap / LoyaltySummaryCard / RadioCard / FilterChips / PageHeader / Itinerary / TicketStub / Stringline In progress: BottomActionBar approaching three of three, StatusLevel at two of three, ExpiryBadge at two of three, StatusBoard at two of three, TransitItinerary legs at two of three, and LineChip at two of three.
📋 Mode progress
- ✈️ Air: five staff + six passenger screens ✅ / 🚆 Rail: five staff + six passenger screens ✅
- 🚌 Bus: two staff + three passenger screens (arrivals, intercity booking, route search) / next mode
Next up: build log #141
- The new mode, taxi, beginning with staff-facing dispatch for vehicle and request matching, then a passenger ride-hailing app. The dispatch board could supply the third
StatusBoardcase.
The run
- gunjo.jp / Itinerary / ListCard / npm
@gunjo/ui/ GitHub / previous rounds #1 through #139 - GunjoUI by UIXHERO
Itinerary was independently found in another mode, but discovery did not prove completeness. Cross-industry use validates direction; a dedicated mode supplies depth.
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.