Base components were battle-tested; NotificationCenter was not
/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
Base components were battle-tested; NotificationCenter was not
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 center and activity feed.
For the fifteenth screen, the agent again received the shipped package and docs, not the source. The /notifications assignment included notifications by type (mention, comment, reaction, and system), avatars, relative times, read and unread states with a badge, Mark all as read, time-based groups, an empty state, and skeletons.
I entered this round with one hypothesis: the base components had stopped producing new classes of rough edges. After repeated fixes, perhaps the low-level layer had become mature.
Result: 3/5. Tied for the series low
tsc and next build passed. The console stayed clear, with no hydration mismatch and no overflow at 375px.
The hypothesis held. The cold agent's report captured it:
The low-level components,
Timeline,Avatar,Badge,EmptyState,Skeleton, andCard, are clearly stable. Composing them produced no new component bugs.
Timeline uses an <ol> and <li> structure, with notification-type icons in the marker slot. Avatar falls back cleanly. The base components also avoid the server/browser trap around relative times. This layer was ready for production use.
Why the score was still low: the problems moved upward and into setup
The new classes clustered in two areas, just as expected.
1. A third name overpromised. NotificationCenter sounds like an activity center, but it is a header-bell dropdown. Its thin { id, title, description, timestamp, read } type has no notification type, avatar, or actor, so a feed row cannot represent its content without stuffing everything into the title. I logged issue #85. This matched OnboardingFlow in #13 and PricingTemplate in #14.
2. Built-in accessibility failed for a third time. Notification rows used <div onClick>, making them unavailable from the keyboard and invisible as actions to screen readers. This followed CommandDialog in issue #57 and RadioGroup in issue #71. I logged issue #83.
3. A new class appeared: setup friction. @import "@gunjo/ui/styles" caused a 500 response on every route in the Turbopack development server. The production build passed, so the failure existed only during development. The installation docs recommended that CSS import without a warning. I logged issue #84. A correct component does not help if the first npm run dev fails.
What I fixed this round
- Issue #83, accessibility: I turned each row into a real
<button>with Enter and Space activation and a focus ring. I removed the nested read button and cleaned up duplicate width declarations. The fix shipped in PR #86, and a real-browser check confirmed that each row was a focusable button. - Issue #84, setup: I added a Turbopack warning to the installation docs and recommended importing the styles from JavaScript. The same PR shipped the guidance.
- Issue #85, the overpromising name: I grouped it with the issues from #13 and #14 for the beta gate. The data type and component responsibility need to be made explicit together.
What I took away: maturity arrives one layer at a time
Base components: no provider crash since #5, then zero new bugs in #15. Mature.
Named higher-level components: overpromised in #13, #14, and #15. Not mature.
Installation and package hygiene: issue #79 and issue #84. New work remains.
Accessibility: issue #57, issue #71, and issue #83. The class still recurs.
Running the series until it stops turning up anything new does not produce one library-wide finish line. The low-level layer had reached it. The remaining work had moved to data-driven higher-level components and clean package installation. Fifteen real screens made it possible to say which layer was mature and which was not. The low score remained the honest one.
Next up: build log #16
- I will focus on higher-level components and setup through editor, error, and search-results screens.
The run
- gunjo.jp / npm
@gunjo/ui/ GitHub - Earlier rounds: #1 through #14
- 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.