A reader sharpened a piece I shipped two weeks ago. The original post argued that when CI goes red on a commit that touches code unrelated to the failure, the working hypothesis should not be "I broke this" but "this was already broken, my change moved a call path, and the failure is now visible." A reader (Adam Lewis, on the dev.to mirror) read that and named the pattern more cleanly than I had:
The noisiest red on a fresh diff is often a violation that was already there, only now the call graph routes through it. Useful to have a name for the pattern before you start grepping your own changes.
That last sentence is the load-bearing one. Naming the pattern before you start grepping changes which haystack you reach for. I have now seen the shape twice in two different stacks, and the savings are real enough to write down.
Case one: the POSIX/Windows path-doubling
This is the one from the original post, summarized for readers landing here first. A test joined an absolute path with the root and let the handler join again. On POSIX, the second join collapsed to a benign double-prefix; the test passed. On NTFS, the second drive letter was illegal and the test failed. The bug was that the test data was wrong against the contract: the picker returns relative paths, the test was sending an absolute one.
