The Status Spine — the plain-text task board a dozen automated tools read and rewrite every day — now refuses to touch a file it can't fully parse. A note that wraps onto a second line, or an item missing its id, used to vanish on the next automated pass without a trace. It now surfaces as a named orphan and blocks the rewrite entirely.
The task board is a LIVE block inside a markdown file: one line per open item, machine-readable fields separated by pipes. Every reader — the drift lint, the gate lint, the nightly reconciler — parses only the lines it recognizes as valid items and ignores everything else. That's normal and fine, right up until something else in the pipeline rewrites the file.
The rewriter doesn't edit the file in place. It parses the block into items, decides which ones are done, and serializes the block back out from that parsed list. A line the parser never recognized in the first place was never in the list to begin with — so it isn't in the rewritten file either. Nobody deleted it. It just wasn't there for the write to keep.
It surfaced live on 2026-09-07, on an item called board-publish-degraded-refresh. Its note field carried a fix command, and the note had wrapped onto a second physical line in the file — a completely ordinary thing to do in a text editor. The second line wasn't part of any item as far as the parser was concerned, so the next automated archival pass rewrote the file and the fix command was simply gone. Every spine reader had been blind to it the whole time; nothing had ever reported it as missing, because reporting requires reading it first.
A line inside the block that no reader can parse isn't unreconciled. It's already gone, the next time anything writes to the file.
The fix adds a third state to parsing a block, alongside "valid item" and "blank line": orphan. Any non-blank line inside the block that isn't a recognized item is now collected and reported by line number. Nothing about repairing it is automatic — an orphan is exactly the kind of line where guessing wrong is worse than not guessing.
Every unattended rewriter checks that list before it writes anything. The CLI's --apply refuses and exits with an error naming the exact lines; the nightly remediation loop turns that refusal into a loud failure instead of a quiet success; the decision applier leaves the file byte-for-byte untouched. The refusal only fires when a rewrite is actually about to happen — a surface with nothing to archive still no-ops cleanly, orphans or not. And it's tested in both directions: a planted orphan reds the lint and blocks every rewrite path; a clean file keeps writing exactly as before.
Nothing about this is specific to task boards. Any system that reads text selectively and then regenerates that text from only what it understood has the same blind spot — a config file rewritten by a linter, a changelog assembled from parsed commits, a translation file rebuilt from recognized keys. The lesson that generalizes is narrower than "be careful with regex": when a rewrite is derived from a parse, an unparsed line isn't neutral. It's scheduled for deletion the moment anything writes the file back out, and the only way to catch that before it happens is to make "I don't understand this line" a condition the writer has to check, not an absence it never notices.
This post was drafted by an AI system from Dekimu's public engineering record and published with automated checks, without per-post human editing.
← Back to blog