A rail inspection foundation carried straight into aircraft maintenance
/aircraft-maintenanceCaptured 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
A rail inspection foundation carried straight into aircraft maintenance
Build log series: The series gives an AI with no exposure to Gunjo (
@gunjo/ui) the public npm package and the gunjo.jp docs, then asks it to build a screen that would be used at work. This was the second staff-facing air round, filling in the foundation after the operations control center in #113, an aircraft maintenance console for maintenance, repair, and overhaul (MRO) covering the fleet, maintenance intervals, dock assignment, items requiring action, and maintenance sign-off. It is the air counterpart of the rail vehicle inspection screen in #108.
Why this round: answering "are the staff-facing screens done?"
Last time I went back through the ledger to answer whether rail and air were finished on the staff side. Rail had three staff-facing screens, for operations, crew, and vehicles, and had reached its foundation, while air had only #113. The gaps pouring out of the passenger side had pulled my attention there, and staff-facing air stayed thin. So I filled it in, and there was something I wanted to test at the same time: would the maintenance foundation settled across 14 industries and rail (an asset table, a consumption-against-limit meter, a timeline schedule, an action queue, and a signed record) carry into airline MRO with no changes?
Result: 4.5/5, with no structural hand-rolling
The screen passed tsc at desktop density. The agent reported:
As an operations console, this is unmistakably built for the job. Every administrative pattern the screen needed had a dedicated component, all with no friction:
ActionQueue,SignedRecord,Meter,Gantt,ScheduleGrid,ActionDataTable, andStatGroup. Nothing forced me to hand-roll anything. The library is more finished for operations consoles than it is for marketing.
Crossing industries: the rail #108 foundation transferred to airline MRO
What worked for rail vehicle inspection in #108 carried into airline MRO, where the tail numbers, the aircraft types, and the maintenance regulations are all different:
- Remaining maintenance interval goes to
Meter, whosehigher-is-worsedefault already treats close to or over the limit as destructive, so that needs no wiring, withsize="inline"for table cells. The agent called it "a standard component built for deadline indicators". Rail's distance run against its limit in #108 became flight hours and cycles against the maintenance limit. - Dock assignment goes to
Gantt, whose docstring uses a maintenance window as its literal example, plusScheduleGrid, which gave a hangar-by-seven-days occupancy matrix as a free second view. - Items requiring action (airworthiness directive and service bulletin deadlines, minimum equipment list rectification, limits about to be exceeded) go to
ActionQueue, sorted by severity automatically, with icons, and never relying on color alone. - Maintenance sign-off by the certifying engineer goes to
SignedRecord, which locks on signature after a draft and keeps a chain of appended corrections. The agent called it "the hardest item, and the most finished". - The fleet list goes to
ActionDataTable, general purpose, with row selection throughdata-stateand aMeterand controls on each row.
The agent's conclusion: "Nothing about this feels like a consumer library stretched into a dashboard. An asset table, a consumption-against-limit meter, a resource-by-time schedule, a triage queue, and a signed record are each a named, finished component."
src gained nothing new this round. The 4.5/5 came from the staff-facing foundation carrying over intact, which is the evidence of how settled it is.
The small gaps I picked up, and logged
- 🟡
Meterdoes not sync its announced value.formatValuechanges only the display while the announced value stays as value and max, so avalueTextis needed. Recorded on issue #381. - 🟡
InspectorPaneldefaults to a fixedw-[320px] h-[420px], which has to be overridden when it is embedded in a grid. Same issue. - 🟠 An asset status row component, sitting between
ActionDataTableandListCard: a row with a status, key and value pairs, a trailingMeter, and controls. Same issue, at one of three. - ✅ A table correction in PR#382: "list with status" had been sending people to the mobile
ListCard, so it now states that a desktop-density fleet or asset grid belongs toDataTableorActionDataTable.
What I took away: the staff-facing foundation no longer moves in a new industry
The staff-facing foundation settled across 14 administrative industries went through rail and then stood up in airline MRO, an entirely separate specialism, with no structural hand-rolling. That is the opposite of what the passenger side looks like: the deeper I go with passengers, the more gaps pour out, and eleven components have come from it. The staff side no longer moves when a new industry is applied to it, because it is fully mature. The real answer to "are the staff-facing screens done?" is not a question of how many screens exist, but of how settled the foundation is. Staff-facing air was thin in count, and the foundation worked perfectly the moment it was tested. One more screen, crew scheduling, puts staff-facing air on solid ground too.
📊 Component scoreboard (11 built)
AmountBreakdown / ActionQueue / ListCard / Gantt-segments / SeatMap / LoyaltySummaryCard / RadioCard / FilterChips / PageHeader / Itinerary / TicketStub In progress: CheckboxCard, a success variant on StatusScreen, StatusLevel, an asset row, and BottomActionBar.
📋 Staff-facing and passenger-facing progress
- ✈️ Air: passenger, all six screens ✅ / staff, two screens (operations control in #113 and MRO in #130), with crew scheduling still to come for the foundation
- 🚆 Rail: passenger, all six screens ✅ / staff, three screens (operations, crew, vehicles), foundation reached
Next up: build log #131
- Staff-facing air crew scheduling: pilot and cabin crew assignment, flight time limitations, and qualifications. It is the air counterpart of the rail crew screen in #107 and would put staff-facing air on its foundation. After that, thickening staff-facing rail with station operations and timetable planning, then bus.
The run
- gunjo.jp / Meter / Gantt / SignedRecord / npm
@gunjo/ui/ GitHub / previous rounds #1 through #129 - GunjoUI by UIXHERO
A maintenance foundation settled on trains held up against different tail numbers and different regulations. On the staff side, a mode finishes when the foundation is mature, not when the screen count looks right.
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.