verification-before-completion

Name the exact claim being treated as ready, identify which seam owns it (contract, runtime, data, Redis, workflow), then pick the smallest check that could falsify that claim. Classify existing evidence as fresh direct, partial, stale, indirect, or missing before issuing a verdict.

Route-level app.inject() proof covers request validation, serialization, headers, and in-process HTTP behavior. It does not prove listen(), socket, shutdown, or stream lifecycle, which need a targeted real-runtime check instead.

No. Typecheck only proves the code compiles and static contracts fit together. Changed runtime, lifecycle, database, Redis, or workflow semantics require proof at the layer that actually exercises that seam.

Use real infrastructure when the claim depends on actual semantics: constraints, transactions, migrations, TTL, Lua scripts, or guard patterns. Mocked proof overclaims when correctness depends on real database or Redis behavior.

CI from before the latest edits is stale evidence, and a broad suite pass may never exercise the changed boundary. Closeout requires fresh, direct evidence tied to the specific claim, not general historical reassurance.

Escalate when the design is still unsettled, the change portfolio needs a dedicated test-plan effort, or the real question is design review, test quality review, or root-cause debugging rather than closeout proof selection.