Evidence and Acceptance

Evidence and acceptance

A completed task means its specified acceptance criteria were reviewed. It does not establish every property of the application, runtime, or release.

Use the canonical evidence guide and evidence template to record the exact claim, task ID, original observation time, source revision, environment, target/artifact identity, action or command, result, retained proof, limitations, and reviewer.

Keep the boundaries distinct

• Source verification establishes checked implementation at an identified revision.
• Integration establishes that the intended changes were combined and checked.
• Artifact verification identifies the package or build that was tested.
• Deployment or installation establishes placement at the intended destination.
• Functional evidence demonstrates applicable user actions and data paths.
• Operational evidence covers the project's required persistence, recovery, and ownership.
• Publication establishes availability to the intended audience.

Select only the boundaries that apply. These are not seven mandatory stages for every project. A documentation or local-library project can have a much smaller acceptance scope. Domain-specific approval requirements belong to that project.

Preserve valid completion credit

When source and runtime acceptance are separate obligations, represent them as separate tasks with the applicable dependency. Keep accepted source evidence while the dependent runtime task remains open. Reopen source work only when new evidence invalidates that original acceptance, preserving its history.

Do not refresh an observation by copying its report or changing a wrapper date. Do not sum overlapping test runs or mix task and route inventories into a single completion count. A successful build, dispatch, mock, or screenshot proves only the behavior actually checked.

Resume from the actual next step

Read CURRENT.md, selected tasks, and the linked checkpoint. Recheck volatile facts needed for the next decision and follow the existing dependency order. Retain ownership and handles for live jobs; a timeout is not cancellation. Retry after identifying a changed condition or a justified transient failure. Run focused affected checks and broaden them when the change or unresolved evidence requires it.

The CLI checks consistency of recorded evidence and reviewer names. It cannot authenticate the reviewer, independently establish artifact truth, or grant permission for an external action.

External task-state observations

The optional ROOT task delta preserves actual external item identity, observed state/time/revision, canonical task fingerprint, and evidence pointers. A matching snapshot means those retained values compare within the documented scope; it is not independent proof of the provider's claim, continuous synchronization, or application behavior. A missing expected revision remains unverified. Recheck changed decisive inputs and the actual external surface when the next decision requires it. Keep acceptance separate from an IDE/bot completed label or a provider exit code.