Round #149Score 4/5Transport: taxi

A taxi receipt showed that mature components must also be left unused

Route: /taxi-history
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

A taxi receipt showed that mature components must also be left unused

⁠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 deeper passenger-facing taxi round⁠, after ride hailing and booking, covered ⁠ride history, receipts, and expense reporting⁠: a history list, receipt issuance, payee and description fields, and grouped expenses.

Result: 4/5. The passenger account foundation held

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

⁠The library fit a Japanese passenger history and receipt screen.⁠ PageHeader, LoyaltySummaryCard, StatGroup, FilterChips, ListCard, AmountBreakdown, EditableField, Sheet, and BottomActionBar formed the skeleton directly, with yen defaults.

ListCard handled ride history, LoyaltySummaryCard with StatGroup summarized use, FilterChips filtered it, AmountBreakdown plus EditableField and Sheet produced the receipt, and BottomActionBar handled bulk expense selection. BottomActionBar had been independently found on three consecutive screens, from through #149.⁠

The core observation: TicketStub was correctly left unused

A naive component match might treat a receipt as another ticket face and choose TicketStub. The agent did not:

TicketStub does not fit a receipt, and its docstring says why.⁠ It is a scannable pass, coupon, or membership face with a barcode or QR and readable code, the passenger counterpart to scan input. A paper tax receipt in Japan has no barcode. Using TicketStub here would be wrong, so I did not.

This was the reverse of independent cross-industry discovery: a mature decision ⁠not to carry a component across a boundary.⁠ When I built TicketStub in , its docstring named the passenger counterpart to ScanInput, boarding passes, coupons, and membership cards, while the catalog split reading a code from presenting one. Nine rounds later, that scope told another agent ⁠not⁠ to use it for a receipt.

A docstring should say not only where a component belongs but also ⁠where it does not.⁠ The two sides together prevent misuse. This followed the same pattern as HeatmapChart in , whose boundary needed both a no and a yes. A settled component is truly mature when adopters both use it correctly and leave it unused correctly.

What it flagged: grouped history and a mobile multi-select false lead

  • 🟠 SectionList or GroupedList.⁠ The agent hand-rolled monthly groups with a heading, rows, and subtotal. ListCard owns one row, but there is no component for the grouped backbone of history, statements, transactions, and line items. I recorded it on issue #404. StatusBoard.groups[] and Itinerary.days[] do not provide a general grouped row list.
  • ✅ The catalog sent mobile multi-select and bulk actions to desktop-oriented DataTable. I corrected it in PR#405 to recommend ListCard, checkboxes, and BottomActionBar. The catalog had silently favored staff dashboards over passenger selection.
  • 🟡 ListCard.selected changed appearance but exposed no aria-pressed or selected state. I added that finding to issue #404.

⁠Nothing new was added under src this round.⁠ The 4/5 confirmed the account foundation across industries, settled the boundary of TicketStub, logged SectionList, and corrected the catalog.

📊 Component scoreboard (⁠15 built⁠)

Earlier components plus PageHeader / Itinerary / TicketStub / Stringline / StatusBoard / ExpiryBadge / BottomActionBar In progress: SectionList, DateTimePicker and PlaceField, ApproachCard, StatusLevel at two of three, and Leaderboard or CaseTable.

📋 Passenger-facing taxi progress

  • 🚕 ⁠Taxi: six staff / three passenger screens (ride hailing, booking, history)⁠. Ride history and receipts brought the passenger side to three screens, halfway to the six staff workflows and still open for deeper testing.
  • Candidates: post-ride ratings and lost property, membership, subscriptions and coupons, or corporate rides.

Next up: build log

  • Continue deeper passenger-facing taxi coverage at the round-number milestone with ratings and lost property, or membership and coupons.

The run

TicketStub was correctly left unused. Mature component guidance must support both correct adoption and correct rejection.

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