Product Acceptance

Product Acceptance asks: Does the assembled product, as intended to ship, deliver the accepted outcome? Local suites can be correct in their own scope while their composition is unusable. Classify them as supporting evidence, not as assembled-product proof.

This is methodology, not permission or a new approval stage. Use agreed requirements, scope exclusions, design, architecture, and project instructions as inputs. Choose ordinary tools and proof mechanics within your task; do not redefine the user's product promise to fit the implementation. Resolve an ambiguous promise with its decision owner, while continuing independent work.

1. Select claim-appropriate scenarios

Group accepted criteria into externally meaningful outcomes. Choose the smallest scenario set whose failures would expose materially different composition defects—not one test per requirement or only paths known to work. Use accepted human scenarios and setup-to-first-result, supported-change, and recovery coverage when relevant; optional lifecycle suggestions do not become requirements.

Useful discriminators include UI → API, command → durable state → later read, scheduler → worker → side effect, policy/auth boundaries, upgrade/migration, and interruption/retry. One scenario may prove several related criteria. A happy path cannot alone prove an agreed no-loss or recovery promise. Keep internal invariants in narrower tests when those are sufficient. A pure local change with unchanged public behavior and adequate contract/regression evidence need not manufacture a new expensive E2E test.

Plan proof when its real components will exist; execute representative final proofs after relevant integration changes. If tools or components are unavailable, specify the executable strategy and mark proof pending rather than substituting a demo. For human-facing outcomes, include current implemented-experience evidence where accepted design materially constrains comprehension, controls, accessibility, or responsive behavior. Functional status alone does not prove that experience.

2. Draw the boundary before choosing doubles

For each scenario write: