Verify

Overview

/verify is the final gate before a change ships. Unit tests prove the code compiles and the methods return what their authors expected. They do not prove the running service accepts real payloads, returns the documented envelope, preserves cross-service contracts, or survives the weird shapes production traffic actually produces. /verify does that.

Core principle: No completion claim is trustworthy until a curl against a running service produces the right response body, status code, and side effects — with fresh, recorded output. Everything else is paraphrase.

Design goals every run must optimize for:

• Evidence, not assertion — every "pass" is backed by recorded curl -i output stored under the ticket folder
• Payload realism — fixtures come from real row shapes (DB sample) or user-provided cases, not invented JSON
• Variant coverage — happy path + at least one boundary + at least one negative per endpoint
• Iteration discipline — on failure, pass a specific delta to /work, not "it broke, fix it"
• Escalation bounds — unproductive /work loops are detected and escalated, not retried forever
• Environment-bounded blast radius — local/dev is default; audit/stg payload runs are allowed only when the user explicitly names that target; prod is never allowed

The Iron Law