testing-strategy

# Testing Strategy Testing is an evidence-selection problem, not a contest to run the largest suite. Choose the smallest set that can falsify the changed behavior, then add one higher-level check only when it covers a boundary the lower level cannot. Keep execution environments reusable, but separate their evidence profiles: `staging-smoke`, `security-proof`, `release-attestation`, and `nightly-stress`. Use `harness-feedback` when a gate is reported as overloaded or misplaced. ## Workflow 1. Freeze the acceptance criteria as observable outcomes. 2. Inspect the changed files and classify the risk. 3. Select the lowest useful test level from the matrix below and name the profile. 4. Run the fast gate first. If it fails, fix the cause before adding more tests. 5. Add a focused regression test for a confirmed bug or a changed invariant. 6. Test real boundaries only when the change crosses them. 7. Keep security-proof and release-attestation checks out of staging-smoke unless the acceptance criteria explicitly require that evidence. 8. For high-risk or long-horizon work, use a fresh-context verifier and store the command, revision, result, and skipped checks in a durable artifact. ## Compact Matrix | Change | Required evidence | Usually deferred | |---|---|---| | Docs, comments, formatting only | Link/lint check when relevant | Runtime suite | | Pure function, local refactor | Fast checks + focused unit/regression tests | Full E2E, mutation | | Parser, serializer, file,...