devrites 3.0.7 → 3.1.0

package/pack/generated/claude/skills/rite-frame/reference/failure-modes.md

@@ -1,9 +1,8 @@
-# The four failure modes: mapped to their DevRites cure
+# Four failure modes and their DevRites controls
 
-The lens behind `rite-frame`. Each mode is a thing LLMs reliably get wrong; each already
-has a cure somewhere in the pack. The value of naming them here is a **portable
-vocabulary**: a fast self-check you can run on ad-hoc or express-lane work that never
-reaches the gates where those cures normally fire.
+`rite-frame` checks four common LLM failure modes. Existing DevRites controls address
+each one. Use these names for quick checks on ad hoc or express-lane work that does not
+reach the normal gates.
 
 ## The map
 
@@ -11,18 +10,17 @@ reaches the gates where those cures normally fire.
 |---|---|---|---|
 | 1 | **Silent assumption** | A value, contract, edge case, or interpretation was *guessed* and run with: no note, no question. The ask had two readings and one was picked silently. | `core.md` #2 (no silent assumptions) / #3 (no guessing through confusion); the Spec Drift Guard; `devrites-doubt` for a single high-stakes call; `devrites-interview` when the ask is underspecified. |
 | 2 | **Overcomplication** | An abstraction, flag, config knob, or indirection nobody asked for. 200 lines where 50 would do. A single-use factory. Defensive `try/catch` + null checks inside trusted code. A dependency added where an in-repo option exists. | `coding-style.md` (simplicity, reuse-first), `patterns.md` (avoid over-engineering), `devrites-audit simplify` (deletion test, Chesterton's Fence), the "over-defensive guarding is slop" anti-pattern. |
-| 3 | **Out-of-scope edit** | Touched code, comments, or formatting outside the ask. A "while I'm here" refactor. Renamed something orthogonal. Reflowed an import block. | `core.md` #7 (feature scope only), `touched-files.md` (the recorded diff boundary), `devrites-engine reconcile` (hard-stops a source file changed outside the claimed set), the "it's only a small refactor" anti-pattern. |
+| 3 | **Out-of-scope edit** | Touched code, comments, or formatting outside the ask. A "while I'm here" refactor. Renamed something orthogonal. Reflowed an import block. | `core.md` #7 (feature scope only), root-owned `.wright-allowlist` (the authorized write boundary), `touched-files.md` (the resulting diff record), `devrites-engine reconcile` (hard-stops a source file outside the captured allowlist), the "it's only a small refactor" anti-pattern. |
 | 4 | **Unverifiable goal** | "It works" with no command, no output, no test. A success criterion that can't be false ("make it better"). A tautological test that passes no matter what. | `rite-spec/reference/acceptance-criteria.md` (measurable acceptance), `core.md` #6 (evidence over confidence), `testing.md` (assertion strength, see it fail first), the TDD wright. |
 
-The first three are the **diseases** Karpathy named; the fourth is the **leverage**: a
-falsifiable criterion is what lets the model loop to done without a human in the loop every
-few minutes. FRAME front-loads mode 4 so the AUDIT of modes 1-3 has something to check
-against.
+Karpathy named the first three. The fourth supplies the falsifiable criterion needed
+for an agent to work without repeated human confirmation. FRAME defines that criterion
+before auditing the other three modes.
 
-## FRAME: the imperative → falsifiable reframe
+## FRAME: rewrite an imperative as a falsifiable condition
 
-The move is to rewrite the *verb* as a *condition that can be false*. If you can't, the ask
-is ambiguous. That's mode 1, caught before the diff instead of after.
+Rewrite the request as a condition that can be false. If that is impossible, the
+request is ambiguous and triggers mode 1 before any diff exists.
 
 | Imperative ask | Weak (still a wish) | Falsifiable criterion + verify |
 |---|---|---|
@@ -33,8 +31,8 @@ is ambiguous. That's mode 1, caught before the diff instead of after.
 | "Handle errors" | "add error handling" | "On `<failure F>` the system fails closed with `<observable>`; a test forces F." → that test |
 | "Improve the UX" | "make it nicer" | *(no falsifiable check → ambiguous → `devrites-ux-shape` / ask which states/flows)* |
 
-A criterion passes the bar when a reviewer could run the verify command and get a clear
-pass or fail without asking you what you meant. If they'd have to ask, sharpen it.
+A criterion is ready when a reviewer can run the verification command and get a clear
+pass or fail without asking what it means.
 
 ## AUDIT: worked finding lines
 
@@ -49,20 +47,20 @@ utils.ts:5  FYI        mode 3 (scope): reflowed an unrelated import block. → r
 sum.spec:12 Important  mode 4 (unverifiable): test asserts `mock.called`, not the result — passes if the fn is empty. → assert the value; see it fail first (testing.md).
 ```
 
-Clean lanes say so explicitly (`1 assumption: clean`) so the audit is a positive
-statement, not a silent skip.
+Record clean modes explicitly (`1 assumption: clean`) so an empty result is not mistaken
+for a skipped check.
 
-## How this differs from the heavier tools (so you don't reach past it)
+## Related tools
 
 - **`devrites-doubt`:** adversarial *fresh-context subagent* pre-mortem on **one** decision.
-  Heavier, independent, anti-anchoring. rite-frame is *self-applied* and covers the four modes
-  broadly; escalate a single load-bearing claim to doubt.
+  It is independent and avoids anchoring. rite-frame is self-applied and covers all four
+  modes; use doubt for one consequential claim.
 - **`devrites-audit <axis>`:** *fresh-context subagent* review of an **active feature's** diff
   on one axis (security / perf / simplify). Needs a `.devrites/` workspace. rite-frame needs no
-  workspace and runs in your own context: cheaper, less independent.
+  workspace and runs in the current context, with less independence.
 - **`/rite-review` · `/rite-seal`:** the **gates**: parallel reviewer fan-out, blocking
   severities, written verdict. rite-frame is the inline reflex for work that never reaches a
-  gate; it does not replace one. If the work is a real feature, the gate is the answer.
+  gate and does not replace one.
 
-The point is not redundancy. It's a tiered ladder. rite-frame is the cheapest rung: a lens
-you run yourself in seconds. Climb to doubt / audit / the gates as the stakes rise.
+Use rite-frame for the quickest self-check. Use doubt, audit, or the full gates when the
+work needs independent or feature-level review.

package/pack/generated/claude/skills/rite-plan/SKILL.md

@@ -7,8 +7,9 @@ user-invocable: true
 
 # /rite-plan: (re)plan an active feature
 
-Reshape the plan when reality and the plan disagree. **Read the active workspace
-first.** If `.devrites/ACTIVE` is empty or its workspace is missing, stop and tell the
+Update an existing plan when implementation evidence, drift, or a user decision makes it
+wrong. **Read the active workspace first.** If `.devrites/ACTIVE` is empty or its workspace
+is missing, stop and tell the
 user to run `/rite-spec <feature>`. **Revise mode is artifact-only**: reconcile
 `spec.md` / `architecture.md` / `plan.md` / `tasks.md` / `traceability.md` without
 editing source code.
@@ -17,9 +18,11 @@ editing source code.
 Pull `development-workflow.md` via `Read` when reshaping slice cadence or DoD criteria.
 
 ## Operating rules
-- Spec is living, not sacred, but never plan around a known-wrong assumption silently.
+- Update the spec when needed, but never plan around a known-wrong assumption.
 - If a change alters product behavior, scope, architecture, data model, UX, security,
-  or migration risk → **ask the user first** (use the Spec Drift Guard question format).
+  or migration risk → search facts first, then route the human-owned contract decision
+  through `/rite-clarify` (using the Spec Drift Guard). Reversible technical repair is
+  agent-owned and must not become a question.
 - Keep each slice small enough for one focused build → prove cycle.
 - **Slice count is derived, never dictated:** reslice when a slice fails the sizing rule
   (multiple "and"s, can't build+prove in one cycle), not to hit a user-named tally. A
@@ -28,13 +31,18 @@ Pull `development-workflow.md` via `Read` when reshaping slice cadence or DoD cr
 - **Size by complexity, order by dependency.** A slice carries a `Complexity: N/5` score (from
   `/rite-define`); a slice scoring **>3** is a reslice trigger unless its inline reason justifies
   the irreducible complexity. Honor each slice's `depends_on:`: the next *buildable* slice is the
-  lowest pending one whose dependencies are all built (keeps one-slice-at-a-time correct, not parallel).
+  lowest pending one whose dependencies are all built. This preserves one-slice-at-a-time execution.
+- **Root writes; drafter proposes.** Follow
+  [`agents.md`](../devrites-lib/reference/standards/agents.md). The controlling chat owns
+  human questions, decisions, reconciliation, and all planning-artifact writes.
 
 ## Workflow
 0. Read `.claude/skills/devrites-lib/reference/standards/core.md` (operating rules) before reshaping anything.
    Then run `devrites-engine preamble` for deterministic workspace orientation.
-1. Read `spec.md`, `plan.md`, `tasks.md`, `state.md`, `drift.md`, and the current
-   `git diff` (if a repo). Read `decisions.md` and `assumptions.md`. If a code-intelligence
+1. Read `spec.md`, `decision-coverage.md`, `plan.md`, `tasks.md`, `state.md`, `drift.md`,
+   `eng-review.md`, and the current `git diff` (if a repo). Read `decisions.md` and
+   `assumptions.md`. Require `Decision coverage: CLEAR`; otherwise STOP → `/rite-clarify`.
+   If a code-intelligence
    index is available: `codebase-memory-mcp` first, cross-checked with `codegraph`
    (`.codegraph/` / `codegraph_*` tools) + `graphify` (`graphify-out/`), else standard methods
    (LSP / `Read`/`Grep`/`Glob`); see `.claude/skills/devrites-lib/reference/standards/tooling.md`:
@@ -56,28 +64,48 @@ Pull `development-workflow.md` via `Read` when reshaping slice cadence or DoD cr
      scope, not a new negotiation.
    - **revise:** apply a requested planning-artifact revision and reconcile existing artifacts in
      any direction; propose the file edit set first, confirm each file before writing, and **never
-     edit source code**. **Gate first: revise or new?** Same intent? >50% of existing scope
+     edit source code**. **Gate first: revise or new?** Same intent? More than 50% of existing scope
      survives? original *not* completable without this? Two "no"s → new work: recommend
      sealing/shipping the current workspace (MVP cut if named) then `/rite-spec` for the new
-     intent, and stop. Revise preserves context; a new workspace provides clarity.
+     intent, and stop. Revise preserves context; a new workspace separates the work.
    See [replan-and-repair](reference/replan-and-repair.md) for each mode's steps.
+2a. **Draft the repair from fresh context.** Freeze the inputs and dispatch
+   `devrites-plan-drafter` in `repair` mode with only the selected mode, affected artifact
+   paths, settled contract, and observed failure/drift. Await one atomic `plan-candidate`;
+   the drafter writes nothing and returns human-owned choices separately.
 3. Reason about dependencies: [dependency-graph](reference/dependency-graph.md).
    **Completion:** the slice graph is cycle-free and every dependency names an existing slice.
 4. Re-slice using vertical-slice rules: [slicing](reference/slicing.md) and
    [task-breakdown](reference/task-breakdown.md). Prefer thin, shippable, verifiable.
    **Completion:** every slice is independently shippable/provable or carries an irreducibility reason.
-5. Update `plan.md`, `tasks.md`, `state.md`, and append rationale to `decisions.md`.
-   If you stopped for drift, mark the `drift.md` entry resolved.
-6. If product behavior/acceptance criteria change, confirm with the user before writing.
+5. Reconcile the candidate against steps 3 and 4, then the root updates `plan.md`, `tasks.md`,
+   `state.md`, and appends rationale to `decisions.md`.
+   Any change to `architecture.md`, `plan.md`, `tasks.md`, or `traceability.md` invalidates
+   the previous vet verdict: set `Phase: plan`, `Next step: /rite-vet`, and, when
+   `eng-review.md` exists, set `Implementation readiness: NEEDS REPLAN`. Never retain READY
+   across changed planning inputs. Preserve `Plan approved` only for behavior/acceptance-neutral
+   technical repair; clear and reconfirm it when the contract changed. If you stopped for drift,
+   mark the `drift.md` entry resolved.
+6. If product behavior/acceptance criteria change, confirm through `/rite-clarify` before
+   writing, re-close `decision-coverage.md`, then reconcile the plan. After any edit to
+   `brief.md`, `spec.md`, `decisions.md`, `assumptions.md`, or `questions.md`, including a
+   behavior-neutral technical rationale appended to `decisions.md`, re-scan the affected coverage
+   rows, assumption audit, residual uncertainty, and closed gates. Partial/Missing, an unowned
+   material assumption, or an open blocking/escalating question routes `/rite-clarify`/HITL;
+   never refresh past it. Only after the matrix is re-closed, run
+   `devrites-engine readiness-digest coverage <slug>` and replace the complete
+   `Coverage inputs SHA-256` line in `decision-coverage.md`.
    **Completion:** the change is classified, and every behavior/acceptance change has explicit
    confirmation recorded before the artifacts are updated.
 7. **Done when:** every slice is sized (builds + proves in one cycle; no slice scoring >3
    left unjustified), the dependency order is acyclic, every `drift.md` entry you stopped for
    is marked resolved, revised artifacts agree with each other, no source files changed in
-   `revise` mode, and behavior-change-vs-not is confirmed (`no`, or asked + answered).
+   `revise` mode, behavior-change-vs-not is confirmed (`no`, or clarified), and every changed
+   plan ends at `/rite-vet` rather than returning directly to build.
    If any check fails, loop back: don't hand off a half-reshaped plan.
 
-> **Mid-flight discipline.** When tempted to change product behavior without asking, absorb drift silently, or skip the user: see [`anti-patterns`](reference/anti-patterns.md). Load it the moment you reach for the excuse.
+> **Mid-flight discipline.** Do not change product behavior without confirmation or
+> absorb drift silently. See [`anti-patterns`](reference/anti-patterns.md).
 
 ## Output
 
@@ -86,10 +114,10 @@ Pull `development-workflow.md` via `Read` when reshaping slice cadence or DoD cr
 Default success shape:
 ```
 Done: plan repaired for <slug> in <mode> mode.
-Changed: plan.md, tasks.md, traceability.md, decisions.md, state.md
+Changed: plan.md, tasks.md, traceability.md, decisions.md, state.md, eng-review.md <invalidated|n/a>
 Evidence: not applicable; slice map now <n> slices and next slice is <name>
 Open: <none | behavior question answered | Alternative: /rite-prove if all built slices need re-verification>
-Next: <single next command: build, re-define, or prove depending on the revision>
+Next: /rite-vet
 Record: .devrites/work/<slug>/plan.md
 ↻ Hygiene: /clear if the repair was large; keep session for small reorder-only repairs
 ```

package/pack/generated/claude/skills/rite-plan/reference/task-breakdown.md

@@ -20,6 +20,10 @@ This reference owns decomposition; the shared schema owns field names and meanin
    planned proof, evidence status, and likely touched files.
 6. Sanity check: every acceptance criterion in `spec.md` maps to ≥1 slice; no slice has
    an unowned criterion.
+7. Resolve every foreseeable human-owned checkpoint now. Keep a build-time checkpoint only
+   when it needs evidence unavailable before code or mandatory action-time approval, and say why.
+8. Make every `Tests/proof` entry executable: exact command, working directory, prerequisites,
+   expected signal, and mutable inputs whose provenance evidence must bind.
 
 ## Keep it honest
 - **Interfaces prevent cross-slice drift.** A slice-wright sees only its own contract; the

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

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

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

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

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

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

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

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

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

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