Yesterday's ActionQueue worked for a different agent today

⁠Build log series⁠: Each round, an AI new to Gunjo (@gunjo/ui) builds a real screen with only the public npm package and the gunjo.jp docs. ⁠This second rail screen moved from the control room⁠ to ⁠crew scheduling and duty management⁠ across rosters, duty sequences, roll call, and working hours. ⁠It was also the first chance to see whether the ActionQueue added in #106 was already discoverable.⁠

#106 covered dispatchers in train control. #107 covered a different role, the crew depot staff responsible for operations and staffing. The central question was ⁠whether another agent would independently find the newly added ActionQueue for incomplete roll calls and overtime alerts.⁠

Result: 4.5/5. The ActionQueue loop closed in one round again

The new ActionQueue was already doing its job on the very next screen. The crew screen passed tsc and build, fit at 375px, and produced no console errors across its metrics, roster, alerts requiring action, duty sequence, roll call, and working hours. The agent reported:

⁠ActionQueue was the single biggest hit for alerts requiring action.⁠ It sorts severity from critical through neutral, shows a kind chip, supports onSelect for drill-down, provides an actions slot, and includes an sr-only severity label instead of relying on color. Given six cases (incomplete roll call, consecutive duty, breathalyzer result, disrupted duty, replacement needed, and reserve assignment), it produced a triage list with ⁠zero custom CSS⁠. ⁠The alert queue required no hand-rolled code.⁠ The by-use-case table led straight from "a queue of items requiring action" to ActionQueue.

⁠I added ActionQueue and its table entry in #106. In the very next round, another agent in a different area, crew staffing, found it independently and used it without friction.⁠ This repeated the AmountBreakdown sequence from #103 and #104: ⁠build a component, then have a different adopter discover it on the next screen. ActionQueue closed that loop in one round too.⁠

Then several other components looked as if they had been made for rail operations:

• ⁠ScheduleGrid⁠ for a crew roster across people and time, with a 2D grid, arrow-key navigation, per-cell tones for conflicts, and contained scrolling on mobile.
• ⁠RouteStops⁠ for a duty sequence from depot departure through train, turnback, and depot return, with automatic planned-versus-actual Delta values and aria-current.
• ⁠SignedRecord plus CoSign⁠ for locking a signed roll call and requiring two people to confirm a duty change.
• ⁠Meter⁠ for hours on duty or consecutive driving against a limit, ⁠ReferenceValue⁠ for checking a breathalyzer reading against its threshold, and StatGroup.

The agent called it "⁠the best-fitting library I have used so far for an operations or control screen.⁠"

What I fixed this round: I added RouteStops to the table

The agent's only case of "it exists, but I cannot find it" was ⁠RouteStops, which did not appear in the by-use-case table and surfaced only after reading the exports from @gunjo/ui.⁠ It called the missing entry for a route, process, or ordered set of stops the highest-value table fix. I added it with PR#353, covering delivery routes, process flows, duty sequences, automatic planned-versus-actual Delta values, and a pointer to ApprovalSteps for approvals. ⁠The component fills a gap, and the table points to it:⁠ the same maintenance loop continued.

Logged, not built: a segmented Gantt bar

The only compromise was ⁠the time-proportional crew-duty bar.⁠ "ScheduleGrid has rich cells but discrete bands, while Gantt has proportional time but thin bars. Nothing sits between them. A continuous 05:40 to 14:10 bar needs segments for depot departure, train, turnback, break, and depot return, plus status tones and click-to-drill-down behavior."

Logged as issue #354, an ⁠extension to Gantt⁠ with segments, renderBar, and onSelectBar. It would carry into rail rosters, projects, and reservations. A selectable list row with a status badge was also hand-rolled for the duty list, adding another case to issue #135.

⁠No new component was added under src this round.⁠ The 4.5/5 result came from independent discovery of ActionQueue in another area and the new table entry for RouteStops.

What I took away: shared foundations prove themselves on the next screen

ActionQueue now spans insurance, train control, and rail crew operations, so it is a ⁠shared foundation for operations work.⁠ An agent found it independently one round after it was built, repeating what happened with StatGroup for metrics and AmountBreakdown for money. Two rail screens also showed ⁠components crossing between separate roles, dispatchers and crew staff.⁠ Testing rail on its own made both the logistics-to-rail reuse of RouteStops and the missing Gantt behavior easy to see.

Next up: build log #108

• I will close the rail set with a third screen such as station operations or vehicle inspection, or move to another mode such as bus, air, taxi, or trucking.

The run

• ⁠gunjo.jp⁠ / ⁠ActionQueue⁠ / the by-use-case table ⁠/docs/by-use-case⁠ / npm @gunjo/ui / ⁠GitHub⁠ / previous rounds #1 through #106
• ⁠GunjoUI by UIXHERO⁠

Yesterday I built ActionQueue. Today a different agent found it without prompting. It used the component for crew alerts.