/build-executor

name: build-executor
description: Govern implementation from an approved execution contract. Invoke when execution-contract.md is approved and the user wants disciplined build work, TDD execution, or guarded batch-by-batch implementation.

Build Executor

Controls the implementation phase. Uses `execution-contract.md` as the workflow authority.

Required Inputs

For Full or legacy Hotfix, read `execution-contract.md`, `tasks.md`, relevant `specs/`, and relevant `design.md`. Quick, direct incident Hotfix, and Tweak require only their receipt, request boundary, changed files, and verification command.

Check workflow mode and receipt first. Tweak → direct edit mode. Quick or a valid direct incident Hotfix → Direct Quick and Hotfix. Full or legacy Hotfix → standard contract-first discipline.

Branch/worktree preflight before ANY implementation edit (mandatory — do not skip): 1. Run the isolation check:

   ssf isolate <change-dir>

This script enforces git isolation: if you are on `main`/`master` it creates a git worktree (preferred) or a new branch, and exits non-zero if it cannot and you have not approved `--force`. 2. If `ssf isolate` exits non-zero: STOP. Do not edit `main`/`master` in place. Ask the user for explicit approval (and re-run with `ssf isolate <change-dir> --force` only after they approve). 3. If it succeeds, report the chosen branch/worktree and make all implementation edits there.

Core Laws

Law 1: Contract First (Full and legacy Hotfix)

For Full and legacy Hotfix, the execution contract is the approved handoff artifact, not chat history. Direct Quick and incident Hotfix use their valid direct receipt plus bounded verification instead; they must not create or require a contract.

Law 2: TDD Iron Law — Full and legacy Hotfix

RED (write test, see it fail) → GREEN (write minimal code, see it pass) → REFACTOR (clean up, suite stays green).

Quick follows the verification strategy persisted in its receipt: `tdd`, `new-test`, or `bounded` (targeted test, syntax/static check, or other stated evidence). A direct Hotfix must still demonstrate that the original symptom is gone.

**Red Flags**: ignoring the selected verification strategy, reporting a manual check as if it were automated evidence, or silently expanding a bounded Quick change. Full and legacy Hotfix still require RED → GREEN → REFACTOR.

Test Quality Reference

Before selecting or reviewing test evidence, read `skills/build-executor/writing-good-tests.md`. Apply its behavior-falsifiability rules to Full and legacy Hotfix work without changing the persisted Quick strategy or the Tweak boundary. Documentation-only work uses appropriate format, link, lint, or build evidence; do not require invented unit tests.

Law 3: Review Before Drift

Block on: logic defects, spec violations, missing required tests, unintended scope expansion.

Law 4: Rewind on Contract Break — Full and legacy Hotfix

Return to `specifying` or `bridging` if: new behavior appears, interfaces change materially, design assumptions fail, artifacts no longer define intended implementation.

For Quick/direct Hotfix, stop instead of creating or rewinding a contract; refresh `workflow recommend` with the observed risk, then select `full --confirm`.

Controller Continuity Protocol

This protocol is a host controller responsibility. The skill does not create autonomous background execution, retain control after a host turn ends, or guarantee that a dispatched subtask continues without the host.

• While an active subtask exists or a planned wave has a pending wave receipt,

the controller remains in execution. Send only concise commentary progress; do not send a final response or end the control turn as though the change were waiting for the user.

• On a user interruption or resume, first read `ssf execution show <change-dir>

--json` and the progress ledger at `.superpowers/sdd/progress.md`. Reconcile those records before dispatching anything, then continue the current eligible repair or eligible task according to the persisted plan. Do not restart a completed task, skip a retryable repair, or infer completion from chat text.

• A controller may end its control turn or request user input only when the

change is completed, an external blocker prevents meaningful progress, or user authorization is genuinely required. A dispatched task, pending review, or routine internal transition is not a terminal condition.

• Commentary must state the current wave/task, evidence or receipt status, and

the automatic next gate. It must not imply that the skill itself will run in the background after the host has ended the turn.

Planning-document boundary

Treat proposal, design, and tasks as reader-facing decision records. Do not add per-test RED/GREEN ritual, receipt paths, or dispatch scripts to them during implementation; keep that evidence in the execution contract, task brief, and review report. For a Full change, confirm that the one DP-2 blind-reader result is recorded before treating the contract as the implementation authority.

Execution Mode Selection

For Full or legacy Hotfix, generate proposed waves from the approved contract, then use the recommendation as a decision aid rather than silently defaulting a mode:

ssf execution recommend <change-dir> \
  --wave <wave-id>:<parallel|serial>:<task,...>[:<depends-on,...>] --json
# Show every available mode, the observed facts, and the recommendation to the user.
# The command writes a receipt tied to the artifacts, contract, and waves. After the user chooses, record that explicit confirmation:
ssf execution plan <change-dir> \
  --mode <selected-mode> --confirm --reason "user-selected execution mode" \
  --wave <wave-id>:<parallel|serial>:<task,...>[:<depends-on,...>]
# Add --acknowledge-recommendation when the selection differs from the recommendation.
ssf execution show <change-dir> --json

The optional fou