Round #31Score 4/5Retail / e-commerce

The toast I expected to be missing turned out to be the strongest part

Route: /product
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

The toast I expected to be missing turned out to be the strongest part

⁠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 an ⁠ecommerce product detail page⁠ (image gallery, variant picker, quantity, add-to-cart feedback, tabs, reviews, related products, and a sticky buy bar).

The conditions were the usual ones: the shipped npm package plus the docs site, with the source kept private. Ecommerce was a completely new class of screen, untouched in rounds through .

Result: 4/5

tsc and build passed, the console stayed at zero, the server and browser output matched with no hydration mismatch, the page had a single h1, and I verified both 375px and desktop.

My prediction missed: the toast I doubted was the star

I figured the add-to-cart feedback would need a ⁠toast notification⁠, and braced for the agent to hand-roll one if the design system had no toast machinery. The opposite happened. The agent's verdict:

⁠The toast is complete out of the box, accessibility included.⁠ ToastProvider plus useToast() gives showToast(msg, "success"). Verified in a real browser: it announces through role="status" (errors use role="alert"), portals to the body, and dismisses itself. The add-to-cart requirement cost zero friction.

On top of that, ⁠the Img fixes from issue #113⁠ (aspectRatio, objectFit, skeleton, and a fallback for broken images, called "the standout"), ⁠Badge as (issue #128), CardTitle as (issue #116), Breadcrumb's items API, and the Radix Tabs⁠ were singled out again as strengths that were built in from the start. ⁠The compounding loop turned again this round.⁠

The new gaps converged on retail-specific components

What cost the point was the absence of product-page components:

  • Issue #168: no Rating or star display.⁠ The biggest gap. Product header, each review, and every related-product card: ⁠six hand-rolls on a single screen⁠. "The one gap that hits every screen of any shop." It goes to Codex as a new display component (it needs .pen nodes, the design-source format).
  • Issue #169: no horizontal quantity stepper⁠ (NumberInput renders only a vertical spin box). Fixed by adding layout="stepper".
  • Issue #171: dark mode is a .dark class only and ignores the OS setting⁠ (no prefers-color-scheme, no ThemeProvider), so the agent hand-wrote the bridge.
  • Smaller points: ToggleGroup deselects on a second click (issue #170), and there is no SwatchGroup (issue #172) or Gallery (issue #173).

What I fixed this round: components plus the next coordination component

Three changes were safe to make in source (PR #174):

  • ThemeProvider + useTheme + ThemeToggle (issue #171), this round's ⁠coordination component⁠: light/dark/system, follows the OS setting, persists to localStorage, toggles .dark, and ships a ThemeScript to prevent the flash on first paint. ⁠Like the form system in , it is a seed planted for a later round to verify.⁠
  • ⁠NumberInput layout="stepper" (issue #169), rendering - [n] + in a row. The default look is byte-identical, zero drift.
  • ⁠ToggleGroup disallowEmpty (issue #170), so a segmented control keeps its selection.

Rating, SwatchGroup, and Gallery need .pen nodes, so they go to the Codex batch.

What I took away: even a wrong guess about what's missing is a measurement

Expected: no toast machinery, so a hand-roll was coming. Actual: it existed and drew the loudest praise.
As expected: the retail-specific components (Rating and friends) are missing.
And: the next coordination component (ThemeProvider) is now planted.

⁠The part I feared was strong, and the weakness sat where I never looked: following the OS dark setting.⁠ The value of handing screens to an AI with no prior knowledge is exactly this. It probes beyond my own assumptions.

Next up: build log

  • ⁠An error screen, search filters, a dashboard⁠, or similar. Whether the next agent verifies ThemeProvider.

The run

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.

業界別「AI指示書パック」、先行登録を受付中です。