devrites 3.0.7 → 3.2.0

package/pack/.claude/skills/rite-spec/reference/investigation.md

@@ -1,23 +1,21 @@
-# Investigation: understand deeply before specifying
+# Investigation before specification
 
-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
-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.
+Understand the requirement, decide where it belongs, define the outcome, and identify
+every issue and gap. Resolve material gaps with the user before the spec is ready. A
+gap first found during `/rite-build` is a drift event.
 
 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
-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.
+`../../devrites-lib/reference/standards/tooling.md`) for structural questions such as
+where code lives, what calls it, and what it could break. With none present, use
+Read/Grep/Glob. When a gap depends on an external fact, such as a standard, UX pattern,
+or comparable product, **search the web if available** (brave MCP preferred;
+`../../devrites-lib/reference/standards/tooling.md`). Cite the finding in the option
+presented to the human.
 
-## 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
-solved work, and you inherit its decisions instead of re-deriving them:
+## Check the archive first
+Before external research, check whether the project already shipped related work. Search
+the archive for the feature's key nouns. A hit may indicate an extension, conflict, or
+replacement and provides prior decisions:
 ```bash
 devrites-engine archive-search "<key nouns>" 2>/dev/null \
   || grep -rliE '<noun1>|<noun2>' .devrites/archive/*/spec.md 2>/dev/null
@@ -29,18 +27,18 @@ devrites-engine archive-search "<key nouns>" 2>/dev/null \
   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 request and problem:** restate the goal and the problem behind it (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
    flows; don't assume.
-3. **Placement, where it should live** *(so it's correctly placed to be used)*
+3. **Placement**
    - 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
      rest of the system).
-4. **What it resolves:** the outcome/value and how we'll *observe* it's resolved (feeds
+4. **Outcome:** the result and how to observe it (feeds
    success + acceptance criteria).
 5. **Issues:** conflicts with existing code/UX/data/permissions, constraints, and
    anything that makes the obvious approach wrong. Each issue gets a disposition.
@@ -48,19 +46,22 @@ devrites-engine archive-search "<key nouns>" 2>/dev/null \
    becomes a question** (next section).
 7. **Blast radius:** what this change could break (use the code graph's impact/callers).
    Informs risks, test strategy, and rollback.
+8. **Human prerequisites:** credentials, accounts, approval windows, or irreversible
+   action-time decisions the acceptance path requires. Separate these from agent-owned
+   implementation and diagnostic work.
 
-Also gather any **design/reference materials** the human supplies (screenshots, Figma,
-links, video): see [references-intake](references-intake.md). They're part of
-understanding the requirement and become the target later phases verify against.
+Gather any design or reference materials the human supplies, including screenshots,
+Figma, links, or video. See [references-intake](references-intake.md). Record whether
+each is a target, constraint, or inspiration for later phases.
 
 ## Gap analysis (present → desired)
-State the **present state** and the **desired state**; the delta is the work, and the
-**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]`.
+State the present and desired states. Their delta defines the work; unknowns in that
+delta are gaps. Resolve them before `/rite-define`. Mark each gap inline with
+`[NEEDS CLARIFICATION: question]`.
 
-## 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
+## Present gaps and issues as options
+For each material gap or issue that changes scope, placement, data model, UX, security,
+migration risk, or acceptance, **ask the human** one gap at a time with a ranked
 option set with the recommended option **first and marked `(Recommended)`** plus an escape
 hatch (via `AskUserQuestion` in HITL):
 ```
@@ -70,15 +71,18 @@ hatch (via `AskUserQuestion` in HITL):
 3. <alternative> — <implication>
 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.
+Investigate and recommend, but do not settle a material decision. High confidence may
+make the answer a one-pick confirmation; it does not change the decision owner.
 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).
 
 ## Done when
 - 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.
+- The problem, current behavior, placement, and outcome 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
-  placed**. This is the `/rite-spec` readiness gate before `/rite-define` plans it.
+- Every foreseeable build-time human prerequisite is resolved, assigned, or justified as an
+  action-time gate; objective repair/retry work is not disguised as a question.
+- No blocking `[NEEDS CLARIFICATION]` remains. The spec covers the gaps found during
+  authoring and records correct placement. This is the `/rite-spec` readiness gate
+  before `/rite-clarify` performs the systematic topology scan.

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

@@ -17,13 +17,17 @@ deferred** (logged and non-blocking), never silently skipped:
 - [ ] **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).
+- [ ] **Human prerequisites**: credentials, approval windows, irreversible action-time gates
+  (or "none").
 
 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.
 
 ## Spec question boundary
-- Things the codebase answers (read it first).
-- Reversible implementation details (decide and note as an assumption).
+- Things the codebase, prior decisions, or authoritative docs answer (search them first).
+- Reversible implementation and test details (decide and note as an assumption).
+- Objective tooling/environment failures (record the prerequisite or technical blocker; never
+  ask the human to authorize the agent's repair work).
 - Everything at once "to be thorough." Thoroughness is depth on the few that matter.
 
 ## Record

package/pack/.claude/skills/rite-spec/reference/spec-checklists.md

@@ -1,27 +1,26 @@
-# Spec-quality checklists: "unit tests for the English"
+# Spec-quality checklists
 
-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
-"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.
+Before `/rite-define`, check that each requirement is complete, unambiguous, and
+measurable. These checklists evaluate the prose, not the implementation. For example,
+"the banner is prominent" fails because "prominent" has no threshold. Fixing that in
+the spec avoids a later reslice.
 
-**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.
+These are not implementation tests. Ask "is *export* defined for an empty dataset?", not
+"does `exportCsv()` handle `[]`?". Implementation checks belong to `/rite-vet` and
+`/rite-prove`. These files never name a function, file, or library.
 
 ## Output: one file per requirement domain
 
-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:
+Emit `.devrites/work/<slug>/checklists/<domain>.md`, one per domain the spec covers.
+Skip a domain marked "none". The domains match the interview taxonomy, so each gap 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). |
-| `non-functional.md` | Constraints, auth / data sensitivity, latency / scale / compatibility budgets. |
+| `non-functional.md` | Constraints, auth / data sensitivity, latency / scale / compatibility budgets, human-only proof prerequisites. |
 | `edge-cases.md` | Empty / boundary / invalid / concurrent / failure paths the requirements imply. |
 
 ## Each item: a question, a verdict, the line it interrogates
@@ -41,11 +40,11 @@ Verdict is `pass` / `fail` / `n/a`. A `fail` carries a severity:
 - **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 nonessential prose. Record it; it does not block.
 
-## The question bank (seed: extend per domain)
+## Question bank
 
-Each question tests one of the failure modes of requirement prose:
+Each question checks one requirement-prose failure mode:
 - **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
@@ -56,18 +55,20 @@ Each question tests one of the failure modes of requirement prose:
 - **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.
+- **Non-functional:** each NFR names affected REQ/AC IDs or a bounded `global` scope;
+  human-only proof prerequisites name their owner.
 
-## How it feeds the readiness gate
+## Readiness gate
 
-The spec **Readiness gate** (bottom of [`spec-template.md`](spec-template.md)) folds these in: every
+The spec **Readiness gate** at the bottom of
+[`spec-template.md`](spec-template.md) requires every
 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.
+`/rite-define` reads the checklists at step 0 and **hard-blocks while any CRITICAL is
+unchecked**. A spec without checklists is not yet checked, so 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.
+- Score honestly. Do not soften a checklist question to pass a weak spec.
 - 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.
+- If a question needs a function name, it belongs in `/rite-vet`'s `test-plan.md`.

package/pack/.claude/skills/rite-spec/reference/spec-template.md

@@ -1,13 +1,13 @@
 # `spec.md` template
 
 Write the product contract: WHAT users get, WHY it matters, how success is
-measured, and what is out of scope. Keep HOW in `plan.md`; put topology and
+measured, and what is out of scope. Keep HOW in `plan.md`; put technical topology and
 diagrams in `architecture.md` / `flows.md`; put coverage in `traceability.md`.
 
 Rules:
 
 1. Mark unknowns with `[NEEDS CLARIFICATION: <question>]`; blocking unknowns
-   stop `/rite-define`.
+   stop `/rite-clarify`.
 2. Use stable IDs: `REQ-001` for requirements and `AC-001` for acceptance.
 3. Link to source artifacts instead of duplicating them.
 4. Keep the file compact. If it exceeds the schema budget, add
@@ -84,11 +84,17 @@ Use `resolved/test`, `resolved/judgment`, `dismissed`, or `unresolved`.
 - Does not own: <adjacent area>.
 - Placement summary: <one-line module/layer summary>; full technical map lives in `architecture.md`.
 
+## Coverage seed
+- Actors/journeys/components: <material surfaces discovered while authoring>.
+- States/data/contracts/integrations: <material boundaries discovered>.
+- Operations/proof surfaces: <configuration, observability, rollout/rollback, evidence constraints>.
+
 ## References
 - `brief.md` - request, objective, non-goals, success definition.
 - `architecture.md` - technical placement and integration points.
 - `flows.md` - diagrams when useful.
 - `decisions.md` - ADR-style product/technical decisions.
+- `decision-coverage.md` - topology scan and clarity verdict once `/rite-clarify` runs.
 - `traceability.md` - AC/REQ coverage once `/rite-define` runs.
 - `design-brief.md` - UI direction when UI is in scope.
 
@@ -107,4 +113,5 @@ Use `resolved/test`, `resolved/judgment`, `dismissed`, or `unresolved`.
 - [ ] Non-goals and scope boundaries are explicit.
 - [ ] Architecture/flows/decisions are linked out instead of duplicated here.
 - [ ] UI work has `design-brief.md`; non-UI work states UI is out of scope.
+- [ ] Coverage seed names the material surfaces `/rite-clarify` must scan.
 ```

package/pack/.claude/skills/rite-spec/reference/state-workspace.md

@@ -19,9 +19,12 @@ Load that schema before creating or updating workspace artifacts.
       decisions.md
       assumptions.md
       questions.md
+      decision-coverage.md       # from /rite-clarify
       plan.md                    # from /rite-define
       tasks.md                   # from /rite-define
       traceability.md            # from /rite-define
+      eng-review.md              # from /rite-vet
+      test-plan.md               # from /rite-vet
       state.md
       evidence.md                # from /rite-build or /rite-prove (proof.md alias supported)
       browser-evidence.md        # UI only
@@ -46,8 +49,10 @@ canonical files and preserves aliases rather than deleting old ones.
 - `/rite-spec` creates the workspace map, `brief.md`, `spec.md`, `decisions.md`,
   `assumptions.md`, `questions.md`, `state.md`, optional `references.md` /
   `references/`, and optional `design-brief.md` for UI.
+- `/rite-clarify` adds `decision-coverage.md`.
 - `/rite-define` adds `architecture.md`, `plan.md`, `tasks.md`, and
   `traceability.md`.
+- `/rite-vet` adds `eng-review.md` and `test-plan.md`.
 - Later phases add only the artifact they own. Do not create optional files as
   empty placeholders; absence means the phase has not produced that artifact.
 - Each artifact starts with a summary and links to deeper source files instead of
@@ -61,7 +66,7 @@ canonical files and preserves aliases rather than deleting old ones.
 # <Feature> Workspace
 phase: spec
 status: running
-next_action: /rite-define after spec readiness passes
+next_action: /rite-clarify after spec readiness passes
 last_updated: <date>
 
 ## Artifact map
@@ -69,6 +74,7 @@ last_updated: <date>
 | --- | --- |
 | brief.md | Objective and bounds |
 | spec.md | Product contract |
+| decision-coverage.md | Clarification verdict; absent until /rite-clarify |
 | architecture.md | Technical map; absent until /rite-define |
 | plan.md | Technical approach; absent until /rite-define |
 | tasks.md | Vertical slices; absent until /rite-define |
@@ -79,7 +85,8 @@ last_updated: <date>
 | Phase / role | Read |
 | --- | --- |
 | Spec | brief.md, spec.md, questions.md |
-| Build | state.md, tasks.md, plan.md |
+| Clarify | spec.md, decisions.md, assumptions.md, questions.md |
+| Build | state.md, decision-coverage.md, eng-review.md, test-plan.md, tasks.md, plan.md |
 | Review | traceability.md, evidence.md, decisions.md |
 
 ## Blocking gates
@@ -100,6 +107,8 @@ None.
 | slice_mode | none |
 | risk | none |
 | next_action | <single command + reason> |
+| return_phase | <later phase; retrofit clarification only> |
+| return_next_action | <saved command; retrofit clarification only> |
 
 ## Awaiting human
 Only present when status is awaiting_human.
@@ -112,7 +121,8 @@ Only present when status is awaiting_human.
 
 `state.md` is a compact cursor, not a history file. Put proof in `evidence.md`,
 decisions in `decisions.md`, assumptions in `assumptions.md`, and drift in
-`drift.md`.
+`drift.md`. Omit both `return_*` rows outside a later-phase `/rite-clarify`
+retrofit; `devrites-engine clarify-return` owns their atomic lifecycle.
 
 ## questions.md entry format
 

package/pack/.claude/skills/rite-temper/SKILL.md

@@ -5,15 +5,13 @@ argument-hint: "[feature-slug] [--mode expand|selective|hold|reduce]"
 user-invocable: true
 ---
 
-# /rite-temper: temper the spec before you plan
+# /rite-temper: review scope and risk before planning
 
-Take a readied spec and **temper** it: heat it (raise ambition on the *outcome*), then
-quench it (pre-mortem + prune the *solution surface*): stronger and less brittle. The one
-DevRites step that decides scope/ambition on a written spec and folds the result into the
-canonical contract, so `/rite-define` plans the **hardened** spec. Optional for small work
-(significance-gated: auto-skips low-stakes specs), but always invoked inside
-`/rite-autocomplete`. **Read the active workspace first**; if there's no readied
-`spec.md`, tell the user to run `/rite-spec`.
+Review a readied spec for outcome ambition, scope, pre-mortem risks, and unnecessary
+solution surface. Fold accepted decisions into the canonical contract before
+`/rite-define`. This step is optional for small work and skips low-stakes specs, but
+`/rite-autocomplete` always invokes it. **Read the active workspace first**; if there
+is no readied `spec.md`, tell the user to run `/rite-spec`.
 
 ## Rules consulted (read on demand from `.claude/skills/devrites-lib/reference/standards/`)
 Pull on demand: `patterns.md` +
@@ -23,65 +21,70 @@ invent one), `documentation.md` (ADR-style `decisions.md` entries), `afk-hitl.md
 that needs more than the default pre-mortem) selected by the section's risk).
 
 ## Operating rules
-- **Ambition on outcomes, minimalism on the surface.** Raise the success bar and solve the
-  *real* problem; never add speculative capability/abstraction. The reconciliation hinge:
-  bigger ambition, smaller surface.
-- **Every scope change routes through the Spec Drift Guard:** it only becomes real by being
-  written into `spec.md` as a recorded, confirmable decision. Expansion is **opt-in** (HITL
+- **Raise outcome ambition without expanding the solution unnecessarily.** Solve the
+  underlying problem without adding speculative capability or abstraction.
+- **Route every scope change through the Spec Drift Guard.** A scope change takes effect
+  only when `spec.md` records the confirmed decision. Expansion is **opt-in** (HITL
   confirm; AFK pauses: see autocomplete policy). Nothing auto-grows into the build.
-- **Bound ambition by reversibility.** Auth / migration / public-API / data-model touches get
-  the *opposite* of ambition: maximum conservatism; they always pause (irreversible-risk list).
+- **Apply maximum caution to hard-to-reverse changes.** Auth, migration, public API, and
+  data-model changes always pause under the irreversible-risk list.
 - **Honest verdict.** Never round "needs work" up to "ready"; record every scope call's *why*.
+- **Search before asking.** Apply `afk-hitl.md` decision ownership; only human-owned calls
+  enter the interactive walk.
 - **You write; the reviewer judges.** You are the single canonical writer (`strategy.md` +
   the spec edits); the reviewer agent is read-only.
-- **Demand the spec-quality checklists for big features.** `/rite-temper` only fires on
-  significant specs: exactly where vague requirement prose is most expensive. Before hardening,
+- **Require spec-quality checklists for significant features.** Before hardening,
   confirm `checklists/<domain>.md` exist and pass (`rite-spec/reference/spec-checklists.md`); a
   scope expansion you fold in **adds its own** rows (new Success/Acceptance criteria get
-  "unit-tested for English" too). A folded expansion with an unquantified criterion is a CRITICAL
-  fail that re-opens the readiness gate.
+  checklist rows too). A folded expansion with an unquantified criterion is a CRITICAL
+  failure that reopens the readiness gate.
 
 ## Workflow
 0. **Read `.claude/skills/devrites-lib/reference/standards/core.md`**, then run
    `devrites-engine preamble` for deterministic workspace orientation.
-   Then read the workspace: `spec.md` (+ `decisions.md`,
+   Then read the workspace: `spec.md`, `decision-coverage.md` (+ `decisions.md`,
    `assumptions.md`, `design-brief.md` if UI), `state.md`. Require `Spec gate: passed`: else
-   STOP → `/rite-spec`. If a plan already exists, scope changes route through `/rite-plan
+   STOP → `/rite-spec`. Require `Decision coverage: CLEAR`: else STOP →
+   `/rite-clarify`. If a plan already exists, scope changes route through `/rite-plan
    repair` (record in `drift.md`), not a blind spec edit.
 1. **Significance test:** [`reference/significance.md`](reference/significance.md). Low-stakes
-   / shape-not-meaning work → write the one-line `skipped — low stakes (<trigger>)` verdict to `strategy.md`,
+   / shape-not-meaning work → write the exact one-line `skipped — low stakes (<trigger>)` verdict to `strategy.md`,
    set `state.md` `Next step: /rite-define`, and recommend it. Otherwise fire the full pass below.
 2. **FORWARD pass + mode selection:** [`reference/scope-modes.md`](reference/scope-modes.md).
    First, the **one-sentence-intent test**: state the whole change's intent in a single sentence.
    If you can't without an "and" that joins two unrelated outcomes, it is **two features**: the
-   sharpest scope-creep signal there is; recommend splitting the spec (or narrowing this one) before
-   tempering further. Then diverge on the *outcome* (the 10-star version of the real problem), and
-   commit **exactly one** scope mode (`expand` opt-in · `selective` · `hold-rigor` · `reduce-to-MVP`)
-   with its rationale and the **hinge** (what would change the call). `$ARGUMENTS` `--mode` is a
+   scope-creep signal; recommend splitting or narrowing the spec before continuing.
+   Then consider the 10-star outcome for the underlying problem and choose **exactly one**
+   scope mode (`expand` opt-in · `selective` · `hold-rigor` · `reduce-to-MVP`) with its
+   rationale and the condition that would change the choice. `$ARGUMENTS` `--mode` is a
    hint, not a command.
 3. **INVERSION pass:** pre-mortem in past tense ("it shipped and failed: what went wrong"),
    each top risk carrying likelihood + mitigation + the slice it will bind to; then the **YAGNI
    ledger** (each candidate scope item gets the "imagine the later refactor" test; defer unless
    now-cost is trivial AND deferred-cost is large).
-   - **Deepen on demand.** When a specific scope call, requirement, or risk needs sharper thinking
-     than the default pre-mortem gives, pull the 3-5 techniques from
+   **Interruption pre-mortem:** audit the spec forecast and assumptions for unresolved behavior,
+   proof prerequisites, approvals, access, and irreversible gates. Resolve facts and reversible
+   details now; retain only unavailable-pre-code or mandatory action-time checkpoints.
+   - **Deepen on demand.** When a scope decision, requirement, or risk needs more analysis
+     than the default pre-mortem provides, choose 3-5 techniques from
      [`elicitation.md`](../devrites-lib/reference/standards/elicitation.md) whose *when-to-reach-for-it* matches that
      section's risk (irreversible decision → Red-Team/Blue-Team + Assumption Audit; sizing → Delphi;
-     vague requirement → Steelman-then-Attack), offer them, and run the chosen one **on that one
-     section**. Record what it changed, not that you ran it. Optional: the default passes stand on
-     their own.
+     vague requirement → Steelman-then-Attack), offer them, and run the chosen one **on that
+     section**. Record what changed, not the technique name. The default passes remain
+     sufficient when no deeper analysis is needed.
 4. **Score the 9 dimensions:** [`reference/review-dimensions.md`](reference/review-dimensions.md).
    Cite evidence *before* the band; **gate on the floor** (the weakest dimension, not an average).
    **Completion:** all nine dimensions have cited evidence, a band, and one explicit floor verdict.
-5. **Walk the findings WITH the human: do not batch-dump.** The artifact is the *output* of an
-   interactive review, not a substitute for it: surface each material scope call / finding via
+5. **Review human-owned findings with the human; do not batch them.** `strategy.md`
+   records the interactive review but does not replace it. Present each material scope decision through
    `AskUserQuestion`, one at a time, best-guess + **why**. Each material scope call ends as a
    **recorded decision**: a resolved `questions.md` qid (HITL) or a `decisions.md` ADR (AFK):
-   so the walk leaves an auditable trail, not just chat. (AFK gate policy is single-sourced in
+   so the review leaves an auditable record outside chat. (AFK gate policy is single-sourced in
    [`reference/significance.md`](reference/significance.md): `hold-rigor` + `reduce-to-MVP`
    auto-apply, **any `expand` is a blocking pause**, irreversible-risk always pauses.)
+   Apply objective clarity, mitigation, and assumption fixes directly.
 6. **Write `strategy.md` + fold back:** [`reference/strategy-template.md`](reference/strategy-template.md).
-   **One drift rule (decide by whether a plan exists):** *no `plan.md` yet* (the normal pre-define
+   **Choose the drift path based on whether a plan exists:** *no `plan.md` yet* (the normal pre-define
    case) → update `spec.md` **through the Spec Drift Guard**. *Success criteria* **and**
    *Acceptance criteria* for each opt-in expansion / cut, **Non-goals** for every deferred item,
    *Constraints* **and** *Risks* the pre-mortem demands, and the gaps/decisions table; *`plan.md`
@@ -90,22 +93,33 @@ that needs more than the default pre-mortem) selected by the section's risk).
    decision · why-not · what-would-change-it) and `assumptions.md` (every "we'll probably need X" →
    assumption-to-verify). **Every scope delta must carry a recorded human decision**: a resolved
    `questions.md` qid (HITL) or a `decisions.md` ADR (AFK within the ceiling); a folded change with
-   no recorded decision is the batch-dump failure. **Re-check the spec Readiness gate** (it fails if
-   any folded scope delta lacks its decision). Update `state.md`: `Phase: temper`,
+   no recorded decision is invalid. **Re-check the spec Readiness gate** (it fails if
+   any folded scope delta lacks its decision or leaves a foreseeable human build choice).
+   After any edit to `brief.md`, `spec.md`, `decisions.md`, `assumptions.md`, or
+   `questions.md`, re-scan the affected coverage rows, assumption audit, residual uncertainty,
+   and closed gates. Partial/Missing, an unowned material assumption, or an open
+   blocking/escalating question routes `/rite-clarify`/HITL; never refresh past it. Only after the
+   matrix is re-closed, run `devrites-engine readiness-digest coverage <slug>` and replace the
+   complete `Coverage inputs SHA-256` line in `decision-coverage.md`.
+   Update `state.md`: `Phase: temper`,
    `Next step: /rite-define`; on a blocking pause (expand / irreversible / a dimension still below
    bar) write the `Awaiting human` block + `Status: awaiting_human` before stopping.
 7. **Adversarial verification loop:** dispatch [`devrites-strategy-reviewer`](../../agents/devrites-strategy-reviewer.md)
-   (fresh context, **only** the hardened spec + the rubric: no authoring reasoning). Resolve
+   through the file-backed fresh-context contract in
+   [`agents.md`](../devrites-lib/reference/standards/agents.md), with **only** the hardened
+   spec + rubric: no authoring reasoning. Resolve
    actionable findings by editing `spec.md`/`strategy.md`, re-dispatch; **cap ≤3 iterations**. A
-   dimension still below bar after 3 → blocking question (HITL) or AFK gate-ceiling entry;
-   irreversible-risk findings always pause. If sub-agents are unavailable, do the independent
-   rubric pass yourself in a separate read, discarding the authoring reasoning (a flagged
-   fallback, not an independent review).
+   dimension still below bar after 3 is classified by decision ownership: a product/scope/risk
+   choice becomes a blocking question; an objective spec defect stays blocked with the exact
+   required edit and routes to `/rite-spec`, not `/rite-resolve`. Irreversible-risk findings
+   always pause. Use the shared capability ladder; an inline final-rung pass is labeled
+   `independence: fallback`, never an independent review. After an accepted edit to a
+   coverage-bound input, repeat step 6's revalidation and digest refresh before handoff.
 8. **STOP.** Report the mode, the scope deltas, and the floor verdict; recommend `/rite-define`.
 
-> **Mid-flight discipline.** When tempted to dump findings into `strategy.md` and skip the
-> walk-through, expand the surface (not the outcome), grow scope without the Drift Guard, or
-> score before citing evidence: see [`reference/anti-patterns.md`](reference/anti-patterns.md).
+> **Mid-flight discipline.** Do not replace the interactive review with `strategy.md`,
+> expand implementation surface without need, grow scope outside the Drift Guard, or score
+> before citing evidence. See [`reference/anti-patterns.md`](reference/anti-patterns.md).
 
 ## Output
 
@@ -115,12 +129,13 @@ Default success shape:
 ```
 Done: spec tempered for <slug>; mode <expand|selective|hold-rigor|reduce-to-MVP|skipped-low-stakes>.
 Changed: strategy.md, spec.md, decisions.md, assumptions.md
-Evidence: dimension floor <band>; reviewer loop <n>; spec readiness re-checked pass
+Evidence: dimension floor <band>; reviewer loop <n>; spec readiness + decision coverage re-checked pass
 Open: <none | n deferred non-goals>
 Next: /rite-define
 Record: .devrites/work/<slug>/strategy.md
 ↻ Hygiene: /clear before /rite-define
 ```
 If readiness is blocked, use the shared `Stopped / blocked` form and route `Fix:`
-to `/rite-spec`; do not recommend `/rite-define`.
+to `/rite-clarify` for an uncovered decision surface or `/rite-spec` for an objective
+spec defect; do not recommend `/rite-define`.
 **DO NOT plan, slice, or write code here**. That's `/rite-define` and `/rite-build`.

package/pack/.claude/skills/rite-temper/reference/review-dimensions.md

@@ -1,23 +1,25 @@
-# Review dimensions + the floor-gate rubric
+# Review dimensions and floor-gate rubric
 
-The spec is scored on nine dimensions. Each catches a *different* failure mode: strength in
-one never compensates for collapse in another, so the gate is the **floor**, not an average.
+Score the spec on nine dimensions. A strong dimension cannot offset a failed one, so
+the gate uses the **lowest band**, not an average.
 
 ## The nine dimensions
-1. **Problem altitude & ambition:** is this solving the *right* problem at the right altitude,
-   or timidly improving the obvious path / over-reaching past the real need? Here, *under-
-   reaching* on the outcome is a failure, not just over-building.
-2. **Scope honesty & boundary:** are Non-goals explicit? Is there a Minimum Usable Subset and a
-   clear IN/OUT line? Flags grab-bags and a missing "Won't-have-this-time".
-3. **Premise & alternatives:** are the load-bearing premises stated and challenged, and is at
+1. **Problem choice and ambition:** does the spec solve the underlying problem, or only
+   make a minor improvement to the obvious path? It may also reach beyond the actual need.
+   Both insufficient outcome ambition and over-building are failures.
+2. **Scope and boundary:** are non-goals explicit? Is there a Minimum Usable Subset and
+   a clear IN/OUT line? Flag unrelated bundles and a missing "Won't-have-this-time".
+3. **Premise and alternatives:** are the consequential premises stated and challenged, and is at
    least one genuinely different approach (different data model / flow / boundary) considered
    with its trade-off? ("Alternatives considered" is one of the most useful parts of a spec.)
-4. **Pre-mortem risk coverage:** run in prospective hindsight; each top risk carries likelihood
-   + mitigation + the slice that owns it. **Unmitigated top risks are gating.**
+4. **Pre-mortem risk coverage:** assess the feature as if it shipped and failed. Each top risk carries likelihood
+   + mitigation + the slice that owns it. The interruption pre-mortem accounts for foreseeable
+   human prerequisites and action-time approvals instead of deferring generic uncertainty to
+   build. **Unmitigated top risks are gating.**
 5. **Over-engineering / YAGNI:** speculative capability, unused extension points, premature
    abstraction, second-system bloat. Apply the pack's standard (`patterns.md`) + the "imagine
    the later refactor" test. Defer unless now-cost is trivial AND deferred-cost is large.
-6. **Acceptance testability & done-ness:** every acceptance criterion measurable, technology-
+6. **Acceptance testability and completion:** every acceptance criterion measurable, technology-
    agnostic, and comparable **down to a baseline** ("better than the current workaround"), not
    up to an unbounded ideal. Vague adjectives ("fast/robust/intuitive") and "handles X
    gracefully" are flagged.
@@ -34,9 +36,8 @@ UI specs also inherit `rite-polish/reference/anti-ai-slop.md` at the cross-cutti
 dimension (design-system fit, anti-AI-slop), but `/rite-temper` reviews the *spec/design-brief*,
 not pixels; the built UI is judged later by `devrites-frontend-reviewer`.
 
-## The rubric: coarse bands, evidence first
-Score each dimension on a **labeled band**, never a 1-10 float or a composite number (labels do
-the work: matches the pack's severity-vocabulary stance):
+## Rubric
+Score each dimension on a **labeled band**, never a 1-10 float or composite number:
 
 | Band | Meaning |
 |---|---|
@@ -45,9 +46,8 @@ the work: matches the pack's severity-vocabulary stance):
 | **thin** | Under-addressed; a real gap to close before planning (Important). |
 | **broken** | Missing or wrong in a way that will cost a redo (Critical). |
 
-**Cite evidence before the band**: name the spec line / absence that justifies it; never score
-first and rationalize after. Borderline dimensions may be sampled twice; take the **lower** band
-(don't average up).
+**Cite evidence before assigning the band.** Name the spec line or absence that
+justifies it. Review a borderline dimension twice if needed and use the **lower** band.
 
 ## The floor-gate
 - **Pass** only when every dimension is `adequate` or `strong` **and** no unmitigated top
@@ -57,9 +57,11 @@ first and rationalize after. Borderline dimensions may be sampled twice; take th
   Suggestion / Nit / FYI**) so they compose with `/rite-review` and `/rite-seal`. `broken` →
   Critical, `thin` → Important; **FYI is band-independent**: an observation on a `strong` /
   `adequate` dimension, not a failing band.
-- **Don't double-count overlap.** Some dimensions key on the same evidence (e.g. #7
+- **Do not double-count overlap.** Some dimensions use the same evidence (e.g. #7
   irreversibility & #9 convention-fit both touch codebase realism; #1 ambition & #2 scope both
   touch over/under-reach). Don't fail two dimensions for the *same* root cause: cite the
-  evidence once, band it once, so one problem isn't laundered into two floor failures.
-- Below-bar dimension after the ≤3-iteration reviewer loop → blocking question (HITL) or AFK
-  gate-ceiling entry. Irreversible-risk findings always pause regardless of band.
+  evidence once and assign one band so one problem does not create two floor failures.
+- Below-bar dimension after the ≤3-iteration reviewer loop → classify by decision ownership:
+  product/scope/risk uncertainty becomes a blocking question; an objective prose/coverage defect
+  routes back to `/rite-spec` without inventing a human decision. Irreversible-risk findings
+  always pause regardless of band.