devrites 7.1.1 → 7.2.0

package/pack/generated/dsh/skills/rite-resolve/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: rite-resolve
+description: User-invoked resume verb for answering, dropping, or batch-resolving open `questions.md` gates.
+argument-hint: "<qid> \"<answer>\"  |  --drop <qid> [\"<reason>\"]  |  --batch <plain-text-file>"
+user-invocable: true
+disable-model-invocation: true
+---
+<!-- loads: {"always":["devrites-lib/reference/standards/core.md","rite-resolve/reference/answer-protocol.md"],"triggers":{"standards":["devrites-lib/reference/standards/afk-hitl.md","devrites-lib/reference/standards/documentation.md"]},"rootOnly":["devrites-lib/reference/standards/afk-hitl.md"]} -->
+> Read-set manifest: `devrites-engine context --skills-root .dsh/skills <slug> --skill rite-resolve` (no workspace: `--out <path>`) bundles every file named below into one deduplicated read. Trigger names map to the conditional rules in the sections that follow.
+
+# /rite-resolve: answer the human gate
+
+`/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 `ask_user_question` and the human is present, that pick resolves the gate **in place** through
+the `devrites-engine state 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 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 `.dsh/skills/devrites-lib/reference/standards/`)
+
+Pull these via `Read` when shaping the resolve:
+
+- [`afk-hitl.md`](../devrites-lib/reference/standards/afk-hitl.md): gate taxonomy, `questions.md` schema, AFK exception rules.
+- [`documentation.md`](../devrites-lib/reference/standards/documentation.md): record decisions and rationale where the answer changes scope.
+
+## Operating rules
+
+- **Requires an active workspace.** Read `.devrites/ACTIVE` first; if empty, **STOP** and
+  tell the user to run `/rite-spec <feature>` first. If the slug has no `questions.md`,
+  report the missing required artifact and stop.
+- **One mutation per call.** A single qid (or `--batch` file) per invocation; never
+  silently coalesce multiple human decisions into one log entry.
+- **Never overwrite an answered question.** If the qid's `status` is `answered` or
+  `dropped`, refuse with the existing answer; ask the user to open a new qid that
+  references the old one (the file is the audit trail).
+- **Phase-aware handoff after writing the answer:** before planning artifacts exist,
+  recommend the current phase owner's action emitted by `state resolve` (for example,
+  `/rite-spec`), not Plan repair. Once a plan exists, material scope, architecture,
+  or acceptance changes route through the Spec Drift Guard (`/rite-plan repair`).
+  Never modify `spec.md` / `plan.md` inside this skill.
+- **The script is the source of truth.** Always invoke
+  `devrites-engine state resolve`. It keeps `questions.md` + `state.md` consistent and emits the
+  next-action recommendation. The one `state.md` field this skill may write by hand is the
+  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. 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.
+
+## Workflow
+
+0. **Read `.dsh/skills/devrites-lib/reference/standards/core.md`** (operating rules + persistence discipline) before
+   touching the workspace.
+   Then read the explicit or active workspace's `state.md` directly.
+1. **Parse arguments.** `$ARGUMENTS` is one of:
+   - `<qid> "<answer>"`: answer the single open question.
+   - `--drop <qid>` (optional `"<reason>"`): mark the question `dropped`; record
+     the reason inline.
+   - `--batch <plain-text-file>`: bulk resolve, one entry per qid (see
+     [`reference/answer-protocol.md`](reference/answer-protocol.md) for the batch
+     format).
+2. **Load context.** Read `state.md` and `questions.md`; require the relevant slice
+   from `tasks.md` only for an actual `SLICE-###` question, not `slice: spec | plan`.
+   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. **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 state resolve --human` with those arguments (a human is resolving). It:
+   - flips the qid's `status` to `answered` / `dropped` and stamps `answered_at` + `answer` + `answered_by: human`;
+   - if the qid is in `state.md`'s `Awaiting human` block (single-question pause), clears
+     that block and sets `Status: running`;
+   - appends a `Log` line to `state.md`.
+
+   **Writer failure:** command not found or nonzero exit → STOP. Do not hand-edit
+   `Slice mode`, `questions.md`, or `state.md`; report the exact command, its exit code,
+   and the decisive stderr line, and recommend `/rite-doctor`. Both files stay as the
+   writer left them.
+   **Completion:** zero exit, or the failure reported with no hand edit.
+
+   On resume, only for an actual `SLICE-###` question and after a zero exit, clear or
+   update the unblocked slice's `Slice mode` in `state.md`: if
+   the answer lets the slice proceed, drop the pause-time `Slice mode` so `/rite-build`
+   re-derives it on the next selection; if the answer re-shapes how the slice should be
+   built, set `Slice mode` to match.
+5. **Post-resolve hand-off.** Before planning artifacts exist, recommend the emitted
+   phase-native next action (for example, `/rite-spec`); do not require or create a plan.
+   Once a plan exists, material scope, architecture, behavior, or acceptance changes →
+   recommend `/rite-plan repair` through the Spec Drift Guard. Otherwise → recommend
+   the emitted phase-native next action (typically `/rite-build` for a waiting slice).
+   **Completion:** the resolved state contains exactly one next command.
+6. **STOP.** User-invoked `/rite-resolve` does not run `/rite-build` itself: the
+   user re-enters the workflow explicitly. A controlling `/rite-autocomplete`
+   caller invokes the same `devrites-engine state resolve` writer internally (never with `--human`) and
+   continues; it must not emit this skill as a user handoff for a question that
+   already names a ranked recommended option.
+
+> **Mid-flight discipline.** Don't edit `spec.md` / `plan.md` to "incorporate" the
+> answer. Before planning artifacts exist, return to the emitted current phase owner;
+> once a plan exists, material changes need `/rite-plan repair`. Don't silently retry a build after the answer
+> lands: the user types the next command. Don't merge two open questions into one
+> answered entry: each question is independently auditable.

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

@@ -0,0 +1,129 @@
+# Answer protocol: how `/rite-resolve` mutates the workspace
+
+`/rite-resolve` is the single canonical writer for `questions.md` `status` flips and
+`state.md` `Awaiting human` clearance. This file is the reference for the three input
+shapes, the batch file format, and the `devrites-engine state resolve` rules.
+
+## 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
+
+```
+/rite-resolve q-2026-05-28-001 "composite index — single key is fine for now, revisit at 1M rows"
+```
+
+- The qid must be `status: open`. Re-answering is refused (see "Never overwrite").
+- The answer is recorded verbatim. Use straight quotes around the answer so the shell
+  preserves whitespace.
+
+### 2. Drop
+
+```
+/rite-resolve --drop q-2026-05-28-002 "merged into q-...-003 after we narrowed the scope"
+```
+
+- A drop is **not** an answer. It removes the question from the active queue without
+  recording a decision. Use it when the question is obsolete, a duplicate, or absorbed
+  by a re-plan.
+- The reason is an optional single trailing string, **strongly recommended** for the
+  audit trail. "obsolete" / "duplicate" / "absorbed by Slice N" are sufficient; if omitted,
+  `devrites-engine state resolve` records it as `dropped`.
+
+### 3. Batch
+
+```
+/rite-resolve --batch .devrites/work/<slug>/answers.batch
+```
+
+The batch file is plain text, one resolution per line. Two line shapes:
+
+```
+q-2026-05-28-001: composite index, revisit at 1M rows
+q-2026-05-28-002: clinician sign-off required at runtime, not at plan time
+--drop q-2026-05-28-003: merged into q-...-004
+# Lines starting with # are comments. Blank lines ignored.
+```
+
+- One qid per line. The first colon is the separator; the rest of the line is the value.
+- The batch is all-or-nothing: every line is validated before one atomic write, then
+  `Awaiting human` is cleared for the resolved qids.
+- An error applies nothing. Report the failing line and exit code, fix that line, and
+  re-run the whole file.
+
+## Never overwrite
+
+A qid that is already `answered` or `dropped` refuses to be re-resolved. The audit trail
+is the file. You do not edit history. If the original answer was wrong:
+
+1. Open a new qid (the agent will, during the next `/rite-build` if the bad answer
+   re-surfaces; or you write it manually).
+2. Reference the old qid in the new question's body (`supersedes: q-...-001`).
+3. Resolve the new qid.
+
+The same rule applies to `--drop`: a dropped question is not undropped. Re-raise it as
+a new qid if it turns out to matter after all.
+
+## State machine
+
+```
+open ──answer──▶ answered  (terminal)
+ │
+ └──drop────▶ dropped   (terminal)
+```
+
+Both terminals stamp `answered_at: <iso>` and write the answer/reason to `answer:`.
+
+## `state.md` clearance rules
+
+`state.md`'s `Awaiting human` block is **single-question by default**: `/rite-build`
+writes one block at a time and pauses. When `/rite-resolve` matches the block's qid:
+
+- the entire `Awaiting human` block is removed (header + fields);
+- `- Status: running` is set;
+- a `Log` line is appended: `- <iso> <resuming phase>: resolved <qid>`.
+
+If `state.md`'s `Status` is `awaiting_human` but no `Awaiting human` block matches the
+qid (drift between the two files), `/rite-resolve` flags the inconsistency and refuses
+to silently fix it. Report it to the current phase owner; once a plan exists,
+reconciliation uses `/rite-plan repair`.
+
+## Phase-aware handoff and slice context
+
+Read `tasks.md` and update `Slice mode` only for an actual `SLICE-###` question,
+never for `slice: spec | plan`; the update is allowed only after the writer exits zero.
+Before planning artifacts exist, recommend the current phase owner's action emitted
+by `state resolve` (for example, `/rite-spec`), not Plan repair. Never create planning
+artifacts as part of Resolve.
+
+If the answer materially changes spec/plan, **do not** edit `spec.md` or `plan.md` inside
+`/rite-resolve`. Once a plan exists, material acceptance, behavior, scope, or architecture
+changes route through the Spec Drift Guard (`/rite-plan repair`); otherwise retain the
+emitted phase-native next action. User-invoked resolutions use `state resolve --human`;
+an internal Autocomplete caller uses the same writer without `--human` and continues.
+Resolve itself never auto-runs the recommended phase owner.
+
+## Multi-question awaiting
+
+If a future evolution lets `/rite-build` queue multiple questions per pause, the
+`Awaiting human` block becomes a YAML list. `/rite-resolve` will:
+
+- match the qid in the list and remove only that entry;
+- leave the rest of the list intact;
+- flip `Status: running` only when the list is empty.
+
+This shape is reserved: current `/rite-build` writes one question per pause.
+
+## Why no auto-`/rite-build` after resolve
+
+The user types the next command explicitly. Reasons:
+
+1. Before planning artifacts exist, the emitted current phase owner must resume;
+   once a plan exists, material changes may need `/rite-plan repair` first.
+   Auto-continuing a build would skip that owner or use a stale plan.
+2. The user may want to `/rite-status` before resuming.
+3. Atomicity: one verb, one mutation. Chaining is a hidden side-effect that hides bugs.
+
+The output's `Next:` line is a recommendation, not an auto-run.

package/pack/generated/dsh/skills/rite-review/SKILL.md

@@ -0,0 +1,190 @@
+---
+name: rite-review
+description: Review polished feature diff for correctness, readability, architecture, security, tests proving acceptance, Critical/Important findings, and quality dimensions before seal.
+argument-hint: "[scope: slice N | feature] [--full]"
+user-invocable: true
+---
+
+<!-- loads: {"always":["devrites-lib/reference/standards/core.md","devrites-lib/reference/standards/code-navigation.md","devrites-lib/reference/standards/code-index.md","devrites-lib/reference/candidate-integrity.md","devrites-lib/reference/orchestration-profiles.md","devrites-lib/reference/parallel-dispatch.md","devrites-lib/reference/standards/agents.md","devrites-lib/reference/standards/tooling.md","rite-review/reference/feature-scoped-review.md","rite-review/reference/five-axis-review.md","rite-review/reference/anti-patterns.md"],"triggers":{"applicability":["devrites-lib/reference/standards/repository-topology.md","devrites-lib/reference/standards/data-integrity.md","devrites-lib/reference/standards/integration-reliability.md"],"code-review":["devrites-lib/reference/standards/code-review.md","devrites-lib/reference/standards/review-checklist.md","devrites-lib/reference/standards/review/README.md","devrites-lib/reference/standards/duplicate-code.md"],"performance":["devrites-lib/reference/standards/performance.md","rite-review/reference/performance-review.md","rite-review/reference/performance-checklist.md"],"principles":["devrites-lib/reference/standards/principles.md"],"security":["devrites-lib/reference/standards/security.md","devrites-lib/reference/standards/security-checklist.md","rite-review/reference/security-review.md"],"testing":["devrites-lib/reference/standards/testing.md"],"ui":["rite-review/reference/nielsen-heuristics.md","rite-review/reference/cognitive-load.md","rite-review/reference/performance-checklist.md"],"workflow-artifacts":["devrites-lib/reference/workspace-artifact-schema.md"]},"workspace":["brief.md","spec.md","state.md","decisions.md","assumptions.md","questions.md","decision-coverage.md","architecture.md","plan.md","tasks.md","traceability.md","eng-review.md","test-plan.md","gates.md","evidence.md","touched-files.md","design-brief.md","browser-evidence.md"],"workspaceByRole":{"code-reviewer":["spec.md","plan.md","tasks.md","test-plan.md","architecture.md","decisions.md","state.md","evidence.md","touched-files.md"],"devex-reviewer":["spec.md","plan.md","tasks.md","state.md","touched-files.md","evidence.md"],"doubt-reviewer":["spec.md","plan.md","tasks.md","state.md","decisions.md"],"frontend-reviewer":["spec.md","plan.md","tasks.md","state.md","touched-files.md","evidence.md","design-brief.md"],"performance-reviewer":["spec.md","plan.md","tasks.md","state.md","touched-files.md","evidence.md"],"plan-reviewer":["spec.md","plan.md","tasks.md","test-plan.md","decision-coverage.md","architecture.md","state.md"],"security-auditor":["spec.md","plan.md","tasks.md","state.md","touched-files.md","evidence.md"],"simplifier-reviewer":["spec.md","plan.md","tasks.md","state.md","touched-files.md"],"spec-reviewer":["brief.md","spec.md","decision-coverage.md","questions.md","decisions.md","assumptions.md","state.md"],"test-analyst":["spec.md","tasks.md","test-plan.md","state.md","evidence.md"]},"rootOnly":["devrites-lib/reference/standards/code-index.md","devrites-lib/reference/standards/tooling.md","devrites-lib/reference/orchestration-profiles.md","devrites-lib/reference/parallel-dispatch.md"]} -->
+> Read-set manifest: `devrites-engine context --skills-root .dsh/skills <slug> --phase review` bundles every file named below into one deduplicated read. Trigger names map to the conditional rules in the sections that follow.
+
+
+# /rite-review: feature-scoped review
+
+Review the **active feature scope only**. **Read the active workspace first**; if none,
+tell the user to run `/rite-spec <feature>`.
+
+> **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 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. Use the shared depth rules in
+[`devrites-lib/reference/orchestration-profiles.md`](../devrites-lib/reference/orchestration-profiles.md);
+all workflow-named roles remain mandatory at every depth.
+
+## Rules consulted (read on demand from `.dsh/skills/devrites-lib/reference/standards/`)
+
+Pull these via `Read` when the diff demands them:
+
+- [`code-review.md`](../devrites-lib/reference/standards/code-review.md): small PRs, severity labels, tests-first review focus.
+- [`review-checklist.md`](../devrites-lib/reference/standards/review-checklist.md): compact pass/fail sweep before reporting the verdict.
+- [`principles.md`](../devrites-lib/reference/standards/principles.md): declared project invariants (`.devrites/principles.md`); a diff that violates one with no recorded exception is a Critical, blocking finding.
+- [`testing.md`](../devrites-lib/reference/standards/testing.md): confirm that passing tests actually prove the spec.
+- [`agents.md`](../devrites-lib/reference/standards/agents.md): when to fan out to which review subagent.
+- [`security.md`](../devrites-lib/reference/standards/security.md): when the shared [`parallel-dispatch.md`](../devrites-lib/reference/parallel-dispatch.md#roster) roster triggers the security auditor.
+- [`security-checklist.md`](../devrites-lib/reference/standards/security-checklist.md): for the same security-sensitive scope, the compact trust-boundary sweep.
+- [`repository-topology.md`](../devrites-lib/reference/standards/repository-topology.md), [`data-integrity.md`](../devrites-lib/reference/standards/data-integrity.md), [`integration-reliability.md`](../devrites-lib/reference/standards/integration-reliability.md): only
+  when the spec applicability map or final diff triggers their ownership/failure/proof checks.
+- [`performance.md`](../devrites-lib/reference/standards/performance.md): only when perf is relevant or a regression risk is visible.
+
+## Operating rules
+
+- **Feature scope only** — see
+  [feature-scoped-review](reference/feature-scoped-review.md). Spec Drift Guard applies.
+- **Silent-failure hunt:** when the suite is green, require proof that error paths and
+  partial-success branches would fail tests if broken. **Failing case:** tests pass but
+  handler returns success on internal error → Critical until an asserting test exists.
+- **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.
+- Follow the shared
+  [`candidate-integrity.md`](../devrites-lib/reference/candidate-integrity.md).
+  Review starts only from the digest Polish closed.
+- Findings are labeled (below). Re-prove after any accepted correction.
+- **Reviewers judge; root reconciles; wright fixes.** Per
+  [`agents.md`](../devrites-lib/reference/standards/agents.md), root directly
+  reconciles verdicts/writes artifacts; engines do not. Accepted corrections
+  route to `devrites-slice-wright`.
+
+## Workflow
+
+0. Read `.dsh/skills/devrites-lib/reference/standards/core.md` first (the always-on operating rules); pull the
+   on-demand rules above as the diff demands them.
+1. Read `spec.md`, `tasks.md`, `state.md`, `decisions.md`,
+   `touched-files.md`, `.devrites/principles.md` (if present: the binding invariants to score
+   the diff against), and the `git diff`. For "what would this change break"
+   questions, apply `.dsh/skills/devrites-lib/reference/standards/code-navigation.md`:
+   `detect_changes` (explicit `base_branch`, `scope: "impact"`), then `trace_path` on the
+   symbols that matter, before falling back to LSP/file search. When a finding hinges on an external library's
+   current API, context7 if available can confirm the signature. Run
+   `devrites-engine check candidate <slug>` and require its digest to match the
+   single `evidence.md` binding and the `browser-evidence.md` binding when that
+   file exists. Read those ledgers via the bounded advisory read
+   ([`workspace-artifact-schema.md`](../devrites-lib/reference/workspace-artifact-schema.md) § Read next by phase; trigger `workflow-artifacts`): binding line, `EVID-###`
+   index, then bodies for this candidate's AC/slice IDs only. A missing,
+   malformed, or open candidate returns to Polish/Prove.
+   Read `touched-files.md` `## Review trail` and `eng-review.md` `## Deferred findings`:
+   every deferred row is an input finding for the step-3 cohort (quoted in the owning
+   reviewer's brief without severity) and ends in `review.md` with its own label and
+   action tag — never silently dropped. Hand each lane reviewer the
+   `devrites-engine recall --paths <its touched paths>` pointers as prior context, not findings.
+2. **Review tests first** while the step-3 cohort runs — launch it first; this
+   root pass needs none of its output: 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. **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).
+   Separate contexts prevent one axis from masking the other. This is the initial
+   full pass; a correction uses step 7's bounded recheck:
+   - Freeze that closed digest: write the candidate diff (feature base to HEAD, plus any
+     uncommitted candidate change) to `packets/<wave>.diff` and name that file in the
+     packet. `dispatch open` refuses a Review or Seal reviewer wave whose packet names
+     no existing diff, or whose manifest omits a path the feature's `WIP(<slug>):`
+     checkpoints changed.
+     Give the same digest and diff to the **two** axis reviewers (three when
+     [engineering lanes](../devrites-lib/reference/parallel-dispatch.md) split the code axis) in
+     parallel, each with its own narrow brief and no
+     cross-pollination — and evaluate the frontend (step 4), security (step 5),
+     and performance (step 6) dispatch conditions from this same diff now,
+     joining the cohort when applicable rather than dispatching later waves:
+     - **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
+       (scope creep / drift), (c) criteria implemented incorrectly. Quote the spec
+       line per finding. If the spec is missing or unreadable, report `Review gap:
+       missing spec` and do not infer requirements from the diff."
+     - **Seal roles** → `devrites-test-analyst`, plus `devrites-doubt-reviewer` per
+       stood decision and `devrites-devex-reviewer` when triggered, join this cohort on
+       the same digest. Their findings join step 7's single correction, and Seal cites
+       their unchanged same-candidate accounts instead of re-dispatching them.
+     - **Code-review axis** → `devrites-code-reviewer`: "Apply your full documented
+       discipline (tests-first, correctness, readability, architecture, maintainability,
+       standards) on the feature workspace + diff. Cite file:line; skip tooling-enforced
+       checks. Apply canonical anti-slop and silent-failure lenses; inspect each hunk
+       for unrequested deletion. Unexcepted `.devrites/principles.md` violations are
+       Critical. Distinguish binding standards from judgment-only baseline smells."
+       Route it through [parallel-dispatch.md § Engineering lanes](../devrites-lib/reference/parallel-dispatch.md#engineering-lanes):
+       a frontend+backend diff gets two lane reviewers in this cohort.
+   - **Do NOT merge or re-rank** their findings. Present them under separate
+     `## Spec` and `## Code review` sub-sections in `review.md`. Surface contradictions
+     between the axes explicitly (e.g. "Spec axis says complete, Code-review axis says
+     untestable"): `/rite-seal` decides what blocks. Preserve each reviewer's
+     `Outcome:` and admit its account through
+     [[`agents.md`](../devrites-lib/reference/standards/agents.md) § Result admission](../devrites-lib/reference/standards/agents.md#result-admission).
+     Either `Outcome: gap` stops Review; silence, failure, or malformed output never
+     becomes an empty findings list.
+4. **Reconcile, don't re-review.** With the two parallel reports in hand, the inline
+   lead reconciles. It does **not** re-run the code-review axes over correctness /
+   readability / architecture / maintainability that `devrites-code-reviewer` already
+   covered. Stay in scope ([feature-scoped-review](reference/feature-scoped-review.md)).
+   Add only what the dispatched agents could not, then resolve overlaps and
+   contradictions before labeling. ([five-axis-review.md](reference/five-axis-review.md)
+   documents the axes the code-review agent applies.)
+   - **UI feature?** `devrites-frontend-reviewer` joins the step-3 cohort; apply the **UX rubric**
+     ([nielsen-heuristics](reference/nielsen-heuristics.md)) and the
+     **cognitive-load lens** ([cognitive-load](reference/cognitive-load.md),
+     [performance-checklist](reference/performance-checklist.md)). No UI/route/style
+     paths: record `Not-applicable: no relevant paths in diff`.
+5. **Security:** `devrites-security-auditor`
+   ([security-review](reference/security-review.md)) joins the step-3 cohort under the
+   canonical [parallel-dispatch roster trigger](../devrites-lib/reference/parallel-dispatch.md#roster),
+   including a dependency-only diff; else `Not-applicable: no relevant paths in diff`.
+6. **Performance:** `devrites-performance-reviewer`
+   ([performance-review](reference/performance-review.md),
+   [performance-checklist](reference/performance-checklist.md)) joins the step-3 cohort
+   only on a budget or
+   hot path; else `Not-applicable: no relevant paths in diff`.
+7. Reconcile and accept only in-scope fixes. Consolidate them into one bounded
+   wright correction; never edit source in the reviewing context. Any correction
+   updates the candidate manifest, returns through affected Prove, and then starts
+   a fresh Review binding on the new digest. Dispatch affected exact reviewers on
+   all their open findings and the dependency/regression closure under
+   [evidence validity](../devrites-lib/reference/candidate-integrity.md#evidence-validity).
+   Cite unchanged sub-scope coverage only with its original identity and explicit
+   justification; never relabel old accounts. Changed contracts or uncertain impact
+   require the full applicable pass.
+8. The root updates `review.md` and `state.md`, writing exactly one candidate
+   binding in `review.md` for the current digest, distinguishing fresh accounts from
+   cited unchanged sub-scope evidence and reconciling complete coverage.
+   **Completion:** the records name the reviewed candidate identity and every accepted
+   correction has affected proof plus a fresh Review. Then checkpoint remaining
+   candidate diffs per [`checkpoint.md`](../rite-build/reference/checkpoint.md);
+   a wright correction does not commit on control until that Review is green.
+
+## Finding labels
+
+- **Critical:** must fix before seal (correctness/security/data loss).
+- **Important:** should fix before seal (likely bug, real maintainability risk).
+- **Suggestion:** worth doing, not blocking.
+- **Nit:** trivial/style.
+- **FYI:** context, no action implied.
+
+**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). Every Critical is `blocking` and gates the
+seal; `non-blocking` / `if-minor` findings are recorded, not a stop.
+
+## Confidence and severity
+
+Apply [[`agents.md`](../devrites-lib/reference/standards/agents.md) § Result admission](../devrites-lib/reference/standards/agents.md#result-admission).
+Roll trivia into one line. `/rite-seal` gates on `Critical == 0`,
+`Important == 0` (y/N override), acceptance, and drift. No 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.
+
+## Output → `review.md`
+
+Write the detailed review to `review.md`.

package/pack/generated/dsh/skills/rite-review/reference/anti-patterns.md

@@ -0,0 +1,32 @@
+# rite-review: anti-patterns
+
+Load this when standing a non-trivial review decision, when tempted to
+demote severity to hide a finding, or when crossing out of feature scope.
+
+Pack-wide rationalizations + red flags: see
+[standards/anti-patterns.md](../../devrites-lib/reference/standards/anti-patterns.md).
+
+## Phase-specific rationalizations
+
+| Excuse | Rebuttal |
+|---|---|
+| "Polish already cleaned this up; nothing to flag." | Polish finishes; review judges. If review still spots a real issue, flag it: don't re-run polish here. |
+| "Tests pass, so they're adequate." | Adequacy = do they prove acceptance, including failure / boundary / empty paths? A passing test is not automatically a good test. |
+| "Security audit isn't needed for this feature." | If the feature touches user input, auth, data storage, external integrations, secrets, or permissions: yes it is. |
+| "I'll just fix everything I find in scope." | Some fixes belong in `/rite-plan` as drift, not as smuggled redesigns inside review. |
+| "Performance is fine without measuring." | No claim without a number or a specified measurement. "Feels fast" is not a finding. |
+
+## Severity gaming
+
+| Excuse | Rebuttal |
+|---|---|
+| "Demoting a Critical to Important keeps the review clean." | Severity reflects the actual risk to ship, not the review you'd like. |
+| "I won't surface this Critical; user can find it later." | Hidden Criticals are the worst-case play. The seal blocks anyway, and now you've burned trust. |
+
+## Red Flags
+
+- A finding without `file:line`.
+- A finding without a severity label (Critical / Important / Suggestion / Nit / FYI).
+- A Critical recorded but silently fixed instead of surfaced to the seal.
+- A fix applied without re-verification afterwards.
+- Review crossing into out-of-scope files because they "looked wrong".

package/pack/generated/dsh/skills/rite-review/reference/cognitive-load.md

@@ -0,0 +1,90 @@
+# Cognitive load: a UX review lens
+
+Cognitive load is the total mental effort the interface demands. Overloaded users
+hesitate, misclick, abandon. Reviewing UI without this lens misses a whole class of
+defects that no a11y checker or perf tool will flag.
+
+DevRites' `/rite-review` uses this reference when the feature touches UI. It is
+descriptive (helps you spot defects) rather than scored: findings raised here
+roll up under the UX axis of the multi-axis review with the usual severity labels.
+
+## Three kinds of load
+
+| Type | Source | Reviewer's job |
+|---|---|---|
+| **Intrinsic** | The task itself: its inherent steps, decisions, and required knowledge. | Can't be eliminated, only **structured**: step the user through it, provide defaults, group related decisions, defer what isn't needed yet. |
+| **Extraneous** | Bad design: friction the task doesn't require: noisy hierarchy, redundant choices, jargon, layout that hides the next step. | **Eliminate it ruthlessly.** It's pure waste, and the easiest class of finding to land. |
+| **Germane** | Effort the user spends *forming a mental model* of the product. | **Invest deliberately.** Consistent flows, shared vocabulary, predictable affordances: anything that lets the user re-use what they already learned. |
+
+A surface can be intrinsic-heavy *and* extraneously-fine. That's a hard task done
+right. A simple surface that still feels heavy is extraneous load disguised as
+"complexity."
+
+## Symptoms reviewers should flag
+
+Treat each as a finding when present; classify by load type so the fix is obvious.
+
+### Extraneous (reduce / remove)
+- **Visual noise** that doesn't earn its place: redundant borders, shadows,
+  dividers, gratuitous icons next to every label, colour used decoratively.
+- **Competing primary actions:** two or three buttons of equal weight when one
+  is clearly the next step.
+- **Jargon and abbreviations** the user doesn't share: names from the codebase
+  or internal team that leaked into the UI.
+- **Restated headings** (the body of a section repeats the section title in
+  long-form).
+- **Decision paralysis:** too many options when one default + a "more options"
+  toggle would do.
+- **Form fields without obvious priority:** required vs optional, primary vs
+  secondary mixed in a single column with no rhythm.
+- **Premature error messaging** (validation that fires before the user has
+  finished typing).
+
+### Intrinsic (structure, don't try to eliminate)
+- **No progressive disclosure** on a genuinely complex task: every field
+  visible at once because "the user might need it".
+- **No safe defaults** on multi-step flows: the user has to choose at every step
+  even when one path is the obvious answer.
+- **Decisions grouped wrong:** "billing address" sandwiched between two
+  unrelated sections rather than next to "shipping address".
+- **No scaffolding** (no template, no example input, no recently-used value)
+  for tasks that have a high blank-page cost.
+
+### Germane (invest in)
+- **Inconsistent vocabulary** across the feature: same concept named two ways
+  (e.g. "member" in one screen, "user" in the next).
+- **Flow-shape divergence** from neighbouring features (modal where the project
+  uses inline; route-change where the project uses an overlay).
+- **Affordances that look interactive but aren't** (and vice versa): destroys
+  the mental model the user is trying to build.
+
+## Reviewing a flow: three-pass discipline
+
+1. **First pass: silent.** Walk the flow without reading any explainer copy.
+   Anything that stops you cold without copy is a finding: either extraneous
+   load you can't dismiss, or a germane-load problem (the user is missing a
+   mental model the UI assumes).
+2. **Second pass: with copy.** Read every label, helper, and error. Does the
+   copy resolve the friction the first pass surfaced, or just paper over it?
+   "Tooltip explaining a confusing button" is rarely the right fix: usually
+   the button needs a different label.
+3. **Third pass: empty + error.** Run the flow with no data, partial data, and
+   the worst inputs (offline / 500 / permission-denied). Most cognitive-load
+   defects hide in non-happy paths because nobody designs them.
+
+## The cheap-fix test
+
+If a finding would take more than 30 minutes to fix, classify it (token gap /
+component miss / flow misalignment per [`ui.md`](../../rite-polish/reference/ui.md)) and
+route to the appropriate bucket. Cognitive-load review surfaces problems; it
+doesn't decide the rewrite strategy.
+
+## What this lens **doesn't** cover
+
+- **Accessibility:** separate axis (WCAG 2.2; see
+  [`devrites-frontend-craft/reference/quality-standards.md`](../../devrites-frontend-craft/reference/quality-standards.md)).
+- **Performance:** separate axis (Core Web Vitals; see
+  [`performance-checklist.md`](performance-checklist.md)).
+- **Code quality:** covered by the simplification audit
+  (`devrites-audit simplify`).
+- **Security:** covered by the security audit (`devrites-audit security`).

package/pack/generated/dsh/skills/rite-review/reference/feature-scoped-review.md

@@ -0,0 +1,26 @@
+# Feature-scoped review
+
+The review boundary is the **active feature**: the files in `touched-files.md` and the
+current diff. This is a hard rule, not a guideline.
+
+## In scope
+- Code added/changed by this feature.
+- Tests for this feature.
+- Files this feature intentionally inspected and depends on (read for context, but
+  don't refactor them).
+
+## Out of scope (do NOT)
+- Refactor unrelated modules because they're "nearby" or "while we're here".
+- Delete suspected dead code outside this feature without asking the user.
+- Restyle/upgrade dependencies or change project-wide config to suit this feature.
+- Expand the review into a project audit.
+
+## When you spot a real problem outside scope
+Record it as an **[FYI] follow-up** in `review.md` (and suggest a separate feature/issue).
+Don't fix it inline. Drive-by changes balloon the diff, dodge their own review, and
+mix concerns the seal can't cleanly evaluate.
+
+## Why scope discipline matters
+A tight diff gets a real review; a sprawling one gets a rubber stamp. Scope creep is how
+"a small fix" becomes an unreviewable, unprovable change. Keep the feature shippable and
+the review honest.