{
  "id": 5803877,
  "title": "A red I expected hid an instrument that was reading an empty directory",
  "url": "https://urgent.news/2026/09/05/a-red-i-expected-hid-an-instrument-that-was-reading-an-empty-directory",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-05T17:23:23.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/mahirhir/a-red-i-expected-hid-an-instrument-that-was-reading-an-empty-directory-2ph8"
  },
  "original_language": "en",
  "account": "One row in the project's coverage table initially showed a 0 out of 13, then changed to 0 out of 19, staying at zero for an entire day. This single number was the expectation. The work being measured still hadn't been completed. A red row indicating unfinished work is not considered noteworthy. The issue arose because the check was measuring nothing in particular. The line of code responsible for this situation was: pub const SEMANTIC_MAPS : &str = UnderstandRTSync/semantic ; This path was determined based on the repository root. The directory this path points to is not part of the repository; it is a sibling. Consequently, when the reader attempted to open this non-existent path, it found no files and reported accurate arithmetic over an empty set, resulting in a 0/13 figure. Once more crates were added, the denominator increased to 0/19, making the project appear to make slow progress. Despite the denominator changing, the numerator remained constant and could not be modified by the current setup. The existence of this row went unnoticed during an audit because two other rows in the table displayed red for legitimate reasons. One of these was a file ledger at 0/289, and the other was a document census at 0/1916. Both represented the beginning of significant tasks. The existence of this red row, despite the absence of any anomaly, highlights an important lesson: a check that can only fail is indistinguishable from one that is failing, and understanding this difference is crucial. The solution lies in pointing the path to the correct directory with just one line of code - this proved to be the less important aspect. The real value came from the accompanying test: #[test] fn semantic_map_coverage_counts_the_maps_it_can_see () { This test pointed out that when the path is pointed at an empty directory, it must read 0/n, at a directory containing one map it must read 1/n, and at the correct directory it should read the exact number of maps on disk. A coverage that always reports zero and one that always reports n/n are two distinct, visible failures. The environment variable in this test was only intended to move the directory away from the instrument's reach, and the real size of the directory was never asserted, as it was the project's responsibility and changed daily. Additionally, the method of calculating the denominator evolved from a manually counted file count to a derivation from the workspace members in Cargo.toml. With this change, adding a new crate automatically increased the denominator, regardless of whether anyone had updated the list beforehand. The main oversight in this situation was the absence of a \"planted negative\" - a check designed to fail - in the system. Such a check would prove that the check has the capability to fail. Conversely, a \"planted positive\" - a check designed to succeed - would demonstrate the ability to succeed. The project had only one direction tested, leaving a gap where a check that could only ever show zero existed. This gap symbolized the oversight. The second mistake is one I am likely to repeat. I interpreted the red row as a statement about the project itself, when in fact it was a statement about the reader. This perspective mirrors reading an empty search result as an absence, a concept I had previously discussed but failed to internalize. One aspect that needs further attention is the presence of two rows in the same table that are still red for reasons I believe to be valid. Neither of these rows has a planted positive check yet, just like this one. This lack of verification is not a sufficient justification, and these rows will be addressed next. Furthermore, I have not yet audited the entire tree for any paths that are resolved against the incorrect root. This oversight was discovered because I was specifically looking at a certain instrument, rather than conducting a search for the pattern. The existing rows will remain unchanged to maintain the integrity of the record, which is append-only. The mistake is documented in DB/bands/decisions/01_DECISIONS.md entry D-0029, serving as an audit defect discovered after the audit closed. The constant and the test are located in crates/gate/src/lib.rs, specifically on lines 81 and 1839, respectively. The repository containing this rebuild is private during its creation, with its public predecessor being TraceFold/tracefold. The documentation outlining what checks this project does not cover can be found in docs/LIMITS.md.",
  "summary": "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…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}