A ramp console hand-rolled the same equipment board for the second time

⁠Build log series⁠: An AI that has not seen Gunjo (@gunjo/ui) before works from the public npm package and the gunjo.jp docs alone, then builds a screen from real work. ⁠Thickening staff-facing air⁠, this was a ⁠ground handling and ramp control console⁠ covering ground support equipment, stands, turnaround progress, and shift handover. It is the air counterpart of the rail station operations screen in #132.

Result: 4/5. The backbone was the highlight, and the equipment board was hand-rolled again

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

⁠ActionQueue and SignedRecord are the highlights of an operations console.⁠ They encode the right domain model: triage by severity, and sign, lock, then append. CoSign fits a two-person safety confirmation exactly. RouteStops and StatGroup had no friction either. ⁠But there is nowhere to put the ground support equipment status board. Hand-rolled again.⁠

The first core observation: StatusBoard reached two of three

⁠I logged StatusBoard after station operations in #132 hand-rolled an equipment status board.⁠ Here the agent hand-rolled the ground support equipment board again, covering tugs, belt loaders, high lifts, ground power units, preconditioned air units, passenger boarding bridges, and cargo dollies. ⁠That is the second case.⁠ More striking still: without being asked, it named the same specification #132 had, and the same places the gap would recur:

"⁠I reimplemented an asset status grid with locations and fault prominence, the same thing station operations, rail vehicle maintenance, and equipment effectiveness all need. The missing component is a StatusBoard or DeviceGrid: a grid of {id, group, location, status, note}, status mapped to tone, faults sorted first, and a fault count per group. It is the single gap that cuts across every field operations domain.⁠"

I added the second case to issue #385 and refined the specification with ⁠grouping by type or zone and a fault count per group.⁠ ⁠A third case, from overall equipment effectiveness on a manufacturing line, a line status board, or warehouse equipment in logistics, and I build it.⁠

The second core observation: RouteStops fits a staged operational sequence, and the table was underselling it

Turnaround progress (arrival, bridge on, unloading, fuelling, loading, pushback, departure, each with planned and actual times and a state) came out like this:

"⁠RouteStops is a perfect fit. plannedTime and actualTime with an automatic Delta, and statusLabels to relabel, make it ideal for watching scheduled departure time. It suits this better than Stepper, which is wizard progress with no timing and no delta.⁠ But the table sends staged progress to Stepper and ApprovalSteps, and I only found RouteStops by reading @gunjo/ui, the single entry point everything imports from. The table undersells what RouteStops can do."

I corrected the table in PR#387: RouteStops covers status tracking ⁠and⁠ staged operational progress (turnarounds, production processes, repair flows), and where there is planned-against-actual timing it beats Stepper. ⁠The boundary settled for baggage in #124 reached the ramp turnaround as well.⁠

⁠No new component was added under src this round.⁠ The 4/5 left StatusBoard at two of three, waiting on the rule of three.

What I took away: a gap and a fit can advance on the same screen

One screen moved two things at once:

• ⁠The gap advanced⁠: StatusBoard went from one of three to two of three, as a station equipment board returned as a ramp equipment board.
• ⁠The fit advanced⁠: the boundary of RouteStops, settled in #124 as belonging to status tracking, reached a turnaround on the ramp, and the table stopped underselling it.

So depth is not only about accumulating gaps. It ⁠checks the boundaries of existing components in another context and repairs the false leads in the table⁠ at the same time. StatusBoard waits for its third case, while RouteStops has its scope pinned down further every time it gets used.

📊 Component scoreboard (⁠11 built⁠)

AmountBreakdown / ActionQueue / ListCard / Gantt-segments / SeatMap / LoyaltySummaryCard / RadioCard / FilterChips / PageHeader / Itinerary / TicketStub In progress: ⁠StatusBoard at two of three⁠, ⁠Stringline at two of three⁠, ExpiryBadge, CheckboxCard, an intraday mode on Gantt, and a success variant on StatusScreen.

📋 Staff-facing and passenger-facing progress

• ✈️ Air: passenger, six screens ✅ / ⁠staff, four screens (operations control, MRO, crew, ground handling)⁠, deeper now, and one more (network and slot planning) makes it symmetrical with rail's five
• 🚆 Rail: passenger, six screens ✅ / staff, five screens ✅

Next up: build log #135

• ⁠Staff-facing air network and slot planning⁠: routes and frequencies, airport slots, and aircraft assignment. As the air counterpart of the rail timetable planning screen in #133, it takes staff-facing air to five screens, fully symmetrical with rail. After that, ⁠the new mode, bus⁠, where a third Stringline case is the main hope.

The run

• ⁠gunjo.jp⁠ / ⁠RouteStops⁠ / ⁠ActionQueue⁠ / ⁠CoSign⁠ / npm @gunjo/ui / ⁠GitHub⁠ / previous rounds #1 through #133
• ⁠GunjoUI by UIXHERO⁠

The equipment board came back for a second case, and RouteStops reached the ramp. Depth stores up gaps while sharpening the map of what already exists.