diff --git a/PHASE0_BREAKAGE_CATALOGUE.md b/PHASE0_BREAKAGE_CATALOGUE.md
index 47cbe69b2..1d1bf5302 100644
--- a/PHASE0_BREAKAGE_CATALOGUE.md
+++ b/PHASE0_BREAKAGE_CATALOGUE.md
@@ -46,7 +46,7 @@ The tracer bullet confirms protocol/client compatibility and minimal SQLite dura
 
 ## Phase 2 estimate refinement
 
-SQLite datum: enabling sqlx SQLite compiled without source changes outside the tracer. Basic durable event JSON uses portable table creation plus SQLite `INSERT OR IGNORE`; the production `event.rs` cannot be mechanically reused because its 39 queries assume the production schema, typed columns, community/channel fences, replacement rules, deletion, and PG-specific query composition. This cheap datum shows driver/toolchain viability, not a completed `event.rs` port.
+SQLite datum: this is only a single-table JSON blob store (`events(id TEXT PRIMARY KEY, event_json TEXT NOT NULL)`) using `INSERT OR IGNORE` and a full-table `SELECT` before filtering in Rust. It proves that sqlx-sqlite links into `buzz-relay`, runs in-process, and persists events across relay restart. It is **not** a port of `crates/buzz-db/src/event.rs` and provides **zero evidence about SQL-dialect friction in its 39 production query sites**, including typed/tag filter queries, replaceable-event upserts, deletions, and community/channel fences. Those queries must be exercised after the AppState/profile seam exists, in the Phase 1 vertical slice.
 
 Core SQL count is not the main blocker. `event.rs` has 39 `sqlx::query` call sites; unavoidable auth/chat widening immediately adds approximately channel (50), relay_members (23), moderation (15), user (11), reaction (8), thread (19), DM (12), and feed (2), before shared `lib.rs` queries. A useful real-client slice is thus roughly 179 module-level query sites, not 39, plus creating the AppState/service seam. Recommended next tracer bullet: land the service aggregate/profile seam first, then port event + tenant/community + auth moderation/membership + channel as one vertical slice.