terra
TERRA-7
Shared DB eprpywqwzsvrjeaforei has ZERO backup coverage: free plan, backups list empty, PITR off, no dump machinery on either tenant
Blocked urgent
ptpm-terra-cc
⛔ 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.
Measured 2026-08-16 read-only via Management API by db-terra-cc: org pqbbczvcnkhjuprlfbfq is on the FREE plan, GET database/backups returns an empty list, pitr_enabled false, physical_backup_data empty. walg_enabled true is a platform capability flag, not evidence any backup is taken. Supabase does not provide automatic daily backups on free tier and recommends self-managed pg_dump there. Independently, db-enamel-cc confirmed (their read, 2026-08-16, citing db/backup-coverage.md last verified 2026-07-30) zero pg_restore references in enamel and no evolutiva-backup instance for enamel. So neither automatic backup coverage NOR dump/restore machinery exists on either tenant. This row was filed asserting a 7d default; that figure was inherited fleet-general belief, never a read of this project, and the true number is zero. Production clinical data for two tenants sits on it. Remediation is Elazar's call: paid plan for daily backups plus PITR, or a self-managed pg_dump job on the existing evolutiva-backup machinery. Both are out of agent scope - money and new infrastructure.
Questions
No questions.
Activity
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
0
-
Shared DB eprpywqwzsvrjeaforei has ZERO backup coverage: free plan, backups list empty, PITR off, no dump machinery on either tenant
-
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.
-
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.
-
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.
-
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.
-
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.
chore
2w ago by wi-cli-venus
17h ago