Nothing Read It, So Nothing Failed

Five defects surfaced on 2026-08-05 across five substrates that share nothing with each other.

A JSON config key, source.verify_before_push, set to true, mirrored in a JSON schema as a const, mirrored again in a test fixture, and read by zero lines of code. A systemd deployment manifest with a writer and no reader. A Postgres grant held on a table because the word appeared in the design vocabulary, not because any code touched it. A Python alert callback bound as a method, so self arrived as the first positional argument and every single call raised TypeError straight into a broad except. An rsync mirror check that verified the copy matched the source rather than that the source still existed.

All five are the same shape. An artifact with a producer and no consumer.

That is precisely why none of them ever failed. They did not emit a false green. Nothing consumed what they produced, so nothing they produced was ever in a position to be wrong.

Be blunt about the distinction, because this blog has already run the “the check was lying” thesis four separate times in two weeks, most recently in The Check That Only Confirmed a Name, and this is not that. A check that reports OK while doing nothing is a wrong answer, and a wrong answer is at least an answer. You catch it by asking whether the green is plausible. Most of these produced no answer at all. The config key was never consulted, so it never approved anything. The manifest was never read, so it never verified anything. The alert dispatch raised before it reached its callback, so it never alerted. There is no green to distrust because there is no signal, and silent failure reads identically to quiet health.

The five are not identical, and pretending they were would be its own decorative claim. Three of them are the pure form: an artifact declared and never consulted. The fourth is the same shape at the call boundary, where a consumer was configured and made unreachable by a one-word binding error. The fifth is the edge of the class, and it is the interesting edge, because it had a consumer and still told nobody anything useful. Taking them in that order is the argument.

Then, hours later, on the other side of the estate and citing none of it, the day’s governance work independently named the general form. Two of the seven questions a subsystem must now answer before it counts as operational are “can Mission Control consume it” and “can an agent consume it.” The engineering found the bug class in the morning. The governance wrote its law in the evening. Neither knew about the other.

The day started with a full disk

The report from the human was “transcript writes are failing.” That is a symptom, and a small one.

Root was at 100 percent: a 387G volume with 100K free. Claude Code writes each command’s output and the session transcript into /tmp, so those writes hit ENOSPC and got dropped. Nothing corrupted. Output just vanished.

Underneath that, three legs of the backup fabric were broken at once, and the estate’s own docs described a system that had not existed since 2026-07-28:

1. The dev box’s own borg backup had failed every run since 08-04 with ENOSPC, and the killed run left a stale lock, so the 02:00 retry died in five seconds trying to acquire it.
2. The VPS to dev-box replica pull failed all three attempts on 08-05, leaving a torn repo.
3. The Backblaze B2 offsite push had not succeeded in eight days while writing nothing at all to its log.

Legs 1 and 2 had an architectural root cause, not a capacity one. backup-system.sh backed up /home/jeremy with no exclude for ~/backups, so the roughly 10G VPS replica was being swallowed into the dev box’s own borg repo and shipped back to the VPS every night. The fabric was feeding itself. Proven by archive diff: 113 replica segment files in the Aug 4 archive, 0 in Aug 5’s. A backup store is never a backup source. That is now a rule with an incident behind it.

Leg 3 was independent and worse in character. The last successful off-site push was 2026-07-28. Every nightly run after it failed, eight in a row, until the fix on 08-05. b2-offsite-push.sh was the only script in the fabric with no export PATH. Cron’s PATH=/usr/bin:/bin excludes ~/bin, where sops lives, so the script exited BEFORE the line that opens push.log. It was reproduced exactly under env -i (exit 1, stderr only, log unchanged at 8 lines) before anything was changed:

# Cron gives this script PATH=/usr/bin:/bin, which does NOT contain ~/bin, where `sops` lives.
# Without this, the live path failed at the SOPS read on line ~100 and exited BEFORE push.log was
# ever opened, so eight consecutive nightly pushes (2026-07-28 through 08-05) failed with zero log
# evidence. The `.ok` staleness alarm was the only signal. Siblings borg-replica-pull.sh and
# devbox-borg-push.sh already carry this line. This script was the one that did not.
export PATH="${B2_OFFSITE_PATH:-$HOME/bin:$HOME/.local/bin:/usr/local/bin:/usr/bin:/bin}"

One line of fix, five lines of comment. For a defect that hid for eight consecutive nights, that is the correct ratio. The other half of the fix was moving log creation above the precondition checks, so a precondition failure can never be silent again.

Restored and verified the same day: backup exit 0, replica borg check verified at 10G, push.ok moved from 2026-07-28 to 2026-08-05T10:27, rclone check clean, receipt 1fc20ce0467ee66e, health monitor green. Disk went from 100K free to 25G free (100 percent to 94 percent) via stale /tmp session dirs (about 6G), 239 orphaned Docker volumes left over from the VPS migration (about 12G), and 12 unused images plus build cache.

The docs were wrong in three places and contradicted themselves: the backup README said “B2 is NOT provisioned,” automations.md said “immutable offsite (R2) still pending” (wrong provider AND wrong status, contradicting the next row of its own table), and the restore runbook told operators no offsite copy existed. Two smaller finds: a bare backup/ line in .gitignore matched at any depth and had been silently swallowing ops/backup/, and the borg timer had two OnCalendar= lines and genuinely fired twice a night.

All of that got written down. The estate (the full set of machines, services and repos this operation runs) keeps an append-only record of itself: numbered after-action reports, and a decision log where each ruling gets an ID and can be revised but never edited away. This incident produced after-action report 000-docs/150, with 13 findings, and rulings D147 through D154 covering exactly the fixes above: the excludes, the PATH, the size floor, and the three wrong docs. Those IDs are cited throughout this post. They are the receipts.

The model argued with its own closing summary

Claude Opus 5 traced “transcript writes are failing” to the full disk, then to the broken borg run, then to the stale lock, then reclaimed space, declared the incident fixed, wrote a memory note for future sessions, and closed with two claims.

Then the human steered, exactly as typed:

i need u to continue ans rhen adress the statemenr id we are backing ip on home server we dont nees tvis

Unprompted, after the incident was already closed, Claude Opus 5 came back and refuted both of its own closing claims.

The first: it had called the cause “the disk filled up.” That was the symptom. The real cause was the missing excludes, so the Docker and /tmp reclaim was triage and the exclude fix was the cure. The second, and the one the human’s steer targeted: it had said the backups had no protection against disk failure and offered to move them off box. False. B2 offsite with Object Lock is live and restore proven, with home server snapshots every six hours on top. It then edited the memory note it had just written, so a future session would not act on the bad read. A model that closes an incident and reopens its own summary to correct it is doing the same job as the guards below. It gave its own output a consumer. Most agent runs never do.

Day totals, for scale: 1,125 tool calls and 1,418 minutes of session span across four project-days, 39 errors hit, one course correction. Claude Fable 5 and Claude Opus 5 carried intent-os (904 of those calls); Claude Opus 5 had the blog repo; Claude Sonnet 5 took a two-minute errand elsewhere.

None of what you just read is one of the five. A full disk, a missing exclude, a stale lock, an unanchored .gitignore line: those are ordinary operational failures, loud once you look. They are here because clearing them is what put a human and three models inside the backup fabric long enough to read it properly. Two of the five defects were sitting in the scripts that incident forced open. The other three surfaced the same day in a system that shares nothing with it.

Defect 1: a config key three files declared and nothing read

This is the purest instance of the pattern, so it goes first.

source.verify_before_push was true in the config. It was in the JSON schema as a const. It was in a test fixture. Three producers, two of them shown here:

// excerpted from two separate files, not one document

// offsite-backup.config.json
"verify_before_push": true

// offsite-backup-config.schema.json
"verify_before_push": { "const": true,
  "description": "only a borg-check-verified source may be pushed (the check-then-mark discipline)." }

Zero consumers. Not one line of the push script ever read it. A schema that constrains a value nobody reads is documentation with a type annotation on it.

It was a live near miss on 2026-08-05 itself. The replica pull had failed all three attempts that day and left a torn repo, which is exactly the state verify_before_push was declared to refuse, and nothing was there to refuse it. Here is the enforcement that did not exist until that afternoon:

# Honour source.verify_before_push. Until 2026-08-05 this config key was declared true and read
# by nothing.
[ -f "$SRC_OK" ] || die_live "verify_before_push=true but no source verification marker at $SRC_OK, refusing to push an unverified repo."
[ "$ok_age_h" -le "$SRC_OK_MAX_H" ] || die_live "verify_before_push=true but source last verified ${ok_age_h}h ago (max ${SRC_OK_MAX_H}h), refusing to push a stale/unverified repo."

Note what changed and what did not. The config did not change. The schema did not change. The fixture did not change. Only the reader was added, and the invariant went from decorative to binding.

b2-offsite-push.sh also had no test suite at all, despite being the script that failed silently for eight nights. It got 6 hermetic cases (stubbing sops and rclone) plus 4 on the sibling suite for the size floor, wired into ci:drills. An untested script is another producer without a consumer: nothing was reading its behavior either.

Defect 2: a manifest with a writer and no reader

The next three defects come from a GitHub webhook receiver built the same day. State the important thing first, because everything below describes hardening against hostile traffic: it is not deployed. No host has run it, no delivery has reached it, and everything here was proven in drills. That is also why these three were findable at all.

Caught in review. The best line of the day is the author conceding it in the thread (punctuation normalized to house style, wording otherwise as written):

I shipped the WRITING half of manifest verification and cited AAR 000-docs/145 as design authority. With no reader, that citation is decorative and the AAR-145 failure mode is straight back in place. The entire point of that incident was that a hand-copied collector file ran for two nights because nothing checked it. A manifest nobody reads is a comment with a hash in it.

AAR 000-docs/145 in one line: on 2026-08-02 a partial hand copy of a collector script bypassed install.sh, and the deployed copy ran for two nights failing manifest verification. Manifest verification has to run on every start, not be cited in a review.

The fix:

#!/usr/bin/env bash
# verify-manifest.sh: refuse to start a deployed copy that does not match its manifest.
# Runs as the FIRST ExecStartPre, before the secret is even materialised.
set -euo pipefail

HERE="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
MANIFEST="$HERE/receiver.manifest.sha256"

fail() { echo "verify-manifest: FAIL: $1" >&2; exit 1; }

[ -f "$MANIFEST" ] || fail "manifest missing at $MANIFEST, deploy via install.sh, never hand-copy"

( cd "$HERE" && sha256sum --check --quiet "$(basename "$MANIFEST")" ) \
  || fail "deployed copy does not match its manifest, redeploy via install.sh (AAR 000-docs/145)"

The actual design decision is not the script. It is where the script sits in the unit file:

[Service]
ExecStartPre=/opt/intentsolutions/github-webhook-receiver/current/verify-manifest.sh
ExecStartPre=/opt/intentsolutions/github-webhook-receiver/current/deploy-secret.sh
ExecStart=/opt/.../current/venv/bin/python /opt/.../current/receiver.py   # paths elided

Verification runs first, ahead of secret materialization. A copy that does not match what was reviewed should be refused before it is handed a secret, not after. The rest of the unit is hardened deliberately rather than decoratively, because this process will terminate untrusted internet traffic once it is deployed: a dedicated unprivileged user, NoNewPrivileges, ProtectSystem=strict, MemoryDenyWriteExecute, a syscall filter, and RestrictAddressFamilies limited to inet. ReadWritePaths is enumerated rather than inherited, so the deployed copy would be read only to the service and a compromise could not rewrite its own binary and survive a restart.

The proof got three assertions, not one, because “the file exists” would have been the same defect at one remove: the unit references it, it runs FIRST, and it actually refuses a tampered copy. That last one is proven by tampering a byte, not by reading the script.

Defect 3: a grant held on vocabulary rather than usage

The claim in the database review was “append events, nothing else.” It was false. The writer role also held SELECT and INSERT on dlq, and nothing drilled it.

Investigation showed the grant was never needed. grep -n dlq ops/github-webhook-receiver/*.py returns nothing. The receiver marks dead-letter state via outbox.status. The dlq table belongs to process_poison() downstream. The grant existed because the word dlq was in the design vocabulary, not because any line of code used it.

A grant belongs in this list because a grant is a claim about what code will do. A privilege audit that only asks whether the grant exists will pass this every time. It is written by one party, addressed to a second, and its correctness depends entirely on a third thing that may not exist: the code that uses it. An unused grant is a declaration with no consumer, and unlike a stale config key it is also standing attack surface.

GRANT  SELECT, INSERT ON outbox TO ghwh_writer;
REVOKE UPDATE, DELETE, TRUNCATE ON outbox FROM ghwh_writer;

GRANT  SELECT, INSERT ON delivery_seen TO ghwh_writer;
GRANT  UPDATE (redeliveries, last_seen_at) ON delivery_seen TO ghwh_writer;
REVOKE DELETE, TRUNCATE ON delivery_seen FROM ghwh_writer;

REVOKE ALL ON dlq FROM ghwh_writer;
REVOKE ALL ON published_log, consumer_offsets FROM ghwh_writer;

A second gap surfaced in the same review round, and it is a different bug class worth naming as such. body_sha256 was protected by a column-scoped GRANT only, while the narrative claimed database-level enforcement. That is an overclaim, not an unread artifact. An attacker on a privileged connection could have forged the recorded hash, which would make a replay-with-modified-body indistinguishable from an ordinary redelivery, silently disarming the only signal the system has that the webhook secret leaked. Fixed with a delivery_seen_identity_guard trigger, so the constraint holds against any connection rather than against one role’s grants.

Both fixes are net privilege reductions, which is the right shape for a review round on something internet facing. In both cases the reviewer offered the easier path, “narrow the claim,” and in both cases making the claim true was the better trade. Ten assertions now establish what the writer role CANNOT do. The framing that produced them: assume the process whose job is to terminate untrusted internet traffic is one day compromised, and ask what the attacker gets. A role that merely works is not a role that is bounded. Both migrations are applied twice in the drill to prove idempotency, because a redeploy that is a coin flip is not a deployment.

Defect 4: an alert callback that was dead on arrival while every status code stayed correct

The receiver’s error paths all called _alert. In the drills, every one of those calls raised TypeError and the broad except swallowed it. HTTP responses stayed correct through all of it, which is exactly why nothing looked wrong.

def _alert(self, title: str, detail: str, severity: str, topic: str) -> None:
    """Dispatch an alert. Never changes the HTTP outcome.

    `on_alert` is stored via staticmethod (see make_server). A plain function assigned to a
    class attribute is BOUND as a method on access, so `self` would arrive as the first
    positional argument and every call would raise TypeError, which the broad `except`
    below then swallowed, leaving the alert path dead and silent. That exact bug shipped
    here once and was caught only because the proof asserts an alert was recorded, not just
    that the status code was right. Assert on the side effect, not only the response.
    """
    cb = getattr(self, "on_alert", None)
    if cb is None:
        return
    try:
        cb(title, detail, severity, topic)          # <- raised TypeError on every call
    except Exception as exc:
        self.metrics.inc("alert_dispatch_failed")   # <- added: the swallow now counts
        print(f"github-webhook-receiver: alert dispatch failed: "
              f"{exc.__class__.__name__}", file=sys.stderr, flush=True)

The broad except is the right call, because an alerting failure must not change the response code that drives GitHub’s retry semantics. What was missing was that it swallowed silently. It now increments a counter and writes to stderr, so a dead alert path is locally observable rather than invisible. The actual bug was one word at the binding site:

# staticmethod: a bare function here would be bound as a method on attribute access and
# receive `self` as its first argument. See Handler._alert.
Bound.on_alert = staticmethod(on_alert) if on_alert is not None else None

This is the shape at the call boundary rather than in a file. The consumer existed and was correctly configured. Every error path reached for it. Not one call ever arrived, because the dispatch died one frame before it. It was found only because the proof asserts the side effect rather than the response code.

Why this one mattered more than it looked. A GUID arriving with a different body whose signature verifies is explainable neither as a redelivery nor as a forgery. It is a replay attack with a modified payload, and it is only possible if the webhook secret leaked. The receiver refuses to persist, answers 401, and raises a security-severity alert. For the life of the bug that alert would have gone nowhere, and the 401 would have looked like an ordinary rejection.

Defect 5: a mirror check that verified the wrong thing

devbox-borg-push.sh verified that the copy matched the source. That is the check that reports green fastest when the source has been destroyed.

An emptied source would rsync --delete straight through to the VPS, satisfy the zero-differing-files check, and write a GREEN .ok over a destroyed backup that the home server then mirrors within six hours. Three tiers of backup, all consistent, all empty.

MIN_RATIO_PCT="${DEVBOX_BORG_PUSH_MIN_RATIO_PCT:-50}"
MIN_SRC_KB="${DEVBOX_BORG_PUSH_MIN_SRC_KB:-1048576}"   # 1 GiB absolute floor
MAX_DELETE="${DEVBOX_BORG_PUSH_MAX_DELETE:-2000}"      # rsync aborts past this many deletions

# Source-plausibility floor (green-on-destruction guard)
[ "$src_kb" -ge "$MIN_SRC_KB" ] || fail "source $SRC is ${src_kb}KB, below the absolute floor" 6

if [ -f "$LASTGOOD" ]; then
  last_kb="$(cat "$LASTGOOD" 2>/dev/null)"          # size of the last VERIFIED push
  case "$last_kb" in ''|*[!0-9]*) last_kb=0 ;; esac
  if [ "$last_kb" -gt 0 ]; then
    floor_kb=$(( last_kb * MIN_RATIO_PCT / 100 ))
    [ "$src_kb" -ge "$floor_kb" ] || fail "source shrank to ${src_kb}KB from last-good ${last_kb}KB, refusing to push a possibly-destroyed repo" 6
  fi
fi

# --max-delete makes rsync ABORT rather than carry out a mass deletion
rsync -a --delete --max-delete="$MAX_DELETE" --stats -e "$SSH_CMD" \
  --rsync-path="sudo -n rsync" "$SRC/" "$REMOTE:$DEST/"

The load-bearing detail is where last_kb gets written. It is recorded only on the success path, so a refused run can never re-baseline the guard downward. A guard that learns from its own refusals is not a guard.

This is the edge of the class, and the post owes you the honesty about that. Defect 5 is the one that had a consumer. The health monitor read its .ok, the next leg trusted it, and the whole chain would have believed it. It is not an unread artifact. It is the neighbor: an artifact whose reader was asking the wrong question, so the answer, though consumed, carried no information about the thing anyone cared about.

That neighbor is worth sitting next to the other four, because the two failure modes rhyme. Consistency between a mirror and its source is a real property, just not the property you are trying to protect. The old check was not lying. It was answering a question nobody wanted the answer to, which is what an unread artifact would have done if anyone had bothered to read it.

The decisions that lost

Design rationale is only useful when the alternatives are named, so here are the ones that lost.

Python stdlib http.server over Node. Chosen by census, not taste. ops/ holds 1,189 .py files against 6 .mjs, and both recently deployed services are a Python engine with a bash entry point. The more interesting stack would have bought a second deployment shape for one service.

psycopg3 over shelling out to psql. The persist step is one transaction spanning a dedup upsert and an outbox insert, with arbitrary JSON as a bind parameter. A subprocess has no safe parameterization for that, spawns a process per delivery inside a 10 second ack budget, and cannot hold a transaction across two statements.

delivery_seen over the outbox as the replay ledger. This is the one worth stealing. The outbox prunes dispatched rows at 90 days and takes their dedup_key UNIQUE constraint with them, so a 91-day-old replay would sail straight through a system that looked perfectly deduplicated. The drill proves it empirically: age a row past the horizon, run the prune, confirm the outbox row is GONE and the ledger row REMAINS, then replay the GUID and watch it still get refused.

Behavior-based assertions over grep-based ones. Grep checks in this same proof produced two false positives on correct code: the source_repository_id placement, and the comment DOCUMENTING the eval-sops anti-pattern being flagged as the violation itself. A test that fails on correct code is worse than no test, because it trains you to ignore the output.

Versioned releases with an atomic symlink swap over in-place copy. install.sh writes releases/<sha>/ and repoints current, so rollback is a rename rather than a re-copy, which matters for a service that is mid-flight when you roll it back. It refuses a dirty working tree, because deployed copies come from origin/main and never a worktree. The venv lives INSIDE the release directory (PEP 668), so a rollback restores the dependency set that release was tested with. It ships BOTH schemas, because without the second one validation attempts a network retrieve and dies on a 404. That bug already landed here once.

Fail closed on secret materialization, with no “start anyway and warn” path. deploy-secret.sh pulls the webhook secret from SOPS to tmpfs and refuses to start if it cannot. It extracts two named keys with an anchored sed and never evals or exports, because the estate has a recorded 2026-05-02 incident where eval-ing sops output turned comment lines into bare export and dumped every exported variable to stdout.

One more, on process rather than code. A regression guard was demonstrated firing before it was trusted: re-introducing the alert-wiring bug produced 17 passed and 3 failed, naming the wiring check, and restoring the fix produced 20 and 0. The rule stated in that PR is a guard that has never failed is a comment, which is this same defect class wearing a test harness.

What this cost

Every one of those calls bought something and gave something up. Honest accounting:

• The size floor and --max-delete trade a class of false refusals for protection against silent destruction. A legitimately shrunk repo, say after a deliberate prune, now needs a human to unblock the push. Real on-call cost, paid forever, against an event that has not happened yet.
• Fail closed on the secret means a SOPS outage takes the receiver down rather than degrading. That costs availability. A service that keeps answering without its verification secret is worse than one that is down, but “worse than down” is not “free.”
• The retroactive governance rule creates visible unpaid debt. Several already-running production subsystems now fail a bar they were never built to meet. Making that debt visible is the point. It is still debt, and nobody has scheduled paying it.
• Eleven PRs merged in one day via the repository-admin bypass. The only unmet rule was the approving review count, which the author cannot self-provide, and no CI gate was bypassed. Moving eleven changes through a lock in one day is still a governance smell, and saying otherwise would be exactly the kind of decorative claim this whole post is about.
• The receiver is not deployed. No host has run any of it. Everything above is proven in drills against a disposable Postgres, 29 assertions in one round, ten of them the negative cases. Drills are not production, and this corpus has a whole post about that gap.

The governance turn

Eleven PRs merged in intent-os on 2026-08-05. The nine this post covers are the post-incident batch, #376 through #384. Four of those were governance, carrying the rulings below in bundles rather than one per PR, and they were written by a different thread than the one finding the defects.

Three of the rulings set up the fourth. D155 makes every operational subsystem self-reporting to Mission Control (the generated cockpit this estate runs itself from): backup, deploys, observability, evals, repo sync, agents, GitHub, all emitting machine-readable health so status is generated rather than assembled by hand. D161 turns that into an admission test every new feature must pass. D162 revises the drift rule so findings cluster into owner-approved recommendations instead of each becoming a backlog item, justified by measurement rather than estimate: the standing set is 92 findings, and the largest class of 50 turned out to carry exactly two root causes. Measuring it refuted the author’s own stated cause along the way (the claim that they were “largely refs into the archived vps-runbook” held for only 10 of 50), after a reviewer challenged the number as self-cited.

A retraction, carried into three documents, sits in the middle of that. The session had claimed WIP was at its limit and deferred Phase 1 backup hardening on that basis. False: the validator counts in-progress EPICS and reported 1 of 2. Nothing was blocked, the deferral was self-imposed, and the same misreading became an owner-facing ask for a ratification estate law never required. Worse, decision-log/043’s Status section had been rewritten IN PLACE, violating append-only law in the one directory where it is absolute. The original was restored verbatim with the false sentence struck through and marked [RETRACTED], because a reader auditing why Phase 1 was deferred needs to see the claim that caused it.

D164 is the one that matters here. Nothing becomes OPERATIONAL until it can answer seven questions:

1. Who produced this?
2. When?
3. What changed?
4. Can it be replayed?
5. Can Mission Control consume it?
6. Can an agent consume it?
7. Can an executive understand it?

The ordering is deliberate. Questions 1 through 4 are machine-answerable properties of the DATA. Question 7 is a human-answerable property of the PRESENTATION.

The gap it closes is specific. The implementation-evidence standard asks “did you prove it works,” and D161 asks “should it exist.” Neither asks whether the estate can actually USE what you built, so a subsystem can pass both and still be a dead end: correct, tested, deployed, and legible to nobody but its author. Read questions 5 and 6 again. That is the day’s five defects, generalized, written by a thread that had not seen any of them.

D167 creates the Estate Capability Matrix: one GENERATED page with Capability, Engine, Health, Last Sync, Owner, Evidence. One row per capability INCLUDING Planned ones, which render with empty cells, because an unfillable row is itself evidence of a gap. Omitting the planned capabilities because they have nothing to report would hide exactly what the page exists to show. It asserts nothing of its own, composes existing projections, and shows unknown LOUDLY rather than blank.

D169 makes D164 permanent architecture, binding on every subsystem INCLUDING ones already in production. Retroactive on purpose: backup, SigNoz, Intent Eval, the agent gateway and others are now measured against a bar they were not built to, and several will fail it.

D167 and D169 landed in the same pull request, and the blueprint states the pairing outright. A rule whose violations nobody can see is a preference. The capability matrix is the surface that makes D169’s bar visible across systems that already run. Without it, D169 is an assertion nobody can audit. With it, the gaps are a column. Which is the thesis applied to the thesis: D169 is itself a produced artifact, and the same diff that created it gave it a reader.

Why producer-without-consumer defects hide longer than the alternatives

Dead code is easy. A linter finds it, a coverage report finds it, and deleting it is safe because nothing calls it. Dead contracts are the inverse and no linter can see them, because the producer is valid, well-formed, and often beautiful. The defect is the absence of a consumer, and absence has no syntax. There is no node in the AST for “nobody reads this.” The catalogue is longer than most people admit: schema fields validating a value no code path consults, feature flags no branch checks, metrics emitted to a dashboard nobody has opened since the quarter it was built, manifests written on every deploy and verified on none, grants held on vocabulary rather than usage.

The industry has solved narrow slices of this and named none of them together. Postgres ships pg_stat_user_indexes, so you can find indexes nothing scans. Feature-flag platforms report stale flags. Linters find unreachable branches. Each is the same query asked once, inside one substrate, by a tool that knows only that substrate: which declarations here have a producer and no consumer. I have not found anything that asks it of your config keys, and nothing that asks it across substrates, which is the only vantage from which the pattern is a pattern at all.

Test theatre is the better-known cousin, and it is genuinely different. Test theatre gives you a wrong green: a suite that passes while asserting nothing meaningful. You can catch it by mutating the code and watching the suite stay green, and this corpus has done exactly that more than once. The unread artifact gives you no signal at all, which is indistinguishable from a healthy quiet system. There is no mutation you can make to a config key nobody reads that changes any observable behavior. That is why it survives longer. When the drills passed and reality did not, the tests were at least answering. These were not.

The detection method that actually worked on 2026-08-05 was embarrassingly simple. For every declared invariant, grep for its reader. grep -n dlq ops/github-webhook-receiver/*.py returned nothing, and that single empty result was the whole investigation. Do it for every config key, every flag, every manifest, every grant. Producer count above zero and consumer count at zero is the signature.

Also shipped

• Two grouped dependabot bumps opened on bobs-big-brain-registrar, both still open, and the 2026-08-04 field note went out through intent-solutions-landing and claude-code-plugins.
• The blog pipeline was itself a casualty of the disk. The 04:00 cron for the 2026-08-04 post died without even writing a log, so the post was backfilled by hand at 18:02 with the cron-identical wrapper. A pipeline that cannot log its own death has the same defect as b2-offsite-push.sh.
• An operational trap got documented: the CI runner is self-hosted on the dev box, so a local pnpm check racing a CI job produces spurious failures. Eleven fake watchdog failures appeared in CI while the same gate was 23 of 23 green locally. An untouched re-run passed 4 of 4 jobs.

Related Posts

• The Filesystem Was the Only Thing They Shared
• The Check That Only Confirmed a Name
• The Drills Passed. Reality Did Not.