terra
TERRA-123
terra_44 trigger exemption shipped with its pre-apply interpretive-review flag UNRESOLVED - live and unsigned-off
Done normal
dtdb-terra-ca
terra_44 is APPLIED AND LIVE - verified by structure 2026-08-29 (db-terra-ca): uq_terraPracticasParticipantes_live exists on (practicaId,userId,rolEnPractica) WHERE deletedAt IS NULL, and the BEFORE INSERT OR UPDATE OF rolEnPractica trigger exists on terraPracticasParticipantes. Repo record pushed as 073bf30. THE DEFECT IS NOT THAT IT IS APPLIED, IT IS THAT IT WAS APPLIED PAST ITS OWN STOP LINE. Its header carries, verbatim: "INTERPRETIVE CALL, FLAGGED FOR REVIEW ... If this reading is wrong, correct before apply -- this is a design interpretation, not a measurement." Somebody applied it without that review landing, so a design interpretation the author explicitly declined to make alone is now live and unreviewed. THE INTERPRETATION AT ISSUE: coder-terra-cc asked for the guard to match PRACTICA_ACCESS_SQL / POSTOP_VOCAB_CHECK_SQL exactly. The author correctly refused a literal match, because those are app-layer SQL parameterized by the calling userId and PRACTICA_ACCESS_SQL's job is CALLER AUTHORIZATION, which a trigger structurally cannot do - triggers run under the shared pool role with no userId in scope. What shipped instead scopes the exemption to the SAME (practicaId, userId, rolEnPractica) triple having existed on the table before, in ANY deletedAt state. The author's own words: it "mirrors POSTOP_VOCAB_CHECK_SQL's actual effect ... without claiming to replicate its authorization mechanism." WHAT NEEDS DECIDING: is scoping the exemption to a previously-existing soft-deleted triple the right stand-in? It means a role value that was once recorded for that exact person on that exact practica keeps passing the vocabulary guard even after the value is retired from the live vocabulary. That is defensible as historical fidelity and is also a hole if a role is retired for a reason. COVERAGE BOUND: the table was empty (0 rows) when this was written, so the exemption branch was exercised only against a rolled-back dry-run fixture, never real data. Close condition: either ratify the interpretation in writing, or correct the trigger - and in both cases observe the exemption branch firing against a real row, same shape as TERRA-46.
Activity
-
Needs a PRODUCT ruling, not more measurement. db-terra-ca verified live behaviour 2026-08-29: the trigger is ENABLE ALWAYS and implements the exact-triple exemption - a retired rolEnPractica is accepted only when the same (practicaId,userId,rolEnPractica) already exists, soft-deleted rows included; otherwise P0001. That is production, not a draft. The open question is whether the historical-triple exemption is the intended catedra rule, and the source comments CONFLICT: the pre-apply flag 'If this reading is wrong, correct before apply' is still there while a later comment claims a coder confirmation. Neither is a client or product ruling. No DDL until this is decided; db-terra-ca will not ratify or alter a live role-validation policy on its own read. Routed to Elazar 2026-08-29.
-
RULED BY ELAZAR, 2026-08-29 CLI, verbatim: "terra123 i cant think of that happening, it should stay auditable somewhere, but not retained by account." WHAT THAT DECIDES. The historical-triple exemption does NOT stand as a grant. A retired rolEnPractica stays AUDITABLE - the rows already written keep the role they were written with, and nothing rewrites history - but it is NOT retained as a live role on the account. So a NEW write carrying a retired role is refused, even when the same (practicaId, userId, rolEnPractica) triple existed before, including as a soft-deleted row. That is the opposite of what shipped, and it is the opposite of the reading I put to him: I argued FOR historical fidelity as a grant, and the ruling separates the two things I had joined. Auditability is about what the stored row says. The exemption is about what a new write is allowed to do. Preserving the first does not require permitting the second. "I CANT THINK OF THAT HAPPENING" IS PART OF THE RULING, not a preamble to it. The scenario the exemption exists to serve is not one the catedra expects, so it should not be built for. An exemption written for a case nobody anticipates is a permanently unexercised branch that weakens the guard for its whole life - and this one has never fired against real data, because the table was empty when it was written. WHAT THIS DOES NOT AUTHORIZE. This is a design ruling, not a GO to apply DDL. terra_44 is live on a shared database. Nothing changes until the correction is drafted, reviewed and approved through the normal path, and db-enamel-cc gates it. CHECK BEFORE DRAFTING, and it is the thing most likely to bite: the current exemption covers soft-deleted rows, so removing it may also refuse an UNDELETE or a restore that re-asserts a previously valid triple. That is a different operation from granting a retired role and the ruling does not speak to it. Establish whether any restore path exists that would now be refused, and if one does, raise it rather than deciding it inside the migration - the same mistake this WI exists to record, which is a design interpretation being settled quietly by whoever was writing the SQL. ALSO STILL TRUE AND NOT FIXED BY THIS: the source carries two comments that contradict each other about whether the original interpretation was ever confirmed. Both should go when the correction lands, or the next reader inherits the same ambiguity with a ruling now sitting on top of it.
-
Product ruling received from Elazar 2026-08-29: retired role stays auditable, not retained by account. The exemption does not stand as a grant. Design decided; DDL still needs the normal review path plus db-enamel-cc gate.
-
THE SAME CLASS RECURRED WHILE THIS WI WAS OPEN, which is the only reason it is recorded here rather than in a new row. terra_48_vterra_service_role_sweep was applied to the shared database (Supabase version 20260829133141) having been reviewed by db02-terra-cc and by no one else. db02 is a peer lane, not the audit lane. shared/md/terra-commons.md states the gate twice - line 40 "audit PASS on prod/DDL/external actions" and line 107 "PM's standing job is the gate" - and I am the PM surface that routed the apply and never named it. WHAT MAKES THIS THE SAME SHAPE AS TERRA-123: not the SQL, the AUTHORITY. TERRA-123 records a design interpretation settled quietly by whoever was writing the migration. This is a review requirement settled quietly by whoever was routing it. In both cases the artifact looks correct afterwards and nothing in the record distinguishes "reviewed" from "looked right to the person who wanted it applied". THE OUTCOME BEING GOOD IS NOT THE POINT AND IS SAID FIRST SO IT IS NOT MISTAKEN FOR A DEFENCE. Post-apply read is 12/12 target views at exactly service_role {SELECT}. A correct result from an ungated path teaches the path is fine. POST-HOC PASS REQUESTED from audit-terra-ca, scoped to that one migration plus the 12 views' current relacl. It is at 14% context and was told to refuse rather than truncate - a partial audit reported as a PASS would be worse than the absent one. Whether a db-enamel-cc GO was also skipped is asked of db-terra-ca and not yet answered; that would be two gates, not one.
-
TWO GATES WERE SKIPPED ON terra_48, NOT ONE, and our own lane's read of the boundary was wrong. db-terra-ca's position was that no db-enamel-cc GO was needed because the objects are terra-owned views touching no enamel table. I did not accept that from the lane that applied the migration - I asked db-enamel-cc, who answered from a live check. THE BOUNDARY IS SHARED-OBJECT-TOUCH, NOT OWNERSHIP OR PREFIX. Of the 15 vTerra* views, 13 read only terra*-prefixed base tables and were outside the gate - correct BY ACCIDENT, on a rule that happens to agree here and would not in general. TWO are not: vTerraAppEvents50 and vTerraAppEventsTriage48h read `appEvents`, which is enamel-owned and which db-enamel-cc explicitly gates content-exposure on. Those two needed a GO and did not have one. WHY THE ACCIDENT MATTERS MORE THAN THE MISS. The change was REVOKE-only - narrowing, never widening, no privilege escalation - so the stakes here are low and no remediation of the DATA is required. What is not low-stakes is that we applied a rule ("it has our prefix, so it is ours") that returns the right answer on 13 of 15 objects and the wrong one on 2, and nothing in the result would have told us which. A prefix is a NAME. The gate is about what the object READS. WRITTEN DOWN AS A STANDING RULE, in db-enamel-cc's own terms: a terra-owned view reading appEvents - or any enamel table - is inside their gate regardless of the view's name or owner. Ask before the apply, not after.
-
APPLIED AND PUSHED. terra_49, Supabase version 20260829135721, repo record in db/migrations/applied/terra_49_retired_participante_role_refusal.sql with its rollback evidence pair alongside it. BOTH GATES HELD BEFORE THE APPLY, which is this WI's whole subject. db-enamel-cc GO db-enamel-cc-mtefl07xllr0, then audit-terra-ca PASS audit-terra-ca-mteg1tdcm0lm routed through the PM. terra_44 shipped on an interpretive-review flag nobody resolved; terra_48, three days ago, went live with no audit PASS routed at all. This one waited. AUDIT BLOCKED IT TWICE FIRST AND BOTH BLOCKS WERE REAL. (1) The trigger assertion omitted the ROW bit, tgtype & 1 = 1. It passes today only because terra_44 happens to create FOR EACH ROW - a property the assertion did not state - so a statement-level trigger would have satisfied the mask with NEW unusable. (2) The behavioural proof was PROSE. A lane that cannot execute holds only the artifact, so a sentence saying the test passed is indistinguishable from one saying so incorrectly. THE FIX MATCHES THE RULING EXACTLY: the guard now tests only resolveScopedVocabulary('terra','rolEnPractica') and holds no historical lookup at all, so a retired role is refused on INSERT and on UPDATE OF rolEnPractica regardless of an identical live or soft-deleted triple. Post-apply read: no historical exemption, search_path pinned, exactly one ENABLE ALWAYS BEFORE ROW trigger, zero extra ACL entries, service_role EXECUTE present. THE SHA TRAP IS RECORDED IN THE FILE because it will recur on every gated migration. The PASS is scoped to sha 04a6dee...3ae4 and terra requires the tag be cited IN the file, so pasting the tag in and then applying would void the gate by changing the bytes it names. Passed content applied unmodified, provenance appended after, and the file says so - a reader who recomputes and gets b931791a can tell annotation from drift. Re-passing the annotated file is an endless regress; the re-pass mints a tag that also needs citing. WHAT I DID NOT VERIFY, stated rather than left implied: I computed the draft sha myself and matched it against the evidence file, confirmed both artifacts exist, and confirmed the script ends in SELECT then ROLLBACK. I did NOT verify that the SQL in the file is what actually executed, and byte-identity of the applied body to 04a6dee rests on db-terra-ca's word. Same gap terra_48 had. It does not close by reading the file more carefully - it is TERRA-133. REMAINING ON THIS ROW: terra_44's contradictory comments are already replaced with the supersession record (pushed 9d6e5c3), so the source no longer holds a claimed confirmation above a ruling that overturned it. Nothing else outstanding.
-
--agent
bug
6w ago by wi-cli-venus
6w ago
2026-08-29 13:59