Files

Edwin van den Houdt 88442b0616 feat(gates): WP-02 — harden check:tokens to whole-app colour guard

- Move the guard to scripts/check-tokens.sh; regex now catches hex +
  rgb()/hsl() (was hex-only) across ALL src/app components (was three
  ui/layout dirs). `token-ok` marker suppresses justified false positives;
  px stays out of scope (documented in the script).
- Zero exclusions: debug-state's dark code-editor palette moves to
  --app-devpanel-* tokens in styles.scss (the one exempt file), dropping its
  --exclude hole.
- Tokenize remaining hits: site-footer border via color-mix; three brief
  border widths via --rhc-border-width-* (new --rhc-border-width-lg: 3px).

Verified: planted violation fails the guard; GREEN + test-storybook:ci.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-07-02 19:32:51 +02:00

2.8 KiB

Raw Blame History

WP-02 — Harden `check:tokens` + fix what it then catches

Status: done (pending commit) Phase: 0 — enforcement & gates

Why

The token guard (check:tokens in package.json) only greps for hex colors and only scans registratie/ui, shared/ui, shared/layout. It misses rgb()/hsl() values and skips brief/, auth/, herregistratie/, showcase/ entirely. The guard must cover the whole app before the CIBG work (WP-10…13) leans on it.

Read first

package.json (check:tokens script)
src/styles.scss (the token bridge — the vocabulary fixes must come from)
CLAUDE.md theming section

Decisions (pre-made, don't relitigate)

Raw px values are not grepped (too many false positives); border-width fixes are done manually in this WP and the script documents why px is out of scope.
A /* token-ok */ inline marker suppresses a justified false positive (e.g. rgb in a comment or data-URI) — each use needs a reason in the comment.

Files

package.json → move logic to scripts/check-tokens.sh (new), keep the npm script name
src/app/shared/layout/site-footer/site-footer.component.ts — rgb(255 255 255 / 0.25)
src/app/shared/ui/debug-state/debug-state.component.ts — raw rgba/hex; tokenize and drop its exclusion (it's dev-only chrome but the rule should have no holes)
src/app/brief/ui/letter-block/letter-block.component.ts — raw 3px border
src/app/brief/ui/letter-preview/letter-preview.component.ts — raw 1px border
src/app/brief/ui/passage-picker/passage-picker.component.ts — raw 1px border

Steps

Create scripts/check-tokens.sh; package.json check:tokens calls it.
Extend the regex to #[0-9a-fA-F]{3,8}\b|rgba?\(|hsla?\( (skip lines containing token-ok).
Extend the scanned set to all src/app/**/*.component.ts.
Run it; fix every hit using tokens from the src/styles.scss bridge (add a bridge token only if no existing one fits — keep the vocabulary small).
Fix the raw border widths in the three brief components (--rhc-border-width-*), even though px isn't grepped.
Plant a violation, confirm the script fails, remove it.

Acceptance criteria

Script scans all contexts and matches hex + rgb()/hsl().
Zero exclusions; any token-ok marker has a reason. (No token-ok markers were needed.)
site-footer, debug-state, and the three brief components are tokenized.
A planted violation provably fails npm run check:tokens.

Verification

GREEN + npm run test-storybook:ci.

Out of scope

Grepping px/rem values; scss files (styles.scss is the one place palette values are allowed — it IS the bridge).

Risks

Regex false positives in strings/URLs — that's what the token-ok marker is for; keep its bar high.

2.8 KiB Raw Blame History

WP-02 — Harden check:tokens + fix what it then catches

Why