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.
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.
-
MEASUREMENT CORRECTION 2026-08-22 (coder-enamel-cc, own read of the Management API, not a relay): the description's line 'only Supabase own daily backup at 7d retention' is WRONG as of today and should not be cited. GET /v1/projects/eprpywqwzsvrjeaforei/database/backups returns HTTP 200 with pitr_enabled=false, backups=[], physical_backup_data={}, walg_enabled=true. No restorable backup is exposed by the API. Coverage statement, deliberately narrow: this says the Management API lists nothing restorable; walg_enabled=true is not a restorable artifact anyone can point at, and I did not test platform-side recovery by any other instrument. Matches bin-whey-cc's four-project sweep the same day, measured independently. Consequence: coder-terra-cc's escalation of 'no backup at all' was NOT an overstatement on this axis and my pushback on it was wrong. The gap is total exposure, not merely a missing independent dump. Blocker unchanged: Elazar ownership ruling on /opt/evolutiva-backups, unanswered since 2026-07-30, nw-whey-cc holding as lane-correct candidate.
-
OWNERSHIP RULED by pmmaster-evolutiva-cc under Elazar's delegated GO (2026-09-11 09:22 announce). The blocker was an Elazar ownership ruling on /opt/evolutiva-backups (whey) - run.sh case-arm, /etc/evolutiva-backup/secrets.env, timer drop-ins - escalated by nw-whey-cc 2026-07-30 and unanswered for six weeks. nw-whey-cc is the lane-correct candidate, was verified live, and stated it is HOLDING rather than declining. RULING: nw-whey-cc owns those three whey-side surfaces. Proceed. This unblocks whole-DB pg_dump insurance for eprpywqwzsvrjeaforei, which matters more today than it did in July: that ref is enamel AND terra, and ENAMEL-35 established every login role on it holds an outbound-HTTP primitive.
-
nw-whey-cc
-
CLOSED 2026-09-11 by pmmaster-evolutiva-cc on nw-whey-cc's live measurement. THE ROW'S PREMISE WAS STALE, NOT WRONG-AT-THE-TIME. evolutiva-backup@enamel EXISTS on whey, timer enabled and active, 06:00/18:00 cadence, last run 2026-09-11 06:00:35 exit status=0/SUCCESS. Dump history in /gdrive/backup/evolutiva/enamel/ has NO GAPS: 09-08 18:00, 09-09 18:00, 09-10 06:01, 09-10 18:00, 09-11 06:00, latest artifact 504,726 bytes. db-enamel-cc's recollection was correct and the two written records were both stale: this row and db/backup-coverage.md, each dated 2026-07-30, three weeks older than the 2026-08-22 cutover they contradict. db-enamel-cc owns backup-coverage.md and corrects it with nw-whey-cc's MEASURED values, not from memory. WHY THIS TOOK SIX WEEKS AND IS WORTH ONE SENTENCE ON THE ROW: db-enamel-cc held a specific, dated, detailed memory that contradicted the row, and refused to close on it - correctly, since an agent asserting its own recollection over a written record is how a false close happens. What actually settled it was one host measurement that neither party could produce from inside its own lane. The lesson is not 'trust memory' - it is that a row whose premise came from a dated diagnostic needs the diagnostic RE-RUN, not re-read, and nothing on the row said when its source was taken until someone looked. COVERAGE LIMIT, explicitly not closed by this: nw-whey-cc did NOT check which credential/DSN/port the job uses, nor whether that role holds BYPASSRLS. Those are EVO-98, bin-whey-cc's, and they are the difference between an artifact existing and an artifact being restorable - a dump role without BYPASSRLS produces a well-formed file whose auth.users restores EMPTY with no error at dump time. Do not read this close as 'enamel backups verified good'; read it as 'the rail exists and runs'. ENAMEL-12's own scope - whole-DB pg_dump insurance for eprpywqwzsvrjeaforei - is met by a rail that runs twice daily with no gaps. Ownership recorded earlier today stands: nw-whey-cc owns /opt/evolutiva-backups run.sh case-arm, /etc/evolutiva-backup/secrets.env and the timer drop-ins.
-
PREMISE FALSIFIED, ROW WAS STALE FOR TWENTY DAYS. The rail landed 2026-08-22 at d781066 and this row kept saying no instance exists. Measured on whey by nw-whey-cc 2026-09-11 13:14 ART on request, not inferred and not recalled: evolutiva-backup@enamel EXISTS, run.sh case-arm line 176 accepts mars|pluto|venus|enamel, timer enabled and active (waiting), last fire 2026-09-11 06:00:35 exited status=0/SUCCESS, dump history in /gdrive/backup/evolutiva/enamel/ on a consistent 12h cadence with no gaps (09-08 18:00 495939B, 09-09 18:00 496004B, 09-10 06:01 499476B, 09-10 18:00 504460B, 09-11 06:00 504726B). db/backup-coverage.md rewritten with nw-whey-cc's measured values, including a section on HOW THIS FILE WENT STALE, since the reusable failure is that a repo-side record of unverifiable state is only as good as its last write and nobody schedules the write that closes the gap. Commit is held behind the venus-host.push-gate lock, currently held by coder-mars-cc. ONE THING DOES NOT CLOSE WITH THIS ROW and is now EVO-98 on bin-whey-cc, fleet-wide: which role the job authenticates as has not been read, and a dump role without BYPASSRLS reads the 26 RLS tables (all of auth.*, cron.*, storage.*) through the policy, gets zero rows, and pg_dump DOES NOT FAIL - the artifact is well-formed and plausibly sized and the loss appears only at restore, when auth.users comes back empty. The 2026-08-22 drill counted 19 auth tables, which proves the schema was dumped, not that the rows were. postgres on this ref does hold rolbypassrls=true, so there is no gap if the job runs as postgres. A dedicated enamel_backup_ro (login, INHERIT, pg_read_all_data, BYPASSRLS, connection limit 2) is offered, not minted; pmmaster ruled hold the offer until the credential is read.