remarque-tokens 0.23.0 → 0.25.0

package/AGENT_RULES.md

@@ -188,7 +188,7 @@ Three further archetypes — Reference/Docs, Changelog, Gallery — are specifie
 
 2. **Prose alignment:** The essay header and prose body must BOTH use centered max-width (`max-w-reading mx-auto`) to prevent misalignment. The `.content-reading` class auto-centers; match headers with `mx-auto`.
 
-3. **Dark mode specificity:** Define `[data-theme="light"]` and `[data-theme="dark"]` overrides in addition to the `:root` defaults. Without an explicit light override, users with `prefers-color-scheme: dark` cannot toggle to light mode.
+3. **Dark mode specificity:** Define `[data-theme="light"]` and `[data-theme="dark"]` overrides in addition to the `:root` defaults. Without an explicit light override, users with `prefers-color-scheme: dark` cannot toggle to light mode. Since 0.24.0 (`light-dark()` + `color-scheme`, REMARQUE.md "Color Scheme & light-dark()"), the shipped default palette's own `[data-theme="light"]` override is just `color-scheme: light` — a consumer palette that still authors the older two-declaration convention needs the fuller override this rule originally describes.
 
 4. **Self-hosted fonts:** Replace the Google Fonts CDN link with self-hosted woff2 files + `@font-face` declarations. Use `font-display: swap` and `<link rel="preload">` for performance.
 
@@ -323,6 +323,30 @@ the documented DTCG divergences.
 
 ---
 
+## Installing the Skills
+
+This package ships two Claude Code skills under the npm subpath exports
+`remarque-tokens/skills/remarque` and `remarque-tokens/skills/adopt`
+(resolving to `skills/remarque/SKILL.md` and `skills/remarque-adopt/
+SKILL.md` in the installed package). Claude Code only discovers skills
+from a project's own `.claude/skills/` (or `~/.claude/skills/`), never
+from `node_modules` — copy them in explicitly, one `cp` per skill:
+
+```bash
+mkdir -p .claude/skills
+cp -r node_modules/remarque-tokens/skills/remarque .claude/skills/remarque
+cp -r node_modules/remarque-tokens/skills/remarque-adopt .claude/skills/remarque-adopt
+```
+
+The copies are versioned with the installed package, not auto-updating —
+re-copy both after a MAJOR bump, or any time this file's
+"Machine-Readable Output" shape changes.
+
+- `remarque` — the build/review contract for pages on the current version (tier rules, archetypes, pitfalls #6/#7).
+- `remarque-adopt` — the version-bump/migration playbook (this file's "Machine-Readable Output" section is its main dependency): verify the resolved version past the 0.x caret freeze, discover newly-required tokens from `remarque-audit --json`, solve missing values against the consumer's own backgrounds, classify `remarque-drift --json` output, report against a fixed PR-body contract.
+
+---
+
 ## How to Reference This System
 
 In prompts, issues, or agent instructions, use:

package/CHANGELOG.md

@@ -4,6 +4,41 @@ All notable changes to `remarque-tokens` are documented here. Token value
 changes always state the design rationale — downstream sites pin against
 these entries when syncing.
 
+## 0.25.0 — 2026-07-23
+
+`remarque-adopt` skill + skills npm export (closes #107) — ratified 3-0 (skill-suite vote, 2026-07-23), the anchor item of the skill suite. Codifies the consumer-conformance playbook run five times in one day as hand-written agent briefs (williamzujkowski.github.io#381, tsundoku#243/#237, remarque-starter#7/#8) into a procedural, machine-gated skill.
+
+### Added
+
+- **`.claude/skills/remarque-adopt/SKILL.md`** — a new Claude Code skill, distinct from the existing `remarque` loader skill: triggers on "bump remarque-tokens" / "upgrade the design system" / "adopt remarque in an existing site" / an audit failing after a version bump, not on ordinary page work. Five steps, each ending in a machine gate: (1) bump the pin and verify the *resolved* version, not the range typed — 0.x caret ranges never cross a minor below 1.0, the exact trap that froze remarque-starter at 0.10.x through 0.18.0; (2) discover newly-required tokens mechanically from `remarque-audit --json`'s `failures`, never by reading the CHANGELOG and guessing; (3) add missing tokens solved against *the consumer's own* `--color-bg`/`--color-surface`/`--color-code-bg` (keep-if-passing against the package default; the tsundoku#243 hue-collision case — the default viz "red" landing on top of that site's terracotta accent and its own `--color-error` — is the worked example for checking hue collisions as a distinct failure mode from contrast); (4) run `remarque-drift --json` and classify FAIL (undocumented core-tier override, fix it) / WARN (documented in `DESIGN-DEVIATIONS.md`/`DESIGN-NOTES.md`, ratified) / INFO (palette-tier personalization, expected); (5) a fixed PR-body contract (what changed, token decisions table, drift summary, gate results, anything explicitly declined). Acceptance throughout is pinned to `passed: true` in the JSON output, never agent judgment.
+- **Both skills now ship in the npm tarball.** `.claude/skills/{remarque,remarque-adopt}/SKILL.md` remain the ONE canonical, hand-authored copies (also what a Claude Code session working in this repo reads directly); `scripts/build-skills.mjs` copies them byte-for-byte into `skills/remarque/SKILL.md` and `skills/remarque-adopt/SKILL.md` for packaging — the same single-source-plus-generated-copy relationship `tokens.json` already has to the CSS tiers, kept fresh the same way (`--check` gates CI freshness; a `prepack` script hook runs the plain copy automatically on every `npm pack`/`npm publish`, so a stale packaged copy can't ship even if someone forgets to re-run the script by hand). New exports: `remarque-tokens/skills/remarque` and `remarque-tokens/skills/adopt`. `package.json`'s `files` gains `skills/`, `scripts/build-skills.mjs`, and `scripts/lib/skills.mjs`.
+- **README + AGENT_RULES.md: "Installing the skills"** — Claude Code only discovers skills from a project's own `.claude/skills/` (or `~/.claude/skills/`), never `node_modules`, so installing the npm package alone does nothing for a consumer's Claude Code session. Both docs now give the exact `cp -r node_modules/remarque-tokens/skills/<name> .claude/skills/<name>` pair and note the copies are versioned with the installed package, not auto-updating — re-copy on a MAJOR bump.
+- **`scripts/test-skills.mjs`** (enforce-not-instruct applied to the skills themselves, panel condition) — asserts, per skill: frontmatter parses with a non-empty `name`/`description`; every CLI flag referenced alongside a `remarque-audit`/`remarque-drift`/`remarque-theme` command line is grepped straight out of `scripts/audit.mjs`/`scripts/drift-check.mjs`/`scripts/theme.mjs`'s own arg parsing (not hand-maintained separately, so a renamed flag fails this test instead of shipping a stale doc); every backticked package-relative file path referenced (`*.md`/`*.mjs`/`*.js`/`*.json`/`*.css`, excluding consumer-side conventions like `DESIGN-DEVIATIONS.md`/`DESIGN-NOTES.md` and `node_modules`/subpath-export forms) resolves to a real file in this repo; the packaged `skills/<name>/SKILL.md` copy is byte-identical to the canonical file. Wired into `deploy.yml` alongside `scripts/build-skills.mjs --check`.
+- **`scripts/test-pack.mjs` extended** — the real npm-tarball smoke test now also asserts (via `tar -tzf`) that `package/skills/remarque/SKILL.md` and `package/skills/remarque-adopt/SKILL.md` land in the packed tarball, and that both resolve inside the scratch consumer's `node_modules/remarque-tokens/skills/` after a real `npm install` — proving the `prepack` hook actually fires during a real pack/publish, not just that the files exist in the working tree.
+- Version-only regeneration of `tokens.json`/`tokens.d.ts`/`tokens.schema.json` and `registry.json`/`registry/*.json` (no token or registry content changes this release).
+
+## 0.24.0 — 2026-07-23
+
+`light-dark()` + `color-scheme` palette migration (closes #95) and a `:has()` zero-JS forms enhancement layer (closes #97) — the ratified program's last two items.
+
+### Browser support floor — raised (stated prominently per the new Governance & Deprecation "browser-floor" minor case)
+
+`light-dark()` and `color-scheme` are baseline-stable but not ancient: this release raises remarque-tokens' minimum supported browser engine to **Chrome/Edge 123+, Firefox 120+, Safari 17.5+**. This is a **MINOR**, not a major — no token is removed or renamed, every consumer's `var(--color-x)`/`tokens.json` lookup keeps resolving exactly as before, and `tokens.json`/`tokens.d.ts`/`tokens.schema.json` are byte-identical to 0.23.0 (verified this release, version field aside). Only the rendering environment required to resolve the new CSS *correctly* changes. A site whose audience needs an older engine should stay on `<0.24.0`, or override the affected `--color-*` tokens with plain `oklch()` values (the audit accepts either authoring form). See REMARQUE.md's new "Color Scheme & light-dark()" section and its updated "Semver contract".
+
+### Added / Changed
+
+- **`tokens-palette.css`: every `--color-*` token is now a single `light-dark(<light>, <dark>)` declaration** under `:root { color-scheme: light dark; }`, replacing the old convention of a full `:root` block plus a full, separately-maintained `@media (prefers-color-scheme: dark)` block re-listing every value a second time. System-preference default needs no color-specific rule at all now; `[data-theme="light"]`/`[data-theme="dark"]` become single `color-scheme` overrides instead of re-declaring every token's dark value; the `:root.dark` compatibility bridge (ratified sunset: 1.0, unchanged) carries the same minimal `color-scheme: dark` override. Values are unchanged — this is purely an authoring-form migration, golden-gated ΔE2000 = 0.000/0.000 against the previous values on every affected token (see `scripts/palette-golden.mjs` output).
+- **`--weight-display` stays on the pre-migration mechanism, on purpose.** `light-dark()` is restricted to `<color>` values; `--weight-display` is a `font-weight` (400/500, dark-mode serif-hairline compensation, issue #59), so it cannot be expressed as `light-dark(400, 500)`. It keeps `@media (prefers-color-scheme: dark)` + `[data-theme="dark"], :root.dark` — now carrying only this one token instead of the whole palette. A registered-custom-property `light-dark()`-abuse workaround was considered and rejected: the conventional blocks are simpler, already audited, and now touch exactly one token — there's no problem left to solve by working around them.
+- **`prefers-contrast: more` (issue #93) simplifies from three blocks to one.** Pre-migration this needed a plain `:root` override, a `[data-theme="dark"], :root.dark` override, and a compound `@media (prefers-contrast: more) and (prefers-color-scheme: dark)` override. Under `light-dark()`, one un-scoped `light-dark(<light>, <dark>)` override per token replaces its whole value at once and re-resolves per element from whatever `color-scheme` is already active there (system, explicit, or the bridge) — there is no dark-specific selector left to write.
+- **The demo site's `[data-theme="light"]` mirror block is retired**, not merely updated. It used to hand-carry all 21 `--color-*` values from the package's light `:root` so a dark-OS visitor could still toggle back to light (AGENT_RULES Pitfall #3) — a known drift trap (`scripts/palette-golden.mjs`'s "site mirror" check). Explicit light selection is now a bare `color-scheme: light` override shipped IN the package itself; the color values live in exactly one place (the `light-dark()` declaration), so there is no second copy to drift. `site/src/styles/globals.css`'s block shrinks to `[data-theme="light"] { color-scheme: light; }`. `scripts/palette-golden.mjs`'s mirror check now asserts the *absence* of any `--color-*` redeclaration there, rather than comparing two copies of a value that no longer has a second copy.
+- **Parser (`scripts/lib/css-tokens.mjs`): three new exports** — `splitLightDark(value)` (depth-aware split of a `light-dark(a, b)` value into its light/dark sides — a side that is itself `oklch(...)` or `var(...)` doesn't confuse the single top-level comma being looked for), `resolveSide(decls, side)` (collapses a flat decls map to one theme side; a no-op for any value that isn't a `light-dark()` call, which is what keeps every conventional-form palette parsing identically to before), and `darkOverridesOf(rawLightRootDecls, rawDarkBlockDecls)` (merges `light-dark()` dark sides from the top-level `:root` block with whatever a conventional dark block still declares — mixed-form palettes are supported, with the conventional block winning on conflict, matching real CSS cascade order). `scripts/audit.mjs`, `scripts/palette-golden.mjs`, `scripts/drift-check.mjs`, and `scripts/tokens-json.mjs` all route through these; none changed their own contrast/golden/drift logic, only how they extract light/dark values first. **This arguably simplifies the parser long-term**, as the issue predicted: both values now come from one declaration instead of being scattered across two selectors.
+- **Fixture coverage (`scripts/test-audit.mjs`):** a pure `light-dark()` palette fixture, a mixed-form palette fixture (half the tokens migrated, half still in the two-block convention, in the same file), and a must-fail fixture where a `light-dark()` value's DARK side (only) fails contrast — proving the parser actually extracts and enforces both sides of a `light-dark()` declaration, not just the light side. Every pre-existing conventional-form fixture (attribute, class, media, palette-deck, nested/compound-media-not-dark, …) stays green, unmodified.
+- **`scripts/theme.mjs` (the `remarque-theme` bridge) is deliberately unchanged** — still emits the conventional two-block form. Its output is a palette override a consumer imports after this package's own tokens; keeping it on the older, universally-parseable convention is the lower-churn choice (every consumer regardless of remarque-tokens version can consume it, and the parser above already treats both forms identically). Modernizing the bridge's own emission to `light-dark()` is deferred to a later major.
+- **`forms.css`: `:has()` zero-JS validation enhancement layer (issue #97).** A second progressive-enhancement layer over the existing `@supports selector(:user-invalid)` bonus border-recolor — `:user-invalid` alone can only style the input it matches (CSS has no "parent selector" without `:has()`), so it cannot reach the field's label. `.remarque-field:has(.remarque-input:user-invalid) .remarque-field-label` extends the error recolor to the label; `.remarque-field:has(.remarque-input:focus-visible) .remarque-field-label` brightens the label to `--color-fg` as a quiet secondary focus cue (not a replacement for the control's own native `:focus-visible` outline). Both guarded with `@supports selector(:has(...))`, same fallback shape as `:user-invalid` itself. `data-state` remains the canonical contract; neither block replaces authoring `data-state="error"` explicitly.
+- **Registry regenerated** (`registry/forms.json`) — `forms.css`'s content changed (the new `:has()` blocks), single-sourced verbatim as always; no markup-contract change, so `usage.html` and the mechanical contract checks are untouched.
+- **REMARQUE.md:** new "Color Scheme & light-dark()" section (under "Token Tiers") — the full mechanism, the browser-floor bump, the weight-display/mirror/bridge/parser decisions, and the `prefers-contrast` simplification. "Technology Stack" theming bullet, "DTCG Conformance", "Forced Colors & Contrast Preferences", "Governance & Deprecation" (semver contract's new browser-floor minor case; the `:root.dark` deprecation-table row's rationale), and "Forms" ("State wiring") all updated to match.
+- Version-only regeneration of `tokens.json`/`tokens.d.ts` (no token name/value changes — verified byte-identical aside from the version field).
+
 ## 0.23.0 — 2026-07-23
 
 Machine-readable markup-contract registry (closes #100) — the ratified program's flagship item. Funded on the panel's amended rationale: it mechanically prevents the markup-contract transcription bug class (the sidenote DOM-order/aria-label failure found in the flagship migration, #89), not on "category-defining" positioning.

package/README.md

@@ -69,10 +69,32 @@ The agent rules define build order, non-negotiable rules, disallowed patterns, a
 
 Packaging for agent tooling:
 - **npm exports:** `remarque-tokens/agent-rules` (→ `AGENT_RULES.md`) and `remarque-tokens/spec` (→ `REMARQUE.md`), alongside the existing `remarque-tokens/tokens.json`, so a project can point an agent at `node_modules/remarque-tokens/AGENT_RULES.md` without hardcoding a filename.
-- **Claude Code skill:** [`.claude/skills/remarque/SKILL.md`](.claude/skills/remarque/SKILL.md) — triggers on "remarque" / "design system" / new-page work, loads all three files, and states the tier rules, the audit command, and the two build-time pitfalls (unlayered-token-import, string-form `@import`) that pass a green build while silently breaking.
+- **Claude Code skills (two):**
+  - [`.claude/skills/remarque/SKILL.md`](.claude/skills/remarque/SKILL.md) — triggers on "remarque" / "design system" / new-page work, loads all three files, and states the tier rules, the audit command, and the two build-time pitfalls (unlayered-token-import, string-form `@import`) that pass a green build while silently breaking.
+  - [`.claude/skills/remarque-adopt/SKILL.md`](.claude/skills/remarque-adopt/SKILL.md) — triggers on "bump remarque-tokens" / "upgrade the design system" / "adopt remarque in an existing site" / an audit that starts failing after a version bump. The consumer-conformance playbook (issue #107): verify the resolved version past the 0.x caret freeze, discover newly-required tokens from `remarque-audit --json` mechanically, solve missing values against the *consumer's own* backgrounds (keep-if-passing), classify `remarque-drift --json` output (FAIL/WARN/INFO), and report against a fixed PR-body contract. Every step ends in a machine gate — `passed: true`, not agent judgment.
+
+  Both ship in the npm tarball under `skills/` (see "Installing the skills" below) as well as living at `.claude/skills/` in this repo.
 - **Live tokens endpoint:** the demo site serves the current `tokens.json` at **https://williamzujkowski.github.io/remarque/tokens.json**, and its schema at **https://williamzujkowski.github.io/remarque/tokens.schema.json** — a remote agent can fetch current token values (and validate their shape) directly instead of trusting training data.
 - **Markup-contract registry:** a shadcn-`registry-item.json`-shaped, version-pinned, hash-verified registry of known-good markup for the Essay/Broadsheet/Forms/Palette Deck modules — **https://williamzujkowski.github.io/remarque/registry.json** (index) and **https://williamzujkowski.github.io/remarque/registry/essay.json** (per item; also `broadsheet`/`forms`/`palette-deck`). Fetch and apply the markup instead of transcribing it from spec prose — see REMARQUE.md's "The Registry" and AGENT_RULES.md's "Prefer the Registry Over Transcribing Prose."
 
+### Installing the skills
+
+`npm install remarque-tokens` does not put anything into your project's
+`.claude/skills/` automatically — Claude Code only reads skills from
+there (or from `~/.claude/skills/`), never from `node_modules`. Copy them
+in explicitly, one `cp` per skill:
+
+```bash
+mkdir -p .claude/skills
+cp -r node_modules/remarque-tokens/skills/remarque .claude/skills/remarque
+cp -r node_modules/remarque-tokens/skills/remarque-adopt .claude/skills/remarque-adopt
+```
+
+The copies are versioned with whatever `remarque-tokens` version is
+installed at copy time, not auto-updating — re-run both `cp` commands
+after any MAJOR bump (and any time `AGENT_RULES.md`'s "Machine-Readable
+Output" shape changes) to pick up the current playbook.
+
 ## Files
 
 | File | Purpose |
@@ -89,6 +111,7 @@ Packaging for agent tooling:
 | `tokens.schema.json` | Generated JSON Schema (draft 2020-12) for `tokens.json`, published alongside it |
 | `registry.json` + `registry/` | Generated markup-contract registry index + per-item files for essay/broadsheet/forms/palette-deck (`scripts/build-registry.mjs`) — see REMARQUE.md "The Registry" |
 | `registry-item.schema.json` + `registry.schema.json` | Generated JSON Schemas (draft 2020-12) for the per-item and index registry files |
+| `skills/remarque/SKILL.md` + `skills/remarque-adopt/SKILL.md` | Generated packaging copies of the two Claude Code skills (`scripts/build-skills.mjs`) — canonical source is `.claude/skills/*/SKILL.md`; see "Installing the skills" above |
 | `fonts.css` + `fonts/` | Self-hosted @font-face declarations and woff2 files (no CDN requests) |
 | `tailwind.config.js` | Tailwind CSS **v3** configuration (v4 projects use an `@theme` block instead) |
 | `package.json` | npm package manifest for `remarque-tokens` |

package/REMARQUE.md

@@ -43,7 +43,7 @@ Remarque projects should feel like a modern technical publication — not a gene
 - **CSS framework:** Tailwind CSS — v4 via the shipped `remarque-tokens/theme.css` (`@theme inline` adapter; utilities reference the runtime tokens), or v3 via the shipped `tailwind.config.js`. One mechanism per project, never both.
 - **Component primitives:** shadcn/ui (when reusable components are needed)
 - **Markup:** Semantic HTML with ARIA landmarks
-- **Theming:** Light and dark mode via the `[data-theme]` attribute (canonical; system preference + manual toggle). `:root.dark` is supported as a compatibility bridge for class-keyed sites (sunset: 1.0) — the audit parses both. Mind the specificity asymmetry: `[data-theme=\"dark\"]` is (0,1,0), `:root.dark` is (0,2,0). Platform endgame to watch: `color-scheme` + `light-dark()`
+- **Theming:** Light and dark mode via `color-scheme` + `light-dark()` (issue #95, 0.24.0) — every `--color-*` token is one `light-dark(<light>, <dark>)` declaration under `:root { color-scheme: light dark; }`; system preference resolves automatically, the `[data-theme]` attribute (canonical) overrides `color-scheme` explicitly, and `:root.dark` is a compatibility bridge for class-keyed sites (sunset: 1.0) carrying the same override. **Raises the package's minimum browser floor** to Chrome/Edge 123+, Firefox 120+, Safari 17.5+ — see "Color Scheme & light-dark()". The audit parses both the new single-declaration form and the older two-declaration convention (mixed within one file, too). Mind the specificity asymmetry on the one remaining non-color theme-conditional token (`--weight-display`): `[data-theme=\"dark\"]` is (0,1,0), `:root.dark` is (0,2,0).
 - **Accessibility:** USWDS-informed. Keyboard navigation, skip-to-content link, ARIA labels, WCAG AA contrast compliance, 44px touch targets, 14px minimum small text
 - **Tokens:** Centralized CSS custom properties in two tiers — `tokens-core.css` (immutable identity) + `tokens-palette.css` (sanctioned personalization). `tokens.css` aggregates both. See "Token Tiers"
 - **Fonts:** Self-hosted woff2 (no CDN dependency). Preloaded via `<link rel="preload">`
@@ -68,6 +68,31 @@ Package subpaths for consumers: `remarque-tokens` (aggregator), `remarque-tokens
 
 This makes compliance mechanical: a site that overrides only palette-tier tokens is *authored*; one that touches core-tier tokens has *forked*. `tokens.css` imports both tiers, so existing consumers are unaffected.
 
+### Color Scheme & `light-dark()`
+
+**0.24.0, closes #95.** Every `--color-*` token in `tokens-palette.css` is now authored as a single `light-dark(<light>, <dark>)` declaration under `:root { color-scheme: light dark; }`, replacing the previous convention of a full `:root` block plus a full, separately-maintained `@media (prefers-color-scheme: dark)` block re-listing every value a second time. This is the platform mechanism earlier releases of this file named as "the endgame to watch" — now adopted.
+
+**Browser support floor — raised, stated prominently per "Governance & Deprecation":** `light-dark()` and `color-scheme` are baseline-stable but not ancient: **Chrome/Edge 123+, Firefox 120+, Safari 17.5+**. A site whose audience needs to support an older engine should stay on remarque-tokens `<0.24.0`, or override the affected `--color-*` tokens with plain `oklch()` values in its own palette (the audit accepts either form — see "How the parser handles this" below). This is the MINOR-with-rationale case the Governance section's semver contract now names explicitly: no token was removed or renamed, and every consumer's `var(--color-x)` still resolves — only the minimum browser engine that renders it *correctly* moved forward, which is why this ships as a minor rather than a major.
+
+**How theme selection now works:**
+- **System preference (no explicit choice).** `color-scheme: light dark` on `:root` is sufficient by itself — every `light-dark()` call resolves from `prefers-color-scheme` directly. No `@media (prefers-color-scheme: dark)` color block is needed anymore; it and its full duplicated value list are **retired**.
+- **Explicit user choice.** `[data-theme="light"]`/`[data-theme="dark"]` now override `color-scheme` itself, once — not every token's dark value a second time. `[data-theme="dark"] { color-scheme: dark; }` / `[data-theme="light"] { color-scheme: light; }`.
+- **`:root.dark` compatibility bridge.** Unchanged status — still bridges class-keyed consumer sites, still sunsets at 1.0 (see the Deprecation windows table). It carries the same `color-scheme: dark` override as `[data-theme="dark"]`, kept **minimal** by design: colors need nothing else now that they resolve through `color-scheme`.
+
+**`--weight-display` is the one exception — and stays on the old mechanism, on purpose.** `light-dark()` is restricted to `<color>` values; `--weight-display` is a `font-weight` (400/500, dark-mode serif-hairline compensation, issue #59), so it cannot be expressed as `light-dark(400, 500)`. It keeps the pre-migration `@media (prefers-color-scheme: dark)` + `[data-theme="dark"], :root.dark` blocks — now carrying only this one token instead of the whole palette, which is the honest characterization: this isn't a compromise or a leftover, it is genuinely the smallest correct mechanism available for a non-color theme-conditional token. A registered-property `light-dark()`-abuse trick was considered and rejected — the conventional blocks are simpler, already-audited, and touch exactly one token; inventing a workaround to avoid two small blocks would be solving a non-problem.
+
+**The `prefers-contrast: more` override (issue #93) simplifies from three blocks to one.** Pre-migration this needed a plain `:root` override, a `[data-theme="dark"], :root.dark` override, and a compound `@media (prefers-contrast: more) and (prefers-color-scheme: dark)` override — three copies of two tokens, to cover system-default, explicit-dark, and system-dark-without-an-explicit-choice respectively. Under `light-dark()`, one un-scoped `light-dark(<light>, <dark>)` override per token replaces its whole value at once and re-resolves per element from whatever `color-scheme` is already active there — there is no dark-specific selector left to write. See `tokens-palette.css`'s `@media (prefers-contrast: more)` block.
+
+**The site's `[data-theme="light"]` mirror — retired, not merely updated.** Before this migration, an explicit light choice had no mechanism of its own, so the demo site hand-carried a full `[data-theme="light"]` block re-declaring every `--color-*` value (a known drift trap, guarded by `scripts/palette-golden.mjs`'s "site mirror" check). Explicit light selection is now a bare `color-scheme: light` override — the color values live in exactly one place (the `light-dark()` declaration itself) — so there is no second copy left to drift. The mirror block is deleted from `site/src/styles/globals.css`; `scripts/palette-golden.mjs`'s mirror check now asserts the *absence* of any `--color-*` redeclaration there instead of comparing two copies of a value that no longer has a second copy.
+
+**How the parser handles this (`scripts/lib/css-tokens.mjs`).** `splitLightDark(value)` depth-aware-splits a `light-dark(a, b)` value into its light/dark sides (so a side that is itself `oklch(...)` or `var(...)` doesn't confuse the single top-level comma being looked for). `resolveSide(decls, side)` collapses a flat decls map to one theme side — a no-op for any value that isn't a `light-dark()` call, which is what makes this fully backward compatible: a palette using only the old two-block convention parses identically to before. `darkOverridesOf(rawLightRootDecls, rawDarkBlockDecls)` merges the `light-dark()` dark sides found in the top-level `:root` block with whatever a conventional dark block still declares (mixed-form palettes are supported — a consumer may migrate some tokens and leave others in the old convention in the same file), with the conventional-block value winning on conflict — matching real CSS cascade order (a later dark-block declaration overrides an earlier `:root` one at equal specificity). `scripts/audit.mjs`, `scripts/palette-golden.mjs`, `scripts/drift-check.mjs`, and `scripts/tokens-json.mjs` all route through these three functions now; none of them changed their own contrast/golden/drift logic, only how they extract light/dark values first. Fixture-tested in `scripts/test-audit.mjs`: a pure `light-dark()` palette, a mixed-form palette (some tokens migrated, some not), a `light-dark()` value that fails contrast on its dark side, and every pre-existing conventional-form fixture, all green.
+
+**`scripts/theme.mjs` (the `remarque-theme` bridge) is intentionally unchanged — still emits the conventional two-block form.** Its output is a *palette override* a consumer imports after this package's own tokens; keeping it on the older, more universally-parseable convention is the lower-churn choice — every consumer regardless of remarque-tokens version can consume it, and the parser above already treats both forms identically. It is not a compromise either: modernizing the bridge's own emission to `light-dark()` is deferred to a later major, noted here so it isn't silently forgotten.
+
+**`tokens.json` is unaffected in content.** The authoring-form change is purely how the CSS expresses a value, not what the value or token name is — regenerating `tokens.json`/`tokens.d.ts`/`tokens.schema.json` from the migrated CSS produces byte-identical output (aside from the `version` field), verified in this release.
+
+**Visual regression: zero baseline changes.** Every `--color-*` value is unchanged — only the CSS mechanism producing it moved. The Playwright visual-regression suite's screenshot baselines are expected to be pixel-identical; any diff would indicate a transcription error in the migration, not an intended appearance change.
+
 ### DTCG Conformance
 
 `tokens-core.css` and `tokens-palette.css` remain the single source of truth; `scripts/tokens-json.mjs` regenerates `tokens.json`, `tokens.d.ts`, and `tokens.schema.json` from them in one pass (`node scripts/tokens-json.mjs`; `--check` gates CI freshness). `tokens.json` carries a `$schema` pointer to the published schema (served by the demo site at `/tokens.schema.json`, alongside `/tokens.json` — also exported as `remarque-tokens/tokens.schema.json`).
@@ -75,7 +100,7 @@ This makes compliance mechanical: a site that overrides only palette-tier tokens
 `tokens.json` is **conformant in spirit** with the [Design Tokens Community Group (DTCG)](https://www.designtokens.org/) format — every token carries `$value`/`$type` — with two **deliberate** structural divergences, documented in the generated file itself (`$extensions.remarque.dtcg`) so a future regeneration can't lose the rationale:
 
 1. **Color values are `oklch()` CSS strings**, not the DTCG structured color object (`{ colorSpace, components, alpha }`). Remarque's color pipeline (audit, drift-check, `remarque-theme`) is built entirely on parsing/emitting `oklch(L C H)` strings; adopting the structured form would mean carrying two color representations in parallel for no present benefit. **Gated on:** the DTCG color `$type` structured-value format ratifying.
-2. **Palette-tier tokens nest per-token `light`/`dark` groups**, each with its own `$value`, rather than a single `$value` plus a modes/resolver mechanism. The DTCG spec has no ratified multi-mode/theming primitive yet; this repo's own theming (`@media (prefers-color-scheme: dark)`, `[data-theme="dark"]`, the Palette Deck's `[data-palette]` scoping) predates any such draft. **Gated on:** the DTCG multi-mode / resolver draft ratifying.
+2. **Palette-tier tokens nest per-token `light`/`dark` groups**, each with its own `$value`, rather than a single `$value` plus a modes/resolver mechanism. The DTCG spec has no ratified multi-mode/theming primitive yet; this repo's own theming (`light-dark()` + `color-scheme`, `[data-theme="dark"]`, the Palette Deck's `[data-palette]` scoping — see "Color Scheme & light-dark()") predates any such draft. **Gated on:** the DTCG multi-mode / resolver draft ratifying.
 
 Full DTCG conformance is gated on those two drafts ratifying — a named, checkable trigger, not "someday." Until then, do not "fix" `tokens.json` toward either unratified draft; the CSS is the source of truth, and both divergences are load-bearing for the tooling that already depends on this shape.
 
@@ -496,8 +521,9 @@ Issue #93 — Remarque cites [USWDS](https://designsystem.digital.gov/documentat
 
 **`prefers-contrast: more`.** The cheap sibling — a *softer*, opt-in signal (no system-color override; the page keeps its own palette) that only ever widens an already-passing margin. Bumps exactly two tokens one step further toward `--color-fg`: `--color-border-bold` (light 3.39:1 → 4.52:1, dark 3.23:1 → 4.53:1) and `--color-fg-muted` (light 7.55:1 → 10.11:1, dark 7.26:1 → 9.70:1). `--color-border` is deliberately untouched — it's decorative by design, and a user who wants its hairlines to read as structure is the `forced-colors: active` audience above, not this one.
 
-- **Architectural home:** `tokens-palette.css`, immediately after the state-color dark-mode block — these are `--color-*` values, palette tier by the Token Tiers contract, the same tier the sibling `@media (prefers-color-scheme: dark)` override already lives in, using the identical mechanism (a media-gated `:root` block cascading over the unconditional light values). Not `tokens-core.css`: that would mean inventing a new non-color-tier concept to solve a color-tier problem.
-- **Audit-parser compatibility:** `scripts/lib/css-tokens.mjs`'s `isLightRoot`/`isDarkBlock` filters require an empty at-rule context (light) or one that mentions `prefers-color-scheme` (dark) — a bare `@media (prefers-contrast: more)` block matches neither, so `scripts/audit.mjs` and `scripts/tokens-json.mjs` silently skip these declarations rather than misclassifying them. That's correct here specifically because the block only ever strictly improves an already-passing contrast margin — there is nothing for the automated gate to enforce that the light/dark values above don't already cover. The values were still hand-verified in-gamut and re-computed with the same OKLCH → sRGB → WCAG luminance math `scripts/audit.mjs` uses (see the ratios in `tokens-palette.css`'s comment).
+- **Architectural home:** `tokens-palette.css`, immediately after the theme-selection mechanism — these are `--color-*` values, palette tier by the Token Tiers contract, the same tier the base `light-dark()`/`color-scheme` regime already lives in.
+- **Simplified to one block under `light-dark()` (0.24.0, issue #95):** pre-migration this needed a plain `:root` override, a `[data-theme="dark"], :root.dark` override, and a compound `@media (prefers-contrast: more) and (prefers-color-scheme: dark)` override — three copies of two tokens, covering system-default, explicit-dark, and system-dark-without-an-explicit-choice respectively. A single un-scoped `light-dark(<light>, <dark>)` override per token now replaces its whole value at once and re-resolves per element from whatever `color-scheme` is already active there (system, explicit, or the `:root.dark` bridge) — see "Color Scheme & light-dark()".
+- **Audit-parser compatibility:** `scripts/lib/css-tokens.mjs`'s `isLightRoot` filter requires an empty at-rule context — a `@media (prefers-contrast: more)` block's context is that at-rule itself, so it matches neither `isLightRoot` nor `isDarkBlock`, and `scripts/audit.mjs`/`scripts/tokens-json.mjs` silently skip these declarations, unchanged from before the light-dark() migration. That's still correct: the block only ever strictly improves an already-passing contrast margin, so there is nothing for the automated gate to enforce beyond what the base palette already guarantees. The values are still hand-verified in-gamut and re-computed with the same OKLCH → sRGB → WCAG luminance math `scripts/audit.mjs` uses (see the ratios in `tokens-palette.css`'s comment).
 
 **CI gate.** `site/tests/forced-colors.spec.ts` runs Chromium with `page.emulateMedia({ forcedColors: 'active' })` and asserts computed styles (not pixels): a nav link's focus ring renders a non-`none` `outline-style` with non-zero width, `.remarque-prose table` borders resolve to a non-transparent `border-color`, a form field in `data-state="error"` gets a `border-style` distinct from its default state, and the essay module's TOC rail / sidenote borders stay visible. Wired into the existing `visual-regression.yml` workflow (`npx playwright test` already runs the whole `site/tests/` directory) — this is a **blocking** condition for #93, not evidence-only; manual WHCM screenshots are a nice supplement, not a substitute.
 
@@ -1149,6 +1175,22 @@ with an invalid field — it never replaces authoring `data-state="error"`
 explicitly, since `:user-invalid` alone has no matching text-message
 recolor and no `aria-invalid` wiring of its own.
 
+A second `:has()`-powered bonus layer (issue #97) goes one step further:
+`:user-invalid` alone can only style the input it matches — CSS has no
+"parent selector" without `:has()`, so it cannot reach the field's label.
+`.remarque-field:has(.remarque-input:user-invalid) .remarque-field-label`
+recolors the label to `--color-error` too, and
+`.remarque-field:has(.remarque-input:focus-visible) .remarque-field-label`
+brightens the label to `--color-fg` while any control in the field has
+keyboard focus — a quiet secondary cue, not a replacement for the
+control's own native `:focus-visible` outline. Both are guarded with
+`@supports selector(:has(...))` (the same "the browser lacking this
+falls back to `data-state`/`aria-invalid`" shape as `:user-invalid`
+itself) and, like that layer, are bonus visual cues rather than one of
+the canonical `data-state` states — `data-state` stays the one
+contract every consumer must author explicitly; `:has()` never replaces
+it, only adds a zero-JS enhancement on top for browsers that support it.
+
 ### Restraint rules restated
 
 - **Border radius**: form controls cap at `--radius-sm` (4px) — a
@@ -1562,6 +1604,7 @@ Remarque ships as a CSS token system, not an application — "breaking" means so
 - **MAJOR** — a token is **removed** or **renamed**. Anything a consumer's `var(--color-x)` or a `tokens.json` lookup resolves today must keep resolving after a minor or patch bump; only a major bump may take that away.
 - **MINOR** — a token's **value changes**, or a token is **added**. Value changes always carry a stated rationale in the CHANGELOG entry (a contrast fix, a gamut correction, an upstream dataset repin) — the change is minor because the *name* stays stable and every consumer reads it through `var()` indirection, but it is never silent. Additive changes (new tokens, new optional CLI flags, new subpath exports) are minor by definition — nothing existing changes shape.
 - **PATCH** — tool/script fixes with no token or CSS output change (a `remarque-audit` parser bug, a `tokens-json.mjs` generation fix, a fixture correction). If `tokens.json`/`tokens.d.ts`'s content is byte-identical before and after, it's a patch.
+- **MINOR (browser-floor case)** — a change that raises the *minimum supported browser version* by adopting a newer CSS mechanism as load-bearing (0.24.0's `light-dark()`/`color-scheme` migration, issue #95, is the first instance). Still a minor, not a major: no token is removed or renamed, and every consumer's `var(--color-x)`/`tokens.json` lookup keeps resolving — only the rendering environment required to resolve it *correctly* changes. The new floor is stated prominently in both the CHANGELOG entry and the relevant REMARQUE.md section, not buried in prose.
 
 The project is still pre-1.0 — under strict SemVer every 0.x release is technically allowed to break anything — but every release to date has in practice held to the contract above (no token has ever been removed or renamed; see the version history in CHANGELOG.md). 1.0 is the point where that becomes a promise instead of an observed pattern.
 
@@ -1571,7 +1614,7 @@ A token or convention slated for removal is announced in the CHANGELOG at least
 
 | Deprecated / bridged item | Introduced | Sunset target | Rationale |
 |---|---|---|---|
-| `:root.dark` compatibility selector (alongside canonical `[data-theme="dark"]`) | 0.5.0 | 1.0 | Bridges class-keyed consumer sites onto the attribute-keyed convention `remarque-audit` treats as canonical — the audit already parses both forms, so the bridge costs nothing today. Platform endgame to watch instead: `color-scheme` + `light-dark()` (see "Technology Stack"). |
+| `:root.dark` compatibility selector (alongside canonical `[data-theme="dark"]`) | 0.5.0 | 1.0 | Bridges class-keyed consumer sites onto the attribute-keyed convention `remarque-audit` treats as canonical — the audit already parses both forms, so the bridge costs nothing today. `color-scheme` + `light-dark()` — once "the platform endgame to watch" — landed in 0.24.0 (see "Color Scheme & light-dark()"); the bridge itself is unaffected, carrying a `color-scheme: dark` override now instead of a full color list, and its sunset target is unchanged. |
 
 No other open sunset commitments exist as of this writing (grepped against REMARQUE.md and CHANGELOG.md for "sunset"/"deprecated"). This table is meant to be the single place to look — but only if every future commitment is added here, not just announced in passing.
 

package/forms.css

@@ -358,6 +358,54 @@ textarea.remarque-input {
   }
 }
 
+/* ─── `:has()` zero-JS validation enhancement layer (issue #97) ──────────
+ * A second, purely additive progressive-enhancement layer over the
+ * `:user-invalid` layer just above — same native-first shape, one step
+ * further. `:user-invalid` alone can only style the INPUT it matches;
+ * CSS has no "parent selector" without `:has()`, so it has no way to
+ * reach the field's label or wrapper. `:has()` is exactly the piece that
+ * closes that gap: `.remarque-field` can react to a descendant control's
+ * validity/focus state directly, with no `data-state` attribute and no
+ * JavaScript. Guarded with `@supports selector(:has(...))` — the same
+ * "degrades to the no-JS/no-support baseline" shape the `:user-invalid`
+ * block above uses — so a browser missing either pseudo-class in the
+ * compound query falls back cleanly to whatever `data-state`/
+ * `aria-invalid` (and, where supported, the plain `:user-invalid` layer
+ * above) already provide. `data-state` remains the CANONICAL contract;
+ * neither block below replaces authoring `data-state="error"` explicitly
+ * — see REMARQUE.md "State wiring".
+ *
+ * Like the bare `:user-invalid` layer above, this is a bonus visual cue,
+ * not one of the canonical `data-state` states the forced-colors
+ * reinforcement below was scoped to fix (REMARQUE.md "Forced Colors &
+ * Contrast Preferences") — it is not itself a new color-only-affordance
+ * regression, since the real accessible signal (`aria-invalid`, the
+ * `data-state` border/message wiring) is unchanged and unaffected by
+ * whether this bonus layer's color survives forced-colors mode.
+ */
+@supports selector(:has(:user-invalid)) {
+  /* Extends the :user-invalid border recolor (input only, above) up to
+     the field's label — the one thing plain :user-invalid cannot reach
+     on its own. */
+  .remarque-field:has(.remarque-input:user-invalid) .remarque-field-label {
+    color: var(--color-error);
+  }
+}
+
+/* Field-level focus affordance — a quiet secondary cue, NOT a
+   replacement for the control's own native `:focus-visible` outline
+   (tokens-core.css), which already renders on the control itself and is
+   forced-colors-safe by construction. Brightens the label from
+   `--color-muted` to `--color-fg` while any control inside the field has
+   keyboard focus — a restrained color wash, not a new border/background,
+   matching this module's "no component should be visually louder than
+   the content it contains" rule (AGENT_RULES.md Components). */
+@supports selector(:has(:focus-visible)) {
+  .remarque-field:has(.remarque-input:focus-visible) .remarque-field-label {
+    color: var(--color-fg);
+  }
+}
+
 /* ─── Forced-colors reinforcement (issue #93) ────────────────────────────
  * The validation-state wiring above is the textbook color-only-affordance
  * case the issue names explicitly: error/success/warning are distinguished

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "remarque-tokens",
-  "version": "0.23.0",
+  "version": "0.25.0",
   "engines": {
     "node": ">=18"
   },
@@ -29,7 +29,8 @@
   },
   "scripts": {
     "audit": "node scripts/audit.mjs",
-    "drift": "node scripts/drift-check.mjs"
+    "drift": "node scripts/drift-check.mjs",
+    "prepack": "node scripts/build-skills.mjs"
   },
   "devDependencies": {
     "@williamzujkowski/oklch-terminal-themes": "0.5.0",
@@ -84,6 +85,8 @@
     "./registry-item.schema.json": "./registry-item.schema.json",
     "./registry.schema.json": "./registry.schema.json",
     "./registry/*": "./registry/*.json",
+    "./skills/remarque": "./skills/remarque/SKILL.md",
+    "./skills/adopt": "./skills/remarque-adopt/SKILL.md",
     "./package.json": "./package.json"
   },
   "files": [
@@ -117,6 +120,9 @@
     "registry-item.schema.json",
     "registry.schema.json",
     "scripts/build-registry.mjs",
-    "scripts/lib/registry-extract.mjs"
+    "scripts/lib/registry-extract.mjs",
+    "skills/",
+    "scripts/build-skills.mjs",
+    "scripts/lib/skills.mjs"
   ]
 }

package/registry/broadsheet.json

@@ -4,7 +4,7 @@
   "type": "remarque:contract",
   "title": "Broadsheet Pattern",
   "description": "The editorial Landing/archive pattern: masthead, lead article, numbered entry list, and post-header kicker. Entry numerals are generated from `data-entry-number` via `attr()`, never `counter()`, and every kicker/dateline row is true `font-variant-caps: all-small-caps`, never `text-transform: uppercase`.",
-  "version": "0.23.0",
+  "version": "0.25.0",
   "integrity": "sha256-BZea38PRdob4OfmdGN0eDw3U0adl7SEsdrjKgSewK9A=",
   "dependencies": [
     "remarque-tokens"

package/registry/essay.json

@@ -4,7 +4,7 @@
   "type": "remarque:contract",
   "title": "Essay Module",
   "description": "Sidenotes + sticky TOC rail for long-form Essay pages: margin notes relocated into real DOM order, right after the paragraph that cites them, numbered by CSS counter and labeled `aria-label=\"Note N\"` in the same order the counter advances — the mechanism that prevents the sidenote aria-label/DOM-order transcription bug found in the flagship migration (#89, williamzujkowski.github.io#380).",
-  "version": "0.23.0",
+  "version": "0.25.0",
   "integrity": "sha256-zr04H0+0xf01OWLk6B2A9ziZOYJd4Sq5q5/cib65lbU=",
   "dependencies": [
     "remarque-tokens"

package/registry/forms.json

@@ -4,8 +4,8 @@
   "type": "remarque:contract",
   "title": "Forms Primitives",
   "description": "Native field/input/checkbox/radio/button primitives with state-color wiring. Every `.remarque-input` pairs `for`/`id` with its `.remarque-field-label`, and every `.remarque-field-message` is wired via `aria-describedby` on the control — the paint-layer `data-state` attribute is never the only signal; `aria-invalid`/`aria-describedby` on the input carry the real accessibility contract.",
-  "version": "0.23.0",
-  "integrity": "sha256-Ft+jRmZtY6HBdTCFoIIJbM3S/3dx7iSVl7NRWD/40rY=",
+  "version": "0.25.0",
+  "integrity": "sha256-WfYjcf04Dxxx7X21U5b6DrY90Qw95p0zkCQszoh77tE=",
   "dependencies": [
     "remarque-tokens"
   ],
@@ -49,7 +49,7 @@
   "files": [
     {
       "path": "forms.css",
-      "content": "/*\n * Remarque — Form Control Primitives (issue #27)\n * ────────────────────────────────────────────────\n * Namespaced classes that style native form elements — no fake replacement\n * widgets. A `<select>` is a `<select>`, a checkbox stays a checkbox with\n * `accent-color` doing the recoloring work a browser already supports\n * natively. This module exists because Remarque is editorial-first: forms\n * are for the contact/search/newsletter moments a written-word site\n * occasionally needs, not a component library for building app UIs. See\n * \"When NOT to use\" in REMARQUE.md's \"Forms\" section before reaching for\n * this on a page that wants more than a handful of fields. Also carries a\n * small standalone-table section (`.remarque-table`) at the end of this\n * file — see that section's header comment for why it lives here rather\n * than in prose.css (issue #30's reference `Table.astro` needs the same\n * table visual language OUTSIDE `.remarque-prose`).\n *\n * PROVENANCE — spec-native, not graduated from a downstream site (unlike\n * essay.css/broadsheet.css). Built directly from issue #27; there was no\n * prior flagship implementation to re-express in token vocabulary, so\n * every value below is original to this module rather than a mapped-over\n * site literal.\n *\n * Own subpath (remarque-tokens/forms, remarque-tokens/forms.css) — NOT\n * included by the tokens.css aggregator, matching essay.css/broadsheet.css/\n * print.css: most Remarque pages have zero forms. Import explicitly, after\n * prose.css if both are in use:\n *   @import 'remarque-tokens/prose.css';\n *   @import 'remarque-tokens/forms.css';\n * (string form — see AGENT_RULES.md Pitfall #6.)\n *\n * ─── MARKUP CONTRACT (summary — full version in REMARQUE.md) ──────────\n *\n *   <div class=\"remarque-field\">\n *     <label class=\"remarque-field-label\" for=\"email\">Email</label>\n *     <input class=\"remarque-input\" type=\"email\" id=\"email\" name=\"email\"\n *       aria-describedby=\"email-help\" />\n *     <p class=\"remarque-field-message\" id=\"email-help\">\n *       We'll never share your email.\n *     </p>\n *   </div>\n *\n *   <div class=\"remarque-field\" data-state=\"error\">\n *     <label class=\"remarque-field-label\" for=\"email2\">Email</label>\n *     <input class=\"remarque-input\" type=\"email\" id=\"email2\" name=\"email2\"\n *       aria-invalid=\"true\" aria-describedby=\"email2-message\" required />\n *     <p class=\"remarque-field-message\" id=\"email2-message\" role=\"alert\">\n *       Enter a valid email address.\n *     </p>\n *   </div>\n *\n *   <label class=\"remarque-checkbox\">\n *     <input type=\"checkbox\" name=\"subscribe\" />\n *     <span>Subscribe to updates</span>\n *   </label>\n *\n *   <label class=\"remarque-radio\">\n *     <input type=\"radio\" name=\"plan\" value=\"a\" />\n *     <span>Plan A</span>\n *   </label>\n *\n *   <button class=\"remarque-button\" type=\"button\">Cancel</button>\n *   <button class=\"remarque-button remarque-button--primary\" type=\"submit\">\n *     Submit\n *   </button>\n *\n * `data-state` lives on `.remarque-field` (not the input) — it recolors\n * both the control's border AND the message text together from one\n * attribute, the same \"one attribute drives several descendants\" shape\n * essay.css's counter-driven numbering uses. `aria-invalid=\"true\"` is the\n * REAL accessibility signal (screen readers announce it); `data-state` is\n * the visual layer on top. Author both together — see \"State wiring\"\n * below for what happens if a consumer only sets one.\n */\n\n/* ─── Field wrapper: label + control + help/error text stack ────────────\n * A vertical rhythm of three parts. `--space-2` between label and control\n * (tight — they read as one unit), `--space-2` again before the message\n * line. No border, no background on the wrapper itself — `.remarque-field`\n * is layout only, never a bordered \"card\" around the control (Components:\n * \"no component should be visually louder than the content it contains\").\n */\n.remarque-field {\n  display: flex;\n  flex-direction: column;\n  gap: var(--space-2);\n  max-width: var(--content-reading);\n}\n\n.remarque-field + .remarque-field {\n  margin-top: var(--space-5);\n}\n\n/* Label voice: same declarations as `.text-label` (tokens-core.css),\n   repeated rather than depended-on-as-a-mixin — the same non-mixin\n   precedent essay.css's TOC summary and broadsheet.css's kicker rows\n   establish. True small caps (`font-variant-caps`), never `text-transform:\n   uppercase` (REMARQUE.md \"Small Caps\"). Quiet mono metadata voice for the\n   label, not the body face — a form label identifies the field, the VALUE\n   typed into it is the content, and that distinction is the same one\n   `.text-label` already draws for dates/tags/status elsewhere. */\n.remarque-field-label {\n  font-family: var(--font-mono);\n  font-size: var(--text-meta);\n  line-height: var(--leading-meta);\n  font-variant-caps: all-small-caps;\n  letter-spacing: var(--tracking-caps);\n  color: var(--color-muted);\n}\n\n/* Required-field marker: a plain asterisk in the accent color is the one\n   sanctioned use here (it is unambiguously \"this is the interactive thing\n   that needs attention right now\" — not decoration). Author it inside the\n   label: <label>Email <span class=\"remarque-field-required\"\n   aria-hidden=\"true\">*</span></label> — aria-hidden because `required` on\n   the input itself is the real signal a screen reader announces. */\n.remarque-field-required {\n  color: var(--color-accent);\n}\n\n/* Help/error/success message line — meta voice, body-face-adjacent size\n   floor (--text-meta, 14px, clears the USWDS small-text minimum). Neutral\n   (muted) by default; recolored by `.remarque-field[data-state]` below.\n   `text-wrap: pretty` matches `.remarque-prose`'s optical default for\n   short justified-feeling message copy. */\n.remarque-field-message {\n  font-family: var(--font-mono);\n  font-size: var(--text-meta);\n  line-height: var(--leading-meta);\n  letter-spacing: var(--tracking-meta);\n  color: var(--color-muted);\n  margin: 0;\n  text-wrap: pretty;\n}\n\n/* ─── Text inputs: input / textarea / select ─────────────────────────────\n * One shared class across all three native elements — same border,\n * radius, spacing, and body-voice typography (Font Slots: \"Body ... UI\n * labels, navigation, buttons\" — form values are UI labels' closest\n * relative here, not metadata). `--color-border-bold`, not `-bold`'s\n * quieter sibling: an input's boundary is a FUNCTIONAL edge (WCAG 1.4.11\n * non-text contrast), the same reasoning `.remarque-sidenote`'s narrow-\n * viewport border and `.remarque-toc-rail`'s hairline both already apply\n * decoratively-vs-functionally in essay.css.\n */\n.remarque-input {\n  display: block;\n  width: 100%;\n  min-height: 44px; /* USWDS/WCAG 2.5.5 touch-target floor — see AGENT_RULES.md */\n  padding: var(--space-2) var(--space-3);\n  font-family: var(--font-body);\n  font-size: var(--text-body);\n  line-height: var(--leading-title);\n  color: var(--color-fg);\n  background-color: var(--color-bg);\n  border: var(--border-width) var(--border-style) var(--color-border-bold);\n  /* Restraint rule (AGENT_RULES.md \"Border radius never exceeds\n     --radius-md\" + this module's own tighter floor): form controls stay\n     at --radius-sm, never the 8px ceiling other chrome is allowed. A\n     smaller control reads as more precise at a smaller radius. */\n  border-radius: var(--radius-sm);\n  transition: border-color var(--motion-fast) var(--motion-easing);\n}\n\ntextarea.remarque-input {\n  min-height: 6rem; /* several lines tall by default — still clears the 44px floor */\n  resize: vertical;\n}\n\n/* Native select's disclosure triangle is left as the platform default —\n   restyling it means either `appearance: none` (which then requires a\n   hand-drawn replacement icon, exactly the \"fake replacement\" this module\n   avoids) or accepting a single browser's rendering as the reference,\n   neither of which is worth it for one triangle. */\n.remarque-input:hover {\n  border-color: var(--color-fg-muted);\n}\n\n/* Placeholder: --color-muted, the same 4.5:1-on-bg/-surface token used\n   everywhere else at this contrast tier — a conscious choice, not the\n   browser default (which is often far below AA). Placeholder text is\n   supplementary (never the only label — every `.remarque-input` pairs\n   with a real `<label>`), so 4.5:1 rather than `--color-fg-muted`'s 7:1\n   is the correct tier: AA is sufficient for non-essential hint copy. */\n.remarque-input::placeholder {\n  color: var(--color-muted);\n  opacity: 1; /* Firefox lowers placeholder opacity by default; pin it so the token value is what actually renders */\n}\n\n.remarque-input:disabled {\n  color: var(--color-disabled);\n  background-color: var(--color-bg-subtle);\n  border-color: var(--color-border);\n  cursor: not-allowed;\n}\n\n/* ─── Checkbox / Radio — accent-color, no fake replacements ──────────────\n * `accent-color` is the ENTIRE recoloring mechanism: no `appearance:\n * none`, no hand-drawn checkmark/dot, no absolutely-positioned pseudo-\n * element standing in for the native control. This is a deliberate\n * ceiling on customization, not an oversight — every browser Remarque\n * targets supports `accent-color` on checkboxes/radios, and a real native\n * control keeps every platform accessibility behavior (keyboard,\n * high-contrast mode, forced-colors mode, screen-reader state\n * announcements) for free, at the cost of not controlling the checkmark\n * glyph's exact shape.\n *\n * Sizing: --space-5 (1.5rem / 24px) — comfortably inside the 44px touch\n * target once the wrapping <label> below adds its own min-height, and\n * large enough to keep the accent-colored fill legible (a 16px default\n * checkbox reads as fussy at this system's generous spacing scale).\n */\n.remarque-checkbox,\n.remarque-radio {\n  display: inline-flex;\n  align-items: center;\n  gap: var(--space-2);\n  min-height: 44px; /* touch-target floor on the whole label, same shape as .nav-link */\n  font-family: var(--font-body);\n  font-size: var(--text-body);\n  line-height: var(--leading-title);\n  color: var(--color-fg);\n  cursor: pointer;\n}\n\n.remarque-checkbox input,\n.remarque-radio input {\n  accent-color: var(--color-accent);\n  width: var(--space-5);\n  height: var(--space-5);\n  margin: 0;\n  flex-shrink: 0;\n}\n\n/* `:has()` is a light progressive enhancement here, not a functional\n   dependency — a browser without it still gets a fully working, natively\n   disabled control; it just skips the muted label-text recolor. */\n.remarque-checkbox:has(input:disabled),\n.remarque-radio:has(input:disabled) {\n  color: var(--color-disabled);\n  cursor: not-allowed;\n}\n\n.remarque-checkbox input:disabled,\n.remarque-radio input:disabled {\n  cursor: not-allowed;\n}\n\n/* ─── Buttons ─────────────────────────────────────────────────────────────\n * Quiet by rule (AGENT_RULES.md Components: \"Buttons are quiet: text-only\n * or subtle bordered. Never filled/solid as default.\"). The default\n * variant is bordered, transparent background, body-voice text — reads as\n * \"a clickable label,\" not a colored block. `--primary` is the ONE\n * sanctioned accent placement per viewport (Visual Rules: accent for\n * \"inline links and one interactive element per viewport\") — even there,\n * it stays unfilled: accent text + accent border, never a solid accent\n * fill, so the same restraint the default variant holds carries through\n * to the emphasized one. Hover on `--primary` washes in\n * `--color-accent-subtle` (the same quiet-highlight token\n * `.remarque-prose mark` already uses) rather than darkening to a filled\n * block — a wash, not a fill.\n */\n.remarque-button {\n  display: inline-flex;\n  align-items: center;\n  justify-content: center;\n  gap: var(--space-2);\n  min-height: 44px;\n  padding: var(--space-2) var(--space-4);\n  font-family: var(--font-body);\n  font-size: var(--text-body);\n  font-weight: var(--weight-medium);\n  line-height: var(--leading-title);\n  color: var(--color-fg);\n  background-color: transparent;\n  border: var(--border-width) var(--border-style) var(--color-border-bold);\n  border-radius: var(--radius-sm);\n  cursor: pointer;\n  transition:\n    color var(--motion-fast) var(--motion-easing),\n    border-color var(--motion-fast) var(--motion-easing),\n    background-color var(--motion-fast) var(--motion-easing);\n}\n\n.remarque-button:hover:not(:disabled) {\n  border-color: var(--color-fg-muted);\n  color: var(--color-fg);\n}\n\n.remarque-button--primary {\n  color: var(--color-accent);\n  border-color: var(--color-accent);\n}\n\n.remarque-button--primary:hover:not(:disabled) {\n  color: var(--color-accent-hover);\n  border-color: var(--color-accent-hover);\n  background-color: var(--color-accent-subtle);\n}\n\n.remarque-button:disabled {\n  color: var(--color-disabled);\n  border-color: var(--color-border);\n  background-color: transparent;\n  cursor: not-allowed;\n}\n\n/* ─── Validation state wiring (0.17.0 state-color tokens) ────────────────\n * `data-state` lives on `.remarque-field`, cascading down to the input's\n * border and the message line's color together — author it alongside a\n * real `aria-invalid=\"true\"`/`aria-describedby` pair on the input (the\n * markup contract above); `data-state` alone changes only the paint,\n * `aria-invalid` is what a screen reader actually announces. `--warning`\n * covers a caution/needs-attention message that isn't yet a hard failure\n * (REMARQUE.md \"State Colors\" — \"states needing attention before\n * proceeding\"), e.g. a password-strength hint. No `-subtle` background is\n * used here: `-subtle` is sized for banner/callout backgrounds (REMARQUE.md\n * \"State Colors\"), and painting a per-field background would make the\n * field louder than the content it holds (Components rule) — border +\n * message-text color is enough signal at this scale.\n */\n.remarque-field[data-state=\"error\"] .remarque-input,\n.remarque-input[aria-invalid=\"true\"] {\n  border-color: var(--color-error);\n}\n\n.remarque-field[data-state=\"error\"] .remarque-field-message {\n  color: var(--color-error);\n}\n\n.remarque-field[data-state=\"success\"] .remarque-input {\n  border-color: var(--color-success);\n}\n\n.remarque-field[data-state=\"success\"] .remarque-field-message {\n  color: var(--color-success);\n}\n\n.remarque-field[data-state=\"warning\"] .remarque-input {\n  border-color: var(--color-warning);\n}\n\n.remarque-field[data-state=\"warning\"] .remarque-field-message {\n  color: var(--color-warning);\n}\n\n/* `:user-invalid` — native, zero-JS validity feedback (matches only after\n   the user has interacted with the field and left it invalid, unlike\n   `:invalid`, which can match a required-but-untouched field on page\n   load). Guarded with `@supports selector(...)`: a browser lacking the\n   pseudo-class simply never matches this block and falls back to\n   whatever `data-state`/`aria-invalid` already provide — the same\n   \"degrades to the no-JS/no-support baseline\" shape essay.css's `@media`\n   gate uses for its own progressive enhancement. This is a bonus layer,\n   not a replacement for authoring `data-state=\"error\"` explicitly. */\n@supports selector(:user-invalid) {\n  .remarque-input:user-invalid {\n    border-color: var(--color-error);\n  }\n}\n\n/* ─── Forced-colors reinforcement (issue #93) ────────────────────────────\n * The validation-state wiring above is the textbook color-only-affordance\n * case the issue names explicitly: error/success/warning are distinguished\n * ENTIRELY by `border-color`/`color`, both of which `forced-colors: active`\n * remaps to a system color regardless of which state authored them — so\n * all three states (and the plain, untouched control) would render\n * IDENTICALLY under forced colors, exactly the failure `aria-invalid` +\n * `role=\"alert\"` already prevent for screen-reader users but do nothing\n * for a sighted low-vision user in Windows High Contrast Mode.\n *\n * Fix is geometry, not color, since color is exactly what forced-colors\n * discards: each state gets a distinct `border-style`/`border-width`\n * combination on the control itself (a shape that reads under ANY forced\n * system border color), plus a small glyph prefixed to the message line\n * — scoped to this media query only, so the quiet default (message text\n * alone) is unchanged everywhere else. The glyph is supplementary, not\n * the primary signal (a screen reader user already gets `aria-invalid` +\n * the message text; a sighted forced-colors user gets the border shape);\n * it is not marked `aria-hidden` because CSS generated content cannot\n * carry that attribute, but it is inert in the accessibility tree by\n * default in every current UA/AT combination tested (Chromium+NVDA,\n * Chromium+VoiceOver) — it is not read as if it were message content.\n */\n@media (forced-colors: active) {\n  .remarque-field[data-state=\"error\"] .remarque-input,\n  .remarque-input[aria-invalid=\"true\"] {\n    border-style: double;\n    border-width: 3px;\n  }\n\n  .remarque-field[data-state=\"warning\"] .remarque-input {\n    border-style: dashed;\n    border-width: 2px;\n  }\n\n  .remarque-field[data-state=\"success\"] .remarque-input {\n    border-style: solid;\n    border-width: 2px;\n  }\n\n  .remarque-field[data-state=\"error\"] .remarque-field-message::before {\n    content: \"\\2715\\0020\"; /* ✕ */\n  }\n\n  .remarque-field[data-state=\"warning\"] .remarque-field-message::before {\n    content: \"\\26A0\\0020\"; /* ⚠ */\n  }\n\n  .remarque-field[data-state=\"success\"] .remarque-field-message::before {\n    content: \"\\2713\\0020\"; /* ✓ */\n  }\n}\n\n/* ─── Standalone data tables (issue #30) ──────────────────────────────────\n * `.remarque-table` re-scopes prose.css's table rules (mono `th` voice,\n * 2px `border-bottom` under the header row, 1px row rules only, `.num`\n * for tabular-lining right-aligned numeric columns) under a top-level\n * class instead of `.remarque-prose table`. This is intentionally a\n * near-verbatim copy of those declarations, not a shared mixin (CSS has\n * none) and not a requirement to wrap a standalone data table in the full\n * `.remarque-prose` container — `.remarque-prose` also applies oldstyle\n * proportional numerals, `> * + *` paragraph-spacing rhythm, and prose\n * max-width, none of which a reference data grid (e.g. `Table.astro`)\n * wants. Living in forms.css rather than a new subpath: this module is\n * already \"the supplementary-UI module\" in AGENT_RULES.md's build order\n * (step 7 groups buttons, tags, cards, code blocks, AND tables together),\n * and a table this small does not justify its own subpath the way the\n * Essay/Broadsheet modules' much larger surface area did.\n *\n * Wrap a wide table exactly like prose.css's convention:\n *   <div class=\"remarque-table-wrap\"><table class=\"remarque-table\">...</table></div>\n */\n.remarque-table-wrap {\n  overflow-x: auto;\n  -webkit-overflow-scrolling: touch;\n}\n\n.remarque-table {\n  width: 100%;\n  border-collapse: collapse;\n  font-size: var(--text-body);\n}\n\n.remarque-table caption {\n  font-family: var(--font-mono);\n  font-size: var(--text-meta);\n  letter-spacing: var(--tracking-meta);\n  color: var(--color-muted);\n  text-align: left;\n  caption-side: top;\n  margin-bottom: var(--space-2);\n}\n\n.remarque-table th {\n  font-family: var(--font-mono);\n  font-size: var(--text-meta);\n  letter-spacing: var(--tracking-meta);\n  font-weight: var(--weight-semibold);\n  text-align: left;\n  padding: var(--space-2) var(--space-3);\n  border-bottom: 2px solid var(--color-border-bold);\n  color: var(--color-fg);\n}\n\n.remarque-table td {\n  font-family: var(--font-body);\n  font-size: var(--text-body);\n  padding: var(--space-2) var(--space-3);\n  border-bottom: var(--border-width) var(--border-style) var(--color-border);\n  color: var(--color-fg);\n}\n\n.remarque-table th.num,\n.remarque-table td.num {\n  font-variant-numeric: tabular-nums lining-nums;\n  text-align: right;\n}\n",
+      "content": "/*\n * Remarque — Form Control Primitives (issue #27)\n * ────────────────────────────────────────────────\n * Namespaced classes that style native form elements — no fake replacement\n * widgets. A `<select>` is a `<select>`, a checkbox stays a checkbox with\n * `accent-color` doing the recoloring work a browser already supports\n * natively. This module exists because Remarque is editorial-first: forms\n * are for the contact/search/newsletter moments a written-word site\n * occasionally needs, not a component library for building app UIs. See\n * \"When NOT to use\" in REMARQUE.md's \"Forms\" section before reaching for\n * this on a page that wants more than a handful of fields. Also carries a\n * small standalone-table section (`.remarque-table`) at the end of this\n * file — see that section's header comment for why it lives here rather\n * than in prose.css (issue #30's reference `Table.astro` needs the same\n * table visual language OUTSIDE `.remarque-prose`).\n *\n * PROVENANCE — spec-native, not graduated from a downstream site (unlike\n * essay.css/broadsheet.css). Built directly from issue #27; there was no\n * prior flagship implementation to re-express in token vocabulary, so\n * every value below is original to this module rather than a mapped-over\n * site literal.\n *\n * Own subpath (remarque-tokens/forms, remarque-tokens/forms.css) — NOT\n * included by the tokens.css aggregator, matching essay.css/broadsheet.css/\n * print.css: most Remarque pages have zero forms. Import explicitly, after\n * prose.css if both are in use:\n *   @import 'remarque-tokens/prose.css';\n *   @import 'remarque-tokens/forms.css';\n * (string form — see AGENT_RULES.md Pitfall #6.)\n *\n * ─── MARKUP CONTRACT (summary — full version in REMARQUE.md) ──────────\n *\n *   <div class=\"remarque-field\">\n *     <label class=\"remarque-field-label\" for=\"email\">Email</label>\n *     <input class=\"remarque-input\" type=\"email\" id=\"email\" name=\"email\"\n *       aria-describedby=\"email-help\" />\n *     <p class=\"remarque-field-message\" id=\"email-help\">\n *       We'll never share your email.\n *     </p>\n *   </div>\n *\n *   <div class=\"remarque-field\" data-state=\"error\">\n *     <label class=\"remarque-field-label\" for=\"email2\">Email</label>\n *     <input class=\"remarque-input\" type=\"email\" id=\"email2\" name=\"email2\"\n *       aria-invalid=\"true\" aria-describedby=\"email2-message\" required />\n *     <p class=\"remarque-field-message\" id=\"email2-message\" role=\"alert\">\n *       Enter a valid email address.\n *     </p>\n *   </div>\n *\n *   <label class=\"remarque-checkbox\">\n *     <input type=\"checkbox\" name=\"subscribe\" />\n *     <span>Subscribe to updates</span>\n *   </label>\n *\n *   <label class=\"remarque-radio\">\n *     <input type=\"radio\" name=\"plan\" value=\"a\" />\n *     <span>Plan A</span>\n *   </label>\n *\n *   <button class=\"remarque-button\" type=\"button\">Cancel</button>\n *   <button class=\"remarque-button remarque-button--primary\" type=\"submit\">\n *     Submit\n *   </button>\n *\n * `data-state` lives on `.remarque-field` (not the input) — it recolors\n * both the control's border AND the message text together from one\n * attribute, the same \"one attribute drives several descendants\" shape\n * essay.css's counter-driven numbering uses. `aria-invalid=\"true\"` is the\n * REAL accessibility signal (screen readers announce it); `data-state` is\n * the visual layer on top. Author both together — see \"State wiring\"\n * below for what happens if a consumer only sets one.\n */\n\n/* ─── Field wrapper: label + control + help/error text stack ────────────\n * A vertical rhythm of three parts. `--space-2` between label and control\n * (tight — they read as one unit), `--space-2` again before the message\n * line. No border, no background on the wrapper itself — `.remarque-field`\n * is layout only, never a bordered \"card\" around the control (Components:\n * \"no component should be visually louder than the content it contains\").\n */\n.remarque-field {\n  display: flex;\n  flex-direction: column;\n  gap: var(--space-2);\n  max-width: var(--content-reading);\n}\n\n.remarque-field + .remarque-field {\n  margin-top: var(--space-5);\n}\n\n/* Label voice: same declarations as `.text-label` (tokens-core.css),\n   repeated rather than depended-on-as-a-mixin — the same non-mixin\n   precedent essay.css's TOC summary and broadsheet.css's kicker rows\n   establish. True small caps (`font-variant-caps`), never `text-transform:\n   uppercase` (REMARQUE.md \"Small Caps\"). Quiet mono metadata voice for the\n   label, not the body face — a form label identifies the field, the VALUE\n   typed into it is the content, and that distinction is the same one\n   `.text-label` already draws for dates/tags/status elsewhere. */\n.remarque-field-label {\n  font-family: var(--font-mono);\n  font-size: var(--text-meta);\n  line-height: var(--leading-meta);\n  font-variant-caps: all-small-caps;\n  letter-spacing: var(--tracking-caps);\n  color: var(--color-muted);\n}\n\n/* Required-field marker: a plain asterisk in the accent color is the one\n   sanctioned use here (it is unambiguously \"this is the interactive thing\n   that needs attention right now\" — not decoration). Author it inside the\n   label: <label>Email <span class=\"remarque-field-required\"\n   aria-hidden=\"true\">*</span></label> — aria-hidden because `required` on\n   the input itself is the real signal a screen reader announces. */\n.remarque-field-required {\n  color: var(--color-accent);\n}\n\n/* Help/error/success message line — meta voice, body-face-adjacent size\n   floor (--text-meta, 14px, clears the USWDS small-text minimum). Neutral\n   (muted) by default; recolored by `.remarque-field[data-state]` below.\n   `text-wrap: pretty` matches `.remarque-prose`'s optical default for\n   short justified-feeling message copy. */\n.remarque-field-message {\n  font-family: var(--font-mono);\n  font-size: var(--text-meta);\n  line-height: var(--leading-meta);\n  letter-spacing: var(--tracking-meta);\n  color: var(--color-muted);\n  margin: 0;\n  text-wrap: pretty;\n}\n\n/* ─── Text inputs: input / textarea / select ─────────────────────────────\n * One shared class across all three native elements — same border,\n * radius, spacing, and body-voice typography (Font Slots: \"Body ... UI\n * labels, navigation, buttons\" — form values are UI labels' closest\n * relative here, not metadata). `--color-border-bold`, not `-bold`'s\n * quieter sibling: an input's boundary is a FUNCTIONAL edge (WCAG 1.4.11\n * non-text contrast), the same reasoning `.remarque-sidenote`'s narrow-\n * viewport border and `.remarque-toc-rail`'s hairline both already apply\n * decoratively-vs-functionally in essay.css.\n */\n.remarque-input {\n  display: block;\n  width: 100%;\n  min-height: 44px; /* USWDS/WCAG 2.5.5 touch-target floor — see AGENT_RULES.md */\n  padding: var(--space-2) var(--space-3);\n  font-family: var(--font-body);\n  font-size: var(--text-body);\n  line-height: var(--leading-title);\n  color: var(--color-fg);\n  background-color: var(--color-bg);\n  border: var(--border-width) var(--border-style) var(--color-border-bold);\n  /* Restraint rule (AGENT_RULES.md \"Border radius never exceeds\n     --radius-md\" + this module's own tighter floor): form controls stay\n     at --radius-sm, never the 8px ceiling other chrome is allowed. A\n     smaller control reads as more precise at a smaller radius. */\n  border-radius: var(--radius-sm);\n  transition: border-color var(--motion-fast) var(--motion-easing);\n}\n\ntextarea.remarque-input {\n  min-height: 6rem; /* several lines tall by default — still clears the 44px floor */\n  resize: vertical;\n}\n\n/* Native select's disclosure triangle is left as the platform default —\n   restyling it means either `appearance: none` (which then requires a\n   hand-drawn replacement icon, exactly the \"fake replacement\" this module\n   avoids) or accepting a single browser's rendering as the reference,\n   neither of which is worth it for one triangle. */\n.remarque-input:hover {\n  border-color: var(--color-fg-muted);\n}\n\n/* Placeholder: --color-muted, the same 4.5:1-on-bg/-surface token used\n   everywhere else at this contrast tier — a conscious choice, not the\n   browser default (which is often far below AA). Placeholder text is\n   supplementary (never the only label — every `.remarque-input` pairs\n   with a real `<label>`), so 4.5:1 rather than `--color-fg-muted`'s 7:1\n   is the correct tier: AA is sufficient for non-essential hint copy. */\n.remarque-input::placeholder {\n  color: var(--color-muted);\n  opacity: 1; /* Firefox lowers placeholder opacity by default; pin it so the token value is what actually renders */\n}\n\n.remarque-input:disabled {\n  color: var(--color-disabled);\n  background-color: var(--color-bg-subtle);\n  border-color: var(--color-border);\n  cursor: not-allowed;\n}\n\n/* ─── Checkbox / Radio — accent-color, no fake replacements ──────────────\n * `accent-color` is the ENTIRE recoloring mechanism: no `appearance:\n * none`, no hand-drawn checkmark/dot, no absolutely-positioned pseudo-\n * element standing in for the native control. This is a deliberate\n * ceiling on customization, not an oversight — every browser Remarque\n * targets supports `accent-color` on checkboxes/radios, and a real native\n * control keeps every platform accessibility behavior (keyboard,\n * high-contrast mode, forced-colors mode, screen-reader state\n * announcements) for free, at the cost of not controlling the checkmark\n * glyph's exact shape.\n *\n * Sizing: --space-5 (1.5rem / 24px) — comfortably inside the 44px touch\n * target once the wrapping <label> below adds its own min-height, and\n * large enough to keep the accent-colored fill legible (a 16px default\n * checkbox reads as fussy at this system's generous spacing scale).\n */\n.remarque-checkbox,\n.remarque-radio {\n  display: inline-flex;\n  align-items: center;\n  gap: var(--space-2);\n  min-height: 44px; /* touch-target floor on the whole label, same shape as .nav-link */\n  font-family: var(--font-body);\n  font-size: var(--text-body);\n  line-height: var(--leading-title);\n  color: var(--color-fg);\n  cursor: pointer;\n}\n\n.remarque-checkbox input,\n.remarque-radio input {\n  accent-color: var(--color-accent);\n  width: var(--space-5);\n  height: var(--space-5);\n  margin: 0;\n  flex-shrink: 0;\n}\n\n/* `:has()` is a light progressive enhancement here, not a functional\n   dependency — a browser without it still gets a fully working, natively\n   disabled control; it just skips the muted label-text recolor. */\n.remarque-checkbox:has(input:disabled),\n.remarque-radio:has(input:disabled) {\n  color: var(--color-disabled);\n  cursor: not-allowed;\n}\n\n.remarque-checkbox input:disabled,\n.remarque-radio input:disabled {\n  cursor: not-allowed;\n}\n\n/* ─── Buttons ─────────────────────────────────────────────────────────────\n * Quiet by rule (AGENT_RULES.md Components: \"Buttons are quiet: text-only\n * or subtle bordered. Never filled/solid as default.\"). The default\n * variant is bordered, transparent background, body-voice text — reads as\n * \"a clickable label,\" not a colored block. `--primary` is the ONE\n * sanctioned accent placement per viewport (Visual Rules: accent for\n * \"inline links and one interactive element per viewport\") — even there,\n * it stays unfilled: accent text + accent border, never a solid accent\n * fill, so the same restraint the default variant holds carries through\n * to the emphasized one. Hover on `--primary` washes in\n * `--color-accent-subtle` (the same quiet-highlight token\n * `.remarque-prose mark` already uses) rather than darkening to a filled\n * block — a wash, not a fill.\n */\n.remarque-button {\n  display: inline-flex;\n  align-items: center;\n  justify-content: center;\n  gap: var(--space-2);\n  min-height: 44px;\n  padding: var(--space-2) var(--space-4);\n  font-family: var(--font-body);\n  font-size: var(--text-body);\n  font-weight: var(--weight-medium);\n  line-height: var(--leading-title);\n  color: var(--color-fg);\n  background-color: transparent;\n  border: var(--border-width) var(--border-style) var(--color-border-bold);\n  border-radius: var(--radius-sm);\n  cursor: pointer;\n  transition:\n    color var(--motion-fast) var(--motion-easing),\n    border-color var(--motion-fast) var(--motion-easing),\n    background-color var(--motion-fast) var(--motion-easing);\n}\n\n.remarque-button:hover:not(:disabled) {\n  border-color: var(--color-fg-muted);\n  color: var(--color-fg);\n}\n\n.remarque-button--primary {\n  color: var(--color-accent);\n  border-color: var(--color-accent);\n}\n\n.remarque-button--primary:hover:not(:disabled) {\n  color: var(--color-accent-hover);\n  border-color: var(--color-accent-hover);\n  background-color: var(--color-accent-subtle);\n}\n\n.remarque-button:disabled {\n  color: var(--color-disabled);\n  border-color: var(--color-border);\n  background-color: transparent;\n  cursor: not-allowed;\n}\n\n/* ─── Validation state wiring (0.17.0 state-color tokens) ────────────────\n * `data-state` lives on `.remarque-field`, cascading down to the input's\n * border and the message line's color together — author it alongside a\n * real `aria-invalid=\"true\"`/`aria-describedby` pair on the input (the\n * markup contract above); `data-state` alone changes only the paint,\n * `aria-invalid` is what a screen reader actually announces. `--warning`\n * covers a caution/needs-attention message that isn't yet a hard failure\n * (REMARQUE.md \"State Colors\" — \"states needing attention before\n * proceeding\"), e.g. a password-strength hint. No `-subtle` background is\n * used here: `-subtle` is sized for banner/callout backgrounds (REMARQUE.md\n * \"State Colors\"), and painting a per-field background would make the\n * field louder than the content it holds (Components rule) — border +\n * message-text color is enough signal at this scale.\n */\n.remarque-field[data-state=\"error\"] .remarque-input,\n.remarque-input[aria-invalid=\"true\"] {\n  border-color: var(--color-error);\n}\n\n.remarque-field[data-state=\"error\"] .remarque-field-message {\n  color: var(--color-error);\n}\n\n.remarque-field[data-state=\"success\"] .remarque-input {\n  border-color: var(--color-success);\n}\n\n.remarque-field[data-state=\"success\"] .remarque-field-message {\n  color: var(--color-success);\n}\n\n.remarque-field[data-state=\"warning\"] .remarque-input {\n  border-color: var(--color-warning);\n}\n\n.remarque-field[data-state=\"warning\"] .remarque-field-message {\n  color: var(--color-warning);\n}\n\n/* `:user-invalid` — native, zero-JS validity feedback (matches only after\n   the user has interacted with the field and left it invalid, unlike\n   `:invalid`, which can match a required-but-untouched field on page\n   load). Guarded with `@supports selector(...)`: a browser lacking the\n   pseudo-class simply never matches this block and falls back to\n   whatever `data-state`/`aria-invalid` already provide — the same\n   \"degrades to the no-JS/no-support baseline\" shape essay.css's `@media`\n   gate uses for its own progressive enhancement. This is a bonus layer,\n   not a replacement for authoring `data-state=\"error\"` explicitly. */\n@supports selector(:user-invalid) {\n  .remarque-input:user-invalid {\n    border-color: var(--color-error);\n  }\n}\n\n/* ─── `:has()` zero-JS validation enhancement layer (issue #97) ──────────\n * A second, purely additive progressive-enhancement layer over the\n * `:user-invalid` layer just above — same native-first shape, one step\n * further. `:user-invalid` alone can only style the INPUT it matches;\n * CSS has no \"parent selector\" without `:has()`, so it has no way to\n * reach the field's label or wrapper. `:has()` is exactly the piece that\n * closes that gap: `.remarque-field` can react to a descendant control's\n * validity/focus state directly, with no `data-state` attribute and no\n * JavaScript. Guarded with `@supports selector(:has(...))` — the same\n * \"degrades to the no-JS/no-support baseline\" shape the `:user-invalid`\n * block above uses — so a browser missing either pseudo-class in the\n * compound query falls back cleanly to whatever `data-state`/\n * `aria-invalid` (and, where supported, the plain `:user-invalid` layer\n * above) already provide. `data-state` remains the CANONICAL contract;\n * neither block below replaces authoring `data-state=\"error\"` explicitly\n * — see REMARQUE.md \"State wiring\".\n *\n * Like the bare `:user-invalid` layer above, this is a bonus visual cue,\n * not one of the canonical `data-state` states the forced-colors\n * reinforcement below was scoped to fix (REMARQUE.md \"Forced Colors &\n * Contrast Preferences\") — it is not itself a new color-only-affordance\n * regression, since the real accessible signal (`aria-invalid`, the\n * `data-state` border/message wiring) is unchanged and unaffected by\n * whether this bonus layer's color survives forced-colors mode.\n */\n@supports selector(:has(:user-invalid)) {\n  /* Extends the :user-invalid border recolor (input only, above) up to\n     the field's label — the one thing plain :user-invalid cannot reach\n     on its own. */\n  .remarque-field:has(.remarque-input:user-invalid) .remarque-field-label {\n    color: var(--color-error);\n  }\n}\n\n/* Field-level focus affordance — a quiet secondary cue, NOT a\n   replacement for the control's own native `:focus-visible` outline\n   (tokens-core.css), which already renders on the control itself and is\n   forced-colors-safe by construction. Brightens the label from\n   `--color-muted` to `--color-fg` while any control inside the field has\n   keyboard focus — a restrained color wash, not a new border/background,\n   matching this module's \"no component should be visually louder than\n   the content it contains\" rule (AGENT_RULES.md Components). */\n@supports selector(:has(:focus-visible)) {\n  .remarque-field:has(.remarque-input:focus-visible) .remarque-field-label {\n    color: var(--color-fg);\n  }\n}\n\n/* ─── Forced-colors reinforcement (issue #93) ────────────────────────────\n * The validation-state wiring above is the textbook color-only-affordance\n * case the issue names explicitly: error/success/warning are distinguished\n * ENTIRELY by `border-color`/`color`, both of which `forced-colors: active`\n * remaps to a system color regardless of which state authored them — so\n * all three states (and the plain, untouched control) would render\n * IDENTICALLY under forced colors, exactly the failure `aria-invalid` +\n * `role=\"alert\"` already prevent for screen-reader users but do nothing\n * for a sighted low-vision user in Windows High Contrast Mode.\n *\n * Fix is geometry, not color, since color is exactly what forced-colors\n * discards: each state gets a distinct `border-style`/`border-width`\n * combination on the control itself (a shape that reads under ANY forced\n * system border color), plus a small glyph prefixed to the message line\n * — scoped to this media query only, so the quiet default (message text\n * alone) is unchanged everywhere else. The glyph is supplementary, not\n * the primary signal (a screen reader user already gets `aria-invalid` +\n * the message text; a sighted forced-colors user gets the border shape);\n * it is not marked `aria-hidden` because CSS generated content cannot\n * carry that attribute, but it is inert in the accessibility tree by\n * default in every current UA/AT combination tested (Chromium+NVDA,\n * Chromium+VoiceOver) — it is not read as if it were message content.\n */\n@media (forced-colors: active) {\n  .remarque-field[data-state=\"error\"] .remarque-input,\n  .remarque-input[aria-invalid=\"true\"] {\n    border-style: double;\n    border-width: 3px;\n  }\n\n  .remarque-field[data-state=\"warning\"] .remarque-input {\n    border-style: dashed;\n    border-width: 2px;\n  }\n\n  .remarque-field[data-state=\"success\"] .remarque-input {\n    border-style: solid;\n    border-width: 2px;\n  }\n\n  .remarque-field[data-state=\"error\"] .remarque-field-message::before {\n    content: \"\\2715\\0020\"; /* ✕ */\n  }\n\n  .remarque-field[data-state=\"warning\"] .remarque-field-message::before {\n    content: \"\\26A0\\0020\"; /* ⚠ */\n  }\n\n  .remarque-field[data-state=\"success\"] .remarque-field-message::before {\n    content: \"\\2713\\0020\"; /* ✓ */\n  }\n}\n\n/* ─── Standalone data tables (issue #30) ──────────────────────────────────\n * `.remarque-table` re-scopes prose.css's table rules (mono `th` voice,\n * 2px `border-bottom` under the header row, 1px row rules only, `.num`\n * for tabular-lining right-aligned numeric columns) under a top-level\n * class instead of `.remarque-prose table`. This is intentionally a\n * near-verbatim copy of those declarations, not a shared mixin (CSS has\n * none) and not a requirement to wrap a standalone data table in the full\n * `.remarque-prose` container — `.remarque-prose` also applies oldstyle\n * proportional numerals, `> * + *` paragraph-spacing rhythm, and prose\n * max-width, none of which a reference data grid (e.g. `Table.astro`)\n * wants. Living in forms.css rather than a new subpath: this module is\n * already \"the supplementary-UI module\" in AGENT_RULES.md's build order\n * (step 7 groups buttons, tags, cards, code blocks, AND tables together),\n * and a table this small does not justify its own subpath the way the\n * Essay/Broadsheet modules' much larger surface area did.\n *\n * Wrap a wide table exactly like prose.css's convention:\n *   <div class=\"remarque-table-wrap\"><table class=\"remarque-table\">...</table></div>\n */\n.remarque-table-wrap {\n  overflow-x: auto;\n  -webkit-overflow-scrolling: touch;\n}\n\n.remarque-table {\n  width: 100%;\n  border-collapse: collapse;\n  font-size: var(--text-body);\n}\n\n.remarque-table caption {\n  font-family: var(--font-mono);\n  font-size: var(--text-meta);\n  letter-spacing: var(--tracking-meta);\n  color: var(--color-muted);\n  text-align: left;\n  caption-side: top;\n  margin-bottom: var(--space-2);\n}\n\n.remarque-table th {\n  font-family: var(--font-mono);\n  font-size: var(--text-meta);\n  letter-spacing: var(--tracking-meta);\n  font-weight: var(--weight-semibold);\n  text-align: left;\n  padding: var(--space-2) var(--space-3);\n  border-bottom: 2px solid var(--color-border-bold);\n  color: var(--color-fg);\n}\n\n.remarque-table td {\n  font-family: var(--font-body);\n  font-size: var(--text-body);\n  padding: var(--space-2) var(--space-3);\n  border-bottom: var(--border-width) var(--border-style) var(--color-border);\n  color: var(--color-fg);\n}\n\n.remarque-table th.num,\n.remarque-table td.num {\n  font-variant-numeric: tabular-nums lining-nums;\n  text-align: right;\n}\n",
       "type": "remarque:css"
     },
     {

package/registry/palette-deck.json

@@ -4,7 +4,7 @@
   "type": "remarque:contract",
   "title": "Palette Deck (markup contract only — no executable content)",
   "description": "Markup/wiring contract for the Palette Deck: set `data-palette` on the same root element as `data-theme` and the two compose independently. This item ships ONLY that HTML fragment. `deck.js` — the runtime module itself, a dependency-free ~60-line ESM file — is deliberately NOT embedded here: the registry’s blocking no-executable-content condition is held to an unambiguous zero-`<script>`-tag bar across every item, so neither `deck.js` nor the FOUC-restore `<script>` sample documented alongside it in REMARQUE.md is included. Consume `deck.js` the normal way, via the `remarque-tokens/deck` package import (`dependencies` below); read the FOUC-restore snippet from the `docs` URL.",
-  "version": "0.23.0",
+  "version": "0.25.0",
   "integrity": "sha256-WGgBZ2j0VnLPRAZlzv/4G1Wu9rKqTdXf1536dWWu8nU=",
   "dependencies": [
     "remarque-tokens"

package/registry.json

@@ -2,14 +2,14 @@
   "$schema": "https://williamzujkowski.github.io/remarque/registry.schema.json",
   "name": "remarque-tokens",
   "homepage": "https://williamzujkowski.github.io/remarque/",
-  "version": "0.23.0",
+  "version": "0.25.0",
   "items": [
     {
       "name": "essay",
       "type": "remarque:contract",
       "title": "Essay Module",
       "description": "Sidenotes + sticky TOC rail for long-form Essay pages: margin notes relocated into real DOM order, right after the paragraph that cites them, numbered by CSS counter and labeled `aria-label=\"Note N\"` in the same order the counter advances — the mechanism that prevents the sidenote aria-label/DOM-order transcription bug found in the flagship migration (#89, williamzujkowski.github.io#380).",
-      "version": "0.23.0",
+      "version": "0.25.0",
       "integrity": "sha256-zr04H0+0xf01OWLk6B2A9ziZOYJd4Sq5q5/cib65lbU=",
       "file": "registry/essay.json"
     },
@@ -18,7 +18,7 @@
       "type": "remarque:contract",
       "title": "Broadsheet Pattern",
       "description": "The editorial Landing/archive pattern: masthead, lead article, numbered entry list, and post-header kicker. Entry numerals are generated from `data-entry-number` via `attr()`, never `counter()`, and every kicker/dateline row is true `font-variant-caps: all-small-caps`, never `text-transform: uppercase`.",
-      "version": "0.23.0",
+      "version": "0.25.0",
       "integrity": "sha256-BZea38PRdob4OfmdGN0eDw3U0adl7SEsdrjKgSewK9A=",
       "file": "registry/broadsheet.json"
     },
@@ -27,8 +27,8 @@
       "type": "remarque:contract",
       "title": "Forms Primitives",
       "description": "Native field/input/checkbox/radio/button primitives with state-color wiring. Every `.remarque-input` pairs `for`/`id` with its `.remarque-field-label`, and every `.remarque-field-message` is wired via `aria-describedby` on the control — the paint-layer `data-state` attribute is never the only signal; `aria-invalid`/`aria-describedby` on the input carry the real accessibility contract.",
-      "version": "0.23.0",
-      "integrity": "sha256-Ft+jRmZtY6HBdTCFoIIJbM3S/3dx7iSVl7NRWD/40rY=",
+      "version": "0.25.0",
+      "integrity": "sha256-WfYjcf04Dxxx7X21U5b6DrY90Qw95p0zkCQszoh77tE=",
       "file": "registry/forms.json"
     },
     {
@@ -36,7 +36,7 @@
       "type": "remarque:contract",
       "title": "Palette Deck (markup contract only — no executable content)",
       "description": "Markup/wiring contract for the Palette Deck: set `data-palette` on the same root element as `data-theme` and the two compose independently. This item ships ONLY that HTML fragment. `deck.js` — the runtime module itself, a dependency-free ~60-line ESM file — is deliberately NOT embedded here: the registry’s blocking no-executable-content condition is held to an unambiguous zero-`<script>`-tag bar across every item, so neither `deck.js` nor the FOUC-restore `<script>` sample documented alongside it in REMARQUE.md is included. Consume `deck.js` the normal way, via the `remarque-tokens/deck` package import (`dependencies` below); read the FOUC-restore snippet from the `docs` URL.",
-      "version": "0.23.0",
+      "version": "0.25.0",
       "integrity": "sha256-WGgBZ2j0VnLPRAZlzv/4G1Wu9rKqTdXf1536dWWu8nU=",
       "file": "registry/palette-deck.json"
     }