ultimate-pi 0.7.0 → 0.9.0

package/.pi/prompts/harness-auto.md

@@ -5,79 +5,54 @@ argument-hint: "\"<task>\" [--quick] [--risk low|med|high] [--budget <amount>]"
 
 # harness-auto
 
-Run full harness flow in one command:
-
-`plan -> execute -> evaluate -> adversary -> severity-policy decision -> commit+PR (no auto-merge)`
+Pipeline orchestrator — one session, sequential `Agent` spawns. Invoke **harness-orchestration** skill for agent IDs. Do **not** implement or review inline.
 
 ## Step 0 — Parse arguments
 
-Read `$ARGUMENTS` and normalize:
-
-- required task: quoted or unquoted first value
-- optional flags: `--quick`, `--risk low|med|high`, `--budget <amount>`
+- required task (quoted or first token)
+- optional: `--quick`, `--risk`, `--budget`
 
-If task is missing, stop and return:
+If task missing:
 
 `Usage: /harness-auto "<task>" [--quick] [--risk low|med|high] [--budget <amount>]`
 
-## Process contract
-
-1. Build and approve plan packet at the canonical active-run path before any mutation (extension allocates one `run_id` for the auto pipeline).
-2. Execute only approved scope with rollback artifacts.
-3. Run independent evaluator then adversarial reviewer.
-4. Apply severity policy + strict pre-PR gates.
-5. If gates pass, auto-commit and open PR; never auto-merge.
-
-## Locked decisions (must not be changed)
-
-- Always produce a plan packet before mutation.
-- Adversarial review is always required.
-- Merge blocking authority is severity-policy-engine.
-- Router tuning is propose-and-approve only.
-- Plan ambiguity must use `ask_user` (harness-decisions skill) — no silent guessing.
-- Rollback artifact must be revert-commit-ready and include:
-  - revert command
-  - prepared revert branch
-  - patch bundle
-- Debate profile is aggressive with locked confidence weights:
-  - claim_quality=0.20
-  - reproducibility=0.40
-  - agreement=0.40
-- Strict pre-PR gate is mandatory.
-- Post-pass behavior is auto-commit and auto-open-PR.
-- Never auto-merge PR.
-
-## Guardrails
-
-- Do not overthink straightforward gate outcomes; enforce gates deterministically.
-- Only follow the locked pipeline and governance decisions listed here.
-- Never bypass mandatory safety gates, even in `--quick` mode.
+## Orchestration (required) — same session
 
-## Strict gates
+1. **Plan** — spawn `harness/planner` → parse JSON → present full plan → `ask_user` Approve/Changes/Cancel → write `plan-packet.json` only on Approve (advances phase via policy-gate).
+2. **Execute** — spawn `harness/executor` with `HarnessSpawnContext` (`mode: execute`). Summarize handoff bullets for next spawn (do not paste full subagent log).
+3. **Eval** — spawn `harness/evaluator` (`mode: benchmark`) after parent scripts if needed.
+4. **Review** — spawn `harness/evaluator` (`mode: verdict`) OR rely on eval verdict if policy allows — prefer both when strict gates require.
+5. **Adversary** — spawn `harness/adversary` with artifact paths.
+6. **Tie-breaker** — spawn `harness/tie-breaker` only if debate unresolved.
+7. **Parent** — apply locked strict gates below; commit/PR only if all pass.
 
-Block commit/PR if any gate fails:
+No new Pi session for review — subagents use isolated context (`inherit_context: false`).
 
-1. Plan gate passed.
-2. Execution completed within approved scope.
-3. Independent evaluator passed.
-4. Adversarial review completed with consensus packet.
-5. Severity-policy-engine output is `pass` or `conditional_pass`.
-6. Benchmark delta checks passed.
-7. Rollback artifacts generated.
+## Locked decisions (do not change)
 
-## Notes
+- Always produce and approve plan before mutation.
+- Adversarial review always required.
+- Severity-policy-engine blocks merge.
+- Router tuning propose-and-approve only.
+- Plan ambiguity → parent `ask_user` (harness-decisions).
+- Rollback artifacts: revert command, revert branch, patch bundle.
+- Debate weights: claim_quality=0.20, reproducibility=0.40, agreement=0.40.
+- Strict pre-PR gate mandatory; auto-commit + open PR; never auto-merge.
 
-- `--quick` may reduce breadth, never safety gates.
-- `--risk` can tighten behavior, never disable adversary.
-- If risk/ambiguity is high, auto-fallback to manual `harness-plan` and use `ask_user` for blocking forks.
-- If execution must be interrupted safely, run `/harness-abort [reason]`, then restart with `/harness-plan "<task>"`.
-- Always output artifact references (`plan`, `eval`, `adversary`, `consensus`, `rollback`) and incident paths when applicable — do not ask the user to copy a run id; point to `/harness-run-status` or `/harness-trace-last` for phase handoff.
+## Strict gates
+
+Block commit/PR if any fails: plan gate, execution in scope, evaluator pass, adversary complete, severity-policy pass/conditional_pass, benchmark deltas, rollback artifacts.
+
+## Notes
 
-## Completion behavior
+- `--quick` reduces breadth, never safety gates.
+- High risk/ambiguity → stop and recommend manual `/harness-plan` with `ask_user`.
+- Interrupt: `/harness-abort [reason]` then `/harness-plan`.
+- Artifact refs under active run dir; `/harness-run-status` or `/harness-trace-last` for handoff.
 
-End with a deterministic handoff block:
+## Completion
 
-1. `Pipeline status` (pass/fail per strict gate).
-2. Phase trace summary and artifact references (`plan`, `eval`, `adversary`, `consensus`, `rollback`) under the active run directory.
-3. `Policy outcome` (`pass`, `conditional_pass`, `block`, or `human_required`) with one-line rationale.
-4. `Next action` (open PR, replan, rollback, or human override path).
+1. Pipeline status per gate
+2. Artifact references
+3. Policy outcome: `pass`, `conditional_pass`, `block`, or `human_required`
+4. Next action (PR, replan, rollback, override)

package/.pi/prompts/harness-critic.md

@@ -5,46 +5,33 @@ argument-hint: "[--run <run-id>] [--trace <trace-ref>] [--risk low|med|high]"
 
 # harness-critic
 
-Run adversarial review against the candidate result.
+Orchestrator — spawn `harness/adversary`.
 
 ## Step 0 — Parse arguments
 
-Read `$ARGUMENTS` and parse:
-
 - optional: `--run <run-id>` (recovery only)
 - optional: `--trace <trace-ref>`, `--risk low|med|high`
 
-On the happy path, **omit `--run`**. Use active run context. Prefer a session isolated from execute.
-
-## Process
-
-1. Assume hidden regressions exist and identify likely fault surfaces.
-2. Challenge evaluator/executor assumptions with reproducible probes.
-3. Emit structured adversarial findings for severity policy consumption.
-
-## Requirements
+Happy path: omit `--run`.
 
-- Assume hidden regressions exist until disproven.
-- Attempt to invalidate evaluator assumptions with concrete evidence.
-- Emit `AdversaryReport` matching `.pi/harness/specs/adversary-report.schema.json`.
-- Flag `block_merge=true` for high-confidence correctness/security/test-integrity risks.
+## Orchestration (required)
 
-## Guardrails
+1. Build `HarnessSpawnContext` with `mode: adversary`, run artifacts, plan path, trace refs.
+2. Spawn:
 
-- Do not overthink speculative attacks; prioritize reproducible findings.
-- Only report risks tied to candidate behavior and gate policy.
-- Never claim a defect without evidence and repro steps.
+```
+Agent({ subagent_type: "harness/adversary", prompt: "…" })
+```
 
-## Output
+3. `get_subagent_result` — parse `AdversaryReport` JSON; parent persists for severity policy.
 
-- Prioritized findings with repro steps.
-- Structured `AdversaryReport` JSON.
-- Clear merge-block recommendation.
+## Parent rules
 
-## Completion behavior
+- Assume hidden regressions until disproven (in subagent).
+- No new Pi session required.
 
-Always end with:
+## Completion
 
 - `block_merge` decision
-- top 1-3 high-confidence findings with repro pointers
-- explicit recommendation (`proceed`, `conditional_pass`, or `block`)
+- Top findings with repro pointers
+- `recommendation`: `proceed`, `conditional_pass`, or `block`

package/.pi/prompts/harness-eval.md

@@ -5,47 +5,39 @@ argument-hint: "[--run <run-id>] [--baseline <ref>] [--suite <name>]"
 
 # harness-eval
 
-Run focused evaluations for the active harness run and produce structured artifacts.
+Orchestrator — run deterministic scripts in parent if needed, then spawn `harness/evaluator` with `mode: benchmark`.
 
 ## Step 0 — Parse arguments
 
-Read `$ARGUMENTS` and parse:
-
-- optional: `--run <run-id>` (recovery only — active run is used when omitted)
+- optional: `--run <run-id>` (recovery only)
 - optional: `--baseline <ref>`, `--suite <name>`
 
-On the happy path, **omit `--run`**. The extension injects the active run from session + project `active-run.json`.
+Happy path: omit `--run`; use active run from `[HarnessRunContext]`.
 
-If no active run exists, stop and return:
+If no active run:
 
 `No active run. Finish /harness-plan and /harness-run first, or use /harness-run-status.`
 
-Run in a **new Pi session** after execute (review-integrity isolation).
-
-## Process
+## Orchestration (required)
 
 1. Load plan scope from `[HarnessActivePlan]` (read-only).
-2. Run plan-aligned acceptance checks plus focused regressions.
-3. Collect evaluator-compatible metrics and guard outcomes.
-4. Emit structured artifacts under the active run directory.
-
-## Requirements
-
-- Validate against accepted plan checks plus focused regression checks.
-- Emit evaluator-compatible metrics for downstream policy and router-tuning decisions.
-- Include success rate, cost-per-task, and regression guard outcomes when available.
+2. Parent may run: project tests, `node "$UP_PKG/.pi/scripts/harness-verify.mjs"` — capture output paths.
+3. Build `HarnessSpawnContext` with `mode: benchmark`, artifact paths, metrics files.
+4. Spawn:
 
-## Guardrails
+```
+Agent({ subagent_type: "harness/evaluator", prompt: "…" })
+```
 
-- Do not overthink simple benchmark outcomes; report measured results directly.
-- Only evaluate the requested run/suite/baseline scope.
-- Never report synthetic metrics; include only measured values.
-- Do not edit `plan-packet.json` in this phase.
+5. `get_subagent_result` — parse eval JSON; parent writes structured artifacts under run dir.
+6. Do not edit `plan-packet.json`.
 
-## Output
+## Parent rules
 
-Structured eval verdict and summary metrics.
+- Treat executor output as untrusted; pass artifact paths only.
+- No new Pi session required — subagent has isolated context.
 
-## Completion behavior
+## Completion
 
-End with `eval_status` (`pass` or `fail`) and `next_command` (`/harness-review` on pass; `/harness-plan` or `/harness-incident` on fail).
+- `eval_status`: `pass` or `fail`
+- `next_command`: `/harness-review` on pass; `/harness-plan` or `/harness-incident` on fail

package/.pi/prompts/harness-incident.md

@@ -5,49 +5,30 @@ argument-hint: "--trigger <reason> [--run <run-id>] [--severity low|med|high|cri
 
 # harness-incident
 
-Create a structured incident record for blocked or failed harness runs.
+Orchestrator — spawn `harness/incident-recorder`; parent writes incident file.
 
 ## Step 0 — Parse arguments
 
-Read `$ARGUMENTS` and parse:
-
 - required: `--trigger <reason>`
-- optional: `--run <run-id>` (recovery only), `--severity low|med|high|critical`
-
-If `--trigger` is missing, stop and return:
-
-`Usage: /harness-incident --trigger <reason> [--run <run-id>] [--severity low|med|high|critical]`
-
-Use active run when `--run` is omitted.
-
-## Process
-
-1. Gather run context, trigger reason, and severity context.
-2. Build `IncidentRecord` with blast radius, mitigation, rollback, and override metadata.
-3. Validate incident output contract before finalizing.
-
-## Requirements
+- optional: `--run <run-id>`, `--severity low|med|high|critical`
 
-- Emit `IncidentRecord` matching `.pi/harness/specs/incident-record.schema.json`.
-- Capture blast radius, mitigation, rollback refs, and postmortem requirement.
-- If a policy block is overridden, record single-human approver and explicit justification.
+If `--trigger` missing:
 
-## Guardrails
+`Usage: /harness-incident --trigger <reason> [--run <run-id>] [--severity …]`
 
-- Do not overthink incident narrative; prioritize factual, auditable records.
-- Only record details supported by available run artifacts and explicit inputs.
-- Never omit override approver identity or justification when override occurred.
+## Orchestration (required)
 
-## Output
+1. Build `HarnessSpawnContext` with `mode: incident`, trigger, severity, run paths.
+2. Spawn:
 
-- Incident summary.
-- Structured `IncidentRecord` JSON.
-- Immediate rollback decision trail.
+```
+Agent({ subagent_type: "harness/incident-recorder", prompt: "…" })
+```
 
-## Completion behavior
+3. `get_subagent_result` — validate `IncidentRecord` draft; parent writes under `.pi/harness/incidents/`.
 
-Finish with:
+## Completion
 
-- `incident_status` (`recorded` or `needs_input`)
-- rollback action (`execute_now` or `standby`)
-- postmortem requirement (`true`/`false`)
+- `incident_status`: `recorded` or `needs_input`
+- `rollback_action`: `execute_now` or `standby`
+- `postmortem_required`: true/false

package/.pi/prompts/harness-plan.md

@@ -5,75 +5,54 @@ argument-hint: "\"<task>\" [--risk low|med|high] [--budget <amount>] [--quick]"
 
 # harness-plan
 
-Create a machine-readable plan packet before execution.
+Orchestrator only — spawn `harness/planner` once; planner runs clarification and approval via `ask_user` (parent UI). Write `plan-packet.json` only after approval. Do **not** plan inline in this session.
 
 ## Step 0 — Parse arguments
 
-Read `$ARGUMENTS` and parse:
+Read `$ARGUMENTS`:
 
 - task statement (required)
-- optional flags: `--risk low|med|high`, `--budget <amount>`, `--quick`
+- optional: `--risk low|med|high`, `--budget <amount>`, `--quick`
 
-If task is missing, stop and return:
+If task is missing:
 
 `Usage: /harness-plan "<task>" [--risk low|med|high] [--budget <amount>] [--quick]`
 
-Do **not** require or accept `--plan` on this command.
+`--quick` narrows planning breadth only — it does **not** skip user approval.
 
 ## Active plan context
 
-If `[HarnessActivePlan]` is present in context:
+Use injected context only — **do not** read `.pi/harness/specs/*.schema.json` or explore specs with bash.
 
-- Read the current PlanPacket from the injected `plan_packet_path` first.
-- Treat the user task as **revise/amend** of that packet (not a greenfield plan), unless `/harness-new-run` was used.
-- After drift replan or post-abort, update the same canonical file.
+If `[HarnessActivePlan]` is present:
 
-If no prior plan file exists, create PlanPacket at the canonical path from `[HarnessRunContext]`.
+- Treat task as **revise/amend** unless `/harness-new-run` was used.
+- Pass `mode: revise` using the `HarnessSpawnContext` JSON in `[HarnessRunContext]`.
 
-## Process
+Otherwise use `HarnessSpawnContext` from `[HarnessRunContext]` for greenfield `mode: create`.
 
-1. Parse the requested task and extract concrete scope and constraints.
-2. If ambiguity blocks safe execution planning, call `ask_user` (harness-decisions skill). Stop with `needs_clarification` if the user cancels.
-3. Build a `PlanPacket` that is valid against `.pi/harness/specs/plan-packet.schema.json`.
-4. **Write** the PlanPacket JSON to the canonical `plan_packet_path` before completing.
-5. Include rollback artifacts in all required forms.
+## Orchestration (required)
 
-## Hard requirements
+1. Copy the `HarnessSpawnContext=…` JSON from `[HarnessRunContext]` into the spawn prompt (adjust `risk_level`, `quick`, `mode` from `$ARGUMENTS` if needed).
+2. Spawn **once** with **`inherit_context: false`**:
 
-- Do not run mutating tools in this command.
-- If task scope is ambiguous, call `ask_user` — do not guess or use prose-only clarification.
-- Produce a `PlanPacket` matching `.pi/harness/specs/plan-packet.schema.json`.
-- Include rollback artifacts in all three forms:
-  - revert command
-  - prepared revert branch name
-  - patch bundle path
-- Set risk level to `high` if uncertainty, broad blast radius, or policy-sensitive surfaces are involved.
-- Do **not** embed `plan_id=` in the user prompt for policy sync — the extension sets `approvedPlan` from the written file.
+```
+Agent({ subagent_type: "harness/planner", prompt: "<task + HarnessSpawnContext JSON + output schema>" })
+```
 
-## Guardrails
+3. `get_subagent_result` — parse final JSON (`status`, `plan_packet`, `human_summary`, `clarification`) via fenced `json` block.
+4. If `status === "ready"` and user approved in the subagent (`ask_user` Approve), validate `plan_packet` fields, then **write** `PlanPacket` JSON to canonical `plan_packet_path` from `[HarnessRunContext]`.
+5. If `needs_clarification`, tell the user the planner is waiting — do **not** re-spawn; user should answer in the subagent or re-run `/harness-plan`.
+6. Do **not** call `ask_user` in this parent session for planner clarification or approval.
 
-- Do not overthink straightforward planning requests.
-- Only plan the requested scope; do not execute or widen implementation.
-- Never speculate about code or configuration that was not read.
+## Parent rules
 
-## Output contract
+- Do not mutate project source files — only `plan-packet.json` after subagent approval is recorded.
+- Do not embed `plan_id=` in prompts for policy sync.
+- Optional: `/harness-plan-commit` if write was blocked but approval exists.
 
-Return:
+## Completion
 
-1. Human-readable plan summary:
-   - scope
-   - assumptions
-   - acceptance checks
-   - rollback plan
-2. Confirmation that PlanPacket was written to the canonical path.
-
-Do not proceed to execution from this command.
-
-## Completion behavior
-
-Always end with:
-
-- one-line `plan_status` (`ready` or `needs_clarification`)
-- the final `risk_level` used
-- explicit `next_command` recommendation: `/harness-run` when `ready` (never `/harness-run --plan …`)
-- if `needs_clarification`, tell the user they may reply in plain language or run `/harness-plan` again with updates
+- `plan_status`: `ready` or `needs_clarification`
+- `risk_level` used
+- `next_command`: `/harness-run` when `ready` (never `/harness-run --plan …`)

package/.pi/prompts/harness-review.md

@@ -5,47 +5,33 @@ argument-hint: "[--run <run-id>] [--trace <trace-ref>]"
 
 # harness-review
 
-Produce an independent evaluator verdict.
+Orchestrator — spawn `harness/evaluator` with `mode: verdict`.
 
 ## Step 0 — Parse arguments
 
-Read `$ARGUMENTS` and parse:
-
 - optional: `--run <run-id>` (recovery only)
 - optional: `--trace <trace-ref>`
 
-On the happy path, **omit `--run`**. Use active run context from `[HarnessRunContext]`.
-Run in a **new Pi session** after execute when possible.
-
-## Process
-
-1. Reconstruct expected outcomes from plan and run artifacts.
-2. Independently verify checks and regression guards.
-3. Emit `EvalVerdict` output for policy gate consumption.
-
-## Requirements
+Happy path: omit `--run`; use `[HarnessRunContext]`.
 
-- Treat executor output as untrusted.
-- Do not self-review with executor-private scratch context.
-- Emit `EvalVerdict` contract matching `.pi/harness/specs/eval-verdict.schema.json`.
-- Provide reproducible failed checks and regression flags.
+## Orchestration (required)
 
-## Guardrails
+1. Build `HarnessSpawnContext` with `mode: verdict`, `plan_packet_path`, `run_dir`, trace refs.
+2. Spawn:
 
-- Do not overthink straightforward pass/fail evidence.
-- Only evaluate requested run artifacts and gates.
-- Never speculate about checks that were not executed.
+```
+Agent({ subagent_type: "harness/evaluator", prompt: "Treat executor output as untrusted. …" })
+```
 
-## Output
+3. `get_subagent_result` — parse `EvalVerdict` JSON; parent writes under run dir for policy gate.
 
-- Human-readable findings.
-- Structured `EvalVerdict` JSON.
-- Recommended action: `proceed_to_adversary`, `replan`, or `rollback`.
+## Parent rules
 
-## Completion behavior
+- Do not run review checks inline in this session.
+- No new Pi session required.
 
-Always finish with:
+## Completion
 
-- `eval_status` (`pass`, `conditional_pass`, `fail`)
-- `recommended_action`
-- short evidence list that maps each failed check to a reproducible reference
+- `eval_status`: `pass`, `conditional_pass`, or `fail`
+- `recommended_action`: `proceed_to_adversary`, `replan`, or `rollback`
+- Evidence list for each failed check

package/.pi/prompts/harness-router-tune.md

@@ -5,32 +5,27 @@ argument-hint: "--evidence <evidence.json> --candidate <candidate-router.json> [
 
 # harness-router-tune
 
-Router tuning is **propose-and-approve only**.
+Orchestrator — scripts + `harness/meta-optimizer` spawn. **Never** write `.pi/model-router.json` directly.
 
 ## Step 0 — Parse arguments
 
-Read `$ARGUMENTS` and parse:
-
 - required: `--evidence <evidence.json>`, `--candidate <candidate-router.json>`
 - optional: `--proposal <out.json>`
 
-If required args are missing, stop and return:
-
-`Usage: /harness-router-tune --evidence <evidence.json> --candidate <candidate-router.json> [--proposal <out.json>]`
-
-## Process
+If missing required args:
 
-1. Validate evidence completeness and guard status. Evidence may live under `.pi/harness/runs/<run_id>/` for the active harness run when produced by `/harness-eval` (resolve via active run context or explicit paths — no run id required on the happy path).
-2. Generate a proposal artifact only (no live router mutation).
-3. Require explicit human approval metadata before any apply step.
+`Usage: /harness-router-tune --evidence <path> --candidate <path> [--proposal <out.json>]`
 
-## Never-do rule
+## Orchestration (required)
 
-- Never write `.pi/model-router.json` directly from this command.
+1. Parent validates evidence paths exist.
+2. Optionally spawn:
 
-## Proposal flow
+```
+Agent({ subagent_type: "harness/meta-optimizer", prompt: "mode: tune, evidence paths…" })
+```
 
-1. Build proposal:
+3. Parent runs proposal script:
 
 ```bash
 node .pi/harness/router/propose-router-tuning.mjs \
@@ -39,8 +34,8 @@ node .pi/harness/router/propose-router-tuning.mjs \
   --proposal-out .pi/harness/router/proposals/<id>.json
 ```
 
-2. Call `ask_user` to approve / reject / request edits before apply (harness-decisions skill).
-3. Apply only after approval, with explicit approver + justification:
+4. `ask_user` approve / reject / edit (harness-decisions).
+5. Apply only after approval:
 
 ```bash
 node .pi/harness/router/apply-router-proposal.mjs \
@@ -50,25 +45,8 @@ node .pi/harness/router/apply-router-proposal.mjs \
   --write
 ```
 
-## Evidence requirements
-
-- Minimum sample count threshold met.
-- Pre/post success-rate delta included.
-- Cost-per-task delta included.
-- Regression guard status present and passing.
-
-If any requirement is missing, stop with `human_required`.
-
-## Guardrails
-
-- Do not overthink weak evidence; reject incomplete proposals quickly.
-- Only produce proposal/apply instructions within this contract.
-- Never apply tuning without explicit human approver identity and justification.
-
-## Completion behavior
-
-End with:
+## Completion
 
-- `tuning_status` (`proposed`, `human_required`, or `rejected`)
-- evidence gate summary (sample count, success delta, cost delta, regression guard)
-- explicit non-mutation confirmation for `.pi/model-router.json`
+- `tuning_status`: `proposed`, `human_required`, or `rejected`
+- Evidence gate summary
+- Confirm `.pi/model-router.json` was not mutated without apply script

package/.pi/prompts/harness-run.md

@@ -5,56 +5,39 @@ argument-hint: "[--budget <amount>]"
 
 # harness-run
 
-Execute implementation only after an approved plan exists in active run context.
+Orchestrator only — spawn `harness/executor`. Do **not** implement inline.
 
 ## Step 0 — Parse arguments
 
-Read `$ARGUMENTS` and parse:
-
 - optional: `--budget <amount>`
+- Do **not** use `--plan` on happy path — load from `[HarnessActivePlan]` / `plan_packet_path`.
 
-Do **not** parse `--plan` on the happy path. Load the PlanPacket from `[HarnessActivePlan]` / injected `plan_packet_path` only.
-
-If the extension reports plan not ready, stop and return:
+If plan not ready:
 
 `Run /harness-plan first — no approved plan in active run context.`
 
-Advanced recovery only: `--plan <path>` must live under the active run directory (extension validates).
-
-## Process
-
-1. Load PlanPacket from the injected canonical path and confirm it is valid.
-2. Execute only within approved scope.
-3. Run focused validations mapped to approved acceptance checks.
-4. Produce rollback artifacts and handoff references for downstream gates.
-
-## Gate behavior
-
-- Refuse execution if active plan is not ready (extension blocks before the agent runs).
-- Keep edits strictly within approved scope.
-- If scope drift appears, stop and return to `harness-plan`.
-- For **implementation forks** inside approved scope, call `ask_user` with 2–4 options. For plan-level ambiguity, stop and return to `harness-plan`.
-- Record evaluator/adversary prerequisites for downstream gates.
-- Always prepare rollback artifacts as part of execution output.
+## Orchestration (required)
 
-## Guardrails
+1. Confirm `[HarnessActivePlan]` / extension reports plan ready.
+2. Build `HarnessSpawnContext` with `mode: execute`, `plan_packet_path`, `run_dir`, `acceptance_checks` from plan file.
+3. Spawn:
 
-- Do not overthink straightforward approved changes; execute the approved scope directly.
-- Only modify files and behaviors covered by the approved `PlanPacket`.
-- Never speculate about successful validation without runnable evidence.
+```
+Agent({ subagent_type: "harness/executor", prompt: "<HarnessSpawnContext + handoff>" })
+```
 
-## Output
+4. `get_subagent_result` — parse executor JSON (`execution_status`, validations, rollback refs).
+5. Parent persists trace/handoff artifacts under run dir if needed; do not self-review.
 
-- Implementation summary scoped to approved plan.
-- Files changed and why.
-- Targeted validations run.
-- Trace pointers and rollback references.
+## Parent rules
 
-## Completion behavior
+- Refuse if plan not approved.
+- On `scope_drift`, stop and recommend `/harness-plan`.
+- Do not call `ask_user` for plan-level ambiguity — return to plan command.
 
-End with:
+## Completion
 
-1. `execution_status` (`completed`, `blocked`, or `scope_drift`).
-2. `validation_summary` (pass/fail with command evidence).
-3. `handoff_ready` booleans for evaluator/adversary prerequisites.
-4. `next_command`: **New Pi session → `/harness-eval`** when execution completed successfully.
+- `execution_status`: `completed`, `blocked`, or `scope_drift`
+- `validation_summary` with command evidence
+- `handoff_ready` for evaluator/adversary
+- `next_command`: `/harness-eval` (same session — spawn isolated review agents; no new Pi session)