Only the docs kept notification settings from a 5/5
/settings/notificationsCaptured 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
Only the docs kept notification settings from a 5/5
Build log series: I hand a real screen to an AI that has never seen Gunjo (
@gunjo/ui) and let it build. This round covered a notification-preferences screen.
As in every round, I exposed only the shipped package and docs, not the source. The /settings/notifications assignment called for channel-level controls (Email, Push, SMS, and In-app) plus individual toggles, a RadioGroup for notification level, a Select for digest frequency, a TimePicker for quiet hours, Save and Discard actions, and an unsaved-changes indicator.
This round tested recent component fixes against a real job: RadioGroup accessibility from issue #71 and the Accordion width fix from issue #78.
Result: 4.5/5, with no new class of problem for a second straight round
tsc and build passed, the page was statically generated at build time, the console stayed clear, the server and browser output matched with no hydration errors, and nothing overflowed at 375px. The cold agent concluded:
No new class of problem in the code. It is almost clean. From the component side, this reads as finished. The docs are the only thing keeping it from 5/5.
For the second round in a row, no new class of problem appeared. The chain of critical failures had stopped.
What the screen confirmed: the accessibility fixes held up
-
RadioGroup: one tab stop for theradiogroup, then Arrow Down changed both selection and focus. The roving tabindex from issue #71 worked correctly in a real browser. -
Accordion: it followed the available width at 360px with no overflow. Removing the fixed width in issue #78 worked. -
Switch: Space toggled it, disabling the parent propagated to all five children, and no event fired twice. -
TimePicker: controlled state traveled in both directions, and turning off quiet hours disabled every select.
A defect fixed in one round was genuinely absent in the next. The series was entering the back half of its goal: run until nothing new turns up.
What remained: minor defects, with the docs blocking 5/5
1. Slider used a fixed w-[200px], leaving it cramped in a full-width form. I logged issue #100, another member of the fixed-width family that had to be corrected from the .pen source.
2. An unset TimePicker displayed 00:00, making an empty value indistinguishable from midnight. I logged issue #101 and changed it to show a placeholder.
3. RadioGroupItem carried duplicate classes, with bg-transparent in both its checked and unchecked states. I logged issue #102 and moved the class to the shared layer.
I fixed the second and third issues in the source and shipped them in PR #103. The first required a .pen change.
The only factor that kept the score below 5/5 was the Select documentation. The cold agent incorrectly assumed that Select was a Radix composition using onValueChange and SelectItem. It is actually a native <select> with <option> children. The repository's documentation was correct, but client-side rendering left its code example stuck on "Loading..." because of issue #50. The agent could not read a real example and guessed from the prop names instead. Deploying the docs would remove that failure.
What I took away: one step short of finished
#3: critical failure
#13 through #16: structural problems
#17: incomplete assembly
#18: polish
#19: docs only
The remaining problem was no longer the components. For the second straight round, a cold agent said that it had not struggled with the components themselves, only with their docs. That was strong evidence that the component layer had stopped producing new classes of failure. The code was not holding back the 5/5; undeployed documentation was.
To be precise, I still needed a few more rounds with no new class of problem before calling the component layer finished. But the direction was no longer in doubt.
Next up: build log #20
- An error page or an empty dashboard. If the streak continues, I will confirm that the component layer has stopped producing new classes of failure.
The run
- gunjo.jp / npm
@gunjo/ui/ GitHub - Earlier rounds: #1 through #18
- Overview: Gunjo (
@gunjo/ui) / Why it exists: Design systems in the age of AI - GunjoUI by UIXHERO
Gunjo was still in early alpha at the time; issues are welcome.
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.