Passenger booking exposed the series' lowest score and a missing SeatMap

⁠Build log series⁠: I hand only the public npm package and the gunjo.jp docs to an AI that has never seen Gunjo (@gunjo/ui) and ask it for a real screen. ⁠The first passenger-facing rail round⁠ was ⁠an online limited-express ticket and reserved-seat booking flow⁠ covering train selection, a seat map, a fare breakdown, and booking steps.

The three earlier rail screens in #106 through #108 all served ⁠staff behind the operation, including dispatchers, crew managers, and vehicle inspectors.⁠ This one moved ⁠to the passenger side⁠ with a consumer booking flow such as Ekinet or Smart EX. I wanted to see ⁠how far a library shaped by administrative work would carry into passenger booking.⁠

Result: 3.5/5, the lowest recent score in the series. That was useful

⁠The score fell,⁠ which was ⁠good news:⁠ the first passenger screen exposed several gaps that had not appeared across seven industries of administrative work. It still passed tsc and build, fit at 375px, and produced no console errors. The agent reported:

⁠The structured form and breakdown pieces were strong.⁠ AmountBreakdown handled fare plus limited-express charge minus discount and produced the total directly, while Stepper, RouteStops for stations, and MetadataList for confirmation all fit. ⁠But the center of the booking flow, the seat map, had no component, and several existing components carried their administrative assumptions into a consumer context.⁠ Components covered around 70% of the screen, but the remaining 30%, including the most important part, was hand-rolled.

Logged, not built: SeatMap, the main missing component

⁠The agent hand-rolled the entire seat map in around 180 lines. There was no seat-map component or even a nearby 2D selection grid.⁠ ScheduleGrid is for staff availability across days, DataTable is a table, and ToggleGroup is one-dimensional. "⁠This is the single largest recurring gap for transportation, events, and cinemas.⁠"

Logged as issue #356. The proposed model covers seats, status (available, booked, selected, or held), an aisle descriptor for layouts such as 2+3 and 2+2, seat facilities, controlled selectedIds and maxSelectable, plus grid-cell semantics, aria-pressed, and detailed accessible labels. ⁠It generalizes beyond rail to air travel, cinemas, stadiums, and events.⁠ Passenger screens in other transportation modes should produce another case soon, leaving it at one of three for now.

What I fixed this round: Stepper clipping at 375px

⁠Stepper clipped the fifth step at 375px.⁠ "The right edge of the payment step is at x=416 while the container ends at x=359. On a five-step mobile checkout, the user cannot see the end of the flow."

Fixed-width w-[60px] connectors and w-16 steps had required 656px. I changed them to ⁠flexible connectors, full width, and w-14 on mobile.⁠ Five steps now fit in about 360px with no overflow at 375px. PR#355 changes no API, so every Stepper user benefits; I also confirmed zero overflow on a 375px device.

Other passenger-facing gaps I observed

• ⁠There is no consumer search-result card list.⁠ The agent hand-rolled train candidates from Card, Badge, and Button. The table suggested DataTable for search results, an administrative reflex that does not suit passengers. I added result cards and radio-style card tiles to issue #135.
• ⁠The visual tone lacks warmth.⁠ The agent described neutral, practical, monochrome, square cards with no warmth: a capable management console that looked more like an insurance claim assessment than a passenger booking service. Consumer screens need emotional cues such as route imagery, large friendly time displays, and reassuring color. ⁠When an administrative library serves consumers, the functions are present but the feel is not.⁠
• The default accessible labels for NumberInput and Badge are hard-coded in English and cannot be localized, so they surface untranslated on a Japanese screen. I added this evidence to issue #326.

⁠What changed under src this round: the 375px Stepper fix.⁠ ⁠AmountBreakdown also carried into a passenger fare⁠, its fourth independent use.

What I took away: passenger screens uncover a new foundation quickly

After more than 100 administrative screens across 14 industries, I had nearly reached a point where new gaps stopped appearing. ⁠The first passenger screen dropped to 3.5/5 and exposed three at once: the large SeatMap, a result-card list, and a warmer visual language.⁠ That is the point of the build log: ⁠entering an untested context reveals what is still missing from a supposedly complete foundation.⁠ Just as staff-facing screens needed shared components such as StatGroup, AmountBreakdown, and ActionQueue, ⁠passenger screens have their own foundation in SeatMap, result lists, and a consumer feel.⁠ I will test both staff and passenger sides in every transportation mode, because the next gap can come from either.

Next up: build log #110

• A second passenger-facing rail screen, either journey planning or service information, will test RouteStops in another industry and look for a second result-list case. I will also watch for a second SeatMap case in air travel.

The run

• ⁠gunjo.jp⁠ / ⁠AmountBreakdown⁠ / the by-use-case table ⁠/docs/by-use-case⁠ / npm @gunjo/ui / ⁠GitHub⁠ / previous rounds #1 through #108
• ⁠GunjoUI by UIXHERO⁠

Moving to the passenger side produced the lowest score and several new gaps. That made this round worth running.