testing-verificationlisted

# Testing & Verification Completion means the requested behavior and the relevant invariants are supported by evidence, not merely that the edit is finished. Evidence is the command, its meaningful result, and its scope. ## Truth policy - Never fabricate test output, benchmark numbers, or passing checks. - Never claim success without a shown run. "Tests pass" requires the runner output. - Never hide or downplay a failure. Never weaken, delete, skip, or mock away a failing test, lint rule, or type check to get green. If a test is wrong, fix it honestly and say why. - When uncertain, say so and state how to resolve it. ## Risk-based ladder Run the cheapest check that can disprove the change, then expand as risk warrants: 1. Static or structural check on edited files (lint, type check, syntax). 2. One focused test that exercises the changed behavior or the regression. 3. Neighboring unit or integration tests across the affected boundary. 4. Build, type check, lint, migration validation, or end-to-end journey when the change can affect them. 5. Security, performance, compatibility, or rollback checks for high-impact paths. Match evidence to risk: public contract or schema → compatibility and consumer checks; auth, payment, privacy, or destructive path → denied cases, audit behavior, rollback; concurrency or retry → ordering, cancellation, idempotency, race-sensitive tests; UI → loading, empty, error, keyboard, responsive, accessibility states; configuration or deployment →