A login screen confirmed the shared tooltip fix and rejected AuthTemplate

⁠Build log series⁠: I hand a real screen to an AI that has never seen Gunjo (@gunjo/ui) and let it build. After #1, settings through #4, a dashboard, this round covered ⁠login and sign-up⁠, a common screen with high search demand.

I changed one condition. ⁠This time, I handed over the package exactly as it would ship, including the fixes I had just finished.⁠ Round three exposed the shared defect tracked in issue #52: about 28 components used Tooltip without a provider and crashed during server-side rendering (SSR). This package contained the fix. Everything else remained the same: ⁠the package and docs only, with no source access⁠. I deliberately did not hint that the page should be wrapped in TooltipProvider.

The assignment

Build a centered authentication card. Tabs switch between Sign in and Create account. The form includes email, password with a visibility toggle, Remember me, live password requirements on sign-up, and inline validation.

Result: 4.5/5. The series high, and the defect was gone

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

The most important line in the cold agent's report was this:

⁠No provider or wrapper required.⁠ It works in an ordinary client page. ⁠No server-side rendering crash.⁠

Rounds two through four all failed unless the agent hand-rolled a <TooltipProvider> wrapper. ⁠Once I fixed issue #52, round five passed without one.⁠ The next test independently proved that the shared bug was gone. That is the series' feedback loop: ⁠find a defect, fix it, and verify its absence in the next round.⁠ The scores improve out in the open.

The rest of the library carried plenty of the work too. Form, FormGroup, FormLabel, and FormMessage provided the structure. PasswordInput includes a visibility toggle, while PasswordRequirementList renders live requirements. Standard aria-invalid handling completed ⁠the typed set an authentication form needs⁠.

The remaining half point and a pattern to rebuild

The agent still found honest rough edges:

• ⁠The docs' code examples remained absent from fetched content.⁠ Issue issue #50 was not deployed, though bundled TypeScript types gave users a fallback.
• Tabs defaults to rounded-lg border, and TabsContent adds p-4. Embedded in a card, those defaults create a double border and double padding, so the agent used border-0 p-0. Button defaults to w-fit, requiring w-full for a full-width action. These are minor, but the docs do not mention them.
• ⁠The existing AuthTemplate pattern was fixed at w-[1280px] h-[720px]⁠ and did not respond to the viewport. The cold agent skipped it and ⁠hand-rolled⁠ the centered card instead. I logged issue #55; the responsive fix later landed in PR#59.

That last finding mattered most. ⁠Gunjo has an authentication pattern, but its fixed frame made it unusable here.⁠ It is direct evidence for the work already underway: rebuilding patterns by asking a cold agent to use them. The hand-rolled login from this round is the candidate to polish into the responsive authentication pattern that should ship.

What I took away

Have the AI use it | Find the rough edges | Fix every source consistently (SSOT) | Run it again and verify the fix

Round five ⁠closed the first full loop⁠. The fix for issue #52 came back on the next screen as a provider-free build and a 4.5 score. The same screen also supplied the next assignment, the fixed-frame pattern in issue #55. Fix, test again, and keep the record honest. ⁠That visible movement toward a finished library is what I wanted to show while Gunjo was still in early alpha at the time.⁠

Next up: build log #6

• ⁠A data table with filters using Table, Select, Pagination, and Badge⁠, a staple of admin screens.

The run

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