A day-old ListCard turned up on a flight list with a hand-built seat map

⁠Build log series⁠: I hand 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 was the first passenger-facing air round⁠, a ⁠domestic flight booking flow⁠ covering flight search, seat selection, a fare breakdown, and the booking steps.

Rail had already reached passengers with limited-express tickets, journey planning, and service information. Air was the second transportation mode to get there, and I was watching two things: whether a different agent would find ListCard on its own for a list of flights, and whether the seat map would be hand-rolled a second time after the rail seats in #109.

Result: 3.5/5. The pattern closed again in one round, and SeatMap reached two of three

The screen passed tsc and build, fit a 375px mobile-first layout, produced no console errors, and carried a five-step booking flow. The agent reported:

⁠ListCard was built for this: the flight result row.⁠ Its docstring names the use case (search results, comparing routes, products, or properties) and even the tags to use (fastest, cheapest, recommended). It carries leading, title, description, tags, status, meta, severity, and onSelect as a real button of at least 44px. ⁠No friction, and the library's flagship component for a list of things.⁠ ⁠AmountBreakdown was the best fit in the whole library⁠, taking base fare, then taxes and charges, then the seat fee, then the discount, through to the total. ⁠Stepper was built for this too⁠, on a five-step mobile checkout.

⁠I added ListCard in #111. One round later, a different agent working in another industry found it without prompting and used it with no friction.⁠ After AmountBreakdown (#103 into #104) and ActionQueue (#106 into #107), that is the third time a new component has been picked up on the very next screen. A foundation shared across industries gets confirmed as soon as it exists.

Stepper earned a note of its own. The agent wrote that ⁠five steps stayed intact at 375px, stepped down gracefully, and did not break the page.⁠ That is PR#355 doing its job, the fix I made after #109 reported the payment step falling off the screen.

The core observation: SeatMap at two of three

⁠Seat selection, the cabin seat map, was hand-rolled from scratch in about 190 lines. There is no SeatMap and nothing close to it.⁠ The by-use-case table sent seat selection to HeatmapChart, a read-only data visualization. The cabin and section model, the aisle gaps, four states (available, booked, selected, unavailable), four seat types (standard, exit row, extra legroom, premium), the fee per seat, the cap on selections, and grid accessibility were all written by hand. "⁠Adding this would let the library own seat selection for airlines, events, cinemas, and stadiums. It is the single largest addition available.⁠"

Rail seats in #109 plus cabin seats here put ⁠SeatMap at two of three⁠ (recorded on issue #356). The agent went as far as designing the model: cabin and aisle layouts ("3-3", "2-4-2", "2-2"), a type, fee, state, and window or aisle position per seat, the capacity cap, and mandatory horizontal scrolling at 375px. ⁠One more case, from a cinema, a stadium, an event, or a restaurant, reaches the rule of three and I build it.⁠ The HeatmapChart false lead in the table gets corrected at the same time.

⁠Nothing new was added under src this round.⁠ The 3.5/5 came with independent discovery of ListCard in another industry and SeatMap at two of three. ⁠AmountBreakdown crossed an industry boundary for the fifth time, now for air fares, and ListCard reached its second industry.⁠

What I took away: shared foundations carry to the next mode, mode-specific ones accumulate

ListCard is a passenger-facing foundation shared across industries. I built it for rail, and air found it immediately. ⁠What I had already seen on staff-facing screens, where a shared foundation is confirmed on the next screen in another industry, now happened on the passenger side and across transportation modes.⁠ SeatMap is the other kind: a passenger-facing foundation specific to one mode, and it moved from rail to air to reach two of three. ⁠Shared foundations such as StatGroup, AmountBreakdown, ActionQueue, and ListCard pay off all at once under the rule of three, while mode-specific ones such as SeatMap, TransitItinerary, and Stringline collect their evidence across modes.⁠ The rule of three keeps sorting both. Localization is still open: the English aria-label on NumberInput is hard-coded and cannot be translated, so it surfaces in English on a Japanese screen, and it waits on the LocaleProvider work in issue #326.

Next up: build log #113

• A staff-facing air screen, the operations board and the aircraft rotation Gantt, could produce the third case for segmented Gantt bars. The alternatives are a third SeatMap case from a cinema or event screen, or the next mode.

The run

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

A component built yesterday was in use today, and a second missing seat map landed. Shared foundations carry to the next mode; mode-specific ones build up case by case.