A green check lied, so I built append-only status

On 2026-09-25, a green report lied to me after a blog recovery worked. A later no-op report buried the fix. That false green is what I spent the day on. I put the repair in config/reporting/ across four commits: 42dfa07b6, b75ad7036, f94294a40, and 23879a4c5.

Why did a green test report lie about my build?

A green test report lies when a pass signal records absence of a crash instead of positive proof. On 2026-09-25, my sweeps showed green while checks inspected zero files. A reporting layer must demand explicit receipts before it declares any job healthy.

SecurityAnalyst marked its scan GREEN with 0 P0 and 11 P2 issues. But gitleaks and osv each read 0 of 5 repos. That unaudited GREEN did not cover five critical findings a separate dependency audit found in bmdpat and agent47-dashboard. Repair PRs 1629, 1724, and 271 sat undecided.

The sweep aborted before dispatch after 22 minutes. An environment listing exposed the Brain signing credential. Zero cards attempted, 45 skipped. Credential P0 hit 19 days. Vault health stood CRITICAL with six staged Outbox drafts past TTL. Across 1,027 ledger rows, 44 failed, with pi-researcher-sync taking 19. The full suite sat RED at 552 of 553. Devlog-daily failed on 2026-09-24 after three attempts.

Brain worker 21:11 shipped 4 items, 0 to patrick/. Loops had 451 sessions, 5 CTA clicks, and zero install intents. In BMD, see what your agents actually did, you track real action instead of assumptions. You must verify what an agent actually produced before trusting a report. Missing evidence is unknown, not green.

How do you stop a later job from burying a real fix?

You stop later jobs from erasing fixes by storing append-only event receipts instead of mutable state. When each run writes an immutable log, no failed attempt can delete earlier progress. Your status engine can then project health without rewriting history.

I built config/reporting/ to enforce this rule. It writes append-only receipts on the existing Reports/Events/ authority. Markdown files become generated views, never input for status decisions. I recorded the decision in Knowledge/decisions/2026-09-25-shared-reporting-contract.md.

When you give an agent a file, not a memory, you keep receipts that survive bad runs. That design allowed me to close two real false greens on 2026-09-25:

What happens when a fuzzer tests your reporting layer?

A fuzzer exposes edge cases by feeding millions of malformed records into your replay parser. On 2026-09-25, my fuzzer ran three million generated inputs across ten seeds. It killed every seeded mutant. The parser held on that generated set.

I pointed the fuzzer directly at config/reporting/. It ran 3,000,000 cases over 10 seeds on malformed inputs and replays with zero failures. Ten seeded mutants were all killed. The engine replayed 10,000 receipts in 0.44 seconds.

I wanted eight nines of reliability. I got 3,000,000 cases without failures. But generated fuzz tests are not production trials. The test receipt records that limit. Bonsai 27B vs Gemma 4 E4B went live at HTTP 200 with two dev.to cross-posts. On bmdpat, PR #1836 and docs PR #1839 merged to match accessible names rather than decorative glyphs.

Who I was on 2026-09-25

I asked for a permanent repair after a later report hid a real blog recovery. The result was a shared reporting tool. It keeps the completed work, the latest attempt, and current health separate. I want to read the record without reconstructing the day myself.

I named the failure I wanted to reduce: incorrect status, especially false green. The Codex test receipt records three million generated cases without failures. It also leaves production reliability unmeasured. That limit belongs beside the number. SecurityAnalyst still called its scan GREEN after reading zero of five repositories. A better reporting tool does not repair every report that came before it.

I made the same call twice on 2026-09-25, at two sizes. On bmdpat #1836 I said the arrow glyph is intended, so repair the test helper and leave the card alone. When a check disagrees with the thing it measures, I fix the check.

I also read the X and LinkedIn drafts for BMD and held them. I said I needed to spend 2026-09-26 really using it. Clean copy did not settle whether I was ready to put my name behind the release.

On 2026-09-25 I changed how the machine records proof. I also left myself a test that no agent can finish for me: use BMD before I announce it.

What should you do with this?

You can protect your own pipelines by decoupling event recording from status presentation. First, record every action as an append-only receipt. Next, reject passing grades whenever scanners inspect zero targets. Finally, recheck your failure logs before you trust any green dashboard.

1. Separate event storage from status views. Write raw receipts to disk. Generate summary views only as downstream projections.
2. Require positive proof of scanned targets. If a scanner reads zero files, mark the run as unknown instead of green.
3. Fix test assertions when they disagree with reality. Update the test helper rather than breaking working UI.

Accompanying prompt

What the prompt does: Audits your test suite or reporting jobs for false green status claims caused by unread targets or disabled checks.

Copy/paste this prompt:

Role:
Code auditor specializing in agent status verification.

Context:
Agent runs often return green status when checks fail silently or inspect zero files.

Inputs:
- Tool or test script: __
- Expected input path: __
- Log output file: __

Task:
1. Read the log output file from the tool or test script.
2. Check if the tool read zero targets or skipped files while reporting success.
3. Identify silent failures such as falsey deadlines or empty sweeps.
4. Output a receipt marking status as unknown when evidence is missing.

Output:
- A Markdown table showing checked files, actual targets inspected, and verified status.

Constraints:
- Never mark a job green if targets read equals zero.
- Flag any missing evidence as unknown.

Copy the block above.

Weekly measured local runs: https://bmdpat.com/5090-reports

Get the local AI lab notes (benchmark rows, VRAM fit, quant choices, what runs on consumer GPUs), M-F only when there is something worth sending: https://bmdpat.com/newsletter?utm_source=blog_md&utm_medium=aeo&utm_campaign=a-green-check-lied-so-i-built-append-only-status-2026

Originally published on bmdpat.com. I run a one-person AI agent company and write about what actually works.

Want these in your inbox? Subscribe to the newsletter - no spam, unsubscribe anytime.