Resume multi-session implementation work across agents

Resumable Implementation Contracts turns a large, mostly defined request into a repository contract that can be read, updated, verified, and resumed after interruption. Stable intent is separated from mutable execution state, and completion requires supporting evidence. The pattern is tool-neutral: it does not configure or replace a platform's built-in goals, tasks, plans, or project features.

Logical ownership is divided among the implementation contract, task tracker, checkpoint, material decisions, and validation record. The contract owns intent, scope, acceptance, and completion conditions. Tasks own current status and dependencies; the checkpoint owns the authoritative position and exact next action. Decisions retain consequential choices and reasons, while validation records checks actually performed. The conventional filenames are IMPLEMENTATION_CONTRACT.md, TASKS.md, CHECKPOINT.md, DECISIONS.md, and VALIDATION.md, optionally grouped under docs/<contract-slug>/. Existing equivalent documents should be reused rather than duplicated or renamed to fit a template.

Use it for work crossing sessions, branches, or context windows, especially when dependencies and acceptance must survive interruption. It also fits work that can appear complete before runtime, artifact, interface, or test evidence exists. Preserving partial and unrelated repository changes is part of the resume discipline.

Skip the full layout for a small task completed and verified in one session. Unsettled product intent needs resolution before freezing the contract. This pattern does not replace discovery, detailed design, project-wide state governance, or retrospective auditing.

Inputs are the objective, observable outcomes, baseline, constraints, authorized scope, dependencies, acceptance checks, interruption rules, and final handoff requirements. Outputs use stable task identifiers that remain unchanged after execution starts. New work receives new identifiers, and obsolete tasks are marked explicitly. The example task structure begins:

### T03 - <observable task outcome>

- [ ] T03.1 <first implementation slice>
- [ ] T03.2 <second implementation slice>

Dependencies: T01

At resume, read repository instructions and the contract, then current tracker documents, branch and commit state, relevant diff, and only the active task's code or artifacts. Disk state and executed checks establish implementation truth; tracking documents summarize it. Reconcile discrepancies without silently changing scope or acceptance to match the code.

Statuses are pending, in_progress, blocked, and done; only evidence-backed acceptance permits done. Validation records capture timestamp, commit or working-tree state, exact procedure, relevant environment, result, artifacts, failures, skipped checks, and unresolved gates. The checkpoint preserves verified behavior, partial work, blockers with clearing conditions, unrelated changes, one concrete next action, and the next focused check. Vague instructions to continue are insufficient.

The execution loop selects dependency-ready slices, makes narrow changes, runs focused checks, updates status from evidence, and refreshes the checkpoint. Broader suites run at defined milestones or when risk warrants them. Git retains checkpoint history; concurrent writers still require repository coordination. Tracking files must not retain secrets or private data.

Companion workflows cover discovery and design, planning, canonical project state, and retrospective evidence auditing. This pattern supplies the execution contract between those concerns.