Issue 12: The Vacuous Green Returns

The Finding

This week the studio discovered something sharper than a bug: a pattern. Five times, work that looked complete was not. Success signals fired while core tasks stayed open. Every time the studio caught it, fixed it, and recorded the diagnosis in receipts, with timestamps where the recovery was visible on the wire. (This issue's material is sourced from internal vault diagnostics; external research pipeline has been down since 2026-08-01, and recovery is tracked separately as an owner-blocked item.)

Issue 6 asked a theoretical question: how does a check that never ran look the same as one that passed? This week answered it practically: when no one asks whether the check was wired to run in the first place.

From game theory, Schelling's "Strategy of Conflict" (1960) distinguishes commitments from threats: a commitment removes your own option to defect (you burn the bridge), while a threat merely reprices defection (the threat could be empty). A guard on a system's only path of action removes the option to route around it; an orphan guard, built but unwired, leaves the bridge standing. A system that catches its own unused guards before they cause failures removes a defection path from itself: there is no stable state where false completions compound into worse decisions later.

The difference between a guard that works and a guard that merely exists is wiring. A guard in the codebase is potential enforcement. A guard on the path the system actually takes is enforcement that enforces. This week the studio found five instances of exactly that gap: guards built but not wired, a render step trusting numbers it never checked, a tool correctly reporting an empty queue as if that were a malfunction, and a meter that went silent instead of screaming "I cannot measure this."

The Audit

False completions this week took five shapes. Each exposed a different gap in how a system can lie to itself.

Built Without Wired

bsg-lopt-resolve.py is a utility that auto-locks L-OPT deadlines when their date passes. It was written weeks ago, sits in the studio's scripts directory, and works perfectly. The studio's newsletter pipeline needed it for Issue 12, whose deadline was 2026-08-10. The deadline passed. The utility was never called.

Result: The L-OPT stayed unlocked. The commission never wrote. The generate step skipped the issue (gate=NO_GATE). The pipeline reported that the publish gate had run; the all-clear came back. But the gate had never checked anything. The tool existed. It simply did not run. When a tool sits in the repo and nothing invokes it, success signals that come back from the pipeline are not about the tool. They are about the absence of the invocation path.

Receipts: root cause verified, 2026-08-13T08:42:07Z; Issue 12 recommissioned and the fault filed, 2026-08-13T08:45:30Z; wiring fix committed and in force, 2026-08-13T10:07:55Z.

Detective, Not Preventive

Canonical store truncation discovered a read-modify-write bug that was losing lines from the studio's receipts log. The fix was append-canonical.sh, which uses O_APPEND and flock to make truncation impossible. The guard was built. It was not in-force until this week.

What made it visible was a completions field confidently reporting work done, based on line counts just cut from 376 to 13. No one noticed until a sweep-time audit compared against a baseline. The system lied first; the audit caught the lie second, three hours late. The difference between a guard that stops a problem and one that only audits it is timing: before the damage, or after. That guard was built preventive, in-path, refusing to write on truncation, but had never been wired to run on every receipt write. This week it was. Now truncation cannot happen silently.

Receipts: root cause closed by the preventive guard, wired to all append paths, 2026-08-13T09:36:30Z.

Rendered Without Verified

Dispatch divergence. The studio's intake pipeline reports health as IN=0 OUT=0 - all consumed, nothing stuck. This week it reported that with 48 dossiers sitting unprocessed in the queue. The completions meter read zero pending. The ground truth read 48 pending. The display said both, loudly, as if they were independent facts.

The guard logic existed (an assess-ack arm inside ingestion-reconciliation.sh, comparing expected-routed manifests against landed counts). It had been built correctly. It was never invoked, because the heartbeat that would have called it had been dead 24 days on an unrelated wiring gap. The render-views step was outputting data without checking that the numbers in the source matched reality.

Receipts: Claimed 08:35:39Z; measured divergence of 48 in against 0 out, wired the acknowledgement arm, completed 2026-08-13T08:42:29Z.

Confusion: Ran vs. Advanced

lp-research-stage.py is a tool that moves LPs through their lifecycle stages. It was asked "why haven't you advanced anything in three days?" The answer was simple: because zero LPs remain in stage "observed" - the queue is empty. When the queue is empty, the tool correctly advances nothing. Every receipt it generated said advanced_item_count: 0. The studio saw "advanced 0" and asked whether the tool was broken. It was not. The queue was drained.

The confusion: "ran but found nothing" looks like "did not run" on a receipt. The real fix is one field in the receipt format: how many items were in the input queue, not just how many came out. That field does not exist yet. What exists today is the manual version, a person writing the queue breakdown into the receipt note by hand, more than thirty times this week, before concluding the tool is correct. A working discipline is not an encoded guard, and naming that gap honestly is this issue's own thesis, applied to itself.

Receipts: One at 07:05:51Z, the 34th confirmation, and one at 09:33:40Z, one of many repeats since: each independently re-verifies lp-research-stage.py --dry-run --verbose is advancing zero items because the observed-stage queue is genuinely empty, not because the tool is broken.

Truth Claim Without Evidence

The status file, the intake pipeline's only status page, reported zero completions for three hours this week. Nine were happening. The meter behind the field, ccusage, reads token usage from Claude Code sessions; it was installed, but its PATH was broken in the systemd environment, so it could not be found and failed silently. The surface rendered zero as fact, not as "cannot measure."

The fix: make the meter fail loudly, exit non-zero, and always report sample size, so a zero meaning "measured nothing" is visually distinct from a zero meaning "nothing there."

Receipts: Sample-size reporting added to the status surface and the usage sweep, 2026-08-13T08:57:20Z; the PATH fix confirmed in the service environment, exiting non-zero on failure, 2026-08-13T10:15:00Z.

The Evidence

Five cases from the vault, each recovered and documented in receipts:

• Issue 12's deadline resolver, built but unwired, diagnosed then wired the same day
• A canonical store truncated from 376 lines to 13, preventive guard closed and wired
• The intake pipeline reported zero in and zero out with 48 dossiers actually pending, acknowledgement arm wired in
• lp-research-stage advancing zero items daily: queue empty, or tool broken? Verified by hand over thirty times; the receipt field that would end the hand-checking is not yet built
• ccusage meter silent on a broken PATH, the intake pipeline's status page rendering zero completions as fact; PATH and sample-size reporting fixed

Timestamps verified from internal receipts logs (rows 1801-1849, 2026-08-07 through 2026-08-13).

The Numbers

Four of the five instances this week reached in-force status: a real guard, wired, self-tested, running on every relevant action. The fifth is still a manual discipline, named honestly below rather than counted as something it is not:

Each in-force row tells what happened: the failure was diagnosed, the fix was built or wired, and the studio proved it was running via receipt traces and test fixtures, not asserted. The one manual row is not a smaller version of the same thing; it is the honest admission that catching a failure reliably by hand, more than thirty times, is not the same claim as a guard that runs unattended.

The Fix

The principle that runs through the four wired repairs is simple: make the check preventive, not detective. Make it run before the system can corrupt itself, not after. Make it fail loudly instead of silently. Make it part of the path the system actually takes.

The first was one added call, try_resolve_pending_lopt, before the generator runs: wiring, not new code. The second was adding calls to append-canonical.sh on every receipt write: wiring again. The third was adding the acknowledgement arm to the intake loop: wiring. ccusage was correcting the PATH and adding an exit code. lp-research is the one still open: a single field on the receipt format so "0 out of 0 in the queue" reads differently from "0 out of many, and something is wrong." Not yet built. All five point at the same thing: making the system's state visible and checking it before it lies, whether the check is code or, for now, a person doing it by hand.

Free Tool: Guard-Wiring Auditor

To find guards that are built but never invoked, run this free auditor on your guard directory and your entry points. Standard library only. This is a file-level check: it catches a guard file nothing calls (the built-without-wired and detective-not-preventive failure class). It does not catch a guard that is wired but checks the wrong condition, an unwired function living inside a file that is otherwise called, or a silent environment failure like a broken PATH. Those are different failure classes, not this tool's job.

#!/usr/bin/env python3
"""guard-wiring-auditor.py - Find guards that nothing reaches.

For each candidate guard file in a directory, answers: (1) does the file
exist? (2) does any named entry point reference its filename?

Verdicts: ENFORCED (exists, referenced by at least one entry point),
ORPHAN (exists, referenced by none).

File-level only: does not follow indirection through systemd units, cron,
or cross-script calls the entry-point list omits. Widening the entry-point
list is the operator's job, not the tool's.

Usage:
    python3 guard-wiring-auditor.py
    (edit ENTRY_POINTS below to point at your real runners)
"""
from pathlib import Path

GUARDS_DIR = Path("scripts")
ENTRY_POINTS = [
    "scripts/nightly-sweep.sh",
    "scripts/work-heartbeat-gate.sh",
    "scripts/queue-consumer.sh",
]

def main():
    entry_text = "\n".join(
        Path(ep).read_text() for ep in ENTRY_POINTS if Path(ep).exists()
    )
    guard_files = sorted(
        f for f in list(GUARDS_DIR.glob("*.py")) + list(GUARDS_DIR.glob("*.sh"))
        if f.is_file()
    )
    enforced = orphan = 0
    for f in guard_files:
        wired = f.name in entry_text or f.stem in entry_text
        print(f"{'ENFORCED' if wired else 'ORPHAN'}: {f.name}")
        enforced += wired
        orphan += not wired
    print(f"\n{enforced} enforced, {orphan} orphan, of {len(guard_files)} scanned")

if __name__ == "__main__":
    main()

Run against this studio's own scripts directory (591 files) against three real entry points, it printed 139 ENFORCED and 452 ORPHAN. Read that number correctly: it is not a claim that 452 guards are genuinely dead. Most of this studio's scripts are wired through systemd units, cron timers, and cross-script calls that a three-file entry-point list cannot see, so most of those 452 are false positives of the tool's own stated limit. The finding is not the count. The finding is that a narrow entry-point list manufactures a large, wrong, confident-looking number, which is the same failure class this issue is about, one level up: a tool that can lie to its operator the same way a wired-but-uninvoked guard lies to a pipeline. Point it at your own entry points, all of them, or read every ORPHAN verdict as a lead to check by hand, not a verdict to trust.

Readers wanting to verify this issue's claims: each LP cited below carries a section titled "in-force" that names the exact guard that proved it is running, along with a command you can re-run yourself to confirm the status today. The evidence is not in the write-up; the write-up points to it. That is the guard-first discipline: make the proof runnable, not narrative.

Guard Execution Memory. The Guard-Wiring Auditor reports which guards are wired right now. Execution Memory records every firing over time, so a guard that stops firing after a refactor is visible as a gap in its own history. Available now to Pro subscribers.