@tyroneross/build-loop 0.35.0 → 0.36.0

package/skills/build-loop/references/output-style.md

@@ -10,16 +10,18 @@ It extends — does not duplicate — the existing guidance:
 
 Scope: **user-facing output only.** Internal agent-to-agent envelopes (subagent return JSON, judge-decisions, run records, MECE briefs) are structured data and stay as-is — they exist for machines, not the human.
 
-## The five rules
+## The rules
 
 1. **Headline = one plain full sentence** stating what changed. First non-blank line. Not a noun phrase, not a telegraph fragment, not a heading.
-2. **Bulleted concrete artifacts.** Below the headline: commit hashes, file paths, issue paths. Concrete things the user can grep, open, or `git show`.
-3. **Substance bullets.** What the change captures or does, in plain language. Optional when the artifacts alone are self-explanatory.
-4. **Validation line, explicit.** Name the exact command, method, or observer that verified the work, with a status marker:
+2. **Outcome framing — lead with what changes for the user.** The headline and substance lead with what the user can now do, what stops failing, or what no longer needs a manual step — the *result*, not the implementation. Use before→after when it clarifies. Mechanism, file paths, and design detail still belong in the report — below the lead, in the progressive-disclosure detail (see rules 3–4), never in the headline. See "Outcome framing" below for the worked good/bad pair.
+3. **Bulleted concrete artifacts.** Below the headline: commit hashes, file paths, issue paths. Concrete things the user can grep, open, or `git show`.
+4. **Substance bullets.** What the change does for the user, in plain language (outcome-first per rule 2). Optional when the artifacts alone are self-explanatory.
+5. **Validation line, explicit.** Name the exact command, method, or observer that verified the work, with a status marker:
    - `✅ Verified by <method>` — ran the script, passing test, curl response, IBR scan, demo
    - `⚠️ Untested — <what couldn't be verified and why>`
    - `❓ Uncertain — <what's assumed and what would close it>`
-5. **Plain language.** No jargon (see blocklist below). No contrastive pivot (`not X — it's Y`, `isn't X, it's Y`, `not just X but Y`) — state the point directly.
+6. **Plain language, stated directly.** No jargon (see blocklist below). No contrastive pivot (`not X — it's Y`, `isn't X, it's Y`, `not just X but Y`) and no soft hedging — state the point directly, and state cause and effect directly (see "Precision and Brevity" below: shorter words, data over adjectives, direct cause→effect). The contrastive-pivot ban and the direct-cause-and-effect rule are the same instinct: say what happened and why, without negation or padding.
+7. **Numbers only when supplied or verified.** Never invent a metric, date, percentage, or count to make a sentence concrete. This is the user-facing-style restatement of build-loop's existing "no false data, no unverified claims" guarantee — the fact-checker (Review-D) traces every rendered metric to its source; this rule keeps the report from adding one the fact-checker never saw. If you have no number, write the plain claim without one.
 
 ## Jargon blocklist (user-facing only)
 
@@ -39,6 +41,97 @@ These tokens are fine in internal envelopes; they must be translated to plain la
 | `state.json.runs[]` | "run record" |
 | Internal phase codenames (C-HEAL, C-RCA, C-FLOW…) | Describe the behavior, not the code |
 
+## Outcome framing — lead with the result, not the mechanism
+
+The report describes what the change DOES FOR THE USER, not the feature or mechanism that delivers it. Lead with what the user can now do, what stops failing, or what no longer needs a manual step. Before→after where it clarifies. Plain language, minimal jargon. The mechanism — script names, normalization, TTLs, file paths — still appears, but in the progressive-disclosure detail below the lead, never in the headline or the first substance line.
+
+This is judgment, not a deterministic check: `report_lint.py` does NOT grade outcome framing (a fuzzy "is this outcome-framed?" rule would false-green on disguised mechanism prose and false-block on terse-but-correct outcome reports). The rule is enforced by the Review-G one-pass self-heal — the orchestrator rewrites a mechanism-only lead into an outcome-first one before emitting.
+
+### Good — outcome-framed (the user-approved target style)
+
+```
+When you run build-loop and a model it depends on goes down, the work now keeps
+running on a backup instead of stopping and waiting for you to step in — and when
+that model comes back, it returns to it on its own. You stop having to be the
+manual fallback.
+
+- No more stalled runs during an outage — if the preferred model is unavailable,
+  agents automatically continue on the next-best one, instead of erroring out and
+  needing a restart.
+- Self-recovery — once the model is back, the system returns to it within about
+  half an hour by itself, rather than staying on the backup until someone resets it.
+- Quality holds during fallback — it won't quietly drop verification to a weaker
+  model, and won't pick a model the setup can't run.
+- Works as you add or change models — the same behavior applies no matter which
+  vendor a model comes from.
+```
+
+Why this is good: the headline says what changes for the user ("the work now keeps running … you stop having to be the manual fallback"), each bullet leads with the user-visible outcome (no stalled runs, self-recovery, quality holds, works as you change models), and the before→after contrast ("instead of stopping and waiting", "rather than staying on the backup") makes the gain concrete. The mechanism that delivers it (the fallback script, the recovery window, the tier floor, vendor-agnostic resolution) is implied through outcomes, not enumerated.
+
+### Bad — mechanism-only (same change, tells the user nothing)
+
+```
+Added dispatch_fallback.py with canonical-id normalization and a host-provider
+filter; outages persist to model-availability.json with a TTL.
+```
+
+Why this is bad: it is the exact same change, but described as the feature/implementation. The reader learns what files exist, not that their runs stop stalling during an outage or that quality holds on the backup. It leads with the mechanism (`dispatch_fallback.py`, `canonical-id normalization`, `host-provider filter`, `model-availability.json`, `TTL`) and never states the user outcome. The fix is the rewrite above: keep this detail, but move it below an outcome-first lead.
+
+## Precision and Brevity — sentence architecture
+
+Clear, concise statements depend less on better words and more on sentence architecture. Strongest pattern: concrete noun + strong verb + specific object/outcome + cause/evidence when needed.
+
+### 1. Core elements of a clear sentence
+| Element | Job | Strong | Weak |
+|---|---|---|---|
+| Actor/subject | Who or what it is about | The team | There was |
+| Verb | What happened/changed | launched, cut, missed, caused | had, was, experienced |
+| Object/outcome | What the action affected | the onboarding flow | the process |
+| Cause | Why it happened | because ownership was split | due to various issues |
+| Metric/evidence | What proves it | 70% dropped at step 5 | many users struggled |
+| Time/place | When/where | in Q2, at step 5 of 7 | recently, during the process |
+| Implication | Why it matters | so the team should shorten setup | which is important |
+
+Core sentence spine: [Actor] [verb] [object/outcome] [because cause].
+Example: The team launched behind schedule because ownership was split across three groups.
+
+### 2. Parts of speech: what to favor
+- Nouns — concrete: name real things/people/roles/systems/outcomes. ("Users abandoned onboarding at step 5." not "There was friction in the user journey.")
+- Verbs — carry the sentence: had an impact on→changed; was responsible for→caused; made improvements to→improved; experienced delays→slipped; provided support for→supported; made a decision→decided.
+- Adjectives — only when they add precision: "missed the regulatory deadline" (why it matters) not "an important deadline" (asks for trust).
+- Adverbs — usually replace with data: significantly increased→increased 42%; quickly resolved→resolved in two days; frequently failed→failed in 3 of 5 tests; strongly suggests→suggests; materially improved→improved conversion by 8 points.
+
+### 3. Most useful sentence patterns
+1. Outcome → Cause — [Actor] [outcome] because [cause]. ("The model gave inconsistent answers because the prompt lacked success criteria.")
+2. Metric → Behavior → Location → Meaning — [Metric] of [group] [behavior] at [point], suggesting [meaning]. ("70% of users abandoned onboarding at step 5 of 7, suggesting the flow was too long.") Use "suggesting" when data implies but does not prove a cause.
+3. Cause → Outcome — [Cause] caused [outcome]. ("No single owner caused the project to stall.")
+4. Actor → Action → Object → Reason — [Actor] should [action] [object] because [reason]. ("The team should cut onboarding from seven steps to three because most users drop off before setup is complete.")
+5. Decision → Rationale → Tradeoff — [Decision] works because [rationale], but [tradeoff]. ("A shorter onboarding flow should improve completion, but it may collect less user data upfront.")
+6. If → Then → Because — If [condition], then [action/outcome] because [reason]. ("If users abandon step 5, then the team should test a shorter flow because the current sequence likely asks for too much upfront.")
+
+### 4. Order of information
+Default: (1) main point, (2) evidence or cause, (3) implication or next step.
+Example: "Users are dropping out late in onboarding. 70% abandon at step 5 of 7, suggesting the setup asks for too much before users see value. The team should test a three-step version."
+
+### 5. Practical rule set
+1. Start with the real actor, not "there is" / "it is."
+2. Use one strong verb instead of a weak verb plus extra words.
+3. Prefer numbers over vague claims.
+4. Put the main point before the explanation.
+5. Use "because" for known causes.
+6. Use "suggesting" for likely causes.
+7. Cut adjectives unless they add specific meaning.
+8. Replace adverbs with data when possible.
+9. Keep one main idea per sentence.
+10. Keep caveats close to the claim they qualify.
+Do not invent data: numbers, dates, and evidence appear only when supplied or verified (this is the user-facing-style face of build-loop's no-false-data principle + the fact-checker, not a second check).
+
+### Best default formula
+[Specific actor] + [strong verb] + [specific outcome] + because + [specific cause].
+Example: "Users abandoned onboarding because the seven-step flow asked for too much before showing value."
+
+This section is JUDGMENT-enforced in the Review-G one-pass self-heal alongside outcome framing — `report_lint.py` does NOT grade "shorter words", sentence patterns, or "is this a causal sentence": a fuzzy check there would false-flag correct terse prose and over-block, against the deterministic-only-for-known-risks rule. The direct cause→effect guidance is the same instinct as rule 6's no-contrastive-pivot ban (state what happened and why, without negation or padding); the no-invented-data line is the user-facing-style face of rule 7 and of build-loop's standing "no false data, no unverified claims" principle, traced by the fact-checker in Review-D — not a second enforcement path. Apply these when rewriting the draft; do not add a lint for them.
+
 ## Good — the exemplar (Codex output, captured 2026-06-04)
 
 ```

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

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

@@ -9,7 +9,7 @@
 **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.

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/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`.*