devrites 3.0.4 → 3.0.6

package/docs/engine/state-schema.md

@@ -1,7 +1,7 @@
 # `.devrites/` state schema (v1)
 
 The `devrites-engine` binary reads a project's workflow state from plain files under
-`.devrites/`. Those files are the source of truth and are hand-editable — a
+`.devrites/`. Those files are the source of truth and are hand-editable. A
 human edit always wins.
 
 `schemaVersion: 1`.
@@ -15,7 +15,7 @@ phase-required section matrix, see [`workspace-schema.md`](workspace-schema.md).
 .devrites/
   work/
     <slug>/
-      README.md       workspace map — phase, status, next action, read-next
+      README.md       workspace map: phase, status, next action, read-next
       brief.md        objective, non-goals, success definition
       spec.md         product WHAT/WHY, requirements, acceptance, boundaries
       architecture.md feature technical map
@@ -28,31 +28,32 @@ phase-required section matrix, see [`workspace-schema.md`](workspace-schema.md).
       state.md        compact cursor
       evidence.md     EVID-### command/action proof
       touched-files.md implementation file map
-  specs/              capability ledger — the living "what the system does now"
+  specs/              capability ledger: the living "what the system does now"
     <capability>/
       spec.md         proven Requirement blocks for this capability
 ```
 
-Each feature is a directory of **small single-concern files**. Splitting the
-work this way (rather than one long document) keeps every file context-cheap and
-makes completeness self-evident: an empty or missing section is visibly empty.
+Each feature is a directory of small files with one concern apiece. This keeps
+the context for each file small and makes missing content easy to spot.
 
-### Capability ledger — `specs/`
+### Capability ledger: `specs/`
 
 `work/<slug>/` is **ephemeral** (archived on ship); `specs/` is **durable**. It is
 the cumulative record of proven behavior, one `spec.md` per capability, so a new
 feature starts from the system's current contract instead of re-deriving it from
-code. A feature's spec carries deltas (`## ADDED/MODIFIED/REMOVED Requirements —
-capability: <c>`); on ship, `devrites-engine ledger sync` folds them in — ADDED
-appends, MODIFIED replaces by header identity, REMOVED deletes. Living outside
-`work/`, the ledger survives close-out's archival — and unlike the rest of
+code. A feature's spec groups deltas under `ADDED`, `MODIFIED`, or `REMOVED`
+Requirements headings tagged with `capability: <c>`. On ship,
+`devrites-engine ledger sync` folds them in: ADDED appends, MODIFIED replaces by
+header identity, and REMOVED deletes. Because it lives outside `work/`, the
+ledger survives close-out archival. Unlike the rest of
 `.devrites/`, it is **git-tracked** (`.devrites/*` + `!.devrites/specs/`), so the
 proven contract is shared, not per-clone. Grammar and delta rules:
 [`spec-grammar.md`](../../pack/.claude/skills/devrites-lib/reference/standards/spec-grammar.md).
 
 Backward compatibility: `.devrites/features/<slug>/` remains readable as a legacy
 workspace location. `feature.md` / `index.md` may stand in for `README.md`, and
-`proof.md` may stand in for `evidence.md`.
+`status.md` may stand in for `state.md`, while `proof.md` may stand in for
+`evidence.md`.
 
 ### Workspace maps
 
@@ -79,10 +80,10 @@ The legacy engine completeness sections, in canonical order:
 A section is **present** (has real content) when its `<section>.md` file exists
 and, after removing any leading YAML frontmatter, ATX (`#`) headings, and
 whitespace, some content remains. A stub that is only a heading counts as
-**empty** — scaffolding a file never fakes completeness.
+**empty**. Scaffolding a file never fakes completeness.
 
 The 2026 Markdown workspace schema is stricter and lives in
-[`workspace-schema.md`](workspace-schema.md): it validates required phase-owned
+[`workspace-schema.md`](workspace-schema.md). It validates required phase-owned
 artifacts, stable IDs (`AC-###`, `SLICE-###`, `EVID-###`), traceability, evidence,
 compactness budgets, Mermaid fences, and stale local links.
 
@@ -125,14 +126,17 @@ result: incomplete (missing: tasks)
 ```
 
 - Found feature → exit `0`, whether complete or incomplete (`status` reports, it
-  does not gate — gating is issue 04).
+  does not gate; gating is issue 04).
 - Unknown or missing slug → non-zero exit with a clear message on stderr.
 
-The engine makes **zero model or network calls**; `status` is a pure read of the
-files under `DEVRITES_ROOT` (or the nearest `.devrites/` above the working
-directory). A hand edit wins immediately because there is no status cache.
+`status` makes no model or network calls; it is a pure read of the files under
+`DEVRITES_ROOT` (or the nearest `.devrites/` above the working directory). A
+hand edit wins immediately because there is no status cache. Other workspace
+control-plane commands share that deterministic boundary; explicit
+install/update/source-cache I/O is isolated under `engine/internal/iohooks` as
+defined by ADR-0008.
 
 `.devrites/` is ignored **except** the capability ledger at `specs/`, which is
-committed shared truth — the recommended pattern is `.devrites/*` +
+committed shared truth. The recommended pattern is `.devrites/*` +
 `!.devrites/specs/` (so `work/`, `archive/`, and `ACTIVE` stay per-clone runtime
 state while `specs/` is tracked).

package/docs/engine/workspace-schema.md

@@ -1,4 +1,4 @@
-# DevRites Workspace Artifact Schema
+# DevRites workspace artifact schema
 
 DevRites workspaces are durable source-of-truth folders for a feature. Chat is
 temporary; the workspace must be enough for a fresh human or AI to resume without
@@ -34,7 +34,7 @@ Canonical live workspace:
       plan.md                   # technical approach and slice strategy
       tasks.md                  # vertical slices
       traceability.md           # AC/REQ -> slices -> tests/evidence/files matrix
-      state.md                  # compact cursor
+      state.md                  # compact cursor; status.md alias allowed
       evidence.md               # command/action proof; proof.md alias allowed
       browser-evidence.md       # optional UI/runtime browser proof
       drift.md                  # optional spec/plan drift register
@@ -49,10 +49,11 @@ Canonical live workspace:
 
 Backward compatibility: `.devrites/features/<slug>/` remains readable as an alias
 for `.devrites/work/<slug>/`; `feature.md` and `index.md` remain valid workspace
-maps; `proof.md` remains a proof alias for `evidence.md`. Migration should add the
-canonical files without deleting aliases.
+maps; `status.md` remains a cursor alias for `state.md`; `proof.md` remains a
+proof alias for `evidence.md`. Migration should add the canonical files without
+deleting aliases.
 
-## Read Order
+## Read order
 
 | Phase / role | Read first | Then read | Usually skip |
 | --- | --- | --- | --- |
@@ -64,7 +65,7 @@ canonical files without deleting aliases.
 | Review / seal | `README.md`, `traceability.md` | `spec.md`, `evidence.md`, `decisions.md`, `drift.md`, `touched-files.md` | raw logs unless needed |
 | Handoff | `README.md`, `state.md` | `handoff.md`, then linked source files | duplicated summaries |
 
-## Artifact Contracts
+## Artifact contracts
 
 | Artifact | Required? | Owner phase | Read trigger | Budget | Required headings | Validation rules |
 | --- | --- | --- | --- | --- | --- | --- |
@@ -77,11 +78,11 @@ canonical files without deleting aliases.
 | `assumptions.md` | required | all phases | assumption is not yet verified | 160 lines | Assumption register | Confidence, owner, and validation status are explicit. |
 | `questions.md` | required | all phases | human input or gate | 180 lines | Question register | `Q-###`; no open blocking/escalating questions before plan/build/prove gates. |
 | `ai-spec.md` | conditional | `/rite-spec` or `/rite-define` | AI/LLM annex | 160 lines | AI surface, model/runtime choice, evals, guardrails, monitoring | Required only for model calls, RAG, agents, evals, or LLM output. |
-| `plan.md` | required from plan | `/rite-define` | implementation approach | 220 lines | Approach, Slice strategy, Validation strategy, Rollback | HOW lives here, not in `spec.md`. `Validation strategy` names the Key links — cross-slice wiring `/rite-prove` walks (or `none` for single-slice features). |
+| `plan.md` | required from plan | `/rite-define` | implementation approach | 220 lines | Approach, Slice strategy, Validation strategy, Rollback | HOW lives here, not in `spec.md`. `Validation strategy` names the Key links: cross-slice wiring `/rite-prove` walks (or `none` for single-slice features). |
 | `tasks.md` | required from plan | `/rite-define` | build one slice | 280 lines | Slice index | Each `SLICE-###` has goal, AC IDs, likely files, tests/proof, mode, gate, dependencies, done condition. |
 | `traceability.md` | required from plan | `/rite-define` | coverage/review/seal | 220 lines | Coverage matrix | Matrix maps AC/REQ ID, slice IDs, test/proof, evidence ID, touched files, status. |
-| `state.md` | required | all phases | current cursor | 120 lines | Cursor | Compact table/key-value cursor; not an append-only narrative. |
-| `evidence.md` / `proof.md` | required from prove | `/rite-build`, `/rite-prove` | proof and seal | 280 lines | Evidence log | `EVID-###`, command/action, result, related AC/slice IDs, limitations. Each acceptance criterion carries a proof class — `test` / `command` / `browser` / `judgment` (untagged reads `judgment`; `judgment` needs its one-line why). |
+| `state.md` / `status.md` | required | all phases | current cursor | 120 lines | Cursor | `state.md` is canonical; `status.md` is a compatibility alias. Compact table/key-value cursor; not an append-only narrative. |
+| `evidence.md` / `proof.md` | required from prove | `/rite-build`, `/rite-prove` | proof and seal | 280 lines | Evidence log | `EVID-###`, command/action, result, related AC/slice IDs, limitations. Each acceptance criterion carries a proof class: `test` / `command` / `browser` / `judgment` (untagged reads `judgment`; `judgment` needs its one-line why). |
 | `browser-evidence.md` | UI only | `/rite-prove`, `/rite-polish` | UI/browser proof | 220 lines | Browser evidence, Visual Verdict | Must reference real route/viewports/actions and related IDs. |
 | `drift.md` | drift only | Spec Drift Guard | spec/plan reality mismatch | 160 lines | Drift register | `DRIFT-###`, status, evidence found, resolution, related IDs. |
 | `touched-files.md` | required from build/prove | `/rite-build` | impact/evidence freshness | 160 lines | Touched files | File, slice ownership, and reason per row. |
@@ -91,7 +92,7 @@ canonical files without deleting aliases.
 
 Files may exceed budgets only with a visible `Budget override: <reason>` line.
 
-## Required vs Optional
+## Required vs optional
 
 Required at `/rite-spec`: workspace map, `brief.md`, `spec.md`, `state.md`,
 `decisions.md`, `assumptions.md`, `questions.md`.
@@ -107,7 +108,7 @@ Optional/conditional files are generated only by their producing phase:
 `browser-evidence.md` for UI, `drift.md` for drift, `handoff.md` for handoff,
 and `references.md` / `references/` when references exist.
 
-## Compactness Rules
+## Compactness rules
 
 - Put summaries first and deep details behind file links.
 - Use tables for matrices, gates, and checklists.

package/docs/extensions.md

@@ -1,8 +1,8 @@
-# Extending DevRites — project extensions & reviewer overrides
+# Extending DevRites with project extensions and reviewer overrides
 
 DevRites ships a fixed, authored pack of rites, reviewers, and standards. The extension sync
 surface is currently **Claude Code-only**; Codex extension mirrors are not generated. Two project-local
-surfaces let a Claude Code project tune the pack **without forking it** — both live in the data plane
+surfaces let a Claude Code project tune the pack **without forking it**: both live in the data plane
 (`.devrites/`), both are git-diffable, and both are held to the same contracts the shipped pack is.
 
 They answer two different questions:
@@ -15,25 +15,25 @@ They answer two different questions:
 The guiding invariant for both: **a shipped gate is never weakened by a customization.** An
 extension earns parity by passing the same validator as the pack; an override may raise the bar,
 never lower it. The deterministic engine gates (`seal`, `review-integrity`, `check-acceptance`, …)
-do not read either surface — they stay authoritative regardless of what a project adds.
+do not read either surface: they stay authoritative regardless of what a project adds.
 
 ---
 
-## Extensions — add a rite or reviewer
+## Extensions: add a rite or reviewer
 
 A project extension is a directory under `.devrites/extensions/`:
 
 ```
 .devrites/extensions/<name>/
-  skill/SKILL.md      (optional) a user rite/skill — needs name + description frontmatter
-  agent.md            (optional) a user reviewer agent — needs name + description frontmatter
+  skill/SKILL.md      (optional) a user rite/skill: needs name + description frontmatter
+  agent.md            (optional) a user reviewer agent: needs name + description frontmatter
   component.yaml      (optional) npx-managed component manifest + safety bounds
   provenance.json     (optional) source/author/review metadata for shared extensions
   extension.yaml      (optional) metadata: aliases (prior names, so a rename doesn't orphan)
 ```
 
 An extension provides a skill, an agent, or both. It is held to the same schema as the shipped
-pack — a malformed extension is refused, not silently half-installed.
+pack. DevRites refuses malformed extensions rather than installing part of one.
 
 ### Commands
 
@@ -54,7 +54,7 @@ devrites-engine extensions sync        # mirror valid extensions into .claude/ f
   also declare `tier`, `requires`, `owns`, and `surface`; dependencies must be acyclic, and anything
   in `owns` that collides with the first-party `rite-`/`devrites-` namespaces is refused. If a
   malformed extension declares a review/gate-like surface, validation warns that the surface is
-  inactive until the schema is fixed — fail-open, but loud.
+  inactive until the schema is fixed. Validation remains fail-open, but reports the problem.
 - **`sync`** validates first, then mirrors `skill/` → `.claude/skills/<name>/` and `agent.md` →
   `.claude/agents/<name>.md`, where the Claude harness discovers them. Idempotent. It refuses to
   sync a set that fails validation.
@@ -94,7 +94,7 @@ a gate, run executables, or bypass `type-GO`.
 
 ### Declarative checks
 
-`component.yaml` may declare **checks** — non-executable, one-line instructions the data plane
+`component.yaml` may declare **checks**: non-executable, one-line instructions the data plane
 surfaces at a lifecycle gate:
 
 ```yaml
@@ -104,13 +104,13 @@ checks:
     doc: docs/license-scan.md   # optional pointer to the project's own procedure
 ```
 
-- A check is an **instruction the in-session model addresses**, never a command the engine runs —
-  the deterministic engine gates still do not read extensions, and `executable: false` still holds.
+- A check is an **instruction the in-session model addresses**, never a command the engine runs.
+  The deterministic engine gates still do not read extensions, and `executable: false` still holds.
 - Checks are **additive-only**: they can raise the bar at a gate, never lower one (same rule as
   overrides). `/rite-seal` treats a declared `at: seal` check that is neither addressed nor
   skip-justified in `seal.md` as an **Important** finding on the review's completeness.
-- Checks in an extension that fails validation are inactive — fail-open, but `extensions validate`
-  says so loudly.
+- Checks in an extension that fails validation are inactive. `extensions validate`
+  reports the problem without blocking unrelated work.
 
 ### Workflow
 
@@ -131,7 +131,7 @@ the generated shipped pack artifacts so extension sync does not become a second
 
 ---
 
-## Overrides — reshape a shipped reviewer
+## Overrides: reshape a shipped reviewer
 
 An override is a single Markdown file named for the agent it targets:
 
@@ -141,14 +141,14 @@ An override is a single Markdown file named for the agent it targets:
 ```
 
 Each shipped reviewer, after loading its governing standards, reads
-`.devrites/overrides/<its-name>.md` if present and applies it as **project overrides** — extra
-emphasis or house rules this project wants enforced. For example, a `devrites-code-reviewer.md`
+`.devrites/overrides/<its-name>.md` if present and applies it as project-specific
+emphasis or house rules. For example, a `devrites-code-reviewer.md`
 override that says "always flag any use of the deprecated `legacyClient` as Important."
 
 ### The one rule
 
 An override may **add** checks or **raise** weight. It may **never** relax a gate, waive a standard,
-or lower a severity floor — a Critical stays a Critical. Overrides are reviewer *input*, not
+or lower a severity floor. A Critical stays a Critical. Overrides are reviewer *input*, not
 permission. The engine gates don't read them at all, so an override literally cannot disable a gate;
 the linter exists to catch one that *tries to talk a reviewer into it*.
 

package/docs/flow.md

@@ -1,7 +1,7 @@
-# DevRites — flow diagrams
+# DevRites flow diagrams
 
 Visual reference for how the skills, agents, and rules fit together. GitHub
-renders Mermaid natively — open this file on the repo to see the graphs.
+renders Mermaid natively: open this file on the repo to see the graphs.
 
 For the full per-skill table, see [`command-map.md`](command-map.md). For the
 "why" behind each piece, see [`architecture.md`](architecture.md).
@@ -10,22 +10,26 @@ For the full per-skill table, see [`command-map.md`](command-map.md). For the
 
 The happy path. Every arrow assumes the readiness gate of the previous phase
 passed; failures route through `/rite-plan repair` or `devrites-debug-recovery`.
-HITL slices pause before code is written; `/rite-resolve` is the resume verb.
+`/rite-temper` is the optional strategic branch; `/rite-vet` runs on every
+defined plan, with depth scaled to risk. HITL slices pause before code is
+written; `/rite-resolve` is the resume verb.
 
 ```mermaid
 flowchart LR
     Start([user has an idea]) --> Spec[/rite-spec/]
     Spec -.->|UI detected| Shape[devrites-ux-shape<br/>plan UX/UI → design-brief.md]
     Shape -.->|brief confirmed| Spec
+    Spec -.->|big / risky| Temper[/rite-temper/] -.->|strategy.md| Define
     Spec -->|spec.md ready| Define[/rite-define/]
-    Define -->|plan.md + tasks.md<br/>each slice tagged AFK/HITL| Build[/rite-build/]
+    Define -->|plan.md + tasks.md<br/>each slice tagged AFK/HITL| Vet[/rite-vet/]
+    Vet -->|every plan; light or full<br/>eng-review.md + test-plan.md| Build[/rite-build/]
     Build -->|one slice done<br/>+ evidence| Build
     Build -.->|"Forge: yes slice"| Forge[forge: K candidates<br/>→ devrites-forge-judge → 1 winner]
     Forge -.->|winner lands<br/>forge-report.md| Build
     Build -->|HITL gate fires| Await{{Awaiting human<br/>state.md + questions.md}}
     Await -->|"/rite-resolve &lt;qid&gt; &lt;answer&gt;"| Build
     Build -->|all slices built| Prove[/rite-prove/]
-    Define -.->|resumed / adopted / stalled<br/>code vs intent| Converge[/rite-converge/]
+    Build -.->|resumed / adopted / stalled<br/>code vs intent| Converge[/rite-converge/]
     Converge -.->|appends remaining slices| Build
     Prove -->|evidence captured| Polish[/rite-polish/]
     Polish -->|polish-report.md| Review[/rite-review/]
@@ -45,7 +49,7 @@ flowchart LR
     classDef repair fill:#4c1d95,stroke:#a78bfa,color:#f5f3ff
     classDef gate fill:#4c1d95,stroke:#a78bfa,color:#f5f3ff
     classDef internal fill:#0f172a,stroke:#9ca3af,color:#f9fafb
-    class Spec,Define,Build,Prove,Polish,Review,Seal,Ship2 phase
+    class Spec,Temper,Define,Vet,Build,Prove,Polish,Review,Seal,Ship2 phase
     class Shipped done
     class Repair repair
     class Await gate
@@ -107,9 +111,9 @@ flowchart LR
 ## 4. `/rite-seal` fan-out
 
 The seal fans out **all** relevant reviewers in parallel and reconciles their
-findings, then **decides** GO / NO-GO and stops. It no longer runs git — on GO
+findings, then **decides** GO / NO-GO and stops. It no longer runs git: on GO
 it hands off to `/rite-ship`, which renders the type-GO prompt and runs the
-irreversible commit · push · tag · archive. The old advisory score has been removed — the gate is severity + acceptance + drift.
+irreversible commit · push · tag · archive. The old advisory score has been removed: the gate is severity + acceptance + drift.
 
 ```mermaid
 flowchart TB
@@ -152,7 +156,7 @@ flowchart TB
 
 ## 5. `devrites-debug-recovery` seven-step loop
 
-Failure recovery — the loop construction in Phase 1 is the load-bearing piece.
+Failure recovery: the loop construction in Phase 1 is the load-bearing piece.
 
 ```mermaid
 flowchart LR
@@ -163,7 +167,7 @@ flowchart LR
     T -->|discriminating probe| I[Step 5<br/>Instrument]
     I -->|change one variable| Fix[Step 6<br/>Fix + regression test]
     Fix --> C[Step 7<br/>Cleanup + classify]
-    L1 -.->|can't build loop| Ask([STOP — ask user])
+    L1 -.->|can't build loop| Ask([STOP: ask user])
 
     classDef phase fill:#1f2937,stroke:#60a5fa,color:#f9fafb
     classDef stop fill:#7f1d1d,stroke:#f87171,color:#fee2e2
@@ -234,18 +238,18 @@ run mode for all skills.
 ```mermaid
 erDiagram
     ACTIVE ||--o| WORKSPACE : points-to
-    AFK_SENTINEL }|..|| RUN_MODE : "presence is authoritative — skills re-read at decision time"
+    AFK_SENTINEL }|..|| RUN_MODE : "presence is authoritative: skills re-read at decision time"
     WORKSPACE ||--|| state : has
     WORKSPACE ||--|| brief : has
     WORKSPACE ||--|| spec : has
-    WORKSPACE ||--o| strategy : "has (optional — from /rite-temper)"
+    WORKSPACE ||--o| strategy : "has (optional: from /rite-temper)"
     WORKSPACE ||--|| plan : "has (from /rite-define)"
-    WORKSPACE ||--|| tasks : "has — slices tagged Mode + Gate"
-    WORKSPACE ||--o| eng-review : "has (from /rite-vet — every plan, light or full)"
+    WORKSPACE ||--|| tasks : "has: slices tagged Mode + Gate"
+    WORKSPACE ||--o| eng-review : "has (from /rite-vet: every plan, light or full)"
     WORKSPACE ||--o| test-plan : "has (from /rite-vet; build + prove read it)"
     WORKSPACE ||--o{ references : "has (design refs)"
-    WORKSPACE ||--o| design-brief : "has (UI features — from /rite-spec via devrites-ux-shape; the build target)"
-    WORKSPACE ||--|| questions : "has — qid, gate, status (open/answered/dropped)"
+    WORKSPACE ||--o| design-brief : "has (UI features: from /rite-spec via devrites-ux-shape; the build target)"
+    WORKSPACE ||--|| questions : "has: qid, gate, status (open/answered/dropped)"
     WORKSPACE ||--|| decisions : has
     WORKSPACE ||--|| assumptions : has
     WORKSPACE ||--|| drift : has
@@ -262,7 +266,7 @@ erDiagram
     }
     AFK_SENTINEL {
         bool present "presence = AFK active"
-        int max_slices "read-only initial budget — copied to state.md once"
+        int max_slices "read-only initial budget: copied to state.md once"
         string notify "optional shell command on pause"
         list allow_gates "gate severities AFK may auto-handle"
     }
@@ -272,7 +276,7 @@ erDiagram
     state {
         string phase "frame | spec | temper | define | plan | vet | build | converge | prove | polish | review | seal | ship | done"
         string status "running | awaiting_human | blocked | done"
-        string active_slice "N — name"
+        string active_slice "N: name"
         int afk_slices_remaining "from .devrites/AFK max_slices on first AFK build"
         block awaiting_human "qid, gate, question, proposed, raised_at (only when paused)"
     }
@@ -291,11 +295,12 @@ The exact list of files per workspace and what each holds is in
 
 The `devrites-` prefix is collision-avoidance against bundled Claude Code
 skills (`prototype`, `handoff`, `triage`, `diagnose`). Visibility is the
-`user-invocable:` flag, not the prefix.
+`user-invocable:` flag, not the prefix; automatic model loading is controlled
+separately by `disable-model-invocation`.
 
 ```mermaid
 flowchart TB
-    subgraph Public["Public (user-invocable: true) — 24 skills"]
+    subgraph Public["Public (user-invocable: true): 30 skills"]
         direction TB
         R1[/rite/]
         R2[/rite-spec/]
@@ -304,6 +309,7 @@ flowchart TB
         RV[/rite-vet/]
         R4[/rite-plan/]
         R5[/rite-build/]
+        RC[/rite-converge/]
         R6[/rite-prove/]
         R7[/rite-polish/]
         R8[/rite-review/]
@@ -317,12 +323,17 @@ flowchart TB
         RA[/rite-adopt/]
         RL[/rite-learn/]
         RD[/rite-doctor/]
+        RE[/rite-explain/]
+        RCU[/rite-customize/]
+        RDO[/rite-dogfood/]
+        RPOV[/rite-pov/]
+        RPF[/rite-pr-feedback/]
         IPT[/rite-pressure-test/]
         D1[/rite-zoom-out/]
         D2[/rite-prototype/]
         D3[/rite-handoff/]
     end
-    subgraph Internal["Internal (user-invocable: false) — 12 skills (11 specialists + devrites-lib library)"]
+    subgraph Internal["Internal (user-invocable: false): 12 skills (11 specialists + devrites-lib library)"]
         direction TB
         I1[devrites-api-interface]
         I2[devrites-audit<br/>security · perf · simplify]
@@ -340,7 +351,7 @@ flowchart TB
 
     classDef pub fill:#064e3b,stroke:#34d399,color:#ecfdf5
     classDef int fill:#1f2937,stroke:#9ca3af,color:#f9fafb
-    class R1,R2,RT,R3,RV,R4,R5,R6,R7,R8,R9,R12,R13,R10,R11,RQ,RF,RA,RL,RD,IPT,D1,D2,D3 pub
+    class R1,R2,RT,R3,RV,R4,R5,RC,R6,R7,R8,R9,R12,R13,R10,R11,RQ,RF,RA,RL,RD,RE,RCU,RDO,RPOV,RPF,IPT,D1,D2,D3 pub
     class I1,I2,I3,I4,I5,I6,I7,I8,I9,I10,I11,I12 int
 ```
 
@@ -373,5 +384,5 @@ stateDiagram-v2
 ```
 
 `AFK` mode (`.devrites/AFK` present) widens which transitions stay in
-`running` via `allow_gates` — but `blocking`, `escalating`, fail-on-red, and
+`running` via `allow_gates`, but `blocking`, `escalating`, fail-on-red, and
 the irreversible-risk list always transition to `awaiting_human` regardless.

package/docs/harness-compliance.md

@@ -2,7 +2,7 @@
 
 DevRites drives more than one agent runtime from a single `devrites-engine`
 binary, but the runtimes do not expose identical enforcement surfaces. This page
-states — per surface — whether each supported harness enforces it natively,
+states, for each surface, whether a supported harness enforces it natively,
 through an adapter, or only by instruction the model may ignore. It is the honest
 answer to "does DevRites work the same on Codex as on Claude Code?"
 
@@ -40,6 +40,6 @@ the table and the code can never silently drift apart.
 | Standards step-0 load | Native | Instruction-backed | all phases | explicit standards read | partial | medium | Claude: skill Reads core.md. Codex: an AGENTS.md directive to read it. |
 | Project activation | Native | Conditional | Codex-only startup | inspect hooks/config, decide trust, then rerun doctor | yes | medium | Codex silently skips every .codex/ layer in an untrusted project; trust remains an operator decision after inspection. |
 
-Tiers: **Native** (the harness exposes and delivers the surface directly; policy notes state whether it blocks) · **Adapter-backed** (supported through a translation shim) · **Instruction-backed** (no runtime surface — rides on a directive the model may under-fire) · **Conditional** (native but gated on an operator precondition).
+Tiers: **Native** (the harness exposes and delivers the surface directly; policy notes state whether it blocks) · **Adapter-backed** (supported through a translation shim) · **Instruction-backed** (no runtime surface: rides on a directive the model may under-fire) · **Conditional** (native but gated on an operator precondition).
 
 <!-- END harness-matrix -->

package/docs/orchestration.md

@@ -1,6 +1,6 @@
 # Orchestration patterns
 
-How DevRites coordinates multiple agents — the patterns it uses, the ones it deliberately avoids,
+How DevRites coordinates multiple agents: the patterns it uses, the ones it deliberately avoids,
 and where Claude Code's Agent Teams and worktree isolation fit. The rule that governs this lives in
 [`pack/.claude/skills/devrites-lib/reference/standards/agents.md`](../pack/.claude/skills/devrites-lib/reference/standards/agents.md); this doc is the map.
 
@@ -8,15 +8,15 @@ and where Claude Code's Agent Teams and worktree isolation fit. The rule that go
 
 DevRites separates three roles and never blurs them:
 
-- **Orchestrator** — the active `rite-*` skill (chiefly `/rite-build` and `/rite-seal`). It owns
+- **Orchestrator**: the active `rite-*` skill (chiefly `/rite-build` and `/rite-seal`). It owns
   the gates and the `.devrites/` workspace, dispatches the other agents, and is the *single
   canonical writer* of workspace state.
-- **Reviewers** — fresh-context, **read-only** subagents under `.claude/agents/`. Each gets the
+- **Reviewers**: fresh-context, **read-only** subagents under `.claude/agents/`. Each gets the
   workspace path + the diff and returns labelled findings. The generated host hooks observe this
   boundary by default; set the documented strict-enforcement environment switch when a blocking
   tool-layer boundary is required. Without strict mode, the agent contract and reconciliation gate
   remain part of the control, rather than a fail-closed sandbox guarantee.
-- **Executor** — `devrites-slice-wright`, the one **write-capable** agent. It implements a single
+- **Executor**: `devrites-slice-wright`, the one **write-capable** agent. It implements a single
   fully-specified slice in a fresh context and returns code + tests; it never writes the `.devrites/`
   bookkeeping (the orchestrator does).
 
@@ -28,18 +28,18 @@ its judgment is independent.
 1. **Direct (no orchestration).** Most phases are one skill doing one job. Don't spawn an agent for
    work the phase can do inline.
 2. **Parallel read-only fan-out.** At `/rite-seal` the relevant reviewers run *in parallel*, then
-   the orchestrator reconciles — banding by confidence and surfacing genuine disagreement explicitly
+   the orchestrator reconciles them by confidence band and reports genuine disagreement
    rather than averaging it away.
-3. **Single writer.** Exactly one `devrites-slice-wright` per slice, never a parallel fan-out of
-   writers *sharing a tree* — concurrent writers on one tree make conflicting implicit decisions
+3. **Single writer.** Exactly one `devrites-slice-wright` works on each slice. DevRites never
+   fans out writers that share a tree because concurrent writers make conflicting implicit decisions
    that corrupt a coherent design. The one sanctioned exception is a **forge** slice
-   (`Forge: yes`, flagged by `/rite-vet`): K=2–3 candidate wrights build it on distinct strategies
+   (`Forge: yes`, flagged by `/rite-vet`). Two or three candidate wrights build it with distinct strategies
    in **isolated** worktrees, `devrites-forge-judge` scores them, and exactly one winner's diff
-   lands — no tree ever has two authors, so the invariant holds
+   lands. No tree ever has two authors, so the invariant holds
    ([`rite-build/reference/forge.md`](../pack/.claude/skills/rite-build/reference/forge.md)).
 4. **Lifecycle as user-driven verbs.** Each verb performs one mutation and stops; chaining is
    explicit (the user types the next command), so there are no hidden side effects between phases.
-   `/rite-autocomplete` is the one deliberate exception — an opt-in unattended driver.
+   `/rite-autocomplete` is the one deliberate exception: an opt-in unattended driver.
 5. **Adversarial single-claim check.** `devrites-doubt` spawns a fresh reviewer to try to refute one
    load-bearing decision, rather than asking the author to re-grade their own work.
 
@@ -47,15 +47,16 @@ its judgment is independent.
 
 - **A persona that paraphrases another.** Passing one agent's summary to the next is lossy telephone;
   reviewers read the raw diff and contract, not a digest of the author's reasoning.
-- **Parallel writers.** See single-writer above — two agents editing the same feature concurrently
+- **Parallel writers.** See single-writer above: two agents editing the same feature concurrently
   is a merge of conflicting decisions, not a speed-up. (Forge is *not* this: its candidates write in
   **isolated** worktrees and exactly one lands, so no tree is ever co-authored.)
-- **A router that does the work.** `/rite` is a *thin dispatcher* — it renders the menu, resolves a
+- **A router that does the work.** `/rite` is a thin dispatcher. It renders the menu, resolves a
   verb to a skill, and gets out of the way. It holds no phase logic and produces no artifact itself.
   (This is the distinction that makes a router fine: the anti-pattern is a "meta-orchestrator"
   persona that paraphrases and re-decides on every call, not a dispatch table.)
-- **Deep persona trees.** Agents don't call agents that call agents. The orchestrator dispatches one
-  level deep — reviewers and the wright — and reconciles the results itself.
+- **Deep persona trees.** Agents do not call agents that call more agents. The
+  orchestrator dispatches reviewers and the wright one level deep, then
+  reconciles the results itself.
 
 ## Agent Teams and worktree isolation
 
@@ -64,12 +65,12 @@ Two Claude Code capabilities sit adjacent to DevRites' model; the stance on each
 - **Agent Teams.** DevRites does **not** use Agent Teams to run the lifecycle. The on-disk workspace
   plus fresh-context read-only fan-out already give independent context per agent without the
   coordination overhead, and the lifecycle is intentionally single-slice / single-writer. Reach for
-  Agent Teams for work *outside* that discipline — competing-hypothesis debugging, or exploring
-  several genuinely different approaches in parallel — not to parallelise a DevRites build. The one
+  Use Agent Teams outside that discipline for competing-hypothesis debugging or
+  several genuinely different approaches in parallel. Do not use it to parallelize a DevRites build. The one
   in-lifecycle form of "compete several approaches" is **forge** (a `Forge: yes` slice), and it is
   deliberately bounded: vet-gated, K≤3, isolated, winner-takes-all.
 - **Worktree isolation.** A single feature is single-writer on one branch by design, so DevRites
-  doesn't spawn worktrees for ordinary builds — but you can run DevRites *inside* a git worktree to
+  does not spawn worktrees for ordinary builds. You can still run DevRites inside a git worktree to
   drive two features in parallel without them colliding (the `.devrites/ACTIVE` sentinel is
   per-working-tree, so each carries its own active feature). The one place DevRites spawns worktrees
   itself is a **forge** slice: each candidate build gets an ephemeral worktree, auto-removed after
@@ -77,7 +78,7 @@ Two Claude Code capabilities sit adjacent to DevRites' model; the stance on each
 
 ## See also
 
-- [`pack/.claude/skills/devrites-lib/reference/standards/agents.md`](../pack/.claude/skills/devrites-lib/reference/standards/agents.md) — the reviewer / executor roster
+- [`pack/.claude/skills/devrites-lib/reference/standards/agents.md`](../pack/.claude/skills/devrites-lib/reference/standards/agents.md): the reviewer / executor roster
   and the when-to-fan-out rules.
-- [`architecture.md`](architecture.md) — the full layer model.
-- [`flow.md`](flow.md) — phase-by-phase flow and the public/internal namespace.
+- [`architecture.md`](architecture.md): the full layer model.
+- [`flow.md`](flow.md): phase-by-phase flow and the public/internal namespace.

package/docs/porting-to-a-new-harness.md

@@ -1,6 +1,8 @@
 # Porting DevRites to a new harness
 
-DevRites is distributed through `npx devrites` and installs project-local artifacts. Do not add a harness through a Claude/Codex plugin or marketplace path.
+DevRites' canonical distribution path is `npx devrites` (with the documented
+Bash bootstrap as a Node-free alternative), and host artifacts install into the
+target project. Do not add a harness through a Claude/Codex plugin or marketplace path.
 
 Before adding a host, add its thin adapter to `engine/internal/harness/harness.go`,
 update the frozen matrix in `compliance.go`, and prove the host can run DevRites
@@ -20,7 +22,9 @@ The harness must invoke DevRites and route to `/rite-spec` (or the host's explic
 - Session/project orientation runs automatically at startup/compact/resume, or the missing surface is recorded in `docs/harness-compliance.md`.
 - `devrites-engine` hooks/gates are wired, or each degraded gate has an honest fallback and confidence label.
 - Subagent support is mapped; if unavailable, reviewers/wrights use the documented inline fallback and label it.
-- Install, update, and uninstall paths stay project-local; no global writes.
+- Skills, agents, standards, hooks, and harness guidance stay project-local;
+  the optional shared `devrites-engine` executable is the sole sanctioned
+  global artifact and must remain skippable with `--no-binary`.
 - Generated artifacts and `docs/harness-compliance.md` are updated from the same source of truth.
 - Routing eval includes the React todo-list acceptance prompt.