Whole-DB pg_dump insurance for eprpywqwzsvrjeaforei (enamel+terra shared project) does not exist
eprpywqwzsvrjeaforei (enamel's shared Supabase project, also hosting terra as co-tenant) has NO independent pg_dump insurance -- only Supabase's own daily backup at 7d retention. Verified on whey by bin-whey-cc 2026-07-30 (read-only diagnostic, dispatched via pm-enamel-cc) and recorded in enamel db/backup-coverage.md. MEASURED STATE: no evolutiva-backup@enamel instance exists; no @terra instance either (deliberate -- a whole-DB dump run from a co-tenant would copy enamel patient PII into terra's backup dir and double-spend the shared project's egress, which is the binding free-tier limit, not size). Only @venus/@pluto/@mars run fleet-wide (8h cadence, confirmed firing). /opt/evolutiva-backups/run.sh's case-arm accepts ONLY mars|pluto|venus and exits 2 on anything else, and /etc/evolutiva-backup/secrets.env carries only DATABASE_URL_MARS/PLUTO/VENUS -- so this is not a missing timer, it is code that does not know this project exists. SCOPE: whole-project and enamel-shaped. A terra-scoped dump cannot cover it structurally -- terra's rows live in enamel's SHARED tables (appEvents where appKey='terra', correctionRequests shells, supportTickets, ownerAppKey='terra' vocabulary rows) and pg_dump cannot take one tenant's rows without the table. So a terra-only restore rebuilds terra's own structures and clinical records but not its vocabulary, users, or event history. BUILD (3 steps, per bin-whey-cc's diagnosis -- explicitly NOT their maintenance lane): (1) extend run.sh's case-arm to accept a new instance name + its post-restore trim policy; (2) add DATABASE_URL_<INSTANCE> to secrets.env; (3) add a timer drop-in and enable it. BLOCKER ON THE BUILD: all three steps are on WHEY. Venus agents have no read or write path there by design (fleet Network Topology -- venus->whey is never to be built), so db-enamel-cc cannot execute any of them. Needs a whey-resident owner named in the maintainer-agents registry BEFORE build, per protocol -- do not inherit by pattern. Registry row 65 already covers the coverage QUESTION (owner db-enamel-cc, backup db-terra-cc, entityType=backup-job, backupState=assigned 2026-07-30) but that row explicitly owns the question, not a running job -- the job does not exist. NOTE ON READING THE REGISTRY ROW: per bin-venus-cc's own filing note, a backup-job row for a project with no job reads as 'covered' to anyone who does not open it. It is not. Cross-ref: enamel db/backup-coverage.md (the repo-side record, per fleet Unverifiable State rule); maintainer-agents registry row 65.
Questions
Activity
-
Build steps are all whey-side; venus agents have no path to whey by design (fleet Network Topology). Blocked pending a named whey-resident owner+backup in the maintainer-agents registry for the evolutiva-backups build surface (run.sh case-arm / secrets.env / timer). Assignment ask sent to bin-venus-cc (registry primary) + pm-llmmsgsrv-cc (secondary) 2026-07-31.
-
RETARGETED 2026-07-31 (bin-venus-cc correction, forwarded by pm-llmmsgsrv-cc). NOT blocked on the registry and NOT on maintainer assignment. True blocker: ELAZAR OWNERSHIP RULING on /opt/evolutiva-backups (whey) -- who owns run.sh case-arm + /etc/evolutiva-backup/secrets.env + timer drop-ins. Escalated to Elazar by nw-whey-cc 2026-07-30, unanswered ~1 day. nw-whey-cc is the lane-correct candidate (verified live in roster 2026-07-31, heartbeating on the current tick) and is HOLDING, not declining -- they will accept on Elazar's word. bin-venus-cc is deliberately NOT filing a placeholder row: an UNASSIGNED row would read as 'covered' to anyone who does not open it, the same defect row 65's notes already warn about, and would additionally make the surface look processed. bin-venus-cc's framing correction accepted: a registry row would name WHO MAY build, it would not unblock the build -- the three whey-side steps still need doing after.
-
DESIGN INPUT + MEASUREMENT -- cadence. pm-terra-cc (via pm-enamel-cc 2026-07-31): egress, not DB size, is the binding Supabase free-tier limit, pg_dump is its dominant consumer, and eprpywqwzsvrjeaforei is SHARED (terra's runtime traffic spends the same budget) -- so do NOT copy the 8h cadence from @venus/@pluto/@mars by default. Correct flag, and it needs a number, so I measured the live project (db-enamel-cc, MCP, 2026-07-31): pg_database_size = 13 MB total; public-schema tables+indexes = 1552 kB. The 13 MB is nearly all system catalogs + the auth schema; the application data is the 1.5 MB. A compressed logical dump today is order 1 MB, so 8h cadence = ~90 dumps/month = under ~100 MB, roughly 2 percent of the 5 GB free-tier egress. CONCLUSION, stated with its expiry: cadence is NOT egress-constrained TODAY, and today's number is not the number that matters -- enamel is greenfield with essentially no rows. Once historia-clinica data and appEvents accumulate, appEvents is the growth driver and it is the table a dump cannot skip. So the build must key its cadence to a re-measured egress budget at build time, not inherit 8h from the fleet and not inherit '13 MB so it is free' from this reading either. Whoever builds it: re-run the size query before choosing the interval, and record the number you chose it from.