devrites 3.0.7 → 3.2.0

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

@@ -7,19 +7,21 @@ user-invocable: true
 
 # /rite-polish: finish before review
 
-The "finish" phase. **Always** code-polishes; **and** runs UI normalize +
-design polish when the feature touches UI. Self-review the work to ship
-quality *before* handing it to `/rite-review`. The two-phase split (code,
-UI) lives in `reference/code.md` and `reference/ui.md`: read each on demand,
-don't load both up front.
+Polish code for every feature. When the feature touches UI, normalize and polish the
+UI as well. Complete this self-review before `/rite-review`. The code and UI phases
+live in `reference/code.md` and `reference/ui.md`; read only the phase in scope.
 
 ## Operating rules
 
 - **Functionality complete first.** Polish runs after `/rite-prove` (full
   feature proven).
 - Feature scope only.
-- For UI: **NEVER polish without normalizing first**: decoration on drift is
-  banned.
+- For UI, **normalize before polishing**. Do not add decoration on top of drift.
+- **Root selects; wright edits.** The controlling chat assesses and reconciles, but every
+  accepted source/test correction is dispatched to the sole writer,
+  `devrites-slice-wright`, through
+  [`agents.md`](../devrites-lib/reference/standards/agents.md). Never edit source inline or
+  run two correction writers concurrently.
 
 ## Orchestration
 
@@ -36,21 +38,25 @@ don't load both up front.
    `pages/`, `routes/`, `app/`, `views/`, `screens/`), Storybook stories,
    or design-token files. When in doubt, look for visual changes that need
    verification.
-3. **Always** read [`reference/code.md`](reference/code.md) and run **Phase 1
-   (code polish)**; if backend was touched, continue into **Phase 2 (backend
-   polish)** from the same file.
+3. **Always** read [`reference/code.md`](reference/code.md) and assess **Phase 1
+   (code polish)**; if backend was touched, assess **Phase 2 (backend polish)** from
+   the same file. Reconcile the findings, then send accepted corrections as one bounded
+   wright contract.
 4. **If UI scope detected** read [`reference/ui.md`](reference/ui.md), and read
-   `design-brief.md` if present (the UX/UI contract `devrites-ux-shape` shaped at spec and
-   `devrites-frontend-craft` refined while building) so the polish honors the agreed
-   direction + states. **Read the `## Visual Verdict` table in `browser-evidence.md` if present:
-   its `FAIL` and `PARTIAL` rows are the normalize/quality-bar worklist**: fix the root cause of
-   each (a missing state, an off-token CTA, an anti-slop hit), don't decorate around it. Then run
-   **Phase 3 (normalize)** → **Phase 4 (UI polish)**. Honor argument modes:
+   `design-brief.md` if present so the polish follows the direction and states established
+   by `devrites-ux-shape` and refined by `devrites-frontend-craft`. **Read the
+   `## Visual Verdict` table in `browser-evidence.md` if present:
+   its `FAIL` and `PARTIAL` rows are the normalize/quality-bar worklist**: identify the root
+   cause of each (a missing state, an off-token CTA, or an anti-slop hit) rather than
+   hiding it with decoration. Assess **Phase 3 (normalize)** → **Phase 4 (UI polish)**,
+   then send accepted UI
+   corrections to the wright (which invokes the relevant craft skill). Honor argument modes:
    - `bolder | quieter | distill | harden`: passed to Phase 4 as the
      emphasis dial.
-   - `normalize-only`: run Phase 3 and stop (no Phase 4).
-5. **Re-verify after any code edit:** polish edits code, so the proof from
-   `/rite-prove` no longer post-dates it. Run the relevant fast checks (the
+   - `normalize-only`: assess Phase 3 and stop (no Phase 4).
+5. **Re-verify after any code edit:** a wright correction invalidates prior proof, so
+   `/rite-prove` no longer post-dates it. Dispatch `devrites-proof-runner` for the affected
+   fast checks (the
    targeted tests for the touched files + typecheck/lint; browser re-check if UI
    changed) and record a **`Re-verification:`** line in `polish-report.md`. A
    polish that changed code without a green re-verification isn't finished.
@@ -58,10 +64,8 @@ don't load both up front.
 
 ## Refinement modes
 
-When the user (or your own assessment) names a direction the UI should move,
-pass it through to Phase 4. Modes don't bypass normalize + quality-bar work:
-they shape the polish *after* the system is aligned. See `reference/ui.md` for
-the mode table.
+Pass the requested UI direction to Phase 4. Modes do not bypass normalization or the
+quality bar; they apply after the system is aligned. See `reference/ui.md`.
 
 > **Mid-flight discipline.** When tempted to polish UI without normalize, cite
 > clean lint as proof of quality, skip Phase 2 on a backend diff, or delete a

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

@@ -6,10 +6,10 @@ disable-model-invocation: true
 argument-hint: "[the question the prototype is answering]"
 ---
 
-# /rite-prototype: throwaway code that answers ONE question
+# /rite-prototype: answer one question with throwaway code
 
-A prototype is **throwaway code that answers exactly one question**. The question
-chooses the shape: get the shape wrong and the whole prototype wastes the user's time.
+A prototype is throwaway code for exactly one question. Choose its shape from that
+question.
 
 ## 0. Read core rules
 
@@ -25,11 +25,12 @@ down. Examples that count as "the question":
 - "Which of these three settings layouts feels right?"
 - "Will the proposed state machine deadlock when X overlaps Y?"
 
-A vague question ("explore this feature") is not enough: push back once to sharpen it.
+A vague request such as "explore this feature" is not enough. Ask once for a specific
+question.
 
 ## 2. Pick the branch
 
-Read the user's prompt + the surrounding code. Two branches:
+Read the user's prompt and surrounding code, then choose one branch:
 
 | Question shape | Branch | Artifact |
 |---|---|---|
@@ -39,50 +40,48 @@ Read the user's prompt + the surrounding code. Two branches:
 If genuinely ambiguous and the user is AFK: pick by the surrounding code (backend module
 → Logic; page / component → UI) and state the assumption in a comment at the top.
 
-**Variations must differ in shape.** UI prototypes where the variations are just colour
-or padding tweaks teach nothing: push each variation to a different *information
-architecture* / *interaction model* so the user can pick a direction, not a polish.
+**Variations must differ in structure.** Colour or padding changes alone do not answer
+a design question. Give each variation a different information architecture or
+interaction model.
 
 ## 3. Rules that apply to both branches
 
-1. **Throwaway from day one, and visibly so.** Place the prototype next to where it
-   will eventually be used (so context is obvious) but name it so a casual reader sees
-   it's a prototype: `prototype/`, `__prototype__`, `.scratch/`, etc. Obey the project's
+1. **Mark it as throwaway.** Place the prototype near its eventual use, but use a name
+   that clearly identifies it: `prototype/`, `__prototype__`, `.scratch/`, etc. Obey the project's
    existing routing / module convention; don't invent a new top-level structure.
-2. **One command to run.** Use whatever task runner the project already has: `pnpm
-   <name>`, `python <path>`, `bun <path>`. The user must start it without thinking.
+2. **Provide one run command.** Use the project's existing task runner: `pnpm
+   <name>`, `python <path>`, or `bun <path>`.
 3. **No persistence by default.** State lives in memory. Persistence is usually the
    thing the prototype is *checking*, not a dependency. If the question explicitly
    involves a DB, hit a scratch DB or a local file with a name like
    `PROTOTYPE — wipe me`.
-4. **Skip the polish.** No tests. No error handling beyond what makes it run. No
-   abstractions. The point is learn fast, delete fast.
+4. **Skip polish.** Add no tests, abstractions, or error handling beyond what is needed
+   to run and answer the question.
 5. **Surface state.** After every action (Logic) or on every variant switch (UI), print
    or render the full relevant state so the user can see what changed.
-6. **Delete or absorb when done.** When the question has an answer, either delete the
-   prototype or fold the validated decision into the real code: don't leave it
-   rotting in the repo.
+6. **Delete or absorb when done.** After answering the question, delete the prototype
+   or fold the validated decision into production code.
 
 ## 4. Capture the answer
 
-The *answer* is the only durable output. Before declaring the prototype done, write
+The answer is the only durable output. Before declaring the prototype done, write
 one of:
 
 - An entry in the active feature's `decisions.md` (`.devrites/work/<slug>/decisions.md`)
   with the question and the answer.
 - A `NOTES.md` next to the prototype if no active feature exists.
 
-If the user is around, this is a quick conversation. If they're AFK, the prototype is
-complete only once the verdict is filled in: a blank `VERDICT: ___` is not an
-answer. Leave it marked **not yet complete** and queue the open question so a later pass
-fills the verdict before the prototype is deleted.
+If the user is present, ask for the verdict directly. In AFK, the prototype remains
+incomplete until the verdict is filled in. A blank `VERDICT: ___` is not an answer.
+Mark it **not yet complete**. Queue the question and do not delete the prototype until
+a later pass records the verdict.
 
 ## Where this slots in
 
-`/rite-prototype` is a **scoped detour**, not a phase of its own. Typical placements:
+`/rite-prototype` is a scoped detour, not a separate phase. Typical uses:
 
-- **Between `/rite-spec` and `/rite-define`:** a design question is undecidable on
-  paper; prototype it, capture the answer, return to `/rite-define`.
+- **During `/rite-clarify` (between spec and define):** a product/constraint question is
+  undecidable on paper; prototype it, capture the answer, return to `/rite-clarify`.
 - **Mid-build:** `/rite-build` hit a state-model ambiguity that the spec doesn't
   resolve. Drop into a Logic prototype, capture the answer, return.
 

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

@@ -7,11 +7,11 @@ user-invocable: true
 
 # /rite-prove: prove the completed feature
 
-Turn "I think it works" into recorded evidence for the **whole feature**. Read the active
-workspace first; if none, run `/rite-spec <feature>`.
+Record evidence for the **whole feature**. Read the active workspace first; if none,
+run `/rite-spec <feature>`.
 
-> **Differs from built-in `/verify` and `/run`:** those prove a single change /
-> launch the app. `/rite-prove` is feature-scoped. It walks `spec.md` acceptance
+> **Scope:** built-in `/verify` proves one change and `/run` launches the app.
+> `/rite-prove` covers a feature. It walks `spec.md` acceptance
 > criteria one-by-one, runs the full relevant test suite + build/typecheck/lint,
 > ascends the browser-proof ladder (step 4),
 > and writes `evidence.md` + `browser-evidence.md` keyed to the active
@@ -21,12 +21,13 @@ workspace first; if none, run `/rite-spec <feature>`.
 Read `tasks.md` + `state.md`. **If ANY slice is still pending/unbuilt, STOP** and tell the
 user to finish it with `/rite-build`: `/rite-prove` runs once, when the full task is
 complete, not after each slice. (Each slice already got its own targeted tests during
-`/rite-build`; this phase is the comprehensive proof of the assembled feature.)
+`/rite-build`; this phase proves the assembled feature as a whole.)
 
-**Never report a pass you didn't observe.** If a command couldn't run, say so and give exact manual steps.
+**Never report an unobserved pass.** If a command could not run, report that and give
+exact manual steps.
 
-**Re-runnable, scoped.** `/rite-prove` runs once when the full feature is assembled, but
-it can be **re-run scoped** afterwards: when `/rite-polish` or `/rite-review` edit code,
+**Scoped reruns are allowed.** `/rite-prove` runs once when the full feature is assembled.
+After `/rite-polish` or `/rite-review` edits code,
 the existing `evidence.md` no longer post-dates the change, so re-run `/rite-prove` over
 the affected criteria/routes to refresh proof before `/rite-seal`.
 
@@ -42,7 +43,7 @@ Pull these via `Read` when relevant:
   user flow): telemetry must be present **and observed to emit**, not assumed.
 - `developer-experience.md`: when the change ships a developer-facing surface (API / CLI / SDK /
   webhook / config / error messages / getting-started): **measure** the DX scorecard (run the flow,
-  time time-to-hello-world, capture the verbatim error text), don't assert it.
+  measure time-to-hello-world, and capture verbatim error text), rather than asserting it.
 - `definition-of-done.md`: standing Done bar: acceptance mapped, fresh proof, no open hard gates, scoped edits, rollback/docs where needed.
 
 
@@ -51,6 +52,10 @@ Pull these via `Read` when relevant:
   blocker; don't refactor unrelated code.
 - Spec Drift Guard applies: if tests/evidence reveal the spec is wrong, stop and handle
   drift (`rite-build/reference/spec-drift-guard.md`).
+- **Runner observes; root records; wright fixes.** Use the file-backed fresh-context
+  contract in [`agents.md`](../devrites-lib/reference/standards/agents.md). The root owns
+  the evidence verdict and canonical writes. Every accepted source/test correction is one
+  bounded `devrites-slice-wright` packet, never an inline edit.
 
 ## Workflow
 0. Read `.claude/skills/devrites-lib/reference/standards/core.md` first (the always-on operating rules); pull the
@@ -63,23 +68,28 @@ Pull these via `Read` when relevant:
    [test-command-discovery](reference/test-command-discovery.md): README, package
    scripts, Makefile, CI configs, Gemfile/Rakefile, pyproject, go.mod, Cargo.toml.
    **Completion:** exact runnable test/build/typecheck/lint commands are recorded or explicitly unavailable.
-3. **Run the full relevant test suite** for the feature (not a single slice), then the
-   relevant **build / typecheck / lint**.
-4. **UI feature?** Read `design-brief.md` + `references.md`, then run the browser proof ladder over the feature's routes:
+3. **Run proof in fresh context.** Freeze the candidate and dispatch
+   `devrites-proof-runner` with the exact commands, cwd, prerequisites, acceptance map,
+   and scratch boundary. Await and validate its observed full relevant test suite plus
+   **build / typecheck / lint** report. The runner writes no canonical evidence.
+4. **UI feature?** Include `design-brief.md`, `references.md`, routes, browser harness, and
+   allowed scratch path in the proof packet, then have the runner apply the browser proof ladder:
    [proof-ladder](reference/proof-ladder.md) + [browser-proof](reference/browser-proof.md)
    (`devrites-browser-proof`): routes, viewports, screenshots (opened + described),
    console, network, interaction paths, and the brief's proof targets. Compare screenshots
-   with target references, record deltas, fix/re-render, and do not pass with an unresolved
-   material mismatch.
+   with target references and record deltas. An unresolved material mismatch is a failed
+   result; the root handles any accepted correction at step 6 before re-rendering.
 5. **Map proof completely.** Follow
    [`reference/acceptance-proof.md`](reference/acceptance-proof.md) for acceptance/scenario
    coverage and the conditional critical-path, observability, developer-surface, and wiring
    branches. Completion: every criterion, planned interaction, and declared key link has a
    proof class plus passing evidence, or is recorded as a blocker.
 6. **On failure** → [failure-triage](reference/failure-triage.md) +
-   `devrites-debug-recovery`. Reproduce → isolate → fix within scope → re-run; if a fix
-   would exceed scope, record a blocker.
-7. Update `evidence.md`, `browser-evidence.md` (if UI), `traceability.md`, and
+   `devrites-debug-recovery`. The root reconciles the reproduction. Send an accepted,
+   in-scope correction to the sole writer, `devrites-slice-wright`; then freeze the new
+   candidate and dispatch a fresh proof runner for affected checks. If a fix would exceed
+   scope, record a blocker.
+7. The root updates `evidence.md`, `browser-evidence.md` (if UI), `traceability.md`, and
    `state.md`. New proof goes to `evidence.md` (`proof.md` is a read-only alias:
    see `devrites-lib/reference/workspace-artifact-schema.md`).
 

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

@@ -8,16 +8,16 @@ disable-model-invocation: true
 
 # /rite-resolve: answer the human gate
 
-`/rite-resolve` is the canonical resume verb for **async** human gates: a checkpoint that
-already paused and **stopped the session** (an AFK blocking/escalating/irreversible queue, or a
-HITL pause the human walked away from), plus `--batch`. When `/rite-build` asks a gap **inline**
+`/rite-resolve` resumes an **async** human gate: a checkpoint that already paused and
+**stopped the session** (an AFK blocking/escalating/irreversible queue, or a HITL pause
+left unanswered), plus `--batch`. When `/rite-build` asks a question **inline**
 via `AskUserQuestion` and the human is present, that pick resolves the gate **in place** through
 the same `devrites-engine resolve` writer. You don't type `/rite-resolve` for it. For the async case this
 skill takes the human's answer (or `--drop` / `--batch`), writes it to `questions.md`, updates
 `state.md` (clears `Awaiting human`, sets `Status: running`), and recommends the next command.
 
-It is **deliberately small**: one verb, one source of truth (`questions.md`), one cursor
-(`state.md`). The full AFK / HITL contract lives in
+It has one verb, one source of truth (`questions.md`), and one cursor (`state.md`). The
+full AFK / HITL contract lives in
 [`afk-hitl.md`](../devrites-lib/reference/standards/afk-hitl.md).
 
 ## Rules consulted (read on demand from `.claude/skills/devrites-lib/reference/standards/`)
@@ -45,9 +45,9 @@ Pull these via `Read` when shaping the resolve:
   unblocked slice's `Slice mode` (step 4, the named exception); everything else goes through
   the script, never by hand.
 - **Human gates are for human-only decisions, not the agent's work.** A `questions.md` entry the
-  human must answer is a genuine *decision* (a scope / design / risk call only the human can make).
-  Not a task the agent can do itself. If a question is really agent-doable ("should I write the
-  test?", "go implement X"), don't record a human answer that punts the agent's own job back to it:
+  human must answer is a genuine decision (a scope / design / risk call only the human can make),
+  not a task the agent can do. If a question is really agent-doable ("should I write the
+  test?", "go implement X"), do not record a human answer that returns the agent's work to it:
   flag the mis-tag and route it to the right skill (`/rite-build`, `/rite-plan unblock`,
   `devrites-debug-recovery`). The human resolves decisions; the agent does the work.
 
@@ -67,9 +67,10 @@ Pull these via `Read` when shaping the resolve:
    `tasks.md`. Confirm the qid is `status: open`. If `state.md` `Status` is not
    `awaiting_human` and the question's `gate` is `blocking`, surface the inconsistency
    before proceeding (don't auto-repair: flag it).
-3. **Render preview.** Echo the qid, the question, the proposed answer (if any), the
-   user's answer, and which slice unblocks. Stop here and ask `confirm? (y/N)` **unless**
-   the answer was provided non-interactively via `--batch`.
+3. **Apply explicit consent.** Supplying `<qid> "<answer>"`, `--drop`, or `--batch` is the
+   user's explicit consent for this local workspace mutation. Echo the qid, answer/drop,
+   and slice being unblocked, then continue immediately; do not ask the user to confirm the
+   command they just typed.
 4. **Mutate.** Run `devrites-engine resolve` with the same
    arguments. The script:
    - flips the qid's `status` to `answered` / `dropped` and stamps `answered_at` + `answer`;

package/pack/.claude/skills/rite-resolve/reference/answer-protocol.md

@@ -6,6 +6,9 @@ shapes, the batch file format, and the rules the underlying `devrites-engine res
 
 ## Three input shapes
 
+Each form is an explicit local mutation command. Supplying it is the confirmation; the
+skill applies it once after validation and reports the result instead of asking for `y` again.
+
 ### 1. Single answer
 
 ```

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

@@ -7,13 +7,13 @@ user-invocable: true
 
 # /rite-review: feature-scoped review
 
-Senior review of the **active feature scope only**. **Read the active workspace first**;
-if none, tell the user to run `/rite-spec <feature>`.
+Review the **active feature scope only**. **Read the active workspace first**; if none,
+tell the user to run `/rite-spec <feature>`.
 
-> **Differs from built-in `/code-review` in:** `/code-review` is a generic
-> diff review with no workspace context. `/rite-review` reads
+> **Scope:** `/code-review` is a generic diff review with no workspace context.
+> `/rite-review` reads
 > `.devrites/work/<slug>/spec.md` first, runs Spec ↔ Code-review axes as
-> parallel subagents (see [`parallel-dispatch.md`](../devrites-lib/reference/parallel-dispatch.md)), and gates feeding
+> parallel fresh-context reviewers (see [`parallel-dispatch.md`](../devrites-lib/reference/parallel-dispatch.md)), and gates feeding
 > into `/rite-seal`. Use `/code-review` for a one-off diff; use
 > `/rite-review` for a DevRites feature where the spec is the contract.
 
@@ -22,7 +22,7 @@ Pull these via `Read` when the diff demands them:
 - `code-review.md`: small PRs, severity labels, tests-first review focus.
 - `review-checklist.md`: compact pass/fail sweep before reporting the verdict.
 - `principles.md`: declared project invariants (`.devrites/principles.md`); a diff that violates one with no recorded exception is a Critical, blocking finding.
-- `testing.md`: confirm the tests prove the spec, not just pass.
+- `testing.md`: confirm that passing tests actually prove the spec.
 - `agents.md`: when to fan out to which review subagent.
 - `security.md`: when input / auth / data / integrations / secrets are in scope.
 - `security-checklist.md`: for the same security-sensitive scope, the compact trust-boundary sweep.
@@ -32,10 +32,14 @@ Pull these via `Read` when the diff demands them:
 - **Feature scope only.** Review touched files + the diff. **NO whole-project refactors,
   NO drive-by cleanup.** DO NOT delete suspected dead code outside this feature without
   asking. Spec Drift Guard applies.
-- **Reviews the finished product.** `/rite-polish` has already done **code simplification**
-  + UI normalize/polish. Review judges; if it reveals a real complexity issue polish
-  missed, flag it as a finding: don't re-run a simplification sweep here.
-- Findings are labeled (below). Re-prove after any change you make.
+- **Review the finished product.** `/rite-polish` has already simplified code and
+  normalized or polished UI. If review finds a remaining complexity issue, record it as
+  a finding rather than rerunning a simplification pass.
+- Findings are labeled (below). Re-prove after any accepted correction.
+- **Reviewers judge; root reconciles; wright fixes.** Follow
+  [`agents.md`](../devrites-lib/reference/standards/agents.md). The root owns the verdict and
+  canonical writes; every accepted source/test correction routes to
+  `devrites-slice-wright`.
 
 ## Workflow
 0. Read `.claude/skills/devrites-lib/reference/standards/core.md` first (the always-on operating rules); pull the
@@ -52,13 +56,14 @@ Pull these via `Read` when the diff demands them:
 2. **Review tests first:** do they prove the acceptance criteria? Missing,
    weak, or wrong tests are the first findings.
    **Completion:** every acceptance criterion maps to a proven test or a labeled finding.
-3. **Spec ↔ Code-review split (parallel sub-agents, fresh context).** A change can pass
+3. **Review spec and code separately in parallel.** A change can pass
    one axis and fail the other: code that follows every project standard but
    implements the wrong thing (Code-review pass, Spec fail), or code that does exactly
    what the spec asked but breaks project conventions (Spec pass, Code-review fail).
-   Running them serially in one context lets one mask the other. So:
-   - Dispatch **two** read-only reviewers in **parallel** via the `Task` tool, each
-     with its own narrow brief and no cross-pollination:
+   Separate contexts prevent one axis from masking the other:
+   - Freeze the candidate and fresh-context dispatch **two** read-only reviewers in
+     parallel, each with its own `agent-packet/v1`, narrow brief, and no
+     cross-pollination:
      - **Spec axis** → `devrites-spec-reviewer`: "Apply your documented discipline on
        the active feature workspace + diff. Report (a) criteria the spec asked for that
        are missing or partial, (b) behaviour in the diff the spec did not ask for
@@ -101,15 +106,20 @@ Pull these via `Read` when the diff demands them:
 6. **Performance:** apply `devrites-audit perf`
    ([performance-review](reference/performance-review.md)) only when performance is
    relevant or a regression risk is visible (measure first).
-7. Apply only in-scope fixes; **run verification after changes** (`/rite-prove` logic).
-8. Update `review.md`, `evidence.md`, and `state.md`.
-9. **Guard against the silent reviewer.** After `review.md` is written, run:
+7. Reconcile and accept only in-scope fixes. Consolidate them into one bounded wright
+   correction packet; never edit source in the reviewing context. Freeze the new candidate
+   and **run affected verification after changes** (`/rite-prove` logic), then perform at
+   most one narrow recheck of affected findings.
+8. The root updates `review.md`, `evidence.md`, and `state.md`.
+   **Completion:** the records name the reviewed candidate identity and every accepted
+   correction has affected proof plus its narrow recheck.
+9. **Require an account from every reviewer.** After `review.md` is written, run:
    ```bash
    devrites-engine review-integrity
    devrites-engine review-fingerprints --write
    ```
-   Exit 1 means an adversarial axis reported nothing and justified nothing: a suspected
-   rubber-stamp. Re-run that axis or add its `No-findings:` justification; do not carry a silent
+   Exit 1 means an adversarial axis reported neither findings nor a justification. Re-run
+   that axis or add its `No-findings:` justification; do not carry a silent
    axis into `/rite-seal` (where it surfaces as an Important).
 
 ## Finding labels
@@ -119,13 +129,13 @@ Pull these via `Read` when the diff demands them:
 - **Nit:** trivial/style.
 - **FYI:** context, no action implied.
 
-**Action decoration (orthogonal to severity).** Also tag each finding with how to act on it:
+**Action tag (separate from severity).** Tag each finding with how to act on it:
 `blocking` (fix before seal), `non-blocking` (fix when convenient), or `if-minor` (fix only if the
 change is already small: a pure noise-economics lever). Only a **`blocking` Critical** gates the
 seal; a `non-blocking` / `if-minor` finding is recorded, not a stop.
 
-## Confidence + signal-to-noise
-Borrow `/rite-vet`'s discipline so review stays **trusted, not noisy**: a reviewer that posts
+## Confidence and signal-to-noise
+Apply `/rite-vet`'s confidence rules. A reviewer that posts
 18 comments per PR teaches the team to ignore every one (below ~10% false-positive rate devs
 investigate each finding; past ~30% they label the tool noisy and skip it):
 - **Confidence-band each finding** (1-10) and state the band. A low-confidence finding (≤4)
@@ -133,21 +143,20 @@ investigate each finding; past ~30% they label the tool noisy and skip it):
   (low-confidence): n` line, never raised as Critical/Important.
 - **Verify before you escalate.** Every Critical/Important quotes the spec line or cites the
   `file:line` that proves it: no unverified blockers.
-- **Budget the noise.** Roll up trivia ("N style nits") into a single line; tooling already
+- **Limit low-value comments.** Roll up trivia ("N style nits") into a single line; tooling already
   catches style. Review's job is correctness + spec fidelity, not a lint dump.
 - **A silent axis is suspicious, not clean.** An adversarial axis that raises nothing must earn
   it: end its `## Spec` / `## Code review` section with a **`No-findings:`** line naming the
   passes it ran (missing/partial/incorrect for spec; edge cases, error paths, the riskiest
   decision, a changed behavior whose test may not cover it for code) and why each came back
-  empty. This is the mirror of confidence-banding: banding kills the false positive, this catches
-  the false negative ([`code-review.md` § Zero findings is suspicious](../devrites-lib/reference/standards/code-review.md)).
+  empty. Confidence bands suppress false positives; this requirement catches silent false
+  negatives ([`code-review.md` § Zero findings is suspicious](../devrites-lib/reference/standards/code-review.md)).
 
 ## Severity orientation (labels, not score)
 
 After labeling, summarize findings as `Critical / Important / Suggestion / Nit /
-FYI` counts. There is no composite number — `/rite-seal` gates on
-`Critical == 0` and on acceptance + drift. Inventing a number invites gaming;
-the labels do the work.
+FYI` counts. There is no composite number. `/rite-seal` gates on
+`Critical == 0` and on acceptance plus drift. Do not invent a composite score.
 
 > **Mid-flight discipline.** When tempted to demote a Critical, hide a finding, fix without re-verification, or wander out of scope: see [`anti-patterns`](reference/anti-patterns.md). Load it the moment you reach for the excuse.