terraCirugias hard-delete ban applied; archive-on-UPDATE ruled NOT TAKEN on redundancy with re-open conditions recorded
Follows TERRA-57's re-decision (db-terra-cc, measured): terraCirugias is no longer vocabulary as of TERRA-52 - it carries a live client-decision writer (isConfirmedByClient) plus a staff-actioned reason code. terraModulos does NOT move with it and is out of scope here; it has no client-writable column and stays vocabulary. terra_13's COVERAGE LIMITS text is already corrected (comment-only, item 3 and the section 5 TRUNCATE paragraph). WHAT IS OWED: the row-level guard set terraCirugias now lacks - archive-on-UPDATE and a hard-delete ban. Live catalog state measured 2026-08-16: exactly ONE trigger, trg_terraCirugias_forbidTruncate (statement-level, tgenabled='A'), which is correct under either classification and is not in question. Today a plain DELETE succeeds outright and a plain UPDATE overwrites content with zero trace. FILED NOW RATHER THAN AFTER TERRA-52 SHIPS, deliberately, and db-terra-cc was right to ask rather than assume: a blocker that exists only in a DM is indistinguishable from one nobody found. That is the same failure that left the confirm gap itself sitting seven days in a memory file with the state unmoved, and it is why TERRA-56 exists. Filing costs nothing; the DDL is what waits. SEQUENCING: do not apply before TERRA-52 is live. Nothing is exposed today - 35 cirugias, 0 confirmadas, and no client can confirm until it ships - and applying an archive trigger under a writer that is still changing shape means writing the guard twice. Exposure begins at the first real confirmation, so this must not slide past that point either. TRAPS THIS MIGRATION WALKS INTO, named because each has already fired once on terra: (1) the archive arm reaches the shared GUC namespace both tenants read - that was terra_11's entire subject and it is what makes a 100%-terra-prefixed change need db-enamel-cc's GO; ask which OBJECTS the statements touch, never which prefix they carry. (2) Any CREATE OR REPLACE on a terra function must restate SET search_path = public, pg_temp VERBATIM and the migration must ASSERT proconfig afterwards - the pin is rebuilt from the definition given, it does not merge, and no row count or successful apply can observe the un-pin. (3) terra has no cheap place to write a test row; a preview deploy reaches the same shared DB under the same appKey, so any fixture mints a permanent artifact under a 365d retention floor terra cannot prune. Also settled by TERRA-52's build and worth carrying here so nobody re-derives it: the unconfirm reason is NOT a column on terraCirugias. That table has seven columns; the reason exists only inside appEvents detail jsonb, on a shared table terra must not constrain. So this migration cannot add a CHECK for the reason set no matter what else it does.
Questions
Activity
-
TERRA-52 confirmed live 2026-08-16 13:06Z (c6eecc7, v0.21.0). Sequencing gate satisfied. Drafting the migration; apply held pending db-enamel-cc GO on the shared GUC namespace trap.
-
SCOPE RULED, 2026-08-16: option 3. The hard-delete ban ships now; archive-on-UPDATE for terraCirugias is NOT applied and CONFIRM_SQL does not grow archive context. Do not close this row as done on the ban alone. THE CONFLICT: the archive-on-UPDATE trigger this row asked for calls fn_terraRequireArchiveContext() unconditionally, which RAISEs P0001 unless app.terraUserId and app.terraArchiveReason are set transaction-locally. TERRA-52's CONFIRM_SQL, live as of c6eecc7/v0.21.0, does a bare UPDATE with neither set. Applying as scoped would have broken confirm/unconfirm on its very next call - not hypothetical, the call site is live. terra_22's own header named this hazard and marked it conditional on there being no child-UPDATE call site in src/; that condition stopped holding for terraCirugias when TERRA-52 shipped. db-terra-cc found it before drafting rather than after, and shipped the ban half meanwhile. WHAT DECIDED IT, and it was a measurement rather than a preference. (a) coder-terra-cc measured exactly ONE UPDATE call site for terraCirugias in the whole app - CONFIRM_SQL at src/lib/cirugia-confirm-core.ts:155; rows arrive by seed migration, not the app. So an archive trigger applied today would archive one thing, the isConfirmedByClient flip, which appEvents already records coupled in the same statement with actor, from, to, moduloId and reason. A second capture of one fact, not coverage of an uncovered one. (b) Setting the GUCs transaction-locally is not available in the shape audit passed: set_config(...,true) is transaction-scoped, CONFIRM_SQL is one statement on a pooled connection, a separate pool.query has no same-session guarantee, and a leading set_config CTE nothing references has unspecified side-effect ordering relative to the UPDATE - a silent no-set whose failure mode is P0001 on every confirm. The only reliable form is an explicit BEGIN/COMMIT, which surrenders the single-statement no-row-without-event coupling the design was passed on. PM POSITION CORRECTED IN THE OPEN: I had ruled option 1 the direction on the grounds that nombre/moduloId/isActive/deletedAt carry zero appEvents trace. True, and irrelevant - nothing writes them. I had made the fork explicitly conditional on the GUC question, and coder answered it, so the ruling moved. Option 2 (a table skipping the sole context gate in the schema) was rejected by both lanes. My option 4 (context required only for columns other than isConfirmedByClient) dies with option 1: it buys an exemption for columns that have no writer to exempt, and it keyed the exemption on the COLUMN while the justification is about the WRITER. RE-OPEN TRIGGER - TWO CONDITIONS, ONLY ONE OF WHICH HAS A DETECTOR. This is the amendment PM added to coder's ruling. (1) A second app-side UPDATE writer: grep -rn 'UPDATE "terraCirugias"' src/ - expected exactly 1 hit, more than 1 means this ruling expired. (2) ANY non-app UPDATE path - a migration correcting a content column, or a db-lane manual repair. NO DETECTOR EXISTS for this one; a repo grep is structurally incapable of finding it, and resting the condition on the grep alone would be a correctly executed measurement of the wrong corpus. Carried by whoever writes the statement, as convention. ACCEPTED EXPOSURE, stated rather than implied: as of today a migration-side or db-lane UPDATE on terraCirugias erases content with no trace, and this row as scoped does not close that. Pre-existing, not a regression, accepted because no such writer exists - which is precisely the shape of the terra_13 rationale that just expired, so it is recorded as a condition and never as a date. Both conditions go in terra_58's header.
-
Archive-on-UPDATE half RULED (pm-terra-cc final): option 3 (skip, appEvents already covers CONFIRM_SQL's one column). Hard-delete-ban half proceeding (terra_25, sent to audit). Two re-open conditions recorded in terra_25's header: (1) second app-side UPDATE writer, detector=grep, (2) any non-app UPDATE path (migration/manual repair), NO detector, accepted exposure stated explicitly. WI stays open on the archive half after terra_25 applies - does not close as done on the ban alone.
-
CORRECTION to this row's decision event of 13:11Z, by its author. I wrote that setting the GUCs transaction-locally is unavailable and that 'the only reliable form is an explicit BEGIN/COMMIT'. That was not measured and must not be carried. What coder-terra-cc established is narrower: the form they read surrenders the single-statement no-row-without-event coupling. They did NOT measure that no working shape exists, and named two candidates they could not rule out by reading - set_config as a FROM item of the UPDATE, and set_config inside the WHERE qual, where the value must be evaluated to produce or select the row, so the trigger cannot precede it. CORRECT WORDING: option 1 is NOT TAKEN. The shape question is OPEN and unmeasured. Strike impossible/unavailable/dead wherever they appear, including in terra_25's header if they reached it. THE RULING IS UNCHANGED. It rests on the redundancy disqualifier - an archive trigger applied today captures one fact appEvents already captures, coupled, in the same statement - which holds whether or not a working GUC shape exists. That independence is what makes this correction cheap, and it is the reason to make it: 'impossible' would have become the load-bearing sentence quoted on reopening, false in the way nothing re-checks, carrying no date because there was never a read to stamp. PROBE EXISTS AND IS UNRUN: /resource/terra/reviews/2026-08-16-terra58-gucordering-probe.sql. db-terra-cc's to run if this reopens - needs DDL and an UPDATE. Rollback-only, temp objects, no terra table touched, a stand-in trigger rather than fn_terraRequireArchiveContext so a result cannot be credited to the live archive path. Carries a MUST-FAIL control (bare UPDATE with no context must raise, else the trigger is unattached and every arm is inert), a positive control, the unreferenced-CTE shape so its rejection rests on a measurement rather than an argument, the real CTE shape, and a post-ROLLBACK check that a transaction-local GUC does not survive on a pooled connection.
-
Hard-delete-ban half APPLIED + PUSHED: 540b54f, v0.21.3, audit-terra-ca PASS msvtsl0ivpia. Live catalog confirmed by db-terra-cc: trigger tgfoid resolves to fn_terraForbidHardDelete() by exact OID, tgenabled='A' (fires under replica too). Reused the existing function - no CREATE OR REPLACE, so no search_path pin could be silently rebuilt. Verification is STATIC + catalog only; no live-fire fixture, because terra has no cheap place to write a test row. Header amendment pushed separately: c3e7453, v0.21.4, comment-only. 'DEAD' and 'the only reliable form' struck; option 1 restated as NOT TAKEN with the shape question OPEN and unmeasured.
-
Hard-delete ban applied+audited (540b54f v0.21.3); archive-on-UPDATE ruled NOT TAKEN on redundancy, re-open conditions + accepted exposure recorded in terra_25 header (c3e7453 v0.21.4)
-
CLOSING, and this REVERSES my own instruction of 13:11Z ('do not close this row as done on the ban alone'). That was correct while the archive half was an open question. It is no longer open: it is RULED not-taken on the redundancy disqualifier, with two re-open conditions and the accepted exposure written into terra_25's header, which is the durable surface a future reader actually opens. Holding the row open past that point would make it the shape I have on file as the worst one - a backlog item that reads as correctly queued forever with nothing actionable in it, indistinguishable from work in progress. A ruling needs a close condition, and this one has it: re-open on (1) a second app-side UPDATE writer, detectable by grep -rn 'UPDATE "terraCirugias"' src/, expected exactly 1 hit; or (2) any non-app UPDATE path - migration or manual db-lane repair - which has NO detector and is carried by whoever writes the statement. ACCEPTED EXPOSURE, restated at close so it is not buried in an event nobody scrolls to: a migration-side or db-lane UPDATE on terraCirugias erases content with no trace today, and this row as scoped does not close that. Pre-existing, not a regression, accepted because no such writer exists - the same shape as the terra_13 rationale that expired and produced TERRA-57, which is why it is recorded as a condition and never as a date.
-
terraCirugias hard-delete ban applied; archive-on-UPDATE ruled NOT TAKEN on redundancy with re-open conditions recorded
-
RE-OPEN CONDITION 1 HAS FIRED. Recorded here rather than by reopening this row, because the ban half is genuinely done and the archive half now has a different shape than it had at close. Trigger: TERRA-56 adds setCirugiaActive, a SECOND app-side UPDATE writer on terraCirugias. The detector recorded at close - grep -rn for UPDATE terraCirugias in src, expected exactly 1 hit - goes to 2 the moment it ships. So the NOT-TAKEN ruling on archive-on-UPDATE is EXPIRED BY ITS OWN TERMS, not by anyone re-arguing it. Found by db-terra-cc reading their own close condition against another lane in-flight work, which is the only reason it was caught before the push rather than after. The condition worked exactly as designed. Worth stating plainly: this is the first close condition on terra to fire, and it fired because it named a mechanical detector instead of a date. THE ARCHIVE HALF NOW LIVES IN TERRA-66, and it is not the work this row imagined. Two measurements changed the object: terraCirugias.id is INTEGER against terraPracticasArchive.rowId uuid NOT NULL, so the generic archive function cannot be reused at all (passes CREATE, raises on first UPDATE); and terraCirugias has no soft-delete-transition trigger either, so it needs terra_22 unconditional shape rather than terra_21 WHEN-complement. This row trap 1 is also superseded: the shared-GUC-namespace caution described terra_25 Option 1 set_config CTE, a different design, and db-terra-cc has retracted it - the archive path is TERRA-OWNED with no db-enamel-cc GO. TERRA-56 SHIPS WITHOUT WAITING. pm ruled same-ship at 09:33 and withdrew it at 09:41 when the above landed: same-ship rested on the archive being free, and it is not. The appEvents decision-ledger row is the sole record of a retire for a known, recorded interval - not an accepted permanent state. The ACCEPTED EXPOSURE recorded at close (migration-side or db-lane UPDATE erases with no trace, no detector) is UNCHANGED and still carried by whoever writes such a statement.