The use-case table returned seven answers with no false leads
/rail-maintenanceCaptured 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
The use-case table returned seven answers with no false leads
Build log series: An AI that has never used Gunjo (
@gunjo/ui) gets only the public npm package and the gunjo.jp docs, then builds a real screen. The third rail round completed the set with vehicle inspection and maintenance management across train sets, inspection intervals, plans, and records.
After train control in #106 and crew operations in #107, this round covered equipment and maintenance. Together, the three screens tested rail across operations, people, and vehicles.
Result: 4.5/5. The by-use-case table was flawless
Seven needs produced seven useful component suggestions, with no false lead and nothing hidden. The screen passed tsc and build, fit at 375px, and produced no console errors across its metrics, train-set list, inspection intervals, inspection plan, action queue, and records. The agent reported:
The
/docs/by-use-casetable was excellent and accurate. With seven needs described from scratch, it returned the right components:DataTable,ReferenceValueplusMeter,Gantt,ActionQueue,SignedRecord, andStatGroup, each with a one-line explanation in Japanese. There were no false leads and no cases of an existing component going undiscovered. That is why a new adopter can land on components instead of hand-rolling the screen.
In #101 the table rescued CoSign; in #102 it misdirected an amount breakdown; and in #103 and #106 I kept correcting gaps. By #108, it had reached "all correct, no false leads." The accumulated payoff from fixing discoverability on every round showed up here as a perfect result.
Every component choice landed cleanly:
-
Meterfor an inspection interval against its limit was the best fit this round. Distance traveled against the next inspection limit and elapsed days against the day limit usevalue,max, andthresholdsfor automatic tones from green to yellow to red, an overdue flag above 100%, andsize="inline"directly inside a table cell. -
Gantt for the shop-entry and release plan, ActionQueue for items requiring action and its third straight rediscovery, SignedRecord for locking signed inspection records, DataTable withrenderCardon mobile, ReferenceValue, andStatGroup.
The agent described Gunjo as "a library clearly designed for administrative, operations, and regulated-record screens, which is exactly this field."
Logged, not built (second case): a segmented Gantt bar
The only limitation was that a
GanttItemhas just one label and tone, so the shop-entry, inspection, and release stages cannot appear as segments or progress within one bar. "AddingsegmentsorprogresstoGanttItemwould be the single most valuable improvement."
I added the second case to issue #354: crew duties in #107 and the inspection plan in #108 put segmented Gantt bars at two of three. One more scheduling screen would trigger the rule of three and an extension to Gantt. I also added evidence about inconsistent tone naming (variant on Badge, but tone on Meter and Gantt) to issue #294.
No new component was added under src this round. The 4.5/5 result came from a flawless table and renewed use of ActionQueue and Meter.
What I took away: repeated discoverability fixes finally reached a perfect result
Earlier in the series, I wrote that discoverability, not features, was the last major challenge, then built the by-use-case table in #100. I kept refining it in #101 (CoSign surfaced), #102 (amount breakdown misdirected), #103 (redirected to AmountBreakdown), #106 (NotificationCenter and Gantt false leads fixed), and #107 (RouteStops added). In #108, those fixes paid off: all seven needs returned the right answer with no false leads. Building components and repeatedly pointing the table toward them eventually let an agent new to Gunjo find everything on the first try. The feature foundation (StatGroup, AmountBreakdown, and ActionQueue) and the table that exposes it finally worked together end to end.
This third rail screen closed the first transportation mode after train control and crew operations. ActionQueue was rediscovered on three consecutive screens, and Meter fit kilometer-based inspection intervals. Splitting transportation by mode made the point of completion for rail unusually clear.
Next up: build log #109
- I will move to another mode such as bus, air, taxi, or trucking while continuing to watch for the third segmented Gantt case.
The run
- gunjo.jp / ActionQueue / the by-use-case table /docs/by-use-case / npm
@gunjo/ui/ GitHub / previous rounds #1 through #107 - GunjoUI by UIXHERO
The table returned seven correct answers with no false leads, closing the three-screen rail operations set.
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.