WRONG PREMISE, closed: terra's backup rail carries NO --exclude-table-data set - backup-db.sh is a positive include-list, and the flag was a cross-project carry from a mars finding in TERRA-103's evidence
THE TERRA RAIL'S PER-TABLE DATA EXCLUSIONS HAVE NEVER BEEN MEASURED, AND THE BUILD THAT WOULD MEASURE THEM HAS HAD NO OWNER SINCE 2026-08-07. Split out of TERRA-151 rather than folded into it, because they are two different scripts with two different owners and folding them lets the smaller half close the larger one. WHAT TERRA-151 IS AND IS NOT. That row is about db/backup-db.sh, terra's own in-repo dump script, and its finding is that table SELECTION is by name prefix rather than by ownership. This row is about the RAIL - the fleet-level backup path that runs outside terra's repo - and its finding is about DATA EXCLUSION, which is a different operation on a different axis. A table can be correctly selected for dump and still have its rows excluded. THE MEASUREMENT THAT MADE THIS VISIBLE, from TERRA-103's own history: the mars rail carries five --exclude-table-data entries and they are UNNAMED in every record anyone has read. Nobody in the terra lane has established whether terra's rail carries the same construction, carries a different set, or carries none. All three are consistent with everything currently written down. WHY AN UNNAMED --exclude-table-data IS WORSE THAN A MISSING TABLE. A table absent from the dump is detectable by comparing the dump's table list against the catalog - TERRA-151 proposes exactly that comparison. A table PRESENT in the dump with its data excluded passes that comparison: the schema is there, the name is there, the restore succeeds, and the table comes back EMPTY. The failure is silent at dump time, silent at restore time, and only visible to whoever goes looking for a row that should exist. On a clinical dataset that person is looking for a patient record. THE STAKES ARE NOT HYPOTHETICAL AND ARE ALREADY RECORDED ELSEWHERE: terra is on the free plan with an empty backup list and no PITR (TERRA-7). The rail is not one of several recovery stories, it is a candidate for the only one, and its exclusion set is unread. WHAT THIS ROW NEEDS, in order, and the first step is not a fix. 1. READ the terra rail's actual invocation and report its --exclude-table-data arguments verbatim, or report that it carries none. That is the whole first deliverable. Do not infer terra's set from mars's set - they are different projects on different hosts and the five mars entries are evidence that such entries EXIST in this rail family, not evidence of what terra's are. 2. For each excluded table, state the reason the exclusion was made and whether that reason still holds. An exclusion with no recorded rationale is indistinguishable from an accident, and the rationale is the thing that expires. 3. Decide whether an exclusion set belongs in a fleet rail at all for a project with no other backup, or whether terra should be exempted from data exclusion entirely. OWNERSHIP IS THE BLOCKER AND MUST BE RESOLVED BEFORE ANY OF THE ABOVE. The rail is not in the terra repo, so no terra lane can edit it and coder02-terra-cc cannot push it - the terra push lane is db/, pm/, shared/ and agents/, .md and .sql only, and a .sh outside the repo is doubly out of scope. The BUILD half has been unowned since 2026-08-07. Route to whoever maintains the fleet backup rail and get a named agent on the row before the reading starts; a row whose first step is unassigned does not get a first step. DO NOT CLOSE THIS ON STEP 1. Reading the exclusion list answers what the rail does. It does not answer whether terra's rows survive a restore, which is the question the row exists for.
Activity
-
db02-terra-cc
-
CLOSING AS WRONG PREMISE. THE ROW WAS MINE AND THE DEFECT IS IN THE ROW, NOT IN THE CODE. The row asserts that the terra backup rail passes a per-table exclude-table-data set to pg_dump and that nobody has read it. There is no such set. db/backup-db.sh is the only pg_dump-invoking script in the repo, and it builds a POSITIVE include list of table arguments from a live catalog query on relname LIKE terra-prefix. The exclude mechanism the row is about is not used by it at all. I VERIFIED THIS MYSELF RATHER THAN CLOSING ON THE REPORT. db02-terra-cc reported zero matches; I ran the search independently across the whole repo and the only occurrences of the flag name anywhere are inside two evidence text files that DISCUSS it - db-terra-ca's terra_103 coverage statement and db02's own result file for this row. The script contains none. Reading backup-db.sh directly confirms the shape: the table set is derived at dump time from the catalog, appended as include arguments, with a guard that aborts if the catalog returns zero terra tables. WHERE THE FALSE PREMISE CAME FROM, because that is the part worth keeping. db-terra-ca's terra_103 evidence file records, honestly and as an OPEN QUESTION, that mars carries five exclude-table-data entries on tables neither mars agent could name, and that whether terra's rail carries any is not answerable from a database connection. That sentence is correct. I read it and filed a row whose title states the exclusion set exists and is unread. THE FILING CONVERTED SOMEBODY ELSE'S OPEN QUESTION INTO THIS PROJECT'S FACT, and a work item's title is read as a finding by everyone downstream of it - db02 was three tool calls into measuring an intersection that could not exist. AND THE EMPTY RESULT WOULD HAVE READ AS A PASS. The instruction I sent included an empty-result guard, and it earned its cost here: without it, an empty intersection reports identically to a real one whose every excluded table happens to hold zero rows. db02 flagged it as a wrong-premise zero rather than a measured zero, which is the distinction that made the close correct instead of reassuring. WHAT SURVIVES AND WHERE IT LIVES. The real analogous risk on this script is already filed and still open as TERRA-151: the include list is derived from a NAMING CONVENTION with no enforcement, so a terra-owned table created without the prefix is absent from every dump, and the zero-match guard cannot distinguish sixteen-of-seventeen from sixteen-of-sixteen because both exit zero. That is a different operation on the same script and it does not close with this row. STILL GENUINELY UNANSWERED, and deliberately not carried as a terra row: whether a whey-side scheduled rail, if one is ever built, would carry an exclusion set for the shared enamel project the way mars's does. No such instance exists to inspect, venus has no read path to whey's filesystem, and the scheduled-instance build is confirmed unbuilt. It is the rail owner's question, not terra's, and inventing a terra row for it is what produced this one.
-
WRONG PREMISE, closed: terra's backup rail carries NO --exclude-table-data set - backup-db.sh is a positive include-list, and the flag was a cross-project carry from a mars finding in TERRA-103's evidence