Skip to content

Forensic — the retained DBs

Finding in one line. There is no evidence a "retained 450 MB rtopacks-db" ever persisted in the UCCA account. The figure and the belief trace to a stale code comment misread by the cleanup audit, which then propagated into our Phase-6 request and back out of RTOpacks' reply. The databases left e5a98302 at the 2026-04-08 migration; the "retained copies pending deletion" were a documentation phantom, not a deleted resource.

Thread 2 — ucca-backup (the smoking gun for the "450 MB")

The ucca-backup worker's own README + wrangler.toml (surfaces/ucca-surfaces/workers/backup/): - wrangler.toml:22-23: "D1 bindings removed — we use the HTTP export API … This avoids Worker memory limits on large databases (rtopacks-db = 450MB)." — This comment is the origin of the "450 MB." It is not a live measurement; it is a note explaining why the binding was removed. - README:7: exports only ops-db, engine-db, mcp-db (UCCA platform DBs — all present in e5a98302). - README:14: "Does not back up rtopacks-db — migrated to RTOpacks account, covered by D1 Time Travel." - It holds no D1 binding to rtopacks-db and uses the HTTP export API for the three platform DBs.

Therefore the cleanup report §4.4 ("ucca-backup … backs up the 450 MB rtopacks-db … live backup of the retained DB") is inverted — the worker explicitly does the opposite. ucca-backup's runs after 2026-04-08 succeed for the three platform DBs; it never touched rtopacks-db. (RTOpacks' "the backup worker's bindings went stale 2026-04-08" refers to the earlier Mac-Mini com.ucca.backup this worker replaced — not the current worker.)

Thread 3 — how the cleanup audit "knew" the retained DBs existed

The audit never queried the account. Its UCCA-RTOPACKS-CLEANUP-REPORT-01 §4 "how we know" columns are "grep call sites + wrangler deployments" and "wrangler name/deployment + config" — bindings and worker deploy status, never a d1 list/d1 info on e5a98302. A binding is a config UUID; it does not prove the DB exists. So "the retained rtopacks-db exists (450 MB)" was inferred from stale config, never verified. The wrangler landmine (an unsourced d1 read defaulting to the RTOpacks account) was not even required to produce the phantom — a misread comment did it — but it remains a live hazard for any future unsourced read (now reduced: the OAuth default was re-pointed to UCCA this session).

Thread 4 — cleanup Tier-1 timing

Executed 2026-07-02 (recorded in UCCA-RTOPACKS-CLEANUP-RECON-01, commit c63a96d, 23:11 −0400). Tier-1 deleted local artefacts only — .migration-exports/ (21 GB) and the radar-screenshots wrangler-dev stub (46 MB). It did not touch any cloud D1 database. So Tier-1 does not explain the DBs' absence from the account.

Thread 1 — CF audit logs (narrowed 2026-07-03, still one gap)

Tim added "Access: Audit Logs: Read" to the ucca-deploy token — but that gates the Cloudflare Access / Zero-Trust audit log (/accounts/…/access/logs/access_requests → HTTP 200, verified), which records Zero-Trust login/access events, not resource changes. The account resource audit log (/accounts/…/audit_logs and /logs/audit) — where a D1 database delete is recorded — still returns HTTP 403 with the same token (valid, active, fingerprint unchanged). Two different logs, near-identical names. The D1-deletion record needs the CF dashboard → Manage Account → Audit Log (filter D1 / 334ac8fb / around 2026-04-08 — Tim's admin browser), or a token with the account-level audit permission (distinct from the "Access" one). Given threads 2-4, the likely "event" is still the 2026-04-08 migration itself, not a later mystery deletion — the audit log would confirm which.

The phantom's propagation (how the record diverged from reality)

  1. ucca-backup config comment: "rtopacks-db = 450MB" (describing the migrated DB, pre-move size).
  2. Cleanup report §4.4 misreads it → "ucca-backup backs up the 450 MB retained rtopacks-db" (live).
  3. Our UCCA-REQUEST-MIGRATE-02-PHASE-6-01 carries "retained rtopacks-db ~450 MB" to RTOpacks.
  4. RTOpacks Q2 answers "your request describes the retained rtopacks-db as ~450 MB" — echoing our own figure back. Both ledgers then "agreed" on a DB that isn't in the account.

Consequences (findings only — nothing acted on)

  • The retirement unit's data targets are likely a phantom. The three DBs left at migration; there is no confirmed retained copy to delete. .migration-exports/ is already gone (Tier-1). What remains is genuinely code residue only (stale bindings in ops-v2 + the config comment).
  • No data-loss incident is indicated. RTOpacks' MIGRATE-02 row-count reconciliation (attested across all nine DBs) covers completeness; nothing was deleted under-review because nothing UCCA-side was there to delete.
  • The one true open item: confirm via the audit log whether a 334ac8fb copy ever persisted post-migration and, if so, its removal date — Tim's dashboard. Everything else is explained.
  • Retirement brief FROZEN pending this; nothing crossed, nothing retired. No crossing to RTOpacks is warranted yet — correcting a figure they only ever quoted back to us is not a fence event until the audit-log check either closes or opens the 334ac8fb question.