Pagination looked finished but was only inert markup

⁠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 ⁠search-results page⁠.

I again withheld the source and supplied only the shipped package and docs. The /search assignment called for a search bar and result count, filters (category checkboxes, a type Combobox, and tags), chips for active filters, sorting, result cards, pagination, and loading, results, and empty states.

Result: 4/5, the highest score in several rounds

tsc and build passed, the page was statically generated at build time, the console stayed clear, the server and browser output matched with no hydration errors, and nothing overflowed at 375px. The cold agent reported:

⁠The base components produced no new bugs.⁠ Combobox (combobox, listbox, and option roles), Checkbox (role and aria-checked), and SearchInput all followed their types and had the correct ARIA attributes. ⁠That layer remains stable.⁠

The full set of search filters composed cleanly, and the score rose with it.

Why it stopped at 4: finished-looking components that were only markup

⁠The names did not overpromise this time.⁠ They matched what the components claimed to be. The problem was different: ⁠base elements were shipping with the appearance of finished components while leaving their behavior unimplemented.⁠

⁠1. Pagination did not work at all, the fifth accessibility failure.⁠ PaginationLink rendered ⁠an <a> without an href⁠, so it could not receive focus or work from the keyboard. Previous, next, and every page number were mouse-only. There was no page or onPageChange API either, leaving consumers to calculate the visible range and ellipsis. ⁠It looked like a component but was only presentational markup.⁠ I logged issue #93.

⁠2. Badge had no remove action.⁠ A filter chip with its own close button is one of the component's main jobs, but consumers had to nest a custom close button inside it. I logged issue #95.

⁠3. The clear button in SearchInput used tabIndex={-1},⁠ so keyboard users could not reach it. I logged issue #94.

What I fixed: all three in the same session

• ⁠Issue #93, Pagination:⁠ I made the rendered element follow the use case. With an href, it remains <a href> for SEO and server rendering. Without one, it becomes a real ⁠<button>⁠ that works from the keyboard. I verified in a real browser that the docs example with an href still rendered a link.
• ⁠Issue #95, Badge:⁠ I added onRemove and a built-in close button, so it can serve directly as a filter chip.
• ⁠Issue #94, SearchInput:⁠ I removed tabIndex={-1} from the clear button and added a focus ring.

All three fixes enabled or created ⁠real <button> elements⁠, making the controls keyboard-operable. They shipped in ⁠PR #96⁠. The run left design:verify green with zero exclusions.

What I took away: the boundary around maturity became more precise

Base components: mature, with no new bugs in #15, #16, or #17
Middle layer: unfinished assembly, with components that look complete but leave behavior and wiring to the consumer
Accessibility: still producing distinct failures (issues #57, #71, #83, #87, and #93)

Through #16, the higher-level problem was an overpromising name. Round #17 exposed a different rough edge: ⁠the name was accurate, but the implementation stopped at presentational markup.⁠ ⁠Each round was making the unfinished work more specific.⁠ Everything here could be corrected inside the library and shipped immediately, which meant ⁠I had reached the point where fixable defects could be closed in full.⁠ The 4/5 was a series high, but the rough edges still belonged in the record.

Next up: build log #18

• ⁠An error page, profile, or notification settings⁠, focusing on how complete the middle-layer compositions are.

The run

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