devrites 3.0.6 → 3.1.0

package/pack/.claude/skills/rite-vet/SKILL.md

@@ -5,44 +5,31 @@ argument-hint: "[slug] [--cross-model] [--full]"
 user-invocable: true
 ---
 
-# /rite-vet: vet the plan before you build
+# /rite-vet: review the plan before build
 
-Take a defined plan and **vet** it the way a senior staff engineer would in a plan review:
-challenge the scope, walk architecture / plan code-quality / test-coverage / performance,
-calibrate every finding by confidence (and refuse to emit one you can't trace to a quoted
-line), design the test coverage the build will target, and map the failure modes and
-parallel lanes: *before* `/rite-build` writes a line. The one DevRites step that hardens
-the **implementation plan** at the engineering level and folds the result into the canonical
-contract, so the build follows a reviewed plan. Runs on **every** plan (depth scales to
-stakes; never skipped) and is always part of `/rite-autocomplete`; `--cross-model` adds a
-different-model second opinion. **Read the active workspace first**; if there's no
-`plan.md`, tell the user to run `/rite-define`.
+Review a defined plan for implementation scope, architecture, code quality, test
+coverage, performance, failure modes, and parallel work. Cite the source for every
+finding and design the test coverage that `/rite-build` will use. Fold accepted
+engineering changes into the canonical plan before code is written. Run this step on
+**every** plan; depth varies with risk. `/rite-autocomplete` always includes it, and
+`--cross-model` adds a second opinion from another model. **Read the active workspace
+first**; if there is no `plan.md`, tell the user to run `/rite-define`.
 
-This is the engineering counterpart to `/rite-temper` (which is strategic, on the *spec*).
-Temper decides *the right thing*; vet decides *the right way to build it*.
+`/rite-temper` reviews product scope and strategy in the spec. `/rite-vet` reviews how
+to implement that settled scope.
 
 ## Rules consulted (read on demand from `.claude/skills/devrites-lib/reference/standards/`)
-Pull on demand: `principles.md` (the project
-invariants gate (how `.devrites/principles.md` is scored pass/fail), `patterns.md` +
-`coding-style.md` (the over-engineering / reuse-first / YAGNI rubric) reuse the pack's
-standard), `testing.md` (the test-coverage axis) + `spec-grammar.md` (when the spec uses
-structured Requirement/Scenario blocks, each scenario is a coverage unit `test-plan.md` must
-map), `performance.md` (the perf axis),
-`error-handling.md` (failure-mode coverage), `development-workflow.md` (parallel lanes,
-definition of done), `afk-hitl.md` (irreversible-risk list + gate ceiling),
-`developer-experience.md` (when the plan ships a developer-facing surface (API / CLI / SDK /
-webhook / config / error messages / getting-started) predict the DX scorecard here),
-`elicitation.md` (the move-set to deepen an axis finding or a risky design choice: selected by
-the section's risk: Tournament for two viable designs, Delphi for a shaky estimate, Assumption
-Audit for a plan resting on unstated beliefs).
-- `definition-of-done.md`: standing Done bar: acceptance mapped, fresh proof, no open hard gates, scoped edits, rollback/docs where needed.
+Pull the standard named by the active axis: `principles.md`, `patterns.md`,
+`coding-style.md`, `testing.md`, `spec-grammar.md`, `performance.md`,
+`error-handling.md`, `development-workflow.md`, `afk-hitl.md`,
+`developer-experience.md`, `elicitation.md`, and `definition-of-done.md`.
 
 
 ## Operating rules
-- **Review the plan, not the spec's ambition.** The spec's scope/ambition is `/rite-temper`'s
-  job and is treated as settled here. Vet asks *given this scope, is this the right, simplest,
-  best-tested, lowest-risk way to build it*, and challenges only implementation scope creep.
-- **You harden the plan directly; the reviewer judges.** Vet *is* the plan-hardening phase, so
+- **Review implementation, not product ambition.** Treat the scope established by
+  `/rite-temper` as settled. Check whether the plan is simple, well tested, and low risk,
+  and challenge only implementation scope creep.
+- **The root updates the plan; the reviewer judges.** Vet is the plan-hardening phase, so
   behavior-preserving plan refinements (test requirements, tightened scope boundaries, ordering,
   parallel lanes, error-handling + failure-mode coverage) are written straight into
   `plan.md` / `tasks.md` / `test-plan.md`. You are the single canonical writer. A finding that
@@ -50,80 +37,71 @@ Audit for a plan resting on unstated beliefs).
   through the **Spec Drift Guard** (record in `drift.md`, recorded decision, then `/rite-plan
   repair` for any structural reslice). Nothing that grows the build's scope lands without a
   recorded human decision.
-- **Confidence over assertion.** Every finding carries a confidence band; a finding you cannot
+- **Support every finding.** Every finding carries a confidence band; a finding you cannot
   back by quoting the plan/spec line (or the code it references) is forced to low confidence and
   suppressed from the main report: see the verification gate in [`reference/review-axes.md`](reference/review-axes.md).
-- **Bound rigor by reversibility.** Auth / migration / public-API / data-model touches get
-  maximum conservatism and always pause (irreversible-risk list), regardless of run mode.
-- **Honest verdict, gated on the floor.** Never round "thin" up to "ready"; the axis verdict is
-  the weakest finding, not an average. Record every call's *why*.
+- **Apply maximum caution to hard-to-reverse changes.** Auth, migration, public API, and
+  data-model changes always pause under the irreversible-risk list.
+- **Use the lowest axis band.** Never round `thin` up to `ready`; do not average the
+  axes. Record the reason for every decision.
+- **Search before asking.** Apply `afk-hitl.md` decision ownership: verify facts and fold
+  reversible technical hardening into the plan; ask only about human-owned choices.
+- **Root hardens; reviewer judges.** Dispatch follows the file-backed contract in
+  [`agents.md`](../devrites-lib/reference/standards/agents.md). The root owns every
+  question, decision, fold-back, readiness verdict, and workspace write.
 
 ## Workflow
 0. **Read `.claude/skills/devrites-lib/reference/standards/core.md`** first.
-   Then **run the shared orientation preamble**. It prints `state.md`, the artifacts present,
-   the run mode (HITL/AFK), and the open-question tally by gate, so you orient deterministically
-   instead of re-deriving state from raw Markdown:
+   Then run the shared orientation preamble. It prints `state.md`, present artifacts,
+   run mode, and open-question totals:
    ```bash
    devrites-engine preamble
    devrites-engine snapshot
    ```
-   Then the workspace: `plan.md`, `tasks.md`, `spec.md`
+   Then the workspace: `plan.md`, `tasks.md`, `spec.md`, `decision-coverage.md`
    (for intent + acceptance), `strategy.md` (if `/rite-temper` ran), `decisions.md`,
    `assumptions.md`, `design-brief.md` (if UI), `state.md`. Require a `plan.md` whose
-   Readiness gate passes (or `Plan approved`): else STOP → `/rite-define`. Prefer a
+   Readiness gate passes (or `Plan approved`): else STOP → `/rite-define`. Require
+   `Decision coverage: CLEAR`: else STOP → `/rite-clarify`. Prefer a
    code-intelligence index if available (see
    `.claude/skills/devrites-lib/reference/standards/tooling.md`) for placement / blast-radius / reuse checks.
-1. **Calibrate depth. Never skip this step.** See [`reference/depth.md`](reference/depth.md). Every plan is
-   vetted; what scales is the *depth*. A simple, single-module, reversible plan with no
-   irreversible-risk / data-model / new-pattern trigger → **light pass** (brief scope check + a
-   one-line scan per axis + the acceptance→test map). Any full-pass trigger (or `--full`) → the
-   **full pass** below. There is no skip: every feature leaves a recorded engineering verdict and
-   a `test-plan.md` coverage map.
-2. **Scope Challenge (blocking gate):** [`reference/review-axes.md`](reference/review-axes.md)
-   §0. Search prior archived decisions for the plan's main nouns before asking the human to re-decide:
-   `devrites-engine decisions search "<2-4 plan nouns>"` (run `decisions index` first if needed).
-   What already exists that solves a sub-problem (reuse vs rebuild)? The minimum diff for the
-   stated acceptance? Complexity smell (the plan touches **>8 files** or adds **>2 new
-   services/modules**) → **STOP and ask** before any axis. Verify each new pattern / infra choice
-   against a built-in (dispatch `devrites-source-driven`); completeness check (with AI, full
-   coverage is ~100× cheaper than the human-hours saved by a shortcut: prefer complete); and a
-   distribution check for any new artifact.
-2a. **Cross-artifact analyze gate + principles / charter / conventions gate.** Before the axes, run
-   one read-only consistency+coverage pass over `spec.md` + `plan.md` + `tasks.md` (+ `traceability.md`
-   if present); any **CRITICAL**: an acceptance criterion with no slice, a slice satisfying no
-   criterion, a contradiction across artifacts, a requirement stated twice with conflicting terms:
-   **blocks `/rite-build`** until resolved. The engine covers the deterministic floor (AC coverage,
-   orphan slices, vague adjectives); you add the semantic passes it can't: **terminology drift**
-   (the same concept named differently across artifacts: normalize to the spec's term) and
-   **duplicated or conflicting requirements**. Then score
-   the three project gates as explicit **pass/fail** on the planned approach:
-   - **Principles** (`.devrites/principles.md`, rubric in [`principles.md`](../devrites-lib/reference/standards/principles.md)).
-     The authored invariants the project will not break. A plan that bakes in a violation of a
-     declared principle with **no recorded, human-approved exception** is a **top-severity** finding,
-     walked **first**, and **blocks `/rite-build`**. Absent or empty file → none declared → passes;
-     **never block for the absence of principles**. A genuine need to break one routes to a scoped,
-     dated exception in the principles register: never a silent work-around (adding the exception is
-     an irreversible-risk decision: it always pauses for a human, even in AFK).
-   - **The anti-slop charter** (`coding-style.md` + `prose-style.md`) and **the conventions ledger**
-     (`.devrites/conventions.md`): a plan that bakes in a god-module, a speculative abstraction with
-     no second caller, or a dependency where an in-repo option exists is a **top-severity** violation.
-   **Re-check all three after the axes harden the plan** (post-design). Write the result to `analysis.md`.
+1. **Set review depth. Never skip this step.** Apply
+   [`reference/depth.md`](reference/depth.md) exactly. Every plan leaves a recorded
+   engineering verdict and `test-plan.md` coverage map.
+1a. **Required initial independent pass (light and full).** Before hardening or writing,
+   freeze the candidate and dispatch `devrites-plan-reviewer` with the plan/spec packet.
+   Await and validate its report. Light depth reduces the inline hardening, not this
+   independent gate. Dispatch the DevEx predictor alongside it when triggered (within the
+   maximum-three read-only budget).
+2. **Scope challenge (blocking gate):** apply §0 of
+   [`reference/review-axes.md`](reference/review-axes.md). Search prior decisions first:
+   `devrites-engine decisions search "<2-4 plan nouns>"`. Harden to the smallest
+   behavior-preserving plan; ask only when that changes acceptance or explicit architecture policy.
+2a. **Cross-artifact analyze + project gates.** Run the deterministic gate, add the
+   semantic terminology/conflict pass, and score principles, the anti-slop charter, and
+   conventions using their named standards. Any Critical blocks `/rite-build`; a principle
+   exception is always human-owned, while an absent principles file passes. Re-check after
+   hardening and write the result to `analysis.md`.
    ```bash
    devrites-engine analyze; echo "analyze rc=$?"
    ```
-3. **Four-axis review:** [`reference/review-axes.md`](reference/review-axes.md), through the
-   senior-engineer lenses in [`reference/eng-lenses.md`](reference/eng-lenses.md): **Architecture
-   → Plan code-quality → Test-coverage design → Performance**, ≤8 findings per axis, each
-   `[severity] (confidence: N/10) <ref> — finding`. **Walk findings WITH the human, one at a
-   time** via `AskUserQuestion` (best-guess + why + options with effort/risk/maintenance, mapped
-   to a rule): the artifact is the *output* of the review, not a substitute for it.
-   When an axis finding hinges on a genuinely open design choice or a shaky estimate, deepen that
-   one finding with a fitting technique from
-   [`elicitation.md`](../devrites-lib/reference/standards/elicitation.md) (Tournament for two viable
-   designs, Delphi for the estimate, Assumption Audit for unstated beliefs) before you band it. (AFK ceiling
-   single-sourced in [`reference/depth.md`](reference/depth.md): hardening /
-   coverage-increasing findings auto-apply; **anything that grows scope or changes acceptance is a
-   blocking pause**; irreversible-risk always pauses.)
+2b. **Build-entry preflight.** Using [`reference/artifacts.md`](reference/artifacts.md), verify
+   each exact proof command/cwd/tool/version and prerequisite; package names against their
+   authoritative source plus nearest manifest/lockfile; parser-sensitive planned syntax in an
+   isolated fixture; and the existing UI/browser harness where applicable. Record complete
+   SHA-256 provenance inputs. This is non-mutating and need not make future behavior pass.
+2c. **Implementation-readiness audit.** Goal-backward map every REQ/AC/NFR, interaction,
+   edge/prohibition, and decision-coverage row to a slice and executable proof. Verify
+   UX/spec/architecture alignment, producer-consumer contracts, slice independence/order and
+   wiring, exact prerequisites, failure paths, operations, observability, rollout, and rollback.
+   Fold technical fixes into the plan. Product/risk gaps are `NEEDS CLARIFICATION` →
+   `/rite-clarify`; technical plan/preflight gaps are `NEEDS REPLAN` → `/rite-plan repair`.
+   Neither becomes a build qid.
+3. **Review four axes:** apply [`reference/review-axes.md`](reference/review-axes.md)
+   through [`reference/eng-lenses.md`](reference/eng-lenses.md). Fold verified,
+   behavior-preserving technical findings into the plan. Walk only human-owned decisions with
+   the human, one coherent option packet at a time. The AFK ceiling remains owned by
+   [`reference/depth.md`](reference/depth.md): scope/acceptance changes and irreversible risk pause.
 4. **Required outputs:** write every shape and fold-back required by
    [`reference/artifacts.md`](reference/artifacts.md), using the review rules in
    [`reference/review-axes.md`](reference/review-axes.md). Ground parallelization in:
@@ -131,34 +109,52 @@ Audit for a plan resting on unstated beliefs).
    devrites-engine lanes plan "$(cat .devrites/ACTIVE 2>/dev/null)"
    ```
    Completion: every scenario and acceptance criterion maps to planned proof, every slice is
-   one-pass implementable, and developer-facing plans have a predicted `devex.md` scorecard.
-4a. **Forge gate (only when `Forge: yes`).** Apply the eligibility and scorecard contract in
-   [`rite-build/reference/forge.md`](../rite-build/reference/forge.md). Confirm and record
-   genuinely distinct strategies, or clear the flag; an ineligible Forge never reaches build.
-5. **Write `eng-review.md` + `test-plan.md`, fold back:** [`reference/artifacts.md`](reference/artifacts.md).
-   `eng-review.md` is the durable record; `test-plan.md` is the build-readable coverage target
-   (`/rite-build` and `/rite-prove` read it). Harden `plan.md` / `tasks.md` directly for
-   behavior-preserving refinements; route every acceptance/behavior-changing delta through the
-   **Spec Drift Guard** (`drift.md` + recorded decision + `/rite-plan repair`). Append
-   `decisions.md` (one ADR per material call) and `assumptions.md`. Re-run the gate after
-   every fold-back so a task edit cannot invalidate the earlier pass:
+   one-pass implementable, the Build-entry preflight is green or names an owned prerequisite,
+   and developer-facing plans have a predicted `devex.md` scorecard.
+4a. **Forge gate.** `/rite-define` leaves `no` / `none` / `none`; Vet alone promotes under
+   [`rite-build/reference/forge.md`](../rite-build/reference/forge.md). Require a costly
+   unresolved architecture fork, 2–3 distinct complete contiguous `A`–`C` strategies, every
+   slice AC plus exact `test-plan.md` rows/commands, and `manifest-env-v1` as an explicit
+   Build-entry prerequisite. After final fold-back the three fields must agree, else clear
+   Forge before READY.
+5. **Write and fold back every artifact required by
+   [`reference/artifacts.md`](reference/artifacts.md).** Route every
+   acceptance/behavior-changing delta through the **Spec Drift Guard** (`drift.md` +
+   recorded decision + `/rite-plan repair`). After any edit to
+   `brief.md`, `spec.md`, `decisions.md`, `assumptions.md`, or `questions.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 is
+   `NEEDS CLARIFICATION` → `/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`. This coverage refresh must precede
+   `devrites-engine readiness-digest engineering <slug>`.
+   Re-run the gate after every fold-back so a task edit cannot invalidate the earlier pass:
    ```bash
    devrites-engine analyze; echo "final analyze rc=$?"
    ```
    Any non-zero result blocks the handoff. Then update `state.md`:
-   `Phase: vet`, `Next step: /rite-build`; on a blocking pause write the `Awaiting human` block +
-   `Status: awaiting_human` before stopping.
-6. **Adversarial verification loop.** Apply the light/full branching contract in
-   [`reference/depth.md`](reference/depth.md). Full mode dispatches the fresh-context plan
-   reviewer, plus the devex predictor when applicable, for at most three repair iterations;
+   write one typed field to `eng-review.md`: `Implementation readiness: READY`,
+   `NEEDS CLARIFICATION`, or `NEEDS REPLAN`. Only READY sets `Phase: vet` and
+   `Next step: /rite-build`, after a final sweep leaves no foreseeable human choice except a
+   justified action-time checkpoint. Technical failure records its reproduction and
+   `/rite-plan repair` without a qid; a human-owned contract gap routes `/rite-clarify` and
+   uses the normal awaiting-human block.
+6. **One narrow recheck after accepted edits.** If steps 2 through 5 changed the frozen candidate,
+   dispatch `devrites-plan-reviewer` once more with only the accepted initial findings,
+   changed planning paths, affected criteria, and the new immutable identity. Do not repeat
+   the full review or start a third loop. If nothing changed, the initial report is final.
+   If the recheck causes an accepted edit, repeat step 5, including coverage refresh and analyze,
+   before generating the engineering digest.
    [`reference/cross-model.md`](reference/cross-model.md) owns the optional outside voice.
-   Completion: the final axis floor clears or a blocking gate is recorded.
-7. **STOP.** Report the scope verdict, the per-axis floor, the coverage gaps closed, and the
-   failure-mode criticals; recommend `/rite-build`.
+   Completion: the final axis floor clears, an objective technical blocker is recorded, or a
+   genuine human-owned gate is recorded.
+7. **STOP.** Report the scope verdict, lowest axis band, coverage gaps closed, the
+   Build-entry preflight, expected action-time checkpoints, and the failure-mode criticals;
+   recommend `/rite-build` only when the entry contract is ready.
 
-> **Mid-flight discipline.** When tempted to batch-dump findings into `eng-review.md` and skip
-> the walk-through, harden the plan past a finding that changes acceptance, score before
-> quoting the source, or wave through a complexity smell "to keep moving": see
+> **Mid-flight discipline.** Do not replace the interactive review with
+> `eng-review.md`, change acceptance through plan hardening, score without source
+> evidence, or ignore unexplained complexity. See
 > [`reference/anti-patterns.md`](reference/anti-patterns.md).
 
 ## Output
@@ -169,12 +165,13 @@ Default success shape:
 ```
 Done: plan vetted for <slug>; depth <light|full> with axis floor <band>.
 Changed: eng-review.md, test-plan.md, plan.md, decisions.md
-Evidence: coverage <x/y> planned; open findings Critical 0 / Important 0 / Suggestion <n>; reviewer loop <n>; outside-voice <ran|skipped-unavailable|disabled>
+Evidence: Implementation readiness: READY; coverage <x/y> planned; build-entry preflight <pass>; open findings Critical 0 / Important 0 / Suggestion <n>; reviewer loop <n>; outside-voice <ran|skipped-unavailable|disabled>
 Open: none
 Next: /rite-build
 Record: .devrites/work/<slug>/eng-review.md
 ↻ Hygiene: /clear before /rite-build
 ```
 If a blocker or Spec Drift Guard delta remains, use the shared `Stopped / blocked`
-form and route `Fix:` to `/rite-plan`; do not recommend `/rite-build`.
+form and route `Fix:` to `/rite-clarify` for product/risk decisions or `/rite-plan`
+for technical replanning; do not recommend `/rite-build`.
 **DO NOT write code, slice, or run the build here**. That's `/rite-build`. Vet reviews and hardens the plan; it never implements.

package/pack/.claude/skills/rite-vet/reference/artifacts.md

@@ -1,9 +1,7 @@
 # `eng-review.md` + `test-plan.md` templates + fold-back rules
 
-`/rite-vet` produces two artifacts and a set of fold-back edits. `eng-review.md` is the durable
-**record** of the review; `test-plan.md` is the build-readable **coverage target**; the
-fold-back edits to `plan.md` / `tasks.md` are what the build follows. The record
-without the fold-back is dead prose: the build reads `plan.md` + `test-plan.md`, not `eng-review.md`.
+`eng-review.md` records the review; `test-plan.md` is the build-readable coverage target.
+Fold findings into `plan.md`/`tasks.md`: review prose alone does not change the build.
 
 ## `eng-review.md`: the record
 Write to `.devrites/work/<slug>/eng-review.md`. If one exists for the slug, **update** it, don't
@@ -12,6 +10,8 @@ clobber.
 ```markdown
 # Eng review: <slug>
 Vetted: <iso>   Cross-model: ran (codex) | off
+Implementation readiness: <READY | NEEDS CLARIFICATION | NEEDS REPLAN>
+Readiness inputs SHA-256: <exact value from `devrites-engine readiness-digest engineering <slug>`>
 
 ## 1. Depth
 light | full (<trigger that escalated it>)     # every plan is vetted — light or full, never skipped (see depth.md)
@@ -22,6 +22,19 @@ light | full (<trigger that escalated it>)     # every plan is vetted — light
 - Complexity: ok | smell (<n files, m new services) → asked → <reduce|proceed, why>
 - Built-in / completeness / distribution: <flags, with source citations>
 
+## 2a. Build-entry preflight
+| Gate | Command + cwd | Tool/version | Prerequisite owner | Full provenance inputs | Fixture/smoke | Verdict |
+|---|---|---|---|---|---|---|
+| <test/browser/package> | <command · cwd> | <version> | <owner + item> | <tool/manifest/lockfile/config SHA-256> | <what ran> | pass/fail/blocked |
+
+## 2b. Implementation readiness
+| Surface | Requirement/decision | Boundary/wiring | Slice | Proof | Verdict |
+|---|---|---|---|---|---|
+| <journey/data/interface/ops> | <REQ/AC + coverage row> | <contract + key link> | <SLICE-###> | <test-plan row> | ready/gap |
+
+Inventory/currentness: <pass/gaps> · slice order/independence: <pass/gaps> ·
+UX/spec/architecture: <pass/n-a/gaps> · operations/rollout/rollback: <pass/n-a/gaps>
+
 ## 3. Axis findings (floor-gated)
 | Axis | Floor band | Findings (sev · confidence) |
 |---|---|---|
@@ -47,6 +60,7 @@ Sequential — no opportunity   # OR the dependency table + lanes + order + conf
 ## 7. Completion summary
 - Scope: accepted | reduced   · Architecture: <n>   · Code-quality: <n>
 - Coverage: <x/y> planned, <n> gaps, <n> regressions (Critical)
+- Build entry: preflight <pass/fail/blocked>; action-time checkpoints <none/list>
 - Failure modes: <n> mapped, <n> critical gaps
 - NOT in scope: written   · What already exists: written
 - Plan: hardened in place | <n> deltas via Spec Drift Guard
@@ -61,6 +75,14 @@ test and where*, not implementation detail.
 # Test plan: <slug>
 From /rite-vet on <iso>. Runner + conventions: <detected framework + command>.
 
+## Build-entry preflight
+| Gate | Command | Cwd | Expected | Prerequisites | Provenance to recapture |
+|---|---|---|---|---|---|
+| <test/browser/package> | <exact command> | <path> | <exit/output> | <service/browser/credential owner> | <tool version + full SHA-256s> |
+
+Link any disposable parser fixture. Build evidence recomputes every digest; preflight values
+are not post-build proof.
+
 ## Coverage diagram
 <the ASCII code-paths + user-flows diagram from review-axes.md, with COVERAGE / GAPS / REGRESSIONS line>
 
@@ -77,11 +99,8 @@ fails any row with no passing result — an unverified element is a NO-GO, like
 ```markdown
 | Element / flow | Kind (field/checkbox/select/radio/toggle/button/link/flow) | Level | Test file | Asserts (action → expected) |
 |---|---|---|---|---|
-| email field   | field    | unit      | <form.test>  | invalid → error shown; valid → accepted |
-| 'remember me' | checkbox | unit      | <form.test>  | toggles the persisted flag |
-| country       | select   | unit      | <form.test>  | options load; change fires handler |
-| submit        | button   | component | <form.test>  | disabled until valid; click → submits once |
-| login         | flow ★★★ | E2E       | <login.e2e>  | enter → submit → lands on dashboard |
+| email field | field | unit | <form.test> | invalid → error; valid → accepted |
+| login | flow ★★★ | E2E | <login.e2e> | submit → dashboard |
 ```
 Omit the whole section only for a slice with **no** interactive surface (pure backend/logic).
 
@@ -114,6 +133,9 @@ acceptance/behavior changes route through the **Spec Drift Guard**.
   - `tasks.md` slices ← added test requirements (point at `test-plan.md`), added error-handling /
     failure-mode coverage, tightened slice scope, a split of a refactor+behavior slice into two.
     Adjust a slice's `Gate:` upward when vet reveals higher stakes (e.g. an unflagged migration).
+    For an eligible architecture competition, set the canonical `Forge`, `Forge strategies`,
+    and `Forge scorecard` fields only after the acceptance→test map is final; otherwise keep
+    `no` / `none` / `none`.
   - Re-run the `plan.md` Readiness gate after edits; it must still pass.
 - **Route through the Spec Drift Guard** (record `drift.md` + a recorded decision, then `/rite-plan
   repair` for any structural reslice) for anything that **changes an acceptance criterion, product
@@ -133,3 +155,14 @@ acceptance/behavior changes route through the **Spec Drift Guard**.
   `/rite-build` (the slice-wright) and `/rite-prove` **read `test-plan.md`** as the coverage
   target; `/rite-review` and `/rite-seal` may consult `eng-review.md` for the failure-mode +
   scope record.
+- Write `test-plan.md` and finish all fold-back edits and rechecks first. If this pass changed
+  `brief.md`, `spec.md`, `decisions.md`, `assumptions.md`, or `questions.md`, revalidate the
+  affected decision-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 hide it with a new digest. Once re-closed, run
+  `devrites-engine readiness-digest coverage <slug>` and replace the complete
+  `Coverage inputs SHA-256` line in `decision-coverage.md`. Only then run
+  `devrites-engine readiness-digest engineering <slug>` and copy its complete
+  field line into `eng-review.md`. The build gate rejects a stale digest,
+  placeholders, non-passing preflight/readiness rows, empty tables, or an
+  acceptance criterion with no test mapping.

package/pack/.claude/skills/rite-vet/reference/review-axes.md

@@ -1,57 +1,53 @@
-# The vet review: scope challenge, four axes, required outputs
+# Vet review: scope, four axes, and outputs
 
-The body of `/rite-vet`. Run §0 first as a blocking gate, then the four axes one at a time,
-then the required outputs. Apply the senior-engineer lenses in [`eng-lenses.md`](eng-lenses.md)
-throughout. They're how you *see* the findings, not a separate checklist. Every finding is
-calibrated and gated (see "Confidence + verification gate" below) before it reaches the human.
+Run §0 first as a blocking gate, then review the four axes in order and produce the
+required outputs. Apply the engineering lenses in [`eng-lenses.md`](eng-lenses.md)
+throughout rather than as a separate checklist. Calibrate every finding through the
+confidence and verification gate before presenting it.
 
 ---
 
-## §0. Scope Challenge (blocking gate: runs before any axis)
+## §0. Scope challenge (blocking gate)
 
-Before reviewing *how* the plan builds, challenge *whether it should build this much*. This is
-implementation-scope discipline (the spec's ambition is settled, that was `/rite-temper`).
+Before reviewing implementation details, check whether the plan includes more work than
+the settled spec requires.
 
 1. **What already exists?** For each sub-problem in the plan, find the existing code/flow that
    already solves it (use a code-intelligence index if available: see `../../devrites-lib/reference/standards/tooling.md`).
    Can the plan **capture outputs from an existing
    flow** instead of building a parallel one? Reuse → extend → build new, in that order
    (`coding-style.md`). List every reuse opportunity the plan misses.
-2. **Minimum diff.** What's the smallest set of changes that meets the spec's *acceptance
-   criteria*? Flag any planned work that can be deferred without blocking acceptance. Be ruthless
-   about implementation scope creep, but never cut an acceptance criterion (that's a Drift Guard
-   matter, not a trim).
+2. **Minimum diff.** Find the smallest set of changes that meets the spec's acceptance
+   criteria. Flag work that can be deferred without blocking acceptance. Do not cut an
+   acceptance criterion; that requires the Drift Guard.
 3. **Complexity smell.** If `plan.md` touches **>8 files** or adds **>2 new services / modules /
    classes**, treat it as a smell. Check the plan's complexity gate justifies it. If it doesn't
-   → **STOP**: name what's overbuilt, propose a smaller version that meets acceptance, and ask
-   via `AskUserQuestion` whether to reduce or proceed. Do not start the axes until answered.
+   → harden to the smallest acceptance-preserving plan. Ask only if reduction changes
+   acceptance or explicit architecture policy; never start the axes unresolved.
 4. **Built-in check.** For each new pattern / infra component / concurrency approach the plan
    introduces, verify a framework/runtime built-in doesn't already do it, and that the choice is
    current best practice with no known footgun: dispatch `devrites-source-driven` to confirm at
    the source and record the citation. A custom roll where a built-in exists is a scope-reduction
    finding.
-5. **Completeness check.** Is the plan doing the complete version or a shortcut? With AI-assisted
-   coding the cost of completeness (full edge-case handling, complete error paths, real test
-   coverage) is a fraction of what it was: a shortcut that saves human-hours but only saves
-   minutes here is a false economy. Prefer the complete option; flag shortcuts that exist only to
-   save effort that AI has already made cheap.
+5. **Completeness check.** Identify shortcuts in edge-case handling, error paths, and
+   test coverage. Prefer the complete option when AI-assisted implementation makes the
+   additional work small. Flag shortcuts that save little time but leave known gaps.
 6. **Distribution check.** If the plan introduces a new artifact (CLI binary, package, container,
    deployable), does it include how it gets built / published / installed? If distribution is
    deferred, say so explicitly in "NOT in scope": don't let it silently drop.
 
-> **STOP discipline.** If the complexity smell trips, the `AskUserQuestion` is a tool call, not
-> prose. Naming the 80%-solution in chat and continuing is the failure this gate exists to prevent.
+> **STOP discipline.** Fold technical reduction into the plan; ask and stop only for a
+> human-owned choice.
 
 If the smell does not trip, present the §0 findings and proceed to Axis 1.
 
 ---
 
-## The four axes (one at a time, ≤8 findings each)
+## Four axes (one at a time, at most 8 findings each)
 
-For each axis: evaluate, then **walk each finding WITH the human** via `AskUserQuestion` (one
-issue per call: see "How to ask" below). HITL pauses on each material finding; AFK auto-applies
-within the gate ceiling (`depth.md`). If an axis genuinely has no issue, say "No issues,
-moving on" and continue: don't manufacture findings.
+For each axis, fold verified technical findings into the plan, then walk each human-owned
+decision via one coherent `AskUserQuestion` packet. Supporting findings may combine only
+with one owner/trade-off. HITL pauses there; AFK follows `depth.md`. Never invent findings.
 
 ### 1. Architecture
 - Component boundaries, coupling, data-flow patterns, single points of failure. Architecture records invariants, not scaffolding: each medium+ decision should state `Binds:` and `Prevents:` so the builder knows what divergence it prevents.
@@ -72,7 +68,7 @@ moving on" and continue: don't manufacture findings.
   change will make stale.
 
 ### 3. Test-coverage design
-The differentiator: design the tests *before* the code, so the build writes them alongside.
+Design tests before code so the build writes them alongside the implementation.
 - **Framework detection:** find the project's existing test runner + conventions; match them
   (never introduce a new runner to prove one change: `testing.md`).
 - **Map acceptance → tests.** Every spec acceptance criterion must map to ≥1 planned, surface-anchored test (the API response/UI state/CLI output the criterion names, not an internal proxy).
@@ -117,22 +113,21 @@ acceptance criteria covered ✓" and continue.
 
 ---
 
-## Confidence + verification gate (applies to every finding, all axes)
+## Confidence and verification gate
 Tag each finding `[severity] (confidence: N/10) <plan/task/spec ref> — finding`:
 - **9-10** verified against a quoted line · **7-8** strong pattern match → report normally.
 - **5-6** moderate → report with "verify this is real".
 - **≤4** speculative → **suppress from the walk-through**, appendix only.
 
-**The gate:** before raising a finding, quote the line(s) that motivate it. Can't quote it →
-force confidence ≤4 and suppress. This kills the "the plan doesn't handle X" finding when the
-plan *does* and you skimmed. Don't fabricate 7+ to dodge it. (Same discipline the reviewer agent
-runs: `devrites-plan-reviewer`.)
+Before raising a finding, quote the lines that support it. If no line supports it, set
+confidence to 4 or lower and suppress it. Do not inflate confidence to avoid suppression.
+`devrites-plan-reviewer` follows the same rule.
 
 ---
 
-## How to ask (the interactive walk)
+## Present human-owned decisions
 Use `AskUserQuestion` per the pack's standard. Plan-review specifics:
-- **One finding = one call.** Never batch findings into one question.
+- **One decision = one call.** Never ask about agent work or batch unrelated choices.
 - Concrete: name the plan/task section + the quoted line.
 - 2-3 options, including "do nothing / proceed as-is" where reasonable.
 - Per option, one line: **effort** (human ~X / with the build agent ~Y), **risk**, **maintenance**.
@@ -144,8 +139,10 @@ Use `AskUserQuestion` per the pack's standard. Plan-review specifics:
   happy-path), add `Completeness: N/10` per option. If they differ in *kind* (two different
   architectures), skip the score and note "options differ in kind, not coverage". Never fabricate
   a score on a kind question.
-- Every material finding ends as a **recorded decision**: a resolved `questions.md` qid for HITL
-  or a `decisions.md` ADR for AFK. The walk must leave an auditable trail, not just chat.
+- Every material call ends as a **recorded decision**: behavior-preserving technical hardening
+  goes to `decisions.md`; a human-owned HITL choice gets a resolved `questions.md` qid; AFK
+  records the allowed recommendation in `decisions.md`. The review must leave an auditable
+  trail without turning agent work into questions.
 
 ---
 
@@ -164,4 +161,9 @@ Use `AskUserQuestion` per the pack's standard. Plan-review specifics:
    parallel lanes (shared module → same lane/sequential; independent → separate lanes), execution
    order, and conflict flags where two lanes touch the same module dir. This feeds `/rite-build`'s
    isolation strategy and the autocomplete loop. (Shape in [`artifacts.md`](artifacts.md).)
-5. **Completion summary:** the one-glance recap (shape in [`artifacts.md`](artifacts.md)).
+5. **Build-entry preflight:** commands/cwds, tools, package state, parser/browser smoke,
+   prerequisites, and provenance ([`artifacts.md`](artifacts.md)).
+6. **Implementation readiness:** goal-backward coverage, wiring, dependency simulation,
+   alignment, operations, and rollback verdict.
+7. **Completion summary:** the compact recap defined in
+   [`artifacts.md`](artifacts.md).