# Implementation plan

Status: proposed / accepted. Spec: path + revision. Execution authority: user instruction or accepted work item.

## Contract

Outcome, acceptance, non-goals, exact interfaces/schema, compatibility and permission invariants. Distinguish existing behavior from proposed behavior.

## Parts

| Key | Deliverable | Existing/new files | Depends on | Lane / worktree | Verification | Review checkpoint |
|---|---|---|---|---|---|---|
| A | One independently reviewable result | Explicit paths | None | Assigned context | Exact commands + expected behavior | Evidence + revision |
| B | Dependent result | Explicit paths | A accepted/integrated as required | Assigned context | Exact commands + environment | Evidence + revision |

Include shared resources: database, ports, schema, locks, build outputs and integration branch. Mark which are isolated and which are serialized.

## Per-part execution brief

Outcome; acceptance; spec/plan at revision; files/interfaces and bounded context; verification/environment; branch/base. Retain Invariants and Test matrix for sensitive or multi-surface work.

## Human gates

Open decision, authority required, self-contained question, evidence and resume step. Release actions have their own preflight, command, verification and rollback.

## Completion

Record implemented revision, checks and exit statuses, unresolved findings, accepted deliverable, integration state and release state separately. Keep attempts and repairs in the cost record.