@nurix/etna 0.20.35 → 0.20.37

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

@@ -22,7 +22,7 @@ No database — three constraints, values yours: **categorical** series need dis
 
 ## Number, date, unit formatting
 
-Tabular figures in tables and KPIs; thousands separators; unit or currency attached to the number; consistent decimals per column; large values truncate meaningfully (`1.2M`, never `1,200,000` in a tile); timestamps show relative when recent and absolute on hover (under `nurix`, that is `<Timestamp format="auto">`, never a hand-rolled formatter); timezones explicit anywhere ambiguity costs money.
+Tabular figures in tables and KPIs; thousands separators; unit or currency attached to the number; consistent decimals per column; large values truncate meaningfully (`1.2M`, never `1,200,000` in a tile); timestamps show relative when recent and absolute on hover (under `nurix`, that is `<Timestamp>`, never a hand-rolled formatter); timezones explicit anywhere ambiguity costs money.
 
 ## Spacing & density
 
@@ -30,15 +30,15 @@ The 2/4/6/8 scale, period. Density is a per-project decision made once, not a pe
 
 ## Radius & stroke
 
-Radius is identity — sharp (0–2px), soft (4–6px), or round (10px+) — chosen by the package and applied consistently; mixing radii on one surface reads as templated. One border weight per surface; elevation *or* borders separate layers, never both at full strength.
+Radius is identity — sharp (0–2px), soft (4–6px), or round (10px+) — chosen by the package and applied consistently; mixing radii on one surface reads as templated. One border weight per surface; elevation *or* borders separate layers, never both at full strength. Under `nurix` both are the `edge` trait — the radius scale, `--radius-pill`, and the `--edge-hairline` / `--edge-stroke` weights — never per-surface literals.
 
 ## Loading, skeleton, progress
 
-Skeletons for layout-known loads, spinners only for unknowable ones, optimistic updates for high-frequency mutations with undo. Skeletons mirror the real layout's bones (no generic gray blocks). Nothing pulses faster than 1.2s; under `nurix` a status pulse is `<Chip prefix="dot" pulse>`, never `animate-pulse` (a hardcoded keyframe neither `pace` nor the inline clamp can reach), and loaders keep breathing inside inline collections by design.
+Skeletons for layout-known loads, spinners only for unknowable ones, optimistic updates for high-frequency mutations with undo. Skeletons mirror the real layout's bones (no generic gray blocks). Nothing pulses faster than 1.2s; under `nurix` a status pulse is `<Chip prefix="dot" isPulsing>`, never `animate-pulse` (a hardcoded keyframe neither `pace` nor the inline clamp can reach), and loaders keep breathing inside inline collections by design.
 
 ## Empty states
 
-The three empties (first-use, no-results, cleared-filter) each say what happened and what to do next, in the project voice. Art direction follows the package's restraint: an icon or nothing for dense tools; illustration only where the package's feel says warm. Never a bare "No data".
+The three empties (first-run, filtered-to-zero, failed-to-load) and a queue's cleared-empty each say what happened and what to do next, in the project voice. Art direction follows the package's restraint: an icon or nothing for dense tools; illustration only where the package's feel says warm. Never a bare "No data".
 
 ## Keyboard
 
@@ -54,4 +54,4 @@ Mono face with `tabular-nums`; a shiki theme paired to the package (dark identit
 
 ## Polish
 
-Focus rings on-brand (2px, offset, the accent — never browser default blue on a styled app); selection color derived from the accent at low alpha; scrollbars styled thin on dense panes; cursor changes only where affordance is real.
+Focus rings on-brand (a visible width, the accent — never browser default blue on a styled app; under `nurix` the library's `focus-ring`, sized by `--ring-width` / `--ring-offset` and coloured by `--ring`); selection color derived from the accent at low alpha; scrollbars styled thin on dense panes; cursor changes only where affordance is real.

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.