pipeline-conductor

name	pipeline-conductor
description	Chains the four core FH verification pipelines (harvest-loop → steel-quench → phantom-quench → sim-conductor) into a single gated sweep. Accepts a scope (single skill, specific asset, full harness) and aggregates results into one structured report. Supports --quick mode (steps 2+3 only) and --full mode (all four steps). Triggered by "run the full pipeline", "chain all verifications", "end-to-end sweep", "pipeline-conductor", or "verify everything".
user-invocable	true
allowed-tools	["Read","Write","Bash","Grep","Glob","Agent"]
model	sonnet

pipeline-conductor — Chained Verification Sweep

Chains the four standalone FH verification pipelines into a gated sequence. Each step receives the previous step's verdict before proceeding. Aggregates all findings into a single structured report at the end.

The gap this closes: harvest-loop, steel-quench, phantom-quench, and sim-conductor are each invocable independently but have no automatic hand-off between them. Running them sequentially by hand loses inter-step signal — a FAIL in step 2 should block step 3 rather than silently continuing. pipeline-conductor enforces that ordering.

Triggers

• /pipeline-conductor
• "Run the full verification pipeline", "chain all four verifications"
• "End-to-end sweep before I push", "verify everything at once"
• "I want to run all the checks in order", "do a full harness review"
• "Run quench then grounding then sim", "chain the pipelines"
• "Full pipeline on this skill", "sweep this asset before release"

Disambiguation: "run the pipeline" alone may trigger harvest-loop (which uses identical phrasing). Prefer "run pipeline-conductor" or "chain all verifications" for unambiguous activation.

Modes

Flag	Steps run	When to use
--full (default)	Steps 1 → 2 → 3 → 4	Complete verification sweep
--quick	Steps 2 → 3 only	Fast adversarial + phantom check; skip knowledge loop and simulation
--no-sim	Steps 1 → 2 → 3	Skip sim-conductor (e.g., no sim environment available)

Mode qualifier on verdicts: CLEAN (--quick) and CLEAN (--no-sim) do not qualify as pre-release gates. Only CLEAN (--full) is sufficient for external publish or PR approval.

Verdict Format

Every step emits exactly one verdict line before handing control to the next step:

Verdict: PASS | CONDITIONAL_PASS | FAIL | ESCALATE
Basis:   [one-line summary of deciding factor]

Verdict	Meaning	Chain behavior
PASS	Step complete, no blocking issues	Proceed to next step
CONDITIONAL_PASS	Issues found but none are blockers; must be resolved before final report	Capture items, proceed to next step; flag in final report
FAIL	Blocking issue found	Halt chain, surface to user immediately
ESCALATE	Ambiguous state requiring human judgment	Pause chain, present three options to user

CONDITIONAL_PASS means proceed, not skip — captured items accumulate into the final report's Pending section and must be addressed before the sweep is considered clean. FAIL halts the chain (user decides fix-and-resume or abandon). ESCALATE pauses the chain pending the user's choice.

ESCALATE Handling

When any step returns ESCALATE, present:

"Step N returned ESCALATE: [basis]. Choose: (a) Make a decision — state your judgment and I will incorporate it and continue the chain. (b) Accept and continue — mark this as PENDING in the report and proceed to the next step. (c) Abort — close the sweep as BLOCKED."

• Option (a): User provides judgment → incorporate as resolution note → re-evaluate step gate with decision context → continue chain.
• Option (b): Mark ESCALATE item as PENDING → continue chain from step N+1.
• Option (c): Halt, output BLOCKED report with ESCALATE item in blocking section.

---

Step 0. Scope, Mode, and Translation

Determine before running any pipeline step:

1. Scope: single skill (path to SKILL.md) · specific asset (file/directory) · full harness (plugins/ + templates/)
2. Mode: --quick, --no-sim, or --full (default)
3. Branch: current git branch (used for regression guard and report header)

If scope is not specified, ask: "What should I sweep? (e.g., a specific skill path, a directory, or the full harness)" Do not infer scope — a wrong scope produces misleading verdicts.

Output the sweep plan and get Y/N confirmation before running.

Detail: See SKILL_detail.md §Output-Formats — sweep plan block, per-step verdict blocks, aggregated report template — read when emitting any step output.

Scope Translation Table

The four constituent skills use heterogeneous scope models. Translate the pipeline scope to each skill's invocation form before running any step:

Pipeline scope	harvest-loop (Step 1)	steel-quench (Step 2)	phantom-quench (Step 3)	sim-conductor (Step 4)
Single SKILL.md	Check session findings relevant to this skill; propose mode only	Adversarial attack on this SKILL.md	Back-trace claims in this SKILL.md to declared sources	Area D (artifact review) on this SKILL.md
Specific directory	Check session findings in this domain	Attack all SKILL.md files in directory	Back-trace all claims in directory	Area A + Area D on the domain
Full harness	Check all recent session findings	Attack all harness assets under scope	Back-trace all claims across harness	Area A + Area B + Area D

---

Step 0.5. return-path-gate — Pre-flight Chain Audit

Skip if return-path-gate is not installed or scope is a single non-pipeline skill.

Run /return-path-gate --skill [scope].

return-path-gate result	Step 0.5 verdict	Chain behavior
0 OPEN chains	PASS	Proceed
MEDIUM/LOW severity OPEN chains only	CONDITIONAL_PASS	Proceed; capture in Pending
1+ HIGH severity OPEN chains	FAIL	Halt sweep — fix chains before running pipeline

Skip override rule: S (skip on FAIL) is available but must be declared explicitly. Skipping records as degraded: return-path-gate (user override) in the final report and the sweep cannot reach CLEAN (--full) status regardless of subsequent step verdicts.

---

Step 1. harvest-loop — Knowledge Loop Check

Skipped in --quick mode.

Check for harvest-loop signals in the current session — read session context rather than invoking harvest-loop directly (a mid-sweep invocation would conflict with the sweep's own pattern collection).

harvest-loop result	pipeline-conductor verdict
Ran this session — all steps pass, no pending patterns	PASS
Ran this session — patterns found but no blockers	CONDITIONAL_PASS — capture pattern list
Ran this session — semantic drift or loop failure detected	FAIL
Did not run this session	CONDITIONAL_PASS — note: knowledge loop not validated
Auto-skipped (< 3 patterns)	CONDITIONAL_PASS — note: sub-threshold, not validated

Detail: See SKILL_detail.md §Execution-Notes — harvest-loop invocation path, per-step FAIL prompts, Area B cadence bash, what-each-step-checks reference — read when executing Steps 1–4.

---

Step 2. steel-quench — Adversarial Verification

Run steel-quench against the target scope (for --quick, this is the first step).

steel-quench severity vocabulary (S/A/B grade — not M/S/R):

• S-grade: Immediate blocker — must fix before proceeding
• A-grade: Required before deployment — fix before external release
• B-grade: Improvement recommended — non-blocking

steel-quench result	pipeline-conductor verdict
0 S-grade findings	PASS
A-grade or B-grade findings only	CONDITIONAL_PASS — capture finding list
1+ S-grade findings	FAIL
Wave 4 (Meta-Aware Adversary) surfaces structural ambiguity	ESCALATE

---

Step 3. phantom-quench — Phantom Claim Detection

Run phantom-quench scoped to the same target as Steps 1 and 2.

Load-bearing Phantom (binary test — apply mechanically). A Phantom is load-bearing if it appears in any of:

• §Done When section of the skill under audit
• Any numbered §Step N execution body
• §Chains with mandatory dispatch language (→ Mandatory next)

All other locations (§Triggers, advisory §Chains language, frontmatter description) are non-load-bearing by definition.

phantom-quench result	pipeline-conductor verdict
0 Phantoms, all claims grounded	PASS
Phantom claims found, none load-bearing (binary test)	CONDITIONAL_PASS — list Phantoms
1+ load-bearing Phantoms	FAIL
Grounding ambiguous (source file exists but content unclear)	ESCALATE

---

Step 4. sim-conductor — Pre-Deploy Simulation

Skipped in --quick and --no-sim modes.

Run sim-conductor against the target scope: Area A + Area B (if cadence allows) + Area D (if scope is a specific SKILL.md or document).

Area B cadence rule (behavioral): Area B has a once-per-week frequency limit. If Area B ran within 7 days (detection bash in §Execution-Notes) → skip Area B, run Area A + D only, capture as CONDITIONAL_PASS with note "Area B skipped — within 7-day cadence limit."

sim-conductor result	pipeline-conductor verdict
0 M-tier findings across all personas	PASS
S/R-tier findings only	CONDITIONAL_PASS — capture finding list
1+ M-tier findings from any persona	FAIL
Persona results conflict, resolution requires human judgment	ESCALATE

---

Step 5. Aggregated Report

After all steps complete (or after chain halt), output the aggregated report (template in §Output-Formats).

Overall verdict logic:

Condition	Overall
All steps PASS	CLEAN ({mode})
Any step CONDITIONAL_PASS or accepted ESCALATE; none FAIL	PENDING
Any step FAIL or unresolved ESCALATE (option c)	BLOCKED

Mode semantics:

• CLEAN (--full): Safe to proceed with commit, PR, or external release.
• CLEAN (--quick) / CLEAN (--no-sim): Safe for internal iteration only — not sufficient for external publish or PR approval gate.
• PENDING: Resolve captured items before external release.
• BLOCKED: Do not proceed. Fix blocking items and re-run affected step(s).

Report persistence: save to tracks/_meta/pipeline_conductor_{YYYY-MM-DD}_{scope-slug}.md. If tracks/_meta/ does not exist, output a B-grade warning and skip persistence.

---

Resume After Fix

After FAIL:

1. User fixes the issue.
2. User says "resume from step N" or "re-run step N".
3. pipeline-conductor re-runs only the failed step and its gate.
4. On PASS, continues the chain from step N+1.
5. Does not re-run steps that already passed (unless user explicitly requests a full restart).

Resume is scope-bound — the scope from Step 0 is preserved across resume calls.

After ESCALATE: present the three options (see ESCALATE Handling above); (a) incorporate decision and continue, (b) mark PENDING and continue from N+1, (c) abort with BLOCKED report.

---

Simplification Guards

• Do not propose pipeline-conductor for single-file read tasks or exploratory sessions.
• If the user invokes one of the four constituent skills directly, do not auto-redirect to pipeline-conductor.
• If only one step is needed, guide the user to call that skill directly.
• For --quick mode on a trivial scope (single short SKILL.md), Steps 2+3 should complete in one pass without sub-Wave fan-out.

---

Chains

After a CLEAN (--full) or PENDING sweep, the following are natural follow-ons:

• field-harvest — harvest patterns surfaced during the sweep
• hub-cc-pr-reviewer — if sweep was run pre-PR, feed results into PR review
• agent-composer — if multiple fix tasks are needed across the Pending list, compose agents to resolve them in parallel
• return-path-gate --all — if Step 0.5 surfaced OPEN chains, run a full chain closure audit

Complexity Routing

complexity_routing:
  base: sonnet
  escalate_when:
    - high_stakes      # pre-external-publish or pre-deploy sweep
    - full_revalidation # user requested "start over"
    - cross_project    # scope spans 3+ projects
  high: opus

---

Done When

Step 0 scope confirmed and scope translation table applied
+ Step 0.5 return-path-gate pre-flight: PASS / CONDITIONAL_PASS / FAIL (halts sweep) / explicitly skipped / degraded (user override)
+ All in-scope steps executed and verdicts emitted
+ Aggregated report output (Step 5 format)
+ Report saved to tracks/_meta/ (or skip warning issued)
+ Overall verdict qualified with mode: CLEAN (--full) / CLEAN (--quick) / CLEAN (--no-sim) / PENDING / BLOCKED
+ If BLOCKED: blocking items listed and user notified
+ If PENDING: pending items listed in report
+ If ESCALATE occurred: user presented three options; choice recorded in report

Verdict: PASS (all conditions met, sweep complete) | CONDITIONAL_PASS (sweep complete, pending items captured) | FAIL (chain halted, blocking items remain) | ESCALATE (chain paused, human decision required)

A sweep is not done until the Step 5 report is output. Emitting per-step verdicts without the aggregated report is incomplete.

Completion-claim discipline (Ralph — no silent partial completion): the Step 5 report's overall verdict must enumerate, not assert — (a) evidence artifact: the per-step verdict source (report path + the verdict lines it aggregates); (b) failed + skipped checks listed by name (degraded / skipped / --quick-omitted steps included). This list is not self-asserted — reconcile it against the Step 0 in-scope step set: a list shorter than (in-scope − passed) is incomplete (an empty list is valid only when every in-scope step passed). This is the mechanical anchor that keeps the clause off a judge-only path; (c) explicit residual risk beyond what the mode-qualifier states (e.g. a single-skill scope is not a full-harness claim). A CLEAN verdict that omits any of the three is incomplete. (Convergent sister evidence: oh-my-claudecode Ralph "refuses silent partial completion"; Hermes Agent /goal per-turn completion judge.)