A third hand-built queue became a catalog component
/rail-operationsCaptured 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 third hand-built queue became a catalog component
Build log series: I ask an AI that has never seen Gunjo (
@gunjo/ui) to build real screens from only the public npm package and the gunjo.jp docs. I treat transportation as separate modes (taxi, bus, rail, air, and trucking), and this first rail screen was a train operations control room covering train lists, service disruptions, a train graph, and service recovery.
Transportation is a category, not one industry. Rail, bus, air, taxi, and trucking all work differently, so I test each mode as a foundation in its own right. For rail, the central question was whether a third hand-built queue of items requiring action would be enough to build ActionQueue for real.
Result: 4/5, and the third case triggered a second straight build
A disruption queue became the third independent version of the same missing pattern. The screen passed tsc and build, fit at 375px, and produced no console errors across its metrics, disruption alerts, train status list, train graph, and service-recovery log. The agent reported:
The disruption alert queue was hand-rolled. There was "no component for a queue of items requiring action, sorted by severity." The by-use-case table pointed to
NotificationCenter, but that was "a bell popover, not an inline triage list" with severity, kind, and a recommended action. The agent assembledAlert, twoBadgecomponents, andButtonin severity order instead. "This is the single largest recurring gap. Every operations, monitoring, or control screen needs exactly this, and every team has to rebuild it from Alert and Badge. It would be the most valuable addition."
Three screens in a row produced the same pattern: the immediate-action list in #102, the alerts requiring action in #105, and the disruption queue in #106. Three separate agents independently hand-rolled the same queue. That triggered the rule of three. It was built for real on the spot. This made two catalog additions in succession after AmountBreakdown for insurance.
Built for real: ActionQueue
The doc example below comes from the insurance round that produced the first case:
<ActionQueue
items={[
{ severity: "critical", kind: "Lapse risk", title: "Tadokoro - whole-life policy lapses at month end",
detail: "Place the lapse-prevention call today.", meta: "Today", actions: <Button size="sm">Follow up</Button> },
{ severity: "warning", kind: "Renewal", title: "Miyake - renewal deadline", meta: "7 days left" },
{ severity: "info", kind: "Birthday", title: "Usami - birthday", meta: "Tomorrow" },
]}
/>
severity(critical/warning/info/neutral) determines the icon, tone, and order when sorted. Severity is conveyed through icon shape, tone, and an sr-only label, not color alone.- The trailing
actionsrenders beside the row button rather than inside it,onSelectactivates the row, and server rendering is safe by default. - The other half of a morning dashboard, paired with
StatGroupfor metrics, was now in place. - Closed issue #350 with PR#351.
I also fixed two entries in the by-use-case table
- I corrected the false lead from an action queue to
NotificationCenter by separating an action queue (ActionQueue), a one-off notice (Alert), and the persistent bell (NotificationCenter). - I annotated the false lead from
Ganttto a train graph.Ganttuses packed horizontal bars and does not draw the intersecting diagonal lines of a rail timetable graph, so the table now says that use case is unsupported.
Logged, not built: Stringline (train graph)
The time-distance train graph was also hand-rolled in SVG. "Gantt has packed bars, while a train graph has intersecting diagonal lines. They are structurally different, and those lines are the data, so SVG is a legitimate exception."
Logged as issue #352. It is specific to rail, so it ranks below the cross-industry ActionQueue, but it is central to a rail timetable screen. A second case in another transportation mode would strengthen it. Another useful result was that RouteStops, designed for logistics deliveries, fit vehicle assignments and turnbacks almost uncannily well in another industry.
What was added under src this round: ActionQueue, on its third case.
What I took away: the cross-industry foundation still had room to grow
I had written that five insurance screens had finished the job, but one more cross-industry component was still missing. ActionQueue is the other half of the morning dashboard found in insurance, rail, and any operations screen. After StatGroup for metrics and AmountBreakdown for money, it became the third piece of the shared foundation for people at work. Stringline, by contrast, is specific to rail. The rule of three is separating components that carry across industries from foundations needed by only one mode.
Next up: build log #107
- I will watch for
ActionQueueor Stringline in a second rail screen for crew or vehicle operations, or move to another mode such as bus, air, taxi, or trucking.
The run
- gunjo.jp / ActionQueue / AmountBreakdown / the by-use-case table /docs/by-use-case / npm
@gunjo/ui/ GitHub / previous rounds #1 through #105 - GunjoUI by UIXHERO
The third hand-built action queue became ActionQueue on the spot.
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.