Flight time limits met a roster foundation built for trains, and it held

⁠Build log series⁠: I put a real brief to an AI that has never touched Gunjo (@gunjo/ui), with the public npm package and the gunjo.jp docs as its only material. ⁠This was the third staff-facing air round⁠, an ⁠airline crew scheduling console⁠ covering pilot and cabin crew assignment, flight time limitations, and qualification management. It is the air counterpart of the rail crew screen in #107, and it puts staff-facing air at three screens, symmetrical with rail.

Result: 4.5/5, and the cross-industry test passed a second time

The screen passed tsc at desktop density. The agent reported:

⁠The administrative components were genuinely built for this rather than something to fight.⁠ The assignment grid (ScheduleGrid), the consumption-against-limit meter for flight time limitations (Meter), the queue of items requiring action (ActionQueue), the signed record (SignedRecord), and the person cell (PersonCell) ⁠all worked with no friction, and not one of them gave me trouble.⁠ The docstrings name shift rosters, dispatch, and operations, so the library is clearly aiming at this surface.

After the airline MRO console in #130, ⁠the crew roster and duty hours foundation settled on rail in #107 transferred to airline crew with no structural hand-rolling⁠, across different flight time rules and different qualification regulations. The cross-industry test on the staff-facing foundation passed a second time.

The foundation that crossed industries, from rail #107 to airline crew

• ⁠The assignment roster⁠ goes to ScheduleGrid, whose docstring literally describes a shift roster of people by day: crew by day, a tone and a conflict ring per cell, arrow keys, and contained horizontal scrolling. The rail roster in #107 carried over as it stood.
• ⁠Flight time and duty limits⁠ go to Meter, where the higher-is-worse default means ⁠exceeding a legal limit needs no wiring⁠, and size="sm" fits two bars, flight time and duty time, into one row. The agent called it "the best fit in the library". Rail's hours on duty in #107 became flight time limitations.
• ⁠Items requiring action⁠ (approaching a flight time limit, a check due, an ineligible assignment, insufficient rest) go to ActionQueue, sorted by severity automatically, with a docstring that already cites lapse prevention, renewals, and expiries.
• ⁠Confirming a duty instruction⁠ goes to SignedRecord: draft, then signature lock, then appended corrections, with canSign wired to "no unresolved flags". CoSign was also standing by for two-person confirmation.
• ⁠Crew members⁠ go to PersonCell, with an avatar, role, base, and presence.

⁠Nothing was added under src this round.⁠ The 4.5/5 was the second pass of the cross-industry test, confirming again how settled the foundation is.

The core observation: only qualification expiry had nowhere to live

⁠The one thing specific to crew with no proper home is the qualification currency matrix.⁠ Type ratings, route qualifications, and checks each expire, and turning an expiry date into "valid", "expiring soon", or "lapsed" was hand-rolled with a homegrown currencyOf() classifier and a Badge on top of ScheduleGrid, the general matrix. The table sent qualification expiry to ReferenceValue, but ⁠that classifies numeric ranges and is powerless against a date, so it is a false lead.⁠

I recorded issue #383 for an ⁠ExpiryBadge and CurrencyMatrix⁠: an expiresAt plus thresholds producing valid, expiring soon, lapsed, or not held, as a badge that does not rely on color alone, with the date arithmetic included. ⁠It repeats well beyond crew qualifications, in medical licenses, certifications of every kind, vehicle inspections, and contract end dates.⁠ I corrected the table in PR#384 as well: ReferenceValue is for numbers, and an expiry date is a separate thing.

Sightings of expiry management so far: travel documents in #123 (passport and visa dates, handled with CheckList), MRO in #130 (airworthiness directives, service bulletins, and part life, handled with ActionQueue), and ⁠crew qualifications here, hand-rolled⁠. That makes this the first case under a name of its own.

What I took away: two rounds in a row confirmed the staff-facing foundation

After MRO in #130, crew scheduling here also ⁠stood up on a foundation settled for trains, across different tail numbers, different flight time rules, and different qualification regulations.⁠ Two consecutive rounds with no structural hand-rolling. That is the mirror image of the passenger side, where going deeper poured out gaps and produced eleven components: ⁠the staff-facing foundation no longer moves when a new industry or specialism is applied to it, because it is fully mature.⁠ What remains are thin, cross-cutting pieces, such as the meaning of a date-based expiry that gets rewritten on top of a general matrix every time.

📊 Component scoreboard (⁠11 built⁠)

AmountBreakdown / ActionQueue / ListCard / Gantt-segments / SeatMap / LoyaltySummaryCard / RadioCard / FilterChips / PageHeader / Itinerary / TicketStub In progress: ExpiryBadge and CurrencyMatrix, CheckboxCard, a success variant on StatusScreen, StatusLevel, and an asset row.

📋 Staff-facing and passenger-facing progress: staff-facing air reached its foundation

• ✈️ Air: passenger, all six screens ✅ / ⁠staff, three screens (operations control #113, MRO #130, crew #131), foundation reached and symmetrical with rail⁠ ✅
• 🚆 Rail: passenger, all six screens ✅ / staff, three screens (operations, crew, vehicles), foundation reached ✅

Next up: build log #132

• ⁠Thickening staff-facing rail, with three candidates⁠: station operations and ticket gates, or timetable and transport planning, to take staff-facing rail from its foundation to real depth. After that, ⁠a new mode, bus, on both the staff and the passenger side.⁠

The run

• ⁠gunjo.jp⁠ / ⁠ScheduleGrid⁠ / ⁠Meter⁠ / ⁠SignedRecord⁠ / npm @gunjo/ui / ⁠GitHub⁠ / previous rounds #1 through #130
• ⁠GunjoUI by UIXHERO⁠

A roster foundation built for train crews held up against flight time limits and type ratings. Two rounds running, the staff side did not move.