Two components I built days earlier came back, and the app bar reached three
/flight-rebookingCaptured 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
Two components I built days earlier came back, and the app bar reached three
Build log series: I give an AI that has never seen Gunjo (
@gunjo/ui) the public npm package and the gunjo.jp docs, then ask it to build a screen for real work. Continuing the deeper passenger-facing air work from the passenger backlog, this was rebooking after a cancellation or a delay, covering the cancellation notice, choosing an alternate flight, and the rebooking flow.
Result: 4/5, with two independent discoveries and a third PageHeader case
The screen passed tsc and fit at 375px, mobile first. The agent reported:
RadioCardwas built for this. Itsvalue,title,description,tags,price,highlight, andleadingmap one to one onto an alternate flight card: flight number with seats left, times with duration, tags, the fare difference, and no extra charge. A correctrole=radiogroup, arrow keys, at least 44px, and a check mark that does not depend on color. No friction. Asked whether a ready-made choice card fit, the agent answered "emphatically yes". FilterChipshad no friction either on the single-select filter for when to fly (any, same day, next day), with scroll-snap and arrow keys.
I built RadioCard in #121 and FilterChips in #122, and a few rounds later a different agent found both of them without prompting. The build-then-rediscover pattern happened twice in a single screen, which is what accumulating trust in a foundation looks like.
The core observation: PageHeader reached its third case
The mobile page header, the app bar, was hand-rolled. This is a real gap.
Header, the only nav-header export and the one the table recommends, is a marketing bar that wraps, with none of the structure of back, centered title, and trailing actions. "There is no mobileAppBarorTopBarcomponent. It is the single biggest thing the library could add."
Three screens in a row. Station navigation in #120, baggage tracking in #124, and rebooking here. Three separate agents independently hand-rolled a mobile app bar, because the library's Header is a desktop shell. Three cases, so I built it.
What I built: PageHeader
The sample below is the docstring example, taken from the baggage tracking round that produced the second case.
<PageHeader
title="Baggage tracking" subtitle="Kuro Yamada - ABC123"
onBack={() => router.back()} // back button of at least 44px
actions={<Button size="icon" variant="ghost" aria-label="Refresh"><IconRefresh/></Button>} />
- Back, title and subtitle, and actions, inside a
<header>landmark, sticky, with safe-area-inset-topfor the notch, aligned left or centered. -
onBackrenders a 44 by 44px back button, so this component satisfies the touch target thatButton size="icon"misses at 36px (issue #362). - I added a table entry sending the mobile app bar to
PageHeaderand separated it fromHeaderandAppRail, the desktop shells, which corrects the false lead that #120, #124, and #125 all followed. - PR#374, verified on a real 375px render: a
<header>landmark, sticky positioning, a back button measuring 44 by 44px in computed styles, actions firing, centered alignment, and no errors.
What I built under src this round: PageHeader, on its third case and the ninth component to come out of this series. One more note: Banner has a prop trap. It takes children only, title collides with the HTML attribute and throws TS2322, and description falls through silently to a div (issue #324).
What I took away: independent discovery started compounding
The passenger-facing foundations built during this stretch, ListCard, SeatMap, LoyaltySummaryCard, RadioCard, FilterChips, and now PageHeader, keep turning up on the next screen without being pointed to. This round surfaced RadioCard and FilterChips at the same time, so "build it and the next screen benefits" is compounding on the passenger side too. The same thing happened with StatGroup, AmountBreakdown, and ActionQueue across administrative industries. The further the depth goes, the closer a new screen gets to assembly with almost nothing hand-rolled, which is the whole goal.
📊 Component scoreboard (9 built)
AmountBreakdown / ActionQueue / ListCard / Gantt-segments / SeatMap / LoyaltySummaryCard / RadioCard / FilterChips / PageHeader In progress: TicketStub at two of three, SegmentedControl, a success variant on StatusScreen, an hour axis on Gantt, and TransitItinerary.
Next up: build log #126
- More of the passenger backlog: air, with itinerary management to observe
TransitItinerary, or lounges, or the rest of rail, where in-station recommendations could giveTicketStubits third case through a membership card or a rail ticket, or refunds.
The run
- gunjo.jp / PageHeader / RadioCard / npm
@gunjo/ui/ GitHub / previous rounds #1 through #124 - GunjoUI by UIXHERO
Two components built days earlier came back on their own, and the app bar reached its third case. On the passenger side, independent discovery is compounding.
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.