The next delivery screen proved that a one-line catalog fix worked

⁠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 second customer-facing trucking round⁠ followed the shipper portal with a mobile ⁠parcel tracking and redelivery flow⁠ for recipients: tracking, redelivery requests, delivery windows and methods, and notifications.

Result: 4/5, and the previous catalog correction was validated immediately

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

⁠This was a genuinely strong mobile library for recipients.⁠ Nearly every needed component existed, mobile-first behavior came by default, and the by-use-case catalog made every decision correctly. The one-point deduction came from missing multiday tracking.

The first core observation: the TimePicker correction worked one screen later

In #164 I found that the catalog substituted exact-time TimePicker for delivery windows. PR#423 corrected windows to SegmentedControl or RadioGroup and clarified that TimePicker selects an exact time. Here the agent said:

⁠Delivery windows needed no hand-rolling or confusion.⁠ The catalog explicitly said that delivery and pickup windows use SegmentedControl or RadioGroup, not TimePicker. I used SegmentedControl. A new adopter might grab the existing TimePicker, but the catalog actively steered me away from that trap.

The agent wrote zero TimePicker workaround code. A substitution trap found in #164 was closed and the next adopter landed on the right answer. Catalog fixes have the same build-to-validation loop as components: even a cheap guidance edit only proves itself when a later agent avoids the trap.

TimeBandPicker stayed at one of three. Because corrected guidance removed the friction, there was no reason to rush a dedicated component.

The second core observation: multiday RouteStops reached two of three

RouteStops fit received, in transit, out for delivery, and delivered states, but parcels cross dates:

⁠The catalog correctly recommends RouteStops, but its per-stage time model only accepts plannedTime and actualTime as HH:MM.⁠ Parcel tracking runs from receipt on June 27 to delivery on June 29. The component cannot represent the dates, and delayMinutes assumes one day, so I forced the date into metadata. It needs a date, timestamp, or dateLabel per stop and optional grouping by day.

This was the second case on issue #422, after the shipper portal in #164. A third multiday tracking screen would trigger a free-form timestamp while preserving the existing intraday HH:MM path.

What I took away: guidance fixes also need later validation

The series now has two validation layers:

1. ⁠Build a component, then watch a later agent find it⁠, as with SectionList from #162 to #164.
2. ⁠Fix the catalog, then watch a later agent avoid the old trap⁠, as with exact time versus time window from PR#423 to this screen.

The second is cheap to implement but still measurable only through later behavior. A mature foundation runs both loops: components close missing behavior, guidance closes traps, and later screens verify each.

What it flagged

• 🟡 Multiday timestamps on RouteStops, now two of three.
• ✅ The TimePicker substitution fix worked, so TimeBandPicker stayed at one of three.
• ✅ RadioCard for delivery method, SegmentedControl for the window, DatePicker, BottomActionBar, and Switch all fit directly. RouteStops also had the right default delivery vocabulary.

⁠Nothing new was added under src this round.⁠ The 4/5 validated the prior guidance change and moved multiday tracking to two of three.

📊 Component scoreboard (⁠20 built⁠)

Two of the six components added this session: LimitMonitor / SectionList. In progress: ⁠multiday RouteStops at two of three⁠, Statistic goodWhen at two of three, TimeBandPicker at one of three, and MatchCard at one of three.

📋 Mode progress

• ✈️ Air ✅ / 🚆 Rail ✅ / 🚕 Taxi ✅ / 🚌 Bus ✅
• 🚚 ⁠Trucking: five staff + two customer-facing screens (shipper portal and parcel tracking)⁠

Next up: build log #166

• Continue customer-facing trucking with shipper billing and documents, or personal delivery-location settings. Another multiday tracking screen could trigger the RouteStops extension.

The run

• ⁠gunjo.jp⁠ / ⁠RouteStops⁠ / ⁠SegmentedControl⁠ / ⁠RadioCard⁠ / npm @gunjo/ui / ⁠GitHub⁠ / previous rounds #1 through #164
• ⁠GunjoUI by UIXHERO⁠

The previous catalog correction proved itself on the next screen. Guidance changes have their own build-to-validation loop, and this one reduced the TimePicker workaround count to zero.