# Independent acceptance and risk matrix for an evolving sprint

Use when reviewing a worktree that another agent or developer is still changing, especially for financial, medical, import, migration, or reconciliation releases.

## Goal
Produce an independent, version-bound release verdict without editing implementation files. Map every stated acceptance case to executable evidence and identify release blockers before broad release gates run.

## Workflow
1. **Bind the snapshot.** Record inventory/base SHA, branch, schema source/target, current tracked changes, and untracked candidate files. Re-check status near the end because the worktree may evolve during review.
2. **Read contracts before tests.** Inspect the inventory/ADR, migration, service, API router, frontend API types, pages, and legacy tests being relied upon.
3. **Freeze the acceptance universe.** Number every supplied golden case. If the exact user list is unavailable, say so and use a clearly labeled provisional decomposition rather than implying it is canonical.
4. **Map each case to four surfaces:** implementation file/function, API endpoint or UI route, focused automated test, and release/UAT gate. Mark coverage `direct`, `partial`, `missing`, or `contradicted`.
5. **Separate legacy green from new-contract green.** Passing predecessor tests are regression evidence only; they do not prove a new versioned importer, pairing engine, API, migration, or UI contract.
6. **Trace preview → confirm end to end.** Compare frontend payload types, router models, service parameters, fingerprint and baseline inputs, transaction boundaries, persisted lineage, audit payloads, and response redaction. A frontend mock can pass while no backend route exists or schemas disagree.
7. **Probe cross-record invariants.** Include same-file, overlapping-file, same-request, cross-batch, pending→final, refund/reversal, stale baseline, idempotent replay with altered input, competing pairs, and canonical-record linking.
8. **Review transaction ownership.** Verify transaction/savepoint start, commit, rollback, and preservation of a caller-owned outer transaction.
9. **Review persisted evidence completeness.** Counts must reconcile with files, rows, duplicates, pending/superseded rows, candidates, pairs, links, and audit. Beware dictionaries keyed by fingerprints collapsing duplicate rows before persistence.
10. **Review migration independently.** Require a schema-N copy upgraded to N+1, unchanged business digest, `integrity_check`, empty `foreign_key_check`, idempotent second run, and backup/restore evidence. A fresh in-memory schema test is not an upgrade test.
11. **Check sensitive-data boundaries.** Prove raw inputs and stable source references are absent from responses, errors, URLs, logs, audit, browser persistence, screenshots, and tracked artifacts.
12. **Run focused read-only evidence.** Execute predecessor regressions and current feature tests separately. Report wrong command paths as corrected invocations, not durable tool failures. Never run productive confirm or provider actions.
13. **Classify findings:** `P0` for correctness, atomicity, idempotency, migration, write security, privacy, or canonical identity; `P1` for required UX/responsiveness/observability; `P2` for accessibility/polish/maintainability.
14. **Deliver the verdict first,** then P0 blockers, numbered matrix, cross-gates, commands actually run/results, still-required commands, and confirmation that no implementation or productive data was modified.

## Common traps
- A test file exists but cannot collect because imported pages/modules are absent.
- From a package directory, a repository-root-prefixed test path can falsely yield “no tests found”; use a package-relative path.
- A fingerprint that includes the baseline can make a later explicit baseline-mismatch branch unreachable; test actual ordering.
- Idempotent success by preview fingerprint before reconstructing resent input weakens replay binding.
- Persisting only writable rows loses duplicate/pending evidence and breaks count reconciliation.
- In-request receipt matching does not prove linkage to an existing canonical money movement.
- Legacy pairing tests do not prove a materially changed pairing version.
- Refresh worktree status before final claims and label the verdict snapshot-bound.

## Minimum evidence groups
Focused predecessor regressions; new-contract backend tests; API/security tests; frontend tests with package-relative paths; migration copy/idempotency/digest tests; static checks; aggregate release gate after stabilization; read-only responsive UAT with before/after business and side-effect digests.