Round #161Score 4/5Transport: trucking

The fourth value-against-X component settled in trucking compliance

Route: /truck-compliance
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

The fourth value-against-X component settled in trucking compliance

⁠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 third staff-facing trucking round⁠ covered ⁠fleet-and-labor compliance⁠: inspections, digital tachograph driving patterns, hours on duty, continuous driving, and rest under Japanese improvement standards.

Result: 4/5, and the value-against-X family gained a fourth member

The dense desktop screen passed tsc. The agent reported:

⁠The library almost suspiciously fit this domain.⁠ ExpiryBadge explicitly names vehicle inspections, StatusBoard fits dispatch, and ActionQueue fits lapse prevention. It felt as if someone had already shipped a Japanese fleet-and-labor console. The only gap was an hours limit monitor, which kept the score from reaching five.

The core observation: LimitMonitor reached three of three

The screen compared hours on duty, continuous driving, and rest against named limits. Meter seemed close, but the agent found:

⁠The Meter docstring says target is reference-only and does not drive tone.⁠ It can draw a limit line, but the caller must classify the exceeded state. Thresholds are proportions of max, so a warning at 90 percent of a 13-hour standard inside a 16-hour maximum requires brittle arithmetic. ReferenceValue gives exceeded semantics but has no bar or limit line, so it cannot show proximity.

The agent hand-rolled LimitMonitor.tsx. This followed two earlier cases: the operating ratio in , where proportional thresholds failed, and driver hours in , where Meter was composed with ReferenceValue. The third case fired, so I built:

  • LimitMonitor compares a value with named soft and hard limits in real units, such as a 13-hour standard and 16-hour maximum. It derives ok, near, over, or critical, draws limit markers, and shows how close the value is to the limit, or how far beyond it lies. direction="floor" handles a minimum such as 11 hours of rest.
  • It became the fourth value-against-X component beside ExpiryBadge (deadline), ReferenceValue (range), and Meter (capacity). Each has a pure classification counterpart, including classifyLimit.
  • Real-unit limits fixed the dead end caused by a reference-only target and thresholds expressed as fractions of max. I corrected the catalog's value-against-limit guidance away from an incomplete ReferenceValue or Meter answer.

PR#420 confirmed 12.5 hours approaching a 13-hour standard one hour in advance, and 9.5 hours of rest falling 1.5 hours short of an 11-hour floor. Issue #417 closed. ⁠This was the nineteenth component produced by the series.⁠

What I took away: explaining a boundary does not guarantee obeying it

The agent explicitly warned that ⁠the type system does not protect the server/client boundary⁠: importing a function prop into a server component can pass tsc and fail only in the Next.js build. Then it made that exact mistake. It placed hand-rolled classifyLimit in a "use client" file and called it from the server page, causing a runtime 500 while tsc stayed green.

Two lessons followed:

  1. Knowing and explaining a rule is different from following it. Rules not enforced by types still get broken.
  2. A shipped component encodes the right behavior. Gunjo's LimitMonitor and classifyLimit have no client directive and remain server-safe, so adoption removes the trap by design.

For the gallery, I restored rendering by deleting the unnecessary client directive from the agent's pure component, with no behavior change. ⁠What I built under src this round: LimitMonitor.⁠ Its value lies not only in the UI but also in the accessibility and server-rendering rules that adopters receive without having to know them.

📊 Component scoreboard (⁠19 built⁠)

Leaderboard / SegmentedControl / LineChip / ⁠LimitMonitor⁠, plus earlier components In progress: MatchCard or PairingPanel at one of three, SectionList at two of three, and ValidityTimer at one of three.

📋 Mode progress

  • ✈️ Air ✅ / 🚆 Rail ✅ / 🚕 Taxi ✅ / 🚌 Bus ✅
  • 🚚 ⁠Trucking: three staff screens (dispatch, matching, fleet and labor)⁠

Next up: build log

  • Continue staff-facing trucking with freight rates, billing, or transport cost, then move to shipper pickup requests and tracking.

The run

The fourth value-against-X component settled, and the agent fell into the server-rendering trap it had just described. Shipped components matter because they encode rules that prose alone cannot enforce.

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指示書パック」、先行登録を受付中です。