A flight status board was the rare passenger screen that needed nothing new

⁠Build log series⁠: I give an AI with no prior exposure to Gunjo (@gunjo/ui) the public npm package and the gunjo.jp docs, then ask it for a real screen. ⁠This was the second of the three passenger-facing air rounds⁠, a ⁠flight status board⁠ covering departures and arrivals, delays and cancellations, and gates. It is the airport version of the rail service information screen.

Result: 4/5, the highest of the three

The screen passed tsc, held together at 375px mobile-first, and produced no console errors. The agent reported:

⁠For a library I assumed was administrative only, this is genuinely strong. Two components, ListCard and RouteStops, could only have been designed for this screen.⁠ ⁠ListCard⁠ carries the flight row: leading for the time, title for the flight number and carrier, description for the city pair, status for a state badge, meta for the gate, and ⁠severity as a left border that makes a delay or cancellation jump out⁠. onSelect with selected gives tap-to-expand and a selection state for free. ⁠The best fit in the whole library.⁠ ⁠RouteStops⁠ carries the departure and arrival legs, with a delayed state, planned against actual times, the minutes lost, and statusLabels to relabel "in transit" as "boarding". A model built for delivery and transit transferred to flight legs with zero friction.

⁠ListCard, which I added in #111, was found immediately again on a passenger-facing air screen.⁠ A shared foundation being discovered independently in another industry showed up here too. The by-use-case table also hit on the first try with no false leads, sending lists and results to ListCard and state with planned-against-actual timing to RouteStops.

Logged, not built

• 🟢 ⁠A segmented control.⁠ Switching between departures and arrivals uses ToggleGroup, whose default styling is "too faint to show which option is selected", so the agent added data-[state=on]:bg-foreground by hand. A switch like this appears on every transit, booking, and status screen and should not need hand styling. Recorded on issue #365; a segmented variant on ToggleGroup would be a cheap fix.
• 🟢 ⁠BadgeVariantKey is not exported from @gunjo/ui,⁠ the single entry point everything imports from, so typing a status-to-variant map needs a ComponentProps workaround. That is a real bug, added to issue #330.
• 🟢 ⁠Banner truncates to a single line,⁠ so multi-line notices belong in Alert. Added to issue #324, along with the corner radius and height fixes a bottom Sheet needed.

⁠No new component was added under src this round.⁠ The 4/5 came from ListCard and RouteStops fitting exactly.

What I took away: passenger screens get scannability, not warmth

The agent's verdict was that ⁠scannability is excellent⁠: the severity border on ListCard plus the state badge makes delays and cancellations surface instantly, which is the entire job of this screen. Its criticism was that ⁠the visual warmth is weak⁠, calling the result a capable, neutral system rather than an expression of a brand. That runs through the whole passenger batch: ⁠an administrative library delivers function and scannability, but feel and brand are a separate layer⁠ (collected on issue #367). Within that limit, this is the round that showed ListCard and RouteStops can carry the functional half of a passenger screen on their own.

Next up

• The last round in this batch: booking management and mileage in #116.

The run

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

Two components fit a flight status board as if they had been designed for it. On the passenger side, the functional foundation holds.