The boarding pass you hold up at the gate still has no component
/eticketCaptured 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 boarding pass you hold up at the gate still has no component
Build log series: An AI that has never seen Gunjo (
@gunjo/ui) is given the public npm package and the gunjo.jp docs and nothing more, then builds a real screen. Continuing the deeper passenger-facing air work from the passenger backlog, this was an international e-ticket receipt with a travel document check, covering the pass itself, the itinerary, and passport, visa, and travel authorization.
Result: 3.5/5
The screen passed tsc and held at 375px mobile-first. The agent reported:
CheckListwas built for this. A checkbox with a label, a description, and atrailingslot, with every row labelled automatically. The travel document checklist dropped straight in, and the docstring names document checklists outright.Badgewith an icon,MetadataList,Tabs, andProgressneeded no hand-rolling either. But the subject of the screen, the face of the boarding pass, has no component.
The core observation: TicketStub at two of three
The e-ticket and boarding pass face was hand-rolled from scratch, and it is the leading gap. The agent grepped every public surface for boarding, barcode, stub, pass, ticket, qr, and perforation and found nothing. The origin and destination pair (HND 17:05 to LAX 10:55), the field grid for seat, gate, and boarding time, the perforation as notches with a dashed
Separator, the QR code, and the barcode were all written by hand. "TicketStubneeds a header for the city pair, a field grid, a perforation variant, a slot for a QR code or barcode, and a status band. It is the single largest missing component in the travel and ticketing space."
The boarding pass in #114 plus this e-ticket put TicketStub at two of three (issue #363). The two rounds also converged on the API: the city pair with local times and the offset between them, a grid for seat, gate, boarding time, and class, notches with a dashed line, a slot for an encoded node with its aria-label, a status band, and plain data, so it stays safe to render on the server. One more case, from a membership barcode, a rail ticket, or an event ticket, reaches the rule of three and I build it.
Other things I noticed
- 🟢
RouteStopsleaks delivery vocabulary into an itinerary as well. The outbound and return legs came out as "not delivered" and "in transit" with a delay column and a current position, which the agent called conceptually wrong for a flight that has not happened yet. Transit routes in #110, station directions in #120, airport directions in #122, and international legs here make four. A segment-centeredFlightItineraryorTransitItineraryis needed (issue #358). - 🟢 A theme token trap. The library uses
@configin the Tailwind v3 style, wherecolors.foregroundresolves tohsl(var(--foreground)), so the v4 formvar(--color-foreground)does not exist. Anyone writing their own CSS hits this immediately; the agent's first barcode gradient nearly came out transparent. - 🟢
IconPassportdoes not exist in Tabler, soIconIdstood in.
No new component was added under src this round. The 3.5/5 moved TicketStub to two of three, and CheckList crossed an industry boundary for travel documents.
What I took away: the emotional center is the least covered part of a passenger screen
The agent's summary was sharp: "Everything around the edges, the checklist, the details, the itinerary scaffolding, the alerts, the tabs, the progress, is fast and more accessible than hand-written markup. But the emotional center of a consumer travel app, the pass you hold up at the gate, is not in the box. The most important surface is the least covered." That structure repeats through the deeper passenger work: an administrative library is strong on peripheral scaffolding and thin on the consumer centerpiece, whether that centerpiece is a large loyalty balance, a seat map, a category chip bar, or a pass. Which is why working through the passenger side settles those centerpieces one at a time, from SeatMap, LoyaltySummaryCard, RadioCard, and FilterChips to TicketStub next.
📊 Component scoreboard (8 built)
AmountBreakdown / ActionQueue / ListCard / Gantt-segments / SeatMap / LoyaltySummaryCard / RadioCard / FilterChips In progress: TicketStub at two of three, SegmentedControl, a success variant on StatusScreen, an hour axis on Gantt, and FlightItinerary or Steps.
Next up: build log #124
- More of the passenger backlog: air, with baggage tracking as a status timeline, itinerary management, or rebooking after a cancellation, or the rest of rail, where in-station recommendations could supply the third
TicketStubcase through a rail ticket or a membership card, or refunds.
The run
- gunjo.jp / the by-use-case table /docs/by-use-case / npm
@gunjo/ui/ GitHub / previous rounds #1 through #122 - GunjoUI by UIXHERO
The pass you hold up at the gate is still hand-rolled every single time.
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.