execute-harness

Execute Harness

Run the task through an existing my-pi harness. Its outer policy is the runtime trust boundary; its versioned inner scaffold is an amendable execution plan subordinate to system, developer, and current user instructions.

Workflow

1. Resolve the harness directory from the user request or active harness context.
2. Read harness.json, SYSTEM.md, TASK.md, and status.json before editing.
3. Call harness_update with status: running and the current phase.
4. If the team tool is available and you are the team lead, create or reuse a team, create/claim a task for the harness, and use one member_spawn executor with mutating: true for file-editing work. Default to the contract cwd; use workspace_mode: worktree only when the user asks for isolation or the plan covers setup, runtime state, merge, and cleanup ownership.
5. The teammate prompt must tell it to read harness.json, SYSTEM.md, TASK.md, and status.json, execute only inside the contract, run validate.sh and review.sh, update harness evidence, and report changed files plus risks. If using a worktree, set HARNESS_CWD to that worktree for validation and review.
6. Recover any remaining source-of-truth context needed to act safely.
7. Execute surgically inside scaffold.allowed_paths. Use harness_amend for a bounded change inside the approved capability. If user direction or source evidence introduces a new capability, architecture decision, or outer-policy expansion, stop execution and enter assessment instead of silently expanding the harness. An approved harness recommendation may then amend the active scaffold.
8. Record decisions, phase changes, and validation evidence with harness_update, including team status and remaining risks when known.
9. Run <harness_dir>/validate.sh.
10. Run <harness_dir>/review.sh from the execution workspace. If using a linked worktree, run it from that worktree or set HARNESS_CWD to the worktree path.
11. Review <harness_dir>/OUTCOME.md or <harness_dir>/outcome.json for changed files, baseline ignored files, validation evidence, team status, and risks.
12. Mark completed only when validation passes and no escalation rule applies; otherwise mark failed with evidence. A terminal status seals the run and keeps its guard active for the remainder of the current turn. The extension deactivates it on the next direct user turn or session startup.