chore(webkit): adopt the design-system toolkit and report adoption on every PR

[isaque-bock-azion]

Why

The webkit ESLint rules have been configured in this repo since the plugin landed in eslint.config.mjs — and nothing has ever run them. lint:eslint exists and no workflow calls it. So the distance between this codebase and the design system was invisible: not measured, not tracked, only ever noticed in review.

Two commits: wire the toolkit that was missing, then make the adoption a number on every PR.

Baseline this produces

Measured on this branch against @aziontech/webkit@4.4.0:

webkit/* violations	72
Files affected	30
UI files clean	51 of 79 — 65%

Rule	Count
no-style-override	26
authoring-standards	25
no-hardcoded-color	16
no-hardcoded-motion	2
prefer-tree-shakeable-root	2
valid-import-path	1

Most of that number is a design-system backlog, not a docs one. The 26 no-style-override hits spread across 17 different components (Table.Cell, IconButton, NavigationMenu, Button, Kbd, GlobalHeader, Accordion.Content, Sidebar, HeroTitle, DocProse, …) and only frame-box declares a styleSeam in the catalog. Some of those are legitimate layout needs the design system should expose; some are overrides that should be composition. Triage is a follow-up, with this report as the input.

The single valid-import-path hit is a false positive from our own patch: patches/@aziontech__webkit@4.4.0.patch adds ./use-mounted to the package exports, but use-mounted is not in catalog.json, so the rule correctly says it is not a published export. The fix is upstream (publish the composable), not a suppression — the rule takes no allow-list.

What changed

Toolkit wiring (webkit init, keeping what fits an Astro repo)

• .stylelintrc.json — stylelint was installed with no config at all. Added **/*.astro to the postcss-html override; verified it catches a hex inside an Astro <style> block. The repo's real CSS passes clean.
• .mcp.json — registers the webkit MCP so an agent working here resolves components against the installed catalog instead of guessing.
• CLAUDE.md + .claude/{rules,skills,agents} — the shared guidance bundle (20 rules, 18 skills, 5 agents).
• .gitignore — .claude/* with negations for those three folders. The bundle is versioned for the team; local settings, launch configs and worktrees stay ignored exactly as before.
• eslint.config.mjs — a block applying the AST-based webkit rules to **/*.astro. The preset's own FILES list does not include .astro, so 41 files here were outside every webkit rule. Verified with a canary plus a .vue control: identical content reported 3 violations as .vue and zero as .astro. That block found 3 real hardcoded colours that were hidden. no-style-override is deliberately excluded — it needs vue-eslint-parser's template visitor, which astro-eslint-parser does not provide.

Adoption report

• scripts/webkit-adoption-report.mjs — aggregates the ESLint JSON into the tables above. Markdown to stdout, progress to stderr, so it redirects cleanly into the Summary. Same "clean files" score shape the console-kit architecture report uses.
• It states its own blind spots (no-style-override on .astro; raw HTML where a webkit component exists is caught by no rule at all) and checks the catalog resolves — without that check, the plugin silently disables 8 of its 12 rules and "clean" would be indistinguishable from "blind".
• pnpm lint:webkit, pnpm report:webkit-adoption, pnpm lint:style.
• CI step is if: always() + continue-on-error: true — runs even if a step above fails, never turns the check red.

CI trigger

pr-checks.yml now also runs on PRs to release/new-azion-docs. That branch is where the new-docs work lands today and it had no CI at all — not build, not frontmatter, not title. This PR is the first one to get it.

What was deliberately dropped from webkit init

Dropped	Why
The dependency additions	tailwindcss would land in devDependencies at ^4.0.0 while dependencies already pins ^4.3.3 — init only checks the target field. @tailwindcss/postcss does not apply: this repo runs Tailwind through @tailwindcss/vite.
scripts.prepare: "husky" + .husky/pre-commit	The generated hook runs eslint . on every commit; with 72 known violations that blocks all work. Local hooks come after the first cleanup pass. It also breaks pnpm install --frozen-lockfile until the lockfile is regenerated.
src/webkit.css	This repo already registers webkit in src/styles/main.css:3. A second entry would load Tailwind and the theme twice.

webkit init left eslint.config.mjs and postcss.config.js untouched, as designed, and printed the merge snippets instead. The lockfile and every @aziontech/* version are unchanged — deliberately, since pnpm-workspace.yaml pins the patch to @aziontech/webkit@4.4.0 in two places.

Two findings for the design system

Both give a false reading on any Astro project, and neither is fixed here:

1. webkit doctor reports webkit.css @source as FAIL because the check hardcodes src/webkit.css. This repo registers webkit correctly in src/styles/main.css. After a plain init the check would go green while the generated src/webkit.css sits unused — so it is wrong in both directions.
2. doctor's source scan omits .astro, the same gap as the ESLint preset's FILES.

Verification

• pnpm build:local — green, 1628 pages, frontmatter test passes
• pnpm lint:navcheck — green (39 pre-existing warnings)
• pnpm lint:style — clean; canary confirms the rules fire, including inside .astro
• pnpm lint:webkit && pnpm report:webkit-adoption — reproduces the numbers above
• webkit doctor — 3 fail / 2 warn / 4 ok → 1 fail / 2 warn / 6 ok (the remaining fail is finding 1 above; the warns are the intentionally skipped husky)
• git diff pnpm-lock.yaml — empty

Not in scope

Making this gate blocking. The flip is a ratchet on changed files — legacy frozen in a baseline, CI failing only when a PR introduces new UI outside the design system. That needs the baseline first, and this PR is what produces it.