The mobile passenger foundation carried intact into a third mode
/bus-approachCaptured 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 mobile passenger foundation carried intact into a third mode
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 first passenger-facing bus round followed operations and dispatch with an arrival and boarding screen for Shibuya Station: minutes to arrival, route selection, fares, and an IC card.
Result: 4/5. The mobile passenger foundation held in a third mode
The screen passed tsc and fit a 375px mobile-first layout. The agent reported:
This was designed for mobile passengers from the start, not retrofitted from administrative screens. Six foundations felt purpose-built:
PageHeaderfor the app bar,ListCardfor arrival rows as a one-to-one match and the best component in the library,FilterChipsfor routes and directions,LoyaltySummaryCardfor the prominent IC balance,TicketStubfor the day-pass QR, andAmountBreakdownfor fares. The severity rail and selection ring onListCardmade an arriving-soon bus prominent without custom CSS.
The mobile passenger foundation settled in rail and air required almost no hand-rolling for bus, the third mode. It passed another cross-industry test.
The first core observation: the PageHeader fix from #380 was working
In #129 I found and fixed a trap where passing both leading and onBack to PageHeader silently removed the back button. Here the agent said:
The
PageHeaderdocs describe the fixed trap:onBackandleadingused to drop the handler when passed together, but both now render. I did not encounter a single misleading prop.
The fix lived in both the source and the docstring, and another agent recognized it as fixed nine rounds later. A correction carries across industries only when code and documentation preserve it together.
The second core observation: StatusLevel reached two of three
The agent hand-rolled a 25-line CrowdingBadge from Badge and a people icon for three crowding states: seats available, moderately crowded, and crowded. After lounge crowding in #127, this was the second case. It described the same specification and gave it the same priority:
There is no component for a graduated status, level, or severity pill.
Badgecan wrap it, but every adopter who needs crowding, inventory, freshness, or signal levels will rebuild the same wrapper.StatusLevelorQualitativeStatusmaps ordered levels to a tone, icon, and label that remains clear without color. It is the single largest addition available.
It also found a false lead in the catalog:
Crowding points to
HeatmapChart, which is wrong. That component is a read-only intensity grid, not a three-level pill for an item. A new developer following the catalog would build the wrong thing.
I added the second case to issue #376 and corrected the catalog in PR#389: crowding and levels use a badge with icon and tone, while HeatmapChart remains a grid. Two independent implementations had stabilized the specification: levels[] of two to four ordered values, each with a tone, icon, and label that does not rely on color, selected by value. One more case from inventory, freshness, or signals would trigger the build.
Smaller findings
- 🟡 A route-number chip for the
leadingslot inListCardwas missing, so the agent hand-rolled an 11 by 11 colored square for route 66. - 🟡 A flat row of chips would fit the next four departures for one route better than the matrix in
ScheduleGrid.
Nothing new was added under src this round. The 4/5 confirmed the mobile passenger foundation in a third mode and left StatusLevel at two of three.
What I took away: passenger foundations no longer move with the mode
Rounds #130 and #131 showed that staff foundations held in new industries, and #137 carried the crew foundation into a third mode. Here six mobile passenger components crossed together into bus, also the third mode. The staff and passenger foundations had both matured beyond their original modes. Remaining gaps were small cross-cutting pieces such as a crowding pill. They no longer opened along an industry axis, but along orthogonal patterns: a data board in #132, a deadline axis in #137, and a graduated level here. The map of gaps had shifted from industries to component concepts.
📊 Component scoreboard (12 built)
AmountBreakdown / ActionQueue / ListCard / Gantt-segments / SeatMap / LoyaltySummaryCard / RadioCard / FilterChips / PageHeader / Itinerary / TicketStub / Stringline In progress: StatusLevel at two of three, ExpiryBadge at two of three, StatusBoard at two of three, and an intraday Gantt mode.
📋 Mode progress
- ✈️ Air: five staff + six passenger screens ✅ / 🚆 Rail: five staff + six passenger screens ✅
- 🚌 Bus: two staff + one passenger screen (arrivals) / remaining passenger route planning and booking, or a move to taxi and trucking
Next up: build log #139
- Continue passenger bus with an intercity seat booking flow, testing
SeatMapandRadioCardacross industries, or start the new taxi mode with dispatch on the staff side and ride hailing on the passenger side.
The run
- gunjo.jp / ListCard / FilterChips / LoyaltySummaryCard / npm
@gunjo/ui/ GitHub / previous rounds #1 through #137 - GunjoUI by UIXHERO
Six mobile passenger components crossed together into a third mode. The foundations no longer moved by industry, and new gaps appeared only in orthogonal patterns.
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.