Verify Live

Reading a diff cannot find the bugs that live below it: provider API quirks (a parameter rejected when another is absent), container build gaps (a manifest missing from an install layer), queue retry semantics, timezone reality, and races between workers. These only exist at runtime. This skill is the discipline of meeting them the same day the code is written, while the context is loaded — not in review, not in production.

Steps

1. Launch the real stack. Use the project's documented launch path (CLAUDE.md § Runtime). Real database, real queue, real emulators — not mocks. First time in a repo: document the launch path as you discover it, so the next session doesn't rediscover it.
2. Drive the actual user path, as the user: create the thing, see the thing, cancel the thing. Not just the API call — the page, the button, the state after refresh.
3. Watch the logs while driving. A flow that "works" while logging a swallowed error every request has not worked.
4. Exercise one failure path minimum. Kill the worker mid-job. Feed it an expired credential. Let a timeout fire. Verify the failure lands in the designed place (status, message, retry affordance) — failure UX is part of the spec, and it is never covered by the happy-path drive.
5. External callbacks need a real tunnel. OAuth redirects and webhooks cannot hit localhost; use the tunnel script (templates/dev-tunnel.sh) with your reserved domain, and confirm the registered callback URL matches the tunnel origin before debugging anything else.
6. Capture proof into the PR body: a screenshot of the driven flow, a log excerpt of the job completing, the failure path rendering its message. "Proof of done" is a deliverable, not a courtesy.

Rules

• Same day. The cost of a runtime discovery doubles every context switch away from the code.
• Fix at the source. A bug found here gets diagnosed (/diagnose for the hard ones), fixed in source, regression-tested (/tdd), and re-driven — never patched in the running environment and forgotten.
• Never delegate verification to the user. "Try it and tell me if it works" inverts the responsibility. Verify first, then show proof.
• If the change cannot be exercised live (a library, a type-level change), say so explicitly and name what covered it instead (tests, typecheck) — don't silently skip.