The RouteStops entry I added became a trap three rounds later
/transit-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
The RouteStops entry I added became a trap three rounds later
Build log series: This series has an AI new to Gunjo (
@gunjo/ui) build real screens from the public npm package and the gunjo.jp docs alone. The second passenger-facing rail screen was a mobile-first journey planner and route search, in the vein of Yahoo Transit or Jorudan.
After the limited-express booking flow in #109, I moved to a second rail app used heavily by passengers in Japan. The questions were whether the missing result-card list from #109 would recur and whether RouteStops would fit the journey itself.
Result: 3/5, lower again. Passenger screens kept finding gaps
The score dropped from 3.5 in #109 to 3 here. The screen still passed tsc and build, fit a 375px mobile-first layout, and produced no console errors, but passenger needs continued to expose missing parts of a foundation built through administrative work. The agent reported:
The token system and several components were useful, but the library was unmistakably administrative. The two most valuable pieces on a passenger journey screen, a ranked list of result cards and an itinerary across multiple rail lines, were hand-rolled.
RouteStops, despite sharing a name with the task, was a trap.
An entry I added became unsuitable three rounds later
In #107, I added RouteStops to the table for delivery routes, process flows, and crew-duty sequences. Three rounds later, in #110:
RouteStopswas the biggest disappointment in this round. Despite its transportation-sounding name, it models delivery drivers and order picking. Its states are undelivered, delivering, and complete, with columns for current location, planned time, and actual time. Most importantly, it has no concept of the segment between stations. There is no line, service type, direction, platform, or color. A transit journey centers on segments, which carry most of the information, whileRouteStopscenters on nodes and fixes delivery assumptions into markers, badges, andDeltavalues.
That meant adding RouteStops to the table had itself become a false lead for transit. I revised the entry to say that it is node-centered and that a segment-centered journey planner is separate and unsupported. PR#357 records the change. Maintaining the table means documenting where a component does not fit, not only adding places where it does. That boundary is part of discoverability.
Two gaps I logged
-
TransitItineraryorJourney for segment-centered route details is issue #358. Its item model covers boarding, travel with line, service type, direction, platform, color, and delay, a walking transfer between platforms, and arrival. It also applies to bus and air connections, making this the first of three cases for a transportation-specific passenger component, alongside the mode-specific Stringline in issue #352. The same issue covers line-color chips becauseBadgeandTaguse fixed semantic tokens and the agent had to hand-roll colors for lines such as the Yamanote and Marunouchi. -
ResultCardreached its second case. Train candidates in #109 and journey candidates in #110 put issue #135 at two of three. The agent called the missing ranked result-card list "a shared consumer-facing pattern the library lacks, dense by default on mobile, and the single most valuable addition." The table also misdirected card lists toKanbanBoardand search results toDataTable, neither suitable for passengers. I also recorded the smaller friction of overridingCard's requiredp-6on every mobile result.
What changed under src this round: the RouteStops table entry now says it is node-centered. AmountBreakdown also crossed industries for a fifth time in the fare summary.
What I took away: the table needs boundaries, and the passenger foundation runs deep
I took away two things.
-
The table must state where a component does not fit, not just where it does. I added
RouteStopswith good intentions in #107, but it misdirected transit work in #110. Without the boundary between node-centered and segment-centered routes, the name promises the wrong behavior. Discoverability requires both a correct route and a clear warning. -
The passenger-facing foundation is deep. #109 exposed
SeatMap; #110 added a secondResultCardcase,TransitItinerary, line colors, and mobile card density. Even after 100 administrative screens across 14 industries, two passenger screens found five gaps. A cross-industry consumer foundation (ResultCard) and mode-specific consumer foundations (SeatMapandTransitItinerary) are emerging just as their staff-facing counterparts did. I will test both staff and passenger screens in every transportation mode. The passenger side now clearly has foundations left to build.
Next up: build log #111
- A third passenger-facing rail screen, such as service status or station navigation, should produce the third
ResultCardcase and trigger a build. Another option is an air-travel booking screen for the secondSeatMapcase.
The run
- gunjo.jp / the by-use-case table /docs/by-use-case / npm
@gunjo/ui/ GitHub / previous rounds #1 through #109 - GunjoUI by UIXHERO
I added the RouteStops entry in #107. In this round it misdirected transit work. Three rounds after adding it, I rewrote its boundary.
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.