Shared DB eprpywqwzsvrjeaforei has ZERO backup coverage: free plan, backups list empty, PITR off, no dump machinery on either tenant

Sub-tickets

Activity

• wi-cli-venus created · 2026-07-31
• wi-cli-venus note · 2026-08-16
  ROUTED 2026-08-16 to pm-enamel-cc (pm-terra-cc-msvhnabuths6). The WI's own stated blocker was an enamel-side WI owned by pm-enamel-cc plus routing to evolutiva-backups' maintainer - i.e. a PM-to-PM message. That message had never been sent. This item was not waiting on analysis or on a lane being busy; it was waiting on me, from 07-31 to 08-16. Recorded because a tracking WI whose only remaining step is an unsent message is indistinguishable from one correctly queued behind someone else's work, and reads as in-progress forever.
• wi-cli-venus note · 2026-08-16
  CORRECTION to the ROUTED note above, same day. That note said the item had been waiting on me from 07-31 to 08-16 because the PM-to-PM message was never sent. My message was indeed never sent, but the conclusion drawn from it is wrong: pm-enamel-cc reports the routing to evolutiva-backups' maintainer already went to pmmaster on 08-07 - case-arm extension plus DATABASE_URL_ENAMEL plus a whey timer drop-in, owner bin-whey-cc/nw-whey-cc. The item was moving on enamel's board without me. THE ACTUAL GAP IS NARROWER AND DIFFERENT: the route happened and never became a maintainer-registry row. pm-enamel-cc is pushing pmmaster for the row rather than re-routing from scratch. No follow-up owed by terra. Worth keeping rather than quietly fixing, because the error has a shape I have made before: I measured MY OWN lane's inaction correctly and inferred the item's global state from it. A tracking WI is by definition a shadow of work owned elsewhere, so my side going quiet is the weakest possible evidence about whether the real item moved - and it is the evidence closest to hand.
• wi-cli-venus blocked · 2026-08-16
  Blocked on enamel, not on terra. Needs (a) an enamel-side WI owned by pm-enamel-cc and (b) routing to evolutiva-backups' actual maintainer. Terra cannot build this: run.sh's case-arm accepts only mars|pluto|venus and exits 2 otherwise, and filing into enamel's backlog unilaterally crosses the bwi access boundary. Status corrected from backlog 2026-08-16 by pm-terra-cc - it was reading as an actionable P1 in terra's lane for weeks while the only move available was an ask to another project. Ask sent to pm-enamel-cc 2026-08-16.
• wi-cli-venus note · 2026-08-16
  pm-enamel-cc 2026-08-16: agrees the gap is real, and confirms routing to pmmaster went out 2026-08-07 but never became a maintainer-registry row. They are pushing pmmaster for the row rather than re-filing. Stays blocked on terra's side; the ask is discharged and the dependency is unchanged. Independently confirms the diagnosis this WI already carried - the hole is the missing row, not a missing route.
• wi-cli-venus note · 2026-08-16
  ESCALATED AND FIXED, 2026-08-16. pm-terra-cc raised to pmmaster-evolutiva-cc (pm-terra-cc-msvooo4ok169) that the framing was wrong: this row had sat blocked nine days on a MAINTAINER-REGISTRY ROW, and a registry row is a tracking artifact, which per pm-commons never gates a fix. What was actually missing was a run.sh arm and a hand to run it; the row records ownership afterwards. Two different dependencies read as one. pmmaster response (pmmaster-evolutiva-cc-msvoowrz3pw1): coder-venus-cc dispatched to add the enamel arm to run.sh NOW, no wait on registry ownership, registry row follows. Their words: not accepting the exposure, fixing it. Terra offered the alternative deliberately - name a date and terra records the exposure as ACCEPTED with that date rather than leaving a P1 that reads as in-progress. pmmaster declined the accept and took the fix, which is the better outcome and the reason the alternative was offered as second preference rather than first. SCOPE OF WHAT TERRA MEASURED, so nobody credits terra with a spec: the run.sh case arm (accepts mars|pluto|venus, exits 2 otherwise) and this WI history. Terra did not read the backups repo and did not verify what the existing arms actually do. The add-an-arm shape is terra inference, stated as such in the escalation. Stays blocked on terra side pending coder-venus-cc landing it - the dependency is now a live dispatch rather than an unowned routing question.
• wi-cli-venus unblocked · 2026-08-16
  Premise measured and FALSE in the dangerous direction: not a 7d default, but ZERO backups. Blocking dependency was a maintainer-registry row, which is a tracking artifact and never gates a fix.
• wi-cli-venus priorityChanged · 2026-08-16
  0
• wi-cli-venus titleChanged · 2026-08-16
  Shared DB eprpywqwzsvrjeaforei has ZERO backup coverage: free plan, backups list empty, PITR off, no dump machinery on either tenant
• wi-cli-venus descriptionChanged · 2026-08-16
  was: TERRA-SIDE TRACKING of an enamel-owned gap. Terra cannot build this; filed so terra's exposure is not rediscovered fresh. EXPOSURE (measured, cited): Supabase project eprpywqwzsvrjeaforei has ONLY Supabase's own daily backup at 7d retention. No independent pg_dump insurance against app-level corruption, for either co-tenant. Source: enamel-pensanta-com/db/backup-coverage.md, "Last verified: 2026-07-30 07:39, by bin-whey-cc"; re-read by db-terra-cc 2026-07-31. WHY IT IS NOT A MISSING TIMER: /opt/evolutiva-backups/run.sh's case-arm accepts only mars|pluto|venus and exits 2 on anything else. It is code that does not know this project exists. DATABASE_URL_<INSTANCE> wiring is absent. Only @venus, @pluto, @mars run fleet-wide. NOT A GAP, DELIBERATE: the absence of an evolutiva-backup@terra instance. That template dumps a whole project; terra owns a scoped subset of enamel's DB. terra/db/backup-db.sh is terra's own pg_dump of terra-owned objects, run manually, and its header already states this. TERRA'S RESIDUAL EXPOSURE EVEN IF ITS OWN SCRIPT RUNS: terra rows inside enamel's shared tables (appEvents where appKey='terra', correctionRequests shells, supportTickets, ownerAppKey='terra' vocabulary rows) are in NO terra-scoped dump — pg_dump cannot take one tenant's rows without the table. A terra-only restore rebuilds terra's structures and clinical records but not its vocabulary, users, or event history. Structural consequence of co-tenancy, not a defect in terra's script. OWNERSHIP: whole-DB backup of this project is ENAMEL's, agreed db-enamel-cc + pm-enamel-cc 2026-07-30. Not yet a maintainer-agents registry row. The build itself belongs to evolutiva-backups' actual owner, not bin-whey-cc (who diagnosed it outside their maintenance lane). COST TO BUILD (per bin-whey-cc, three steps, whey-side): (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 + enable it. No code written, no timer exists. BLOCKED ON, and this is the real ask: an ENAMEL-side WI owned by pm-enamel-cc, plus routing to evolutiva-backups' maintainer. db-terra-cc filed this one because pm-terra-cc asked; filing into enamel's backlog without pm-enamel-cc's lead would cross the bwi access boundary. NOT RELATED to migration-replay idempotency. Dump-restore does not run migrations, so replay guards buy nothing here. Recorded because an hour went into replay hardening on 2026-07-31 while this — the procedure that would actually save the DB — stayed unbuilt.
• wi-cli-venus note · 2026-08-16
  TERRA-47 finding, filed as a stated input to whatever restore procedure eventually lands here, not solved by TERRA-47 itself: physical/PITR restore is unaffected by trigger tgenabled state (WAL replay bypasses the trigger executor entirely). A LOGICAL pg_restore's --disable-triggers flag works BY setting session_replication_role=replica for the duration of the restore. TERRA-47 (db-terra-cc) is setting terra's guard triggers to ENABLE ALWAYS specifically so they fire under replica mode too - which means an unmodified pg_restore --disable-triggers run against this DB after TERRA-47 lands would have every terra guard fire mid-restore and abort it. Not an issue today: this WI's own body confirms zero backup/dump machinery exists yet. But whichever restore procedure gets built (self-managed pg_dump per this WI, or the run.sh arm being added by coder-venus-cc) must either set the guard bypass GUCs (app.bypass_terraCountersGuard etc.) or flip the ENABLE ALWAYS triggers back to ORDINARY before running --disable-triggers, or state explicitly that plain pg_dump/pg_restore without --disable-triggers is the intended path (slower, but doesn't fight the guards). Whoever builds the restore script for this project needs this before first real recovery, not discovered mid-incident.
• wi-cli-venus note · 2026-08-17
  OWNER CORRECTED 2026-08-17, and this row carried the wrong one for a day. My 08-16 note recorded 'coder-venus-cc dispatched to add the enamel arm to run.sh NOW' as the live dependency. pmmaster (pmmaster-evolutiva-cc-msx06f7y75d8) reports that was a MISROUTE, corrected on venus's side the same day: the build is bin-whey-cc's. Terra's record never learned, so this row named a lane that was not working on it while reading as a live dispatch - the third time on this single WI that the recorded dependency and the real one have diverged, and each time terra's side looked correct from inside terra. STATE AS OF NOW: build owned by bin-whey-cc; pmmaster has no confirmation that Elazar's GO landed and is checking bin-whey-cc directly, will relay. So the chain is: Elazar GO (unconfirmed) -> bin-whey-cc builds -> terra's exposure closes. Terra owns no step. TRIGGER CONSTRAINT ROUTED AND CONFIRMED REAL, and it is WIDER THAN TERRA: coder-venus-cc verified it against venus, which has 4 ENABLE ALWAYS triggers with the same pg_restore --disable-triggers exposure - narrower there (INSERT unaffected, only clear-first restores hit it) but present. Passed forward to the build owner. Terra found this as a terra fact and it is a fleet fact; nobody had asked whether other projects had ALWAYS triggers.
• wi-cli-venus blocked · 2026-08-17
  Blocked on bin-whey-cc's build of the enamel arm, itself blocked on an Elazar GO whose landing pmmaster cannot confirm and is chasing. Terra owns no step and has no move. Moved off todo because a P0 sitting unblocked in the PM lane reads as work somebody here can start, and there is none - the only terra-side contribution left was the ENABLE ALWAYS restore constraint, now routed and confirmed.
• wi-cli-venus note · 2026-08-17
  GO CONFIRMED ABSENT, not lost, 2026-08-17 (pmmaster-evolutiva-cc-msx0717l8b2y): pmmaster checked bin-whey-cc, there is no GO from Elazar; their direct escalation to him (GO + owner assignment) is unanswered. That upgrades the block reason from 'cannot confirm' to 'confirmed waiting' - a real difference, because a possibly-lost dispatch is chased and a genuine wait is not. FILED AS eq 40 (topic terra-backup-coverage, refs this WI and pmmaster's tag) so the ask has a queued home. pmmaster's escalation was a DM, and an unanswered DM scrolls; eq persists and sits beside terra's other six open questions. Deliberately ONE ask across two channels, not a second opinion - the decision is the same one pmmaster raised and terra is not re-asking it independently.
• wi-cli-venus commented · 7w ago
  Surveyed mars and pluto per Elazar (do not just adopt, make sure it is a good plan). BOTH run the same machinery: systemd timer evolutiva-backup@<app> on whey, pg_dump 3x/day at 00/08/16 ART, landing in /gdrive/backup/evolutiva/<app>/ at 2-day retention plus /media/rob/backupYes USB LUKS at 90-day. Mars verified live - latest dump 2026-08-22 03:02, ~8h spacing back through the week, not stale; pluto zero fail rows ever in backup-log.sqlite. Neither uses Supabase PITR (Free plan, unavailable). THE PATTERN IS PRODUCING, NOT PROVEN, AND IT IS UNWATCHED - both PMs said so unprompted and neither presented it as a model. (a) RESTORE HAS NEVER BEEN EXECUTED on either project. Mars documents the pg_restore --clean --if-exists command and records no executed test; pluto has no restore script, no restore log, and has never drilled. A dump nobody has restored is an assumption with a file attached. (b) ALERTING IS THE FAILURE SHAPE WE ALREADY MEASURED. Mars fires msmtp + notify-send ONLY on a FAILED systemd result; pluto has no OnFailure= at all, stdout/stderr null, and nothing polls backup-log.sqlite. A silently-stopped timer never fires and never fails, so it is invisible to both - identical to applog-listen@enamel sitting cleanly Stopped for 16.79 days. Pluto: it would surface only when someone needs a restore and it is not there. (c) BOTH TIERS LIVE ON WHEY. Lose whey and the only surviving copy is gdrives own Drive-side replication. (d) Mars flags the lane MAINTAINER AS UNRESOLVED - a 2026-08-07 ruling naming bin-whey-cc was withdrawn the same day and no registry row exists since, so no owner would catch a silent failure either. RECOMMENDATION for terra: copy the pg_dump timer shape, which is proven to produce, but do NOT inherit its three gaps. Terra needs, in this order: a restore actually executed once against a scratch target and recorded with its output; a positive did-it-run check asserting a recent dump EXISTS and is non-trivial in size rather than waiting on a failure signal this mode never emits; and one off-whey destination. Sequencing matters because a backup that is monitored but never restored is the more dangerous of the two, and terra currently has neither. Terra is also NOT the same case as mars/pluto in one respect that raises the stakes: the DB is SHARED WITH ENAMEL, so scope, restore target, and who is authorised to run a restore all need deciding before any dump is scheduled - a restore here is not a terra-only act.
• wi-cli-venus commented · 7w ago
  CORRECTION, folded into the survey above - pm-pluto-cc re-checked with bin-whey-cc and two of its four claims were wrong. Plan off THIS, not the earlier comment. (a) THE TIERS ARE NOT BOTH ON WHEY: /gdrive/backup/evolutiva is an rclone mount of Google Drive and is a genuine OFF-HOST copy; only /media/rob/backupYes is whey-local, and run.sh already REFUSES to write to /gdrive when unmounted, so that leg is guarded. My off-host recommendation is therefore already satisfied by the shape being copied - drop it. (b) ALERTING IS NOT ABSENT, IT IS NARROWER THAN THAT: run.sh:99 notify_failure() does send notify-send + email on in-band tier failures. The real gap has two legs - a crash or RuntimeMaxSec kill that never reaches notify_failure is silent (the class is confirmed, 2 venus start-with-no-terminal-row instances in 30d), and there is NO STALE-BACKUP ALARM, nothing that fires on >Nh since the last ok, so a timer that stops firing entirely is invisible. That second leg is exactly the applog-listen@enamel shape and it is the one worth building; the generic no-monitoring claim was mine and it was wrong. (c) RESTORE-NEVER-DRILLED STANDS and is worse than a gap I found: it is a known filed todo inside the orchestrator itself, dated 2026-05-01, done=0 - so it has been recorded and not acted on for nearly four months. (d) Reliability numbers stand. REVISED RECOMMENDATION for terra: copy the timer shape including its gdrive/USB split, add exactly two things - a stale-backup alarm keyed on time-since-last-ok rather than on a failure signal, and one executed restore with its output recorded. The shared-DB caveat is unchanged and still the gating decision: restore scope, target, and who may execute one must be settled with enamel before any dump is scheduled.
• wi-cli-venus commented · 7w ago
  Asked bin-whey-cc (coder-terra-cc-mt4m5veyxuof) whether eprpywqwzsvrjeaforei is backed up anywhere in the fleet today, and to add it on the same footing as mars/pluto/venus if not - parity, not a bespoke design. Elazar's instruction. Explicitly asked for schedule, retention and artifact path so this WI can close on a reference rather than on an assurance. Flagged that I did NOT check for an existing fleet-side job, so if one exists this WI is wrong and gets corrected rather than duplicated.
• wi-cli-venus commented · 7w ago
  CONFIRMED BY bin-whey-cc, four independent measurements, and the WI is correct as filed: nothing in the fleet backs up eprpywqwzsvrjeaforei. The allowlist at /opt/evolutiva-backups/run.sh:60-63 admits only mars|pluto|venus and EXITS 2 on anything else; /etc/evolutiva-backup/secrets.env defines exactly three DATABASE_URL_* names and none is ours; no systemd unit exists for enamel or terra in any state; no artifact on the gdrive or USB tiers. THE ONLY FLEET REFERENCE TO OUR PROJECT REF IS A SCHEMA WATCHER (jobreg.tsv:58, db-schema-watch.timer) WHICH WRITES NOTHING RESTORABLE - named explicitly because it is the hit that would make someone grepping for the ref stop and conclude they were covered. BIGGER THAN THIS WI: mars, pluto and venus are ALSO pitr_enabled=false with backups=[], paid tiers included. Client-side pg_dump is the ONLY restore path for every tenant in the fleet, so our free plan was never the blocker and parity was the right ask. SIZE MEASURED LIVE: 15 MB total, PG 17.6 server against a 17.11 pg_dump client (newer client is the safe direction; the reverse refuses at run time). At that size bin-whey-cc WITHDREW their own retention warning - pre-flight dumps need no rationing and no special tier. AGREED SHAPE: instance name NOT , signed off by db-enamel-cc - one Postgres serves two apps and the tables that matter most are enamel's, so naming it terra would stamp a false ownership claim into every filename, log row and unit name, and renaming later orphans directories. Full dump, NO --exclude-table-data trims (an exclusion is an unstated claim that the omitted data does not matter, and that claim is untestable from an artifact that omits it). 12h timer at 06:00/18:00 as the floor, plus an ON-DEMAND PRE-FLIGHT I run before each wipe: foreground, non-zero exit on any failure including a partial or zero-byte artifact, staged-then-moved only after pg_dump exits 0, path printed to stdout, and pg_restore --list run against the file before exiting 0 - because 'pg_dump exited 0' is a statement about pg_dump, not about the file on disk. Pre-flight artifacts land under <OUTDIR>/preflight/ and are exempt from the pruner BY CONSTRUCTION (find -maxdepth 1), not by a rule anyone has to remember. BLOCKED ONLY ON ELAZAR'S GO to bin-whey-cc, who will not add a fourth production tenant on a relayed instruction. DSN already delivered to them by db-enamel-cc. Nothing built, armed or credentialed. This WI closes on the unit name / schedule / retention / artifact path / pre-flight command line, not on an assurance.
• wi-cli-venus commented · 7w ago
  CONFIRMED BY bin-whey-cc, four independent measurements, and the WI is correct as filed: nothing in the fleet backs up eprpywqwzsvrjeaforei. The allowlist at /opt/evolutiva-backups/run.sh:60-63 admits only mars|pluto|venus and EXITS 2 on anything else; /etc/evolutiva-backup/secrets.env defines exactly three DATABASE_URL_* names and none is ours; no systemd unit exists for enamel or terra in any state; no artifact on the gdrive or USB tiers. THE ONLY FLEET REFERENCE TO OUR PROJECT REF IS A SCHEMA WATCHER (jobreg.tsv:58, db-schema-watch.timer) WHICH WRITES NOTHING RESTORABLE - named explicitly because it is the hit that would make someone grepping for the ref stop and conclude they were covered. BIGGER THAN THIS WI: mars, pluto and venus are ALSO pitr_enabled=false with backups=[], paid tiers included. Client-side pg_dump is the ONLY restore path for every tenant in the fleet, so our free plan was never the blocker and parity was the right ask. SIZE MEASURED LIVE: 15 MB total, PG 17.6 server against a 17.11 pg_dump client (newer client is the safe direction; the reverse refuses at run time). At that size bin-whey-cc WITHDREW their own retention warning - pre-flight dumps need no rationing and no special tier. AGREED SHAPE: instance name is enamel NOT terra, signed off by db-enamel-cc - one Postgres serves two apps and the tables that matter most are enamels, so naming it terra would stamp a false ownership claim into every filename, log row and unit name, and renaming later orphans directories. Full dump, NO --exclude-table-data trims (an exclusion is an unstated claim that the omitted data does not matter, and that claim is untestable from an artifact that omits it). 12h timer at 06:00/18:00 as the floor, plus an ON-DEMAND PRE-FLIGHT run before each wipe: foreground, non-zero exit on any failure including a partial or zero-byte artifact, staged-then-moved only after pg_dump exits 0, path printed to stdout, and pg_restore --list run against the file before exiting 0 - because pg_dump exited 0 is a statement about pg_dump, not about the file on disk. Pre-flight artifacts land under a preflight/ subdirectory and are exempt from the pruner BY CONSTRUCTION (find -maxdepth 1), not by a rule anyone has to remember. BLOCKED ONLY ON ELAZAR GO to bin-whey-cc, who will not add a fourth production tenant on a relayed instruction. DSN already delivered to them by db-enamel-cc. Nothing built, armed or credentialed. This WI closes on the unit name / schedule / retention / artifact path / pre-flight command line, not on an assurance.
• wi-cli-venus commented · 7w ago
  CREDENTIAL DELIVERED 2026-08-22 ~17:18 ART. Chain closed today: bin-whey-cc shipped run.sh v2.5.0 + restore-drill.sh v1.4 (commit 8e4cd28) under Elazar GO, tooling accepts enamel|terra by both case-arms; Elazar ruled the credential owner is db-enamel-cc; they were offline during the storm shutdown so I routed to db-terra-cc, who checked and holds NO postgres URL at all (only a Supabase management API token); db-enamel-cc came back and sent the SESSION-MODE :5432 DSN to bin-whey-cc with the co-tenancy stated explicitly, and is owning it going forward. SESSION not pooler on purpose - pg_dump against a :6543 transaction pooler is a known trap and the backup is the worst place to find that out. CO-TENANCY STATED because it changes what the artifact MEANS: terra and enamel share ONE database, so a per-app DATABASE_URL_TERRA and DATABASE_URL_ENAMEL would be two names for one target and a drill counting them as two covered projects counts one. REMAINING, and this row does NOT close until it lands: the timer drop-in, plus a first successful run whose artifact somebody has actually restored. Coverage is still ZERO until then - a credential handed over is not a backup taken.
• wi-cli-venus commented · 7w ago
  BACKED UP. bin-whey-cc commit d781066: first artifact ever for eprpywqwzsvrjeaforei - 428KB, 38 public + 19 auth + 1 cron table, to /gdrive/backup/evolutiva/enamel/ plus a USB tier. Timer 06:00 and 18:00 daily; restore drill Thursdays 07:30. FIRST DRILL PASSED: 61 tables, 1000 rows, object census 152/152 - fk 61/61, constraint 76/76, trigger 82/82, plus every named view/index/sequence. Row count independently confirmed against source (1000 is a suspiciously round number and they checked rather than reported it). I VERIFIED THE TABLE COUNT FROM TERRA SIDE, since a coverage claim about a shared DB should not rest on one lane counting: public schema holds exactly 38 base tables, of which 16 are terra-owned, plus 30 views. Matches their 38 - so terra tables are in the artifact, not merely nearby. CO-TENANCY HANDLED CORRECTLY AND BETTER THAN ASKED: run.sh 2.5.1 REFUSES the terra key rather than aliasing it to enamel. An alias would still let someone add a second timer later and dump one target twice while a coverage query reads 2 projects for 1; a refusal that names enamel and says why cannot. One database, one timer, one coverage entry. EXCLUSIONS, now visible from terra side: cron.job_run_details, auth.flow_state, auth.refresh_tokens, and auth.sessions + auth.mfa_amr_claims excluded AS A UNIT - excluding the parent rows while keeping the child orphans the FK and it vanishes with zero row loss and no error. STILL UNMEASURED, stated not assumed: nobody has read this project pitr_enabled/backups - bin-whey-cc holds no Management API credential. The 12h cadence is an INFERENCE from every other project on the rail returning pitr_enabled=false, backups=[]. Worth db-enamel-cc turning that into a floor. RECOMMEND CLOSE once someone confirms the second scheduled run fires on its own - the drill passed on a hand-triggered artifact, and a timer that has never elapsed unattended is not yet evidence.
• wi-cli-venus unblocked · 7w ago
  bin-whey-cc (2026-08-22 17:22 ART, commit d781066): coverage no longer zero. First artifact shipped (428KB, 38 public+19 auth+1 cron table), timer live 06:00/18:00 daily under /gdrive/backup/evolutiva/enamel/ + USB tier. First restore drill PASSED: 61 tables, 1000 rows, object census 152/152 (fk 61/61, constraint 76/76, trigger 82/82, every view/index/sequence accounted for), row count independently verified against db-enamel-cc's live source count. Co-tenancy handled as terra+enamel described: run.sh 2.5.1 REFUSES a separate 'terra' timer/instance rather than aliasing it - one database, one coverage entry, no double-dump risk. Exclusions (cron.job_run_details, auth.flow_state, auth.sessions+auth.mfa_amr_claims as a unit, auth.refresh_tokens) now visible on the dump side. Open but non-blocking: bin-whey-cc has not independently re-read enamel's live pitr_enabled/backups today (no Management API cred on whey); 12h cadence assumes it stays false per db-terra-cc's 2026-08-16 read. Terra's own leg (ENABLE ALWAYS restore-trigger constraint) already routed/confirmed 2026-08-17. Close condition from prior comment (timer drop-in + first successful run + a restored artifact) met.
• wi-cli-venus commented · 7w ago
  UNATTENDED RUN CONFIRMED - the one condition I attached to this close is now met, and it was the only one left. bin-whey-cc (mt4v6pkwtgoq): backups row id 6663, project=enamel, trigger=systemd, host=whey, 21:01:27-21:01:43 UTC, status=ok, 428384 bytes -> /gdrive/backup/evolutiva/enamel/2026-08-22-2101-enamel.dump, mirrored to the USB tier at 18:01:43 ART. Nobody triggered it and nobody was watching the unit. It fired at 18:01:27 rather than 18:00:37 because the template carries RandomizedDelaySec=60 - recorded so a future reader does not mistake that offset for a late timer. THE DRILL RAN AGAINST THE UNATTENDED ARTIFACT, not the hand-triggered one, which is exactly what separates this from the 17:22 close: restore-drill.sh v1.4.1 picks the USB tier first and the newest USB dump was this run, confirmed by the source line it printed. 61 tables, 1000 rows, 25 non-empty, largest userGroups=170; fk 61/61, constraint 76/76, trigger 82/82, named objects 152/152, zero missing and zero UNVERIFIABLE. Row count identical run-over-run (1000 vs 1000, floor 500). pg_restore exited rc=1 with 7 error lines, all attributable to the pre-seeded extension set with no object lost to them - AND THE VERDICT COMES FROM THE NAME CENSUS, NOT FROM rc. That is the correction to the earlier drill, which passed on a TOTAL_ROWS>=1 threshold while rc=1 and 8 error lines went unreported. A threshold of one is not a check; a census of 152 named objects is. STILL UNMEASURED, stated rather than assumed: bin-whey-cc holds no Management API credential and has not re-read this project pitr_enabled/backups. That gap is now closed from the other side - Elazar confirmed 2026-08-22 that there is no PITR and the plan is free, so the 12h cadence rests on a stated fact rather than an inference carried from db-terra-cc 2026-08-16 read. This dump is the only copy of this database that exists.
• wi-cli-venus completed · 7w ago
  Doctor hygiene backfill 2026-08-24 (coder02-terra-cc): status=done since 2026-08-22T20:23:03Z but no completed event was ever logged, only unblocked+commented. Appending the missing terminal event now; no new work performed, closedAt unchanged.
• wi-cli-venus verified · 6w ago
  RE-MEDIDO CONTRA LA API DE SUPABASE 2026-09-01 07:05 UTC, no citado de la medicion del 2026-08-17. Esa medicion no era falsa, era vieja, y una afirmacion vieja sobre backups no autoriza ninguna decision de hoy - que es la unica razon por la que la volvi a tomar en vez de re-mandar la pregunta con la cifra anterior. MEDICION TEXTUAL sobre el proyecto eprpywqwzsvrjeaforei: pitr_enabled false, lista de backups VACIA, physical_backup_data vacio. Estado del proyecto ACTIVE_HEALTHY, Postgres 17.6.1.141, region sa-east-1, creado 2026-07-04. CONCLUSION QUE SE SOSTIENE: no hay punto de recuperacion ni backup listado para la base que guarda los registros clinicos de terra y enamel. UN DATO QUE NO CIERRA Y LO DEJO ASENTADO ASI COMO ESTA: walg_enabled viene en TRUE. La infraestructura de backup fisico figura habilitada mientras la lista de backups y los datos fisicos vienen los dos vacios. No se que implica y no lo resuelvo inventando una lectura: no puedo afirmar que exista una copia recuperable, y tampoco puedo afirmar categoricamente que no exista ningun mecanismo corriendo. Lo que si puedo afirmar es que nada recuperable esta LISTADO. Si alguien cierra esta fila alguna vez, esa bandera es lo primero que hay que entender, porque es la unica cosa medida que apunta en la otra direccion. LO QUE NO MEDI: si algun script de dump en whey cubre este proyecto. Whey es otro host y no es mi carril. Esa mitad viene de pmmaster y sigue sin re-verificar por nadie de terra. ACCION: abri la eq 80 con esta medicion, bajo el mismo topico terra-backup-coverage que la eq 40, que quedo stale sin respuesta desde el 2026-08-17. Una respuesta cierra las dos. El pedido no cambio: un GO y confirmar que bin-whey-cc lo hace. POR QUE NO LO ARREGLO YO: no es mi carril y no es de terra - el script vive en whey y su mantenedor es bin-whey-cc. Lo unico que este carril puede hacer es medir el estado y mantener la pregunta viva con una cifra fresca, que es lo que hice.
• wi-cli-venus note · 6w ago
  RETIRO EL EVENTO QUE ACABO DE POSTEAR Y LA eq 80 QUE ABRI CON EL. LOS DOS ESTABAN MAL Y EL ERROR ES MIO. Esta fila esta CERRADA CON RAZON desde el 2026-08-22 y yo la trate como un P0 vivo. QUE HICE MAL, y es exactamente la clase de error que estuve corrigiendo en otras filas toda la noche. Lei la eq 40, que quedo stale sin respuesta desde el 2026-08-17, y en vez de leer la fila que esa pregunta referencia, fui a medir. Medi la API de Supabase: pitr_enabled false, lista de backups vacia, physical_backup_data vacio. Todo cierto. Y NO MIDE LO QUE LA AFIRMACION DICE, porque el backup de este proyecto no vive en Supabase - vive en whey, en un pg_dump con timer. POR QUE NO SE NOTABA: la medicion CONCORDABA con la pregunta vieja. Una cifra fresca que confirma una afirmacion stale se lee como confirmacion y es lo contrario - es medir el lugar equivocado y encontrarlo igual que la ultima vez que alguien midio el lugar equivocado. Si la medicion me hubiera contradicho, habria ido a buscar por que; como me dio la razon, la mande a la cola de un humano. LO QUE LA FILA YA DECIA Y NO LEI. Que el backup existe desde el 2026-08-22, commit d781066 de bin-whey-cc: primer artefacto 428KB, 38 tablas public mas 19 auth mas 1 cron, timer 06:00 y 18:00 diario a /gdrive/backup/evolutiva/enamel/ mas una capa USB, y drill de restauracion PASADO - 61 tablas, 1000 filas, censo de objetos 152/152, con el conteo de filas verificado contra la fuente viva. Y corrida desatendida confirmada el 2026-08-22 21:01 UTC, fila 6663, que era la unica condicion que quedaba pendiente del cierre. Y PEOR: la descripcion de esta fila YA EXPLICABA la bandera que yo levante como dato que no sabia interpretar. Dice textual que walg_enabled true es una bandera de capacidad de plataforma, no evidencia de que se tome ningun backup. Yo la reporte como "un dato que no cierra y no se que implica". La fila lo sabia. No la lei antes de medir. LA REGLA QUE ME LLEVO: antes de re-medir para refrescar una afirmacion vieja, leer la fila que la afirmacion referencia. Una pregunta stale y la fila que la responde envejecen por separado, y la cola no se entera de que la fila se cerro. Y medir el sistema que tengo a mano no es medir el sistema del que habla la afirmacion - la coincidencia entre las dos mediciones equivocadas es el motivo por el que esto pasa desapercibido. QUE QUEDA EN PIE de lo que medi, acotado a lo que si mide: en Supabase no hay PITR ni backup listado, y eso es correcto y esperado - la cobertura nunca vino de ahi. La eq 80 queda descartada y la eq 40 esta obsoleta por la misma razon.