@nurix/etna 0.20.36 → 0.20.38

package/data/harnesses/code/skills/design/references/intake.md

@@ -2,19 +2,19 @@
 
 Read the brief and choose from the menus: one identity package (the design.md system), any axis overrides the brief demands, layout blueprints per surface, and the product domain for content. Every choice is one recorded line.
 
-**Returning workspace first.** If the repo carries a `workspaceId` (or the NuStack context supplies one), open with `get_preferences`: the workspace's `design.md`, `taste.md`, and `product.md` rows are the session's context — then run the drift check (compare the repo's fork — `node scripts/validate-design-md.mjs --project .` resolves its one path from the repo shape and fails closed on a copy anywhere else — against the server row; on mismatch, tell the user which is newer and ask). A workspace with a recorded identity re-enters the steps with that identity already chosen; the rules below are for first intake.
+**Returning workspace first.** If the repo carries a `workspaceId` (or the NuStack context supplies one), open with `get_preferences`: the workspace's `design.md`, `taste.md`, and `product.md` rows are the session's context. Then run the drift check — compare the repo's fork (the path `node scripts/validate-design-md.mjs --project .` resolves) against the server row; on mismatch, tell the user which is newer and ask. A workspace with a recorded identity re-enters the steps with that identity already chosen; the rules below are for first intake.
 
 ## Rules
 
 - **The brief's own words outrank any database default.** "Beautiful" means the ceiling, not the safe row.
 - **Adjectives become referents.** When the brief speaks in adjectives ("premium", "editorial"), name the 2–3 real products the brief is pointing at and pick the package whose recorded identity sits in that class — unnamed ambition becomes beige.
-- **Search is a retrieval aid, never a router.** `search_catalog` (family `design_md`) with the brief's segment/keyword resemblance; shortlist 2–3 results by their head metadata (feel, reads-as, keywords), then choose reading the brief. After the choice, `get_entry` **once**: the chosen package's full design.md enters context and **stays in view through step 4**; unchosen candidates are never fetched.
-- **The escape hatch fires mechanically.** No catalog hit, plus a recorded one-line reason why the closest package fails → author a one-off project design.md in the package schema, `tier: project`, at the path `--project .` resolves — the validator is the schema authority and checks it like any library entry. This path is expected to be common; flag the file as a curation candidate for the roster.
-- **Record the identity.** First intake ends with `record`: the identity choice as a decision line, and the resolved fork pushed as the workspace's `design.md` preference row. The `workspaceId` is committed to the repo if it is not ambient. Design taste is workspace-level — an app never gets its own.
+- **Search is a retrieval aid, never a router.** `search_catalog` (family `design_md`) with the brief's segment/keyword resemblance; shortlist 2–3 results by their head metadata (feel, reads-as, keywords), then choose by reading the brief. After the choice, `get_entry` **once**: the chosen package's full design.md enters context and **stays in view through step 4**; unchosen candidates are never fetched.
+- **The escape hatch fires mechanically.** No catalog hit, plus a recorded one-line reason why the closest package fails → author a one-off project design.md in the package schema, `tier: project`, at the path `--project .` resolves — the validator is the schema authority and checks it like any library entry. Expect this path to be common; flag the file as a curation candidate for the roster.
+- **Record the identity.** First intake ends with `record`: the identity choice as a decision line, and the resolved fork pushed as the workspace's `design.md` preference row. Commit the `workspaceId` to the repo if it is not ambient. Design taste is workspace-level — an app **never** gets its own.
 - **Axis overrides fetch or read the single named entry** — color/font/gradient/chart-style overrides `get_entry` their dictionary entry; elevation/motion/iconography overrides read the named local entry under `data/`.
 - **Set the primitives switch** — write one `primitives: nurix | native` line into the project's `design.md` (the path `--project .` resolves; first intake creates the file there). Default by the probe: the project resolves `@nurix/components` (check package.json / lockfile / node_modules) → `nurix`; otherwise — existing apps, foreign stacks, no library access — → `native`. Set once here; nothing downstream re-asks. Also write `source-package: <slug>` (or `authored` for escape-hatch one-offs).
 - **Write or update `product.md`**: users and their jobs, roles/permissions, action frequency, risk level, accessibility commitments, brand anti-references. Package choice, UX decisions, motion intensity, and demo data all cite it. Push it as a preference row too — Studio shows it.
-- **The taste profile biases every choice** — `get_preferences` returns the workspace's `taste.md` (per-dimension feel/avoid lines); user reactions to shipped output update it via `record`. No profile yet = no bias, never a block.
+- **The taste profile biases every choice** — `get_preferences` returns the workspace's `taste.md` (per-dimension feel/avoid lines); user reactions to shipped output update it via `record`. No profile = no bias, **never** a block.
 - **Stated-choice awareness:** if prior package picks are visible in the workspace, name them and say in one line why this pick repeats or differs — awareness, never forced rotation.
 - **Questions go to the user only when the answer changes the design** (theme, audience, density); everything else is inferred and marked inferred.
 
@@ -29,7 +29,7 @@ Step 1 ends with a preview block:
 - domain corpus
 - surface map with archetypes
 - planned deviations
-- the personality traits (under `nurix`): the six-trait reading of §4–§7 — density, pace, edge, depth, texture, tone — naming only what differs from neutral, written into the design-values block so the library compiles it
+- the personality traits (under `nurix`): the six-trait reading of §4–§7 — density, pace, edge, depth, texture, accent — naming only what differs from neutral, written into the design-values block so the library compiles it
 
 When a user is present, pause here **once** for confirm-or-redirect — a wrong pick costs one message now instead of a full build. Autonomous runs proceed. Either way the block goes to workspace memory — `record` it as decision lines heading this run's choices, with the app as context.
 

package/data/harnesses/code/skills/design/references/object-pass.md

@@ -12,7 +12,7 @@ Derive the object model and surface map using the UX-pattern decision layer (`re
 8. `container-choice` — container by workflow (duration, interruption, comparison need), never by size
 9. `creation-paths` — form, import, conversion, clone, recurrence
 10. `table-mechanics` — where tables project a surface
-11. `state-matrix` — loading, the three empties (first-use, no-results, cleared), degraded, stale — per surface
+11. `state-matrix` — loading, the three empties (first-run, filtered-to-zero, failed-to-load), a queue's cleared-empty, degraded, stale — per surface
 12. `standard-pages` / `ai-layer` / `dashboards` / `settings` — when the brief has them
 
 Each pass file carries its rule as prose plus its machine-readable decision table; **follow the table's answer**. Disagreement is legitimate craft only when recorded — one `record` line naming the pass, the table's answer, yours, and why. An unrecorded divergence is the violation.

package/data/harnesses/code/skills/design/references/ship-gate.md

@@ -1,10 +1,10 @@
 # Step 5 — The ship gate
 
-The project ships with its project-local artifacts — `design.md` (the resolved fork, with provenance line, brief bindings, recorded deviations), its derived `design.tokens.css`, and `product.md` — and its memory server-side. The gate has two tiers, both objective: this is the only runtime check the skill performs, permitted precisely because it is automated and needs no judgment. Nothing here grades taste — anything that needs grading was the build-time harness's burden, not the run's.
+The project ships with its project-local artifacts — `design.md` (the resolved fork, with provenance line, brief bindings, recorded deviations), its derived `design.tokens.css`, and `product.md` — and its memory server-side. The gate has two tiers, both objective — the only runtime check the skill performs, because it needs no judgment. Nothing here grades taste; grading is the build-time harness's burden, not the run's.
 
 ## Tier 1 — fails closed
 
-Every check a binary predicate. Run the validator (`node scripts/validate-design-md.mjs --project . --mode ship`) plus the build itself; all of these must hold:
+Every check is a binary predicate. Run the validator (`node scripts/validate-design-md.mjs --project . --mode ship`) plus the build itself; all of these must hold:
 
 - **No placeholder text or scaffold stubs** anywhere (lorem, TODO, "Coming soon", empty `href="#"` walls).
 - **Data plausibility** against the corpus's declared invariants: aggregates reconcile with their visible rows; legal ranges hold; no degenerate repetition in visible rows (surname clusters, identical amounts).
@@ -18,10 +18,10 @@ Every check a binary predicate. Run the validator (`node scripts/validate-design
   - the emitted CSS actually compiles;
   - charts and status surfaces consume the package's tokens (a dark dashboard with hardcoded light charts fails here).
 - **The library reach checks** (`primitives: nurix`):
-  - `personality.css` recompiles from the design.md's personality block to a byte-match (the validator's `dmv-12`); a design.md with no block fails nothing, and its `dmw-05` warn appears in the ship report;
+  - `personality.css` recompiles from the design.md's personality block to a byte-match (the validator's `dmv-12`); a design.md with no block fails nothing, and its `dmw-09` warn appears in the ship report;
   - no `data-theme` selector or attribute in app CSS or HTML — the theme is the `.dark` class;
   - no `duration-<n>` utility, no `transition-all`, and no literal `ms` inside a transition or animation declaration in app code — the seam carries timing;
-  - no `<time` element outside `<Timestamp>`; no `truncate` or `line-clamp-` utility (the `clip` family replaces them);
+  - no `<time` element outside `<Timestamp>`; no `truncate` or `line-clamp-` utility (use the `clip` family);
   - every interactive element under 24px in either rendered dimension carries a `hit-area` utility.
 
 A Tier-1 failure blocks the ship; fix and re-run. Binary phrasing is the contract — anything that would need "use sparingly" grading does not belong in this tier.
@@ -32,4 +32,4 @@ Sweep `data/tells.csv` (the operator tell list), at this step only, plus the mot
 
 ## The ship report
 
-Close the run with a compact report: surfaces shipped, the recorded choices, Tier-1 results, every Tier-2 flag with its disposition, and the validator's warn list. No scores, no self-grades. Write it to memory — `record` with `report: { kind: "gate", summary }` — and, if the run's surviving edits changed the project's `design.md`, push the new text in the same `record` so the server canonical stays current.
+Close the run with a compact report: surfaces shipped, the recorded choices, Tier-1 results, every Tier-2 flag with its disposition, and the validator's warn list. No scores, no self-grades. Write it to memory — `record` with `report: { kind: "gate", summary }` — and, if the run's surviving edits changed the project's `design.md`, push the new text in the same `record` so the server canonical matches.

package/data/harnesses/code/skills/design/references/ux-patterns/Readme.md

@@ -5,15 +5,15 @@ sourced: 2026-07-12
 source: "b2b-ux-patterns playbook (16 chapters) — distilled"
 license: open
 ---
-# B2 — the B2B UX-pattern decision layer
+# The B2B UX-pattern decision layer
 
-What-to-use-when for every structural UI decision, distilled from the ratified 16-chapter B2B UX playbook. **One decision file per pass**, each carrying its rule twice in one body: prose for the model, then an embedded machine-readable `json decision-table` that is the executable core — the contract runner ([`../../../../evals/design/run-decision-contracts.mjs`](../../../../evals/design/run-decision-contracts.mjs)) parses and evaluates these tables directly, so the tested rule and the followed rule are the same bytes.
+What-to-use-when for every structural UI decision, distilled from the ratified 16-chapter B2B UX playbook. **One decision file per pass**, each carrying its rule twice in one body: prose for the model, then an embedded machine-readable `json decision-table` that is the executable core. The skill's contract tests evaluate these tables directly, so the table is the rule as tested — where prose and table seem to differ, follow the table.
 
 The pinned **seven-archetype roster** every pass conforms to: `browse`, `queue`, `grid`, `record-detail`, `dashboard`, `creation-flow`, `settings`. View-types (table, board, cards, calendar, timeline, map) are **projections** of an archetype, never archetypes themselves.
 
 ## The 15 passes
 
-Run each at the step of the method that needs it — the order below is the method's order.
+Run each at the step of the method that needs it, in the order below.
 
 | # | Pass | Source | Owns |
 | --- | --- | --- | --- |
@@ -192,4 +192,4 @@ Every `when` key used across the 15 passes, with its legal values. **Any key may
 
 ## The load rule
 
-**One pass file per step, never all at once.** The load contract ([09 §Load contracts](../../../../docs/features/design-skill/09-database-structures.md)) is explicit: B2 enters context as *the one pass file the current step needs*; loading all passes at once is forbidden. Consult this Readme to route to the right file, then load only that file at the step that needs it. Clarification codes are surfaced, never guessed around — a `then.clarifications` firing means an input the pass needs is missing, and the step pauses to obtain it rather than proceeding on a default.
+**One pass file per step, never all at once** (the `SKILL.md` load contract). Route through this Readme, then load only the pass file the current step needs. **Never** guess around a clarification code — a `then.clarifications` firing means an input the pass needs is missing; pause the step to obtain it (infer-and-mark when the answer does not change the design, ask when it does) rather than proceed on a default.

package/data/harnesses/code/skills/design/references/ux-patterns/ai-layer.md

@@ -21,7 +21,7 @@ license: open
 
 **Guardrails are one orthogonal layer, factored once.** *Prevention*: confidence gating with a numeric threshold where the domain is mature (high-confidence posts through, sub-threshold queues for review); **statistical-significance gating** where the system corrects a human or third-party claim (never assert on a small sample — the reputation guardrail, and the home of the house-knowledge corrective); simulation/eval gating before an agent version deploys. *Recovery*: the undo/rollback backstop under every agent action; the **escalation floor** — no serious autonomous agent ships without a mandatory hand-to-human boundary, and the handoff carries what was already tried so the human resumes mid-stream. *Glass box*: citations, the source anchor stored beside every transduced value, and the **AI-action audit log as a surface distinct from record edit history** (actor = AI, what changed, and what data informed it).
 
-**The agent is a governed actor and the checkpoint is how the flow waits.** An agent principal gets its own identity in the directory, scoped least-privilege permissions, a human sponsor, and a lifecycle — never a borrowed human credential; its effective access is the intersection of its grants and its delegating subject's (see viewer-context). The **durable checkpoint** (axiom 21) — pause, persist, notify, resume — is the portable guardrail node: decision rights choose *when* the human enters; the checkpoint is *how* the flow waits, with state persisting across days and the notification carrying the evidence pack. Design against this primitive, not against inline blocking prompts. Chat is the **home surface** when its output is inspectable and reversible (conversational BI — expose the compiled query as the escape to determinism) and the **escape hatch** when output is externally committing (the human ratifies). Accumulated memory (system-auto-written, cross-session) is audited after and demands its own management surface and memory-provenance show-which. When an AI capability writes but its blast radius is undeclared, the decision-rights stance cannot be set: clarify.
+**The agent is a governed actor and the checkpoint is how the flow waits.** An agent principal gets its own identity in the directory, scoped least-privilege permissions, a human sponsor, and a lifecycle — never a borrowed human credential; its effective access is the intersection of its grants and its delegating subject's (see viewer-context). The **durable checkpoint** — pause, persist, notify, resume — is the portable guardrail node: decision rights choose *when* the human enters; the checkpoint is *how* the flow waits, with state persisting across days and the notification carrying the evidence pack. Design against this primitive, not against inline blocking prompts. Chat is the **home surface** when its output is inspectable and reversible (conversational BI — expose the compiled query as the escape to determinism) and the **escape hatch** when output is externally committing (the human ratifies). Accumulated memory (system-auto-written, cross-session) is audited after and demands its own management surface and memory-provenance show-which. When an AI capability writes but its blast radius is undeclared, the decision-rights stance cannot be set: clarify.
 
 ```json decision-table
 {"pass": "ai-layer", "rows": [

package/data/harnesses/code/skills/design/references/ux-patterns/container-choice.md

@@ -17,7 +17,7 @@ license: open
 
 **Body organization forks two ways.** *Tabs* (lazy-loaded, per-section linkable) when sections are large, independently loaded, and rarely needed together — the record is "several pages sharing a header." *Single-scroll with a sticky anchor rail* when the job needs cross-section skimming in one pass and sections are modest. Objects worked in long sessions over a streaming main column (conversation, timeline) earn a persistent **360 / context rail** — the parent summary and key attributes stay put while the narrative moves; the rail is denormalization-for-display doing its job.
 
-**The container ladder — `hovercard → inline-popover → center-modal → side-peek → full-page`.** Information size does not pick the rung; five workflow axes do, size only breaks ties. (1) **Context retention** — if the originating list must stay live behind the opened record (open, close, open the next, compare), it is a **side peek**, however small the record; a modal dims and blocks the hub, a peek keeps it alive. (2) **Read-vs-edit depth** — a quick read wants a peek; deep, multi-field, interdependent editing wants center focus or a full page, because accidental dismissal becomes expensive. (3) **Shareability** — a record that needs a stable, shareable URL can now live in a URL-addressable peek or split pane; a record **sent outward** (an invoice) still defaults to a **full page** despite tiny size. (4) **Traversal** — processing or comparing many records in a row needs next/prev through the *exact filtered, sorted set*, which means a peek or split pane, never a modal and never a full-page round-trip per record. (5) **Interruption** — a center modal *blocks* (correct for confirmations and irreversible commits); a peek *continues* (work proceeds around it). Size is the tiebreaker only when the axes are indifferent: a leaf datum in a popover, a modest record in a peek.
+**The container ladder — `hovercard → inline-popover → center-modal → side-peek → full-page`.** Information size does not pick the rung; five workflow axes do, size only breaks ties. (1) **Context retention** — if the originating list must stay live behind the opened record (open, close, open the next, compare), it is a **side peek**, however small the record; a modal dims and blocks the hub, a peek keeps it alive. (2) **Read-vs-edit depth** — a quick read wants a peek; deep, multi-field, interdependent editing wants center focus or a full page, because accidental dismissal becomes expensive. (3) **Shareability** — a record that needs a stable, shareable URL can live in a URL-addressable peek or split pane; a record **sent outward** (an invoice) defaults to a **full page** despite tiny size. (4) **Traversal** — processing or comparing many records in a row needs next/prev through the *exact filtered, sorted set*, which means a peek or split pane, never a modal and never a full-page round-trip per record. (5) **Interruption** — a center modal *blocks* (correct for confirmations and irreversible commits); a peek *continues* (work proceeds around it). Size is the tiebreaker only when the axes are indifferent: a leaf datum in a popover, a modest record in a peek.
 
 **Container requirements.** Every peek and modal carries an **"open as full page"** escape hatch — users promote up the ladder themselves, so picking the lighter rung costs one click. Closing a peek or modal honors the **return contract**: the originating surface restores *exactly as left* — same scroll, filters, selection. The same object opens at the same rung from the same kind of origin, product-wide — container choice is per-object-per-origin, not per-screen improvisation. When a record must open but no workflow axis is declared, the rung cannot be chosen from size alone: clarify.
 

package/data/harnesses/code/skills/design/references/ux-patterns/dashboards.md

@@ -21,7 +21,7 @@ license: open
 
 **Dashboards are where three lifecycle declarations become visible.** Trend tiles are the UI output of the **Sampled** history class — a field declared Overwrite has no trend to show, and an empty trend tile is a history-class declaration failure, not a chart bug. **Freshness is mandatory** — every tile group carries "updated N minutes ago" and degraded tiles fail individually, so one dead query never blanks the board. **Targets and thresholds are config objects** — owned, versioned, auditable — not constants buried in tile definitions. The whole surface renders f(data, viewer): a scope switcher (me / my team / org) rather than separate dashboards per rung, tiles gated by role and plan.
 
-**Promotion follows frequency × criticality, not habit** — dashboards go high for managers and low for operators, whose landing surface is the queue or index with the glance strip at most zoned above it; defaulting every sidebar item to a dashboard is the dashboard-first fallacy. The 2026 push inversion turns the monitoring dashboard from the ritually-visited wall into the drill-down destination behind a pushed digest — design the digest → dashboard → door → records chain unbroken, and ship auto-narration only behind the significance gate. A monitoring tile with no declared threshold cannot render a state: clarify. A trend tile over an Overwrite field has no trend to show: clarify.
+**Promotion follows frequency × criticality, not habit** — dashboards go high for managers and low for operators, whose landing surface is the queue or index with the glance strip at most zoned above it; defaulting every sidebar item to a dashboard is the dashboard-first fallacy. Under the push inversion, the monitoring dashboard is the drill-down destination behind a pushed digest, not a ritually-visited wall — design the digest → dashboard → door → records chain unbroken, and ship auto-narration only behind the significance gate. A monitoring tile with no declared threshold cannot render a state: clarify. A trend tile over an Overwrite field has no trend to show: clarify.
 
 ```json decision-table
 {"pass": "dashboards", "rows": [

package/data/harnesses/code/skills/design/references/ux-patterns/modes.md

@@ -15,7 +15,7 @@ license: open
 
 A mode is a behaviorally distinct way of using the product; it earns a place only if it demands different UI — different layout, affordances, success metric. **Modes are not persona traits:** the same user on the same data switches modes hour to hour (monitoring at 9:00, triage at 9:15, procedural until lunch, an exception at 2:00, approvals at 4:00). Never map persona → mode and design one surface per persona; inventory which modes each role enters per dataset and let one dataset serve several modes — a leads list must support monitoring (stat glance), triage (route verbs, bulk bar), and batch mutation (grid selection) without becoming three pages.
 
-**Mode selects archetype — not the object.** When a screen feels wrong despite showing the right object, the usual cause is a mode mismatch: an index built for browsing handed to a team that triages, or a settings *page* given to what is actually a configuration *mode* needing preview and rollback. Distinctions the table encodes: investigation has a fixed question (timeline, trail, drill); exploration has none yet (pivot, segment — the question is the output). Triage routes without resolving; procedural resolves and takes the next. Approval judges someone else's finished output; supervision (the fastest-growing mode of 2025–26) steers an autonomous worker mid-flight — pause, redirect, resume — and is neither monitoring (no intervention), approval (finished artifact), nor exception handling (single-user improvisation after the playbook fails). Exception handling is exactly where UX quality matters most, because the designed flows have run out.
+**Mode selects archetype — not the object.** When a screen feels wrong despite showing the right object, the usual cause is a mode mismatch: an index built for browsing handed to a team that triages, or a settings *page* given to what is actually a configuration *mode* needing preview and rollback. Distinctions the table encodes: investigation has a fixed question (timeline, trail, drill); exploration has none yet (pivot, segment — the question is the output). Triage routes without resolving; procedural resolves and takes the next. Approval judges someone else's finished output; supervision steers an autonomous worker mid-flight — pause, redirect, resume — and is neither monitoring (no intervention), approval (finished artifact), nor exception handling (single-user improvisation after the playbook fails). Exception handling is exactly where UX quality matters most, because the designed flows have run out.
 
 Richer surface forms noted in `page-archetype` (conversational inbox, split-pane console, canvas builder, report builder, wizard, log explorer, merge/diff views) are realizations of these roster mappings, not extra archetypes.
 

package/data/harnesses/code/skills/design/references/ux-patterns/object-model.md

@@ -24,11 +24,11 @@ Cardinality deterministically dictates UI treatment — never information size.
 
 **Composite / line-item children** (invoice + line items, form + questions) are meaningless alone and edited atomically with the parent: master-detail *form* treatment — an editable grid inside the parent's create/edit surface, saved as one unit. Giving line items related-tab navigation produces absurd flows (navigate away from an unsaved invoice to create its second line).
 
-**Denormalization is an explicit pass:** for every relationship ask "which fields from the other side must appear here without a click?" — parent identity fields on child rows (lookups), child aggregates on parents (rollups). Skipping it is why v1 tables show bare foreign-key names.
+**Denormalization is an explicit pass:** for every relationship ask "which fields from the other side must appear here without a click?" — parent identity fields on child rows (lookups), child aggregates on parents (rollups). Skipping it leaves tables showing bare foreign-key names.
 
 **Users are objects in the model.** There is no separate collaboration layer: ownership, assignment, watching, comments, @mentions, and read/unread are ordinary relationships between User and record. The test of a complete chart: three people touch every record — the model must say who owns it, who watches it, who said what, who has seen it. The User object carries `actor ∈ {human, agent}`; agents are Users, but the fork must be declared because assignment, delegation, audit origin, and access all branch on it.
 
-Consult this file once per relationship decision; if cardinality is not yet known, clarify before assigning any treatment.
+Consult this file once per relationship decision; if cardinality is unknown, clarify before assigning any treatment.
 
 ```json decision-table
 {"pass": "object-model", "rows": [

package/data/harnesses/code/skills/design/references/ux-patterns/promotion-demotion.md

@@ -15,7 +15,7 @@ license: open
 
 **Prominence = frequency × criticality, computed per role. Parenthood is not the driver.** Parent/child position in the schema is a data-integrity fact; it says nothing about how often a human opens the object. The canonical counterexample: in a CRM, Account is the parent of Leads, Contacts, and Opportunities — and it is demoted; reps live in Leads, Opportunities, and Tasks. If you find yourself promoting an object because "it's the parent," ask instead who opens it, how often, and what breaks if they can't — that answer sets the sidebar. Without a frequency reading per role, prominence cannot be computed: clarify.
 
-**Prominence is per persona × plan.** An object demoted for a rep is promoted for the ops admin who lives in it; the same schema yields different sidebars per role. Plan-gated items change what each tenant's sidebar contains (whether locked items render hidden or as upsell is `viewer-context`'s call). Agents and agent surfaces now compete for promoted slots like any object.
+**Prominence is per persona × plan.** An object demoted for a rep is promoted for the ops admin who lives in it; the same schema yields different sidebars per role. Plan-gated items change what each tenant's sidebar contains (whether locked items render hidden or as upsell is `viewer-context`'s call). Agents and agent surfaces compete for promoted slots like any object.
 
 **The demotion contract** — demotion is only safe when two guarantees hold, or it punishes users:
 1. **Creatable in context** — every demoted object is creatable from inside the flows of promoted objects that reference it (nested create-in-context: "+ New Account" inside the Lead form). If a rep must abandon a half-filled form to create the parent first, the demotion has failed.

package/data/harnesses/code/skills/design/references/ux-patterns/settings.md

@@ -21,7 +21,7 @@ license: open
 
 **Risk class dictates the interaction tier.** *Preferences* (personal, reversible, instant): autosave silently, no confirm — friction here is pure tax. *Behavior config* (affects others, reversible): explicit save plus a changelog entry, and the setting's own Logged history answers "who changed this and when." *Structural & destructive* (schema changes, role edits, SSO, retention, deletion): the full ceremony — **draft → impact preview → publish**, where the impact preview is the load-bearing step ("this role change affects 34 users"; "changing this field type will truncate 1,204 values"); add maker-checker where policy demands, isolate the irreversible in a type-to-confirm **danger zone**, and log everything to the org audit trail. Tier-3 changes deserve the test-before-live discipline of the AI layer's agent CI (simulate the rule against yesterday's traffic before publishing).
 
-**The inheritance cascade — the most underserved settings pattern.** Any setting existing at more than one scope forms a cascade (org default → team override → user override), and the UI must solve the resolved-value problem: show the **effective value** the viewer gets, show **where it came from** ("inherited from Organization" vs "overridden here"), and offer **reset to inherit** as a first-class action distinct from "set to the same value." Once a cascade exists, impersonation/view-as is the only honest debugger. **Findability**: settings search is mandatory past ~30 nodes (admins remember words, not the tree), every setting has a stable deep link, and the in-context gear links bidirectionally between a governed surface and the setting that governs it. **The AI subjects (2026)**: build-time generation compiles NL to an inspectable artifact editable before commit — never a black box; the agent governance console (identities, model-routing, data masking, permission scoping, the AI-action audit view) is a new org-scope subject. Anti-patterns forbidden: the junk drawer, features hiding in settings (saved views, dashboards, templates are product surfaces, not settings), modal settings, and the invisible cascade. A settings page whose scope is undeclared cannot be placed or permissioned: clarify.
+**The inheritance cascade — the most underserved settings pattern.** Any setting existing at more than one scope forms a cascade (org default → team override → user override), and the UI must solve the resolved-value problem: show the **effective value** the viewer gets, show **where it came from** ("inherited from Organization" vs "overridden here"), and offer **reset to inherit** as a first-class action distinct from "set to the same value." Once a cascade exists, impersonation/view-as is the only honest debugger. **Findability**: settings search is mandatory past ~30 nodes (admins remember words, not the tree), every setting has a stable deep link, and the in-context gear links bidirectionally between a governed surface and the setting that governs it. **The AI subjects**: build-time generation compiles NL to an inspectable artifact editable before commit — never a black box; the agent governance console (identities, model-routing, data masking, permission scoping, the AI-action audit view) is an org-scope subject. Anti-patterns forbidden: the junk drawer, features hiding in settings (saved views, dashboards, templates are product surfaces, not settings), modal settings, and the invisible cascade. A settings page whose scope is undeclared cannot be placed or permissioned: clarify.
 
 ```json decision-table
 {"pass": "settings", "rows": [

package/data/harnesses/code/skills/design/references/ux-patterns/standard-pages.md

@@ -21,7 +21,7 @@ license: open
 
 **Audit has two surfaces, both outputs of the Logged history class at different scopes.** Per-object history is the record-scoped timeline on every detail page. The **global audit log** is an org-scope, append-only index of who-did-what-when across security-relevant actions — logins, permission changes, deletions, exports, setting changes, and every impersonation session (impersonation is always logged, no exceptions) — filterable by actor/action/object/time, searchable, exportable; for SOC2/enterprise buyers it is a purchase criterion, not an afterthought.
 
-**Admin pages are indexes and forms over the org's meta-objects.** User management (invite — noting SSO/SCIM may provision users externally, so the invite form is not the only entry point — role assignment, deactivation) must trigger an **ownership-transfer flow** on deactivation: reassign the departing user's records before the account closes, or orphaned records are guaranteed. Roles & permissions is the admin surface for the access layers, paired with **impersonation/view-as** — once record- and field-level access exist, "log in as this user" is the only practical way to debug what a person actually sees. Seats & licenses render "X of Y seats used," pending invites, and reclaim-on-deactivation. Billing is brief here; customer-facing usage/billing surfaces are deferred.
+**Admin pages are indexes and forms over the org's meta-objects.** User management (invite — noting SSO/SCIM may provision users externally, so the invite form is not the only entry point — role assignment, deactivation) must trigger an **ownership-transfer flow** on deactivation: reassign the departing user's records before the account closes, or orphaned records are guaranteed. Roles & permissions is the admin surface for the access layers, paired with **impersonation/view-as** — once record- and field-level access exist, "log in as this user" is the only practical way to debug what a person actually sees. Seats & licenses render "X of Y seats used," pending invites, and reclaim-on-deactivation. Billing is brief here; customer-facing usage/billing surfaces are out of scope.
 
 **Integrations resolve to objects, never a free-floating layer.** External data always maps to objects and fields: a connect flow (OAuth or keys, workspace scope), a **field-mapping editor** (their "Company" ↔ your "Account," with sync direction and frequency per mapping), and **connection health** (status, last successful sync, error counts, per-connection sync logs as an index of sync events); synced fields carry their origin declaration wherever they render. When a standard-page request omits which meta-object it is over, its contract cannot be derived: clarify.
 

package/data/harnesses/code/skills/design/scripts/README-validator.md

@@ -1,27 +1,39 @@
 # validate-design-md.mjs — the design.md system's validator + token emitter
 
-**CLI:** `node validate-design-md.mjs <file|folder> [--mode admission|build|ship] [--json] [--emit]`
+**CLI:** `node validate-design-md.mjs (<file|folder> | --project [dir]) [--mode admission|build|ship] [--json] [--emit] [--emit-personality] [--write] [--lib <folder>]`
 File mode validates one design.md. Folder mode validates every `.md` in the tree (skipping `SCHEMA.md`) plus `index.csv` integrity.
-`admission` and `build` run the same checks; `ship` adds the dmv-11 drift check against a `design.tokens.css` beside the input file.
+`--project [dir]` validates the project's own fork, located by the repo's shape: `packages/common/design.md` in a multi-package
+workspace, `src/common/design.md` in a single-package repo (`dir` defaults to the cwd; an absent file fails closed, naming the path).
+`admission` and `build` run the same checks; `ship` adds the dmv-11 drift check against a `design.tokens.css` beside the input file,
+and dmv-12's drift check against `personality.css`.
 `--json` prints `{file, fails:[{id,detail}], warns:[{id,detail}]}` (array in folder mode). Exit 0 on pass (warns allowed), 1 on any FAIL.
 
 **Emit:** `--emit` (single file) compiles the token artifact from the `yaml design-values` block to stdout — deterministic, byte-stable;
-redirect to `design.tokens.css`. Shape: `:root, :root[data-theme="light"]` + `:root[data-theme="dark"]` blocks (specificity armor, both
-0,2,0) carrying the 36 color roles as `--<role>`; the light block also carries `--font-display/sans/mono` (registered names quoted, with
-fallback stacks), `--text-<step>-size/-line/-weight` (+ `-family/-tracking/-features`), `--radius-*`, `--shadow-*`, `--duration-*`,
-`--ease-*`, and layout vars (`--space-base`, `--sidebar-width[-collapsed]`, `--topbar-height`, `--side-panel-width[-wide]`, `--content-max-width`).
+redirect to `design.tokens.css`, or add `--write` to write it beside the design.md. Shape: three blocks. A bare `:root` carries every
+theme-invariant token — `--font-display/sans/mono` (registered names quoted, with fallback stacks), the ramp as `--text-<step>` with
+`--line-height`/`--font-weight`/`--letter-spacing` sub-keys, `--radius-*`, `--shadow-*`, `--duration-*`, `--ease-*`, and layout vars
+(`--space-base`, `--sidebar-width[-collapsed]`, `--topbar-height`, `--side-panel-width[-wide]`, `--content-max-width`). Then
+`:root:not(.dark)` and `:root.dark` (specificity armor, both 0,2,0) carry the color roles as `--<role>`.
+`--emit-personality` (`primitives: nurix`) hands the design.md's `personality` traits to `@nurix/components`' own compiler
+(`compileToCss` from `@nurix/components/lib/personality`) and prints `personality.css`, or writes it with `--write`; `--lib <folder>`
+names where the library is installed when the resolver cannot tell. Any FAIL suppresses either artifact.
 
 **Fails (close the gate):** dmv-01 frontmatter strict, per-tier keys, id = filename · dmv-02 the 12 sections in order, non-empty,
 plus trailing design-values block · dmv-03 value block parses as YAML · dmv-04 coverage: 36 roles × both themes, ramp, register-scope,
 elevation, motion base, iconography, charts, layout · dmv-05 contrast on every declared pairing (body ≥ 4.5:1; primary/accent/
 destructive/sidebar-primary fills ≥ 3:1, warn under 4.5) · dmv-06 no image reference anywhere · dmv-07 index.csv ↔ files, both
 directions, no duplicates · dmv-08 registered font names + fallback stacks · dmv-09 no claude.md (any case) · dmv-10 project tier:
-`primitives: nurix|native` + `source-package` · dmv-11 (ship) emitted artifact byte-matches recompilation.
+`primitives: nurix|native` + `source-package` · dmv-11 (ship) emitted artifact byte-matches recompilation · dmv-12 the
+`personality` block (`primitives: nurix` only) uses the six traits `density|pace|edge|depth|texture|accent` with their closed values
+(`pace` a number 0..1; a `tone` key fails naming `accent`, as the library's compiler rejects it), and under `--mode ship`
+`personality.css` byte-matches the recompiled artifact.
 
 **Warns (recorded, never close):** dmw-01 background in the anti-cream band (L 0.84–0.97, C < 0.06, hue 40–100) · dmw-02 neutral
 surfaces pure gray (C < 0.005) or over-tinted (C > 0.015) · dmw-03 untinted black shadow above 0.15 alpha · dmw-04 ease-in entrance
 or duration over its element-class budget · dmw-05 display face granted a data register · dmw-06 dark ladder steps < ~0.04 L or hue
-drift · dmw-07 accent chroma delta between themes > 0.06.
+drift · dmw-07 accent chroma delta between themes > 0.06 · dmw-08 the dense operator tier unadopted (`typography.ramp` omits the
+optional steps) · dmw-09 (`primitives: nurix`) no personality block, so the library's neutral traits ship · dmw-10 (`primitives: nurix`)
+the `info` role undeclared, so `--intent-info` falls back to the library's own hue.
 
 Stdlib-only: vendors its own YAML-subset parser and oklch → sRGB → WCAG-contrast math. The exact contrast pair table, thresholds,
 and emission order live in the script's header comment.

package/data/harnesses/code/skills/design/scripts/validate-design-md.mjs

@@ -62,13 +62,14 @@
 //   dmv-11  (--mode ship) drift: the token artifact recompiled from the design.md byte-matches the
 //           design.tokens.css beside it.
 //   dmv-12  the personality block (primitives: nurix): a mapping over the six closed-vocabulary traits
-//           density|pace|edge|depth|texture|tone (pace a number 0..1); absent under native. In --mode
+//           density|pace|edge|depth|texture|accent (pace a number 0..1; a `tone` key fails naming
+//           `accent`, as the library's compiler rejects it); absent under native. In --mode
 //           ship, personality.css beside the design.md byte-matches the recompiled artifact, and no
 //           personality.css exists without a block (a hand-authored layer).
 //
 // WARN checks (never close): dmw-01 anti-cream backgrounds · dmw-02 neutral tint · dmw-03 untinted shadows ·
-//   dmw-04 motion budgets · dmw-05 personality block absent on a nurix project (the library's neutral
-//   traits ship) · dmw-06 `info` role undeclared on a nurix project (--tone-info falls back to the
+//   dmw-04 motion budgets · dmw-09 personality block absent on a nurix project (the library's neutral
+//   traits ship) · dmw-10 `info` role undeclared on a nurix project (--intent-info falls back to the
 //   library's own hue).
 //
 // dmv-05 — the exact contrast pair table (both themes; WCAG 2.1 relative-luminance contrast; colors
@@ -106,6 +107,8 @@
 //   dmw-07  accent chroma delta between themes > 0.06 (identity likely not held across themes).
 //
 //   dmw-08  the dense operator tier is unadopted: typography.ramp omits optional steps (one warn per package).
+//   dmw-09  (primitives: nurix) no personality block — the library's neutral traits ship.
+//   dmw-10  (primitives: nurix) the `info` role undeclared — --intent-info falls back to the library's own hue.
 //
 // Emitted artifact shape (deterministic, byte-stable): THREE blocks. A bare `:root` carries every
 // theme-invariant group — --font-display/sans/mono (registered names quoted, fallback stacks appended),
@@ -148,18 +151,18 @@ const RAMP_STEPS_OPTIONAL = ["title", "h3", "prose", "control-lg", "dense", "con
 const RAMP_STEPS = [...RAMP_STEPS_REQUIRED, ...RAMP_STEPS_OPTIONAL];
 const FONT_SLOTS = ["display", "sans", "mono"];
 // Optional color roles: emitted only when declared (both themes or neither). `info` completes the
-// success/warning/info trio @nurix/components' status dots read through --tone-*.
+// success/warning/info trio @nurix/components' status dots read through --intent-*.
 const OPTIONAL_COLOR_ROLES = ["info"];
 // The personality block — six closed-vocabulary traits @nurix/components compiles into the token
 // families its components read (lib/personality). The library owns the vocabulary; this mirrors it.
-const PERSONALITY_ORDER = ["density", "pace", "edge", "depth", "texture", "tone"];
+const PERSONALITY_ORDER = ["density", "pace", "edge", "depth", "texture", "accent"];
 const PERSONALITY_TRAITS = {
     density: ["compact", "regular", "airy"],
     pace: null, // the one scalar: 0 still · 0.5 the library's neutral timing · 1 lively
     edge: ["sharp", "regular", "soft"],
     depth: ["flat", "layered", "elevated"],
     texture: ["clean", "grainy"],
-    tone: ["neutral", "expressive"],
+    accent: ["neutral", "expressive"],
 };
 const THEMES = ["light", "dark"];
 const TIERS = ["default", "variant", "brand", "project"];
@@ -750,13 +753,13 @@ function checkCoverage(values, report) {
     else if (layout.base == null) missing("layout.base");
 }
 
-// dmv-12 — the personality block, and the two nurix-project warns (dmw-05 block absent, dmw-06 info absent).
+// dmv-12 — the personality block, and the two nurix-project warns (dmw-09 block absent, dmw-10 info absent).
 function checkPersonality(front, values, report) {
     const isNurixProject = !!front && front.tier === "project" && front.primitives === "nurix";
     const p = values.personality;
     if (p === undefined) {
         if (isNurixProject) {
-            warn(report, "dmw-05", "personality block absent — @nurix/components ships its neutral traits (regular · pace 0.5 · regular · layered · grainy · neutral); declare the traits §4–§7 imply so density, motion, radius and depth reach the components");
+            warn(report, "dmw-09", "personality block absent — @nurix/components ships its neutral traits (regular · pace 0.5 · regular · layered · grainy · neutral); declare the traits §4–§7 imply so density, motion, radius and depth reach the components");
         }
     } else if (!isObj(p)) {
         fail(report, "dmv-12", "personality must be a mapping of traits");
@@ -765,7 +768,9 @@ function checkPersonality(front, values, report) {
             fail(report, "dmv-12", "personality is compiled by @nurix/components — under primitives: native nothing reads it; drop the block or switch primitives");
         }
         for (const [k, v] of Object.entries(p)) {
-            if (!(k in PERSONALITY_TRAITS)) {
+            if (k === "tone") {
+                fail(report, "dmv-12", `personality.tone is not a trait — the accent trait carries that axis (accent: ${PERSONALITY_TRAITS.accent.join("|")}); the library's compiler rejects tone`);
+            } else if (!(k in PERSONALITY_TRAITS)) {
                 fail(report, "dmv-12", `personality.${k} is not a trait (${PERSONALITY_ORDER.join("|")})`);
             } else if (k === "pace") {
                 const n = typeof v === "number" ? v : Number(v);
@@ -787,7 +792,7 @@ function checkPersonality(front, values, report) {
             const bad = THEMES.filter((t) => !parseColor(color[t][role]));
             if (bad.length) fail(report, "dmv-04", `color.${role} unparseable in ${bad.join(", ")}`);
         } else if (isNurixProject) {
-            warn(report, "dmw-06", `color.${role} undeclared — @nurix/components' --tone-${role} falls back to the library's own hue beside your success/warning; declare it in both themes`);
+            warn(report, "dmw-10", `color.${role} undeclared — @nurix/components' --intent-${role} falls back to the library's own hue beside your success/warning; declare it in both themes`);
         }
     }
 }

package/data/harnesses/code/skills/documentation/SKILL.md

@@ -3,7 +3,7 @@ name: documentation
 description: "Use when creating or substantively editing ANY markdown doc — invoke BEFORE writing. Genre registry, templates and style authority for technical docs: LLDs, ADs, plans, changelogs, READMEs, runbooks. Owns the tense rule: truth docs state the present; history only in dated records. Baselining is the maintenance agent."
 ---
 
-# Technical Documentation Skill
+# Technical documentation skill
 
 This skill writes one document at a time: the genre registry says what kind of document it is, a template gives its shape, the style guide its prose, and `doc-lint` checks the mechanical half. It does not baseline, audit or reconcile a repo's doc tree; that is the `maintenance` agent, which calls this skill once per document it scaffolds.
 
@@ -67,7 +67,7 @@ The full strip-list and the record-side rules: `references/style-guide.md` § Th
 - **Intent and promises; facts are the graph's.** An owning document (feature, package, system) says why the product is shaped this way and what it promises, and names the objects it designs in `objects:`. Every computable fact (a table's columns, which function writes which column, which route sits behind which guard, which file holds what) is the code's, and a hand-typed copy is wrong the day the code moves. `doc-lint` blocks the retired mechanism sections (`mechanism-section`) and an owning document with no `objects:`.
 - **Read by people, pointed at by the footer.** Sharp bullets under noun-phrase headings, each a bold label, a colon, one or two plain sentences; code named only where a person types or sees it, or at a cross-cutting seam; every other pointer in the closing **For the agent** footer (style guide § Owning documents — the body and the footer).
 - **The stability test.** A sentence that would change when a function is renamed, a file moves, or a route, column or error code changes is the code's, not the document's. The code is the authority on *what*; the document on *why* (style guide § Shape).
-- **Unbuilt work has one home per kind.** Decided design the code does not yet do sits in the body, wrapped in an `UNBUILT` marker; a shortfall in what is built is one bullet under Gaps; the work that would close either is a backlog row, which the document never tracks (style guide § The stability test).
+- **Unbuilt work has one home per kind.** Decided, unbuilt design sits in the body, wrapped in an `UNBUILT` marker; a shortfall in what is built is one bullet under Gaps; the work that would close either is a backlog row, which the document never tracks (style guide § The stability test).
 - **No empty stubs.** Omit a section with nothing real to say. Write "None" only where the absence is itself information, such as a plan's Cross-Module Contracts Affected.
 - **No redirect documents.** Moving a document deletes the old file and repoints every inbound link; a "Moved to X" stub rots and creates false search hits.
 
@@ -78,9 +78,9 @@ The full strip-list and the record-side rules: `references/style-guide.md` § Th
 - **The links an index may carry:** a sibling folder's `Readme.md`, the mandated scaffolds (`structure.md`, `operations/setup.md`, `history/CHANGELOG.md`, `history/backlog.md`, `history/journal.md`, `history/health-log.md`, `memory/main.md`), and the root `CLAUDE.md` and `AGENTS.md`. `doc-lint` blocks the rest under `docs/` as `index-lists-files`, a drawn tree as `index-file-tree`, a named file or record as `index-names-records`.
 - **Routing documents point at truth.** A "read first" row names the topic's truth document, never a plan or changelog entry. An index of the records themselves (a History section naming `plans/` and `changelog/`) is sanctioned.
 
-### Ownership today
+### Ownership edges
 
-A document names the objects it designs in `objects:`, and a source file names the document that speaks for it in its path header. The harness's ownership scan reads one edge today: the transitional `owns:` region glob on each feature, package, system and surface-owning UX document, the narrower glob winning. Write the header pointer anyway, so the scan can switch to it and to the object closure without a second pass over the code. Where a repository has no `docs/architecture/systems/knowledge-layer.md`, this skill and `references/frontmatter.md` are the whole authority on document–code edges. `docs/structure.md` is harness-owned: the installer writes it, and the `maintenance` agent stamps only its `harness-version`.
+A document names the objects it designs in `objects:`, and a source file names the document that speaks for it in its path header. The harness's ownership scan reads one edge: the transitional `owns:` region glob on each feature, package, system and surface-owning UX document, the narrower glob winning. **Always write the header pointer as well** — the scan switches to it and to the object closure, and pointers already in place spare that switch a second pass over the code. Where a repository has no `docs/architecture/systems/knowledge-layer.md`, this skill and `references/frontmatter.md` are the whole authority on document–code edges. `docs/structure.md` is harness-owned: the installer writes it, and the `maintenance` agent stamps only its `harness-version`.
 
 ---
 
@@ -113,7 +113,7 @@ A document names the objects it designs in `objects:`, and a source file names t
 | Scaffold a standard doc (docs index, changelog guide, backlog, memory) | The registry's § Baseline scaffolds |
 | Frontmatter keys (`objects:`, `verifies:`, the transitional `owns:`) | [`references/frontmatter.md`](references/frontmatter.md) |
 | Source-file comments: what stays, what moves to a doc, proving a sweep | [`references/source-comments.md`](references/source-comments.md) |
-| Instruction file (`CLAUDE.md`, a rule, an agent, skill prose) | [`references/instruction-style.md`](references/instruction-style.md): every-load prose stays lean; the present-tense rule still applies |
+| Instruction file (`CLAUDE.md`, a rule, an agent, skill prose) | [`references/instruction-style.md`](references/instruction-style.md): every-load prose stays lean; the present-tense rule applies too |
 | Author or restructure a skill | The skill-authoring field guide in the etna repo (`nurixlabs/etna`), `docs/playbooks/skills/`. No etna checkout ⇒ ask the user for access, or proceed from first principles with `references/instruction-style.md` governing the prose |
 | No template matches | [`references/untemplated.md`](references/untemplated.md) |
 

package/data/harnesses/code/skills/documentation/references/examples.md

@@ -1,12 +1,12 @@
-# Documentation Examples
+# Documentation examples
 
-Good vs bad examples showing the key differences.
+Good and bad documentation side by side; `style-guide.md` cites each example by number.
 
 ---
 
-## Example 1: Function Documentation
+## Example 1: Function documentation
 
-### Bad: Full Implementation
+### Bad: full implementation
 
 ```markdown
 ### mergeData
@@ -14,9 +14,9 @@ Good vs bad examples showing the key differences.
 function mergeData(server, local, changes) { const result = {}; const serverMap = new Map(server.map((i) => [i.id, i])); // ... 30 more lines return result; }
 ```
 
-**Problems:** Will become obsolete, focuses on HOW not WHAT.
+**Problems:** goes stale with the first refactor; shows *how* instead of *what*.
 
-### Good: Contract Only
+### Good: contract only
 
 ```markdown
 ### `mergeData(serverData, localData, changes)`
@@ -40,9 +40,9 @@ function mergeData(server, local, changes) { const result = {}; const serverMap
 
 ---
 
-## Example 2: State Documentation
+## Example 2: State documentation
 
-### Bad: State Everywhere
+### Bad: state everywhere
 
 ```markdown
 ## Component State
@@ -58,9 +58,9 @@ const [items, setItems] = useState([]);
 { items: [], loading: false, error: null }
 ```
 
-**Problems:** Documents transient state, repeats shapes.
+**Problems:** documents transient state and repeats shapes.
 
-### Good: Persistence Points Only, in the API reference
+### Good: persistence points only, in the API reference
 
 Persisted shapes live in the API reference (`docs/architecture/api.md`), never in a feature document, where `## State` is a retired mechanism section.
 
@@ -89,7 +89,7 @@ export const items = pgTable('items', {
 
 ## Example 3: Changelog
 
-### Bad: Vague
+### Bad: vague
 
 ```markdown
 # 2025-01-05 - Updates
@@ -105,7 +105,7 @@ export const items = pgTable('items', {
 - Various files in src/
 ```
 
-### Good: Behavior First, Refinement Context Kept
+### Good: behavior first, refinement context kept
 
 ```markdown
 # 2025-01-05 · data-sync — Local edits survive a sync only when versions match
@@ -123,7 +123,7 @@ export const items = pgTable('items', {
 
 ## Example 4: Flow
 
-### Bad: Mechanism narrated in a paragraph
+### Bad: mechanism narrated in a paragraph
 
 ```markdown
 ## Data Flow
@@ -133,7 +133,7 @@ When the page loads, the useAppInit hook calls the syncData function. This funct
 
 **Problems:** names a hook, a function and a store that a rename would invalidate (the stability test); runs parallel cases together in one paragraph; gives a scanning reader no label to land on; "Data Flow" is a retired mechanism section.
 
-### Good: Labelled bullets, a role-level diagram beside them
+### Good: labelled bullets, a role-level diagram beside them
 
 ````markdown
 ## Flows
@@ -161,7 +161,7 @@ sequenceDiagram
 
 ## Example 5: Architecture Decision revision
 
-### Bad: Supersession chain
+### Bad: supersession chain
 
 ```
 docs/architecture/decisions/
@@ -170,9 +170,9 @@ docs/architecture/decisions/
 └── AD-011-auth-better-auth-v2.md  (status: Accepted, "supersedes AD-006")
 ```
 
-**Problems:** Three files hold one subject; the reader must diff a chain to learn the current truth; two of the three are wrong-but-present (the same pathology as keeping `report_v1.sql` beside the live `report_v2.sql`); the reasoning that killed Keycloak is stranded in a dead file nobody opens.
+**Problems:** three files hold one subject; the reader must diff a chain to learn the current truth; two of the three are wrong-but-present (the same pathology as keeping `report_v1.sql` beside the live `report_v2.sql`); the reasoning that killed Keycloak is stranded in a dead file nobody opens.
 
-### Good: One subject, updated in place
+### Good: one subject, updated in place
 
 ```
 docs/architecture/decisions/
@@ -195,15 +195,15 @@ We use Better Auth with one-shot credential issuance…   ← current truth, no
 - 2026-01-10 — Initial decision accepted. Implemented by [plan](…).
 ```
 
-**Why it works:** The body answers "how does auth work and why" without archaeology; the tail preserves every reversal with its trigger; the rejected alternatives stay findable in the one file a reader actually opens.
+**Why it works:** the body answers "how does auth work and why" without archaeology; the tail preserves every reversal with its trigger; the rejected alternatives stay findable in the one file a reader actually opens.
 
 ---
 
 ## Example 6: Stripping history from a truth doc
 
-The move agents fumble: deleting narration is only half the job — the story must land in a record.
+Deleting narration is only half the move; the story **must** land in a record.
 
-### Bad: The journey narrated in place
+### Bad: the journey narrated in place
 
 ```markdown
 ## Export Pipeline
@@ -214,7 +214,7 @@ output is not yet implemented. Treat any reference to `reports/export.js` as
 stale — it was superseded by `src/export/run.js`.
 ```
 
-### Good: Present-tense truth doc + a dated record carrying the story
+### Good: present-tense truth doc + a dated record carrying the story
 
 The feature doc states only what is:
 
@@ -243,7 +243,7 @@ And the change-story goes to `docs/history/changelog/2026-06-02-export-extractio
 
 ---
 
-## Quick Comparison
+## Quick comparison
 
 | Aspect     | Bad                  | Good                        |
 | ---------- | -------------------- | --------------------------- |

package/data/harnesses/code/skills/documentation/references/frontmatter.md

@@ -6,7 +6,7 @@ This reference states how a document joins the knowledge graph, and it is kept i
 
 ## The model
 
-A document names the product objects it designs. Every other edge between a document and the code is either authored on the code's side or computed, never typed into the document. The harness's ownership scan reads one edge today, the transitional `owns:` region glob (§ `owns:`); principles 2 and 3 are the edges it switches to, and the header pointer is written now so the switch needs no second pass over the code.
+A document names the product objects it designs. Every other edge between a document and the code is either authored on the code's side or computed, never typed into the document. The harness's ownership scan reads one edge, the transitional `owns:` region glob (§ `owns:` — transitional); principles 2 and 3 are the edges it switches to, and the header pointer is written alongside it so the switch needs no second pass over the code.
 
 ### Principles
 
@@ -63,7 +63,7 @@ Tooling keys sit beside these on any genre: `rev:` (a generator's generation sta
 
 ### `owns:` — transitional
 
-- **Reason for the key:** the harness's ownership scan (`.claude/hooks/lib/ownership.mjs`) keys on `owns:` until it switches to the header pointers and the object closure, which is the knowledge layer's recorded gap. Until then the key keeps the session's ownership index and the doc-debt detectors working.
+- **Reason for the key:** the harness's ownership scan (`.claude/hooks/lib/ownership.mjs`) keys on `owns:` until it switches to the header pointers and the object closure, which is the knowledge layer's recorded gap. The key is what keeps the session's ownership index and the doc-debt detectors working.
 - **Form:** region globs only, one per region the document speaks for: `packages/{name}/**` on a package document, the machine's subtrees on a system document, a feature's own directory on a feature document. Never a list of individual files, and never a shared file several features import.
 - **Growth:** none. A new document carries the region glob its genre needs and nothing more; an edit never adds file-level entries.
 - **Retirement:** removed from every document in the same change that switches the scan, and this section with it.
@@ -73,7 +73,7 @@ Tooling keys sit beside these on any genre: `rev:` (a generator's generation sta
 | Key | Retired because | What replaces it |
 | --- | --- | --- |
 | `applies:` | A list of governing documents is a hand-kept copy of a relationship the graph computes through the objects both documents name, and it drifts the way any copy does | The objects the doctrine and the surface share, computed; for people, the document's Scope section (a UX document's Purpose) names its governing doctrine and what each settles |
-| `keywords:` | An object's name and aliases are its discovery terms | `objects:`. The ownership scan still shows a document's `keywords:` in the index when it names no `objects:`, so removing the key without adding `objects:` empties that entry |
+| `keywords:` | An object's name and aliases are its discovery terms | `objects:`. The ownership scan shows a document's `keywords:` in the index when it names no `objects:`, so removing the key without adding `objects:` empties that entry |
 | A file-level `owns:` list | The header pointers and the object closure compute it | Region globs only, until the scan switches (above) |
 
 An edit to a document that carries a retired key removes the key in the same edit.