Week 25: The Event Store Broke, The Log Still Shipped

The event bus was unreadable today.

That should have stopped the story from getting cleaner. It did not stop the system from getting the work done. The build log still shipped because the chronicler named the broken source, used secondary receipts, and refused to inflate the numbers.

What Got Built

• The daily build log completed with a degraded metric source. The normal event bus read failed because data/db/leads.db reported a malformed database image. Instead of inventing rows, the chronicler used STATUS.md, GitHub commits, the latest work-log readback, and Atlas ledgers. Plain English version: when the main activity notebook had torn pages, the system used only the other notebooks it could actually read.

• Content review moved one Medicare article forward. The autogate reviewed 6 recent draft or review rows. It auto-approved Understand My Medicare content #157, medicare-part-d-donut-hole-gone-2026, and kept Life Settlement content #156 held because it still needs outbound source links and primary-authority citations.

• Revenue radar produced safe work while email stayed closed. It created 65 cross-sell candidates, a 75-click Instabrain attribution snapshot, a source-tag dry run, a WeHelpHI rewrite draft, and an X metrics snapshot. None of that sent an email. That matters while the send gate remains closed.

• The weekly pipeline stayed visible. Lead-orchestrator wrote the weekly report with 1,488 total prospects, 804 outreach-ready records, 41 qualified records, and 0 conversions. It also surfaced the accounting split between 0 local email_log sends and 22 provider-send events in the last-7-day ledger.

• Social kept a low-risk public pulse. The system posted 1 X community question from @mattragudo and verified the social bridge length. LinkedIn skipped again because LINKEDIN_ACCESS_TOKEN is still unset.

• Content publication kept its source-file discipline. One approved article moved through a deterministic publisher as a source change, not just a database status change. That distinction is becoming one of the most important controls in the system.

What Broke (And How I Fixed It)

The event store was malformed.

The normal way to write this article is simple. Read the daily build log. That build log reads the event bus. The event bus gives a clean activity ledger.

Today that chain broke at the source.

The bridge returned database disk image is malformed, and a direct SQLite integrity check confirmed malformed pages in data/db/leads.db. SQLite is the small local database file many of these agents use as a shared ledger. If that file is damaged, the right answer is not to keep querying until the story sounds better.

The fix for the article was procedural, not cosmetic.

The chronicler degraded the source. It used explicit secondary receipts: the status file, GitHub commits, the latest available work log, and Atlas ledgers. It then wrote the failure into the build log itself.

That is the standard I want. A broken metric source should reduce confidence. It should not make the whole reporting loop lie.

The email lane remained closed because the previous safety bug is not fixed yet.

The system still has the daily-cap issue from last week. A rule that was supposed to mean 10 emails per day behaved like 10 emails per run. Two runs created a 20-send pilot day.

Today the right number was 0 emails.

That does not mean outbound is dead. It means the system is not allowed to trust a fragile lane just because the calendar moved. Until send-approved.sh checks the actual send ledger for the current day before SMTP fires, the gate stays closed.

The content gate kept saying no where it should.

Life Settlement content #156 is still held. That is good.

A content machine should not publish because something exists in a queue. It should publish when the source support is strong enough. For health, finance, and insurance topics, weak citation coverage is not a formatting issue. It is a trust issue.

The review gate moved one Medicare article forward and held the weak one back. That is exactly the shape I want from autonomous publishing: progress without pretending every draft is ready.

LinkedIn is still not a strategy channel until credentials exist.

X posted. LinkedIn did not.

That keeps showing up in the logs because the system is honest about skipped distribution. A missing token is not a branding decision. It is a credential blocker. Until the token exists, LinkedIn output should be counted as skipped, not quietly implied.

The Lesson

Build your reporting loop so it can survive one broken source.

Here is what I would tell someone building agents: do not make one database the only path to memory.

If the event bus breaks, the system should still know how to read commits, status files, work logs, ledgers, and source artifacts. The fallback does not need to be perfect. It needs to be explicit. Say which source failed, say which receipts were used instead, and keep the numbers conservative.

Do not let an agent turn a source gap into certainty.

A missing metric is not an invitation to average yesterday and today.

If the event store is malformed, the honest number may be smaller than the real number. That is acceptable. A conservative report with a named source gap is better than a confident report built from assumptions.

This applies outside build logs. If a CRM count is stale, say stale. If a deploy check only proves HTTP 200, say that. If a reply sensor is not trusted, do not resume sends because the dashboard looks quiet.

Use blocked lanes to compound safe work.

The email lane is still closed, but the company did not stop.

Revenue radar scanned. Content review moved. Medicare content advanced. Social posted. Pipeline state refreshed. The system used the pause to prepare better inputs instead of forcing risky output.

That is the operating pattern I want: when a high-risk channel is blocked, agents should move into read-only, review-gated, or source-improving work. Keep the machine useful without creating damage that cannot be unsent.

Separate internal intent from public proof.

The content publisher lesson keeps repeating because it matters.

Approved is internal intent. Published is a source-file change. Live is deployed and verified on the public page. Promoted is a separate distribution action. If those states collapse into one word, the dashboard will look cleaner than reality.

The Numbers

• Commits: 7 total (7 agent, 0 Matt)
• Agent jobs run: 13
• Prospects added: 0
• Emails sent: 0
• Social posts: 1
• Content published: 1

The most important number is not 7 commits.

It is 0 emails while the send gate remains under repair, plus 1 content publication that moved through a source-file path instead of a vague approval state.

The other important number is invisible: one malformed event store. That is the thing to fix before it spreads into more reporting, routing, or pipeline-health work.

What’s Next

Repair or isolate data/db/leads.db, keep outbound paused until the calendar-day cap is enforced at the sender, and keep routing agents toward read-only revenue scans, citation repair, and verified publishing work while the risky lanes stay closed.