prepare-acceptance

Prepare Acceptance

Prepare an implemented change for a separate human acceptance session. Exercise it as a human user or real client would, report clear defects, wait for CI once no defects remain, and produce concise evidence for the code currently checked out. Fixes and automated validation belong to separate caller-managed steps when used. PR and commit identity establish final CI and handoff alignment; they are not prerequisites for exercising the product.

Required inputs

Resolve these from the caller before acting:

• approved requirements, scenarios, design, test plan when one exists, and task artifacts;
• caller-supplied implementation summary or completion evidence identifying delivered behavior;
• evidence output directory;
• unresolved-assumptions ledger path, when one exists;
• verification scope:
  • full;
  • targeted, naming the affected flows, directly dependent flows, a concise impact rationale, and prior full-pass evidence to retain, plus the caller's attestation that this scope covers the tracked changes since that baseline; or
  • evidence-only, identifying prior flow evidence whose coverage revision exactly matches the current tracked contents and supplying the caller's attestation of that content match.

If source-of-truth artifacts or the evidence directory are missing, report what is missing and stop before flow execution. Do not infer product behavior from implementation alone. When an approved test plan exists, treat its required and activated conditional AT-* flows, evidence requirements, authorized effects, and permitted substitutes as authoritative. Use full when the caller does not supply a scope or no trustworthy full-pass baseline exists. Targeted and evidence-only reuse depend on the caller's impact or content attestation: reconcile it with the approved flow inventory, but do not independently inspect a diff. Use evidence-only only when the caller attests that no tracked product contents changed after the recorded coverage revision; PR alignment, pushing the already-tested commit, waiting for CI, or a Validator run that made no tracked change do not invalidate flow evidence. When no assumptions-ledger path is supplied, use <evidence-directory>/acceptance-assumptions.md and create it if needed. Keep this preparation autonomous: preserve product, scope, or design ambiguity for the later human acceptance session instead of asking the user here.