# Task Execution Protocol

Use this as the detailed end-to-end loop for implementation work.

## Phase 0: receive and bind

1. Read the current user request.
2. Identify explicit constraints, desired outcome, prohibited actions, and
   whether release/deployment is authorized.
3. Read applicable repository instructions before editing.
4. Inspect current workspace state enough to avoid trampling user work.
5. State the immediate approach in a short working update.

## Phase 1: discover

1. Search for the changed behavior, test, and primary caller.
2. Read the smallest source regions that define the contract.
3. Inspect current failures/logs when the task is a regression.
4. Form a testable hypothesis.
5. If discovery crosses independent areas, fan out and consolidate evidence.

Do not begin with broad speculative edits when the source/runtime contract is
still unknown.

## Phase 2: define proof

Before implementation, express:

```text
behavior now: <observed bad/current behavior>
behavior after: <required observable behavior>
regression boundary: <what must remain true>
proof: <focused test or direct observation>
```

If the repository already contains a test harness for the boundary, extend it.
If it does not, create the smallest harness that crosses the real changed path.

## Phase 3: implement

1. Apply a coherent patch.
2. Keep change scope narrow.
3. Preserve actual tool errors and source conflicts.
4. If a required assumption changes, return to discovery rather than layering
   defensive controller behavior over uncertainty.
5. Update/add the test that proves the intended behavior.

## Phase 4: verify and iterate

1. Run the focused test.
2. If it fails, inspect the exact failure and classify it:
   - incorrect implementation;
   - incorrect test expectation;
   - missing fixture/setup;
   - changed contract;
   - environmental failure.
3. Correct the smallest implicated component.
4. Rerun the focused test.
5. Run the required build and broader focused tests.
6. Mark proof stale after any later relevant mutation.

## Phase 5: review

Review the final diff as a user would:

- Does each changed file serve the requested outcome?
- Is the public/tool behavior simple and understandable?
- Did a controller or cache layer accidentally hide real evidence?
- Are tests behavioral enough to catch the original regression?
- Are operator-facing messages truthful and non-coercive?

## Phase 6: hand off

Report:

```text
Outcome
Changed behavior/files
Verification performed
Known limitation or intentionally unperformed action
```

Do not add a new release, restart, remote push, or unrelated cleanup step at
handoff unless it was requested and authorized.