The fourth value-against-X component settled in trucking compliance
/truck-complianceCaptured 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.
ExpiryBadgeexplicitly names vehicle inspections,StatusBoardfits dispatch, andActionQueuefits 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
Meterdocstring saystargetis reference-only and does not drive tone. It can draw a limit line, but the caller must classify the exceeded state. Thresholds are proportions ofmax, so a warning at 90 percent of a 13-hour standard inside a 16-hour maximum requires brittle arithmetic.ReferenceValuegives 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 #154, where proportional thresholds failed, and driver hours in #159, 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 derivesok,near,over, orcritical, 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), andMeter(capacity). Each has a pure classification counterpart, includingclassifyLimit. - 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 incompleteReferenceValueorMeteranswer.
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:
- Knowing and explaining a rule is different from following it. Rules not enforced by types still get broken.
- A shipped component encodes the right behavior. Gunjo's
LimitMonitorandclassifyLimithave 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 #162
- Continue staff-facing trucking with freight rates, billing, or transport cost, then move to shipper pickup requests and tracking.
The run
- gunjo.jp / LimitMonitor / ExpiryBadge / ReferenceValue / Meter / npm
@gunjo/ui/ GitHub / previous rounds #1 through #160 - GunjoUI by UIXHERO
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.