Agent verification

Agent entry point

1. Read /llms.txt for the rules and page index, or /llms-full.txt for the contract and all page content.
2. Read /agent-contract.json for rule IDs, token names, registry components, exports and CVA axes. Inherited Base UI props and per-export variants still come from the component source.
3. Search the existing component catalogue before making a primitive. Read that component's Markdown and registry source.
4. Install through the existing shadcn registry. In MCP-capable clients use the standard shadcn MCP server with this application's components.json registry entry. There is no custom NAMCHE MCP server or OAuth setup.
5. Compose a recipe, wire application callbacks, then verify.

Local commands

pnpm registry:build
pnpm agent:check
pnpm ui:check
pnpm ui:check ../my-app/src/features
pnpm lint
pnpm types:check
pnpm build --webpack
pnpm docs:check

registry:build regenerates registry files, the agent contract and foundations. agent:check tests the checker's negative/positive fixtures, checks generated artifact freshness, validates local docs links and checks core dependency boundaries. ui:check scans the checked-in recipes by default; explicit paths scan downstream TS/JS source. It exits nonzero for diagnostics and prints file, line and canonical rule ID. Run it from this checkout against your app, or copy the script plus its generated contract and installed TypeScript. An empty scan is an error. docs:check runs after the build and inspects prerendered HTML and Markdown endpoints, navigation and the recipe preview; it does not start a server or make visual assertions.

The scanner catches known source patterns: unknown registry imports and CVA values, asChild, copied native control primitives, missing explicit names, unknown CSS variables, hardcoded colour and common arbitrary spacing/type values, live status regions nested inside explicit aria-busy containers, theme utilities, text tinting, line tinting, elevation and editorial palette usage outside chart/illustration modules. Mark occurrences require surface review rather than being silently accepted. Each diagnostic links by ID to the canonical rules in the contract.

Scope and limits

The default strict scan covers recipes, not the entire legacy component tree. The installed token revision and existing primitives still require the upstream follow-up described in Tokens. A successful command is not a claim that the current published package meets the revised visual contract.

The live-region check follows explicit JSX ancestry and treats dynamic busy values as potentially busy; it cannot trace ancestors across component boundaries or spreads.

Static checking cannot prove accessible names passed through spreads, dynamic class construction, computed CSS colours, whether a custom component truly duplicates another, or the count of marks across a composed page. CSS files and MDX prose are outside ui:check's TS/JS scan. It conservatively flags some valid compositions; use an accessible explicit form or inspect the diagnostic, not an unexplained blanket suppression. TypeScript checks actual component props. Application linting and tests remain required.

Runtime acceptance

In a browser-enabled environment, verify each loading, empty, error, success and refetch state at narrow and wide viewports. Keyboard-test trigger, Tab, Shift+Tab, Escape, submit, retry and focus restoration. Check dialog names, input errors and status announcements with an accessibility tree. Check full ink text, consistent line colour with distinct weights, one identity mark per surface, and ink primary actions against the component examples. Capture screenshots with fonts loaded and animations settled for visual comparison.

A browser accessibility runner such as @axe-core/playwright plus Playwright would automate part of this acceptance pass; neither is added by this change. Automated accessibility results still need keyboard and visual coverage.