A Kanban board showed Gunjo was not battle-tested yet

⁠Build log series⁠: I hand a real screen to an AI that has never seen Gunjo (@gunjo/ui) and let it build. After a first pass through the main components in #1 through #8, I moved into ⁠complex interactions⁠. Round nine: a ⁠drag-and-drop Kanban board⁠.

After #8, I almost wrote that the rough edges were running out. ⁠That was premature.⁠ The classes of bug were beginning to converge, but ⁠the range of screens I had tested was still much too narrow⁠. I had not tried a single interaction-heavy screen. New failures could be waiting there, so I resumed with complex interfaces.

Again, the agent saw only the shipped package and its docs, never the source. The assignment was a /board screen with To Do, In Progress, and Done columns, cards with priority badges and assignee avatars, and ⁠drag and drop across columns⁠.

Result: 4/5. A new class of problem appeared

npm run build passed and the page rendered statically. Drag and drop worked in a real browser, and moving a card updated the counts in both columns.

Gunjo handled the cards cleanly. Card uses forwardRef and passes its props through, so the agent attached dnd-kit listeners directly. Badge covered priority, and Avatar covered assignees. Its tooltip prop now provides its own provider, another confirmation that issue #52 remained fixed. The agent found no visual friction.

The complex screen still surfaced rough edges that simpler screens had missed.

1. Gunjo has no drag-and-drop component

The @gunjo/ui entry point contains no Sortable, Draggable, or Droppable. The cold agent ⁠brought in dnd-kit itself⁠. Leaving drag and drop to dnd-kit can be a valid design-system decision, and many libraries do exactly that. But the rest of Gunjo's Kanban story made the omission harder to defend.

2. KanbanTemplate was a broken fixed-size frame, the same class as issue #55

Gunjo ⁠had⁠ a KanbanTemplate, but it consisted of w-[1280px] h-[720px] h-screen w-full overflow-hidden. The later classes canceled the fixed pixels, then forced the template to fill the entire screen and hide overflow, fighting any surrounding page layout. It provides no columns, cards, states, or drag-and-drop behavior. ⁠This was the same fixed-frame problem as AuthTemplate in #5.⁠ The cold agent skipped it and hand-rolled the board. I logged issue #60, and the responsive, layout-only template fix landed in PR#61.

3. Kanban returns a 404 on the docs site

There was no Kanban entry on gunjo.jp/patterns, and /patterns/kanban returned 404. Only the type declarations revealed that it existed. The name promised a Kanban pattern, but the implementation and docs did not deliver one.

For completeness, the agent's dnd-kit integration produced a server/browser mismatch in the aria-describedby ID during server-side rendering. That behavior came from ⁠dnd-kit⁠, not Gunjo. It still strengthens the case for shipping an SSR-safe board pattern from Gunjo.

What I took away: wait for complex screens before calling a library mature

My conclusion after #8 came from ⁠one result and too narrow a sample⁠. Round nine found both ⁠a known class returning, the fixed frame from issue #55⁠, and ⁠a new cluster around the Kanban name: no drag-and-drop behavior, a broken template, and a 404 in the docs⁠.

1. The bug categories begin to converge.
2. The tested surface is still thin: drag and drop, files, calendars, wizards, and chat remain untested.
3. Keep running complex screens before calling the categories exhausted.

The right beta threshold is ⁠several consecutive rounds without a new class of defect⁠. Round nine produced a new cluster, so Gunjo was not there yet. ⁠My own test corrected my premature conclusion.⁠

Next up: build log #10

• ⁠File upload using Dropzone, FileUploader, and Progress⁠, another complex interaction.

The run

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