trykeyline 0.1.0 → 0.1.2

package/.claude-plugin/marketplace.json

@@ -6,7 +6,7 @@
   },
   "metadata": {
     "description": "Keyline: interface design laws for coding agents, applied in your project's own tokens.",
-    "version": "0.1.0"
+    "version": "0.1.2"
   },
   "plugins": [
     {

package/LICENSE

@@ -19,19 +19,3 @@ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
-
----
-
-WHAT THIS LICENCE DOES AND DOESN'T COVER
-
-The licence above covers the template: the components, hooks, styles, build
-configuration and scripts.
-
-It does not cover content. Text, photographs, designs, writing, résumés, logos
-and brand marks belong to whoever made them, are not licensed here, and are not
-yours to republish by virtue of having a copy of this repository. If you cloned
-this from someone's personal site, replace their content with your own.
-
-Third-party marks in `src/lib/stackIcons.tsx` are generated from simple-icons
-(CC0-1.0). The brands they represent remain the property of their owners and
-their trademark guidelines still apply.

package/bin/keyline.mjs

@@ -90,7 +90,8 @@ Options:
   -t, --tool <tool[,tool…]>   which agent — asked for when not given, Claude Code
                               when there's no terminal to ask on. One of:
                               ${TOOL_IDS.join(", ")}
-  --user                      for every project on this machine, not just this one
+  --agent <tool[,tool…]>      the same as --tool
+  --user                     for every project on this machine, not just this one
   --dir <path>                into <path>, whatever the agent
   -f, --force                 overwrite a copy that's already there
   -h, --help                  this

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "trykeyline",
-  "version": "0.1.0",
+  "version": "0.1.2",
   "description": "Interface design laws for coding agents: one skill that reads your codebase, writes a DESIGN.md in your own token names, then critiques, audits and fixes type, colour, layout, depth, motion and product patterns through it.",
   "keywords": [
     "design",

package/plugins/keyline/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "keyline",
   "displayName": "Keyline",
-  "version": "0.1.0",
+  "version": "0.1.2",
   "description": "Interface design laws for coding agents. /keyline init reads your codebase and writes a DESIGN.md in your own token names; critique, audit, type, color, layout, depth, motion, patterns and polish work through it, with dials set by a preset (editorial, product, expressive or glass).",
   "author": {
     "name": "Mihir Modi",

package/plugins/keyline/plugin.json

@@ -0,0 +1,22 @@
+{
+  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
+  "name": "keyline",
+  "version": "0.1.2",
+  "description": "Interface design laws for coding agents. /keyline init reads your codebase and writes a DESIGN.md in your own token names; critique, audit, type, color, layout, depth, motion, patterns and polish work through it, with dials set by a preset (editorial, product, expressive or glass).",
+  "author": {
+    "name": "Mihir Modi",
+    "url": "https://modimihir.com"
+  },
+  "homepage": "https://github.com/Mihirmodi27/keyline#readme",
+  "repository": "https://github.com/Mihirmodi27/keyline",
+  "license": "MIT",
+  "keywords": [
+    "design-system",
+    "design-tokens",
+    "typography",
+    "motion",
+    "colour",
+    "layout",
+    "accessibility"
+  ]
+}

package/plugins/keyline/skills/keyline/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: keyline
-description: "Design, review and fix interfaces with one set of laws applied in the project's own tokens, names and character. Commands: init (scan the codebase and write DESIGN.md), sync, critique, audit, type, color, layout, depth, motion, patterns, polish. Use when the user wants to set up or document a design system, review or audit a UI, or improve typography, type scale, font weights, colour, contrast, theming, dark mode, spacing, padding, alignment, layout, hierarchy, radii, z-index, cards, shadows, elevation, glass or translucent surfaces, animation, transitions, hover and focus states, reduced motion, UI copy, labels, buttons, forms, dialogs, empty states, dashboards, tables, agent and AI chat interfaces — on websites, landing pages, apps and components. Also for screens that feel generic, boxy, cluttered, flat, noisy, inconsistent or template-made, and for building new UI that should look considered from the first commit. Not for backend-only work."
+description: "Design, review and fix interfaces with one set of laws, applied in the project's own tokens and names. Commands: init (write DESIGN.md), sync, critique, audit, type, color, layout, depth, motion, patterns, polish. Use to set up or document a design system, critique or audit a UI, or improve typography, colour, contrast, dark mode, spacing, layout, hierarchy, cards, shadows, glass and translucent surfaces, animation, hover and focus states, UI copy, forms, dashboards, and agent and AI chat interfaces. Also for screens that feel generic, boxy, cluttered or template-made, and for building new UI. Not for backend-only work."
 ---
 
 # Keyline
@@ -13,45 +13,35 @@ Paths in these files are relative to this skill's folder. In shell commands it i
 
 `/keyline <command> [target]` — the target is a route, file, directory or component; without one, the command takes the whole project, or the screen the conversation is about.
 
-| Command | Does | Changes code |
-|---|---|---|
-| `init` | Scans the codebase, maps its tokens onto roles, picks a preset, writes `DESIGN.md` with the open issues it found | No |
-| `sync` | Reconciles `DESIGN.md` with code that has moved since: drift, new tokens, issues fixed or new | No |
-| `critique` | A designer's read of one screen: what the reader feels first, what's working, the few changes that matter most | No |
-| `audit` | Every law checked with evidence, per domain, scored; findings go to `DESIGN.md` | No |
-| `type` | Type scale, weights, leading, tracking, emphasis, numerals, fonts | Yes |
-| `color` | Tokens by intent, text tiers by measured contrast, status colours, themes | Yes |
-| `layout` | Measure, spacing that groups, radii, line weights, z-index, breakpoints, empty states | Yes |
-| `depth` | Elevation levels, shadows, edges, scrims, translucent surfaces and their fallbacks | Yes |
-| `motion` | Durations, curves, springs, open and close, reduced motion, scroll, hover intent | Yes |
-| `patterns` | Behaviour and words: labels, buttons, destructive actions, forms, agent UIs, dashboards | Yes |
-| `polish` | All six domains in order, one reviewable pass each | Yes |
-
-**No command named?** Pick the one the request is about, say which, and go: "set up", "document", "extract" → `init`; "review", "what's wrong", "feedback" → `critique`; "check everything", "lint", "score" → `audit`; "font", "headings", "typography" → `type`; "colour", "contrast", "dark mode" → `color`; "spacing", "padding", "alignment", "cramped" → `layout`; "shadow", "card", "glass", "modal" → `depth`; "animate", "transition", "feels janky" → `motion`; "copy", "labels", "form", "dialog" → `patterns`; "make it better", "clean this up", "finish" → `polish`. Building something new runs the relevant domains' **Building it for a project** sections, in polish order. `colour`, `typography`, `spacing`, `animate` and `copy` work as aliases.
+| Command | Does |
+|---|---|
+| `init` | Scans the codebase and writes `DESIGN.md` |
+| `sync` | Reconciles `DESIGN.md` with code that has moved |
+| `critique` | A designer's ranked read of one screen |
+| `audit` | Every law checked with evidence, scored per domain |
+| `type` | Scale, weights, leading, tracking, numerals, fonts |
+| `color` | Tokens, contrast, status colours, themes |
+| `layout` | Measure, spacing, radii, lines, z-index, breakpoints |
+| `depth` | Elevation, shadows, scrims, translucent surfaces |
+| `motion` | Durations, curves, springs, reduced motion |
+| `patterns` | Labels, buttons, forms, dialogs, agent UIs, dashboards |
+| `polish` | All six domains in order, one pass each |
+
+**No command named?** Pick the one the request is about, say which, and go: "set up", "document", "extract" → `init`; "review", "what's wrong", "feedback" → `critique`; "check everything", "lint", "score" → `audit`; "font", "headings", "typography" → `type`; "colour", "contrast", "dark mode" → `color`; "spacing", "padding", "alignment", "cramped" → `layout`; "shadow", "card", "glass", "modal" → `depth`; "animate", "transition", "feels janky" → `motion`; "copy", "labels", "form", "dialog" → `patterns`; "make it better", "clean this up", "finish" → `polish`. Building something new runs the relevant domains' `## Building it for a project` sections, in polish order (patterns has none; its nearest is `## Iterating on feedback`). `colour`, `typography`, `spacing`, `animate` and `copy` work as aliases.
 
 ## Before any command
 
 1. **Read `DESIGN.md`** at the project root. `## Profile` gives the preset and any areas on another preset; each domain has its own section; `## Decisions` overrides the preset's defaults and must be respected; `## Open issues` is what's already known.
-2. **No `DESIGN.md`:** for `init`, that's the job. For anything else, run `init`'s scan and mapping for the domains this command touches, do the task, then recommend a full `/keyline init`. Don't refuse.
-3. **Load the command's file**, `commands/<command>.md`. It says which guides to read; read them, don't work from memory of them.
-4. **Preset `glass`:** the exact system from modimihir.com. Read `glass/<domain>/guide.md` beside each domain guide; its values and `assets/` are the recipes.
+2. **No `DESIGN.md`:** for `init`, that's the job. For anything else, run `init` for the domains this command touches — `## Profile` and those domains' sections — do the task, then recommend a full `/keyline init`. Don't refuse.
+3. **Load the command's file**, `commands/<command>.md`. It says which guides to read, and which sections; read them, don't work from memory of them.
+4. **Preset `glass`:** the exact system from modimihir.com. Beside each domain guide, read `glass/<domain>/guide.md` for the exact recipes behind the values in `DESIGN.md`; from its `assets/`, take only the files its `## Assets` list names for what you're changing. There is no `glass/patterns/`: patterns take the dials of the preset nearest the reader.
 
 ## What every command holds to
 
-- **The project's names, always.** Reason in roles (`text.secondary`, `duration.small`), write code in whatever the project calls them. Never rename a project's tokens; never add a second token system beside the first.
+- **The project's names, always.** Reason in roles (`text.secondary`, `duration.small`), write code in whatever the project calls them. Never rename a project's tokens; never add a second token system beside the first. Where a role you need has no row, reuse a value already doing that job; otherwise add one in the project's naming style, marked `proposed`.
 - **Measure, don't estimate.** Mechanical laws are checked by `<keyline>/scripts/check.mjs`; contrast comes from `<keyline>/scripts/contrast.mjs`; inventories from `<keyline>/scripts/scan.mjs`; counts from the code. A finding carries its evidence: a ratio, a count, a `file:line`.
 - **Laws hold under every preset; dials move between them.** A change that would break a law, or move a dial off the preset, is said out loud and asked about first. When the user agrees, it goes under `## Decisions` with its date and reason.
 - **Keep what the design already chose.** An existing interface keeps its brand colour and gradients wherever they do a job, and its corners stay at least as round. Only a law removes something, and the report names that law: a pass that leaves the screen greyer or boxier than it found it has to say why.
 - **Findings are not fixes.** `init`, `sync`, `critique` and `audit` change no code. The refining commands change only what their domain owns, and name the owning domain for anything else they notice.
-- **Write back.** A decision that changes the system — a new role, a moved dial, a law knowingly broken — goes into `DESIGN.md`, so the next session starts from it. Fixed issues come off `## Open issues`.
-- **Look at the result.** When the project can be rendered, render it after a change and look at both themes, a narrow width, and reduced motion where they apply. Code that reads right can still look wrong.
-
-## Where things are
-
-| Folder | Holds |
-|---|---|
-| `commands/` | One file per command: what to read, the steps, what to report |
-| `system/` | Setup: the canonical `roles.md`, the four `presets.md`, the `design-md.md` format, `detection.md` for each stack |
-| `domains/<domain>/` | Each domain's `guide.md` — laws, dials per preset, building, auditing, checklist — and its deeper references |
-| `glass/<domain>/` | The `glass` preset: modimihir.com's exact values, with drop-in tokens and components in `assets/` |
-| `scripts/` | `check.mjs` (the detector: 24 mechanical laws, `--json`, exit codes for CI), `scan.mjs` (token and value inventory) and `contrast.mjs` (measured contrast, translucency composited). Node 18+, no dependencies |
+- **Write back.** A decision that changes the system — a new role, a moved dial, a law knowingly broken, a change a law forced that a later session might undo (marked *law*) — goes into `DESIGN.md`, so the next session starts from it: roles and values in the domain's section, decisions under `## Decisions` (format: `system/design-md.md`). Open issues are one line each with evidence; fixed ones come off.
+- **Look at the result.** When the project can be rendered, render it before and after a change and look at both themes, a narrow width, and reduced motion where they apply. Code that reads right can still look wrong.

package/plugins/keyline/skills/keyline/commands/audit.md

@@ -2,7 +2,12 @@
 
 Every law, checked with evidence, per domain — the full inspection `critique` is the summary of. Findings go into `DESIGN.md` so later sessions start from them.
 
-**Read:** `DESIGN.md`, then the `## Auditing existing code` and `## Checklist` sections of every `domains/<domain>/guide.md` (all six unless the user narrows it). Under preset `glass`, also each `glass/<domain>/guide.md` checklist.
+**Read:** `DESIGN.md`, then from every `domains/<domain>/guide.md` (all six unless the user narrows it):
+
+- **The checklist** — each law's `### N.` heading and its bold first sentence: `awk 'FNR==1{p=0; print "== " FILENAME} /^## /{p = /^## Laws/} p' <keyline>/domains/*/guide.md | grep -oE '^(== |### ).*|^\*\*([^*]|\*[^*])+\*\*'`
+- **`## Auditing existing code`**, and `## Checklist` where a guide still has one: `awk 'FNR==1{p=0; print "== " FILENAME} /^## /{p = /^## (Auditing|Checklist)/} p' <keyline>/domains/*/guide.md`
+
+Read a law's full text where a finding needs it. Under preset `glass`, also each `glass/<domain>/guide.md` checklist (there is no `glass/patterns/`): `awk 'FNR==1{p=0; print "== " FILENAME} /^## /{p = /^## Checklist/} p' <keyline>/glass/*/guide.md`
 
 **Steps:**
 
@@ -20,6 +25,6 @@ Every law, checked with evidence, per domain — the full inspection `critique`
 | 1 | Several laws broken across templates; the domain isn't working as a system |
 | 0 | No system: values typed inline, nothing on a ladder |
 
-**Report:** a table of the six domains with score and finding count, then findings grouped by domain, worst first, one line each with evidence — `file:line`, a ratio, a count — and the law, with its UX-law name where one explains it (the table in `commands/critique.md`). Close with the order to fix in: usually the lowest score first, unless a law in another domain blocks it.
+**Report:** a table of the six domains with score and finding count, then findings grouped by domain, worst first, one line each with evidence — `file:line`, a ratio, a count — and the law, with its UX-law name where one explains it (`commands/ux-laws.md`). Close with the order to fix in: usually the lowest score first, unless a law in another domain blocks it.
 
-**Write back:** every finding under `## Open issues` in `DESIGN.md`, replacing entries now fixed. **Changes no code.**
+**Write back:** every finding under `## Open issues` in `DESIGN.md`, replacing entries now fixed.

package/plugins/keyline/skills/keyline/commands/critique.md

@@ -2,37 +2,14 @@
 
 A designer's read of one screen, flow or component: what a reader notices first, what's working, and the few changes that would matter most. Judgement, ranked — not a checklist. For every law checked with evidence, use `/keyline audit`.
 
-**Read:** `DESIGN.md`. Then the law headings (the `### N.` lines) of all six `domains/<domain>/guide.md` — enough to know which laws exist and cite them by number. Read a law's full text only for the two or three domains where the screen's biggest problems sit, after step 3 has found them. A critique ranks a few changes; it doesn't need every law in full, which is what `/keyline audit` is for.
+**Read:** `DESIGN.md`. Then the law headings (the `### N.` lines) of all six domain guides — enough to know which laws exist and cite them by number: `grep -n '^### [0-9]' <keyline>/domains/*/guide.md`. Read a law's full text only for the two or three domains where the screen's biggest problems sit, after step 3 has found them: `awk '/^## /{p = /^## Laws/} p' <keyline>/domains/<domain>/guide.md`. A critique ranks a few changes; it doesn't need every law in full, which is what `/keyline audit` is for.
 
 **Steps:**
 
 1. **Look at it.** Render it if you can — the running app, a preview, a screenshot through whatever browser tool you have — at a desktop and a phone width, in each theme. Read the code too, for what rendering hides (states, focus, reduced motion). If nothing can be rendered, say the critique is from code alone. With a headless Chrome and no other tool, `--screenshot --window-size=1440,900` shoots a page; dark mode needs the page's own theme switch (its `data-theme` or class) set in the URL or DOM, because Chrome's `--blink-settings` flag only gives light reliably.
 2. **Name what the screen is for and who reads it**, in one sentence. Everything below is measured against it.
 3. **Read it as its reader would, in order:** what the eye lands on first, second, third — and whether that order matches what matters. Then how it groups, what competes, what's missing, what's noise.
-4. **Tie each problem to a law**, by domain and number (`layout law 3`), so the fix is a rule rather than a taste. Where a named UX law explains *why* the reader feels it, name that too (`layout law 13, Fitts's law`) — it tells the owner the problem is about people, not preference. The names are reasons, not a checklist: cite one only where it fits the finding.
-
-| UX law | The reader… | Where Keyline holds it |
-|---|---|---|
-| Aesthetic-usability | forgives a polished screen, and overlooks its problems in testing | Here: judge the laws, not the polish — a beautiful screen still gets every check |
-| Hick's law | takes longer to choose as choices grow | patterns law 8 |
-| Fitts's law | hits big, near targets faster | layout law 13 |
-| Jakob's law | expects this product to work like the others they use | patterns law 14 |
-| Miller's law | holds only a few chunks at once | patterns law 8 |
-| Doherty threshold | keeps pace with responses under ≈ 400ms | patterns law 15; motion law 3 |
-| Proximity | groups what sits close | layout law 2 |
-| Similarity | groups what looks alike | patterns law 3; layout law 3 (one style per device) |
-| Common region | groups what shares a boundary | layout law 3 — the quietest boundary that holds, a card last |
-| Visual hierarchy | reads in the order size, weight, colour and position set | type laws 3–4; layout law 2; step 3 above |
-| Progressive disclosure | copes when detail arrives on request | patterns law 8; layout law 11 |
-| Recognition over recall | finds seeing easier than remembering | patterns law 16; patterns law 7 (shortcuts shown where the action lives) |
-| Von Restorff | remembers the one thing that differs | colour law 7; motion law 9; one primary button (patterns law 13) |
-| Peak-end rule | remembers the best or worst moment and the end | patterns law 17 |
-| Goal-gradient | speeds up near the goal | patterns law 17 |
-| Serial position | remembers the first and last items | patterns law 3; primary destinations first in the shell (layout dials) |
-| Tesler's law | shouldn't carry complexity the product can | patterns law 16 |
-| Postel's law | types things in many forms | patterns law 16 |
-| Occam's razor | is served by the fewest parts that do the job | motion law 1; patterns law 12; `commands/refine.md` |
-| Feedback loops | needs to see every action land | patterns law 15 |
+4. **Tie each problem to a law**, by domain and number (`layout law 3`), so the fix is a rule rather than a taste. Where a named UX law explains *why* the reader feels it, name that too (`layout law 13, Fitts's law`) — it tells the owner the problem is about people, not preference. The names, and where Keyline holds each, are in `commands/ux-laws.md`.
 
 **Report:**
 
@@ -40,4 +17,4 @@ A designer's read of one screen, flow or component: what a reader notices first,
 - **Changes, most important first** — at most five. Each: what's wrong, as the reader feels it; the law; the fix in a sentence, in the project's names; and the command that makes it (`/keyline layout`).
 - **Keep** — what's working and shouldn't be touched by the fixes.
 
-Don't pad to five. Don't list what's fine as a problem to fix. **Changes no code.**
+Don't pad to five. Don't list what's fine as a problem to fix.

package/plugins/keyline/skills/keyline/commands/init.md

@@ -4,12 +4,13 @@ Fit Keyline to this project: find out once what it calls things, who it's for an
 
 **Read:** `system/guide.md`, then `system/roles.md`, `system/presets.md` and `system/design-md.md`. `system/detection.md` when the scan leaves you unsure where a stack keeps its tokens.
 
-**Steps:** follow `system/guide.md` from step 1 to step 5 — scan, map by usage, measure contrast, choose the preset from the reader, ask at most four questions, write the file. Before writing `## Open issues`, read the law headings (the `### N.` lines) of each domain guide you cite, so every citation names the right law.
+**Steps:** follow `system/guide.md` from step 1 to step 5 — scan, map by usage, measure contrast, choose the preset from the reader, ask at most four questions, write the file. Before writing `## Open issues`, read the law headings (the `### N.` lines) of each domain guide you cite, so every citation names the right law: `grep -n '^### [0-9]' <keyline>/domains/*/guide.md`. Once the preset is chosen, read every guide's `## Dials` for its column, since `## Decisions` records each dial the project sets differently: `awk 'FNR==1{p=0; print "== " FILENAME} /^## /{p = /^## Dials/} p' <keyline>/domains/*/guide.md`.
 
+- **Preset `glass`:** the values come from the tables in each `glass/<domain>/guide.md`, under the project's existing names wherever it has them, not from the whole folder. There is no `glass/patterns/`; patterns take the dials of the preset nearest the reader.
 - **`DESIGN.md` already exists:** this is `/keyline sync`, not a rewrite. Say so and run that instead.
-- **A new project with no interface yet:** there is nothing to scan. Ask what the product is and who reads it, propose a preset, and write `## Profile` with the preset's defaults from each domain guide's `## Dials`, marked as defaults. Generate tokens only if asked (`system/guide.md` §6).
-- **Asked for one domain only** (by another command finding `DESIGN.md` missing): write `## Profile` and that domain's section, and leave the rest for a full run.
+- **A new project with no interface yet:** there is nothing to scan. Ask what the product is and who reads it, propose a preset, and write `## Profile` and each domain's section with the preset's defaults from those `## Dials`, marked as defaults. Generate tokens only if asked (`system/guide.md` §6).
+- **Run for some domains only** (another command found `DESIGN.md` missing): write `## Profile` and those domains' sections, and leave the rest for a full run.
 
 **Report**, briefly: the preset and the evidence for it, how many roles mapped cleanly, which names you proposed, and the three open issues that matter most. Then the next step — usually `/keyline critique` on the main screen, or `/keyline polish` if the user wants changes.
 
-**Changes no code.** Generating tokens is a separate request.
+Generating tokens is a separate request.

package/plugins/keyline/skills/keyline/commands/polish.md

@@ -9,10 +9,10 @@ All six refining commands on one target, in order, each as its own reviewable pa
 1. Read `DESIGN.md`. If it's missing, run `/keyline init` first and say so — polish without a profile is guessing.
 2. Agree the target: one screen, flow or component. "The whole app" is several polishes; offer to start with the screen readers see most.
 3. Run `commands/refine.md` once per domain, in order, reading each domain's guide when its turn comes. Keep each pass to its domain.
-4. **Settle.** Later passes create and change elements the earlier ones never saw — the depth pass turns a callout into a note, and nothing has given the note its type role. Re-run each earlier domain's `## Checklist` on the elements later passes created or changed, and fix within that domain.
+4. **Settle.** Later passes create and change elements the earlier ones never saw — the depth pass turns a callout into a note, and nothing has given the note its type role. Re-run each earlier domain's checklist (`commands/refine.md` step 7) on the elements later passes created or changed, and fix within that domain.
 5. Render the result beside the starting point.
 
-Polish improves the screen it's given; it doesn't move navigation or add features (`commands/refine.md`, the two limits).
+Polish improves the screen it's given; it doesn't move navigation or add features (`commands/refine.md`, the limits).
 
 **Report**, per domain in order: what changed and why, in a line or two each — a domain with nothing to fix says so — then what the settling pass changed. Then what was measured, what went into `DESIGN.md`, and anything left for later with its command.
 

package/plugins/keyline/skills/keyline/commands/refine.md

@@ -2,28 +2,18 @@
 
 `type`, `color`, `layout`, `depth`, `motion` and `patterns` share one procedure. Each command's own file names its guide and what it covers; this is the rest.
 
-1. **Read the domain's `guide.md` in full**, and the references its laws point to for the parts the target touches. Under preset `glass`, read `glass/<domain>/guide.md` too, and take values and components from its `assets/`.
+1. **Read the parts of the domain's `guide.md` a pass uses**, not the whole file: `## Laws`, `## Dials` (the preset's targets, which `DESIGN.md`'s values are judged against), `## Auditing existing code`, `## Writing back to DESIGN.md`, and `## Checklist` if it has one — `awk '/^## /{p = /^## (Laws|Dials|Auditing|Writing back|Checklist)/} p' <keyline>/domains/<domain>/guide.md`. Add `## Building it for a project` only when adding a role or proposing a set for a domain with no tokens (patterns has none; its nearest is `## Iterating on feedback`), read the same way with its heading in the pattern. Then the references its laws point to, for the parts the target touches. Under preset `glass`, read `glass/<domain>/guide.md` too (there is no `glass/patterns/`), and take from its `assets/` only the files that guide's own `## Assets` list names for what you're changing.
 2. **Read the domain's section of `DESIGN.md`** and every `## Decisions` entry it covers. A decision beats a dial; never "fix" a decided value back.
 3. **Find the problems first.** Run `node <keyline>/scripts/check.mjs <target> --root <project root> --rule <domain>` for what can be checked mechanically, then the guide's `## Auditing existing code` on the target only, and list what breaks a law before changing anything. With no target, take the screen the conversation is about; if there isn't one, ask which, or offer the whole project as a longer pass.
-4. **Fix in the project's names**, at the smallest scope that removes the cause — a token over twenty call sites, a shared component over its instances. Add a role only where the guide's `## Building it` says one is missing, in the project's naming style, marked `proposed` in `DESIGN.md`. Where the project has no tokens for the domain at all — no type tokens, no motion tokens — propose a full set in the project's style, each marked `proposed`, and fix against it.
-5. **Stay in the domain.** Something another domain owns — a colour noticed while fixing type — is reported with its owning command, not fixed. The exception: a fix that belongs to an earlier domain in polish order but only became visible in this pass — the note this pass made from a callout now needs its type role — is made here, and reported as that domain's.
-6. **Sweep** every route the changed rule reaches and report what moved (`domains/patterns/iteration.md`).
-7. **Look at it** rendered, before and after, in each theme and at a narrow width; for motion, also with reduced motion on.
-8. **Write back** to `DESIGN.md`: the domain's section if a role or value changed, `## Decisions` for anything moved off the preset (with the user's go-ahead) and for any change a law forced that a later session might undo (marked *law*), and strike fixed `## Open issues`.
-9. **Run the guide's `## Checklist`** on what you changed, and the detector again on the target: nothing you touched should still be flagged.
+4. **Fix in the project's names**, at the smallest scope that removes the cause — a token over twenty call sites, a shared component over its instances. Add a role only where the guide's `## Building it for a project` says one is missing, in the project's naming style, marked `proposed` in `DESIGN.md`. Where the project has no tokens for the domain at all — no type tokens, no motion tokens — propose a full set in the project's style, each marked `proposed`, and fix against it.
+5. **A fix that belongs to an earlier domain** in polish order but only became visible in this pass — the note this pass made from a callout now needs its type role — is made here, and reported as that domain's. Anything else another domain owns is reported with its command.
+6. **Sweep** every route the changed rule reaches and report what moved: `awk '/^## /{p = /^## The sweep/} p' <keyline>/domains/patterns/iteration.md`.
+7. **Check what you changed** against the domain's checklist — each law's bold first sentence, plus anything left under `## Checklist` — and run the detector again on the target: nothing you touched should still be flagged.
 
 **Three limits hold in every pass:**
 
 - **The brief wins over the preset.** An element the product or its brief requires stays, even where a dial or a law would cut it — a dashboard's activity feed, a top bar the product has. The pass changes how it's built, not whether it exists.
 - **Improving is not restructuring.** Improving an existing screen doesn't move its navigation or add features — a collapsible icon rail, a theme toggle, a new view. Those go under `## Open issues` unless the user asks for them.
-- **Improving keeps what the design already chose.** Its brand colour and gradients stay wherever they do a job, and its corners stay at least as round as they were. A dial describes a new system, so an existing design is never greyed or sharpened to fit one. Only a law removes something, and the report names it. When a pass would make the screen plainer than it was, check whether a law actually asked for that.
-
-**Where a preset's default and the existing design disagree**, this is the order, and the one place it is decided:
-
-- **Dividers.** The design's section device stays: panels stay panels, made quieter (layout law 3). The preset's "full-bleed hairline, no tiles" describes a new system. One thing changes either way: a row of stat tiles folds into one strip of figures parted by hairlines, because that is a law about figures, not a divider dial — unless keeping the tiles is recorded under `## Decisions`.
-- **Corners.** The nesting law (layout law 5) never sharpens a corner. Where inner = outer − inset would come out sharper than the inner corner is now, raise the outer radius or trim the inset until they share a centre; if neither fits, the corners aren't concentric and the inner keeps its radius.
-- **Line weight.** The design's line weights stay, like its corners. Product's 0.5px hairline is for a new system, or for an existing line that reads heavy and whose colour is strong enough to survive halving; a border already near the surface colour keeps its 1px.
-
-Record each of these calls under `## Decisions`, so the next run makes the same one.
+- **Improving keeps what the design already chose** (`SKILL.md`). Where a preset's default and the existing design disagree on dividers, corners or line weight, `## Refining an existing design` in the layout guide decides; read it when the pass touches layout or depth: `awk '/^## /{p = /^## Refining an existing design/} p' <keyline>/domains/layout/guide.md`.
 
 **Report:** what was wrong, as a reader would feel it; what changed, by token or component, with the law; what was measured (sizes, ratios, durations); and anything noticed outside the domain, with its command.

package/plugins/keyline/skills/keyline/commands/sync.md

@@ -2,7 +2,7 @@
 
 Bring `DESIGN.md` back in line with code that has moved since it was written. An audit of the file, not a rewrite of it.
 
-**Read:** `system/guide.md` §0, and `system/design-md.md` for the format.
+**Read:** `system/design-md.md` for the format.
 
 **Steps:**
 
@@ -13,5 +13,3 @@ Bring `DESIGN.md` back in line with code that has moved since it was written. An
 5. Propose the edits as a short diff and apply them. Every name the user chose and every `## Decisions` entry survives; a decision the code now contradicts is reported, never silently dropped.
 
 **Report:** what drifted, what's newly fixed, what's newly broken, and anything in `## Decisions` the code no longer follows.
-
-**Changes no code** — only `DESIGN.md`.

package/plugins/keyline/skills/keyline/commands/ux-laws.md

@@ -0,0 +1,26 @@
+# UX laws
+
+The named laws behind what a reader feels, and where Keyline holds each one. `critique` and `audit` cite a name beside a finding only where it explains why the reader feels the problem: the names are reasons, not a checklist. In the table, "step 3 above" is `critique`'s step 3: reading the screen in order.
+
+| UX law | The reader… | Where Keyline holds it |
+|---|---|---|
+| Aesthetic-usability | forgives a polished screen, and overlooks its problems in testing | Here: judge the laws, not the polish — a beautiful screen still gets every check |
+| Hick's law | takes longer to choose as choices grow | patterns law 8 |
+| Fitts's law | hits big, near targets faster | layout law 13 |
+| Jakob's law | expects this product to work like the others they use | patterns law 14 |
+| Miller's law | holds only a few chunks at once | patterns law 8 |
+| Doherty threshold | keeps pace with responses under ≈ 400ms | patterns law 15; motion law 3 |
+| Proximity | groups what sits close | layout law 2 |
+| Similarity | groups what looks alike | patterns law 3; layout law 3 (one style per device) |
+| Common region | groups what shares a boundary | layout law 3 — the quietest boundary that holds, a card last |
+| Visual hierarchy | reads in the order size, weight, colour and position set | type laws 3–4; layout law 2; step 3 above |
+| Progressive disclosure | copes when detail arrives on request | patterns law 8; layout law 11 |
+| Recognition over recall | finds seeing easier than remembering | patterns law 16; patterns law 7 (shortcuts shown where the action lives) |
+| Von Restorff | remembers the one thing that differs | colour law 7; motion law 9; one primary button (patterns law 13) |
+| Peak-end rule | remembers the best or worst moment and the end | patterns law 17 |
+| Goal-gradient | speeds up near the goal | patterns law 17 |
+| Serial position | remembers the first and last items | patterns law 3; primary destinations first in the shell (layout dials) |
+| Tesler's law | shouldn't carry complexity the product can | patterns law 16 |
+| Postel's law | types things in many forms | patterns law 16 |
+| Occam's razor | is served by the fewest parts that do the job | motion law 1; patterns law 12; `commands/refine.md` |
+| Feedback loops | needs to see every action land | patterns law 15 |

package/plugins/keyline/skills/keyline/domains/color/deriving-a-ramp.md

@@ -64,7 +64,7 @@ The brand hue is given; derive the rest per theme. A logo's colour is where the
 1. **`accent` in light.** The highest in-gamut chroma at a lightness where `text.on-accent` clears 4.5:1 — with white text, usually L 0.45–0.55. If the script reports clipping, lower the chroma, not the lightness.
 2. **`accent` in dark.** Either one value, L roughly 0.72–0.78 with chroma trimmed a little, with `text.on-accent` flipped to the dark `surface.page`; or, where the brand keeps white text on its fill, two: the fill near its light-theme lightness, and a lighter `accent.ink` at 4.5:1 on the dark page for links, icons and brand text, since no single value clears both. Measure each as a new colour.
 3. **Its hover.** 0.05 in L away from the page — darker in light, lighter in dark: more contrast in both.
-4. **`surface.selected`.** For a selected row in a dense table, the accent hue at the `surface.selected` lightness, chroma about 0.03. For the current nav item or tab under product and expressive, the stronger tint colour law 7 asks for: the accent at about 25% over its surface, carrying `accent.ink`. Re-measure the *lowest* text tier on each: this fails most often, because a tint costs a little luminance.
+4. **`surface.selected`.** For a selected row in a dense table, the accent hue at the `surface.selected` lightness, chroma about 0.03. For the current nav item or tab under product and expressive, the stronger tint colour law 7 defines, carrying `accent.ink`. Re-measure the *lowest* text tier on each: this fails most often, because a tint costs a little luminance.
 5. **`focus`.** The accent, if it clears 3:1 on every surface including `surface.selected`, and on the page: `outline-offset` leaves a gap of page colour, so a ring round an accent button is seen against the page.
 
 **When the brand colour can't be text.** Yellows, limes and light cyans have no lightness at usable chroma where white text clears 4.5:1, and fail as text on white. Keep them for fills and marks with dark `text.on-accent`, and derive a darker token for anything text-sized — `text.link`, if links are coloured. Name both for their jobs; neither is "brand-yellow".

package/plugins/keyline/skills/keyline/domains/color/guide.md

@@ -4,12 +4,7 @@ A near-monochrome reading site, a dense product with a full status palette and a
 
 ## Before you start
 
-Read `DESIGN.md` at the project root: `## Profile` for the preset and any areas on another one, `## Colour` for the project's name for each role and the decisions already made. Reason in roles; write code in the project's names.
-
-- **No `DESIGN.md`:** run `/keyline init` for this domain only, do the task, then recommend the full setup.
-- **A role you need has no row:** reuse a value already doing that job; otherwise add one in the project's naming style and record it in `DESIGN.md`.
-- **The task would break a law or move a dial off its preset:** say so and ask; if the user confirms, record it with its reason under `## Decisions`.
-- **Preset `glass`:** the values are in `DESIGN.md`; `glass/color/guide.md` has the exact recipes behind them.
+Reads `DESIGN.md` `## Colour`.
 
 ## Laws
 
@@ -32,7 +27,7 @@ The allowed literals:
 
 **A text colour is picked for text contrast, never a mid-ramp step borrowed from the border and fill range.**
 
-Text needs 4.5:1 against its surface; a border or icon a user must see to operate a control, 3:1; a decorative edge, only visibility. One value rarely serves both, least in a *light* theme, where mid steps are light tints on white. The Glass preset shipped this for a whole revision — timestamps at **1.66:1** on the border-hover step, icons at **2.38:1** on border-active, its most-used text colour at **4.12:1** on fill-hover, beside a note claiming "about 4.6:1" — until three new tokens, picked for contrast, went between its two text steps.
+Text needs 4.5:1 against its surface; a border or icon a user must see to operate a control, 3:1; a decorative edge, only visibility. One value rarely serves both, least in a *light* theme, where mid steps are light tints on white: a timestamp borrowing a border-hover step can sit at 1.66:1.
 
 Dark mode hides this — the same indices sit far lighter on near-black, so every mid step passes, and a system reviewed in dark ships a light theme whose body copy fails. So `text.primary`, `text.secondary`, `text.tertiary` and any tiers between are separate tokens. Icons take their label's tier or one below — an icon has more visual mass than text at the same value — and both advance together on hover. Decorative marks with no text (bullets, dots, inactive rail markers) are `mark`, stay on the ramp and aren't held to text contrast; kept faint, a list doesn't read as a column of dark dots.
 
@@ -84,23 +79,17 @@ A status palette is a set of **pairs**, each a foreground at 4.5:1 on the page a
 
 **Every hue has one job, written down. Each chromatic spend beyond the accent and the status palette is named for what it's for, with a reason that can't spread to another element or another job, and contained so that only the mark takes the colour.**
 
-Colour is attention, spent because of what the element *is*, never as decoration. Content looks like everything else the reader came for; only the interface speaking about it — an offer, a warning, a way in — may announce itself. The Glass preset's one exception, a "short version" panel, is the site's only offer, so the reason cannot spread; "it's important", "it's new" or "it's the brand colour" can, and becomes a palette within two components, because every author thinks their element qualifies. That test is for colour being *added*. Colour the design already spends on a job is not on trial (below).
+Colour is attention, spent because of what the element *is*, never as decoration. "It's important", "it's new" or "it's the brand colour" can spread, and becomes a palette within two components, because every author thinks their element qualifies; a reason naming a category of one can't. Only the mark takes the colour, never the text inside. Record each as `exception.<what-it's-for>` in `DESIGN.md`, a family as `exception.<question>.<member>`, with its reason; how many a system holds is a dial. First ask whether weight, position and space can do the job. Most can. That test is for colour being *added*.
 
 **Colour the design already has stays.** When improving an existing interface, its brand colour stays wherever it does a job: the selected nav item, the primary data series, a progress or usage bar, a brand mark, the gradient every avatar shares. Each of those is the owner's decision and part of how the product is recognised. Turning it grey is a regression that no law asks for. Colour comes out only when it breaks a law, and the change cites that law: text under its contrast floor, a second hue competing with the primary action, colour carrying a state on its own, or body text dyed for emphasis. Even then, the first fix is the shade (re-pick it until it passes) rather than taking the colour away. Muting the brand for calm is a dial for a new system, not a fix for an existing one.
 
-**"Too grey" is answered with jobs, not decoration.** Near-monochrome can go too far: a records product built to it came back as "all black and white" from its owner and "wants more colour" from its client within days. What it lacked was hue that answers a question at a glance, one family per question — *what* a thing is (its type), *how* it's doing (status), *where* it lives (its area), *who* (a person). A hue never crosses into another job: a type hue never signals state, and the danger red never marks something that is merely live.
-
-Only the edge, the icon or the glyph takes the colour, never the text inside: a coloured paragraph shares the loudness until it means nothing. Record each as `exception.<what-it's-for>` in `DESIGN.md`, a family as `exception.<question>.<member>`, with its reason: how many a system holds is a dial; a written, non-transferable job is not. First ask whether weight, position and space can do the job. Most can.
-
-**One hue acts, and colour points at what still needs a person.** The accent's jobs — primary action, focus, "your turn" — share one hue, and it marks one action per view. A second highlight hue beside it (a teal next to a blue) splits one meaning in two, and readers start asking which colour means what; whatever wanted it goes to a status pair, a neutral marker or weight. A hue family is not a highlight: it sits on marks and asks nothing of the reader. A place in the data with one member, today's column on a calendar, may be a written exception.
+**One hue acts.** The accent's jobs — primary action, focus, "your turn" — share one hue, and it marks one action per view. A second highlight hue beside it splits one meaning in two; whatever wanted it goes to a status pair, a neutral marker or weight.
 
 **Where the reader *is* takes the accent as a tint, not a fill.** Under product and expressive, the current nav item sits on `surface.selected`: the accent at about 25% over the surface it sits on, with the icon and label in `accent.ink`. Measure that label at 4.5:1 on the tint in each theme, and deepen the ink, not the tint, until it passes. The tint marks a place and the solid fill marks the action, so the selected item and the primary button never read as two calls to act. A page tab marks its current tab with layout law 3's underline instead, in `text.primary`. **This is the one definition of current**: the type guide adds weight to it, the motion guide moves it, neither re-picks it. Editorial and glass keep the current item neutral (a marker, a rule or weight), because a reading page has little chrome and the accent there belongs to focus.
 
-**A chart's primary series takes the accent at full strength:** it is what the screen is about, not a second highlight, so no washed-out opacity or grey bar. Comparison and previous-period series are neutral. Three or more series use the chart palette in `status-and-exceptions.md`. Rising and falling figures on a dashboard may take the success and danger foregrounds, with an arrow or sign beside the figure so the colour isn't the only carrier. Code takes syntax highlighting under every preset: a token palette is a reading aid, not decoration, and it counts against no exception limit.
+**"Too grey" is answered with jobs, not decoration**: one hue family per question the reader can't answer at a glance — what, how, where, who — and no hue crosses into another's job. Whether done takes success colour is a dial; a chart's primary series takes the accent at full strength; code takes syntax highlighting under every preset, counted against no limit.
 
-**Success has one job; whether finishing is that job is a dial.** Ask whether completion is the news. In a sequence the reader passes through — setup steps, passed checks, a wizard — it isn't: under editorial and product, done is an ink check on a neutral circle, because a column of green ticks outshouts the one item still pending, and success is kept for an outcome the reader must notice, approved or released. On a board or list people open to see what got done, it is: done takes `status.success` on a filled check whose shape already says done, while what's late takes warning or danger so the eye still finds what needs a person. Expressive may colour completion per brand, sequences included, counted among its exceptions.
-
-→ Hue families, figures, done states, charts, live and AI marks, destructive rows: `domains/color/status-and-exceptions.md`
+→ The exception test and containment, hue families, figures, done states, charts, live and AI marks, destructive rows: `domains/color/status-and-exceptions.md`
 
 ### 8. A theme is a re-pick, not a reuse
 
@@ -140,7 +129,7 @@ A build-time token (a Sass variable, an inlined JS constant, a static theme obje
 | Chromatic exceptions beyond accent and status | ≤ 1 | None by default; a hue family per question the reader can't answer at a glance (what, where, who), plus one-member exceptions — each listed | ≤ 4, each named |
 | Hues that call for action | 1, the accent | 1, the accent | Brand hues, each placed by rule |
 | Completed states | Uncoloured | `status.success` where completion is the news; uncoloured in a sequence passed through | Uncoloured, or per brand, sequences included, counted among the exceptions |
-| Current location | Uncoloured: a marker, rule or weight | `surface.selected` (accent ≈ 25%) with icon and label in `accent.ink` | As product, or per brand |
+| Current location | Uncoloured: a marker, rule or weight | `surface.selected` (law 7) with icon and label in `accent.ink` | As product, or per brand |
 | Link colour | Text colour, underlined | `accent` | `accent` or a brand hue, underlined in prose |
 | Text tiers, `text.primary` to `text.tertiary` | 3–5 | 3 | 3–4 |
 | Minimum step between adjacent tiers (ratio of ratios) | 1.15× | 1.4× | 1.25× |
@@ -170,7 +159,7 @@ A build-time token (a Sass variable, an inlined JS constant, a static theme obje
 3. **Fix the ends, per theme:** `surface.page` and `text.primary` near-white and near-black in light, the dial's dark lightness and a light grey in dark.
 4. **Place surfaces and lines** (`surface.raised`, `surface.hover`, `surface.pressed`, `surface.subtle`, `border.default`, `border.hover`) as small steps down from the page in light (or `surface.raised` a step up, white on a grey page), up in dark, spaced by contrast against it; what must be seen (an input's edge, an icon, the focus ring) clears 3:1.
 5. **Solve the text tiers from contrast targets** (tertiary at the dial's target, the rest at least the minimum step apart) on each tier's worst surface; verify per theme with `contrast.mjs --ladder`.
-6. **Derive the accent from the brand hue**, per theme: `text.on-accent` at 4.5:1 and `focus` at 3:1 on every surface; then its hover and `surface.selected` tint (about 25% of the accent over the surface; translucent, so it re-tints with the theme), with `accent.ink` at 4.5:1 on that tint, re-measuring the lowest text tier on it too.
+6. **Derive the accent from the brand hue**, per theme: `text.on-accent` at 4.5:1 and `focus` at 3:1 on every surface; then its hover and the `surface.selected` tint (law 7; translucent, so it re-tints with the theme), re-measuring the lowest text tier on it too.
 7. **Status pairs**, if the preset needs them; **exceptions and hue families**, each passing law 7, every mark at 3:1 on its grounds.
 8. **The translucent set**: black at low alpha in light, white in dark, for `border.layered` and any layered washes.
 9. **Write it** as custom properties, one block per theme, with the framework's tokens pointing at them (law 10), and record the ratios in `DESIGN.md`.
@@ -203,41 +192,16 @@ Collect evidence, then measure. The greps assume CSS, Tailwind or CSS-in-JS; ada
 
 Then measure, in every theme: each text tier on its worst surface (`contrast.mjs --ladder`), the focus colour at `--min 3` on every surface it can land on, each status foreground on the page and its tint.
 
-Report each finding as one line in `DESIGN.md` `## Open issues`, with evidence — a ratio, a count, a file: "`text.tertiary` (`--ink-3`) is 4.21:1 on `surface.hover` in light — fails 4.5:1. Used in 22 files." Don't fix what wasn't asked for.
-
 ## Writing back to DESIGN.md
 
 - **The ratios.** Every text tier and the focus colour, per theme, with the surface measured on; re-measure when a value in `## Colour` changes.
 - **New roles.** Any you added — a missing `surface.selected`, a tier between secondary and tertiary — in the project's naming style, marked `proposed` until accepted.
 - **Exceptions.** Each `exception.<name>` under **Exceptions**: what it's for, and why that reason can't spread; a family with its question, its members and the marks it may take.
-- **Moved dials.** Under `## Decisions`, dated, with the reason: "Links in `accent`, not text colour: the docs area is navigation-heavy and readers scan for links."
-- **Open issues.** As in the audit; remove the line once fixed.
 
 ## Checklist
 
-- [ ] Every colour is a job-named token; literals only in artwork and shared multi-layer constants.
-- [ ] Components use roles (`accent`, its hover, `surface.selected`), not brand-hue steps.
-- [ ] `text.primary` through `text.tertiary` are their own tokens, never border or fill steps.
-- [ ] Every tier clears 4.5:1 on its worst surface, per theme, computed with `contrast.mjs`.
-- [ ] The text ladder strictly descends in every theme.
-- [ ] Icons take their label's tier or one below; `mark` is only for decoration without text.
 - [ ] Control edges and icons that must be seen clear 3:1.
-- [ ] Anything layered is translucent (`border.layered` and kin), inverting per theme.
-- [ ] `focus` clears 3:1 on every surface it can land on, uses `:focus-visible` with an offset, never sits beside its own colour.
-- [ ] No state or status is signalled by colour alone.
 - [ ] Each `status.*` is a fg/bg pair per theme, fg at 4.5:1 on the page and its tint.
-- [ ] Each `exception.<name>` has a written reason no other element shares; only its mark is coloured.
-- [ ] Each hue family answers one question (what, how, where, who) and never another's.
-- [ ] One hue calls for action; the reader's current location follows the dial (the accent tint under product and expressive, uncoloured under editorial); done is coloured only where the dial says completion is the news.
-- [ ] Accents, status pairs, exceptions and family hues are re-picked per theme; every gradient stop moves; marks clear 3:1 on every ground.
-- [ ] Dark `surface.page` and light `text.primary` are near-black, not `#000`.
-- [ ] With a toggle, the theme is a root attribute or class set by a blocking inline script before the stylesheet.
-- [ ] `color-scheme` is declared in every theme.
-- [ ] Context-dependent and multi-layer values are runtime custom properties; preference overrides follow every theme block.
+- [ ] Dark `surface.page` and light `text.primary` are near-black, not `#000`; `color-scheme` is declared in every theme.
 - [ ] Every brand colour and gradient the original spent on a job is still there, or the law that removed it is named.
-- [ ] Product and expressive: the current nav item is on the accent tint, with its label at 4.5:1 in `accent.ink`; the primary chart series is the accent at full strength.
-- [ ] Dial check: palette, accent's jobs and link colour match the preset.
-- [ ] Dial check: exception count and done colour match the preset.
-- [ ] Dial check: tier count, minimum step and tertiary target match the preset.
-- [ ] Dial check: status palette present if the preset requires it.
-- [ ] Dial check: theme control and dark page lightness match, or `## Decisions` says why not.
+- [ ] Product and expressive: the current nav item's label clears 4.5:1 in `accent.ink` on its tint; the primary chart series is the accent at full strength.

package/plugins/keyline/skills/keyline/domains/color/status-and-exceptions.md

@@ -84,7 +84,7 @@ input[aria-invalid="true"] { border-color: var(--status-danger-fg); }
 .field-error svg { color: var(--status-danger-fg); }    /* only the mark takes the colour */
 ```
 
-The neutral case: a contents rail moving the current label from `text.secondary` to `text.primary` — 7.7:1 to 15:1, clear in a table, nearly invisible in daylight, to low vision, or mid-scroll. A 2px rule or marker at the edge carries the state; the colour change reinforces it.
+The neutral case, a current label one grey tier darker, needs a rule or marker too (colour law 6).
 
 A ring that fills as work moves is legible in greyscale, so its colour only confirms what the shape says; that is what lets a product colour done without colour carrying it.
 
@@ -99,7 +99,7 @@ Law 7's dial, decided by whether completion is the news:
 | A long list of ticked checkboxes | A light grey box with an ink tick | An inverted ink or accent block per tick shouts down a long list; the tick's shape carries the state |
 | A switch | Its strong fill, on | A switch has no tick, so the fill is the state |
 
-The second row reverses the first on purpose: it is what the "too grey" product in law 7 changed on its boards. Record which lists take which row under `## Decisions`, so the next audit doesn't "fix" one into the other. Under `expressive`, completion may take a brand colour in any row, counted among its exceptions.
+The second row reverses the first on purpose. Record which lists take which row under `## Decisions`, so the next audit doesn't "fix" one into the other. Under `expressive`, completion may take a brand colour in any row, counted among its exceptions.
 
 Where the reader *is* in the interface (the current nav item or tab) takes the accent tint under product and expressive and stays neutral under editorial and glass (colour law 7). A place in the data with one member is different: on a calendar board, today's column may take a filled `accent` with `text.on-accent`, the one time the brand marks a place rather than an action. Record it as `exception.today`; it doesn't make a second.
 

package/plugins/keyline/skills/keyline/domains/depth/elevation-recipes.md

@@ -53,13 +53,7 @@ inset highlight  inset 0 1px 0 white at h       (optional, per preset)
 
 ## Per preset
 
-Light-theme floating shadows at the dial strengths; raised and overlay follow from the `Y` values above.
-
-| Preset | Floating recipe (light) |
-|---|---|
-| `editorial` | `inset 0 1px 0 rgb(255 255 255 / 0.5), 0 1px 1px rgb(0 0 0 / 0.02), 0 8px 16px -4px rgb(0 0 0 / 0.04), 0 24px 32px -8px rgb(0 0 0 / 0.06)` |
-| `product` | `0 1px 1px rgb(0 0 0 / 0.04), 0 12px 24px -8px rgb(0 0 0 / 0.10)` — edges carry the rest |
-| `expressive` | `inset 0 1px 0 rgb(255 255 255 / 0.6), 0 1px 2px rgb(0 0 0 / 0.06), 0 10px 20px -6px rgb(0 0 0 / 0.10), 0 32px 48px -12px rgb(0 0 0 / 0.16)` |
+Each preset's layers and peak opacity are the depth dials, built by the proportions above: editorial's floating shadow is the example, product's is the ring edge below.
 
 Product leans on `border.default` with short shadows, so dense screens don't fill with grey, and draws that edge as a ring inside the shadow on cards, menus and dialogs alike (below). Expressive may add one decorative level — a branded pocket, a hero card — named, with its own bundle.
 
@@ -114,7 +108,7 @@ A card animating by transform, as in a reordering stack, can't change its border
 }
 ```
 
-Half a pixel is one device pixel on a 2x screen and rounds to a faint 1px on 1x, which is the point — quieter than any border — and why the contrast preference gets a real one. Forced colours paints the transparent border.
+Half a pixel is one device pixel on a 2x screen; a shadow's spread doesn't snap to the pixel the way a border does, so on 1x it antialiases to a faint line, which is the point — quieter than any border — and why the contrast preference gets a real one. Forced colours paints the transparent border.
 
 ## Moving between levels