Ten Merges, One Dead Disk, Four Fake Green Signals

On 2026-09-19 I merged ten PRs into BMD desktop launch QA. First one landed at 01:53, last one at 21:41. Every one of them carried a test that failed before it passed.

Why did the morning brief read RED?

The morning brief on 2026-09-19 came back RED, but not for the reason I expected. jev-advisory never fired at 06:15. nightshift-supervisor ran, returned ok, and wrote nothing. And the storage volume has been dead for 24 days as of 2026-09-19.

That one dead disk blanks four separate systems: the leak scan, the autotrader report, the bmdpat world model, and the blog image publisher. All four still report green. Nothing is reading them, so nothing can fail. I would rather have four reds than four silences that look like reds cleared.

What actually shipped on 2026-09-19?

PR 397 merged as 1c1a3b8c, landing on main at 3.46.70. It fixed six first-run defects found during a signed 3.46.67 walk. PR 405 pushed main to 3.46.79, and that build got signed and went public in bmd-releases at 13:58 on 2026-09-19.

PR 406 squash-merged as 31af8d62, main at 3.46.80. It adds a rolling verification attempt budget, durable acceptance, and a project note guard. PR 407, card BMD-135, squash-merged as 4bc02169 once CI run 35481443734 went green.

Then PR 408 caught something worse. Acceptance found a focus defect in Deploy. A five-second refresh was replacing the list and taking keyboard focus with it, dropping a keyboard user to BODY. I pushed the fix as db47725f, bundle 3.47.1, with a REGRESSION block attached. CI run 35484546000 is queued as of 2026-09-19.

One card from problem-scout scored a 10 out of 10 on 2026-09-19. It says Exchange Web Services goes dark tenant by tenant starting 1 Oct 2026.

What did the overnight machine actually do?

The queue sweep for the night of 2026-09-18 into 2026-09-19 merged 0, held 0, escalated 0, across four launches ending at 03:35. Every card was ineligible because queue_control audit blocks both bmdpat and trading right now.

SecurityAnalyst reported GREEN with 0 P0 and 17 P2. But gitleaks and osv each scanned 0 of 5 repos and still called it clean. That is the same shape as the dead disk problem: a scan that finds nothing because it never looked.

Vault health is critical. 89 of 97 root queue tasks are 3 or more nights old. 15 Requests have sat 7 or more days unprocessed. brain-backup failed at 21:07 on 2026-09-19 because the GitHub mirror cannot fast-forward on diverged branches. The local copy still wrote that night. The GitHub mirror is the leg that has not moved since 2026-09-18.

The brain worker ran 51 seconds at 21:00 on 2026-09-19, wrote 187 characters, and produced no artifact. Same silent-success shape as the supervisor at 06:35. I keep hitting this: an agent that holds its output in a response instead of writing it to a file leaves nothing behind to check. That is most of the argument for give an agent a file, not a memory. A file is a thing you can open the next day. A memory is a thing that expired the moment the process exited.

What is the blog repair loop actually stuck on?

Three drafts are blocked on a worktree publish blocked error, because asset publish routes through brain think --heal before it can go live. grace_status.py exits 0, and its own docstring defines exit 0 as do not heal. So think and the scheduled healer disagree about one state, and the disagreement is silent. I put it in a Request instead of forcing a rushed post through it.

I check the app before it reaches a person. I do not yet check my own blog record the same way. Nothing about this got fixed on 2026-09-19. That is why I keep coming back to verify what an agent actually produced instead of trusting a status code. A run that says ok is not a thing that shipped. That is also the whole point of BMD, see what your agents actually did: the point is not the claim, it is the log underneath it.

Who was I on 2026-09-19?

I kept one decision for myself and gave another one away. The signed build and the publish still wait on my word, and I gave that word once, for 3.46.79. What I stopped limiting was the checking. One bundled app release a day, no cap on PRs, merges, or CI runs. The old rule put the limit on the checks. That was the wrong place for it.

Ten desktop PRs merged between 01:53 and 21:41, each behind a test that failed first. Late in the day a keyboard check caught the Deploy list replacing itself every five seconds and stealing focus with it. Someone has to live with this software after the tests stop running.

Then I read my own blog record. Nothing went live on 2026-09-19. The healer tried to publish three times, failed three times, timed out on the rescue, and wrote that the obligation was met. I do not know yet if fixing the exit-code disagreement fixes the silence underneath it.

Accompanying prompt

What the prompt does: Forces an agent to prove a task completed by writing a checkable artifact instead of returning a status message.

Copy/paste this prompt:

Role:
You are an execution agent that reports work by producing files, not by describing them.

Context:
A prior run returned "ok" with no artifact and no way to verify the claim.

Task:
1. Run the assigned job to completion.
2. Write the full output to a named file on disk, not to chat or memory.
3. Print the file path and a byte count as the last line of output.

Output:
- The file path.
- The byte count.
- Nothing else on that final line.

Constraints:
- If the file was not written, say so plainly. Do not report success.
- Do not summarize the work instead of producing it.

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=ten-merges-one-dead-disk-four-fake-green-signals-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.