A third fixed frame exposed one defect across seven templates

⁠Build log series⁠: I hand a real screen to an AI that has never seen Gunjo (@gunjo/ui) and let it build. The fourth complex-screen round covered ⁠a chat interface⁠.

For chat, I again withheld the source and supplied only the package users install and the docs they can read. The /chat assignment included a message list with sender, avatar, time, and user/assistant distinction; an input that sends on Enter; a simulated typing state and reply; and an empty state.

Result: 4.5/5. Tied for the series high

npm run build passed, the page rendered statically, and the console stayed clear.

⁠The chat components were the real thing.⁠

• ChatMessage changes its presentation by assistant, user, or system role and includes an avatar, time, typing cursor, and standard actions. It accepts a preformatted time string instead of formatting a Date internally, which ⁠avoids server/browser hydration mismatches⁠.
• ChatInput supports controlled state and ⁠Japanese input methods (IME)⁠. Enter used to confirm a composition does not send the message, Shift+Enter inserts a line break, and isProcessing changes the action into a stop button.
• The Chat docs are among the few whose ⁠code examples appear in machine-fetched content⁠, avoiding issue #50.
• The default copy is Japanese, and tooltips provide their own provider, confirming issue #52 again.

The rough edge: a third fixed frame revealed a shared cause

ChatTemplate had the same fixed frame again: w-[1280px] h-[720px] h-screen w-full overflow-hidden. It was the third case after AuthTemplate in issue #55 and KanbanTemplate in issue #60. That was enough to warrant an audit of every pattern template.

Fixed frame remains: Bannalyze, Chat, Dashboard, Editor, Landing, MediaLibrary, Settings (7)
Already clear: Auth (issue #55), Kanban (issue #60), Blog, Docs, Onboarding, Pricing

⁠Seven templates still had it.⁠ I had fixed Auth and Kanban one by one, but the same root cause connected them, just as the tooltip failures in #3 eventually became the shared issue #52. The third occurrence turned suspicion into evidence of a library-wide class. I logged issue #66 to fix all seven together, and the shared responsive-sizing fix landed in PR#67.

Other findings:

• ⁠Components with no route to users:⁠ AIChatInput and AIChatMessage existed under src but were not exported from the entry point. PR#67 also added their public exports.
• Badge has no success variant, despite status displays calling for one. Only four variants exist.

What I took away: repeated instances reveal the shared class

1. Issue #55 fixed the Auth frame.
2. Issue #60 found the same frame in Kanban.
3. Chat became the third case, so I audited the templates.
4. Seven remaining instances became one class of fix in issue #66.

This followed the same path as issue #52 and its 28 tooltip consumers. ⁠Fixing isolated examples can hide their common cause. Complex screens supply the third and fourth cases that turn a hunch into a class of defect.⁠ That is why I keep testing until it stops turning up anything new. Once the evidence showed a shared problem, I recorded it that way and moved to fix the class.

Next up: build log #13

• ⁠A multi-step onboarding wizard using OnboardingFlow and Stepper⁠, another complex screen.

The run

• ⁠gunjo.jp⁠ / npm @gunjo/ui / ⁠GitHub⁠
• Earlier rounds: #1 through #11
• 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.