The oldest missing component finally shipped after 30 rounds

⁠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 round opened ⁠a new mode, bus⁠, after rail and air, with a ⁠service control screen⁠ covering a stringline diagram, vehicles in service, items requiring action, and control records.

Result: 4/5, and the oldest gap in the series triggered a build

The screen passed its type check at desktop density. The agent reported:

⁠Half of the administrative screen carried over intact even though the mode changed.⁠ ActionDataTable for vehicles in service, ActionQueue for congestion and delays, StatGroup, and SignedRecord with CoSign for control records all worked ⁠without bus-specific gaps or hand-rolling.⁠ These were real operations components, not leftovers from rail or air. Even RouteStops fit the progress of a bus run. ⁠Only the stringline diagram, a time-against-distance graph of diagonal lines, lacked a component. I had to hand-write about 210 lines of SVG.⁠

The core observation: the third Stringline case fired

⁠The agent in #106 hand-rolled a rail control diagram and I logged Stringline. Round #133 supplied the second case in rail timetable planning.⁠ Here a third agent built the diagram again for bus operations. ⁠That made three of three, in a different mode.⁠

The agent: ⁠Gantt uses horizontal bars, with one bus per row, and has no distance axis. A stringline chart puts distance (stops) vertically, and every run is a diagonal line crossing all stops. Its slope shows speed, and two lines drawing closer show one bus catching another. A bar chart cannot structurally show two vehicles converging over distance. I found the same hand-rolled Stringline in the neighboring rail folder. Rail had hit the same wall and rebuilt the same thing. This component is waiting to enter the library.⁠

Rail operations in #106, rail timetable planning in #133, and bus operations here meant ⁠three independent agents had hand-rolled the same missing component.⁠ The rule of three fired, so I built it.

What I built: Stringline, the twelfth component

Issue #352, opened in #106, was the oldest unresolved gap in the series. It finally closed 30 rounds later.

const stops = [{ id: "shinjuku", label: "Shinjuku", distance: 0 }, { id: "tachikawa", label: "Tachikawa", distance: 27.2 }]
const runs = [{ id: "712T", direction: "down", tone: "primary",
  points: [/* planned */], actual: [/* actual, delayed */], onSelect: () => openRun("712T") }]
<Stringline stops={stops} runs={runs} startTime={420} endTime={500} now={450} tickInterval={20} />

• Distance (stops) runs vertically, time horizontally, and each service is a diagonal line. Slope shows speed; converging lines show catching up, passing, or congestion. The rendering follows the same principle as a polyline chart.
• Both directions have defaults, primary for outbound and info for inbound. It includes a current-time line, paired planned (dashed) and actual (solid) paths, selectable services with targets at least 44px wide, station and time grids, and screen-reader support.
• It is safe for server rendering because both the current time and displayed times arrive as values. The component never reads the clock itself, so server and browser output stay aligned.
• I updated the by-use-case catalog from the old warning that Gantt did not support stringline diagrams to guidance that time against distance belongs to Stringline, while air without a fixed route belongs to Gantt or ScheduleGrid.
• PR#388 verified seven diagonal lines, the current-time marker, dashed planned and solid actual lines when delays were toggled, selection on all seven services, time ticks, and no browser errors.

⁠What I built under src this round: Stringline, on its third case and as the twelfth component. Issue #352 closed.⁠

What I took away: waiting gave the component its best design

Stringline remained unsupported for 30 rounds after #106. During that time I:

• wrote an honest unsupported note in the docs catalog, which saved the agent in #133 from forcing Gantt into the wrong job;
• used the second case in #133 to refine the specification;
• confirmed in #135 that the gap ⁠does not appear⁠ in air, where there is no fixed route; and
• got the third case in bus, an independent reproduction in another mode, before building it.

⁠If I had built it in #106, it probably would have lacked a current-time line, planned and actual paths, and both directions.⁠ Evidence from three screens across two modes produced one component that covered live control, timetable planning, and planned-against-actual bus operation. ⁠Letting a missing component wait is design work, not neglect.⁠ The oldest gap in the series demonstrated the real value of the rule of three.

Components added to Gunjo so far (12)

AmountBreakdown / ActionQueue / ListCard / Gantt / SeatMap / LoyaltySummaryCard / RadioCard / FilterChips / PageHeader / Itinerary / TicketStub / ⁠Stringline⁠

Mode progress

• ✈️ Air: five staff + six passenger screens ✅ / 🚆 Rail: five staff + six passenger screens ✅
• 🚌 ⁠Bus: first staff screen, operations control⁠ / remaining staff work (dispatch and crews) plus passenger routes, arrivals, and fares

Next up: build log #137

• A ⁠passenger-facing bus screen⁠ for stops, arrivals, fares, and boarding, testing how PageHeader, ListCard, FilterChips, and TicketStub carry into bus, or another staff-facing bus screen.

The run

• ⁠gunjo.jp⁠ / ⁠Stringline⁠ / ⁠Gantt⁠ / npm @gunjo/ui / ⁠GitHub⁠
• ⁠GunjoUI by UIXHERO⁠

The oldest gap finally closed after 30 rounds, on its third case in another mode. Waiting supplied the evidence to build the full component in one pass.