The catalog sent a review form to a rating component that cannot move
/taxi-supportCaptured 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 catalog sent a review form to a rating component that cannot move
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. At the round #150 milestone, this fourth deeper passenger-facing taxi round covered post-ride ratings, lost property, and support: star input, FAQs, lost-item inquiries, and inquiry history.
Result: 3.5/5. The frame and FAQ worked, but rating input was missing
The screen passed tsc and fit a 375px mobile-first layout. The agent reported:
The frame and lists were strong.
PageHeader,BottomActionBar,ListCard,SearchableAccordion, andFilterChipswere excellent and clearly mobile-oriented. But the leading interaction, entering a rating, landed on a real gap.Ratingis display-only, and the catalog points input to that inert component. For a post-ride review app, that is critical.
The core observation: the catalog pointed to an inert component
A star rating invites Rating, but the agent found:
Ratingis a display-onlyrole=imgwith noonChangeand no focusable stars. The screen needed to set a rating, so I hand-rolled a starradiogroupwith focusable buttons, hover preview, arrow keys, an accessible label per star, and targets at least 44px tall. Worse, the catalog sends "star rating" and "review input" to the display-only component. A new developer wiresonChange, sees nothing happen, and only then reads the source. That is not merely a gap but an actively wrong answer. Thelabelprop makesRatinglook even more interactive than it is.
I opened issue #406 for RatingInput, the interactive twin of Rating, with focusable stars, onValueChange, hover, half-stars, and accessible labels. PR#407 now states that Rating is display-only and directs input to a star radiogroup. I also noted InquiryStatus because the consumer states "received," "in progress," and "answered" had been forced into staff-oriented ApprovalSteps.
What I took away: a false answer is more dangerous than no answer
The series had already found missing components, false leads, shallow cross-industry abstractions, and dishonest types. Rating represented the most dangerous form of false lead:
- If a component is simply missing and the catalog says so, the adopter hand-rolls it, as happened before
BottomActionBar. - If a component looks interactive but is not, and the catalog recommends it for input, the adopter believes the wiring succeeded and gets stuck on silent behavior. Detection comes much later.
This resembles the dishonest type in #145. Types, names, and guidance imply that something works, but runtime behavior disagrees. An agent that trusts the library reveals the problem. The remedy has two parts: explicitly mark display-only components as not input, and provide the interactive twin. Display and input are separate components: Rating and RatingInput, Meter and Slider, ExpiryBadge and DatePicker. The catalog must preserve that boundary.
What it flagged
- ✅
SearchableAccordionfit the FAQ perfectly, combining search, categories, grouped questions and answers, and an empty state. - 🟡 The agent reused
ToggleGroupfor multi-select positive-feedback chips, a use the catalog did not mention.
Nothing new was added under src this round. The 3.5/5 corrected the rating guidance and logged RatingInput and InquiryStatus.
📊 Component scoreboard (15 built)
Earlier components plus PageHeader / Itinerary / TicketStub / Stringline / StatusBoard / ExpiryBadge / BottomActionBar In progress: RatingInput and InquiryStatus, SectionList, DateTimePicker and PlaceField, ApproachCard, and StatusLevel at two of three.
📋 Passenger-facing taxi progress
- 🚕 Taxi: six staff / four passenger screens (ride hailing, booking, history, support), two away from symmetry
- Candidates: membership, subscriptions and coupons, or corporate rides
Next up: build log #151
- Continue passenger taxi with membership and coupons or corporate rides, moving toward six staff and six passenger screens.
The run
- gunjo.jp / Rating / SearchableAccordion / npm
@gunjo/ui/ GitHub / previous rounds #1 through #149 - GunjoUI by UIXHERO
The catalog recommended a component that looked interactive but could not move. Every display component needs a clearly documented boundary, and sometimes an input twin.
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.