A station console exposed the first board-shaped gap in the staff toolkit
/station-opsCaptured 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 station console exposed the first board-shaped gap in the staff toolkit
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. This deepened staff-facing rail coverage beyond operations, crews, and vehicles with a station operations console for Shinjuku Station: an equipment status board, lost property, fare adjustment, and shift handover.
Result: 4.5/5. The backbone needed no work, but one pattern had no home
The desktop-density screen passed tsc. The agent reported:
The administrative backbone was present and built for this work.
SignedRecordfor signed handover,Meterfor consumption against a limit,ActionQueuefor items requiring action,ActionDataTablefor row and bulk operations,StatGroupfor KPIs, andAmountBreakdownfor collected fares all carried over from operations, crew, and maintenance without changes or friction. The backbone remained the library's strength.
The same foundation held in a third staff-facing rail domain. For the first time, however, one piece had no place in it.
The core observation: a different data pattern exposed a staff-facing gap
Station operations exposed a live equipment status board. Operations uses a train list, crew management uses a roster, and maintenance uses work orders. Those are all tables or lists, so
DataTable,ScheduleGrid, andActionQueuework. A station floor is different: physical devices sit in space and faults need to stand out. That is a board, not a table, and the library had no answer.AssetCardandAssetGridtarget image assets withsrc, preview, and ratings; they have no first-class status field and do not fit an equipment board.
I recorded issue #385 for StatusBoard or DeviceGrid: items[] with {label, location, status, tone, note?, updatedAt?}, faults sorted first, tiles with an icon and label so state does not depend on color, each tile as one accessible unit, and a grid layout. It recurs beyond stations in depots, factory lines, and airport equipment. The agent called EquipmentBoard.tsx a specification for the missing component.
Nothing new was added under src this round. The 4.5/5 left StatusBoard at one of three, waiting on the rule of three.
Why the gap matters: the staff foundation breaks by data pattern
Rounds #130 and #131 had shown twice that the staff-facing foundation stayed stable in a new domain. Here the same backbone remained excellent, but the moment the data moved from a table to a spatial board, there was nowhere to put it. That sharpened the map of a mature staff toolkit:
- Table, list, and roster data: the foundation is complete (
DataTable,ScheduleGrid,ActionQueue,SignedRecord, andMeter). - Board data, where equipment has a location and faults need prominence: the foundation is missing
StatusBoard.
The remaining staff-facing gaps therefore open by data pattern, not by industry. Lost property fit ActionDataTable outright because it is a table. On one screen, the pattern alone decided whether the foundation covered the work.
Smaller findings
- 🟡
PersonCell.secondarydoes not matchPageHeader.subtitle. The inconsistent prop names for secondary text cost the agent onetscround trip. I recorded it on issue #385. - ✅ The by-use-case catalog produced no false leads. It had no status-board row, which helped confirm that the gap was real.
📊 Component scoreboard (11 built)
AmountBreakdown / ActionQueue / ListCard / Gantt-segments / SeatMap / LoyaltySummaryCard / RadioCard / FilterChips / PageHeader / Itinerary / TicketStub In progress: StatusBoard or DeviceGrid, ExpiryBadge or CurrencyMatrix, CheckboxCard, a success variant on StatusScreen, and StatusLevel.
📋 Staff-facing and passenger-facing progress
- ✈️ Air: six passenger screens ✅ / three staff screens ✅
- 🚆 Rail: six passenger screens ✅ / four staff screens (operations, crews, vehicles, station operations), now deeper, with timetable planning still to come
Next up: build log #133
- Staff-facing rail timetable and transport planning, covering timetable construction and vehicle diagrams. It will test whether the
Stringlinechart logged in #106 returns for a second case. The next new mode after that will be bus.
The run
- gunjo.jp / ActionQueue / SignedRecord / ActionDataTable / npm
@gunjo/ui/ GitHub / previous rounds #1 through #131 - GunjoUI by UIXHERO
After twice proving that industries did not shake it, the staff foundation finally revealed where it breaks: when the data changes from a table to a board.
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.