CommandPalette worked from one prop, then flagged its own accessibility

⁠Build log series⁠: I hand a real screen to an AI that has never seen Gunjo (@gunjo/ui) and let it build. After #1 through #6, a data table, this round covered the familiar power-user pattern: a ⁠Command-K palette⁠.

The conditions stayed the same: the package exactly as shipped and the docs, with no source access or hints about wrappers such as TooltipProvider. The assignment covered a palette opened with Command-K or Ctrl-K, input filtering, grouped commands (Navigation, Actions, and Settings), icons, shortcut labels, keyboard navigation with the arrow keys and Enter, dismissal after selection, and a confirmation toast.

Result: 4.5/5. Tied for the series high

npm run build passed, and the page rendered statically. The console stayed clear on load. Opening with Command-K, filtering by typing, moving through results with the arrow keys, running one with Enter, and closing with Escape all worked.

The cold agent found more than the low-level Command component. It also discovered the high-level ⁠CommandPalette, which works from data alone⁠.

A ⁠single typed groups prop⁠ provides the search field, grouped commands, icons, shortcut labels, keyboard navigation, and closing behavior for Escape.

The earlier provider fix held too:

⁠No provider required for the palette.⁠ It handles the popup and focus management itself. It opened cleanly during server-side rendering without a <TooltipProvider> wrapper.

The agent only had to pass an array of { id, label, icon, shortcut, action }. That is a strong API.

The rough edge: an accessibility library warned about its own dialog

The warning appeared during development but did not stop the build.

Warning: Missing `Description` or `aria-describedby={undefined}` for {DialogContent}.

CommandDialog included a visually hidden Title for screen readers, but ⁠it omitted the corresponding Description and aria-describedby⁠ in Command.tsx:59. The warning appeared only in development, yet it was hard to excuse. A library that promises built-in accessibility was emitting its own accessibility warning. Screen readers had no dialog description to announce. I logged issue #57, and the accessibility fix landed in PR#59.

That finding was uncomfortable, but it is exactly what the cold test is for. ⁠A claim such as built-in accessibility must survive an actual run. The test shows where reality falls short.⁠ No embellishment and no hiding the warning.

Other findings:

• ⁠The docs' code examples still did not appear in machine-fetched content⁠, the known issue #50.
• Command, CommandPalette, and Table contain duplicate classes such as w-[Npx] w-full. The later class wins, so they are harmless, but the pattern needs cleanup across components.

What I took away

Have the AI use it | Find where a claim fails | Fix it | Run it again

Round seven found ⁠a gap between the promise of built-in accessibility and the implementation⁠. CommandPalette was excellent and earned 4.5/5, while the same dialog retained an accessibility warning. ⁠One screen showed both what worked and where the claim was not yet true.⁠ Both belong in the record.

Next up: build log #8, then a pause

• ⁠Empty, loading, and toast states using EmptyState, Skeleton, and Toast.⁠ Everyone needs these states, but few people want to build them. This will complete the first pass through the main categories.

The run

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