One row in my project's coverage table read 0/13. Later it read 0/19. It read a zero at every commit for a full day, and I looked at it every time without stopping, because zero was the number I expected. The work it measures was not finished. A red row on unfinished work is not news. The row was measuring nothing. Here is the line that decided it, from the crate that owns the check: pub const SEMANTIC_MAPS: &str = "UnderstandRTSync/semantic"; That path was resolved against the repository root. The directory it names is not inside the repository; it is a sibling of it. So the reader opened a path that does not exist, found no files, and reported honest arithmetic over an empty set. Zero of thirteen. Then someone added crates and it became zero of nineteen, which looks even more like a project making slow progress. The denominator was moving. The numerator could not move, and nothing in the setup could tell me that. Why it survived an audit It survived because two rows next to it were red for real reasons. A file ledger at 0/289. A document census at 0/1916. Both genuinely at the start of long jobs. An expected red hides inside a row of expected reds. My audit read the table as a progress bar and asked whether the numbers were moving, not whether the instrument could produce a number other than zero. The general form: a check that can only ever fail is indistinguishable from a check that is failing, and the difference matters more than any single verdict on the board. The repair is a positive control, not a fix Pointing the path at the right directory takes one line. That was not the interesting part. The test that went in with it is: #[test] fn semantic_map_coverage_counts_the_maps_it_can_see() { and its comment states the discriminator plainly: pointed at an empty directory it must read 0/n, at a directory holding one map it must read 1/n, and at the real directory exactly the number of maps on disk. A coverage that always reports zero and a coverage that always reports n/n are then two different, visible failures. The environment variable exists only so the test can move the directory under the instrument's feet. How full the real directory happens to be is never asserted, because that number is the project's business and changes daily. One more thing changed with it. The denominator used to be a hand-walked file count. It is now derived from the workspace members in Cargo.toml, so a new crate raises the denominator whether or not anyone remembers to update a list. A denominator I maintain by hand is a denominator that agrees with me. What I got wrong I wrote the rule "every control needs a planted negative" early and followed it. Every check on this project has a case that must turn it red. I had no rule for the opposite direction, and this row is what that gap looks like: a check that had never once been shown a world in which it should say something other than zero. A planted negative proves a check can fail. A planted positive proves it can succeed. I had built half of the pair and called it discipline. The second mistake is the one I keep making. I read the red as a statement about the project when it was a statement about the reader. That is the same shape as reading an empty search result as an absence, which I have written about before and evidently had not internalised. What I did not check Two rows in the same table are still red for reasons I believe, and neither has a planted positive yet: the file ledger and the document census. I believe them for exactly the reason I believed this one. That is not a good enough reason and they are next. I have not audited the rest of the tree for paths resolved against the wrong root. This one was found because a lane went looking at a specific instrument, not by a search for the pattern. The historical rows stay as written. The record is append-only, so a day of 0/13 remains in it, wrong, with this entry beside it saying why. Trace: ledger DB/bands/decisions/01_DECISIONS.md entry D-0029, which registers this as an audit defect found after the audit closed. The constant and the test are at crates/gate/src/lib.rs, lines 81 and 1839. Repository: this rebuild is private while it is being cut. Its public predecessor is TraceFold/tracefold, and docs/LIMITS.md is where that project writes down what its own checks do not cover.