65 of 72 real daily agendas were not showing today's date. 29 were more than a fortnight behind. <email> was being served an agenda from Aug 10; <email> and <email> from Jul 30, 36 days. On the same morning, 42 of those users had a correct # 2026-09-04 agenda sitting in documents.content that nothing would ever show them.

There were no failed tool calls. Every agent was told it had written the agenda.

---

The mechanism

write-document persists in two non-atomic phases, and only the first one had happened.

All line numbers below are as of staging , the code that had the bug.

agendaIntegrityHook returned abortPersist: true. applyUpdate.ts:258-272 then returned early with no UPDATE documents at all.

So phase 2 had committed and phase 5 had not. content held today's agenda; content_yjs held one from weeks ago. Every reader takes content_yjs.

It is self-sustaining

The hook builds beforeJson from content_yjs. Frozen, its task set is frozen , so every later agenda, which legitimately rotates rows, appears to drop the same open tasks and is refused again. Xander's Sep 3 write carried 24 taskIds; 12 of the 20 frozen ones were absent and all 12 were still todo → abortPersist. The refusal manufactures the condition for the next refusal.

Nothing self-heals

• reconstructYDoc never re-reads markdown once bytes exist , hydrate.ts:264-269 returns early on row.contentYjs.
• The lazy backfill is gated on their absence , get-doc.ts:529 is if (!row.contentYjs), so stale bytes skip it. get-doc.ts:508-511 already warns about exactly this shape for playbooks.
• The agenda reconciler is subtractive only (tasks-to-agenda.ts:152-176; its own header says "REMOVES ONLY ... There is deliberately no INSERT") and returns mutated: false because all rows are still todo.

And it actively anti-repairs

applyUpdate.ts:289 derives markdownMirror from the Y.Doc and writes it to documents.content at :308; get-doc.ts:651-668 does the same on a mutating reconcile. So the next passing write, or a human opening the editor, reverts the good markdown to the stale state.

This happened to Xander mid-investigation. His content now reads # 2026-09-01, and the Sep 4 agenda survives only in agent_tool_calls. 12 of the 57 affected documents are in this state.

---

The data signature

An aborted persist still called recordHistoryAsync, with Buffer.alloc(0) from applyUpdate.ts:265. The normal path is Y.encodeStateAsUpdate, which is never 0 bytes , so a zero-byte document_updates row is unambiguous.

 zero_byte_rows | docs | document_type
----------------+------+---------------
            991 |   47 | agenda          ← this bug
            104 |   51 | playbook        ← playbook.compile, working as designed

Xander's last 8, consecutive, no successful write between them:

 started              from_seq  to_seq  bytes  origin
 09-03 16:53:10       298       298     0      agent
 09-03 17:18:05       299       299     0      agent
 09-03 17:48:02       300       300     0      agent
 09-03 19:35:12       301       301     0      agent
 09-03 22:30:51       302       302     0      agent
 09-04 14:41:24       303       303     0      agent
 09-04 15:10:13       304       304     0      agent
 09-04 15:38:30       305       305     0      agent

---

Two things this rules out

**The