Evidence has a scope.
A green result proves only what it exercised.
Treat every verification result as a claim with limits. A unit test may establish a transformation while leaving serialization, persistence, and UI behavior untested. Match the evidence to the changed contract and the callers that depend on it.
Test the behavior, not the generated structure
Prefer examples that fail when the promised behavior is wrong. For cursor pagination, check ordering, duplicates, and invalid cursors instead of asserting that a helper was called twice. For a shared utility, consider representative consumers. Keep verification proportional to the risk rather than collecting redundant tests to make the patch look substantial.
Record what actually ran
Capture the relevant command, outcome, and environment limitation. A proposed command is not an executed check, and an unavailable service is not a passing integration test. When a failure is pre-existing, establish that with evidence before excluding it from the patch assessment. Rerun affected checks after meaningful changes to the implementation.
- CLAIM
- Invalid cursors follow the existing error contract.
- CHECK
- Exercise the parser and endpoint response.
- LIMIT
- Name any unavailable integration dependency.
WORKING REQUEST / SPEC 06
Summarize verification for the changed contract. Include executed commands and observed outcomes. Separate passing, failing, and unrun checks. Explain what remains unknown before integration.
Do not turn an unavailable check into an affirmative claim.