Goal Quench

---
name: goal-quench
description: >-
  Wraps /goal with a tiered safety + orchestration ladder. core (default): a token budget gate (pre-run estimate), mid-run budget thresholds, and an automatic post-run quality verification via pipeline-conductor — closing /goal's two gaps (the runner's per-turn judge evaluates completion, pipeline-conductor evaluates correctness). pro: adds context-doctor token reduction and agent-composer goal decomposition. max: adds internal-first capability-gap fill (LOCAL_SKILL_REGISTRY skill-bus scan → plugin-recommender external search → auto_project_mapping map/cluster) and cross-ecosystem-synergy-detection pre-validation. The Phase-1 budget verdict auto-recommends the mode. Triggered by "goal with quality gate", "safe goal", "goal-quench", "orchestrate this goal", or before running /goal on high-stakes tasks.
user-invocable: true
allowed-tools: ["Read", "Write", "Bash", "Grep", "Agent", "WebSearch", "WebFetch"]
# Agent: Steps at :198 / :216 dispatch sub-agents (skill-bus proposals, agent-composer panel).
# WebSearch/WebFetch: max-mode deep-research rung 2 (:46). All three were commanded by the body
# while undeclared here — a declaration that omits what the skill actually does is not a diet.
model: sonnet
complexity_routing:
  base: sonnet
  escalate_when:
    - pro_mode       # orchestration: context-doctor + agent-composer decomposition
    - max_mode       # + external discovery: plugin-recommender + synergy pre-validation
  high: opus
  # NOTE: CC switches models per-turn by task weight, not per-skill invocation.
  # With `/model opusplan`: Opus activates on plan-mode turns (reasoning, decomposition);
  # Sonnet handles execution turns (tool calls, edits). Both appear in session jsonl.
  # Without opusplan: all turns use the session model regardless of mode.
---

# goal-quench — /goal with Token Budget + Quality Gate

**Availability of `/goal` is unresolved** — treat it the way `CLAUDE.md` treats `/deep-research`:
use the built-in **if present**, and do not assert it is absent either. Everything below applies to
whatever autonomous-run command this environment actually has; goal-quench is the wrapper, not the
runner. Probe before relying on it (`/help`, or the skill/command list), and say which you found.

`/goal` is understood to run until a cheap per-turn judge (reported as Haiku) says "done" — that is
**second-hand, not verified here**, so treat it as the assumption goal-quench is designed against
rather than as a fact about the implementation. What matters for this skill holds either way: a
completion judge is not a quality judge, and without a budget ceiling a session can exhaust tokens
silently. goal-quench adds three things such a runner does not itself provide:

1. **Pre-run**: token-budget-gate estimate — know the cost before committing
2. **Mid-run**: budget threshold awareness — signal before exhaustion (instructional; not mechanically enforced)
3. **Post-run**: pipeline-conductor — verify quality before accepting "done"

The evaluator principle: the runner's own per-turn judge decides completion (every turn, cheap). pipeline-conductor judges quality (once at the end, structured). Separating the two closes the self-evaluation bias that a single evaluator cannot avoid — the principle holds whatever model that per-turn judge turns out to be.

> **Scope by mode**: core = budget gate + stop-hook verification (v1 behavior, unchanged). pro/max add token reduction, goal decomposition, and external discovery (see Modes below). (Tier names mirror Claude Code's subscription units — core / pro / max — and avoid colliding with pipeline-conductor's `--full` flag.) Mid-run Sonnet quality signals remain deferred (requires empirical calibration).

---

## Modes — core → pro → max (fluid)

goal-quench is a ladder, not a fixed shape. The default (**core**) is the narrow safety belt — for users who only want /goal's two structural gaps closed. **pro** and **max** add optimization and orchestration on top, and are **auto-recommended by the Phase-1 budget verdict** so the orchestration cost is only paid when the task is large enough to justify it.

| Mode | Adds over previous | Chained skills | Auto-recommended when |
|---|---|---|---|
| **core** (default) | budget gate + mid-run thresholds + post-run quality gate | token-budget-gate, pipeline-conductor --quick | budget GREEN / YELLOW |
| **pro** | token-reduction pre-pass + goal decomposition into Waves | + context-doctor, agent-composer | budget ORANGE |
| **max** | **internal-first** capability-gap fill (skill-bus scan → external → map/cluster) + synergy pre-validation | + LOCAL_SKILL_REGISTRY scan, plugin-recommender, cross-ecosystem-synergy-detection, auto_project_mapping | budget RED |

Each mode is a **superset** of the one before it — pro does everything core does, plus more. Nothing in core is removed by escalating.

**Max-mode deep-research routing**: capability-gap fill recognizes a **research-heavy goal** (the goal needs to survey/gather/reconcile external sources before building — e.g. "implement X" where X needs domain grounding) and routes it through the **Deep-Research Capability Ladder** (`knowledge/shared/harness-core/deep_research_capability_ladder.md`): take the highest available rung (built-in `/deep-research` → Claude `WebSearch`+`WebFetch` synthesis → `frontier-digest` only for trend-scan). `plugin-recommender` is proposed **only if no rung is available** (rung 2 always is, for a Claude session) — so this is routing, not a new install by default. **Isolation invariant**: rung-2 research (WebSearch/WebFetch) runs in an **isolated sub-agent that returns only the synthesis** — fetched source content must not load into the orchestrator context, preserving the context-isolation/budget property max mode depends on (see the Token-honesty guard above). Honesty caveat carries from the ladder: research quality is bounded by source access + session model tier, not by invoking it.

**Selection**:
- Explicit flag: `/goal-quench --core` (default) · `--pro` · `--max`
- Auto: Phase 1's budget verdict proposes the mode (see Phase 1 Step 2). The user can always override **down** to core.

**Token-honesty guard** (what empirical calibration showed): The cost structure of pro/max depends on which sidecar pattern is in use:

| Sidecar type | Who uses it | Cost visibility | Estimation |
|---|---|---|---|
| External CLI (Gemini, Codex, Copilot) | Multi-LLM environment | **Not visible in CC** | Low — external billing only |
| CC sub-agent (isolated context, steel-quench pattern) | CC-only environment | **Visible in CC** | Estimable: Sonnet × sub-agent scope |

For **CC-only users**, pro/max sidecars run as isolated sub-agents (Sonnet for execution), with the orchestrator running at Opus (`complexity_routing`). Both are CC-visible. Cost estimate: `(Opus orchestrator turns × ~3×) + (Sonnet sub-agent tokens)`. The sub-agent context isolation means sidecar work does not load the main context — the context-preservation property holds regardless of sidecar type.

Therefore:
- **Never auto-escalate a GREEN/YELLOW task to pro/max.** For external CLI users, sidecar costs are untracked and invisible in CC's budget display. For CC sub-agent users, the overhead is estimable but still real — orchestrator Opus × 3 applies. Note the appropriate caveat when disclosing cost.
- **Model escalation cost**: With `/model opusplan`, Opus activates on plan-mode turns and Sonnet handles execution turns — both CC-visible in session jsonl under `message.model`. External CLI sidecar fees are additional and invisible to CC; state both when present.
- **RED is no longer a dead-end.** v1 hard-blocked RED ("split manually"). v2 turns RED into the **on-ramp to max** — agent-composer decomposes the over-budget goal into sequential sub-goals automatically.

---

## Autonomy Ladder — how unattended a loop may run (orthogonal to the budget modes)

The core/pro/max modes above key on **budget**. This ladder keys on a different axis — **how much human approval gates each action** — for a *recurring or unattended* loop (the autonomous-loop / `/loop` case), not a one-shot /goal. **Climbing a rung here changes *oversight*, never budget — the two never move together.** (Distilled 2026-06-27 from the "Loop Engineering" sister-asset's "training-mode dry-run → graduated autonomy"; cross-audit `tracks/_audit/session_2026_06_27_loop-engineering-silbal.md`.)

Three rungs, climbed one at a time:

| Rung | What runs | Human role |
|---|---|---|
| **① dry-run** | run once manually; observe outputs; **no irreversible actions** | reads every output |
| **② step-approval** | each action is HITL-gated before it fires | approves per action |
| **③ unattended** | the loop runs on its own | reviews after the fact |

- **Graduation threshold (measured):** a loop climbs one rung only after **K consecutive clean rounds across a 2+ session/run window** — the *2+ window* reuses `operations.md`'s promotion-window discipline (`accepted ≥ 60%` / recurrence `N=3`). **`K=2` is a provisional default, not yet calibrated** — no loop-run data exists yet; revisit once it does (same honesty as this SKILL's `N=10` budget baseline). "Clean" = the round's Done-When passed **AND** a positive downstream verdict (pipeline-conductor / sidecar = CLEAN) **AND zero S/M-grade governor-catch and zero post-ship correction** — *not merely* the absence of a governor-catch, so a quieter or weaker governor cannot manufacture graduation. **The streak is recorded per round in a local autonomy ledger** (the hub keeps it at `tracks/_meta/autonomy_ledger.yaml`; a plugin-only user keeps their own — anywhere in their project, the path is theirs): date · task · done-when · verdict · governor-catch grades · `clean:` bool. Graduation reads that ledger. A *computation script* (`scripts/`) that auto-derives the current rung from the ledger is **deliberately deferred** until enough entries exist to compute over — building the meter before there is a stream to measure is the speculative-infra the evidence-threshold discipline forbids. *Check class: a **measured count** (ledger grep) over a **judged per-round grade** — and the grade must be bound to the round's own challenger / steel-quench S/M verdict (the upstream adversarial artifact), **never an author self-grade** (else "measured" laundering a judge-only path). Until ≥~5 entries make a computation script worth writing, the streak is judged-and-hand-recorded — provisional by construction.*
- **Irreversible carve-out (non-negotiable — the FH increment over the video):** any action whose effect **cannot be undone within the loop** — not only the two examples (Destructive-Op delete/rewrite · Pre-Publish go-public) but **any irreversible side-effecting write** (an MCP `ask`-tier send, a payment, an outbound publish) — **never reaches rung ③**. Membership is the **mechanical surface test** of CLAUDE.md's Surface-Class Degrade Invariant + `mcp_tool_gating` (grep the action surface; do **not** self-label), not a match against the two examples. Such actions stay at rung ② (HITL) **permanently**, regardless of clean-round count. ⚠️ Rung ② assumes a **human** answers the prompt: under an auto-approver (a `PermissionRequest` allow hook) a hook's `ask` was answered for you and the call ran 5/5, while `deny` stopped it (interactive, 2026-09-25) — so where one is installed, rung ② must be enforced with **deny / exit 2**, not ask (`knowledge/shared/harness-core/hook_channel_visibility.md`). The video graduates a loop to fully unattended; FH caps graduation at the irreversible boundary. *Check class: judged — pair: a target-tier blind sim per CLAUDE.md §Target-tier sim gate (run 2026-06-27, Sonnet, PASS — a remote-branch-delete loop correctly held at rung ② despite 4 clean rounds). **Prose-enforced, not hook-enforced** — accepted residual, named not silent.*
- **Demotion (fail toward oversight, with a liveness floor):** any governor-catch, failed Done-When, or correction **resets the clean-round counter and drops the loop one rung** — autonomy is earned per-window, surrendered on the first miss, never sticky. A failed **dry-run (①)** has no lower rung: it **blocks graduation and surfaces to the operator**, it does not demote. A loop that **flips promote/demote ≥ `N=3` times in a window** (reusing operations.md's recurrence-escalation) is a noisy boundary — **freeze at the lower rung and surface**, do not keep oscillating.

### Two paths to autonomous completion (by surface reversibility)

The clean-streak graduation above governs **unattended-no-review** operation (rung ③) — right for *narrow recurring loops* (digest / sync / poll) where nobody sees each result, so the demonstrated clean streak is the only safety. **Most substantive novel work — including FH self-development — rarely earns a clean streak by design.** It is not therefore undelegatable; it takes a second, *reviewed* path:

- **Path 1 — clean-streak → unattended (rung ③):** narrow recurring tasks reviewed by nobody. Safety = the demonstrated clean streak (above).
- **Path 2 — *deliver-then-review* (a reviewed mode at rung ②'s oversight, not a new rung):** autonomous *execution* with **mandatory review** — it is **not** unattended and **does not climb to ③** (only Path 1's clean streak reaches ③). **Intent-seeded, mechanically-reversible, reviewed** work — mapped-project acceleration / first-project creation (human intent via Q&A), and self-dev absorption of frontier-digest-style insights. Path 2 permits autonomous *execution to completion without per-step approval*, but operator review of the delivery is **mandatory before the work is consumed** — that review is what *substitutes for* pre-approval. All five conditions hold, or it is not Path 2:
  - **(a) Human-selected direction — auditable, not narrated.** A human *selects* the direction; record it in the ledger (`seed: human-selected` or `innovator-proposed-human-confirmed`). An agent/innovator-proposed direction is a **candidate, not a seed**, until a human confirmation token is recorded — the machine never chooses *what* to pursue (self-echo guard, `[[fh_self_evolution_vision]]`).
  - **(b) Mechanically-reversible surface — anchored to the carve-out partition, never a softer self-judged "reversible".** Admissible only if **all three**: **(i)** not a member of the line-81 **grep-gated** irreversible set (mechanical); **(ii)** **effect-confined** to git-tracked tree state — no file deletion, external/DB mutation, or out-of-tree write. *This conjunct is **judged, not grepped** — whether delivered code mutates external state at runtime is behavioral, not a static surface (`[[qa_static_dynamic_complementarity]]`); its pairing is the line-81 grep **plus** the operator's mandatory delivery review, and it **degrades safely** — unproven confinement → treat as irreversible → HITL.* **(iii)** **not yet consumed** (a *local, unpushed-to-shared* commit; the instant a delivery is pushed to a shared branch or read by a downstream cache / CI / registry it is *effectively published* and re-enters HITL, per CLAUDE.md §Pre-Publish (b)).
  - **(c) Reviewable delivery.** Deliver as **discrete revertable units** (per-commit, not one opaque squash) so **rollback granularity ≥ delivery granularity**. A batch too large to actually review makes "roll back after seeing it" theoretical and voids the substitute-for-approval logic — cap the batch at what the operator can review; interdependent commits (revert 1 orphans 3) forfeit per-unit rollback and must be delivered batch-atomic with a higher review bar.
  - **(d) Rollback feeds demotion.** A Path-2 delivery the operator rolls back **forces the next same-class run back to rung ② full step-approval (per-action *pre*-approval — stricter than Path 2's post-hoc review) until one clean delivery**, and counts toward the `N=3` noisy-boundary freeze — so the riskier, novel work-class is not handed the looser path. *Prose-enforced, not hook-enforced — accepted residual (the ledger records the rolled-back delivery; no hook yet gates the next run, same status as the carve-out's residual above).* (Rung ② names two oversight strengths: Path-2 = human reviews *after* each delivery; demoted = human approves *before* each action. The demotion tightens from the former to the latter.)
  - **(e) Every action in the run is gated by (b) — not just the final delivery** *(cross-family review caught this 2026-06-27; the Claude same-family reviewers + the Sonnet sim shared the blind spot)*. Producing a Path-2 delivery often requires *executing* code — running a test suite, installing a package, a migration script, an API call. **Each such action is itself subject to (b)**: a preparation step that deletes files, mutates a DB, installs an untrusted dependency, or hits the network has an **irreversible *runtime* effect that no `git` rollback undoes** (git reverts the tree, never the execution that produced it). So it stops for HITL exactly like a delivery action — and a purely *exploratory/speculative* run that would do any of these is not "free" either. "Reversible" is a property of **every action in the run**, never only of the committed tree at the end.

**Direction is always human (both paths).** The machine automates *execution* of a human-seeded direction, never the direction itself. **The irreversible carve-out holds regardless of path** — anything irreversible, effect-unconfined, or already-consumed (at *delivery or during the run*) stays pre-action HITL; Path 2 delegates only what (b) admits.

---

## Triggers

- `/goal-quench`
- "run /goal with a quality gate", "safe goal run", "goal with verification"
- "I want to use /goal but worried about tokens", "goal with budget control"
- "goal-quench", before any long /goal session
- `/goal-quench --pro`, `/goal-quench --max`, "orchestrate this goal", "decompose this goal", "optimize then run this goal"
- "this goal is too big for one run", "find a tool for this goal if FH lacks one" (→ max mode)
- "assemble capabilities for this project", "develop project X with everything FH has", "what can FH + tools do for this project", "use all of FH's and others' sharp parts on this" (→ max mode, **project-dev capability-assembly** entry — internal skill-bus scan first, then external gap-fill, then map+cluster; token-efficient, non-expert-friendly)
- Automatically proposed when user mentions `/goal` on tasks estimated > 15K tokens
- Mode is auto-recommended by the Phase-1 budget verdict (GREEN/YELLOW → core, ORANGE → pro, RED → max)

---

## One-Time Setup (required)

**Claude Code runtime**: merge the Stop-hook snippet from `templates/goal-quench-hook-setup.md` into `.claude/settings.json`, and gitignore the two state files. Recovery flags exist for hook failures: `/goal-quench --verify` (Phase 3 only, manual trigger) and `/goal-quench --recover` (interrupted /goal — promotes `.active` → `.pending`).

**Codex runtime**: do not replace Codex's native goal/session capability with goal-quench state files — use `fh-gate`/`fh-goal` as post-run governance wrappers instead.

> **Detail**: See `SKILL_detail.md §Setup` — CC hook snippet + gitignore lines, hook-failure/interrupted-run recovery commands, Codex runtime commands — read when performing one-time setup or recovery.

---

## Phase 1 — Pre-run Gate

### Step 1. Collect task description

Ask: *"What will you run with /goal? Describe the task and expected scope."* Collect: task description, target files or directories, expected output.

**Pre-flight rule (pro/max only)**: verify required chained skills (context-doctor, agent-composer) are installed before proposing pro/max. If any is missing, **fall back to core and warn**: "Pro/max mode requires `{skill}` — not installed. Running in core mode instead."

> **Detail**: See `SKILL_detail.md §Phase1-Blocks` — pre-flight check bash, token-budget-gate invocation contract, state file format, threshold injection block, hand-off output — read when executing Phase 1 Steps 1–5.

### Step 2. token-budget-gate estimate

Run token-budget-gate against the task description (invocation contract in §Phase1-Blocks). If the skill is not installed, use this fallback estimator and note `budget_source: fallback-heuristic` in `.active`:

```
< 5 files changed, no new architecture  → GREEN  (< 10K)
5–20 files or new module/feature        → YELLOW (10K–30K)
20+ files or cross-system refactor      → ORANGE (30K–60K)
Full-project migration or rewrite       → RED    (> 60K)
```

**Session overhead factor (empirical, N=10, 2026-06-01–06-03)**: the tiers estimate *task* tokens only. Actual full CC session tokens average 4.7× the task estimate (range 1.3×–10.5×) for harness-heavy projects. Multiply task estimate by 4× for FH-density projects to get the expected session total — this informs the mode recommendation, not the go/no-go thresholds.

Map the verdict to a go/no-go decision:

| token-budget-gate verdict | goal-quench action |
|---|---|
| GREEN (< 10K) | Proceed without comment |
| YELLOW (10K–30K) | Proceed — note estimated cost, suggest /goal scope if possible |
| ORANGE (30K–60K) | Propose **pro mode** as the cheaper path: "This is expensive. Run as a single /goal, or let pro mode optimize (context-doctor) + decompose (agent-composer) it?" Proceed in core only if the user declines orchestration. |
| RED (> 60K) | Propose **max mode** instead of a hard block: "Too big for one /goal run. Route through max mode — agent-composer decomposes into sequential sub-goals, plugin-recommender fills any capability gaps." Hard-block only if the user declines orchestration. |

On RED: **accept max mode** (recommended) → Phase 1.5 decomposition recovery path; **decline orchestration** → goal-quench halts, writes no `.active`, and will not gate or verify a session started without its active file.

### Step 3. Write state file

Create `.claude/goal-quench.active` (format in §Phase1-Blocks). `target_files` is the **verification artifact** — what pipeline-conductor will evaluate in Phase 3. Specify explicitly if known; otherwise write `"inferred from git diff"` and Phase 3 resolves via `git diff {start_commit}..HEAD` (captures interim commits).

> **Control flow (core vs pro/max)**: in **core** mode, proceed directly Step 3 → Step 4. In **pro/max** mode, run **Phase 1.5 (orchestration) here — after Step 3, before Step 4** — then return to Step 4. The `composed_plan` field in `.active` stays `n/a` until Phase 1.5 fills it.

### Step 4. Inject mid-run budget thresholds

Before the user runs /goal, output the threshold instruction block (50% progress note · 70% re-prioritize · 85% stop-and-ask · 95% stop-and-commit — full block in §Phase1-Blocks) so Claude carries it into the /goal session.

### Step 5. Hand off to /goal

Output the ready message (budget verdict + estimated tokens + "run `/goal {your condition}`" — template in §Phase1-Blocks).

---

## Phase 1.5 — Pro / Max Orchestration Layer

> Runs only in `--pro` or `--max` mode (auto-proposed on ORANGE/RED budget, or user-selected). **Skipped entirely in core mode** — core hands off straight to /goal after Step 5.

The ordering is deliberate: optimize the context first (cheapest win), then decompose, then — only if a capability gap remains — reach outside FH.

### Step A — context-doctor (token-reduction pre-pass) · pro + max

Invoke context-doctor on the target scope before /goal runs (generates/updates `.claudeignore`, flags over-read files, recommends `/clear` timing). **Re-estimate** the budget after the pre-pass. If the verdict drops (e.g., ORANGE → YELLOW), offer to step back down to core (see Simplification Guards — post-optimization step-down).

### Step B — agent-composer (goal decomposition) · pro + max

Hand the task description to agent-composer in compose-only mode → Wave plan with capability-fit scoring (agent-composer Step 0.2). For RED-origin runs this decomposition is the recovery path v1 lacked.

**Sub-goal execution (user-driven, not automatic)**: `/goal` is user-invoked — goal-quench cannot programmatically loop over sub-goals. Write the plan to `.claude/goal-quench.queue` (format in §Queue-Format) and instruct the user to invoke `/goal-quench` once per sub-goal. Each invocation pops the first `remaining` item, runs it as an independent core-mode run, then moves it to `completed`. When `remaining` is empty, delete the queue file. (Parallel sub-goal execution is deferred — sequential is the v2 contract.)

goal-quench does **not** re-implement agent-composer's gates — its destructive-action gate (Step 2.7) and per-wave fan-out cap apply as-is.

> **Detail**: See `SKILL_detail.md §Queue-Format` — queue file format, plan-ready output text, sidecar `.active` fields — read when writing the queue (Step B) or the sidecar fields (Step D).

### Step C — capability fill: internal-first, then external · max only

Triggered only when agent-composer Step 0.2 reports a capability **GAP** (`fit_score < 0.5` on a required-weight sub-task). Fill order is **internal before external** — honors no-reinvention (use FH's + sibling projects' sharp parts before installing anything), and cheaper **on an internal hit** (a local registry read ≪ an external marketplace search; on an internal *miss* the scan is added overhead before the same external path):

1. **Internal scan first.** Run the `LOCAL_SKILL_REGISTRY` scan / Cross-Project Skill Bus (the runtime-root-derived scan under `.claude/registry/`) to check whether an existing **FH meta-skill or a sibling-project skill** already fills the gap. **Trust-gated dispatch** (the fields the registry carries are *consumed*, not just surfaced): an **FH meta-skill** hit → propose directly (Agent + Context Card, no install, token-cheap); a **non-FH sibling** hit → if `trust≠trusted` OR `writes≠read-only` → **ask-tier HITL before dispatch** (never propose-directly — sibling code is an injection surface), else propose. **Degrade direction**: if `.claude/registry/` is missing/malformed, treat as an internal-miss and **fall through to external (step 2), warn** — never silently skip capability fill (that drops the GAP sub-task unnoticed; capability-fill is a reversible surface → advisory-degrade per the Surface-Class Degrade Invariant).
2. **External only if internal has nothing.** `plugin-recommender` searches FH + Codex + Claude Code marketplaces + external repos for a fitting skill/agent; `cross-ecosystem-synergy-detection` pre-validates fit + overlap **before anything is installed**.
3. User decides: use-internal / install-external / skip / general-purpose fallback (agent-composer's degraded-composition rule applies — `⚠️ degraded: [role]`).
4. **Approved external capability → map + cluster (deferred to session close).** An adopted external skill or a newly-relevant sibling project is registered via `auto_project_mapping` — but that write **edits CLAUDE.md's track-mapping table and creates `tracks/{project}/` (an FH-asset change that trips the 4-axis auto-gate and shifts the onboarding is-mapped signal — [[feedback_tracks_dir_is_mapped_signal]])**, so it is **deferred to session close**, not run mid-`/goal`-loop: it passes the 4-axis gate as its own change instead of interrupting the run. The **next** run then discovers the capability internally at step 1 — the loop compounds.

max mode never installs or maps anything silently — internal hit, external discovery, synergy-check, and mapping are all surfaced for approval first.

### Step D — scope-driven sidecar configuration · pro + max

Runs after Step C (or after Step B if no capability gap). Selects an adversarial sidecar based on the task's quality-risk profile — distinct from Step C's capability-gap sidecar. Step D's sidecar addresses **blind-spot risk**: the generator and reviewer sharing the same reasoning distribution.

> **Availability resolution**: "if available" below is decided by the canonical Tier 1→2→3 recipe in `knowledge/shared/harness-core/multi_model_sidecar_strategy.md §Sidecar Engine Resolution Protocol` — discovery is automatic, invocation stays value-gated. Tier 3 (Claude sub-agent) guarantees this step never hard-fails even with zero external CLIs/keys.

**Scope → sidecar routing table**:

| Task scope signal | Sidecar | Invocation point |
|---|---|---|
| Code quality review / new SKILL.md / governance gate change | `steel-quench` cross-provider challenger (Gemini sidecar if available; Tier 3 Claude sub-agent fallback) | Post-/goal, before pipeline-conductor |
| Architecture design / cross-project dependency | `agent-composer` multi-model panel (if external CLIs available; otherwise single-Claude sub-agent) | Parallel to /goal as separate Agent |
| External publication / marketplace-gate / skill release | `sim-conductor` + `steel-quench` Wave 5 | Post-/goal quality gate |
| No signal match (default) | None — pipeline-conductor handles quality alone | — |

Write the resolved `sidecar:` + `sidecar_rationale:` fields to `.active` (format in §Queue-Format). Output one line: *"Sidecar: {config} — {rationale}"*. Do not ask for confirmation; the user may override via `/goal-quench --sidecar none`.

**Dispatch-failure triage (saturation disguise)**: a sidecar dispatch failing with a 1M-context / usage-credits error late in a long run may be reporting *session context saturation*, not a billing gate (measured 2026-06-12). Triage order: compact — flushing handoff state to disk first — → retry the dispatch once → only then take the headless `claude -p` fallback (credit-pool cost) or an inline at-floor pass.

### Hand-off

After orchestration, **update** (not re-create) `.claude/goal-quench.active` — add `mode:` and `composed_plan:` lines alongside existing budget fields. Re-creating the file loses the `start_commit` field. Then proceed to threshold injection (Phase 1 Step 4) and hand off to /goal. Phase 3 verification runs as in core — `pipeline-conductor --quick` for pro, `--full` for max.

---

## Phase 2 — Mid-run (during /goal execution)

goal-quench does not directly control /goal execution. The budget thresholds injected in Phase 1 are instructions Claude follows during the /goal session: track approximate consumption against the estimate, execute the corresponding action at each threshold (50/70/85/95%), self-enforced without waiting for goal-quench.

**Threshold enforcement caveat**: Claude cannot reliably read its own real-time token consumption — thresholds are instructional approximations, not mechanically enforced. For hard enforcement, see the Anthropic feature request (--budget flag).

**Queue mode (per-sub-goal threshold scope)**: each `/goal-quench` invocation from the queue is an independent core-mode run — thresholds are re-injected fresh against that sub-goal's own Phase 1 estimate, not inherited from the outer pro/max run.

**What goal-quench cannot do in v1** (requires native Anthropic support): hard token ceiling (--budget), auto-checkpoint commits (--checkpoint), mid-run Sonnet quality signal. These gaps are the basis for the feature request (`knowledge/shared/harness-core/goal_quench_anthropic_issue.md`).

---

## Phase 3 — Post-run Verification

### Claude Code path

When /goal stops, the Stop hook: detects `.active` → copies to `.pending` → removes `.active` → prints the verification-pending notice.

On the next Claude response, check `.claude/goal-quench.pending` **with a freshness guard** (bash in §Phase3-Bash):
- **Fresh (< 4 hours)**: **automatically run pipeline-conductor** before responding to any other request — `--quick` for core/pro, `--full` for max (the `mode:` field in `.pending` selects). Not optional — pending verification takes priority.
- **Stale (> 4 hours)**: warn — "A stale goal-quench.pending exists from {timestamp}. Run `/goal-quench --verify` to re-evaluate, or delete it to clear." Do not auto-trigger verification on stale state.

### Codex path

After the Codex goal completes, run `fh-gate` on changed files (commands in §Phase3-Bash). Treat `BLOCKED`/`ESCALATE` the same as the Claude path.

> **Detail**: See `SKILL_detail.md §Phase3-Bash` — freshness guard bash, verification-artifact resolution bash, Codex gate commands — read when executing Phase 3.

### Verification flow

Resolve the verification artifact from `.pending` — explicit `target_files`, or `git diff {start_commit}..HEAD` when inferred (bash in §Phase3-Bash; empty target = hard error). Run pipeline-conductor on the artifact and gate on the result:

| pipeline-conductor verdict | goal-quench action | Delete `.pending`? |
|---|---|---|
| `CLEAN (--quick)` | Output: "Quality gate passed (--quick). Safe for local iteration and internal commits. Run pipeline-conductor --full before external release or PR." Log tokens. | **Yes — immediately** |
| `PENDING` | Proceed with caution. Output pending items. Recommend: "Resolve before any external release." | **Yes — immediately** |
| `BLOCKED` | Block commit. Output blocking items. Ask: "Fix and re-run /goal, or accept partial completion?" | **Only after user acknowledges** |
| `ESCALATE` | Surface to user for decision. Do not auto-delete — preserve state until user explicitly decides. | **Only after user decision** |

**Deletion rule**: On BLOCKED or ESCALATE, `.pending` must survive until the user makes an explicit decision — deleting before that loses the recovery anchor.

**Deadlock prevention**: While `.pending` exists (BLOCKED/ESCALATE), the next-turn verification check runs ONCE per turn only. After the first verification output, suppress further auto-trigger until the user explicitly acts. If the user starts a new `/goal-quench` run while `.pending` exists, warn and do not silently overwrite with a new `.active`.

Record actual token usage in `tracks/_meta/goal_quench_{YYYY-MM-DD}.md` for calibration (regardless of verdict).

### Step 3-c — Sidecar verdict gate (pro + max, when sidecar ≠ none)

After pipeline-conductor completes, read `sidecar:` from `.pending`. If non-none, gate on the sidecar's verdict before advancing to Done When:

| Sidecar | Wait for | Failure action |
|---|---|---|
| `steel-quench-crossprovider` | Wave 2 convergence: PASS or CONDITIONAL_PASS | FAIL → reopen Phase 2, surface blocking findings to user |
| `agent-composer-panel` | Panel findings file written + incorporated into pipeline-conductor context | Not yet written → re-run pipeline-conductor with panel findings |
| `sim-conductor` + `steel-quench-w5` | Both: sim-conductor Area A PASS **and** steel-quench W5 convergence PASS | Either FAIL → block Done When; surface failing verdict |

This gate is **blocking** — Done When cannot be reached until the sidecar verdict is resolved. Record `sidecar_findings_count` in the calibration record before closing.

---

## Calibration Record

After each goal-quench run, append a calibration entry to `tracks/_meta/goal_quench_{YYYY-MM-DD}.md`. Baseline (N=10, 2026-06-01–06-03, Sonnet): mean actual/estimate ratio 4.7× — systematic underestimation from session overhead. Target: 10 prospective runs per mode before treating mode comparison as reliable.

> **Detail**: See `SKILL_detail.md §Calibration-Record` — full YAML entry format, actual_tokens collection script, calibration baseline notes — read when appending the post-run record.

---

## Simplification Guards

- Do not activate goal-quench for exploratory or single-turn tasks — only for /goal sessions.
- If the user runs /goal without going through goal-quench setup, propose retroactively: "Run /goal-quench --verify to quality-check the output."
- `--verify` mode: skip Phase 1+2, go directly to Phase 3 verification using current session scope.
- **core is the default and the floor** — never auto-escalate a GREEN/YELLOW task to pro/max. Sidecar CLI costs (external, untracked in CC) apply in pro/max — auto-escalation requires ORANGE/RED budget or explicit user flag.
- **pro/max are supersets of core, not replacements** — a user who wants only the v1 safety belt stays in core and sees no orchestration.
- **Post-optimization step-down**: if a pro/max run's re-estimated budget drops to GREEN/YELLOW after context-doctor trims (Phase 1.5 Step A), offer to drop back to core — don't run orchestration the trimmed scope no longer needs.
- Phase 1.5 does not re-implement the gates of the skills it chains (agent-composer's destructive/fan-out gates, plugin-recommender's install approval) — it defers to them.

---

## Chains

- `token-budget-gate` — Phase 1 cost estimation (all modes)
- `context-doctor` — Phase 1.5 Step A token-reduction pre-pass (pro + max)
- `agent-composer` — Phase 1.5 Step B goal decomposition into Waves (pro + max)
- `LOCAL_SKILL_REGISTRY` scan / Cross-Project Skill Bus — Phase 1.5 Step C internal-first scan (max only, GAP-triggered, before external)
- `plugin-recommender` — Phase 1.5 Step C external capability-gap fill (max only, GAP-triggered, only if no internal hit)
- `cross-ecosystem-synergy-detection` — Phase 1.5 Step C pre-validation of discovered candidates (max only)
- `auto_project_mapping` — Phase 1.5 Step C map/cluster of an adopted external capability (max only, approval-gated, deferred to session close)
- `pipeline-conductor` — Phase 3 quality gate (`--quick` for core/pro, `--full` for max; called by Stop hook)
- `field-harvest` — capture calibration data as reusable pattern after 10 runs

---

## Done When

```
☐ Phase 1: token-budget-gate verdict output + mode resolved
  (core default, or pro/max via budget verdict / explicit flag)   (mandatory-pass)
☐ .claude/goal-quench.active written (with mode: field) +
  thresholds injected — the file exists on disk and is read back  (mandatory-pass)
☐ If pro/max: Phase 1.5 ran — context-doctor pre-pass +
  agent-composer plan; max additionally: GAP-triggered internal
  LOCAL_SKILL_REGISTRY scan FIRST (trust-gated dispatch);
  plugin-recommender + cross-ecosystem-synergy pre-validation
  ONLY if no internal hit; auto_project_mapping map/cluster
  deferred to session close only if an external capability was
  adopted (each surfaced for approval)                            (mandatory-pass)
☐ Phase 3 (on next response after /goal): .pending detected +
  pipeline-conductor run (--quick core/pro, --full max)           (mandatory-pass)
☐ Verification verdict output (CLEAN/PENDING/BLOCKED/ESCALATE)    (mandatory-pass)
☐ If sidecar invoked (pro/max Step D): Step 3-c sidecar verdict
  resolved (PASS/CONDITIONAL_PASS) before closing                 (mandatory-pass)
☐ .pending deleted + calibration record appended                  (mandatory-pass)
☐ Calibration record carries actual_tokens as a NUMBER or the
  literal "unknown" — never 0, never blank, never omitted         (measured: field present and
                                                                   non-empty)
☐ Enumerated failed/skipped checks reconcile against the resolved
  mode's in-scope set: len(list) == in-scope − passed             (measured: exact equality —
                                                                   this is the anchor that keeps
                                                                   the verdict off a judge-only
                                                                   path)
☐ The run actually achieved the stated goal, not merely finished  (judged — adversarial pairing:
                                                                   pipeline-conductor's verdict is
                                                                   the independent check; the
                                                                   runner's own completion judge
                                                                   does NOT satisfy this, which is
                                                                   the entire reason this skill
                                                                   exists)
```

Verdict: PASS (CLEAN verification) | CONDITIONAL_PASS (PENDING verification) | FAIL (BLOCKED verification) | ESCALATE (user decision required on partial completion)

**Completion-claim discipline (Ralph — no silent partial completion):** a PASS/CONDITIONAL_PASS
verdict must **enumerate, not assert** — (a) **evidence artifact**: the pipeline-conductor verification
verdict + the calibration record path; (b) **failed/skipped checks by name** (which pipeline axes /
sidecars FAILED or were skipped). This list is **not self-asserted** — reconcile it against the resolved
mode's in-scope axis/sidecar set: a list shorter than (in-scope − passed) is incomplete, not PASS (an
empty list is valid only when every in-scope check passed). This is the mechanical anchor that keeps the
clause off a judge-only path; (c) **explicit residual risk beyond what the mode-qualifier already states**
(e.g. an axis that ran but on degraded input). A verdict that omits any of the three is **incomplete, not
PASS**. (Convergent sister evidence: oh-my-claudecode Ralph "refuses silent partial completion"; Hermes
Agent `/goal` per-turn completion judge.)