Task agreement and implementation evidence

Every task has two durable artifacts with different authority. task-definition.md is the work agreement. It owns the objective, declared targets, dependencies, acceptance criteria, evidence profile, validation commands, and recovery boundary. implementation-summary.md is the canonical technical evidence artifact. It records what the current attempt actually changed and proved.

No competing completion note, chat transcript, receipt, or reconciliation page replaces the implementation summary. Create or refresh the canonical paired artifact with implementation-summary build --task-definition <path>. Build writes the summary shape and derived evidence; it does not accept the work or close the task.

Before implementation

task readiness-review evaluates the agreement without writing. task readiness-authorize is the separate revision-bound authorization write. task attempt-open then opens one canonical attempt tied to that readiness review. Runtime and Hybrid work must capture task baseline after authorization and before implementation writes.

The baseline records declared-target observations, repository state, source revision, attempt and checkpoint identities, and any explicit adoption of an already-dirty target. Later attribution compares current target state with those observations. That comparison is why work cannot recreate a trustworthy baseline after editing begins.

Contract-impact posture

When .day-shift/contract-impact.json exists, readiness computes a cycle-safe transitive closure from the task’s declared targets before authorization. Schema v2 classifies each producer and consumer as writable-target, generated-output, read-only-evidence, or frozen-dependency. Output keeps writable paths, generated outputs, immutable dependencies, required validation commands, enforcing contracts, and unknown producers in separate lanes.

A required writable or generated consumer that is absent from the task agreement blocks readiness. Read-only and frozen dependencies are checked for repository presence and remain visible evidence; they are never proposed as writable targets. Every frozen entry names a repository-relative enforcing audit or contract, and a missing dependency or enforcer fails closed. Changing a frozen posture requires an explicit contract revision rather than an implementation-scope expansion.

The contract’s unknownPolicy controls how uncovered producers are treated. blocking is exhaustive mode: every declared target must have an exact producer relationship before readiness and baseline capture can proceed. advisory is sparse opt-in mode: unknown producers stay visible as warnings and remain part of the posture-aware fingerprint, but they do not block otherwise-complete work. Advisory unknowns never prove coverage. In both modes, every known relationship still strictly enforces its required writable and generated closure, immutable posture, enforcers, and validation commands. This repository uses advisory so the relationship graph can describe high-value transitive obligations without becoming a global allowlist. Baseline recomputes and binds the exact fingerprint, rejecting invalid, incomplete known obligations, unknown-under-blocking, or stale evidence without writes.

Additive recovery after baseline

If a later contract revision reveals only the complete required writable/generated path and validation closure, task scope-recover continues the same fresh full-cycle-strict run without pretending the earlier baseline saw those obligations. Preview binds the exact task revision, open attempt, immutable baseline ID, and current schema-v2 impact fingerprint. Apply accepts only the derived closure.

Untouched additions amend the open attempt and add supplemental observations while preserving the original baseline. If any eligible addition already changed, the command closes the predecessor as contract_gap, preserves all of its evidence, opens one successor with the same recovery identity, and returns the exact successor-baseline action. Read-only, frozen, unknown, arbitrary, incomplete, objective, acceptance, ownership, external-authority, and destructive-boundary changes remain material no-write blockers. Agents follow the returned action instead of opening a sibling run or editing lifecycle metadata.

During implementation

Keep the summary aligned with the current attempt. Its attempt history owns implementation_status, validation results, deviations, waivers, blockers, review disposition, and close time. Record validation through task validation-record; command-owned execution, manual evidence, CI evidence, and imported evidence retain distinct provenance.

Changed Paths lists current-cycle declared-target evidence as one exact top-level - \repository/relative/path`bullet per entry, without a description or second path.implementation-summary buildreturns deterministiccandidatePaths`, ready-to-paste candidate Markdown, and a reason for every excluded dirty path; use those candidates instead of inferring ownership from the worktree. Necessary changes outside declared targets belong in Deviations with the exact declared target, exact dependent or replacement path, rationale, and bounded effect. A no-write Changed Paths parser rejection remains recorded but does not replace the lifecycle run’s last accepted artifact revision, so the corrected summary can be retried without restoring rejected bytes.

Completion is a sequence

task implementation-complete evaluates the exact attempt, current task revision, baseline attribution, required validations, and authored acceptance evidence. It changes only the attempt’s implementation status. implementation-summary review remains read-only. task disposition records the explicit review decision. task close performs the receipt-bound terminal task/summary transaction only after accepted review evidence exists.

These records cannot substitute for one another. A completed implementation is not accepted; an accepted review is not closure; a close receipt proves that the selected mutation applied but is not a second source of authority.

Milestone reconciliation.md consumes closed task summaries and evaluates the combined outcome. It rolls evidence up; it does not replace the task agreement or canonical implementation summary. See Evidence review and reconciliation for the operator journey and Lifecycle records reference for field and command ownership.