This one covers a morning, from just after midnight to about eight, with a gap in the middle. I won't pretend it's more than that. The thread that ties it together showed up three separate times before breakfast: something told me it was fine when it wasn't.
A fix that finished, then got quietly undone
The main piece of work was closing C1, the critical finding in the board tool's design: a card in the backlog can carry an evidence_cmd, a command that proves the card's work is done, and if that field is ever handed to a shell it becomes a remote-code-execution primitive sitting in the ledger. Closing it needed two separate things to be true. First, shape: never build a shell string, ever, from that field — argv only, absolute-path binary resolution, an allowlist of argument shapes, a dedicated denial exit code, a 120-second timeout. Second, provenance: prove the command can only ever come from the trusted ledger, not from anywhere a stranger could write to.
Mutation-testing the executor caught a real bug on the first pass. Flipping shell=False to shell=True should have made a test fail cleanly. Instead it hung, because stdin wasn't redirected — a piped payload left the child process blocking on inherited input forever. Fixed with stdin=DEVNULL.
Then the first instance of the morning's pattern. A mutation-test job had started running before that stdin fix landed, kept going in the background, and finished afterwards. Its last step restored the executor from a backup — quietly undoing the fix I'd just applied, with no error and no message. I only caught it because the job's completion notification prompted a re-read of what its final step had actually done. There was no security regression; the argv-only behaviour had survived. But the hang fix had to be reapplied, and the stale backup files got deleted so nothing else could do that again.
The provenance half followed: check now reads evidence_cmd only from the backlog file, never from a card's description, comments, or labels. The test for it plants a hostile command in all three of the wrong places — description, a comment, a label — with a benign one sitting in the ledger, then asserts the tool runs the ledger's command and never even fetches the comments. Mutation-verified: making check prefer the card's own description instead fires five assertions and names the hostile payload by name. One more gap surfaced while I was in there — "no write path to the backlog file" had only ever been enforced by a docstring, not by code, so that got a structural guard test of its own. C1 closed, both halves.
Root-sitting, and a security fix that measurement disproved
Separately I worked through a root-privileged checklist at the keyboard, setting up a sandboxed worker identity on the main host — ACL tooling, a new account with no sudo, docker, lxd or adm membership, vault ACLs, the binary pinned immutable, OAuth login done. Steps 1 through 7, all clean, with one false alarm along the way: the runbook's expected lsattr output didn't match what the box actually showed, but the difference was just the normal ext4 extent-format flag, not a fault. Runbook corrected.
One real gap turned up reading the sudoers file — the reboot permission is looser than I'd assumed, which is worth having written down properly rather than half-remembered. It also meant correcting a standing claim that "Claude has no sudo here" — the automation account is the account Claude runs as, and passwordless sudo needs no TTY. Both went into the record straight.
The better beat, though, was a security check that got disproven by its own measurement. A socket-isolation probe first came back inconclusive, because the script couldn't find its own file — turns out DynamicUser=yes implies PrivateTmp=yes, which hides a probe from every test variant that writes to /tmp. Fixed with a read-only bind. The clean re-run then showed that the drafted fix — naming three specific paths as inaccessible — failed empirically, leaving three sockets wide open. Denying the whole runtime directory, rather than picking paths inside it, is what actually closed it. The shipped unit file still had the disproven variant in it; that got corrected too.
A mirror that had never worked
I asked for the C1 fix ported into plankamd, the public generalisation of the board tool. That work stayed off subagents deliberately — the stated reasoning was blunt: on this project agents have previously produced a bypass envelope, an unauthorised DNS grant, and verification batteries that passed green over broken subjects, which is a poor track record for code that gates whether a card can be closed. So the allowlist went in by hand, made data-driven through a config table, 302 tests passing, version bumped, tagged, pushed.
That's where the second instance of the morning showed up. Forgejo reported the push-mirror sync to GitHub as succeeded, its last_update timestamp advancing. git ls-remote against the actual GitHub remote told a different story: zero branches, zero tags, and had been empty since the repo was created a day or two earlier. The cause was specific — GitHub rejects any ref update that creates or modifies a workflow file from a token that lacks the workflow scope, and this is the only one of five mirrored repos that carries one (.github/workflows/ci.yml). The exact rejection: "refusing to allow a Personal Access Token to create or update workflow .github/workflows/ci.yml without workflow scope." This is the runsheet's own documented trap, biting a second time — last_update advancing was never evidence of anything; only the real remote is. I added the scope to the token, said so, and the next sync pushed all three refs on the first try. Verified by installing the published tag into a clean environment straight from GitHub and confirming it resolved to the right commit and ran clean.
A push that didn't deploy
The last one folded in from a website correction. I'd flagged that the site's hardware numbers were stale — the second node's memory was wrong, and a node's model name was missing "Micro" — so every hardware claim on the site got checked against the running systems and corrected across four pages, including a portfolio card that predated the second node entirely and still described a DNS filter decommissioned weeks earlier.
Committed and pushed. All three remotes agreed, nothing errored. And the production deploy for that commit sat in a BLOCKED state and never built, because the linked repo had been switched to private at some point after 2026-07-27 — the deployment metadata read githubRepoVisibility: "private" where every earlier successful deploy read "public". Production kept quietly serving the old build the whole time. The workaround exported the exact commit to a clean temporary directory rather than deploying the working folder directly, to avoid publishing anything that had deliberately never been pushed; the first attempt at that failed with a path error because the deployment link only resolves inside a real git worktree, fixed by switching to a plain project link. The deploy went READY and got confirmed live on both domains by fetching the actual page HTML, not by trusting a 200. I flipped the repo back to public at 07:56. Whether a normal push will trigger a clean deploy again from here on is untested in this window — I'm not calling that fixed, only worked around.
Three times, in the space of a few hours: a job that said done and had reverted the fix, a mirror that said synced and had never had a single branch on it, a push that said clean and never reached production. The rule for all three is the same one: check what the thing actually produced, not what it reported.
Somewhere in catching up the backlog of journal entries after this, I nearly filed several of them under the wrong dates — the transcripts are timestamped UTC and the day is lived eight hours ahead of that, and only comparing a commit's local timestamp against its transcript timestamp caught it before anything got misfiled. The morning wasn't over when this got written up.