ultimate-pi 0.6.1 → 0.8.0

package/.pi/lib/harness-ui-state.ts

@@ -1,4 +1,4 @@
-import type { ExtensionContext } from "@mariozechner/pi-coding-agent";
+import type { ExtensionContext } from "@earendil-works/pi-coding-agent";
 
 export type HarnessPhase =
 	| "plan"
@@ -97,6 +97,7 @@ export interface HarnessUiState {
 		testIntegrity: number | null;
 	};
 	traceRunId: string | null;
+	nextRecommendedCommand: string | null;
 }
 
 const DEFAULT_STATE: HarnessUiState = {
@@ -123,6 +124,7 @@ const DEFAULT_STATE: HarnessUiState = {
 		testIntegrity: null,
 	},
 	traceRunId: null,
+	nextRecommendedCommand: null,
 };
 
 const RELEVANT_CUSTOM_TYPES = new Set([
@@ -135,6 +137,7 @@ const RELEVANT_CUSTOM_TYPES = new Set([
 	"harness-test-integrity-flag",
 	"harness-run-trace",
 	"harness-trace-state",
+	"harness-run-context",
 ]);
 
 function asNumber(value: unknown): number | null {
@@ -284,6 +287,14 @@ function createStateFromEntries(entries: unknown[]): HarnessUiState {
 				? traceState.run_id
 				: null;
 
+	const runCtx = latest.get("harness-run-context") as
+		| { next_recommended_command?: string }
+		| undefined;
+	state.nextRecommendedCommand =
+		typeof runCtx?.next_recommended_command === "string"
+			? runCtx.next_recommended_command
+			: null;
+
 	state.flowSubstate = deriveFlowSubstate(state);
 	return state;
 }

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

@@ -13,8 +13,9 @@ Safely abort the current harness run in this session.
   - `phase: plan`
   - `approvedPlan: false`
   - `planId: null`
-- records abort metadata for observability.
-- enables a hard safety lock that blocks mutating tools until a new approved plan is attached.
+- clears active run `plan_ready` (plan files may remain on disk for forensics)
+- records abort metadata for observability
+- enables a hard safety lock that blocks mutating tools until a new approved plan is attached
 
 ## Usage
 
@@ -27,8 +28,8 @@ Examples:
 
 ## Safety guarantees
 
-- no mutating work should continue under the previous run context.
-- a fresh approved plan is required before mutation can resume.
+- no mutating work should continue under the previous run context
+- a fresh approved plan is required before mutation can resume
 
 ## Next step
 
@@ -36,6 +37,8 @@ Run:
 
 `/harness-plan "<task>"`
 
-Then proceed with:
+Then:
 
-`/harness-run --plan <path-to-plan-packet.json>`
+`/harness-run`
+
+(No `--plan` or run id required — the harness restores active context after replan.)

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 before any mutation.
-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 trace bundle ID and incident/rollback references.
+## 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. `Trace bundle` and artifact references (`plan`, `eval`, `adversary`, `consensus`, `rollback`).
-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

@@ -1,52 +1,37 @@
 ---
 description: Adversarial reviewer command with reproducible, merge-blocking findings.
-argument-hint: "--run <run-id> [--trace <trace-ref>] [--risk low|med|high]"
+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:
-
-- required: `--run <run-id>`
+- optional: `--run <run-id>` (recovery only)
 - optional: `--trace <trace-ref>`, `--risk low|med|high`
 
-If `--run` is missing, stop and return:
-
-`Usage: /harness-critic --run <run-id> [--trace <trace-ref>] [--risk low|med|high]`
-
-## 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

@@ -1,51 +1,43 @@
 ---
 description: Run focused benchmark/eval checks and emit structured harness verdict artifacts.
-argument-hint: "--run <run-id> [--baseline <ref>] [--suite <name>]"
+argument-hint: "[--run <run-id>] [--baseline <ref>] [--suite <name>]"
 ---
 
 # harness-eval
 
-Run focused evaluations for the 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:
-
-- required: `--run <run-id>`
+- optional: `--run <run-id>` (recovery only)
 - optional: `--baseline <ref>`, `--suite <name>`
 
-If `--run` is missing, stop and return:
-
-`Usage: /harness-eval --run <run-id> [--baseline <ref>] [--suite <name>]`
-
-## Process
+Happy path: omit `--run`; use active run from `[HarnessRunContext]`.
 
-1. Run plan-aligned acceptance checks plus focused regressions.
-2. Collect evaluator-compatible metrics and guard outcomes.
-3. Emit structured artifacts keyed by run ID.
+If no active run:
 
-## Requirements
+`No active run. Finish /harness-plan and /harness-run first, or use /harness-run-status.`
 
-- 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.
+## Orchestration (required)
 
-## Guardrails
+1. Load plan scope from `[HarnessActivePlan]` (read-only).
+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:
 
-- 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.
+```
+Agent({ subagent_type: "harness/evaluator", prompt: "…" })
+```
 
-## Output
+5. `get_subagent_result` — parse eval JSON; parent writes structured artifacts under run dir.
+6. Do not edit `plan-packet.json`.
 
-- Benchmark/eval summary table.
-- Structured verdict artifacts referenced by run ID.
-- Pass/fail recommendation for policy gate consumption.
+## Parent rules
 
-## Completion behavior
+- Treat executor output as untrusted; pass artifact paths only.
+- No new Pi session required — subagent has isolated context.
 
-End with a compact evaluator handoff:
+## Completion
 
-- measured metrics (`success_rate`, `cost_per_task`, regression guard status)
-- verdict (`pass`/`fail`)
-- artifact paths keyed by run ID
+- `eval_status`: `pass` or `fail`
+- `next_command`: `/harness-review` on pass; `/harness-plan` or `/harness-incident` on fail

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

@@ -1,51 +1,34 @@
 ---
 description: Create incident record with rollback and override trail for harness failures.
-argument-hint: "--run <run-id> --trigger <reason> [--severity low|med|high|critical]"
+argument-hint: "--trigger <reason> [--run <run-id>] [--severity low|med|high|critical]"
 ---
 
 # 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>`, `--severity low|med|high|critical`
 
-- required: `--run <run-id>`, `--trigger <reason>`
-- optional: `--severity low|med|high|critical`
+If `--trigger` missing:
 
-If required flags are missing, stop and return:
+`Usage: /harness-incident --trigger <reason> [--run <run-id>] [--severity …]`
 
-`Usage: /harness-incident --run <run-id> --trigger <reason> [--severity low|med|high|critical]`
+## Orchestration (required)
 
-## Process
+1. Build `HarnessSpawnContext` with `mode: incident`, trigger, severity, run paths.
+2. Spawn:
 
-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.
+```
+Agent({ subagent_type: "harness/incident-recorder", prompt: "…" })
+```
 
-## Requirements
+3. `get_subagent_result` — validate `IncidentRecord` draft; parent writes under `.pi/harness/incidents/`.
 
-- 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.
+## Completion
 
-## Guardrails
-
-- 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.
-
-## Output
-
-- Incident summary.
-- Structured `IncidentRecord` JSON.
-- Immediate rollback decision trail.
-
-## Completion behavior
-
-Finish with:
-
-- `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,60 +5,56 @@ 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`, present draft, run `ask_user`, write plan after Approve. 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]`
 
-## Process
+`--quick` narrows planning breadth only — it does **not** skip user approval.
 
-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. Include rollback artifacts in all required forms.
+## Active plan context
 
-## Hard requirements
+If `[HarnessActivePlan]` is present:
 
-- 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.
+- Read current packet from `plan_packet_path` first.
+- Treat task as **revise/amend** unless `/harness-new-run` was used.
+- Pass `mode: revise` in spawn context.
 
-## Guardrails
+Otherwise use canonical path from `[HarnessRunContext]` for greenfield `mode: create`.
 
-- 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.
+## Orchestration (required)
 
-## Output contract
+1. Build `HarnessSpawnContext` JSON (`.pi/harness/specs/harness-spawn-context.schema.json`) from injected run/plan context: `run_id`, `plan_packet_path`, `task_summary`, `risk_level`, `quick`, `mode`.
+2. Spawn with **`inherit_context: false`**:
 
-Return:
+```
+Agent({ subagent_type: "harness/planner", prompt: "<task + HarnessSpawnContext JSON + output schema>" })
+```
 
-1. Human-readable plan summary:
-   - scope
-   - assumptions
-   - acceptance checks
-   - rollback plan
-2. A valid JSON `PlanPacket` object.
+3. `get_subagent_result` — parse final JSON (`status`, `plan_packet`, `human_summary`, `clarification`) via fenced `json` block.
+4. If `needs_clarification`, call `ask_user` (harness-decisions) with planner `clarification.options`, then re-spawn with answers.
+5. Present **full** human-readable plan in chat (scope, assumptions, acceptance_checks, rollback_plan, risk_level).
+6. Call `ask_user`: **Approve** / **Request changes** / **Cancel** (harness-decisions). **Do not write** until Approve.
+7. On **Request changes**, re-spawn planner with `mode: revise` and user feedback — do not write file.
+8. **Only after Approve** — write `PlanPacket` JSON to canonical `plan_packet_path`.
 
-Do not proceed to execution from this command.
+## Parent rules
 
-## Completion behavior
+- Do not mutate project source files — only `plan-packet.json` after approval.
+- Validate draft against `.pi/harness/specs/plan-packet.schema.json` before `ask_user` Approve.
+- Do not embed `plan_id=` in prompts for policy sync.
 
-Always end with:
+## Completion
 
-- one-line `plan_status` (`ready` or `needs_clarification`)
-- the final `risk_level` used
-- explicit `next_command` recommendation (`/harness-run --plan ...` or clarification request)
+- `plan_status`: `ready` or `needs_clarification`
+- `risk_level` used
+- `next_command`: `/harness-run` when `ready` (never `/harness-run --plan …`)
+- If `needs_clarification`, user may reply in chat or re-run `/harness-plan`

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

@@ -1,52 +1,37 @@
 ---
 description: Independent evaluator pass/fail verdict in session isolation mode.
-argument-hint: "--run <run-id> [--trace <trace-ref>]"
+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:
-
-- required: `--run <run-id>`
+- optional: `--run <run-id>` (recovery only)
 - optional: `--trace <trace-ref>`
 
-If `--run` is missing, stop and return:
-
-`Usage: /harness-review --run <run-id> [--trace <trace-ref>]`
-
-## 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.
-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