devrites 5.10.2 → 5.11.0

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

@@ -0,0 +1,98 @@
+---
+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 <path-to-file>"
+triggers:
+  - user
+---
+
+# /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 `AskUserQuestion` 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 `.devin/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).
+- **If the answer materially changes scope, architecture, or acceptance**, route it
+  through the Spec Drift Guard (`/rite-plan repair`) **after** writing the answer: do
+  not 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 `.devin/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 <path-to-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`, `questions.md`, and the relevant slice from
+   `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. **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` with those arguments. It:
+   - flips the qid's `status` to `answered` / `dropped` and stamps `answered_at` + `answer`;
+   - 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`.
+
+   On resume, also 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.** If the answer changes product behavior or acceptance →
+   recommend `/rite-plan repair`. Otherwise → recommend the slice's natural next action
+   (typically `/rite-build` for the slice that was awaiting).
+   **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 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. That's `/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/devin/skills/rite-resolve/reference/answer-protocol.md

@@ -0,0 +1,118 @@
+# 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.
+- Order matters only for `state.md` clearance: the script processes top-to-bottom and
+  flushes `Awaiting human` after each match.
+- Errors abort the batch at the first failing line so partial state is small and
+  diagnosable. (Re-run after fixing the offending line; already-applied lines refuse to
+  re-apply because their `status` is no longer `open`.)
+
+## 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. Use `/rite-plan repair` to reconcile.
+
+If the answer materially changes spec/plan, **do not** edit `spec.md` or `plan.md` inside
+`/rite-resolve`. That's `/rite-plan repair`'s job. The skill's post-resolve hand-off
+recommends `/rite-plan repair` whenever the answer touches acceptance criteria, scope,
+or architecture.
+
+## 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. The answer may need a `/rite-plan repair` first; auto-continuing would build against
+   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/devin/skills/rite-review/SKILL.md

@@ -0,0 +1,171 @@
+---
+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]"
+---
+
+# /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 `.devin/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 input / auth / data / integrations / secrets are in scope.
+- [`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 `.devin/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 `.devin/skills/devrites-lib/reference/standards/tooling.md`: use
+   the primary available index and cross-check only one named unresolved predicate 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): 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.
+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. **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 and give the same digest to **two** read-only reviewers 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."
+     - **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."
+   - **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 when
+   input, auth, data,
+   secrets, or permissions are in the 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/devin/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/devin/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/devin/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.

package/pack/generated/devin/skills/rite-review/reference/five-axis-review.md

@@ -0,0 +1,66 @@
+# Five-axis review: tests first, then six axes
+
+The dispatched `devrites-code-reviewer` checks tests first, then correctness, readability,
+architecture, maintainability, and standards under one severity scale (Critical / Important / Suggestion / Nit / FYI).
+The `/rite-review` inline lead **reconciles** the returned report against the Spec
+axis. It does not re-run these axes itself. This file is the shared definition of
+what "full code-review discipline" covers; use it to judge whether the agent's report
+is complete, and to scope anything the agent could not (e.g. UI-only lenses below).
+
+## 0. Tests (first)
+- Do tests exist for the changed behavior, and do they prove the acceptance criteria?
+- Would they fail if the code were wrong? (No assertion-free or tautological tests.)
+- Edge cases: empty, boundary, error, permission-denied, concurrency.
+- Applicable data/integration/topology cases use a risk-capable boundary; no
+  risk-erasing mock, one-tenant isolation claim, or one-root proof for another root.
+
+## 1. Correctness
+- Does it do what the spec says? Off-by-one, null/undefined, error paths, race
+  conditions, incorrect assumptions about inputs.
+- Does it handle the states the slice promised (loading/empty/error for UI)?
+- Does retry/interruption converge without duplicate effects; do partial/unknown external
+  outcomes, migrations, old/new versions, tenant scope, and rollback follow the accepted plan?
+
+## 2. Readability
+- Can the next engineer understand it without the author? Naming, function length,
+  nesting depth, comments that explain *why* not *what*.
+- Structural smells: a conditional **bolted onto an unrelated flow** (wants its own
+  helper/state/policy: a design smell, not a nit); **repeated conditionals on the same
+  shape** (a missing model or dispatcher).
+
+## 3. Architecture
+- Right seam/boundary? Coupling and cohesion. Does it fit existing patterns or
+  introduce a competing one? Is the abstraction earned (not premature)?
+- Does a refactor **reduce** complexity or just **relocate** it? Count the concepts a
+  reader must hold; a "cleaner" version that leaves that count unchanged isn't cleaner.
+- Is feature-specific logic **leaking into a shared module** instead of its owning layer?
+  Is a **type boundary** left implicit by a gratuitous `any`/cast or a silent fallback?
+- **Name the remedy, not just the smell:** replace a conditional chain with a typed
+  dispatcher, separate orchestration from business logic, move feature logic to its owning
+  package, delete a pass-through wrapper, split a large file. Prefer the move that removes
+  moving pieces over one that re-centralizes the same complexity.
+- Are repository/deployable roots, canonical contract and mutable-state owners, shared
+  resources, and synchronous/asynchronous consistency boundaries preserved without a cycle?
+
+## 4. Security
+- Trust boundaries, input validation, authz checks, secrets handling. Hand off to
+  `devrites-audit security` when input/auth/data/integration is in scope.
+
+## 5. Performance
+- Obvious N+1s, unnecessary work in hot paths, payload sizes. Hand off to
+  `devrites-audit perf` when perf is relevant: **measure before claiming**.
+
+## 6. Maintainability
+- Tests, docs/comments where needed, no dead code added, no TODOs left, consistent
+  with project conventions.
+
+## Frontend axes (if UI)
+- UX flow matches neighbors; all interaction states; a11y (focus, labels, contrast,
+  keyboard); responsive; design-system alignment (no drift, no anti-AI-slop).
+
+## Sizing & speed
+Prefer reviewing roughly one slice / ~100 lines of meaningful change at a time. Larger
+diffs hide defects: recommend splitting rather than rubber-stamping. Watch **file size,
+not just diff size**: a small diff that pushes an already-large file further past a healthy
+boundary wants decomposition (extract helpers / split modules) *first*: decompose, then
+add.