Skip to content

Build1 publisher3 min readPublished

Five cheap controls caught all nine broken checks in a single working day

A dev.to post logs nine defects found in one day's own verification tooling on 23 September 2026. The cheapest fix in it is one assert line that fires when a count of unique keys exceeds the rows it came from.

The Engineer · Build desk

Illustration accompanying Five cheap controls caught all nine broken checks in a single working day

What happened

  • A dev.to author counted nine defects in their own verification checks on 23 September 2026, among them a wrong token, a wrong constant, and a pattern that matched the wrong word.
  • None of the nine reached anyone else, because each was caught by a second, cheaper check the author had attached to the first.
  • A delivery tool that had passed eleven controls left the recipient's copy intact on a repeat run, but overwrote its own receipt for the first delivery.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • constraint A zero result stops being reportable on its own. Every search-based check now needs a fixture that provably contains the target, and the check cannot pass until the same instrument has produced a one.
  • cost Adoption is priced in lines, not suites: two for a control, one for a relationship assert. The recurring cost is keeping fixtures honest, because a fixture that drifts fails the run and not just the check.
  • exposure Second-order checks only guard the artifacts someone named. The receipts sat outside the eleven controls, so the audit trail was the part that silently lost a record.
  • decision Anyone weighing this pattern is weighing one person's self-audit with no total-checks denominator, so the transferable part is the five techniques and not the defect count.

The positive control is two lines of shell, and it fails closed. `hits=$(grep -c "$TARGET" known_positive.txt)` counts matches in a file picked because it must contain the target, and `[ "$hits" -ge 1 ] || die "positive control failed: this search cannot see its own target"` aborts the run when that count is zero [4]. The fixture chosen on the day was the tool's own source file, which looked safe right up until it turned out the file never writes the tool's name [3]. The author wrote that "a zero is only evidence if the same instrument has just shown you a one" [5].

The negative control inverts it: search for something that must not match, and demand zero [6]. A hand-picked placeholder in the `zzz-nope` style came back 39, because other documents in the same corpus had reached for the same obviously absent string for the same reason [6]. The replacement generates the sentinel at run time out of `/dev/urandom` [7]. "A string you invented a second ago cannot already be in anyone's file," the author wrote [8]. Randomness only helps where the corpus is text. When the check was a pattern match over running processes, the negative control used a process name that should not exist and returned 2, because the checking command's own command line contained the pattern [9].

Three of the nine defects surfaced only when the same quantity was counted two unrelated ways and the numbers disagreed [10]. `grep -c` counts lines, `grep -o` piped to `wc -l` counts occurrences, and listing files counts files [11]. One count of the word "table" ran high because the pattern matched inside "uncomfortable" and "accountable", which word boundaries fixed [12]. A literal search for `5/5` found nothing, because the document had written it as `*5/5*` [13]. The author wrote that when two instruments measure the same thing and disagree, that disagreement is the most valuable output of the day [21].

Cheaper still is the relationship a measurement cannot violate. A uniqueness check reported 10 unique keys in a table of 7 rows, and the pattern was also matching bold numbers outside the table [14]. If a row holds at most one key, at least three of those ten matches came from somewhere else [22]. The check is one line, `assert unique_keys <= rows` [15]. The same shape covers a part against its whole, a failure count against an attempt count, and an end time against a start time, at a line each [16].

Controls cover what you thought to name. The predecessor of the author's delivery tool copied files into place and overwrote same-named files without a word, eighteen times before anyone noticed [17]. The replacement reserves the destination atomically, fails loudly when something is already there, and passed eleven controls [18]. On its first day in use the author delivered one real file, then delivered it again on purpose; the recipient's copy was untouched, but the receipt for the first delivery was gone, because receipts were named by file name alone and opened in overwrite mode, so the second run's receipt of "delivered: nobody" replaced it [19].

For the pattern-matching defects to show up in your stack, your instruments have to be searches over prose that other people format, which is where word boundaries and `*5/5*` bite [12][13]. A check that parses structured data will not meet those two. The positive control applies to any query that can return zero, and the impossibility assert applies to any count with a denominator. Nine is a count and not a rate: the post does not say how many checks ran that day [20].

What to watch

  • Whether the author publishes a denominator for the day, which would turn nine defects into a rate rather than a tally.
  • Whether the receipt path gets its own relationship check, such as receipts written being at least deliveries made, after the go-live loss.
  • Whether the known-positive fixture is pinned, since an edit to that file turns every run red instead of only the broken searches.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories