OnboardingFlow missed the one job its name promised
/onboardingCaptured 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
OnboardingFlow missed the one job its name promised
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 multi-step onboarding wizard.
I kept the agent on the public surface: the shipped package and docs, without the repository source. The /onboarding assignment had five steps: Welcome, profile, settings, team invitations, and completion. It needed progress, Back and Next actions, a disabled Next action until each step was valid, and a final summary.
Result: 3.5/5
tsc passed cleanly, next build passed with static rendering, and clicking through the flow produced zero console errors and no hydration mismatch. The supporting pieces were strong, but the component meant to own the wizard missed its core job.
What worked:
OnboardingTemplategives the hero and content a responsive two-column layout.- The form components compose cleanly.
FormMessageuses the error color by default, whileSelectis a native<select>with semantics and keyboard behavior built in. SwitchandRadioGroupsupport both controlled and uncontrolled state. All TypeScript types, includingStepperStepandOnboardingStep, are exported from the entry point.
The rough edges: the dedicated component missed the core, and accessibility failed again
1. OnboardingFlow could not block Next when input was invalid. This is central to onboarding, yet the component exposed no nextDisabled, canAdvance, or equivalent. Next always advanced. The agent abandoned OnboardingFlow midway and replaced it with Stepper plus hand-rolled navigation. A component named for onboarding lacked one capability every onboarding flow needs. I logged issue #70.
2. RadioGroup did not work from the keyboard. It had role="radio", but no role="radiogroup", arrow-key behavior, or roving tabindex. It did not function as a radio group. This was the second failure of the built-in accessibility claim after issue #57 on CommandDialog. I logged issue #71.
3. Alert was fixed at w-[320px]. Even inside a 462px card, it remained a narrow 320px box. It belonged to the fixed-width family from issues #47, #58, and #66, so I logged issue #72. Other findings included fixed-width Stepper items that overflow narrow screens (issue #73) and a missing docs page for OnboardingTemplate, leaving no import example or working composition (issue #74).
What I fixed this round: browser evidence for accessibility
I shipped the two most important fixes during the same round in PR #75:
- Issue #70: I added
OnboardingStep.nextDisabledandcanAdvance(index). Invalid input now disables Next or Finish and guards advancement. A tooltip, composed the same way as the Back action, explains why the button is unavailable. - Issue #71: I added
role="radiogroup", selection with the arrow keys, Home, and End, plus roving focus. I verified it in a real browser: ArrowDown moved selection and focus from item one to item two, ArrowUp moved back, and End selected the last item. The console showed no warning or error.
I also fixed the width of Alert from the feedback.pen source in PR #76. Browser measurements confirmed that the alert matched its parent width. All three fixes passed design:verify with no drift-check exclusions.
What I took away: test a dedicated component against its actual job
1. Trust the OnboardingFlow name and build two steps.
2. Discover that it cannot block Next.
3. Rebuild the navigation from Stepper and custom controls.
A name can promise the job, but the missing core does not surface until the component performs that job in a real screen. The built-in accessibility claim also failed for a second time after issue #57. A claim becomes evidence only when each screen tests it. The 3.5 score stayed honest. I fixed what broke and collected browser evidence.
Next up: build log #14
- I will keep testing unused templates and real demand, including editor, pricing, error screens, payments, and notification feeds, until it stops turning up anything new.
The run
- gunjo.jp / npm
@gunjo/ui/ GitHub - Earlier rounds: #1 through #12
- 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.