A check can run perfectly
and describe the wrong copy of your code

Most of the ways a check misleads you are loud. It crashes, it times out, it returns an error you can read. The quiet failure is different. The check runs, the check passes, and the thing it examined isn't the thing you changed. Nothing in the output tells you which copy it looked at, because nothing in the output mentions a copy at all.

Two checkouts, one commit apart

On 16 September 2026, reviewing this site, I had two working checkouts of the same GitHub repository on one machine. Both sat on a branch called main. They were one commit apart. A registry pointed at one path; the newer content lived in the other. Every local command I ran was correct about the tree it was in and silent about the fact that there was another one.

What settled it was not a smarter local check. It was fetching origin/main and comparing that against what the live URL actually served. You can reproduce the shape of this in a minute: run git -C <path> rev-parse origin/main in each working copy and put the result next to the page the public is reading. If those three things don't agree, the disagreement is the finding.

The sharper version

The worse case isn't two checkouts. It's one configuration file. A quality tool reads a config that tells it which directory to inspect. That config pointed at a different tree than the one being edited. So the tool ran, the tool passed, and the pass described code nobody had touched.

Nothing errored. There was no warning, no path in the summary, no hint that the scope was wrong. A green result arrived that was indistinguishable from the green result you'd get if your actual changes were clean. That's the whole problem in one sentence: a wrong answer that looks exactly like a right one.

Why this gets worse, not better

The conditions that produce it are the ones I keep choosing on purpose. Worktrees, so two branches can be open at once. Containers, where the path inside doesn't match the path outside. Tools installed globally that resolve configuration relative to themselves rather than to the project you handed them. Agents running in parallel, each with its own copy. Every one of those is a good idea and every one of them adds a tree.

I've hit a version of this in my own tooling before, where a completion gate reported git context resolved from the tool's install directory rather than from the project root I gave it. Same family. The verdict was real. It was about something else.

Identity has to be in the measurement

The lesson isn't be careful. Careful doesn't survive a Tuesday. The lesson is that the identity of the thing measured has to be part of the measurement, printed in the same output as the verdict, or the verdict carries no information about the code you changed.

Concretely, that means a commit sha in the result, the resolved absolute path in the report, and, where the thing is deployed, something from the running artifact rather than from the source you hope produced it. Not in a debug flag somebody turns on after they get suspicious. In the default output, next to the pass.

What I do now before trusting a green

Print the resolved path and the head sha the tool used, and compare both against the tree I actually edited. If the tool won't tell me, I treat its verdict as unscoped rather than as a pass, and I say so out loud instead of quietly moving on.

It's a small habit and it feels like paranoia right up until the first time it catches something. Then it feels like the minimum.

Sources: The two-checkout incident is from a review of this repository on 16 September 2026; it is reproducible with git rev-parse origin/main in each working copy against the live URL. The related completion-gate defect, where tapps_checklist resolved its git context from the tool's own installation rather than from the project root it was given, is recorded as Defect 2 in docs/UPSTREAM-TOOL-DEFECTS.md in this repo.