devrites 3.0.4 → 3.0.6

package/pack/generated/codex/skills/rite-spec/SKILL.md

@@ -11,21 +11,21 @@ This is the Codex mirror of a DevRites skill. In Codex:
 
 - Load DevRites engineering standards from `.agents/skills/devrites-lib/reference/standards/`. Read `.agents/skills/devrites-lib/reference/standards/core.md` before workflow work, then load the other `.agents/skills/devrites-lib/reference/standards/*.md` files exactly when this skill asks for them.
 - Use the installed `devrites-engine` binary as the canonical runtime helper surface for orientation, gates, and state mutation.
-- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here — Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
-- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review** — an inline pass shares the calling context and is weaker evidence.
+- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here: Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
+- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review**: an inline pass shares the calling context and is weaker evidence.
 - Codex project hooks are installed in `.codex/hooks.json`. Review and trust them with `/hooks` before relying on hook enforcement.
-- When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers — NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
+- When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers: NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
 
 
-# $rite-spec — investigate deeply, write the spec
+# $rite-spec: investigate deeply, write the spec
 
 The spec phase. Turn a request (even a vague one) into a **fully-covered, correctly-placed
-`spec.md`** by investigating deeply and closing every material gap with the human — so
-`$rite-define` can plan it and nothing is missed. **No plan, tasks, or code here** — those
+`spec.md`** by investigating deeply and closing every material gap with the human, so
+`$rite-define` can plan it and nothing is missed. **No plan, tasks, or code here**. Those
 are `$rite-define` and `$rite-build`.
 
 > **Too small to spec? Use `$rite-quick`.** A typo, copy tweak, config bump, or one-function
-> fix does **not** need a full workspace + lifecycle. Stop and run `$rite-quick <change>` — its
+> fix does **not** need a full workspace + lifecycle. Stop and run `$rite-quick <change>`: its
 > express lane (one contract → TDD build → scoped prove → ship) escalates back here the moment
 > the change turns out to touch auth / data / a migration / a public API / more than one slice.
 > Spec is for real features; don't pay its ceremony for a one-off.
@@ -33,11 +33,11 @@ are `$rite-define` and `$rite-build`.
 ## Rules consulted (read on demand from `.agents/skills/devrites-lib/reference/standards/`)
 Pull `documentation.md` via `Read`
 when capturing significant spec decisions (why-not-what, ADR-style notes in `decisions.md`);
-pull `principles.md` when the project has declared invariants (`.devrites/principles.md`) — a
+pull `principles.md` when the project has declared invariants (`.devrites/principles.md`): a
 new spec must respect them, and a requirement that can only be met by breaking one is a blocking gap.
 Pull `spec-grammar.md` and `devrites-lib/reference/workspace-artifact-schema.md` when writing
 acceptance for a behavioral / high-risk requirement (auth,
-data model, state machine, public API, money, migration) — the structured `### Requirement:` /
+data model, state machine, public API, money, migration): the structured `### Requirement:` /
 `#### Scenario:` (SHALL · WHEN/THEN) form, lint-checked by `devrites-engine spec-validate`. Simple criteria
 stay flat `AC-###` bullets; the grammar is opt-in by rigor, never forced.
 
@@ -54,19 +54,19 @@ stay flat `AC-###` bullets; the grammar is opt-in by rigor, never forced.
   the weak section.
 
 ## Workflow
-0. **Read `.agents/skills/devrites-lib/reference/standards/core.md`** — the always-on operating rules and anti-rationalizations.
+0. **Read `.agents/skills/devrites-lib/reference/standards/core.md`:** the always-on operating rules and anti-rationalizations.
    Then run `devrites-engine preamble` for deterministic workspace orientation.
-0a. **Brownfield check — onboard before speccing onto un-adopted existing code.** If this is an
-   **existing codebase** (real source predating DevRites) that has **never been adopted** — no
-   `.devrites/conventions.md`, no prior `.devrites/work`, `.devrites/features`, or `.devrites/archive` — the build has no
+0a. **Brownfield check: onboard before speccing onto un-adopted existing code.** If this is an
+   **existing codebase** (real source predating DevRites) that has **never been adopted** (no
+   `.devrites/conventions.md`, no prior `.devrites/work`, `.devrites/features`, or `.devrites/archive`) the build has no
    conventions ledger to follow and the first slice would guess the project's idioms. Route
    through `$rite-adopt` **first**, carrying `$ARGUMENTS` as its *next objective*: adopt
    reverse-derives the baseline `spec.md`, **seeds the conventions ledger**, and proposes
    principles, so this feature is specced on top of an onboarded project (adopt owns the
-   onboarding; `$rite-spec` only detects and routes — no duplicated logic). In **HITL** present a
+   onboarding; `$rite-spec` only detects and routes: no duplicated logic). In **HITL** present a
    ranked option (recommended: *adopt first, then spec this on top*; escape hatch: *spec-only, skip
    onboarding*); in **AFK** (adoption allowed) run `$rite-adopt` first automatically. **Greenfield
-   (no pre-existing source) or an already-onboarded project → skip silently** — never block a spec
+   (no pre-existing source) or an already-onboarded project → skip silently**: never block a spec
    for the absence of adoption (the same no-op discipline as the principles gate). Cheap probe:
    ```bash
    if [ ! -f .devrites/conventions.md ] && [ ! -d .devrites/archive ] \
@@ -84,75 +84,75 @@ stay flat `AC-###` bullets; the grammar is opt-in by rigor, never forced.
    ```
    If it finds a close match, ask the user: extend existing / adopt / new spec. Record the choice in
    `decisions.md` once the workspace exists. No match → continue silently.
-2. **Investigate deeply** — [investigation](reference/investigation.md). Produce, and
+2. **Investigate deeply:** [investigation](reference/investigation.md). Produce, and
    later write into the spec: **current behavior**; **placement** (which module/layer/
-   file/component should own it, the seam, patterns to reuse, and integration points —
+   file/component should own it, the seam, patterns to reuse, and integration points:
    callers, dependents, data, APIs/events); **what it resolves**; **issues**
    (conflicts/constraints); **gaps** (unknowns); **blast radius**. Use a code-intelligence
-   index **if available** — `codebase-memory-mcp` first, cross-checked with `codegraph`
+   index **if available**: `codebase-memory-mcp` first, cross-checked with `codegraph`
    (`.codegraph/` / `codegraph_*`) + `graphify` (`graphify-out/`), else standard methods
-   (LSP / `Read`/`Grep`/`Glob`); see `.agents/skills/devrites-lib/reference/standards/tooling.md` —
+   (LSP / `Read`/`Grep`/`Glob`); see `.agents/skills/devrites-lib/reference/standards/tooling.md`:
    for placement/callers/impact instead of broad file reads; fall back to reading files. For
    uncertain external library/framework facts that bear on placement or feasibility, consult
-   context7 if available. When a material decision turns on a fact outside the codebase — a
-   common UX pattern, a standard, a prevailing best practice, how comparable products solve it —
+   context7 if available. When a material decision turns on a fact outside the codebase: a
+   common UX pattern, a standard, a prevailing best practice, how comparable products solve it:
    **search the web if available** (brave MCP preferred; see `.agents/skills/devrites-lib/reference/standards/tooling.md`), and
    carry the cited finding into the option you put to the human at step 4.
    Also discover the project's **test / build/typecheck/lint** commands and the
    frontend/backend systems; read `PRODUCT.md` / `DESIGN.md` / `CLAUDE.md` / `AGENTS.md` if
-   present (`AGENTS.md` is the cross-tool agent-conventions standard — treat it as project
+   present (`AGENTS.md` is the cross-tool agent-conventions standard (treat it as project
    conventions the build must follow, same standing as `CLAUDE.md`), and read
-   `.devrites/principles.md` if present — the declared invariants the feature must respect.
-   **Consult the capability ledger** — the living record of what the system already does
+   `.devrites/principles.md` if present) the declared invariants the feature must respect.
+   **Consult the capability ledger**: the living record of what the system already does
    ([`ledger.md`](../rite-ship/reference/ledger.md)): `devrites-engine ledger list` for the
    capabilities on record, then `devrites-engine ledger show <capability>` for any this feature
    touches. Also search prior decisions with `devrites-engine decisions search "<2-4 feature nouns>"`
    before asking the human to re-decide a settled architecture/API/auth choice. Starting from the proven contract (not a cold re-derive) is what makes the spec store
    compound across features; it also tells you which requirements are new vs a change to existing
    behavior, which decides the delta kind in step 5.
-3. **Gather design references (optional)** — [references-intake](reference/references-intake.md).
-   The human **may** attach screenshots, mockups, a Figma link, a video, or links — or
+3. **Gather design references (optional):** [references-intake](reference/references-intake.md).
+   The human **may** attach screenshots, mockups, a Figma link, a video, or links, or
    **none at all** (perfectly normal; skip this step then). If any are given: **view/fetch**
    them, **save local files** into `.devrites/work/<slug>/references/`, and index them in
    `references.md` as target, constraint, or inspiration. Later phases honor that role
    rather than treating every reference as a fidelity target.
    **Completion:** every supplied reference is saved and classified, or absence is explicit.
-3a. **Shape the UX/UI before code (if the feature touches UI)** — when this feature is
+3a. **Shape the UX/UI before code (if the feature touches UI)**, when this feature is
    frontend ([frontend-trigger](../rite-build/reference/frontend-trigger.md)), apply
-   `devrites-ux-shape` **now**, woven into the spec — not as a separate phase. It turns the
+   `devrites-ux-shape` **now**, woven into the spec, not as a separate phase. It turns the
    references + the spec into a feature-level **`design-brief.md`** (design direction, key
    states, interaction model, optional Figma/image visual-direction probe) that `$rite-build`
    targets so the UI is built to plan, not guessed. In HITL it pauses for the human to
    confirm the direction; in AFK it asserts the best guess and logs it. Pure
    backend/data/CLI features skip this.
-4. **Close the gaps with the human — you recommend, the human decides.** Every material gap
+4. **Close the gaps with the human. You recommend, the human decides.** Every material gap
    (one that moves **objective · scope · placement · data model · UX · integration ·
    non-functional · security · migration risk · acceptance**) is **put to the human as a ranked
-   option set**, one gap at a time, via the harness `AskUserQuestion` in HITL: **2–4 concrete
+   option set**, one gap at a time, via the harness `AskUserQuestion` in HITL: **2-4 concrete
    options, your recommended one first and marked `(Recommended)`**, each with a one-line
    rationale + trade-off tagged by the dimensions that matter, plus an escape hatch (*Something
-   else — I'll describe it*). Render contract + AFK behaviour: the **Option set** section of
+   else. I'll describe it*). Render contract + AFK behaviour: the **Option set** section of
    [`afk-hitl.md`](../devrites-lib/reference/standards/afk-hitl.md); spec-phase question discipline:
    [question-protocol](reference/question-protocol.md). Your job is to **investigate, rank, and
-   recommend** — not to settle a material decision yourself. **Confidence changes the *cost* of
-   the question, not its *owner*:** when you're near-certain, you still present the set — the
-   human just confirms your `(Recommended)` option in one pick — you do **not** silently decide
+   recommend**, not to settle a material decision yourself. **Confidence changes the *cost* of
+   the question, not its *owner*:** when you're near-certain, you still present the set (the
+   human just confirms your `(Recommended)` option in one pick) you do **not** silently decide
    it because you predicted the answer. Only a **genuinely reversible, low-impact** detail is
    auto-decided and logged to `assumptions.md`; when unsure whether a gap is material, ask.
    (Vague ask → `devrites-interview`; rough idea → `$rite-pressure-test`.) For a vague ask,
    load [`reference/interview-patterns.md`](reference/interview-patterns.md), **map the decision
-   tree**, and resolve each branch depth-first; **cover every dimension** —
+   tree**, and resolve each branch depth-first; **cover every dimension**:
    each resolved by a human pick or explicitly deferred (logged, non-blocking), never silently
    skipped. Aim for **zero blocking gaps**. *If a gap is genuinely undecidable on paper (state
    machine that may deadlock, data shape ambiguity, "which UX wins") → suggest a
    scoped detour to `$rite-prototype` to answer that ONE question before
    continuing.* **Invariant conflict is a blocking gap:** if a requirement or acceptance
    criterion can only be satisfied by breaking a declared principle (`.devrites/principles.md`),
-   surface it — the principle wins by default; breaking it needs a recorded, scoped exception a
+   surface it: the principle wins by default; breaking it needs a recorded, scoped exception a
    human approves, never a spec that silently contradicts an invariant.
 5. **Create the workspace** + set `.devrites/ACTIVE`
    ([state-workspace](reference/state-workspace.md)). Write compact `README.md`,
-   `brief.md`, and `spec.md` ([spec-template](reference/spec-template.md)) — WHAT/WHY,
+   `brief.md`, and `spec.md` ([spec-template](reference/spec-template.md)). WHAT/WHY,
    technology-agnostic, with requirements, acceptance, edge cases, scope boundaries, links
    to future `architecture.md` / `traceability.md`, and measurable acceptance
    ([acceptance-criteria](reference/acceptance-criteria.md)). For a
@@ -160,8 +160,8 @@ stay flat `AC-###` bullets; the grammar is opt-in by rigor, never forced.
    `### Requirement:` (SHALL) + `#### Scenario:` (WHEN/THEN) block per
    [`spec-grammar.md`](../devrites-lib/reference/standards/spec-grammar.md), nesting the `AC-###` id inside each scenario
    so `$rite-seal` still grades it; routine criteria stay flat `AC-###` bullets. **When a
-   capability the ledger already holds is changing, write those requirements as deltas** —
-   `## ADDED / MODIFIED / REMOVED Requirements — capability: <c>` (spec-grammar.md § Delta form) —
+   capability the ledger already holds is changing, write those requirements as deltas**:
+   `## ADDED / MODIFIED / REMOVED Requirements — capability: <c>` (spec-grammar.md § Delta form):
    so the change, not just the end state, is explicit and `$rite-ship` folds it cleanly; a
    capability with no ledger entry stays flat (the first sync seeds it). Also
    write `brief.md`, `references.md`, `questions.md`, `decisions.md`, `assumptions.md`,
@@ -176,19 +176,19 @@ stay flat `AC-###` bullets; the grammar is opt-in by rigor, never forced.
    ```bash
    devrites-engine context sync || true
    ```
-5a. **Score the spec prose — "unit tests for English"** ([spec-checklists](reference/spec-checklists.md)).
+5a. **Score the spec prose: "unit tests for English"** ([spec-checklists](reference/spec-checklists.md)).
    Emit `.devrites/work/<slug>/checklists/<domain>.md` (one per requirement domain the spec covers:
    functional · data-model · interaction · non-functional · edge-cases). Each tests the *requirement
-   prose* for completeness / clarity / measurability — "is 'prominent' quantified?", "is every
-   enumeration closed?" — **not** the implementation. Fix each CRITICAL fail by editing the spec
+   prose* for completeness / clarity / measurability: "is 'prominent' quantified?", "is every
+   enumeration closed?", **not** the implementation. Fix each CRITICAL fail by editing the spec
    (not by softening the question); minor fails are logged. The checklists feed the readiness gate.
 6. **Run the spec readiness gate** (bottom of spec-template): no blocking
    `[NEEDS CLARIFICATION]`, placement decided, all material gaps resolved, any design
    references provided are saved, **UX/UI shaped into `design-brief.md` if the feature is
    UI**, requirements testable, success criteria measurable, **one-sentence intent** (the whole
-   change states its intent in a single sentence — if it can't, it is two features: split it or
+   change states its intent in a single sentence (if it can't, it is two features: split it or
    narrow the scope), **every `checklists/<domain>.md` at
-   `Verdict: pass`**, and **any structured requirement blocks are grammar-valid** — run
+   `Verdict: pass`**, and **any structured requirement blocks are grammar-valid**) run
    `devrites-engine spec-skeleton` first, then `devrites-engine spec-validate` with
    `--against .devrites/specs` so any delta sections are also
    reconciled against the ledger (an ADDED that already exists, or a MODIFIED/REMOVED that doesn't,
@@ -205,11 +205,11 @@ stay flat `AC-###` bullets; the grammar is opt-in by rigor, never forced.
    plus the hard gates), and `Build exactly this?` (yes → next phase; no → revise now). The digest
    is a view over `spec.md`, not a new artifact. **Stop** after the digest.
 
-> **Mid-flight discipline.** When tempted to skip investigation depth, gap-closing, or placement decisions — see [`anti-patterns`](reference/anti-patterns.md) (Common Rationalizations + Red Flags). Load it the moment you reach for the excuse.
+> **Mid-flight discipline.** When tempted to skip investigation depth, gap-closing, or placement decisions: see [`anti-patterns`](reference/anti-patterns.md) (Common Rationalizations + Red Flags). Load it the moment you reach for the excuse.
 
 ## Output
 
-**Progress first** — run `devrites-engine progress`, then use the shared completion reply contract
+**Progress first**: run `devrites-engine progress`, then use the shared completion reply contract
 ([`devrites-lib/reference/reply-contract.md`](../devrites-lib/reference/reply-contract.md)).
 Default success shape:
 ```
@@ -221,11 +221,11 @@ Next: $rite-temper
 Record: .devrites/work/<slug>/spec.md
 ↻ Hygiene: /clear before the next phase; $rite-handoff if away > a few hours
 ```
-If a workspace with the slug already exists, update its spec rather than overwriting blindly —
+If a workspace with the slug already exists, update its spec rather than overwriting blindly:
 and **show the human a short diff of what changed** in `spec.md` (acceptance criteria added /
 removed / reworded) before proceeding. A spec edit reviewed as a diff catches silent scope
 drift that a full re-read buries; this is the spec-review view (`$rite-spec --review` renders
 just the diff + the open-question delta, no re-investigation).
 
 When the ask overlaps the ACTIVE feature (same intent, >50% scope), route to
-`$rite-plan revise` — its gate decides — rather than minting a parallel workspace.
+`$rite-plan revise` (its gate decides) rather than minting a parallel workspace.

package/pack/generated/codex/skills/rite-spec/reference/acceptance-criteria.md

@@ -5,7 +5,7 @@ Acceptance criteria are the contract the seal checks. Write them so each is
 
 ## A good criterion
 - Is observable: a test passes, a command outputs X, a screenshot shows Y.
-- Is binary: met or not — no "mostly".
+- Is binary: met or not: no "mostly".
 - Names the evidence: "`npm test path/x.test.ts` passes" or "POST /export returns 200
   with a CSV body" or "empty state renders 'No exports yet' at 375px".
 - Belongs to a slice: every criterion maps to at least one slice (mapped in `$rite-define`).
@@ -21,10 +21,10 @@ Acceptance criteria are the contract the seal checks. Write them so each is
 | Negative | "<invalid input> is rejected with <message>, no <side effect>." |
 
 ## Anti-patterns
-- "Works well" / "is fast" / "looks good" — unverifiable. Attach a number or an
+- "Works well" / "is fast" / "looks good": unverifiable. Attach a number or an
   observation.
-- Criteria with no slice — orphaned scope.
-- Criteria only provable by reading the code — require runtime/test evidence instead.
+- Criteria with no slice: orphaned scope.
+- Criteria only provable by reading the code: require runtime/test evidence instead.
 
 ## At seal time
 Each criterion gets a checkbox + the evidence that proves it. Unproven critical

package/pack/generated/codex/skills/rite-spec/reference/anti-patterns.md

@@ -1,4 +1,4 @@
-# rite-spec — anti-patterns
+# rite-spec: anti-patterns
 
 Load this when standing a non-trivial decision in `$rite-spec`, or when the
 agent feels reluctance toward investigation depth, gap-closing, or
@@ -10,19 +10,19 @@ Pack-wide rationalizations + red flags: see [standards/anti-patterns.md](../../d
 
 | Excuse | Rebuttal |
 |---|---|
-| "User said *just make it work* — no spec needed." | Vague asks are exactly where `$rite-spec` earns its keep; load `devrites-interview` and ask one question at a time. |
+| "User said *just make it work*: no spec needed." | Vague asks are exactly where `$rite-spec` earns its keep; load `devrites-interview` and ask one question at a time. |
 | "I already understand the request." | Then writing the placement + acceptance criteria takes minutes and saves drift later. Investigation isn't for *you*, it's for `$rite-define`. |
 | "Too small for a spec." | If it's big enough for `$rite-build`, it's big enough for one paragraph of WHAT/WHY + measurable acceptance. |
-| "No design refs were attached, so skip references." | Skip the *gathering*, not the *acknowledgement*. Note "no references provided" in the spec — silence is ambiguous. |
+| "No design refs were attached, so skip references." | Skip the *gathering*, not the *acknowledgement*. Note "no references provided" in the spec: silence is ambiguous. |
 | "I can resolve gaps as I build." | Drift discovered at slice 3 costs more than 5 questions answered now. |
-| "I'm confident of the answer, so I'll just decide this myself." | Confidence changes the *cost* of the question, not its *owner*. A material decision (scope · placement · data model · UX · security · migration · acceptance) is put to the human as a ranked option set — near-certainty just makes it a one-pick confirm, never a silent decision. |
+| "I'm confident of the answer, so I'll just decide this myself." | Confidence changes the *cost* of the question, not its *owner*. A material decision (scope · placement · data model · UX · security · migration · acceptance) is put to the human as a ranked option set: near-certainty just makes it a one-pick confirm, never a silent decision. |
 | "Presenting options for every gap is over-asking." | Over-asking is many questions at once or asking what the codebase answers. One ranked option set per *material* gap, recommended-first, is the opposite: it hands the human the decision cheaply. Reversible low-impact details you still auto-decide and log. |
 
 ## Red Flags
 
 - About to start writing `spec.md` without a Placement & integration section.
-- Spec has no measurable acceptance criteria — "works as expected" is not measurable.
+- Spec has no measurable acceptance criteria: "works as expected" is not measurable.
 - A `[NEEDS CLARIFICATION]` marker remains on a blocking item.
 - Design references were attached but never opened, saved, or indexed in `references.md`.
 - The investigation didn't read the module/component that currently owns this area.
-- A material decision landed in `spec.md` / `assumptions.md` that the human never picked from an option set — decided on the agent's confidence alone.
+- A material decision landed in `spec.md` / `assumptions.md` that the human never picked from an option set: decided on the agent's confidence alone.

package/pack/generated/codex/skills/rite-spec/reference/interview-patterns.md

@@ -5,7 +5,7 @@ Each question still follows the protocol: one at a time, best guess attached.
 
 ## Vague ask? Map the decision tree first
 For a fuzzy one-liner (`"design a contact page"`, `"add reporting"`), sketch the branches
-the answer splits into, then resolve each **depth-first** — one branch to a decision before
+the answer splits into, then resolve each **depth-first**: one branch to a decision before
 opening the next:
 
 ```text
@@ -17,7 +17,7 @@ contact page
 ```
 
 Once per interview you may **challenge the premise** instead of refining it
-(*"is a form even the right answer, or a mailto / booking link?"*) — a good reframe
+(*"is a form even the right answer, or a mailto / booking link?"*): a good reframe
 collapses whole branches. Then use the domain ladders below for each open branch.
 
 ## Objective / problem
@@ -49,7 +49,7 @@ collapses whole branches. Then use the domain ladders below for each open branch
 - "Auth/permission rules? Anything sensitive (PII, secrets, payments)?"
 
 ## Acceptance
-- "How will we *prove* this works — what's the test or observation?"
+- "How will we *prove* this works: what's the test or observation?"
 - "What would make you reject the PR?"
 
 ## Anti-references (taste)

package/pack/generated/codex/skills/rite-spec/reference/investigation.md

@@ -1,8 +1,8 @@
-# Investigation — understand deeply before specifying
+# Investigation: understand deeply before specifying
 
 The spec is only as good as the investigation behind it. Goal: understand the
 requirement **completely**, decide **where it correctly belongs**, name what it
-**resolves**, and surface every **issue and gap** — then drive the gaps to closure with
+**resolves**, and surface every **issue and gap**, then drive the gaps to closure with
 the user so the spec ships fully-covered and correctly-placed. A gap found here is cheap;
 a gap found in `$rite-build` is a drift event.
 
@@ -10,47 +10,47 @@ Use a code-intelligence index if available (see
 `../../devrites-lib/reference/standards/tooling.md`) for the structural parts below; it answers "where does this
 live / what calls it / what would it break" far more cheaply and accurately than reading files.
 With none present, fall back to Read/Grep/Glob. When a gap turns on a fact the codebase can't
-answer — a standard, a prevailing UX pattern, how comparable products solve it — **search the
+answer: a standard, a prevailing UX pattern, how comparable products solve it: **search the
 web if available** (brave MCP preferred; `../../devrites-lib/reference/standards/tooling.md`) and cite the finding in
 the option you present, so the human's pick is informed rather than guessed.
 
-## Prior art — check our own archive first (cheap, silent when empty)
+## Prior art: check our own archive first (cheap, silent when empty)
 Before investigating outward, check whether we already shipped this. Grep the shipped
-archive for the feature's key nouns — a hit means an extension, a conflict, or a re-spec of
+archive for the feature's key nouns: a hit means an extension, a conflict, or a re-spec of
 solved work, and you inherit its decisions instead of re-deriving them:
 ```bash
 devrites-engine archive-search "<key nouns>" 2>/dev/null \
   || grep -rliE '<noun1>|<noun2>' .devrites/archive/*/spec.md 2>/dev/null
 ```
 - **Overlap found** → read the overlapping `spec.md` + its `decisions.md`, then put it to
-  the human as a ranked option — *extend the shipped feature* · *this supersedes it* ·
-  *genuinely distinct* — same option-set contract as a gap.
+  the human as a ranked option (*extend the shipped feature* · *this supersedes it* ·
+  *genuinely distinct*) same option-set contract as a gap.
 - **No archive / no hit** → skip silently; never block a spec on absent history (the
   brownfield / principles no-op discipline).
 
 ## Produce these findings (write into spec.md)
-1. **The real ask** — restate the goal and the *problem behind the request* (people ask
+1. **The real ask:** restate the goal and the *problem behind the request* (people ask
    for "a dashboard" when they want an answer to a question). Who hits it, how often,
    what they do today instead.
-2. **Current behavior** — how it works today, or what's absent. Read the actual code and
+2. **Current behavior:** how it works today, or what's absent. Read the actual code and
    flows; don't assume.
-3. **Placement — where it should live** *(so it's correctly placed to be used)*
+3. **Placement, where it should live** *(so it's correctly placed to be used)*
    - Which module / layer / file / component should own this; the right seam.
    - Existing patterns/components/utilities to **extend or reuse** instead of duplicating.
    - **Integration points**: callers and dependents, the data it reads/writes, the
-     APIs/events/contracts it touches (interface analysis — how it interacts with the
+     APIs/events/contracts it touches (interface analysis: how it interacts with the
      rest of the system).
-4. **What it resolves** — the outcome/value and how we'll *observe* it's resolved (feeds
+4. **What it resolves:** the outcome/value and how we'll *observe* it's resolved (feeds
    success + acceptance criteria).
-5. **Issues** — conflicts with existing code/UX/data/permissions, constraints, and
+5. **Issues:** conflicts with existing code/UX/data/permissions, constraints, and
    anything that makes the obvious approach wrong. Each issue gets a disposition.
-6. **Gaps** — unknowns, ambiguities, undecided behavior, missing inputs. **Every gap
+6. **Gaps:** unknowns, ambiguities, undecided behavior, missing inputs. **Every gap
    becomes a question** (next section).
-7. **Blast radius** — what this change could break (use the code graph's impact/callers).
+7. **Blast radius:** what this change could break (use the code graph's impact/callers).
    Informs risks, test strategy, and rollback.
 
 Also gather any **design/reference materials** the human supplies (screenshots, Figma,
-links, video) — see [references-intake](references-intake.md). They're part of
+links, video): see [references-intake](references-intake.md). They're part of
 understanding the requirement and become the target later phases verify against.
 
 ## Gap analysis (present → desired)
@@ -58,9 +58,9 @@ State the **present state** and the **desired state**; the delta is the work, an
 **unknowns in the delta are the gaps**. Drive the count of open gaps toward zero before
 handing off to `$rite-define`. Mark each gap inline with `[NEEDS CLARIFICATION: question]`.
 
-## Turn gaps & issues into questions WITH options — you recommend, the human decides
+## Turn gaps & issues into questions WITH options: you recommend, the human decides
 For each material gap/issue (one that changes scope, placement, data model, UX, security,
-migration risk, or acceptance), **put it to the human** — one gap at a time, as a ranked
+migration risk, or acceptance), **put it to the human**: one gap at a time, as a ranked
 option set with the recommended option **first and marked `(Recommended)`** plus an escape
 hatch (via `AskUserQuestion` in HITL):
 ```
@@ -71,7 +71,7 @@ hatch (via `AskUserQuestion` in HITL):
 4. Something else — I'll describe it
 ```
 Investigate and recommend; don't settle a material decision yourself. Confidence in the answer
-lowers the *cost* of the question (a one-pick confirm), not its owner — present the set anyway.
+lowers the *cost* of the question (a one-pick confirm), not its owner: present the set anyway.
 Only a **genuinely reversible, low-impact** gap is decided and recorded in `assumptions.md`
 without asking. Full render contract + AFK behaviour: [`afk-hitl.md`](../../devrites-lib/reference/standards/afk-hitl.md).
 
@@ -79,6 +79,6 @@ without asking. Full render contract + AFK behaviour: [`afk-hitl.md`](../../devr
 - The shipped archive was checked for prior art; any overlap was surfaced to the human.
 - The real problem, current behavior, placement, and what-it-resolves are written down.
 - Every issue has a disposition; every material gap is resolved **by a human pick** from its
-  option set (or explicitly deferred as non-blocking) — not settled silently on your confidence.
-- No blocking `[NEEDS CLARIFICATION]` remains — the spec is **fully covered and correctly
+  option set (or explicitly deferred as non-blocking), not settled silently on your confidence.
+- No blocking `[NEEDS CLARIFICATION]` remains: the spec is **fully covered and correctly
   placed**. This is the `$rite-spec` readiness gate before `$rite-define` plans it.

package/pack/generated/codex/skills/rite-spec/reference/question-protocol.md

@@ -7,16 +7,16 @@ and completion. The shared HITL/AFK rendering contract lives in
 
 This reference owns only the spec-specific coverage and recording rules below.
 
-## Coverage gate — am I done asking?
+## Coverage gate: am I done asking?
 Before declaring the interview complete, each dimension is **resolved** or **explicitly
-deferred** (logged, non-blocking) — never silently skipped:
-- [ ] **Objective** — one-sentence success + the real problem behind it.
-- [ ] **Scope** — what's in vs explicitly out for v1.
-- [ ] **Data model** — core entities + relationships (or "none").
-- [ ] **UX / flow** — happy path + empty / loading / error / permission states (or "no UI").
-- [ ] **Integration** — external systems / APIs / contracts (or "none").
-- [ ] **Non-functional** — auth, sensitive data, latency / scale (or "n/a").
-- [ ] **Acceptance** — how each requirement is *proven* (test / observation).
+deferred** (logged and non-blocking), never silently skipped:
+- [ ] **Objective:** one-sentence success + the real problem behind it.
+- [ ] **Scope**: what's in vs explicitly out for v1.
+- [ ] **Data model**: core entities + relationships (or "none").
+- [ ] **UX / flow**: happy path + empty / loading / error / permission states (or "no UI").
+- [ ] **Integration**: external systems / APIs / contracts (or "none").
+- [ ] **Non-functional**: auth, sensitive data, latency / scale (or "n/a").
+- [ ] **Acceptance**: how each requirement is *proven* (test / observation).
 
 A blocking gap in any dimension keeps the interview open; a deferred one goes to
 `questions.md` and doesn't block. This feeds the `$rite-spec` readiness gate.

package/pack/generated/codex/skills/rite-spec/reference/references-intake.md

@@ -1,4 +1,4 @@
-# Reference intake — design/style materials from the human
+# Reference intake: design/style materials from the human
 
 During spec, the human may supply screenshots, Figma, video, sites, or docs showing how the
 feature should look or behave. When present, inspect them, save local copies, and classify
@@ -6,14 +6,14 @@ each as a fidelity **target**, hard **constraint**, or **inspiration** so a mood
 cannot become a pixel-match contract. No references is valid; skip this intake.
 
 ## Gather + understand each reference
-- **Images / screenshots / mockups** — open and **view** them (the Read tool renders
+- **Images / screenshots / mockups:** open and **view** them (the Read tool renders
   images). Describe what they show: layout, components, spacing, states, the target look.
-- **Figma link** — if a Figma integration is available, pull its design context (frames,
+- **Figma link:** if a Figma integration is available, pull its design context (frames,
   tokens, components); otherwise record the link and ask the human for an export/screenshot
   so there's something concrete to match offline.
-- **Links / reference sites / docs** — fetch and read for the relevant intent (tone,
+- **Links / reference sites / docs:** fetch and read for the relevant intent (tone,
   layout, interaction, quality bar). Capture *why* it's a reference, not just the URL.
-- **Video** — note what it demonstrates (the expected interaction/flow). Save it; later
+- **Video:** note what it demonstrates (the expected interaction/flow). Save it; later
   phases can step through it as tooling allows.
 
 ## Save local assets into the workspace
@@ -45,14 +45,14 @@ composition, copy, or distinctive assets. Usage is normative too: only **may shi
 enter product code.
 
 ## Feed them into the spec + the design brief
-- Use references to sharpen `spec.md` (UI impact, success/acceptance — e.g. "matches R1").
+- Use references to sharpen `spec.md` (UI impact, success/acceptance: e.g. "matches R1").
 - When the feature touches UI, these references are the primary input to **`devrites-ux-shape`**
   (spec step 3a): they anchor the design direction and can seed the visual-direction probe
   (a Figma link → pulled design context; reference sites → screenshots). The resulting
   `design-brief.md` cites them by R-id **and role**.
-- A reference can *resolve a gap* ("which layout?") — record that in the gaps table.
+- A reference can *resolve a gap* ("which layout?"): record that in the gaps table.
 - If a reference **conflicts** with the existing design system, that's an issue to raise
-  with the human (match the system, or adopt the reference — their call).
+  with the human (match the system, or adopt the reference: their call).
 
 ## Later phases use them (wire-through)
 `devrites-frontend-craft` builds to the approved brief and its **target** references,

package/pack/generated/codex/skills/rite-spec/reference/spec-checklists.md

@@ -1,30 +1,30 @@
-# Spec-quality checklists — "unit tests for the English"
+# Spec-quality checklists: "unit tests for the English"
 
 Before the spec hands off to `$rite-define`, test the **requirement prose itself** the way you'd
 unit-test code: is each requirement complete, unambiguous, and measurable? These checklists
-interrogate the *writing*, not the implementation — there is no code to run yet. A criterion like
+interrogate the *writing*, not the implementation. There is no code to run yet. A criterion like
 "the banner is prominent" passes a human skim and fails here ("prominent" is unquantified).
 Catching it now is a one-line spec edit; catching it at `$rite-prove` is a reslice.
 
-**Not implementation tests.** A checklist item asks "is *export* defined for an empty dataset?" —
+**Not implementation tests.** A checklist item asks "is *export* defined for an empty dataset?":
 it does **not** ask "does `exportCsv()` handle `[]`?". The first tests the spec; the second is
 `$rite-vet`'s test-plan and `$rite-prove`'s job. These files never name a function, file, or library.
 
-## Output — one file per requirement domain
+## Output: one file per requirement domain
 
-Emit `.devrites/work/<slug>/checklists/<domain>.md`, one per domain the spec actually covers (skip
+Emit `.devrites/work/<slug>/checklists/<domain>.md`, one per domain the spec covers (skip
 a domain the spec marks "none"). The domains mirror the interview taxonomy, so a gap here maps to a
 `devrites-interview` dimension:
 
 | Domain file | Tests the prose of |
 |---|---|
-| `functional.md` | Functional requirements + scenarios — is each capability stated, bounded, testable? |
-| `data-model.md` | Key entities / data model — shapes, fields, lifecycle, relationships (skip if "none"). |
-| `interaction.md` | API / UI impact + UX states — every screen state and contract named (skip if no UI/API). |
+| `functional.md` | Functional requirements + scenarios: is each capability stated, bounded, testable? |
+| `data-model.md` | Key entities / data model: shapes, fields, lifecycle, relationships (skip if "none"). |
+| `interaction.md` | API / UI impact + UX states: every screen state and contract named (skip if no UI/API). |
 | `non-functional.md` | Constraints, auth / data sensitivity, latency / scale / compatibility budgets. |
 | `edge-cases.md` | Empty / boundary / invalid / concurrent / failure paths the requirements imply. |
 
-## Each item — a question, a verdict, the line it interrogates
+## Each item: a question, a verdict, the line it interrogates
 
 ```markdown
 # Spec checklist: <domain> — <slug>
@@ -38,24 +38,24 @@ Scored: <iso>   Verdict: pass | gaps (<n CRITICAL / n minor>)
 ```
 
 Verdict is `pass` / `fail` / `n/a`. A `fail` carries a severity:
-- **CRITICAL** — the ambiguity would change the build or its acceptance: an unquantified
+- **CRITICAL:** the ambiguity would change the build or its acceptance: an unquantified
   acceptance/success criterion, an incomplete enumeration in a requirement, an ambiguous data
   shape, an undefined edge case on a stated flow, a contradictory pair of requirements.
-- **minor** — vague but non-load-bearing prose. Record it; it does not block.
+- **minor:** vague but non-load-bearing prose. Record it; it does not block.
 
-## The question bank (seed — extend per domain)
+## The question bank (seed: extend per domain)
 
 Each question tests one of the failure modes of requirement prose:
-- **Measurability** — every "good / fast / prominent / simple / secure" carries a number, a budget,
+- **Measurability:** every "good / fast / prominent / simple / secure" carries a number, a budget,
   or a named reference. No adjective stands in for a threshold.
-- **Completeness** — every enumeration is closed (no "etc."); every requirement with a precondition
+- **Completeness:** every enumeration is closed (no "etc."); every requirement with a precondition
   states the failure branch; every entity names its required fields + lifecycle; every stated flow
   names its empty / error / boundary behaviour.
-- **Clarity** — one entity, one name (no `user`/`customer`/`account` drift); no requirement two
+- **Clarity:** one entity, one name (no `user`/`customer`/`account` drift); no requirement two
   readers would implement differently; no "should" where "MUST" is meant.
-- **Testability** — each acceptance criterion is binary and names (or clearly implies) its evidence.
+- **Testability:** each acceptance criterion is binary and names (or clearly implies) its evidence.
   A criterion only provable by reading code is a fail.
-- **Consistency** — no requirement contradicts another, the data model, or a non-goal.
+- **Consistency:** no requirement contradicts another, the data model, or a non-goal.
 
 ## How it feeds the readiness gate
 
@@ -63,11 +63,11 @@ The spec **Readiness gate** (bottom of [`spec-template.md`](spec-template.md)) f
 emitted `checklists/<domain>.md` must reach `Verdict: pass` (zero CRITICAL fails) before the gate
 passes. Minor fails are logged, not blocking. A single open CRITICAL keeps the spec `Status: Draft`.
 `$rite-define` reads the checklists at its step 0 and **hard-blocks while any CRITICAL is unchecked**;
-a spec that skips the checklists is treated as not-yet-scored — define stops and routes back here.
+a spec that skips the checklists is treated as not-yet-scored: define stops and routes back here.
 
 ## Discipline
 - Score honestly. A checklist you pass by softening the *question* instead of the *spec* is the
-  spec-quality version of weakening a test to go green — it defeats the gate.
+  spec-quality version of weakening a test to go green. It defeats the gate.
 - Don't pad. Five real questions that find one CRITICAL beat thirty rubber-stamped rows.
 - These are *English* tests. The moment a question needs a function name to answer, it belongs in
   `$rite-vet`'s `test-plan.md`, not here.