devrites 2.6.1 → 3.0.1

package/pack/generated/codex/skills/rite-vet/reference/anti-patterns.md

@@ -0,0 +1,29 @@
+# $rite-vet — anti-patterns
+
+Universal rationalizations + red flags live in
+[`../../devrites-lib/reference/standards/anti-patterns.md`](../../devrites-lib/reference/standards/anti-patterns.md) — read it when the
+reluctance is broader than this phase. Below are the vet-specific ones.
+
+## Phase rationalizations
+
+| Excuse | Rebuttal |
+|---|---|
+| "I'll write all the findings into `eng-review.md` and let the user read it." | The artifact is the *output* of an interactive review, not a substitute for it. A material finding's path to "done" goes **through `AskUserQuestion`**, one at a time, with a recommendation + why. Dumping findings into one write and moving on is the exact failure this skill exists to prevent. |
+| "The plan doesn't handle X — flag it." (without checking) | Quote the line first. If you can't quote where the plan handles X, you also can't be sure it doesn't — force confidence ≤4 and suppress. The "field/case doesn't exist" finding is the most common false positive; the verification gate exists to kill it. |
+| "It's an obvious fix — I'll just edit the plan." | An obvious *plan refinement* (a test requirement, an error path, tighter scope) you write directly — that's vet's job. A fix that **changes an acceptance criterion or product behavior** is not obvious enough to skip the human: route it through the Spec Drift Guard with a recorded decision. |
+| "This dimension is thin but the others are strong — net it's fine." | The gate is the **floor**, not the average. A plan `broken` on test-coverage does not pass because it's `strong` on architecture. |
+| "I can see it's adequate — I'll note the band, the evidence is obvious." | Cite the quoted evidence **before** the band. Score-first-justify-later is how a reviewer waves through a plan it already likes. |
+| "8+ files but it all needs to change — proceed." | The complexity smell is a **STOP-and-ask**, not a note. Name the overbuilt part, propose the smaller version that still meets acceptance, and let the human decide before any axis runs. Maybe it's justified — record *why* — but the gate fires first. |
+| "There's no test for this, but the user can add one later." | Coverage is designed **now**, before the code, so the build writes tests alongside it. A deferred test is a test that misses the boundary cases writing-it-now would expose. Regressions are non-negotiable — Critical, no question. |
+| "Performance looks fine." | "Looks fine" is not a measurement. A perf finding is "measure X against budget Y" or it's nothing — don't recommend speculative tuning, and don't wave past an N+1 you can quote. |
+| "Cross-model agrees, so apply it." | Cross-model consensus is a strong *signal*, not an approval. Every cross-model finding is informational until the human approves it (or, in AFK, until the gate ceiling clears a hardening-only change). |
+
+## Red flags
+- `eng-review.md` / `test-plan.md` written but `plan.md` / `tasks.md` **not** hardened — the build
+  follows the plan, so the review changed nothing.
+- A finding raised with confidence ≥7 but **no quoted source line** — that defeats the verification gate.
+- A scope-growing finding auto-applied in AFK (it must pause), or any irreversible-risk touch that didn't pause.
+- A failure-mode table with rows but no verdict column filled — a "no test + no handling + silent" row not marked Critical.
+- The reviewer loop running past 3 iterations, or the reviewer / cross-model being handed the author's reasoning (defeats the fresh-context point).
+- The skill writing code, implementing a slice, or running the build — that's `$rite-build`. Vet reviews and hardens the plan; it never implements.
+- Re-litigating the **spec's** scope/ambition — that was `$rite-temper`. Vet challenges *implementation* scope only.

package/pack/generated/codex/skills/rite-vet/reference/artifacts.md

@@ -0,0 +1,135 @@
+# `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 actually 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` — the record
+Write to `.devrites/work/<slug>/eng-review.md`. If one exists for the slug, **update** it, don't
+clobber.
+
+```markdown
+# Eng review: <slug>
+Vetted: <iso>   Cross-model: ran (codex) | off
+
+## 1. Depth
+light | full (<trigger that escalated it>)     # every plan is vetted — light or full, never skipped (see depth.md)
+
+## 2. Scope challenge
+- What already exists (reuse vs rebuild): <findings — each reuse the plan should adopt>
+- Minimum diff: scope accepted as-is | trimmed <n items, listed in NOT-in-scope>
+- Complexity: ok | smell (<n files, m new services) → asked → <reduce|proceed, why>
+- Built-in / completeness / distribution: <flags, with source citations>
+
+## 3. Axis findings (floor-gated)
+| Axis | Floor band | Findings (sev · confidence) |
+|---|---|---|
+| Architecture | strong/adequate/thin/broken | [Critical](9) … |
+| Plan code-quality | … | … |
+| Test-coverage design | … | see test-plan.md |
+| Performance | … | … |
+Suppressed (confidence ≤4, unverified): <count — one line each>
+
+## 4. Failure modes
+| New codepath | Realistic failure | Test? | Handling? | Silent? | Verdict |
+|---|---|---|---|---|---|
+| <path> | timeout / nil / race / stale | y/n | y/n | y/n | ok / **CRITICAL gap** |
+
+## 5. Parallelization
+Sequential — no opportunity   # OR the dependency table + lanes + order + conflict flags
+
+## 6. Reviewer loop
+- iter 1: <findings → resolution> · iter 2: … (≤3)
+- Cross-model (if --cross-model): <overlap / unique findings — informational until approved>
+- Final: floor = <band>; unresolved → <none | blocking qid>
+
+## 7. Completion summary
+- Scope: accepted | reduced   · Architecture: <n>   · Code-quality: <n>
+- Coverage: <x/y> planned, <n> gaps, <n> regressions (Critical)
+- 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
+```
+
+## `test-plan.md` — the build-readable coverage target
+Write to `.devrites/work/<slug>/test-plan.md`. `$rite-build` (the slice-wright) reads it to write
+tests alongside the code; `$rite-prove` walks it against `evidence.md`. Keep it about *what to
+test and where*, not implementation detail.
+
+```markdown
+# Test plan: <slug>
+From $rite-vet on <iso>. Runner + conventions: <detected framework + command>.
+
+## Coverage diagram
+<the ASCII code-paths + user-flows diagram from review-axes.md, with COVERAGE / GAPS / REGRESSIONS line>
+
+## Per-gap test requirements
+| ID | Path / flow | Test file (match conventions) | Asserts (input → expected) | Kind | Slice | Priority |
+|---|---|---|---|---|---|---|
+| T1 | <path> | <path/to.test> | <empty list → 200 + []> | unit / E2E / eval | <slice> | P1 / **Regression-Critical** |
+
+## Interaction inventory (UI slices — every element + flow gets an asserting test)
+Enumerate every interactive element and user flow the feature exposes; one row each, none
+skipped. Level per `testing.md` "Completeness": elements/fields → unit/component, critical
+journeys → one E2E (never one-per-field). `$rite-build` must cover every row; `$rite-prove`
+fails any row with no passing result — an unverified element is a NO-GO, like an unproven criterion.
+```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 |
+```
+Omit the whole section only for a slice with **no** interactive surface (pure backend/logic).
+
+## Acceptance → test map
+- <spec acceptance criterion> → <T1, T3>   # every criterion maps to ≥1 test
+```
+
+## Parallelization table (in `eng-review.md` §5 when there's an opportunity)
+```markdown
+| Step / workstream | Modules touched (dir-level) | Depends on |
+|---|---|---|
+| API endpoints | controllers/, serializers/ | — |
+| Worker | jobs/, lib/queue/ | API endpoints |
+
+Lanes:  A: API → Worker (sequential, shared lib/)   ·   B: migration (independent)
+Order:  launch A + B in parallel worktrees → merge → C
+Conflicts: Lanes A and B both touch models/ — sequential or coordinate.
+```
+
+## Fold-back — the part the build follows
+Vet *is* the plan-hardening phase, so behavior-preserving refinements are written **directly**;
+acceptance/behavior changes route through the **Spec Drift Guard**.
+
+- **Write directly into `plan.md` / `tasks.md`** (single canonical writer — you, not the reviewer):
+  - `plan.md` §Scope boundaries ← "NOT in scope" items.
+  - `plan.md` §Architecture decisions ← reuse-over-rebuild calls + named failure scenarios.
+  - `plan.md` §Dependency graph / §Implementation order ← the parallel lanes + any ordering fix
+    (e.g. refactor-before-feature split).
+  - `plan.md` §Complexity & deviations gate ← any deviation the §0 challenge surfaced + its justification.
+  - `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).
+  - 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
+  behavior, or the spec** — including a scope reduction that drops a criterion. A folded change with
+  no recorded decision is the batch-dump failure.
+- **`decisions.md`** — one ADR per material call: `context · decision · why-not-the-alternative ·
+  what-would-change-it`.
+- **`assumptions.md`** — every "we'll probably need X" demoted to an explicit assumption-to-verify,
+  never smuggled into scope as a fact.
+
+## Write discipline
+- **Single canonical writer.** The skill writes `eng-review.md` / `test-plan.md` and edits
+  `plan.md` / `tasks.md`; `devrites-plan-reviewer` is **read-only** and only returns findings + bands.
+- **No silent scope.** A plan refinement that grows acceptance without a recorded decision, or a
+  deferral that drops a criterion without the Guard, is a defect — not a convenience.
+- Add `eng-review.md` + `test-plan.md` to the workspace between `tasks.md` and `state.md`.
+  `$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.

package/pack/generated/codex/skills/rite-vet/reference/cross-model.md

@@ -0,0 +1,43 @@
+# `--cross-model` — the outside voice (a genuinely different model)
+
+`devrites-plan-reviewer` gives an *independent* read (fresh context, no authoring reasoning) —
+but it's still the same model family. `--cross-model` adds a second opinion from a **different**
+AI system, because two models agreeing on a plan is stronger signal than one model reviewing it
+thoroughly. It is **opt-in** for `$rite-vet` (the flag) and **off by default in
+`$rite-autocomplete`** unless the flag was armed — it costs latency and a second runtime.
+
+## When it runs
+Only when `$ARGUMENTS` contains `--cross-model` **and** a different-model reviewer is available.
+First run `devrites-engine reviewers list`; configured aliases there are preferred over ad-hoc
+model choices. The default path (no flag) relies on `devrites-plan-reviewer` for independence —
+that is a complete review on its own; cross-model is an enhancement, not a requirement.
+
+## Dispatch
+After the in-model reviewer loop converges (or in parallel with its final iteration), hand the
+**same fresh inputs** to a different model — preferentially a configured `codex` reviewer alias,
+then the `codex:codex-rescue` agent if no alias exists. Give it only the contract, never the
+authoring reasoning:
+
+> Independent engineering review of a defined implementation plan, before any code.
+> Read only `.devrites/work/<slug>/plan.md`, `tasks.md`, and `spec.md`. Judge: architecture &
+> boundaries, scope discipline & reuse, test-coverage design, performance, reversibility, and
+> failure-mode coverage. For every finding, quote the line that motivates it and give a 1-10
+> confidence; suppress anything you can't quote. Return labeled findings (Critical / Important /
+> Suggestion) with a concrete fix. Do not edit anything. Do not approve — find what will cost a redo.
+
+If the agent / runtime is unavailable, **skip and say so** in `eng-review.md` ("cross-model:
+requested but unavailable — in-model review only"); do not block on it and do not silently treat
+the absence as a pass.
+
+## Integration rule (the important one)
+Cross-model findings are **informational until the human approves each one** — even when you
+agree with them, even when they overlap the in-model reviewer. Cross-model **consensus** is a
+strong signal: surface it as such ("both reviewers flagged SLICE-003's missing timeout test"), but
+the human still makes the call via `AskUserQuestion`. In AFK, the same gate ceiling applies:
+a cross-model finding that *hardens* the plan auto-applies and is recorded; one that *grows
+scope* or changes acceptance is a blocking pause.
+
+## Recording
+In `eng-review.md` §6, note: which model ran, the overlap with the in-model reviewer (consensus
+findings), and any **unique** findings the outside voice caught that the in-model pass missed —
+those are the highest-value output of running it at all.

package/pack/generated/codex/skills/rite-vet/reference/depth.md

@@ -0,0 +1,53 @@
+# Depth calibration — always vet, scale the rigor (never skip)
+
+`$rite-vet` runs on **every** plan — every feature deserves a correct engineering plan, not
+just the big ones. What changes with stakes is the *depth*, never *whether* it runs: a simple,
+reversible plan gets a fast **light pass**; a big or risky one gets the **full pass**. There is
+no skip. This shared definition is used by both the standalone `$rite-vet` and the always-run
+`$rite-autocomplete` step, so they agree on how deep to go.
+
+A four-section deep-dive on a one-file reversible plan is wasteful; rubber-stamping a
+migration-touching plan is dangerous. Match the effort to the stakes — but **always** leave a
+recorded engineering verdict and a coverage plan.
+
+## Full pass when ANY trips
+- **Irreversible-risk contact** — the plan touches anything on the `afk-hitl.md` irreversible-risk
+  list: destructive data migration, auth/authz boundary, public-API break, external-service
+  contract, filesystem destruction outside the workspace.
+- **Data model** — new/changed entities, relationships, or persistence shape.
+- **Cross-module blast radius** — the impact (from a code-intelligence index if available — see
+  `../../devrites-lib/reference/standards/tooling.md` — or an honest estimate) crosses
+  module/service boundaries or has many dependents.
+- **Complexity** — `plan.md` touches **>8 files** or adds **>2 new services/modules/classes**.
+- **Multi-slice / multi-day**, or a new dependency / pattern / second design system.
+- **The user asked**, or `--full`.
+
+Full pass = §0 scope challenge + all four axes (each walked finding-by-finding) + the failure-mode
+table + parallelization + the reviewer loop. See [`review-axes.md`](review-axes.md).
+
+## Light pass otherwise (the default for simple plans — still never a skip)
+When none of the full-pass triggers fire, run the **light pass**: a fast but real engineering
+check that still leaves a verdict and a coverage plan. In a handful of lines:
+- **§0 scope challenge, in brief** — confirm minimum diff + reuse (one line each); if a complexity
+  smell or missed reuse appears, escalate that to the full treatment.
+- **One-line scan per axis** (architecture / plan code-quality / test-coverage / performance) —
+  "No issues" is a valid result, but you must look and say so per axis, not assume.
+- **Always** produce the acceptance→test map + any regression-Criticals in `test-plan.md`. This is
+  the part that makes "a correct engineering plan for *everything*" real — it never downgrades,
+  light or full.
+- Write the short `eng-review.md` (`Depth: light`) and harden `tasks.md` with the test requirements.
+
+A light-pass finding that turns out to be real **escalates that axis to full treatment** (walk it
+with the human, confidence-banded). Light means *less ceremony*, never *less honesty*.
+
+## In `$rite-autocomplete`
+Autocomplete runs `$rite-vet` after `$rite-define` on **every** feature — light or full per the
+triggers above, **never skipped**. Under the AFK gate ceiling:
+- **Auto-apply (no pause):** hardening findings — added test requirements, error-handling /
+  failure-mode coverage, tightened scope, reuse-over-rebuild, dependency-order / parallel-lane fixes
+  (these never grow acceptance). Record the rationale in `decisions.md`.
+- **Blocking pause:** any finding that **grows scope, adds a slice, changes an acceptance
+  criterion, or alters product behavior**.
+- **Always pause:** irreversible-risk findings, and any axis still below bar after the
+  ≤3-iteration reviewer loop.
+- **Cross-model** is off by default; it runs only if `--cross-model` was explicitly armed.

package/pack/generated/codex/skills/rite-vet/reference/eng-lenses.md

@@ -0,0 +1,48 @@
+# Senior-engineer lenses — how to *see* the findings
+
+These are not extra checklist items. They are the instincts an experienced staff engineer
+applies while reading a plan — the pattern recognition that separates "read the plan" from
+"caught the landmine". Apply them across all four axes in [`review-axes.md`](review-axes.md):
+each lens turns a vague unease into a concrete, quotable finding.
+
+## The lenses
+
+1. **Boring by default.** A team gets a few innovation tokens; everything else should be proven
+   technology. When the plan introduces something novel (a new datastore, a hand-rolled queue, a
+   bespoke pattern), ask whether this is a wise token to spend or whether a boring built-in does
+   it. → Architecture / Scope axes.
+2. **Blast radius.** For every decision: what's the worst case, and how many systems / callers /
+   users does it touch? A change with wide blast radius and no rollback is a different risk class
+   than a leaf change. → Architecture / Reversibility.
+3. **Reversibility preference.** Prefer the choice that's cheap to undo — feature flag, additive
+   migration, incremental rollout — over the one that's right only if you're right the first time.
+   Make the cost of being wrong low. → Architecture / Reversibility.
+4. **Incremental over revolutionary.** Strangler-fig, not big-bang rewrite; refactor first, then
+   change behavior — never both in one slice. If the plan does a structural rewrite and a behavior
+   change together, split them. → Plan code-quality / slice shape.
+5. **Systems over heroes.** Design for a tired engineer at 3am, not your sharpest engineer on
+   their best day. A plan that only works if every step is done perfectly is fragile. Favor
+   guard rails, explicit errors, and obvious failure paths. → Code-quality / Failure modes.
+6. **Essential vs accidental complexity.** Before anything the plan adds, ask Brooks's question:
+   is this solving a real problem, or one we created? Accidental complexity is the cheapest thing
+   to cut. → Scope / Code-quality.
+7. **Make the change easy, then make the easy change.** If a slice is hard because the surrounding
+   structure fights it, the first move is a (separate, behavior-preserving) refactor — call it out
+   so the plan sequences it before the feature work, not tangled into it. → Plan code-quality.
+8. **Failure is information.** Every new codepath fails *somehow* in production — timeout, nil,
+   race, stale data, partial write. The plan should name the failure and decide: test it, handle
+   it, or accept it loudly (never silently). → Failure-mode coverage.
+9. **DX is product quality.** Slow CI, painful local dev, untestable seams → worse software over
+   time. If the plan makes the code harder to test or run locally, that's a real finding, not a nit.
+   → Test-coverage / Code-quality.
+10. **Trust boundary discipline.** Every untrusted input crosses an explicit validation + authz
+    boundary before it reaches trusted core logic. A plan that lets a value skip the boundary is a
+    security finding even pre-code. → Architecture / Security seam.
+
+## Using them
+- A lens is a *prompt*, not a verdict. It turns "something's off here" into a finding you can
+  quote and band. If a lens fires, follow it to the specific plan line, then run it through the
+  confidence + verification gate.
+- Don't recite the lenses in the output — recite the *findings* they produced.
+- When a plan is genuinely clean against a lens, that's worth one line of evidence ("Reversibility:
+  additive migration + flag — strong"), not silence; it shows the lens was applied.

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

@@ -0,0 +1,167 @@
+# The vet review — scope challenge, four axes, required 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.
+
+---
+
+## §0. Scope Challenge (blocking gate — runs before any axis)
+
+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`).
+
+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).
+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.
+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.
+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.
+
+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)
+
+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.
+
+### 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.
+- Scaling characteristics; where the plan's approach breaks under real load.
+- Security architecture at the seams (auth, data access, API boundaries) — does the plan name
+  the trust boundary for each untrusted input?
+- For each new codepath / integration point: **one realistic production failure scenario** and
+  whether the plan accounts for it (feeds the failure-mode table).
+- Does any key flow deserve an ASCII diagram in the plan or an inline comment in the code the
+  build will write? Name the files that should carry one.
+
+### 2. Plan code-quality
+- Module structure the plan implies; DRY across the slices (flag planned repetition aggressively).
+- Error-handling + edge cases the plan names — and the ones it doesn't (call those out explicitly).
+- Over-engineering (premature abstraction, an extension point with no second caller) vs
+  under-engineering (fragile / hacky) relative to `patterns.md` + `coding-style.md`.
+- Tech-debt hotspots the plan walks into; existing inline diagrams in touched files that the
+  change will make stale.
+
+### 3. Test-coverage design
+The differentiator: design the tests *before* the code, so the build writes them alongside.
+- **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).
+- **Tool per path** — unit (pure logic, single function, edge cases), integration/E2E (a user
+  flow spanning 3+ components, an auth/payment/data-loss path, a mock-hides-failure boundary),
+  eval (an LLM/prompt change that needs a quality bar).
+- **Interaction inventory (UI slices) — enumerate every interactive element + flow.** List each
+  input field, checkbox, radio, select, toggle, button, and actionable link, plus each user
+  flow; assign each ≥1 asserting test **at the right level** — elements/fields → unit/component,
+  critical journeys → one E2E (never one-per-field). Every element/flow with no asserting test
+  is a GAP; no element ships unverified. Write the inventory to `test-plan.md` (table in
+  `artifacts.md`). This is `testing.md` "Completeness" made concrete for the plan.
+- **Regression rule (mandatory, no question):** when the plan modifies existing behavior and the
+  current suite doesn't cover the changed path, a regression test is added to the plan as a
+  **Critical** requirement — no `AskUserQuestion`, no skipping. Regressions are the highest-priority
+  test because they prove something broke. When unsure whether a change is a regression, write the test.
+- Produce the **coverage diagram** (shape below) and add a specific test requirement per GAP.
+
+#### Coverage diagram (write to `test-plan.md`)
+Both code paths and user flows in one view; mark E2E-worthy `[→E2E]` and eval-worthy `[→EVAL]`:
+
+```
+CODE PATHS                                          USER FLOWS
+[+] services/billing                                [+] Checkout
+  ├── processPayment()                                ├── [★★★ planned] complete purchase — checkout.e2e
+  │   ├── [★★★ planned] happy + declined + timeout    ├── [GAP] [→E2E] double-click submit
+  │   └── [GAP]         invalid currency              └── [GAP]        navigate away mid-payment
+  └── refundPayment()                               [+] Error states
+      └── [★  planned] full refund only               └── [GAP]        network-timeout UX
+
+COVERAGE: 4/9 planned (44%)  |  GAPS: 5 (2 E2E)  |  REGRESSIONS: 1 (Critical)
+```
+Legend: ★★★ behavior+edge+error · ★★ happy path · ★ smoke · [→E2E] integration · [→EVAL] LLM eval.
+**Fast path:** every acceptance criterion already maps to a planned test → "Test coverage: all
+acceptance criteria covered ✓" and continue.
+
+### 4. Performance
+- N+1 / unbounded queries and DB access patterns; memory concerns; caching opportunities;
+  high-complexity hot paths.
+- Per `performance.md`: name a number to measure or a budget — don't recommend speculative
+  micro-tuning. A perf finding is "measure X against budget Y", not "this feels slow".
+
+---
+
+## Confidence + verification gate (applies to every finding, all axes)
+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`.)
+
+---
+
+## How to ask (the interactive walk)
+Use `AskUserQuestion` per the pack's standard. Plan-review specifics:
+- **One finding = one call.** Never batch findings into one question.
+- 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**.
+  If the complete option is only marginally more effort than the shortcut (AI makes it cheap),
+  recommend complete.
+- **Map to a rule.** One sentence tying the recommendation to a DevRites rule (reuse-first,
+  fail-fast, test-behavior, measure-first, minimum diff).
+- **Coverage vs kind:** if the options differ in *coverage* (more tests vs fewer, complete vs
+  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 (HITL) or
+  a `decisions.md` ADR (AFK) — so the walk leaves an auditable trail, not just chat.
+
+---
+
+## Required outputs (after the axes)
+1. **"NOT in scope"** — work considered and explicitly deferred, one-line rationale each. Folds
+   into `plan.md` §Scope boundaries + `spec.md` Non-goals (via the Guard) so it can't silently re-enter.
+2. **"What already exists"** — existing code/flows that solve sub-problems, and whether the plan
+   reuses or rebuilds them. Every missed reuse becomes a §0 finding.
+3. **Failure-mode table** — for each new codepath: a realistic failure, and whether (a) a test
+   covers it, (b) error handling exists, (c) the user sees a clear error or a silent failure. A
+   failure with **no test AND no handling AND silent** is a **Critical gap**. (Shape in
+   [`artifacts.md`](artifacts.md).)
+4. **Worktree parallelization strategy** — analyze the slices for parallel execution. **Skip** if
+   all slices touch the same module or there are <2 independent workstreams ("Sequential, no
+   parallelization opportunity"). Otherwise: a dependency table (module-level, not file-level),
+   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)).

package/pack/generated/codex/skills/rite-zoom-out/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: rite-zoom-out
+description: User-invoked read-only structural map of unfamiliar code: modules, callers, callees, and relevant decisions.
+argument-hint: "[symbol | file | area to map]"
+user-invocable: true
+disable-model-invocation: true
+---
+
+## Codex compatibility
+
+This is the Codex mirror of a DevRites skill. In Codex:
+
+- Load DevRites engineering standards from `.agents/skills/devrites-lib/reference/standards/`. Read `.agents/skills/devrites-lib/reference/standards/core.md` before workflow work, then load the other `.agents/skills/devrites-lib/reference/standards/*.md` files exactly when this skill asks for them.
+- Use the installed `devrites-engine` binary as the canonical runtime helper surface for orientation, gates, and state mutation.
+- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here — Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
+- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review** — an inline pass shares the calling context and is weaker evidence.
+- Codex project hooks are installed in `.codex/hooks.json`. Review and trust them with `/hooks` before relying on hook enforcement.
+- When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers — NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
+
+
+# $rite-zoom-out — step up one abstraction layer
+
+When the agent (or the user) is staring at unfamiliar code without a working mental
+model of how it fits the larger system. Stops the "open more files" reflex by returning
+a single, structured map instead.
+
+Read `.agents/skills/devrites-lib/reference/standards/core.md` first — chiefly its vocabulary / existing-conventions
+disciplines, which keep the map in the project's own language. The other rule files load
+on demand.
+
+## What this skill returns
+
+A **structural map** — terse. One pass should answer:
+
+- **The area** — what this code is for, in one sentence, using the project's own
+  vocabulary.
+- **Modules in scope** — the related files / packages / slices, with a one-line
+  purpose each.
+- **Callers (in)** — who calls into this area from outside. Keep to the highest-signal
+  3–6; collapse the rest.
+- **Calls (out)** — what this area depends on downstream.
+- **Decisions touching it** — ADRs (under `docs/adr/` if present) or notes in
+  `.devrites/work/<slug>/decisions.md` that pre-decide something here.
+- **Smallest sensible change-scope** — where a fix would naturally land, so the next
+  step doesn't drift into a project-wide refactor.
+
+## Prefer a code-intelligence index (if available)
+
+If the project has them — `codebase-memory-mcp` (`get_architecture` / `search_graph`) first,
+cross-checked with `codegraph` (`.codegraph/`) and `graphify` (`graphify-out/`) — use them. For
+codegraph, `codegraph_context` + one `codegraph_explore` return the map in two calls — vastly
+cheaper than a file-walk and more accurate for callers/callees. Fall back to standard methods
+(LSP, then `Grep` + `Read`) when no index is available. See `.agents/skills/devrites-lib/reference/standards/tooling.md`.
+
+## Vocabulary discipline
+
+Use the **project's** domain language — `CONTEXT.md`, glossaries, the active feature's
+`spec.md` / `decisions.md`. Don't invent fresh names for things the project already
+names. If you notice a fuzzy or overloaded term while mapping, flag it as a FYI at the
+end; don't try to fix it here.
+
+## When NOT to use
+
+- You already have a clear mental model — zooming out is just tax.
+- The question is a literal text lookup (a string, a comment, an error message) — use
+  `Grep`.
+- You need to design or change something — that's `$rite-spec` (new feature) or
+  `$rite-define` (plan an approved spec).
+- You want a project-wide architecture audit — use the project's normal architecture
+  review process; this skill is a read-only feature-area map.
+
+## Output shape
+Reply-contract exception: read-only mapping utility. It skips `devrites-engine progress` when
+there is no active workspace, but follows
+[`devrites-lib/reference/reply-contract.md`](../devrites-lib/reference/reply-contract.md).
+
+```
+Done: mapped <area> in the project's vocabulary.
+Changed: workspace only
+Evidence: modules <n>; callers <n>; callees <n>; decisions <n>
+Open: <none | fuzzy term | suspected drift | open question>
+Next: <single recommended command>
+Record: <decision/ADR path | not applicable>
+↻ Hygiene: /clear if this was only orientation; $rite-handoff if it informs active work
+```
+
+Print the path of any decisions/ADR files referenced so the user can open them.

package/pack/generated/codex/skills/rite-zoom-out/agents/openai.yaml

@@ -0,0 +1,2 @@
+policy:
+  allow_implicit_invocation: false

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "devrites",
-  "version": "2.6.1",
+  "version": "3.0.1",
   "description": "DevRites — disciplined senior-engineer workflow skills pack for Claude Code and Codex",
   "license": "SEE LICENSE IN LICENSE",
   "homepage": "https://github.com/ViktorsBaikers/DevRites#readme",
@@ -29,12 +29,12 @@
   },
   "files": [
     "bin/",
+    "engine/",
     "pack/",
     "scripts/",
     "install.sh",
     "uninstall.sh",
     "update.sh",
-    "mcp/",
     "docs/",
     "README.md",
     "LICENSE",
@@ -47,10 +47,14 @@
   },
   "scripts": {
     "prepare": "husky || true",
-    "prepack": "rm -rf scripts/__pycache__ scripts/.cache docs/internal",
+    "prepack": "bash scripts/build-host-artifacts.sh && rm -rf scripts/__pycache__ scripts/.cache docs/internal",
     "commitlint": "commitlint --edit",
     "validate": "bash scripts/validate.sh",
-    "test": "for t in tests/*.sh; do echo \"== $t ==\"; bash \"$t\" || exit 1; done",
+    "test": "node scripts/run-tests.mjs",
+    "test:fast": "node scripts/run-tests.mjs --fast",
+    "test:parallel": "node scripts/run-tests.mjs",
+    "test:serial": "node scripts/run-tests.mjs --serial",
+    "size:baseline": "node scripts/check-instruction-size-baseline.mjs --write",
     "release": "semantic-release",
     "release:dry": "semantic-release --dry-run --no-ci"
   },