Four Greens That Depended on Where They Ran
The previous lessons built a check that compares the right bytes, renders templates before comparing, refuses placeholders, and runs from each consumer's own suite. In the weeks after, the family found four ways that check could be green and wrong at once. None was a bug in the comparison. Each was about where the check was standing when it looked.
- An absent kit. The check skipped when the kit was not checked out beside the consumer, on the reasoning that no deploy could have happened there either. A review found the hole: a hand-edited copy passed green on exactly such a checkout, because a skipped check reports nothing. The owner chose a middle path. On a fleet Mac, where the kit is always expected, the same absence now fails and names the path where the kit should be; off the fleet — a cloud session, an archive restored years later — it skips and says why.
- A worktree. A desktop session runs a consumer's suite in a git worktree nested inside the repository. The test found the kit by counting directories up from its own file, and from a nested worktree that count lands inside the repo, so a fleet Mac failed a suite on a kit that only looked absent. The other half was worse: the check, given a repository name, located that repository beside the kit — the main checkout — and reported its copies clean while the suite was running the worktree's copies. The fix asks git for the main checkout instead of counting, and passes the checkout under test explicitly, so the worktree's own copies are the ones judged.
- A copy git ignores. A vendored file can sit on disk, match its source byte for byte, and never be committed, because an ignore rule swallows it. A global ignore rule for any directory named like a common script folder silently dropped a newly vendored helper from three repositories while their tracked install scripts called it. The check now reports a vendored copy that git ignores, by name, with the override to add.
- A header that names the wrong commit. A copy's body can match while its provenance header names a commit whose copy of the source is not the one that body was rendered from. The check now warns about exactly that, and the deployer refuses to deploy any source that is not committed, so the header can only ever name a commit that holds what it delivered.
What the Four Have in Common
Each green described a different tree from the one that ships. The skip described a checkout with no kit in it. The worktree check described the main checkout. The ignored copy described a working directory that git would never commit. The stale header described a commit that never held the source of that body. In every case the comparison was correct about the thing it looked at, and the thing it looked at was not the thing that mattered.
So the check now has to answer four questions before its verdict means anything: which machine am I on, which checkout am I judging, which of these files will git actually keep, and does the commit each header names really hold the source its body was rendered from. Those are questions about vantage, and none of them is visible in a byte comparison.
Do Not Fix an Honest Red
One consequence surprised people. A worktree whose vendored copies are simply older than the kit's — because its branch has not taken main since the kit last deployed — now fails. That is not a bug to route around. The worktree's tree is not what the kit ships, and a merge of main is what brings the newer copies. The failure message says which tree was compared and that a merge is the remedy. A check that could be made green by skipping this case would be back to describing a different tree from the one under test.