verification-gatelisted

# Verification Gate The human will NOT read your implementation. Their confidence comes entirely from the **evidence report** you produce, proving the code ran the gate. Your job is to make that report trustworthy enough that line-by-line review becomes optional within the boundaries of what the gate actually measured. This inverts the normal review model: **trust moves from inspection to constraints.** Be honest about what that buys: the gate turns the constraints the stated intent expresses into executable evidence — it cannot show the stated intent expresses everything that matters, and it is not self-authenticating, because a checker can be unsound and a mapping can claim more than it demonstrates. Upstream, `old-coder` closes the first gap with a spec the human approves **before** code exists — the one artifact that breaks the everything-authored-by-the-same-agent correlation. This skill runs after the code is written, so that artifact may not exist. What replaces it is the acquisition step below: read git for facts, ask the human once for intent, and record honestly which of the two you got. Every shortcut you take against the gate destroys the only basis of trust. ## Scope Boundary This skill **does not review code**. It does not look for defects, does not rank findings, and does not propose fixes. It runs checks and reports results. One named exception: the **capability diff** in the supply-chain layer. It is scoped mechanically so it cannot drift into review —