devrites 3.0.5 → 3.0.7

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,24 +28,24 @@ 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).
@@ -80,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.
 
@@ -126,7 +126,7 @@ 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.
 
 `status` makes no model or network calls; it is a pure read of the files under
@@ -137,6 +137,6 @@ 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
@@ -53,7 +53,7 @@ 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 |
 | --- | --- | --- | --- |
@@ -65,7 +65,7 @@ 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 |
 | --- | --- | --- | --- | --- | --- | --- |
@@ -78,11 +78,11 @@ 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` / `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). |
+| `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. |
@@ -92,7 +92,7 @@ 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`.
@@ -108,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).
@@ -111,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
@@ -156,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
@@ -167,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
@@ -238,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
@@ -266,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"
     }
@@ -276,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)"
     }
@@ -300,7 +300,7 @@ separately by `disable-model-invocation`.
 
 ```mermaid
 flowchart TB
-    subgraph Public["Public (user-invocable: true) — 30 skills"]
+    subgraph Public["Public (user-invocable: true): 30 skills"]
         direction TB
         R1[/rite/]
         R2[/rite-spec/]
@@ -333,7 +333,7 @@ flowchart TB
         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]
@@ -384,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/release.md

@@ -1,16 +1,27 @@
 # Release pipeline
 
-Releases are **fully automated** via [semantic-release](https://semantic-release.gitbook.io/): every push to `main` is analyzed; if the merged commits carry a `feat:`, `fix:`, `perf:`, `refactor:`, `build:`, `docs(README):` (or a `BREAKING CHANGE:` footer), the `release` job in [`.github/workflows/ci.yml`](../.github/workflows/ci.yml) determines the next SemVer version and:
+[semantic-release](https://semantic-release.gitbook.io/) handles releases. On
+each push to `main`, the `release` job in
+[`.github/workflows/ci.yml`](../.github/workflows/ci.yml) checks the merged
+commit messages. A `feat:`, `fix:`, `perf:`, `refactor:`, `build:`,
+`docs(README):`, or `BREAKING CHANGE:` tells it to choose the next SemVer
+version and run these steps:
 
 1. Waits for the workflow's validation, full shell suite, strict Go-engine checks, Linux cross-compile smoke, and Windows Go tests.
 2. Regenerates `CHANGELOG.md` from the commits.
 3. Syncs the new version into `package.json` and the README status line (`scripts/sync-version.sh`).
 4. Builds `dist/devrites-v<version>.tar.gz` plus its SHA-256 sidecar via `scripts/build-release-tarball.sh`. The extractable bundle used by `curl | bash` includes host-native Claude/Codex artifacts regenerated from `pack/.claude/` into `pack/generated/`.
 5. Cross-compiles five `devrites-engine` release binaries (macOS arm64/amd64, Linux arm64/amd64, Windows amd64) plus a SHA-256 sidecar for each.
-6. Publishes the `devrites` package to npm (`@semantic-release/npm`, requiring `NPM_TOKEN`) — this is what `npx devrites@latest` resolves. `npm pack` regenerates the same `pack/generated/` artifacts during `prepack`; there is no `postpack` cleanup step.
+6. Publishes the `devrites` package to npm through `@semantic-release/npm`, using `NPM_TOKEN`. This is what `npx devrites@latest` resolves. `npm pack` regenerates the same `pack/generated/` artifacts during `prepack`; there is no `postpack` cleanup step.
 7. Commits the version bump + changelog as `chore(release): <version> [skip ci]`, creates tag `v<version>`, and publishes a GitHub Release with the tarball, checksum, binaries, and binary checksum sidecars attached.
 
-Local dry-run: `npm run release:dry` (shows the proposed version + notes without publishing). For a manual preflight, `bash scripts/release-check.sh` builds an evidence packet covering generated-pack freshness, tarball checksum presence, `npx-pack-smoke`, install/update/uninstall, `validate-pack`, behavioral-eval schema, and the documented npm distribution path. This preflight is available to maintainers but is not a hidden semantic-release step. DevRites is not shipped through Claude or Codex plugin stores. The release job is gated by passing CI — a broken `main` won't ship.
+Run `npm run release:dry` to see the proposed version and notes without
+publishing. Maintainers can also run `bash scripts/release-check.sh` to build an
+evidence packet for generated artifacts, checksums, package smoke tests,
+install/update/uninstall, pack validation, the behavioral eval schema, and npm
+distribution. This manual preflight is not a hidden semantic-release step.
+DevRites does not ship through Claude or Codex plugin stores. The release job
+waits for CI, so a broken `main` does not ship.
 
 ## Authoring commits that trigger releases
 
@@ -26,6 +37,12 @@ Husky + commitlint reject non-conventional messages at commit time, so you can't
 
 ## Dependency updates
 
-Dependabot watches the `npm` and `github-actions` ecosystems and opens **weekly grouped PRs** for routine patch + minor bumps (see [`.github/dependabot.yml`](../.github/dependabot.yml)). The [`dependabot-auto-merge.yml`](../.github/workflows/dependabot-auto-merge.yml) workflow auto-approves + enables auto-merge (squash) on those PRs so they land when required checks are green. Major-version bumps stay open with a `needs-review` label so a human can scan the changelog before merging.
+Dependabot watches the `npm` and `github-actions` ecosystems and opens grouped
+PRs each week for routine patch and minor updates (see
+[`.github/dependabot.yml`](../.github/dependabot.yml)). The
+[`dependabot-auto-merge.yml`](../.github/workflows/dependabot-auto-merge.yml)
+workflow approves those PRs and enables squash auto-merge after the required
+checks pass. Major updates stay open with a `needs-review` label so a human can
+read the changelog before merging.
 
-> GitHub does not allow Dependabot to push directly to `main` — a PR is always opened. Auto-merge is the closest equivalent. Required CI checks still gate the merge.
+> GitHub does not allow Dependabot to push directly to `main`: a PR is always opened. Auto-merge is the closest equivalent. Required CI checks still gate the merge.

package/docs/research/go-authoritative-workflow-schema-and-quality-2026-07-20.md

@@ -1,4 +1,4 @@
-# Go Authoritative Workflow Schema and Quality Research
+# Go authoritative workflow schema and quality research
 
 Date: 2026-07-20
 
@@ -182,8 +182,8 @@ govulncheck ./...
 ```
 
 Run race-enabled tests for concurrency changes and a bounded fuzz job for state
-parsers. Run `deadcode` for every supported build configuration—at minimum the
-supported Unix and Windows targets—before deleting reported code. Review each
+parsers. Run `deadcode` for every supported build configuration, including the
+supported Unix and Windows targets, before deleting reported code. Review each
 finding; generated files, reflection, build tags, assembly, and external entry
 points can change reachability assumptions.