Round #157Score 4.5/5Transport: bus

One service-status screen validated, ruled out, and created components

Route: /bus-service-status
Desktop preview
Mobile preview

Captured 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

One service-status screen validated, ruled out, and created components

⁠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 fifth passenger-facing bus round⁠ covered ⁠service status, delays, and cancellations⁠: overall condition, route-level normal, delayed, or suspended states, notices, a history, and notifications. It was the first customer service-status screen across the modes.

Result: 4.5/5, with three different test outcomes on one screen

The screen passed tsc and fit a 375px mobile-first layout. The agent reported:

⁠A new adopter built a real accessible service-status screen with almost no hand-rolling.⁠ JSDoc and the by-use-case catalog repeatedly name service status, giving this domain unusually precise guidance.

The same screen produced three outcomes: validation, a confirmed non-gap, and a new component.

First: the day-old SegmentedControl was independently found

The all-routes versus disruptions-only filter used the component built in :

SegmentedControl fit the two exclusive filters.⁠ size="lg" made it 44px tall, with a real radiogroup and arrow keys. The catalog led to it correctly and gave a clear rule: two to four exclusive options use SegmentedControl, many horizontally scrolling categories use FilterChips, and multi-select uses ToggleGroup.

Built and documented one round earlier, SegmentedControl was found without prompting and used with no friction. The next adopter proved that it had closed the gap.

Second: StatusLevel was not a gap

Normal, delayed, and suspended need an indicator that does not rely on color. The agent looked for StatusLevel, then concluded it was unnecessary:

⁠There was no StatusLevel, ServiceStatus, or StatusPill, but the catalog explicitly says ordered levels use Badge with a leading icon and a semantic tone, keeping the state clear without color. That fit perfectly, and I did not feel a gap.⁠

This negative confirmation matters. Like air not needing Stringline in , it clarified something Gunjo ⁠does not need to build⁠. Badge with an icon already represents an accessible ordered status. The test maps both required and unnecessary components.

Third: LineChip reached three of three

The route-number chip, route 88 in a route color, was hand-rolled for the third time:

⁠There was no line or route chip.⁠ The ListCard.leading JSDoc even names a line chip as its intent, but the library did not ship one, so I wrote a span.

After a colored square in and an outlined pill in , this was the third implementation. I built:

  • LineChip, filled with any route brand hex color and using luminance to choose black or white text automatically and deterministically on the server. The label carries meaning, so the component remains readable without color or in monochrome.
  • It is the identity counterpart to Badge. Badge uses semantic tone variants; a route chip needs an arbitrary brand color with guaranteed contrast.

PR#416 confirmed white text on dark red #e60012 and black text on light orange #f5a200 and green #9acd32. Issue #392 closed. ⁠This was the eighteenth component produced by the series.⁠

What I took away: the test has three outputs

The two endings described in , build and validate, gained a third here:

  1. ⁠Build⁠ when the third case arrives: LineChip.
  2. ⁠Validate⁠ when a later agent finds a previous build: SegmentedControl.
  3. ⁠Confirm a non-gap⁠ when existing components already cover the need: Badge instead of StatusLevel.

A mature screen can extend the catalog in all three directions at once. Passenger coverage makes that especially likely because it hits stored candidates, exercises recent builds, and tests whether the existing foundation is sufficient.

What it flagged

  • 🟡 Statistic had no tone or icon for a severe count such as suspended services. I added this to issue #412, alongside inverted metrics.
  • ListCard, Badge with icon, Timeline, Alert, Sheet, and PageHeader all fit, with state cues that did not rely on color.

⁠What I built under src this round: LineChip.⁠ The 4.5/5 also validated SegmentedControl and confirmed that StatusLevel did not need a component.

📊 Component scoreboard (⁠18 built⁠)

Gantt with intraday resolution / Leaderboard / SegmentedControl / ⁠LineChip⁠, plus earlier components In progress: ComparisonTable, tone and icon on Statistic, ValidityTimer at one of three, and ReferralCard.

📋 Mode progress

  • ✈️ Air ✅ / 🚆 Rail ✅ / 🚕 Taxi ✅
  • 🚌 ⁠Bus: five staff + five passenger screens⁠, one passenger screen short of comparable depth
  • 🚚 Trucking: not started

Next up: build log

  • Finish passenger bus with IC balance and charging or a commuter pass, reaching five staff and six passenger screens, or open trucking.

The run

One screen validated a recent build, confirmed another component was unnecessary, and created a third. Mature testing maps what to build and what to leave alone at the same time.

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.

業界別「AI指示書パック」、先行登録を受付中です。