A day-old bottom action bar found its next booking screen on its own
/taxi-bookingCaptured 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 day-old bottom action bar found its next booking screen on its own
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 deeper passenger-facing taxi round followed ride hailing with advance booking and flat-rate airport service: scheduled pickups, Haneda and Narita flat fares, and private sightseeing hire. Passenger coverage remained thin beside six staff screens, so it continued.
First, a correction: one passenger screen did not finish taxi
After #147, the AI helping with implementation and drafting reported taxi complete. My immediate reaction was that one passenger screen could not balance six staff screens. Rail and air each had six passenger screens, and the working note explicitly said to deepen the weaker passenger side instead of closing it early. Passenger coverage only becomes complete when it has comparable depth, so I continued.
Result: 4.5/5. The booking foundation worked as-is
The five-step flow passed tsc and fit a 375px mobile-first layout. The agent reported:
This library is unusually well suited to Japanese consumer transactions. The app bar, stepper, priced selection cards, fare breakdown, fixed primary action, list rows, and confirmation all worked with little adaptation. The Japanese vocabulary in the docstrings made the intended market clear.
The core observation: yesterday's BottomActionBar was independently found
I had built BottomActionBar one day earlier in #147. Here another agent found it for the booking action:
BottomActionBarwas built for this.childrenheld the ride summary and estimated total,actionsheld the primary button, and the docstring explicitly named booking.maxWidth="md"centered it on the content column. No friction.
A component was built and independently discovered on the very next screen, joining TicketStub from #128 to #129 and ExpiryBadge from #142 to #144 among the fastest transfers. The booking use case written into the docstring in #147 led directly to this screen. Specific use cases in a docstring invite future discovery.
What it flagged: date plus flexibility and paired place inputs
Scheduling was partly hand-rolled.
DatePickerhandled the date, whileTimePickerused two accessible but desktop-like selects. No component represented a flexibility window such as plus or minus 10 or 20 minutes, so the agent usedToggleGroup. Nothing combined date, time, and flexibility into one pickup time. The highest-value addition is a future-constrainedDateTimePickerwith a flexibility window, the heart of every booking app. Pickup and drop-off fields, including the paired green circle and red square, were also hand-rolled.
I opened issue #403 for a DateTimePicker with future date, time, and flexibility, plus PlaceField or RouteInput for paired pickup and drop-off locations with a swap control. Booking, dining, lodging, inspections, and delivery appointments all share these patterns. The missing success variant on StatusScreen from issue #379 also returned when the agent reused an error-oriented full-screen component for booking confirmation.
Nothing new was added under src this round. The 4.5/5 brought independent discovery for BottomActionBar and logged DateTimePicker and PlaceField.
What I took away: a docstring is a letter to the next adopter
When I built BottomActionBar, its docstring named payments, ride hailing, booking, and food ordering. The word booking led this agent to it one day later. Writing concrete places where a component belongs is a message to future agents and human users arriving without context. Cross-industry discovery is not pure chance; specific usage language makes it possible. That is why Gunjo docstrings name industries and scenarios.
📊 Component scoreboard (15 built)
Earlier components plus PageHeader / Itinerary / TicketStub / Stringline / StatusBoard / ExpiryBadge / BottomActionBar In progress: DateTimePicker and PlaceField, ApproachCard, a success variant on StatusScreen, StatusLevel at two of three, and Leaderboard or CaseTable.
📋 Passenger-facing taxi progress
- 🚕 Taxi: six staff / two passenger screens (ride hailing and advance booking). The newly validated booking flow raised the passenger side to two screens, still well short of the six staff workflows.
- Candidates: ride history and receipts, post-ride ratings and lost property, membership, subscriptions and coupons, or corporate rides.
Next up: build log #149
- Continue deeper passenger-facing taxi coverage with ride history and receipts, or membership and coupons. I'll choose before the next round.
The run
- gunjo.jp / BottomActionBar / RadioCard / DatePicker / npm
@gunjo/ui/ GitHub / previous rounds #1 through #147 - GunjoUI by UIXHERO
The bottom bar built yesterday was independently found by today's booking screen. A concrete docstring is a letter to the next adopter, and one passenger screen was never enough to finish taxi.
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.