The status board became a component on its third field-operations screen

⁠Build log series⁠: I give 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. ⁠Taxi opened as the fourth mode⁠ after rail, air, and bus, with a ⁠dispatch console⁠ for vehicle status, ride requests, matching, and items requiring action.

Result: 4/5, and the most common field-operations gap triggered a build

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

⁠The four administrative mainstays (ActionQueue, StatGroup, Meter, and MetadataList) fit an unfamiliar taxi mode without being bent at all.⁠ The ActionQueue docstring names dispatch and operations, while Meter with higher-is-better and a target looked designed for the loaded-distance ratio. ⁠But the vehicle status board had no home. The center of the dispatch console was hand-rolled.⁠

The core observation: StatusBoard reached three of three

⁠I logged the first equipment board in station operations in #132, and ramp ground-support equipment supplied the second in #134.⁠ Here another agent hand-rolled a taxi fleet status board. ⁠That was the third case, in another mode.⁠ Across all three screens the agents independently described the same gap and the same component:

⁠There is no status-board, device-grid, or status-matrix component.⁠ ListCard makes each cell easy, but every screen reinvents the board-level behavior: sort by status priority, group by area, and make idle vehicles and faults stand out. ⁠StatusBoard or EntityGrid, with items, a status-to-tone map, groupBy, and onSelect, would reduce about 80 lines to configuration. It is the center of dispatch and monitoring floors, not a HeatmapChart, and now the clearest cross-domain gap in operations.⁠

The agent also rediscovered a false lead: ⁠the catalog pointed status boards to HeatmapChart, a matrix colored by value rather than a board of labeled, clickable entities with states.⁠

Station operations in #132, ramp operations in #134, and taxi dispatch here meant ⁠three independent agents had hand-rolled the same thing.⁠ I built it immediately.

What I built: StatusBoard, the thirteenth component

const groups: StatusBoardGroup[] = [
  { label: "Shibuya area", items: [
    { id: "501", label: "Car 501", icon: <IconCar />, status: "Available", tone: "success", location: "Sato driving", note: "Waiting at Shibuya Station", onSelect: () => open("501") },
    { id: "508", label: "Car 508", status: "Fault", tone: "danger", note: "Engine warning light, action required", onSelect: () => open("508") },
  ]},
]
<StatusBoard groups={groups} />

• Accepts either items[] or groups[], sorts faults first by severity rank, shows a count requiring action per group, and supports selection through onSelect and aria-pressed. State uses an icon and label in a color-safe pill plus a toned accent rail.
• Uses HTML and CSS tiles rather than SVG, with a data-driven layout. It is safe for server rendering because the current time and all displayed times arrive as values; the component never reads the clock itself.
• It fills a structure that Gantt (rows against time), DataTable (sortable table rows), and HeatmapChart (a read-only colored matrix) cannot represent. I corrected the by-use-case catalog to send status boards to StatusBoard.
• PR#393 verified two area sections and seven selectable tiles. Toggling a fault moved its tile to the front and changed the group counter from "4 cars" to "1 needs action", with color-safe pills and no browser errors.

⁠What I built under src this round: StatusBoard, on its third case and as the thirteenth component. Issue #385 closed.⁠

What I took away: the field-operations gap closed in the fourth mode

The staff foundation had already held across new industries, but #132 exposed its first gap when the ⁠data pattern changed from a table to a board⁠. Ramp operations in #134 and taxi dispatch here supplied two more field-operations floors, and the same board pattern settled.

This was the second example, after Stringline, of a ⁠cross-cutting data pattern accumulating across modes until the third case made it real.⁠ The staff foundation was mature by industry but still had gaps by structure: tables in DataTable, rosters in ScheduleGrid, time against distance in Stringline, and now boards in StatusBoard. Taxi, the fourth mode, filled the last major monitoring pattern.

📊 Component scoreboard (⁠13 built⁠)

AmountBreakdown / ActionQueue / ListCard / Gantt-segments / SeatMap / LoyaltySummaryCard / RadioCard / FilterChips / PageHeader / Itinerary / TicketStub / Stringline / ⁠StatusBoard⁠ In progress: BottomActionBar approaching three of three, StatusLevel at two of three, ExpiryBadge at two of three, TransitItinerary legs at two of three, and LineChip at two of three.

📋 Mode progress

• ✈️ Air: five staff + six passenger screens ✅ / 🚆 Rail: five staff + six passenger screens ✅ / 🚌 Bus: two staff + three passenger screens
• 🚕 ⁠Taxi: first staff screen, dispatch⁠ / remaining staff work and the passenger ride-hailing app

Next up: build log #142

• A ⁠passenger-facing taxi app⁠ for ride requests, arrival estimates, fare estimates, the ride, and payment, testing the mobile passenger foundation in a fourth mode and the real-time request pattern.

The run

• ⁠gunjo.jp⁠ / ⁠StatusBoard⁠ / ⁠ActionQueue⁠ / npm @gunjo/ui / ⁠GitHub⁠ / previous rounds #1 through #140
• ⁠GunjoUI by UIXHERO⁠

The most common field-operations gap closed across station, ramp, and dispatch screens. The staff foundation fills structural gaps one data pattern at a time.