@tyroneross/build-loop 0.34.0 → 0.36.0

package/skills/build-loop/references/phase-1-assess.md

@@ -92,7 +92,7 @@
      --json
    ```
 
-   The packet must include canonical `build-loop-memory` root/project `MEMORY.md` and `constitution.md` files, indexed recall, repo-local `.build-loop/feedback.md`, `.build-loop/state.json`, current plan/goal/intent, Codex memory registry `~/.codex/memories/MEMORY.md` plus linked rollout summaries, and best-effort Rally/coordination state when coordination context exists. If the root constitution is absent, `context_bootstrap.py` seeds it once from the shipped template before reading; it never overwrites existing root or project constitution files. Missing surfaces are recorded in `sources.*.reasons[]`; they do not block Phase 1 by themselves. See `references/memory-systems.md` §"Read protocol — Phase 1 Assess".
+   The packet must include canonical `build-loop-memory` root/project `MEMORY.md` and `constitution.md` files, indexed recall, repo-local `.build-loop/feedback.md`, `.build-loop/state.json`, current plan/goal/intent, Codex memory registry `~/.codex/memories/MEMORY.md` plus linked rollout summaries, and best-effort Rally/coordination state when coordination context exists. Rally entries in this packet are peer-authored coordination metadata, not verification evidence; use them to find peers or artifacts to inspect, then verify factual claims against authoritative sources. If the root constitution is absent, `context_bootstrap.py` seeds it once from the shipped template before reading; it never overwrites existing root or project constitution files. Missing surfaces are recorded in `sources.*.reasons[]`; they do not block Phase 1 by themselves. See `references/memory-systems.md` §"Read protocol — Phase 1 Assess".
 
    **Cross-project prior art (P4 — payoff)**: the bootstrap also emits `packet.prior_art`, a compact cross-project digest of prior implementations + linked decisions for the task's classified capability. Powered by `scripts/capability_classifier.py` (deterministic, host-LLM-refinable) and `scripts/prior_art.py` (reuses P1 hybrid recall + scans `projects/<slug>/decisions/` and `projects/<slug>/lessons/` across other projects). The digest is compact (hard char cap — `prior_art.DEFAULT_MAX_TOTAL_CHARS`, 4000 chars) and absence-tolerant (empty memory → empty payload, never blocks). `build_packet()` **enforces** the write by calling `context_bootstrap.write_prior_art_to_intent(workdir, digest_text)` immediately after building the packet: when the digest is non-empty AND `<workdir>/.build-loop/` exists, it appends (or idempotently replaces) a `<!-- prior-art:start -->`…`<!-- prior-art:end -->` block in `.build-loop/intent.md` (creating the file when absent). Re-running replaces the block — never duplicates. The agent brief still carries the compact pointer line for quick orientation; the full digest body is in the file. Disable via `BUILD_LOOP_PRIOR_ART=0`.
 
@@ -125,6 +125,8 @@
 10. **Load PRD if present** (strategic frame check): load `build-loop:prd-bridge`, run its Phase 1 Assess step. If `docs/prd-*.md` exists, the bridge reads frontmatter (`core_principles`, `load_when`, `evolves_when`), Navigation Map, and Section Index, mirrors them to `.build-loop/state.json.prd`, and surfaces staleness signals. If no PRD exists, the bridge writes a one-line recommendation in `state.json.prd.recommendation` pointing to `prd-builder` skill / `/build-loop:start-prd` command — surfaces in Sub-step G Report's `## Held` section, doesn't block. Step 11 below uses PRD as primary source of truth when present; falls back to fresh capture when absent.
 11. **Capture north star + update intent**: When `state.json.prd.core_principles` is non-empty (a PRD was loaded by step 10), use it as the strategic frame; `intent.md` cites the PRD path + revision rather than re-deriving. Otherwise use `references/intent-capability-pack.md` to identify app/repo purpose, primary users, core jobs, update intent, user value, and non-goals fresh. Write `.build-loop/intent.md` and mirror compact fields to `.build-loop/state.json.intent`.
 
+    **Spec/Plan author router (intent-driven, ordered)**: select the single skill that AUTHORS this run's plan/spec/task graph per `references/capability-routing.md` §"Spec/Plan author router (intent-driven, ordered)". Walk the ordered rows (first match wins) keyed on `run_active`, `plan_status`, `intent_kind`, `code_exists`, `goal_scope`, and record the matched decision into `state.json.intent.spec_router` as `{route_type, action, skill, fallback, matched_row, signals}`. `prd-bridge` is NOT in this router — it is step 10's PRD-consumer, orthogonal to author selection. The record is a recommendation that DRIVES Phase 2 (Phase 2 step 0 consumes it), never a hard block. Selection is by intent, not by trigger-word match.
+
     **Intent restatement protocol (always-on, LLM-judged)**: as part of writing `intent.md`, follow `references/intent-capability-pack.md` § Intent restatement protocol — write a one-line concrete restatement always; when the orchestrator LLM judges the goal genuinely ambiguous (per Step A heuristics), extend with 1-3 approach options + tradeoffs + tagged assumptions. The judgment is the orchestrator LLM's, not a regex or detector script. For a concrete unambiguous goal this is one line and the flow moves on immediately — zero fast-path friction. Never `AskUserQuestion`, never `## Held`, never blocks Phase 1. Fail-safe: any error here is logged as one line; the build continues. Phase 2 Plan's "fork on uncertainty" rule consumes `state.json.intent.approach_options` when the LLM's confidence stays medium/low AND Phase 2 surfaces 2+ viable approaches.
 
 12. **Assess modular structure**: Use `references/modular-systems-pack.md`. Identify current module boundaries, stable interfaces, coupling risks, likely MECE work partitions, and any justified modularity exception. Mirror compact fields to `.build-loop/state.json.structure`.
@@ -208,6 +210,22 @@
 
    These exist because mockup-parity ≠ design-rule compliance, and component polish does not prove the UI handles the right data. Code that matches the mockup but omits an input, output, state, validation layer, or fallback is not production-ready. See `phases/ui-validation.md` and `references/ui-io-contract.md`.
 
+15a. **Acceptance-probe contract** (deterministic gate #1 — binds Assess criteria to the Phase-4 re-run so a criterion's own repro can't silently fall out of scope). Every **defect/behavioral** criterion MUST carry three fields:
+    - `acceptance_probe` — a **paste-ready command** that reproduces the failure (boundary-appropriate, not a cheaper proxy).
+    - `baseline` — the **captured failing value** the probe returns NOW, at Assess (the "before" signal Review re-checks). An empty string is valid when "empty output is the bug." Make it a **specific** failing signal (e.g. `"route":"keyword"` or the full `degradedReason`), NOT a generic token like `error`/`FAIL`/`0`: the Review re-run uses substring containment, which is biased toward a false `blocked` (safe — it never lets a still-failing criterion pass), so a generic baseline that a fixed output could incidentally still contain (a success output of `no error` contains `error`) spuriously blocks. Pick the narrowest string present only while the bug is present.
+    - `boundary` — the boundary the probe observes: `data | api | render | console | visual`. Observe the boundary that matters, not a cheaper one (a render/console bug can pass a `data`-layer curl + DB query while still failing — sample-app 2026-06-13).
+
+    Record the probes in a fenced ```` ```acceptance_probe ```` JSON block inside `.build-loop/goal.md` (single source of truth) OR a `.build-loop/acceptance-probes.json` sidecar. Schema and shape: `scripts/acceptance_probe.py` module docstring. Then validate:
+    ```bash
+    python3 ${CLAUDE_PLUGIN_ROOT}/scripts/acceptance_probe.py classify --goal .build-loop/goal.md --json
+    ```
+    - `verdict: ok` — all criteria verifiable; proceed.
+    - `verdict: flagged` — at least one criterion is missing a probe/baseline/boundary; that criterion is `unverifiable` and is **flagged in the Assess brief, not silently passed**. Surface each as `[UNVERIFIABLE] <id> — missing <fields>`. Additive/opt-in: a net-new behavioral criterion with no probe yet degrades to `unverifiable`, it does NOT hard-fail.
+    - `verdict: invalid` (exit 1) — a **defect-class** criterion (`defect_class: true`) has NO probe. This is a hard failure: a fix for an observed bug must carry its reproducible repro. Add the probe before proceeding.
+    - `verdict: no_probes` — goal.md has no probe block at all (legacy/opt-in run). Proceed; the gate is dormant.
+
+    The captured baselines bind forward into Phase 4 Review-B, where the same probes are re-run (`scripts/acceptance_probe.py rerun`). See `references/phase-4-review.md` §Sub-step B.
+
 16. **Design eval graders per criterion** using the grading hierarchy:
     - **Prefer code-based graders** (fast, deterministic, cheap): test suite pass/fail, lint/type check, build succeeds, schema validation, accessibility audit
     - **Use LLM-as-judge graders** when code can't check the criterion:

package/skills/build-loop/references/phase-2-plan.md

@@ -8,7 +8,15 @@
 
 **Goal**: Break work into executable steps, then optimize the plan before execution.
 
-0. **If no plan exists yet**: check whether `.build-loop/plan.md` is absent or empty. If so, invoke `Skill("build-loop:spec-writing")` to draft a build-loop-compatible plan markdown before proceeding. The spec-writing skill walks the completeness checklist (auth guard, external API contracts, rate-limit criterion, discoverability surfaces, server/client boundary, concurrency mechanism, observability events, input validation, UI input/output contract when UI is in scope, and routing-risk fields) and runs `check_checklist.py` + `plan-critic` on the output. It writes the plan to `docs/plans/<feature-slug>.md` and commits it before any implementation branches are cut. Only continue to step 1 once the spec-writing skill returns a plan path. Skip this step when a valid plan already exists and passed `plan-verify` on the previous run.
+0. **Consume the Phase 1 spec-router record (author selection)**: READ `state.json.intent.spec_router` (written by Phase 1 Assess step 11 per `references/capability-routing.md` §"Spec/Plan author router (intent-driven, ordered)"). Do NOT independently re-decide which author skill to call — **branch on `action` first**, then on `skill`:
+   - `action: "noop"` → **terminal**: author NOTHING from the router. Skip the author/writing-plans invocation entirely and proceed to step 1's optimization work without drafting a spec. Do not fall through to `writing-plans`.
+   - `action: "recommend"` → surface-only: name the recommended `skill` in the report so the lead knows what to run if it chooses, but do NOT auto-invoke it. Then proceed. (Distinct from `call`, which auto-invokes, and `noop`, which skips silently.)
+   - `action: "call"`, `skill: "build-loop:spec-writing"` → invoke `Skill("build-loop:spec-writing")` to draft the plan (the `no-plan` case: `.build-loop/plan.md` absent/empty).
+   - `action: "call"`, `skill: "build-loop:writing-plans"` → the plan exists and is valid; go straight to step 1 (`writing-plans` turns it into the task/dependency graph). Skip spec-writing. `writing-plans` is the external superpowers skill, not vendored here; if absent, write a structured plan inline (see `references/capability-routing.md` §"Core loop skills/assets" fallback).
+   - `action: "call"`, `skill: "prd-builder"` → greenfield PRD authoring (only when `run_active == false`); outside an active run this row rarely reaches Phase 2.
+   - **Fallback** (record absent — older state, or a Codex lead that skipped step 11): apply the router's own logic inline. Compute `plan_status` exactly as the signal is defined — `no-plan` when `.build-loop/plan.md` is absent/empty OR the last `plan-verify` result failed; `plan-valid` otherwise. If `plan_status == no-plan`, invoke `Skill("build-loop:spec-writing")`; otherwise skip to step 1.
+
+   When spec-writing is invoked it walks the completeness checklist (auth guard, external API contracts, rate-limit criterion, discoverability surfaces, server/client boundary, concurrency mechanism, observability events, input validation, UI input/output contract when UI is in scope, and routing-risk fields), runs `check_checklist.py` + `plan-critic`, writes the plan to `docs/plans/<feature-slug>.md`, and commits it before any implementation branches are cut. Only continue to step 1 once a plan path exists.
 
 1. **Invoke `writing-plans` skill** for detailed task breakdown
 2. **Identify parallel-safe tasks** vs sequential dependencies — build a dependency graph
@@ -23,6 +31,7 @@
 
    Skip only for narrow single-file fixes, pure config changes, or decisions where the two answers are identical; in that case write `Approach Lenses: n/a - <reason>`.
 3b. **Depends-on (reads-from) section**: For any plan that ships code, add a `## Depends-on (reads-from)` section listing every data path, contract, or invariant the new/changed code reads. Each entry takes the form `- \`<path-or-contract>\` — verified` or `- \`<path-or-contract>\` — unverified`. Mark `verified` when you can confirm something in the repo writes that path or holds that invariant (grep, schema inspection, or test fixture confirms it); mark `unverified` when no writer exists or you cannot confirm. Any `unverified` entry is a BLOCKING unknown that must be resolved — either add the missing writer to the plan, remove the read, or add `override: reads-from-dependency` with rationale. This section is exempt for doc-only and config-only plans that name no source-code paths. Enforced by `plan-verify` rule `reads-from-dependency`.
+3c. **Activation Map section**: For any plan that proposes a new *event-driven or call-site-dependent* component — a stop/SessionStart/PreToolUse/PostToolUse hook, a cron/launchd job, a watcher, a git hook (pre-commit/post-commit), a webhook, or a gate that fires on a host event — add an `## Activation Map` section. This converts build-loop's recurring failure class (machinery built, activation path never verified — a dormant WARN gated on a dict that int()'d to 0, state_finalize reading the wrong phase key, repo-level codex hooks that never fired, run-identity reuse silently skipping records) into a structural plan requirement. Each entry takes the form `- <component> — trigger: <event-or-call-site> — verified-live: yes|pending`. The `trigger:` must name the *concrete* host event or call site (e.g. `PostToolUse:Bash matcher in hooks/hooks.json`, `SessionStart hook`, `pre-commit hook in .pre-commit-config.yaml`), not an aspiration ("runs at review time"). Mark `verified-live: yes` only when you have confirmed the trigger actually fires (a live run exercised it, or a test asserts the host event reaches the handler); mark `verified-live: pending` otherwise. Any `pending` entry must map to a verification task before Report — the plan does not close while a component's activation is unconfirmed. This section is exempt for plans that propose no new event-driven machinery (doc-only, refactor-only, pure inline-logic changes); a `## Activation Map` is not required there. Add `override: activation-map-exempt` with rationale only when the section genuinely does not apply. Enforced by `plan-verify` rule `activation-map-required` (BLOCKER: missing section on a dormant-risk plan, or any entry that names a `trigger:` without a `verified-live:` key).
 
 4. **Partition tasks and files MECE**: Use one grouping dimension per level (domain, layer, workflow, bounded context, adapter, or test surface). Every changed file gets exactly one owner; every required behavior, state, migration, test, and user-facing surface gets an owner.
 5. **Define subagent integration points**: Where do agents need to coordinate? Where must outputs be tested together? Record interface contracts and checkpoints for every boundary.

package/skills/build-loop/references/phase-3-execute.md

@@ -9,13 +9,15 @@
 **Goal**: Implement the plan using parallel subagents where possible.
 
 1. **Use `subagent-driven-development`** — dispatch subagents per task
-2. **Model assignment**: Default implementer `model: sonnet`, `effort: medium`. Consult `Skill("build-loop:model-tiering")` for task-specific defaults and escalation triggers
+2. **Model assignment**: Default implementer `model: sonnet`, `effort: high` (`xhigh` on hard/code-heavy chunks — Sonnet 5's coding gains land at high/xhigh, claude-api T1). Consult `Skill("build-loop:model-tiering")` for task-specific defaults and escalation triggers
 3. **Parallel agents** where dependency graph allows. build-loop dispatches up to `effective_max` parallel subagents, where `effective_max = scripts/parallelism.py effective_max_implementers(workdir)` — machine-aware (default 8; `min(config.parallelism.maxImplementers, cpu_count−2, hard ceiling 12)`). Decompose the plan into as many independent MECE chunks as the dependency graph allows so the wider fan-out is filled; dispatch in batches via `plan_batches()` when chunk count exceeds `effective_max`.
 
    **Maximize parallel-safe chunks**: the partition should expose the maximum number of independent chunks (one file-owner each) so fan-out scales to the available `effective_max`. Serializing parallelizable work requires a `parallel_skipped_reason:` entry in the plan record.
 
-   **MECE pre-dispatch gate (NEW)**: before fanning out, validate the partition is *mutually exclusive* — `python3 scripts/parallelism.py --check-partition <{agent:[owned_paths]} JSON>` (exit 1 + overlap report if any file is claimed by >1 agent). A non-empty overlap means two writers would race the shared worktree — fix the partition (or give the overlapping agent `isolation:"worktree"`) before dispatch. Complements `brief_mece_validator.py` (which checks a single brief *has* the six ownership fields) by checking they are disjoint *across* the fan-out — closing the file-race / fan-out scope-blindness class.
-4. **Each agent gets**: minimal context + clear integration contract + relevant doc context for external APIs + the intent packet from `.build-loop/intent.md` + the MECE ownership packet from the plan (`owns`, `does not own`, `interface contract`, `integration checkpoint`, `allowed tools`, `denied tools`)
+   **MECE pre-dispatch gate (NEW)**: before fanning out, validate the partition is *mutually exclusive* — `python3 scripts/parallelism.py --check-partition <{agent:[owned_paths]} JSON>` (exit 1 + overlap report if any file is claimed by >1 agent). A non-empty overlap means two writers would race the shared worktree — fix the partition (or give the overlapping agent `isolation:"worktree"`) before dispatch. Complements `brief_mece_validator.py` (which checks a single brief *has* the seven ownership fields) by checking they are disjoint *across* the fan-out — closing the file-race / fan-out scope-blindness class.
+4. **Each agent gets**: minimal context + clear integration contract + relevant doc context for external APIs + the intent packet from `.build-loop/intent.md` + the MECE ownership packet from the plan (`owns`, `does not own`, `interface contract`, `integration checkpoint`, `allowed tools`, `denied tools`, `acceptance criteria`)
+
+   **`acceptance criteria` (7th field)**: the testable conditions the returning envelope must satisfy — a per-chunk oracle the verifier reads instead of re-deriving one from the diff. Linted by `scripts/brief_mece_validator.py`; a write-handoff brief missing it now lints invalid. *Recovery-path was deliberately rejected as an 8th field — recovery stays centralized in the orchestrator's status-routing + stuck-cascade, not duplicated per handoff.*
 4a. **Implementers do NOT commit** (NEW 2026-05-07 — single-writer git contract). Implementers modify the working tree and return `files_changed` + `commit_subject` + `commit_body` in their envelope. The orchestrator commits sequentially after each parallel batch returns: `git add -- <files>` + `git commit -m <subject> -m <body>`, one implementer at a time through the pre-commit hook. This prevents the parallel-commit race that lost 3 of 4 commits in example-app round 3 (2026-05-07). See `agents/build-orchestrator.md` §"Phase 3 commit step" for the full procedure.
 4b. **Halt-and-ask backstop for architectural-class decisions** (NEW — C5). When an implementer encounters a synthesis-class decision NOT in the plan's `synthesis_dimensions` AND it's architectural-class (where a phase lives, defensive contract shape, error-propagation policy, persistence boundary, hard-fail counters), the implementer returns `status: "blocked"` with the decision in `novel_decisions[]` and does NOT commit. The orchestrator dispatches each blocked decision to the configured Thinking-tier resolver (per `references/model-tier-mapping.md` — never a hardcoded model name), persists resolutions to `state.json.novelDecisionResolutions[]`, and re-dispatches the implementer with resolutions appended to its brief. Hard-fail counter N=3 per chunk; exhausted chunks surface as ❓ Unfixed in Review-F. C3's attestation lint and C4's synthesis-critic still cover what they can grade — C5 catches what falls outside both. Full procedure: `agents/build-orchestrator.md` §"Phase 3 halt-and-ask branch".
 5. **Codex execution adapter**: If running in Codex, load `references/codex-subagents.md` before any spawn decision. Spawn `explorer` or `worker` subagents only when the Codex permission gate passed; otherwise execute locally. When spawning a worker, use `templates/codex-worker-prompt.md`, prefer explicit prompt packets over full context forks, and require the worker return changed files, validation, unresolved risks, and integration notes.

package/skills/build-loop/references/phase-4-review.md

@@ -120,6 +120,23 @@ If any infrastructure step fails (server won't start, curl errors, can't parse h
 - Use `verification-before-completion` for evidence-based claims
 - No criterion marked "pass" without proof
 
+**Acceptance-probe re-run gate (deterministic gate #1 — runs first, before any criterion can be marked passed)**: re-execute every `acceptance_probe` captured in Phase 1 Assess against the post-fix tree:
+```
+python3 ${CLAUDE_PLUGIN_ROOT}/scripts/acceptance_probe.py rerun --goal .build-loop/goal.md --workdir "$PWD" --json
+```
+Per-criterion `gate_verdict`:
+- `passed` — the probe ran and its output **no longer matches the captured baseline-failure**. The criterion's data-layer evidence is necessary but NOT sufficient; this re-run is the boundary observation that makes "passed" real. Proceed to the criterion's other graders.
+- `blocked` — the probe **still returns its baseline-failure state**. A blocked criterion **CANNOT be marked `passed`, and CANNOT be deferred inline** (no "out of scope" prose drop — that exact scope-drop is the evidenced failure this gate closes, sample-app 2026-06-13). It routes to Iterate like any Validate failure. If the run nonetheless needs to defer it, the deferral is a **DECISION-class surface**: pass the criterion's `decision_command` through the existing autonomy gate —
+  ```
+  python3 ${CLAUDE_PLUGIN_ROOT}/scripts/autonomy_gate.py --workdir "$PWD" \
+      --action "defer acceptance criterion <id>" --command "<decision_command>" --json
+  ```
+  with `.build-loop/config.json` `autonomy.confirmFor` carrying `"defer acceptance criterion *"`, so the verdict is `confirm` and the item lands in Sub-step G's `## Held` (explicit operator confirmation), never an inline prose defer. This reuses the Sub-step F Auto-Resolve wiring — no parallel surface.
+- `unverifiable` — the criterion carried no probe (flagged at Assess). The re-run has nothing to execute; the criterion falls through to its LLM-judge/other graders as today. Surface `⚠️ <id> unverifiable — no acceptance_probe` in Review-G.
+- `error` — the probe could not run (timeout / OS error). Surfaced, not silently passed; treat like an infrastructure-failure note and re-attempt or route to Iterate.
+
+`rerun` exit 0 = no criterion blocked; exit 1 = at least one blocked. Skip cleanly when goal.md has no `acceptance_probe` block (legacy/opt-in run; `no_probes`). Boundary discipline: the probe's declared `boundary` (`data|api|render|console|visual`) is the boundary the re-run observes — a `console`/`render` criterion is re-checked at that boundary, not via a cheaper `data` proxy. Full contract: `scripts/acceptance_probe.py` module docstring; Phase 1 capture in `phase-1-assess.md` §"Acceptance-probe contract".
+
 **Runtime smoke gate (post-tests, pre-LLM-judges)**: after code-based graders pass, invoke `python3 scripts/runtime_smoke.py --changed-files <list> --workdir "$PWD" --json` whenever any changed file matches a runtime-smoke trigger. The script auto-detects a dev-server adapter from the project's manifest (Next.js today; FastAPI, Express, and SSE-consumer adapters are documented future slots). `pass` proceeds; `fail` routes to Iterate using the smoke envelope's `findings` as the rubric; `skipped` (no trigger matched or no adapter for this stack) records `runtime_smoke: skipped (<reason>)` in Review-F and proceeds — library-only repos never fail this gate. See `references/runtime-smoke-triggers.md` for the full trigger-pattern table and adapter roadmap, and `agents/build-orchestrator.md` §"Review-B: Runtime smoke gate" for the routing rules.
 
 **Pytest-collection gate (full-suite-load check, every run)**: after code-based graders pass and before LLM judges, invoke `python3 scripts/pytest_collect_gate.py --workdir "$PWD" --json` on Python-bearing repos. The gate runs `pytest scripts/ tests/ --collect-only` with `PYTHONPATH` stripped (matching the spec's `env -u PYTHONPATH` discipline). Collection-only is the bar — it does NOT require the full suite to execute green (db/live tests legitimately skip via their markers); it only verifies that every test module *loads*. `pass` (exit 0, no findings) proceeds; `fail` (exit 1, one or more import/syntax errors) routes to Iterate using `findings[]` as the rubric — each finding carries `{file, line, error_class, message}` pointing at the broken module so the next iteration fixes the import rather than papering over the test; `exit 2` (runner error — pytest not found or a usage error with no parseable output) carries `status="fail"` with `error_class="RunnerError"` and `stderr_tail` — treat it exactly as `fail` and route to Iterate; `skipped` (no `pyproject.toml`/`pytest.ini`/`setup.cfg` and no test paths — library-only repo) records `pytest_collect: skipped (<reason>)` in Review-F and proceeds. **Non-standard layouts**: when `pyproject.toml` is present but the default `scripts/`/`tests/` paths are absent, the gate skips with a loud reason naming the gap — pass `--paths <dir> [...]` so a Python-bearing repo with tests elsewhere is not silently bypassed. **Why this gate exists** (every issue is a systems issue): build-loop's run gate historically scoped to changed-area tests, so a broken import that quietly removed an entire test module from coverage would not fail the build — exactly how 8750d2a's psycopg breakage and the EXECUTION_SCHEMA_VERSION miss hid for multiple runs. The collection gate closes that gap with one cheap check; the gate file is `scripts/pytest_collect_gate.py`, its regression tests are `scripts/test_pytest_collect_gate.py`.
@@ -162,6 +179,7 @@ Nothing false, fabricated, or placeholder reaches the user. Three gates, run in
 - **Gate 6 — Version-Bump Advisor** (only when `pluginWork: true`): run `python3 ${CLAUDE_PLUGIN_ROOT}/scripts/version_advisor.py --workdir "$PWD"`. Default state is `hold` — emits a one-line note in Review-F: `"N commits accumulated since vX.Y.Z. Holding version. Create .build-loop/release-pending.md when the batch is ready."` Switches to `suggest` only when `.build-loop/release-pending.md` exists; in `suggest` mode, Review-F proposes `vA.B.C` (semver inferred from Conventional Commits) and asks for explicit user confirmation before any plugin.json edit. Never auto-bumps. Never blocks. The marker file is the user's release signal; build-loop only ever advises.
 - **Gate 7 — UX Triage** (only when `uiTarget != null`): run `python3 ${CLAUDE_PLUGIN_ROOT}/scripts/ux_triage.py --workdir "$PWD" --clear`. Static-scans for four dimensions — interactability, performance, data-accuracy beyond current scope, usability — across the full project (not just changed files). Each `blocker` or `major` finding becomes a queue entry in `.build-loop/ux-queue/<id>.md` with a complete fix plan, evidence, files-touched, and an `architecture_impact` flag. Minor findings stay in the Review-F report only. The agent layer augments static findings with `performance-assessor` and `fact-checker` agent dispatches against the same surface for dimensions the static scanner can't fully cover. Queue entries feed into Phase 5 Iterate (see "Iterate input contract" below). Never block the current build — UX rot fixes ride along, they don't gate.
 - **Gate 8 — UI Coverage-Gap** (only when `uiTarget != null`): compare changed surfaces against existing project test files and the UI input/output contract. If a changed critical surface has no interaction/render coverage, add a queue entry to `.build-loop/ux-queue/` with `dimension: test-coverage` and a proposed repo-native test plan. Build-loop does not auto-draft `.ibr-test.json` files.
+- **Gate 9 — README Currency** (every build; generic, not plugin-only): run `python3 ${CLAUDE_PLUGIN_ROOT}/scripts/readme_currency_check.py --workdir "$PWD" --diff-range <pre_build_sha>..HEAD --json`. If the run changed a user-facing surface (a command, skill, agent, or CLI/`bin` entry per `readmeCurrency.surfaceGlobs`) but touched no README/`AGENTS.md` (`readmeCurrency.readmePaths`), it emits `verdict: warn` naming the undocumented surface. **WARN-only, never blocks** (advisory per the hook charter; exit 0 always) — surfaced in the Review-F report so the doc is updated before the batch ships. Skips cleanly when no surface changed, when disabled (`readmeCurrency.enabled: false`), or when no diff range resolves. Distinct from Gate 4 (which checks README↔plugin-cache *sync*, plugin repos only); this checks README *content currency* in any repo. Config + defaults: `.build-loop/config.json > readmeCurrency`; gate + tests: `scripts/readme_currency_check.py` / `scripts/test_readme_currency_check.py`.
 
 Blocking issues (Gates 1-4) -> route to Iterate; do not halt the run. For Gate 2 privacy findings, the orchestrator invokes the appropriate implementer, auditor, or specialist agent to remediate, then re-runs validation. Prefer `.gitignore` plus untracking for runtime/generated files, archive or private-store relocation over deletion for useful evidence, and redaction/scrubbing over removing useful public documentation. Queue entries (Gates 7-8) -> flow into Phase 5's prioritized work list. Warnings -> include in Report (sub-step G). Auto-bumping is forbidden.
 
@@ -246,7 +264,7 @@ Runs only when all prior sub-steps pass OR when iteration cap is hit. Writes fin
 
 Final report sections, in this order:
 
-- `## Done` — every verified pass + every Auto-Resolve `auto` item, with one-line evidence each.
+- `## Done` — every verified pass + every Auto-Resolve `auto` item, with one-line evidence each. **Lead outcome-first** (`output-style.md` §"Outcome framing"): the report's headline and substance lead with what the user can now do / what stops failing / what no longer needs a manual step, not the feature or mechanism that delivers it; mechanism, file paths, and design detail stay in the progressive-disclosure detail below the lead.
 - `## Held` — items Auto-Resolve verdicted as `confirm`, with the `reason` field from `autonomy_gate.py` quoted verbatim. The user may run any held command manually if they want to. Build-loop does NOT prompt or auto-execute these.
 - `## Blocked` — items Auto-Resolve verdicted as `block`, same shape as Held.
 - `## Status markers` — ✅ Known / ⚠️ Untested / ❓ Unfixed (existing convention; keep this section).
@@ -285,6 +303,7 @@ Style lint (`report_lint.py`) — WARN with self-heal, never a hard halt. The us
 
 - `summary.total == 0` → emit the report.
 - `summary.total > 0` → auto-revise the draft ONCE to clear the findings (translate jargon to plain language per the contract's blocklist, rewrite a missing headline as a one-sentence statement of what changed, add a validation line naming the exact command/method that verified the work, remove contrastive-pivot constructions), then re-run the lint. If a second pass still has findings, emit the report with a `[warn] report-lint findings remain after one revise pass` line in `## Done` and continue. Never block on style.
+- Outcome framing AND precision-and-brevity are part of this same self-heal pass (the lint does NOT grade either — both are judgment, not pattern): if the headline or first substance line leads with the feature/mechanism rather than the user outcome, rewrite it outcome-first per `output-style.md` §"Outcome framing"; and apply `output-style.md` §"Precision and Brevity — sentence architecture" (actor+strong-verb+outcome spine, concrete nouns/verbs, data over adjectives/adverbs, direct cause→effect with `because`/`suggesting`, no invented numbers) to the prose while rewriting. No extra pass and no new lint — fold both into the one revise pass above; a fuzzy "shorter words / causal pattern" check would over-block and is deliberately not added.
 - Script error / file not found → record `[warn] report-lint skipped (<reason>)` in `## Done` and continue.
 
 The two lints are orthogonal: structural rules live in `build_report_lint.py`, style/jargon rules live in `report_lint.py`. Neither replaces the other. The lints target ONLY the final user-facing report markdown; internal envelopes between agents stay structured/jargon-ok.

package/skills/build-loop/references/phase-5-iterate.md

@@ -25,7 +25,7 @@ The "code is cheap, AI agents build fast" framing: the orchestrator does NOT def
 
 **Fan-out** (mode-dependent): After dequeue, partition entries by `files_touched` into independent groups (no overlapping files).
 
-- **Top-level mode** (orchestrator invoked directly via the user's session): dispatch up to 4 `implementer` subagents in parallel via `Agent(subagent_type="build-loop:implementer", ...)` per the bundled `agents/implementer.md` (Sonnet 4.6, scoped tools=[Read, Write, Edit, Bash, Glob, Grep]). Hard cap from `~/.claude/CLAUDE.md` §Sub-Agents. Sequential groups process after the parallel batch.
+- **Top-level mode** (orchestrator invoked directly via the user's session): dispatch up to 4 `implementer` subagents in parallel via `Agent(subagent_type="build-loop:implementer", ...)` per the bundled `agents/implementer.md` (Sonnet 5, scoped tools=[Read, Write, Edit, Bash, Glob, Grep]). Hard cap from `~/.claude/CLAUDE.md` §Sub-Agents. Sequential groups process after the parallel batch.
 - **Subagent mode** (orchestrator was itself spawned via `Agent(...)` so the no-sub-sub-agents rule applies): degrade to **inline-implementer mode** — iterate the queue serially, apply each fix following the implementer's protocol (scope to `files_touched`, refuse `architecture_impact: true`, verify locally before declaring fixed). No parallelism, same quality bar. The orchestrator surfaces the degradation in Review-F.
 
 In both modes, each pass returns the same structured outcome (status + files_changed + verifications). Status routing covers all 9 implementer return values:
@@ -46,17 +46,18 @@ Results re-enter Sub-step B for re-validation. For Validate failures (no queue e
 **Infra self-heal before counting an attempt (C-HEAL / self_heal_safe_issues).** When an Iterate attempt's own tooling, hook, or Bash command FAILS (infra error — non-zero exit that is not a graded-criterion failure, e.g. a pre-commit hook crash, a lint runner that throws on a binary file, a script that errors on a missing env var): ROOT-CAUSE and FIX that infra error first. Classify via `scripts/classify_action.py`. SAFE → apply, verify (re-run the failed action), commit, then resume the Iterate attempt. RISKY/DECISION/PRODUCTION → isolate/surface per the normal routing table. An infra self-heal does NOT burn the iterate budget; only a graded-criterion failure (test/lint/validate failure against the rubric) burns a count. This prevents `--no-verify` bypasses and other workarounds from masking fixable infra errors.
 
 Per attempt:
-1. **Diagnose root cause** — don't just retry. Start the failure brief in plain language, then trace visible symptom -> technical failure -> upstream dependency/interface/process failure -> first controllable system failure. Actor-blame phrases such as "agent forgot" or "model missed context" are not terminal causes unless paired with the missing control that allowed them.
+1. **Diagnose root cause** — don't just retry. Start the failure brief in plain language, then trace visible symptom -> technical failure -> upstream dependency/interface/process failure -> first controllable system failure. Actor-blame phrases such as "agent forgot" or "model missed context" are not terminal causes unless paired with the missing control that allowed them. Split the brief into two axes — **creation** (why the defect existed at all) and **escape** (why no control caught it before the surface) — a bug often needs both fixed. The root cause is closed only when the named fix passes the **counterfactual**: it would have prevented/detected/contained THIS exact failure on the real input, not a hand-constructed one.
 2. **Stuck-iteration cascade (always on)**: at the START of EACH attempt, the orchestrator runs the cascade in order — see `agents/build-orchestrator.md` §Phase 5 for the full ladder. Summary:
    - **Evidence-gap repair (highest priority)**: if the prior gate flagged `evidence_gap: true`, invoke `Skill("build-loop:logging-tracer")` with intent `repair`. Ephemeral-by-default — Mechanism A (`DEBUG_TRACE=1` runtime gate) or Mechanism B (`git-stash` throwaway). Re-run the failed criterion; if output is now informative, proceed with new context.
    - **Memory-first re-check**: invoke `Skill("build-loop:debugging-memory")` again with the new symptom (it may have shifted shape after the prior fix attempt).
-   - **2 consecutive same-root-cause failures** → parallel multi-domain assessment via `build-loop:debugging-assess`. Pass `model: sonnet` to domain assessors explicitly (override `inherit` default to prevent 4× Opus fan-out from the Opus 4.7 orchestrator). The full procedure is documented in `skills/debug-loop/SKILL.md` §"If stuck — parallel multi-domain assessment".
+   - **2 consecutive same-root-cause failures** → parallel multi-domain assessment via `build-loop:debugging-memory` `{op:"assess"}`. Pass `model: sonnet` to domain assessors explicitly (override `inherit` default to prevent 4× Opus fan-out from the Opus 4.7 orchestrator). The full procedure is documented in `skills/debug-loop/SKILL.md` §"If stuck — parallel multi-domain assessment".
    - **3 consecutive same-criterion failures** → causal-tree investigation via `Skill("build-loop:debug-loop")`. Runs its own 7-phase cycle internally; returns with fix applied or hard-stop.
 3. **Build the prioritized work list** from the table above (Validate failures + UX queue).
 4. **Partition for parallel fan-out**: group by disjoint `files_touched`; dispatch ≤4 subagents in parallel.
 5. **Execute fixes**; for UI files, run the UI re-validate hook before continuing.
 6. **Loop back to Review sub-step B** (Validate). Sub-step A (Critic) usually skipped on re-runs unless the fix touched new files. Sub-steps C-F run only on final pass.
 7. **Followup overflow**: when the iteration cap (5) is reached and queue entries remain, write them to `.build-loop/followup/<topic>.md` for a subsequent `/build-loop:run` invocation. Plan content is already complete — the followup build skips its own Plan phase for these entries.
+   - **`judgment-owed-<run-id>.md`** entries (written by `stop_closeout` when a stakes-gated inline run closed at the inline floor) mean: **dispatch the owed verification layer(s) named in the file for that run** (the Frontier auditor/advisor it skipped), then the file is cleared automatically on the next passing Stop. Do not treat it as a code work-item — it is a dispatch-the-judgment debt.
 8. **Track**: attempt count, what failed, what was attempted, what changed, queue depth before/after each pass.
 
 **Convergence detection**:

package/skills/build-loop/references/phase-6-learn.md

@@ -50,6 +50,8 @@ Phase 6 has NO "skip entirely" condition. Three outcome states cover every run:
 - Promotion to `active/` STILL requires explicit `/build-loop:promote-experiment <name>` (decision-3 safety boundary preserved — auto-promote of unreviewed drafts never happens).
 - Auto-promote defaults to OFF — set `"autoPromote": true` to enable (requires effective sample ≥ 8).
 
+- Consumer default — learned drafts route to `~/.build-loop-extensions/pending/` via `scripts/extensions_route.py --name <ext-slug> --file <draft>`; they do not load until `scripts/extensions_approve.py` moves them into `plugin/`. (Maintainer routing: P2.)
+
 **What this phase will NOT do**:
 - Modify the build-loop plugin repo
 - Promote artifacts cross-project without explicit `/build-loop:promote-experiment <name>`

package/skills/build-loop/references/verify-dispatch.md

@@ -0,0 +1,85 @@
+<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
+<!-- PROVENANCE: folded from skills/verify-dispatch/SKILL.md (v0.1.0) on 2026-07-02 (pool-consolidation Inc 2). Reactive-selection trigger preserved in agents/build-orchestrator.md §"Verify every subagent" + skills/build-loop/SKILL.md; this reference holds the checklist body. -->
+
+# Verify dispatch — post-dispatch verification checklist
+
+Walk this after any dispatched Agent, Task, or orchestrator sub-agent (including background/`run_in_background` dispatches and headless build-loop orchestrators) claims commits landed and tests passed — especially when the safety classifier was unavailable or when you would say "classifier unavailable". Also applies when the user says "verify the subagent", "did the agent actually commit", or "confirm the dispatch worked". A solicited peer agreeing after you asked it to check is NOT independent verification — use this checklist instead.
+
+## When this fires / Why
+
+**Standing rule:** "verify every subagent." A dispatched agent's report is a claim, not evidence. Three recurring failure modes:
+
+- The safety classifier is unavailable, so the agent's self-report goes unchecked.
+- A solicited peer reviews your work after you asked it to — that's anchoring, not independent validation (memory: `feedback_solicited_peer_review_is_not_independent.md`).
+- An auditor was supposed to run but was substituted by inline self-audit (memory: `feedback_buildloop_verify_auditor_ran.md`).
+
+Ground truth comes from commands you run yourself, not from prose the agent returned.
+
+## 5-Step Verification Checklist
+
+Run these yourself. Do not echo the agent's report back as your own finding.
+
+### 1 — Confirm the commit hashes exist on the claimed branch
+
+```bash
+git log --oneline -n 5
+git rev-parse HEAD
+git branch --contains <hash>
+```
+
+The hashes the agent named must appear in the log. The branch must be the expected one. If HEAD is on the wrong branch, flag it before reading anything else.
+
+### 2 — Working tree is clean (modulo known runtime churn)
+
+```bash
+git status --short
+```
+
+Acceptable noise: `.rally/log/`, `.build-loop/state.json`, build artefacts declared in `.gitignore`. Anything else — unexpected staged files, leftover edits, index residue from a parallel agent — is a scope breach or index corruption; name it explicitly.
+
+### 3 — Run the test suites yourself; do not trust the report
+
+Pick the command that matches the repo:
+
+```bash
+# Rust
+cargo test
+
+# Python (prefer uv; system python may be broken)
+uv run --with pytest python -m pytest
+
+# Node / TypeScript
+npx tsc --noEmit && npx jest --passWithNoTests
+```
+
+Capture and report real pass/fail counts and any error output. "The agent said tests passed" is not a verification; this step is.
+
+### 4 — Confirm cross-repo parity fixtures are byte-identical
+
+When the build involves copied or synced artifacts (e.g. native skill copies from a sibling repo, fixture pairs, generated schema files):
+
+```bash
+diff <canonical-source> <copy-in-this-repo>
+# or
+sha256sum <file-a> <file-b>
+```
+
+A hash or diff mismatch means the sync did not complete correctly even if the agent reported success.
+
+### 5 — Report your findings with evidence
+
+State the outcome in this form:
+
+```
+✅ verified by: git log (commit abc1234 on branch X), cargo test (47 passed, 0 failed), git status clean
+⚠️ untested: <what you could not check and why>
+```
+
+Never emit "the agent confirmed it passed" as your own verification line. Name which commands you ran and what they returned. If a step was skipped, say why.
+
+## What this does NOT replace
+
+- **runtime-parity-verification** — that skill cross-checks a running app's UI against backend state. This checklist covers the git/test layer only.
+- **plan-verify** — that skill lints a plan's evidence claims before Phase 2 acceptance. This checklist fires after a dispatch reports completion.
+
+Origin lessons: `feedback_solicited_peer_review_is_not_independent.md`, `feedback_buildloop_verify_auditor_ran.md`, `feedback_verify_running_app_not_compile_green.md`.

package/skills/build-loop/templates/codex-worker-prompt.md

@@ -87,6 +87,10 @@ Does not own:
 
 - <function/route/schema/component/CLI/doc contract to preserve or expose>
 
+### Acceptance Criteria
+
+- <testable conditions the returning envelope must satisfy — the verifier's per-chunk oracle>
+
 ### Validation
 
 Run if feasible:

package/skills/debug-loop/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: debug-loop
-description: Use when a fix didn't hold, `/build-loop:debug` is invoked, the user asks for root cause analysis, memory lookup returns LIKELY_MATCH/WEAK_SIGNAL/NO_MATCH, or Review-B Validate fails. Deep iterative debugging loop — not for known fixes or trivial issues.
+description: Use when a fix didn't hold, `/build-loop:debug` is invoked, the user asks for root cause analysis, memory lookup returns LIKELY_MATCH/WEAK_SIGNAL/NO_MATCH, or Review-B Validate fails. Deep iterative debugging loop — not for known fixes or trivial issues. NOT for blameless postmortem system-lever analysis (use `root-cause-analysis`) or memory search/store (use `debugging-memory`).
 version: 1.1.0
 user-invocable: true
 ---
@@ -168,6 +168,8 @@ Every item in the report gets one marker:
 
 ### After Reporting
 
+> **Durable post-failure RCA:** for the blameless durable-lever pass (creation+escape paths, action-strength hierarchy, lever+actuator, regression artifact, spread check), delegate to the shared `references/root-cause-analysis/` suite. This skill/agent finds and fixes the live issue; that suite is the post-failure prevention layer.
+
 - **Store the incident** as a native `.build-loop/issues/*.md` note for future retrieval
 - **Record the outcome** through standalone Coding Debugger only if that optional plugin supplied the prior incident
 - **Write state** to `.build-loop/debug-loop/scorecard.md`
@@ -215,7 +217,7 @@ When to use parallel assessment vs continuing the linear loop:
 If the bundled assessor coverage isn't enough (e.g., the failure crosses a domain build-loop's bundled assessors don't cover well, or you need cross-build coordination), escalate via the native debugging skills:
 
 ```
-Skill("build-loop:debugging-assess") with input { symptom, scope: "global", calledBy: "debug-loop", reason: "stuck-iteration" }
+Skill("build-loop:debugging-memory") with input { op: "assess", symptom, scope: "global", calledBy: "debug-loop", reason: "stuck-iteration" }
 ```
 
 The native skill includes domain-specific assessors (api / database / frontend / performance). It uses build-loop local memory by default and may use standalone Coding Debugger for cross-build memory when available; otherwise it falls back to grep across `.build-loop/issues/` and `.build-loop/feedback.md` with narrower coverage.

package/skills/debugging-memory/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: debugging-memory
-description: Use when the user asks to "debug this", "fix this bug", "investigate error", "diagnose", "root cause", or reports a crash/exception/failure. Memory-first workflow checks past incidents before investigating.
-version: 1.5.0
+description: Use when the user asks to "debug this", "fix this bug", "investigate error", "diagnose", "root cause", or reports a crash/exception/failure. Memory-first workflow that checks past incidents before investigating — owns verdict-handling and Review-F outcome feedback. Op-routed (input `{op: "search" | "store" | "assess", ...}`): search = memory lookup, store = incident write, assess = parallel domain assessment; per-op detail in `references/{search,store,assess}.md`. NOT the iterative fix loop (use `debug-loop`) or the postmortem system-lever analysis (use `root-cause-analysis`).
+version: 1.6.0
 user-invocable: false
 ---
 
@@ -11,12 +11,24 @@ user-invocable: false
 
 This skill integrates build-loop's native debugging memory into debugging workflows. The core principle: **never solve the same bug twice**.
 
+## Op-routing interface (ADR-01)
+
+This skill accepts an `op` selector. Callers invoke `Skill("build-loop:debugging-memory") with input { op, ... }`:
+
+| `op` | Purpose | Detail reference |
+|---|---|---|
+| `"search"` | Memory LOOKUP — search local `.build-loop/issues/` (+ optional standalone Coding Debugger), return a verdict + compact matches. Default op for the memory-first gate and the domain assessors. | `references/search.md` |
+| `"store"` | Incident WRITE — persist a resolved bug as a native incident note (Review-F storage path). | `references/store.md` |
+| `"assess"` | Parallel domain ASSESSMENT — fan out api/database/frontend/performance assessors and rank findings. | `references/assess.md` |
+
+Omitting `op` runs the memory-first workflow below (equivalent to `op: "search"` followed by verdict-based routing). The three former skills `debugging-memory-search`, `debugging-store`, `debugging-assess` were folded into these ops (2026-07, pool-consolidation Inc 5); their bodies are the reference files above.
+
 ## Memory-First Approach
 
 Before investigating any bug, always check build-loop's native debugging memory:
 
 ```
-Search `.build-loop/issues/` and invoke `build-loop:debugging-memory-search` with the symptom description.
+Search `.build-loop/issues/` and invoke `build-loop:debugging-memory` `{op:"search"}` with the symptom description.
 ```
 
 The search returns a **verdict** with matching incidents and patterns.
@@ -49,9 +61,9 @@ When `KNOWN_FIX` direct-apply is blocked, the caller should treat the verdict as
 
 Results are returned as compact summaries. Drill into matches on demand:
 
-1. **Initial search**: Use `build-loop:debugging-memory-search` — returns verdict + compact matches when structured memory exists
+1. **Initial search**: Use `build-loop:debugging-memory` `{op:"search"}` — returns verdict + compact matches when structured memory exists
 2. **Drill down**: Read the matching `.build-loop/issues/<id>.md` incident note for full context
-3. **Outcome tracking**: Use `build-loop:debugging-store` after verification to record whether the fix worked, failed, or was modified
+3. **Outcome tracking**: Use `build-loop:debugging-memory` `{op:"store"}` after verification to record whether the fix worked, failed, or was modified
 
 ## Visibility
 
@@ -264,8 +276,8 @@ When a pattern matches:
 If project-local memory misses but cross-project memory might have a hit, re-call this skill with broader scope, or escalate to the assess skill for additional domain assessor coverage:
 
 ```
-Skill("build-loop:debugging-memory") with input { symptom, scope: "global", calledBy: "debugging-memory" }
-Skill("build-loop:debugging-assess") with input { symptom, scope: "global" }
+Skill("build-loop:debugging-memory") with input { op: "search", symptom, scope: "global", calledBy: "debugging-memory" }
+Skill("build-loop:debugging-memory") with input { op: "assess", symptom, scope: "global" }
 ```
 
 Both are native build-loop skills. They search local `.build-loop/issues/` first and may use standalone Coding Debugger only when that plugin is installed and the caller explicitly requests cross-project memory.
@@ -281,11 +293,11 @@ Do NOT use this for: every memory call (it's escalation, not primary path), or w
 
 | Surface | Purpose |
 |------|---------|
-| `build-loop:debugging-memory-search` | Search memory for similar bugs (returns verdict when available) |
-| `build-loop:debugging-store` | Store a new debugging incident |
+| `build-loop:debugging-memory` `{op:"search"}` | Search memory for similar bugs (returns verdict when available) |
+| `build-loop:debugging-memory` `{op:"store"}` | Store a new debugging incident |
 | `.build-loop/issues/<id>.md` | Full incident or pattern detail |
 | `.build-loop/issues/` | Recent incidents and local memory corpus |
-| `build-loop:debugging-assess` | Parallel domain assessment |
+| `build-loop:debugging-memory` `{op:"assess"}` | Parallel domain assessment (`references/assess.md`) |
 
 ## Parallel Domain Assessment
 
@@ -394,7 +406,7 @@ When debugging involves subagents (your own or from other plugins), follow these
 ### Automatic Behavior
 
 **Before spawning debugging-related subagents:**
-1. Search debugging memory first using `build-loop:debugging-memory-search`
+1. Search debugging memory first using `build-loop:debugging-memory` `{op:"search"}`
 2. Pass relevant context to the subagent in its prompt
 3. Include any matching incidents or patterns found
 
@@ -424,7 +436,7 @@ Start your investigation considering this prior knowledge.
 
 When using parallel assessment or multiple debugging subagents:
 
-1. **Pre-query memory once** using `build-loop:debugging-memory-search` before spawning agents
+1. **Pre-query memory once** using `build-loop:debugging-memory` `{op:"search"}` before spawning agents
 2. **Distribute context** - each agent gets relevant subset
 3. **Aggregate findings** - collect new insights from all agents
 4. **Store unified incident** - write a native `.build-loop/issues/*.md` note to document the combined diagnosis

package/skills/{debugging/assess/SKILL.md → debugging-memory/references/assess.md}

@@ -1,11 +1,4 @@
----
-name: build-loop:debugging-assess
-description: Parallel domain assessment for complex debugging symptoms — fans out database / frontend / API / performance assessors in parallel and ranks findings. Build-loop's native assessor orchestration, adapted from debugger command workflows (no canonical SKILL.md exists upstream).
-version: 0.1.0
-user-invocable: false
-source: claude-code-debugger/commands/assess.md
-source_hash: f97d4966e110928acea7678124aad0c421e6fc64ddf0a6f53a7e14580650307a
----
+<!-- PROVENANCE: op=assess reference for `build-loop:debugging-memory` (ADR-01 op-routing). Folded from skills/debugging/assess/SKILL.md (former skill name build-loop:debugging-assess, v0.1.0) on 2026-07-02, pool-consolidation Inc 5. Drift-check vs upstream retired (native, adapted; no canonical upstream). Former provenance for record: source=claude-code-debugger/commands/assess.md source_hash=f97d4966e110928acea7678124aad0c421e6fc64ddf0a6f53a7e14580650307a -->
 
 <!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
 
@@ -40,7 +33,7 @@ Run multiple specialized assessor agents in parallel against a vague or multi-do
    | API | endpoint, route, request, response, auth, 500, 404, cors, middleware |
    | Performance | slow, latency, timeout, memory, leak, cpu, bottleneck, optimization |
 
-2. **Search memory once** — invoke `build-loop:debugging-memory` with the symptom; pass any matching incidents to each assessor as context. Don't make each assessor re-query memory.
+2. **Search memory once** — invoke `build-loop:debugging-memory` `{op:"search"}` with the symptom; pass any matching incidents to each assessor as context. Don't make each assessor re-query memory.
 
 3. **Launch assessors in parallel** with `Agent`, all in a single message:
    - `database-assessor` — queries, schema, migrations, connection issues
@@ -87,7 +80,7 @@ Action sequence: 1) eliminate N+1, 2) add index, 3) re-verify latency
 
 If two assessors return overlapping `probable_causes` with similar confidence — flag as **multi-causal**. Both fixes may be needed. Don't pick one and discard the other.
 
-If they disagree fundamentally (e.g., database-assessor says query, performance-assessor says rendering) — present both, ask user which path to pursue first, OR escalate to `build-loop:debugging-debug-loop` for causal-tree investigation.
+If they disagree fundamentally (e.g., database-assessor says query, performance-assessor says rendering) — present both, ask user which path to pursue first, OR escalate to `build-loop:debug-loop` for causal-tree investigation.
 
 ## Output
 
@@ -104,8 +97,8 @@ Write summary to `.build-loop/state.json.debugging.assess[<symptom-hash>]`:
 
 ## Sibling Skills
 
-- `build-loop:debugging-memory` — search before assessing (mandatory pre-step)
-- `build-loop:debugging-debug-loop` — escalate when assessment is inconclusive
-- `build-loop:debugging-store` — store the resolved incident after the recommended action lands
+- `build-loop:debugging-memory` `{op:"search"}` (references/search.md) — search before assessing (mandatory pre-step)
+- `build-loop:debug-loop` — escalate when assessment is inconclusive
+- `build-loop:debugging-memory` `{op:"store"}` (references/store.md) — store the resolved incident after the recommended action lands
 
 *Source: adapted from the standalone debugger assess command plus the four assessor agents. Drift-checked by `build-loop:sync-skills`.*

package/skills/{debugging/memory/SKILL.md → debugging-memory/references/search.md}

@@ -1,11 +1,4 @@
----
-name: build-loop:debugging-memory-search
-description: Memory-first lookup before debugging — search local build-loop incidents and optionally standalone Coding Debugger memory. Build-loop's native debugging memory, adapted from debugger workflows. Distinct from the legacy in-tree `build-loop:debugging-memory` skill (kept for backward compat); this is the source-tracked native version.
-version: 0.1.0
-user-invocable: false
-source: claude-code-debugger/skills/debugging-memory/SKILL.md
-source_hash: 5c4ee5ada781107e7def92abeca4d51fc0efc61700f7cf43e948da34f4c0681d
----
+<!-- PROVENANCE: op=search reference for `build-loop:debugging-memory` (ADR-01 op-routing). Folded from skills/debugging/memory/SKILL.md (former skill name build-loop:debugging-memory-search, v0.1.0) on 2026-07-02, pool-consolidation Inc 5. Drift-check vs upstream retired (native, adapted; no canonical upstream). Former provenance for record: source=claude-code-debugger/skills/debugging-memory/SKILL.md source_hash=5c4ee5ada781107e7def92abeca4d51fc0efc61700f7cf43e948da34f4c0681d -->
 
 <!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
 
@@ -13,7 +6,7 @@ source_hash: 5c4ee5ada781107e7def92abeca4d51fc0efc61700f7cf43e948da34f4c0681d
 
 Memory-first debugging. Core principle: **never solve the same bug twice**. Native to build-loop; initially adapted from the debugger workflow lineage. Search local `.build-loop/issues/` first, then use standalone Coding Debugger for cross-project memory only when that plugin is installed.
 
-> **Naming note**: this skill is `build-loop:debugging-memory-search` to avoid colliding with the legacy in-tree `build-loop:debugging-memory` skill (which the orchestrator continues to call as the memory-first gate's primary entry point). Both have equivalent content; this one carries `source` + `source_hash` provenance and is drift-checked by `build-loop:sync-skills`. New code should prefer the legacy name until the orchestrator is migrated; sibling skills in `skills/debugging/` reference the legacy name where the gate's exact runtime semantics are needed.
+> **Op-routing note**: this is the `op: "search"` reference for `build-loop:debugging-memory` — the memory LOOKUP step. Callers invoke `Skill("build-loop:debugging-memory") with input { op: "search", symptom, domain? }`; this file holds the lookup procedure the workflow delegates to (ADR-01).
 
 ## When to Activate
 
@@ -32,7 +25,7 @@ The search returns a **verdict** with matching incidents and patterns when struc
 1. **KNOWN_FIX**: Apply the documented fix directly only when the strict direct-apply gate (below) passes; otherwise adapt the prior incident as a hypothesis and route to the standard fix flow
 2. **LIKELY_MATCH**: Review the past incident, use it as a starting point — never direct-apply
 3. **WEAK_SIGNAL**: Consider loosely related incidents, but investigate fresh
-4. **NO_MATCH**: Proceed with standard debugging via `build-loop:debugging-debug-loop`, then document the solution after
+4. **NO_MATCH**: Proceed with standard debugging via `build-loop:debug-loop`, then document the solution after
 
 ### Direct-apply gate (KNOWN_FIX only)
 
@@ -59,7 +52,7 @@ When this skill activates, always announce it to the user:
 
 ## Deep Investigation Mode
 
-For non-trivial issues, escalate to the `build-loop:debugging-debug-loop` skill. Trigger is the **verdict category**, not a numeric confidence score:
+For non-trivial issues, escalate to the `build-loop:debug-loop` skill. Trigger is the **verdict category**, not a numeric confidence score:
 
 - **`KNOWN_FIX`** → apply directly, skip the loop
 - **`LIKELY_MATCH`** → enter debug loop (past incidents need verification against current context)
@@ -82,7 +75,7 @@ Also enter the debug loop when:
 
 ## Incident Documentation
 
-After fixing a bug, store via `build-loop:debugging-store`. Required fields: `symptom`, `root_cause`, `fix`. Optional: `category`, `tags`, `files_changed`, `file`.
+After fixing a bug, store via `build-loop:debugging-memory` `{op:"store"}`. Required fields: `symptom`, `root_cause`, `fix`. Optional: `category`, `tags`, `files_changed`, `file`.
 
 ## Quality Indicators
 
@@ -122,7 +115,7 @@ Use these only when standalone Coding Debugger is installed. Build-loop does not
 
 Closes the memory-first gate's feedback loop. Both required:
 
-- For each newly resolved Review-B/Iterate failure: invoke `build-loop:debugging-store` with `{symptom, root_cause, fix, tags: ["build-loop", project, layer], files}`
+- For each newly resolved Review-B/Iterate failure: invoke `build-loop:debugging-memory` `{op:"store"}` with `{symptom, root_cause, fix, tags: ["build-loop", project, layer], files}`
 - For each Review-B memory gate where standalone Coding Debugger supplied a prior `KNOWN_FIX` or `LIKELY_MATCH`: invoke its `outcome` tool with `{incident_id, result: "worked"|"failed"|"modified", notes}` — this trains the optional verdict classifier
 
 Skipping `outcome` means the optional verdict classifier never improves.
@@ -134,14 +127,14 @@ When debugging involves subagents:
 1. **Pre-query memory once** through `build-loop:debugging-memory` before spawning agents
 2. **Distribute context** — each agent gets relevant subset
 3. **Aggregate findings** — collect insights from all agents
-4. **Store unified incident** — single `build-loop:debugging-store` call to document combined diagnosis
+4. **Store unified incident** — single `build-loop:debugging-memory` `{op:"store"}` call to document combined diagnosis
 
 Subagents do not inherit Skill or MCP access — pre-load context into their prompt.
 
 ## Sibling Skills
 
-- `build-loop:debugging-store` — write incident after fix
-- `build-loop:debugging-assess` — parallel domain assessment for multi-domain symptoms
-- `build-loop:debugging-debug-loop` — iterative root-cause analysis with causal-tree investigation
+- `build-loop:debugging-memory` `{op:"store"}` — write incident after fix
+- `build-loop:debugging-memory` `{op:"assess"}` — parallel domain assessment for multi-domain symptoms
+- `build-loop:debug-loop` — iterative root-cause analysis with causal-tree investigation
 
 *Source: adapted from the debugger workflow lineage and maintained as a build-loop-native skill. Drift-checked by `build-loop:sync-skills`.*

package/skills/{debugging/store/SKILL.md → debugging-memory/references/store.md}

@@ -1,12 +1,4 @@
----
-name: build-loop:debugging-store
-description: Store a debugging incident after fixing a bug — writes build-loop's native local incident record and optionally mirrors to standalone Coding Debugger. Build-loop's native incident storage; canonical source has no discrete SKILL.md (the §"Incident Documentation" section of debugging-memory).
-version: 0.1.0
-user-invocable: false
-source: claude-code-debugger/skills/debugging-memory/SKILL.md
-source_hash: 5c4ee5ada781107e7def92abeca4d51fc0efc61700f7cf43e948da34f4c0681d
-source_section: "Incident Documentation"
----
+<!-- PROVENANCE: op=store reference for `build-loop:debugging-memory` (ADR-01 op-routing). Folded from skills/debugging/store/SKILL.md (former skill name build-loop:debugging-store, v0.1.0) on 2026-07-02, pool-consolidation Inc 5. Drift-check vs upstream retired (native, adapted; no canonical upstream). Former provenance for record: source=claude-code-debugger/skills/debugging-memory/SKILL.md §Incident-Documentation source_hash=5c4ee5ada781107e7def92abeca4d51fc0efc61700f7cf43e948da34f4c0681d -->
 
 <!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
 
@@ -19,7 +11,7 @@ Persist a fixed bug to debugging memory so future builds can recognize recurrenc
 ## When to Activate
 
 - Phase 4 Review-F Report: for each Review-B/Iterate failure newly resolved this build, store the incident
-- After any `build-loop:debugging-debug-loop` run that produced a verified fix
+- After any `build-loop:debug-loop` run that produced a verified fix
 - User asks "save this fix", "remember this bug"
 
 ## Native Path — Build-Loop Incident Note
@@ -146,8 +138,8 @@ Write to `.build-loop/debugging/incidents/<incident_id>.json`. Flag `debugger JS
 
 ## Sibling Skills
 
-- `build-loop:debugging-memory` — search memory before debugging
-- `build-loop:debugging-assess` — parallel domain assessment
-- `build-loop:debugging-debug-loop` — full iterative debugging that produces the incident this skill stores
+- `build-loop:debugging-memory` `{op:"search"}` (references/search.md) — search memory before debugging
+- `build-loop:debugging-memory` `{op:"assess"}` (references/assess.md) — parallel domain assessment
+- `build-loop:debug-loop` — full iterative debugging that produces the incident this op stores
 
 *Source: adapted from the debugger incident-documentation workflow and maintained as a build-loop-native skill. Drift-checked by `build-loop:sync-skills`.*