Intraoperative-complication DB invariant is ENABLE ALWAYS and replica-tested

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
  parent=#3078
• wi-cli-venus note · 6w ago
  App enforcement under the parent is not proof of the database invariant. Preserve pre-existing zero-row legacy; unrelated UPDATE must work. New-write coverage: parent insert ending empty, sin-only, actual one or multiple, contradiction, relevant child soft-delete causing zero, and legacy unrelated update.
• wi-cli-venus note · 6w ago
  App-side enforcement of this invariant SHIPPED AHEAD OF THIS MIGRATION in df8faf1 (2026-08-30) and is not evidence that the invariant exists. practica-complicaciones-core.ts refuses an empty or contradictory answer in the form and in practica-actions.ts, so the feature WORKS TODAY and looks identical to the state where the database holds the rule. Do not close this WI on the working form. The DB boundary still accepts what terra_6:416 always accepted - COALESCE(complicacionesIntraArg, '{}'::text[]) - so any writer that does not import that module still writes an empty answer successfully. Only an applied migration closes this.
• wi-cli-venus note · 6w ago
  PRECONDITION MEASURED BEFORE ANY DRAFTING, and the headline number is a trap rather than a green light. db02-terra-cc, live data, SELECT only, evidence agents/db02-terra/evidence/2026-08-31-terra_136-precondition-measurement.result.txt. THE FOUR ANSWERS. Legacy practicas with zero intraoperative-complication rows: 0 of 6 total, with the filter proven non-vacuous by 7 live intra rows. Pre-existing rows carrying sinComplicaciones together with an actual complication: 0, with the filter proven non-vacuous by 2 live sinComplicaciones rows. Shape, from the catalog rather than from the app's naming: child table terraPracticasComplicaciones, practicaId FK to terraPracticas(id), fase CHECK IN intra/post, and sinComplicaciones is a VALUE in the value column under lookupOptions category terraComplicacionesIntra - NOT a column and NOT a flag, so any constraint written against a boolean field is written against a table that does not exist. Six existing triggers on the table (archive x3, forbidHardDelete, forbidTruncate, vocabGuard on value and fase); vocabGuard checks a value against the live vocabulary only and carries no cross-row exclusivity, so nothing here collides with the new rule and, more importantly, nothing here should be read as already covering it. WHY 0 VIOLATIONS IS NOT PERMISSION TO SHIP VALIDATED WITHOUT SAYING SO. Both zeroes are measured over a SIX-PRACTICA population. Correct-for-today, not proof against a state that has never occurred. A validated constraint added on that basis is a decision resting on an uncontrolled zero, and it should be recorded as such in the migration rather than presented as a clean precondition. AND THE CLAUSE THAT MATTERS MOST IS VACUOUS IN THE DATA. This row's own requirement is to PRESERVE historical practicas that legally have zero complication rows. There are none. Zero of six. So the preservation half of the invariant cannot be exercised by any dry-run against live data, cannot be observed to work, and will ship untested while looking covered - the drafter reads 0 legacy violations and concludes the legacy path is safe, when what was actually established is that the legacy path is unreachable. That is a scoping clause with no population behind it, the same shape as TERRA-148. Write it, but write down that it is untested and say what would test it. STILL db-terra-ca's TO DRAFT. This is the measurement, not the migration, and it does not authorise an apply.
• wi-cli-venus note · 6w ago
  THE DRAFT ALREADY EXISTED AND NOBODY SAID SO. db/migrations/draft/terra_51_practica_intra_complicacion_required.sql is dated 2026-08-30 04:02, written the day BEFORE db02-terra-cc measured the table's shape. It was not mentioned when the drafting assignment was acknowledged. Found by listing the draft directory rather than by asking - which is the point: an artifact on disk answers a question that a status line does not. IT SURVIVES THE MEASUREMENT, which is the good news and was not guaranteed. The draft models sinComplicaciones as a VALUE in the value column rather than as a boolean or a flag column, so the warning issued from db02's shape finding was already satisfied. Deferred constraint triggers are the correct instrument for a parent-plus-child single-transaction write; search_path pins pg_temp LAST; and the pre-flight assert deliberately checks the contradiction condition WITHOUT checking the zero-answer condition, which is exactly what preserves legacy rows rather than retroactively invalidating them. THREE FINDINGS FROM READING IT, all revisions to the same file, none of them a redesign. FIRST, AND I CHECKED THIS RATHER THAN ASSUMING IT IN EITHER DIRECTION. I initially read the AFTER DELETE constraint trigger as dead code, on the grounds that fn_terraForbidHardDelete guards the table. It is NOT dead. That guard carries a transaction-local escape - app.bypass_terraHardDelete set to the string true - for data-heal. So the DELETE arm fires ONLY during a heal, which is precisely the operation where somebody is deliberately removing rows, and it will REFUSE any heal that removes the last live intra answer from a live practica. The new constraint has no corresponding bypass, so that heal cannot complete: the operator must restore an answer or soft-delete the parent inside the same transaction. That may well be the correct ruling. What it must not be is implicit, discovered mid-heal by the person least able to stop and reason about it. Decide it in the file: either the invariant is absolute and the documented heal procedure changes, or the constraint adopts the same bypass-GUC pattern the delete guard already uses. SECOND, THE PRESERVATION CLAUSE PROTECTS AN EMPTY SET AND THE FILE PRESENTS IT AS PROTECTING A POPULATION. The header states that existing zero-answer practicas are intentionally preserved. Measured: 0 of 6. There are none. The behaviour therefore ships exercised only by the synthetic row in the draft's own fixture arm 6, and never by real data, while a reader encountering a carefully reasoned legacy clause will infer a legacy population behind it. The file must say the protected set is EMPTY as measured 2026-08-31, that arm 6 is the only thing that will ever exercise it, and that this is a forward guarantee rather than a migration of existing state. THIRD, THE ACL ASSERT IS NARROWER THAN THE REVOKE DIRECTLY ABOVE IT. The migration revokes from PUBLIC, anon and authenticated, then asserts only grantee = 0. anon and authenticated go unverified, while the assert's presence reads as having verified the whole line. Assert the pair or narrow the claim. AND THE SIX-ROW BOUND GOES IN THE FILE, not only on this row: both preconditions were measured over a six-practica population, correct-for-today rather than a general safety property, so nobody later reads 0 violations as proof against a state that has never occurred. STATUS: draft only, no dry-run yet, no gates, no apply. Revisions assigned back to db-terra-ca as a single-artifact order.
• wi-cli-venus statusChanged · 6w ago
• wi-cli-venus progress · 6w ago
  Draft revised and independently verified. terra_51 SHA-256 36ef6a974c1cc276c6063e9ce8d58795c8b2b776a46adf3d6f212e937b4b5077, recomputed by me rather than accepted; header READ rather than grepped, because a keyword can be present while the sentence says nothing. All three findings addressed in substance: the heal-delete ruling is stated as ABSOLUTE with the operator's actual remedy (add a replacement answer or soft-delete the parent in the same transaction), the six-practica bound is written as a current-population fact explicitly not generalised, the preservation path is named as having no live historical instance with fixture arm 6 as its only execution evidence, vocabGuard is recorded as neither colliding with nor covering this invariant, and the ACL assert now covers anon and authenticated alongside the PUBLIC grantee=0 leg. Remaining before dry-run: the file must state its own shared-object TOUCH analysis in db-enamel-cc's terms and route it to them for confirmation rather than skipping the gate on the author's reading - that is the shape that produced TERRA-153 and I am deliberately not ruling it myself. And arm 6 is the load-bearing fixture: arms 1-5 exercise the new refusals, arm 6 is the only evidence the preservation clause does anything, and its population does not exist in live data. No dry-run, no gates, no apply.
• wi-cli-venus audit-finding · 6w ago
  APP-side source audit: createPractica validates required/exclusive intra values server-side before BEGIN (practica-actions.ts:229-230 via practica-complicaciones-core.ts:14-20) and writes intra rows at 512-518; its two-invariant creation acceptance matches terra_51. The only other complication action writes literal post rows only, so no app intra edit/archive path was found. Source review only: no live DB, fixture matrix, authenticated browser, or action invocation.
• wi-cli-venus note · 6w ago
  APP-SIDE ACCEPTANCE SET MEASURED AGAINST THE DRAFT, BEFORE IT APPLIES RATHER THAN AFTER. coder-terra-ca, source-level, no live DB and no authenticated browser - stated as their own coverage bound. Result: on the creation-input domain the app and terra_51 accept EXACTLY the same set, for both invariants. The required-answer rule is enforced in the SERVER action at practica-actions.ts:229-230 via validateComplicacionesIntra before BEGIN, not merely in the browser, so a stale tab or a direct server-action call cannot create a zero-answer practica; the form mirrors the same helper but is not relied upon. The exclusivity rule matches terra_51's has-sin AND has-non-sin predicate at practica-complicaciones-core.ts:14-20. One benign nuance recorded rather than smoothed over: a duplicated sinComplicaciones is refused by the app as a conflict where terra_51's two predicates alone would not call it one - not an acceptance difference, because the live unique index on (practicaId, fase, value) refuses it anyway, but a DIFFERENT FAILURE REASON reaching the user, which is worth knowing when someone reads the friction rail. I DID NOT ACCEPT THE ABSENCE CLAIM ON A SEARCH. 'No other writer exists' is the class of claim that dies on the grep nobody ran, so I censused every source reference to terraPracticasComplicaciones myself: two writer modules only, practica-actions.ts inserting and practica-postop-core.ts inserting and updating, with informe-query.ts and practica-detail.ts read-only. And the postop soft-delete UPDATE carries AND fase = 'post' at practica-postop-core.ts:183, so it cannot archive an intra answer and cannot trip the new invariant. CONSEQUENCE FOR SEQUENCING: no Spanish-copy change needs to ship WITH terra_51, because there is no submission path the DB will reject and the app will not. That was the open question this measurement existed to close. The app remains narrower than the DB only in the harmless direction - the DB additionally protects direct child DML the app does not expose.
• wi-cli-venus note · 6w ago
  SHARED-OBJECT GATE: CONFIRMED OUTSIDE, BY THE OWNER, ON THE EXACT BYTES. db-enamel-cc read the full draft and confirmed it sits outside the shared-object gate, no GO needed. They cited SHA-256 005ee2481758d25c907b34e29c2424586b70f91046d430b0673fcbaf7fb3eddb, and their stated basis is a touch census rather than a reading of the author's summary: every table and function reached is terraPracticas, terraPracticasComplicaciones or fn_terraRequireIntraComplicacionAnswer, with no users, appEvents, groups, lookupOptions or vUserGroups, no role-global or schema-wide grant, and no shared function called. I RECOMPUTED THE SHA MYSELF against the file on disk and it matches 005ee248...eddb, so the confirmation is bound to the revision that exists now and not to a superseded one. This is the whole reason a gate answer must cite bytes: I had recorded 36ef6a97... for an earlier revision of this same path, and a confirmation quoting no SHA would have been indistinguishable between the two. WHY THE GATE WAS ROUTED RATHER THAN DECIDED HERE. The author's own touch analysis reached the same conclusion and was still not sufficient, because the gate's owner decides its scope. I got exactly this judgment wrong on TERRA-133 and the correction was that the citing lane does not get to classify itself out of another lane's gate. The analysis in the file is now a claim addressed to db-enamel-cc, and their answer is the record. WHAT REMAINS AND WHAT IS STILL FORBIDDEN. The rolled-back dry-run fixture matrix has NOT been run. No apply. Arm 6 - a synthetic pre-existing zero-answer practica taking an unrelated parent UPDATE and committing - is the load-bearing arm, because it is the only execution evidence the preservation clause does anything at all: the population it claims to protect is 0 of 6 live practicas, so nothing in real data will ever exercise it.
• wi-cli-venus note · 6w ago
  ARM 6 RAN AND ITS GREEN IS NOT YET EVIDENCE. A SECOND PASS IS ORDERED BEFORE THIS COUNTS. db/migrations/dryrun/2026-08-31-terra_51-arm6.sql exists and was run inside a transaction ending in ROLLBACK. The reported sequence: a synthetic parent with zero live intra answers created FIRST, terra_51's DDL applied afterwards in the same transaction, an unrelated archiveReason UPDATE issued against that parent, then SET CONSTRAINTS ALL IMMEDIATE, which returned without exception. THE TWO MID-RUN REFUSALS ARE WORTH RECORDING BECAUSE THEY SHOW THE RUN WAS REAL. The first fixture attempt was rejected by fn_terraAssignPracticaNumber with practicaNumber is assigned by the database not the caller; the second reached the UPDATE and was rejected by the parent archive trigger with terra archive app.terraUserId GUC not set. Both are existing guards behaving correctly against a synthetic row, and both were reported rather than smoothed out of the account. BUT THE PASS CANNOT BE DISTINGUISHED FROM AN EMPTY EVALUATION, and separating those is the only reason this arm exists. Trace what SET CONSTRAINTS ALL IMMEDIATE actually had to check for this fixture. The parent was inserted BEFORE the DDL existed, so no parent-INSERT constraint event was ever queued for it - which is correct, and is precisely what makes it a legacy row. terra_51 attaches no UPDATE trigger to terraPracticas by design, so the unrelated UPDATE queued nothing. No child row was touched, so the three child arms never fired. THE DEFERRED QUEUE FOR THAT PRACTICA WAS EMPTY, and returning without exception is exactly what an empty queue returns. So the observed result is equally consistent with the preservation clause working and with nothing having been checked at all. Those two worlds emit identical output. This is the uncontrolled-zero shape this project has already been bitten by, arriving in the one arm that was designated load-bearing. WHAT WAS ORDERED, one edit and one run on the same file: in the SAME transaction, after the legacy parent's UPDATE and before ROLLBACK, insert a SECOND parent created with the DDL already in place and leave it with zero live intra answers, then SET CONSTRAINTS ALL IMMEDIATE again. It must RAISE, naming that new practica, with the new-practica message and ERRCODE P0001. If it raises, arm 6's earlier silence becomes evidence, because the same statement in the same transaction has been shown capable of firing against the same table. If it does not raise, arm 6 proved nothing and terra_51 carries a real defect found before apply rather than after. ON THE MISSING COMMAND TAGS: not chased. The MCP path returns only a final result set, and a SELECT count of live intra answers for each practica id taken before the SET CONSTRAINTS supplies the same evidence in a form that does come back. An instrument that cannot be read is replaced, not insisted on. Still no apply and no audit request.
• wi-cli-venus note · 6w ago
  ARM 6 IS NOW EVIDENCE. THE CONTROL FIRED IN THE SAME TRANSACTION. Observed at SET CONSTRAINTS ALL IMMEDIATE, quoted from the run: P0001, terra: new practica 373ce608-85ba-4e90-8f5f-1c06070cbb18 requires at least one active intraoperative-complication answer, with CONTEXT naming fn_terraRequireIntraComplicacionAnswer line 34 at RAISE. That is the parent-INSERT branch, and the practica named is the one inserted AFTER terra_51's DDL with zero live intra answers. WHY THIS CHANGES THE EARLIER SILENCE FROM NOTHING INTO A RESULT. Before the control, arm 6's clean SET CONSTRAINTS was equally consistent with the preservation clause working and with an empty deferred queue - two worlds emitting identical output. The control puts both cases in ONE transaction, against ONE table, evaluated by ONE statement: the legacy parent, created before the DDL and given an unrelated archiveReason UPDATE, passed through without exception, and the new parent aborted. The mechanism is therefore demonstrably live at the moment the legacy row went unchallenged. THE PRECISE THING PROVEN, stated narrowly because the strong reading is available and wrong. This does not show the legacy parent was checked and found acceptable. It shows the legacy parent QUEUED NO CONSTRAINT EVENT AT ALL - which is exactly the design claim, since terra_51 attaches no UPDATE trigger to terraPracticas, and an unrelated parent UPDATE is meant to be incapable of invalidating a pre-existing zero-answer row. Preservation here means not evaluated, not evaluated-and-passed, and the distinction matters to whoever reads this next. ONE LIMIT ON THE RECORD. The abort replaced the preceding SELECT counts in the MCP response, so the two practicas' answer counts were not returned; the exception's own text names the offending id, which carries the same discrimination. And because the transaction aborts on the first failure, this run cannot order events between the two parents - it does not need to, since the legacy parent queued none by construction. BOTH FIXTURE INSERTS DELIBERATELY CARRIED ZERO CHILD ROWS, so the child arms are still entirely unexercised. Arm 6 is satisfied; arms 1 through 5 are not, and nothing here licenses an apply.
• wi-cli-venus blocked · 6w ago
  ARMS 1 TO 5 OF THE terra_51 DRY-RUN MATRIX ARE UNRUN. NOTHING HAS BEEN EXECUTED FOR THEM. The row carries this rather than an absence, because an absence in a directory that already holds one real dry-run file reads as "not written yet" when the truth is "written, and it tests nothing". WHAT ARRIVED WAS A SKELETON, AND I READ IT RATHER THAN COUNTING THE FILE. db/migrations/dryrun/2026-08-31-terra_51-arms1-4.sql appeared at 1286 bytes against arm6's 11576, which is the only reason I opened it instead of treating its appearance as completion. The SAVEPOINT and ROLLBACK TO scaffolding is present and the 1, 4, 2, 3 ordering is respected, so the shape is right. Every arm body is a comment. There is no INSERT, no SET CONSTRAINTS ALL IMMEDIATE, no DDL, and its own line 8 states that execution is blocked until the migration body is copied in. THAT FILE WOULD HAVE RUN GREEN. BEGIN, four SAVEPOINT and ROLLBACK TO pairs against nothing, ROLLBACK - it succeeds, raises nothing, and exercises no trigger. A skeleton that completes without error is indistinguishable on disk from a matrix that passed, and it is sitting in dryrun/ under a name announcing arms 1 to 4 beside a file that genuinely ran. The next reader of that directory - including the agent that wrote it, after a compact - sees two terra_51 dry-run artifacts and concludes the matrix executed. Ordered deleted for that reason: the absence is honest and the artifact is not. THIS IS THE SAME FAILURE AS ARM 6'S FIRST GREEN, ONE LAYER OUT. Arm 6 passed against an empty deferred queue - parent inserted before the DDL, no parent-UPDATE trigger, no child touched - and only a discriminating control in the same transaction turned it into evidence. There the uncontrolled zero was in the data; here it is in the file. Both produce a clean result from a check that never ran. THE CAUSE IS CONTEXT, NOT THE ATTEMPT, and it is worth naming so the next assignment is not the same one. db-terra-ca is at 19 percent. Copying terra_51's executable body plus four fixture arms into one transaction does not fit in that, and a skeleton is what the constraint produces - the shape gets written because the shape is cheap and the bodies are not. Three prior orders on this item came back as plans; the fourth came back as a plan in SQL syntax. STATE: terra_51 remains UNAPPLIED and unaudited, which is correct. Arms 1 to 4 unrun, arm 5 - archiving the final live intra answer with app.terraUserId and app.terraArchiveReason set - never written into any file. Arm 6 is the only executed arm and its evidence stands. The blocker is DB-lane context, and restarting a session is not my call; routed to Elazar alongside the same question for audit-terra-ca.
• wi-cli-venus blocked · 6w ago
• wi-cli-venus note · 6w ago
  BLOCKER EXPIRED UNWATCHED, AND THAT IS THE FIRST THING WORTH RECORDING. This row was blocked at 15:37 with the stated reason "the blocker is DB-lane context, db-terra-ca is at 19 percent". I captured their pane before assigning anything: 65 percent. The condition had lapsed, nothing was watching it, and the row would have sat blocked indefinitely - a block whose condition has quietly expired is indistinguishable from one that still holds, because the status line is identical either way. blockedReason on this row is EMPTY; the real condition survived only in free-text. THE THREE REVISIONS ARE IN THE FILE AND I VERIFIED THEM AT SOURCE, not from the lane's report. Heal-delete ruling absolute at :26-28 - fn_terraForbidHardDelete's transaction-local app.bypass_terraHardDelete permits a data-heal DELETE but does NOT bypass this deferred invariant, so a heal removing the final live intra answer must supply a replacement or soft-delete the parent in the same transaction. Forward-guarantee wording at :21, with the protected population stated EMPTY as measured (0 of 6 live practicas) and exercised only by synthetic arm 6. ACL pair at :226-232. The ACL fix uses has_function_privilege for anon and authenticated rather than more proacl rows, which is the BETTER instrument and not merely an equivalent one: it catches EXECUTE reaching those roles THROUGH a PUBLIC grant, which a grantee-row check cannot see. THE DRY-RUN MATRIX IS REAL THIS TIME. db/migrations/dryrun/2026-08-31-terra_51-arms1-5.sql is 409 lines with 63 executable statements; the previous arms1-4 skeleton, whose arm bodies were all comments and which would have RUN GREEN against nothing, is deleted. Arm 5 - archiving the final live intra answer with both archive GUCs set - exists for the first time. GATE CONFIRMATION IS VOID AND THE REASON IS THE FINDING. db-enamel-cc confirmed this draft sits outside the shared-object gate citing SHA-256 005ee248...eddb, and I recomputed that myself at the time. The file is now 513701d54dd6f0563883266e71a9454062e29673e114d3d36f7011551162c451, verified by me with sha256sum. THE REVISIONS I ORDERED ARE WHAT CHANGED THE BYTES. So requesting review edits EXPIRES A BYTE-BOUND GATE ANSWER BY CONSTRUCTION, and nothing announces it - I quoted the stale hash forward in my own assignment as though it were current. db-terra-ca caught it and refused to treat the old confirmation as binding, which was correct. Re-confirmation requested from db-enamel-cc against 513701d5; nothing applies until they answer, and if they require changes the same rule applies to whatever revision follows. ARM 6 HAS NO RETAINED TRANSCRIPT, found by find across the repo: exactly three terra_51 files exist, the draft and two .sql arm scripts, no .result artifact anywhere. This row states "arm 6 is the only executed arm and its evidence stands" and what actually stands is A HUB MESSAGE - the exact class TERRA-169 closed on today. IT IS RECOVERABLE HERE AND THE DISTINCTION IS THE POINT. TERRA-169 forbids backfilling because for an APPLIED migration the moment is gone and a transcript written afterwards manufactures the evidence rather than recovering it. Arm 6 is a ROLLED-BACK DRY RUN, so re-running it produces a genuine transcript of a genuine execution. That is recovery, not manufacture, and there is no reason to accept the absence. NEXT, gated on db-enamel-cc: run arms 1-5, RE-RUN arm 6, retain paired .result.md files beside each .sql with the migration number in the filename (terra_54's transcript is named for its WI and was invisible to every coverage count until someone read it). Arm 6's transcript must include its same-transaction discriminating control, not only its refusal - it first passed against an EMPTY deferred queue and became evidence only when a control proved the trigger was reachable at all. A refusal with nothing establishing reachability is the uncontrolled zero again. No apply, no push.
• wi-cli-venus note · 6w ago
  DRY-RUN EVIDENCE PUSHED AS 880858e AND NOTHING IS APPLIED. I confirmed the second half against the live catalog myself instead of reading it off db-terra-ca's transcript: fn_terraRequireIntraComplicacionAnswer returns oid null from pg_proc and pg_trigger holds zero triggers matching IntraComplicacion. The draft is byte-identical to the revision I gated, sha256 513701d5, so this commit adds evidence and moves no DDL. THE ARTIFACT THIS REPLACES WAS THE INTERESTING PART. arms1-4.sql carried arm bodies that were entirely comments - zero executable statements in the arm sections - so it would have RUN GREEN and produced a transcript that exists, is green, and tests nothing. Replaced rather than amended: arms1-5.sql is 409 lines and 63 executable statements. BOTH CONDITIONS I SET WERE MET, VERIFIED BY READING THE TRANSCRIPTS RATHER THAN THE SUMMARY. Arm 6 now shows its discriminating control in the SAME transaction, which is why the first run was refused: its green came from an empty deferred queue, and a refusal arm with nothing establishing that the trigger was REACHABLE in that transaction prints identically to a pass. The rerun puts 6a and 6b in one transaction and the discriminating line is the census between them - both parents listed at live_intra_answers = 0, the legacy row inserted BEFORE the CREATE TRIGGER and the new one after, and the P0001 names only the new one. Two rows identical on the predicate, one refused and one preserved, proven by one statement. Stronger than what I asked for, because it shows the legacy parent still at zero at the MOMENT of the refusal rather than at the start of the arm. ARM 5 DISCRIMINATES ON THE RAISE LINE, not on the appearance of an error. The three alternative causes are each excluded separately in the transcript: SET CONSTRAINTS IMMEDIATE then DEFERRED discharges the parent and child INSERT events before the archive UPDATE, so a deferred event firing late is out; both archive GUCs echo their set_config values and the archive UPDATE reports UPDATE 1, so archive context was ACCEPTED rather than refused; and the RAISE sits at function line 81, the live-parent-after-child-UPDATE path, distinct from line 34 in arm 1 and line 39 in arm 4. Three arms, three lines, three messages. ON_ERROR_STOP WAS DISABLED FOR ARM 6 DELIBERATELY AND THAT CUTS BOTH WAYS. It is what lets the explicit ROLLBACK be recorded after the expected error; it also means an unexpected EARLIER error would not have halted the script and would sit in the transcript looking like part of the plan. So I counted instead of assuming: arm 6 holds exactly one ERROR line and it is the expected one, every preceding statement carries a success tag, and arms1-5 holds three, one per refusal arm. Nothing was masked. THIS ROW DOES NOT CLOSE ON THIS. The apply decision is db-terra-cc's and has not been made. A dry-run transcript is recoverable by rerunning it and an applied migration's is not, which is why the evidence lands before any apply rather than alongside one.
• wi-cli-venus note · 6w ago
  CORRECTION TO 880858e's COMMIT MESSAGE AND TO MY PREVIOUS EVENT ON THIS ROW. I wrote that arm 6 shows "two rows identical on the predicate, one refused and one preserved, proven by the same statement". THAT SENTENCE IS WRONG and I published it. audit-terra-ca found it by reading the arm SOURCE with the transcripts and db-terra-ca's messages deliberately withheld; I verified it myself at the draft rather than accepting the report. WHAT IS ACTUALLY TRUE. terra_51 defines four constraint triggers: on terraPracticas it is AFTER INSERT ONLY (:172-176), and the three on terraPracticasComplicaciones cover INSERT, UPDATE and DELETE, each gated on fase = intra (:178-196). Arm 6a's statement is an UPDATE of public."terraPracticas" (arm6.sql:266-268). NO TRIGGER WATCHES THAT STATEMENT. Its success was structurally guaranteed by the trigger definition before the arm ran, so the legacy row was never subjected to a check that it then passed. SO THE TWO HALVES OF ARM 6 ARE NOT ONE COMPARISON. 6b's refusal arrives through the parent INSERT trigger; 6a's preservation arrives through a statement no trigger is attached to. They exercise different paths, and the census printing both parents at live_intra_answers = 0 does not make them one predicate - it makes them two rows that happen to share a column value. My sentence claimed a symmetry the arm does not have. THE CONCLUSION SURVIVES AND THE JUSTIFICATION DOES NOT, WHICH IS THE WORSE HALF. terra_51 does not retroactively invalidate legacy zero-answer practicas, and that is still true - it is true BECAUSE the parent trigger is INSERT-only, which is a stronger and cheaper guarantee than a passing arm. What I destroyed by overstating it is the reason anyone would keep checking. AND IT HIDES THE PRESERVATION BOUNDARY NOBODY TESTED. Legacy rows are preserved only while nothing touches their intra complicaciones. A pre-existing zero-answer parent that later receives an intra complicacion INSERT, or has one UPDATEd or DELETEd, DOES reach the child triggers and will be evaluated under the new rule. That is the real edge for existing data and no arm in either file covers it. It is not a defect in terra_51 - it may well be the intended behaviour - but it is an untested consequence being carried by a file whose transcripts read as complete. audit's systemic finding, separate and also accepted: NO ARM ASSERTS ITS OWN OUTCOME IN SQL. ON_ERROR_STOP off around SET CONSTRAINTS ALL IMMEDIATE only PERMITS an error; nothing asserts that a P0001 occurred, nothing checks its SQLSTATE or message, and no arm asserts fixture cardinality, so a resolver CTE returning zero rows can produce an unexpected SUCCESS and the script still exits 0. An echo is not an assertion. The practical consequence is precise: the transcripts in this commit are valid evidence FOR THE RUN THAT PRODUCED THEM, because I read the RAISE line numbers and message text out of them by hand. They are not a self-checking instrument, so a future rerun cannot be trusted green without a human reading it again.
• wi-cli-venus note · 6w ago
  PROVENANCE CORRECTION ON THE "NOTHING IS APPLIED" CLAIM IN 880858e's COMMIT MESSAGE. The claim is TRUE. The evidence I offered for it was not evidence. I wrote that I confirmed it against the live catalog myself. The connection I used was fjnhfjwskixzsilxrkph, an unrelated project belonging to a venus agent lane, which I obtained by grepping ltm.md for a project ref and taking the first hit. Terra is eprpywqwzsvrjeaforei (ltm.md:64). The query succeeded and returned oid null and zero triggers, because that project has no terra_51 objects either - and no project on earth would. RE-RUN AGAINST THE CORRECT PROJECT, and this is now the actual evidence: on eprpywqwzsvrjeaforei, fn_terraRequireIntraComplicacionAnswer returns oid null from pg_proc and pg_trigger holds zero triggers matching IntraComplicacion. Nothing is applied. Same conclusion, obtained honestly this time. WHY THIS IS RECORDED RATHER THAN LET GO. The conclusion was right, so nothing downstream is wrong and no reader would ever have found this by checking the claim - the claim holds. What was wrong is the sentence justifying it, and that sentence is now in an immutable commit message where the next person will read it as a verified fact and cite it. An absence query against ANY database returns the absence, which is exactly why "I checked and it is not there" is the claim least able to detect that it was pointed at the wrong thing. A negative result carries no signal about its own address.
• wi-cli-venus note · 6w ago
  ARM 7 IS PUSHED AS 7a3fa2f AND THERE IS A DUPLICATE COMMIT BEHIND IT, 01deefd, WHICH IS MINE AND IS WASTE. I piped gitpush.sh through grep to pull the lines I expected; the pre-push hook runs the test suite, the TAP output flooded the filter, and no push confirmation came back. I read that absence as a failed push and re-ran the command. It had already succeeded. The second run found nothing left but the version stamp the first had bumped, so 01deefd is one file - package.json - carrying a byte-identical copy of arm 7's 3000-character commit message while containing none of its artifacts. Anyone reading git log will see the same message twice against different contents. Recorded rather than left to be discovered, and also on TERRA-163, whose rule this is: never filter the output of a mutating command, because the filter destroys the report of whether the write happened and the natural response to a missing confirmation is to run the write again. WHAT ARM 7 ESTABLISHES, verified at source before either push. A parent created BEFORE the DDL with zero intra answers ACCEPTS a valid intra child INSERT afterwards and its forced SET CONSTRAINTS IMMEDIATE succeeds; archiving that sole answer then REFUSES with P0001. So a legacy practica may sit at zero indefinitely but CANNOT RETURN TO ZERO once it gains an answer. That is a real consequence for existing data, it is not visible anywhere in arms 1 to 6, and it exists as a question only because arm 6's claim had to be retracted. IT IS ALSO THE FIRST ARM THAT FAILS WHEN IT PASSES FOR THE WRONG REASON. Nine abort conditions, not echoes: one pre-DDL fixture parent (:39), zero pre-DDL live intra answers (:46), fixture surviving the DDL unmultiplied (:270), an available actual complication value (:280), exactly one inserted live answer (:292), the archive UPDATE touching a row (:315), and at :318 the one that closes audit-terra-ca's systemic gap - expected child-trigger P0001 but forced check SUCCEEDED. It then catches the exception and compares RETURNED_SQLSTATE (:324) and the exact dynamic MESSAGE_TEXT (:327), so a P0001 from a different deferred constraint fails the arm instead of satisfying it. Four-trigger count at :231 and the ACL pair at :242 and :249. Transcript holds zero ERROR lines and one NOTICE recording the verified refusal. db-terra-ca disclosed that a first attempt failed on min(uuid) before the test body and was corrected, so the retained transcript is the successful self-checking run and not a rerun of an already-passing script. Arms 1 to 6 were NOT rerun and must not be trusted green on a future rerun without a human reading the RAISE line numbers out of them by hand. STILL NOT APPLIED, verified on eprpywqwzsvrjeaforei: oid null, zero matching triggers. The apply decision is db-terra-cc's and is not made.
• wi-cli-venus note · 6w ago
  THE WHOLE MATRIX IS SELF-CHECKING NOW, PUSHED AS ee74f01, and it went out on ONE gitpush invocation with the output tee'd to a file and read whole - the corrected form of the mistake that produced the duplicate commit an hour ago. WHAT CHANGED AND WHY IT IS IN NEW FILES. audit-terra-ca's systemic finding was that no arm asserted its own outcome: ON_ERROR_STOP off around SET CONSTRAINTS ALL IMMEDIATE merely PERMITS an error, nothing asserted a P0001 occurred, nothing checked SQLSTATE or message, and no arm asserted fixture cardinality - so a resolver CTE returning zero rows yields an unexpected SUCCESS and the script exits 0. The originals are NOT overwritten. They remain valid evidence for the runs that produced them, because I read the RAISE line numbers and message text out of those transcripts by hand; what they were never was a self-checking instrument, and replacing them would have destroyed the only record of the runs I actually verified. THE REFUSAL ARMS DISCRIMINATE MECHANICALLY NOW. Arms 1, 4, 5 and 6b force the deferred check and then RAISE 'expected P0001 but check succeeded' on the very next line, so an unexpected success is a FAILURE rather than a green. Each then catches WHEN SQLSTATE 'P0001' and compares, via GET STACKED DIAGNOSTICS, both RETURNED_SQLSTATE and the exact dynamic MESSAGE_TEXT rebuilt with that arm's own fixture id. A P0001 raised by any other deferred constraint now fails the arm instead of satisfying it, which was precisely the alternative audit said remained open. THE SUCCESS ARMS ESTABLISH REACHABILITY BY CONSTRUCTION rather than by absence of an error. Arms 2 and 3a assert exactly one live intra answer and arm 3b exactly two, counted from terraPracticasComplicaciones after the INSERT, and arm 3 aborts unless resolveScopedVocabulary yields two distinct non-sinComplicaciones values. The child triggers are AFTER INSERT FOR EACH ROW WHEN fase = intra, so a counted row IS a queued event and the forced SET CONSTRAINTS is no longer running against a possibly-empty queue - the exact defect that failed arm 6 on its first run. Arms 2 and 3 carry no exception handler at all, so anything unexpected propagates and aborts. ARM 6a IS DELIBERATELY NOT MADE TO LOOK LIKE THE OTHERS, and refusing to fake it is the point. Its UPDATE targets terraPracticas, whose only trigger is AFTER INSERT, so no check can fire; an assertion implying one did would have been worse than the gap it filled. It instead asserts the trigger's EVENT SET from the catalog - count from pg_trigger where tgtype carries the INSERT bit and not the UPDATE bit must be exactly 1, at arm6-selfchecking.sql:276-280. That is the honest form: preservation here is a property of the trigger DEFINITION, not of a check that ran and passed. It also permanently corrects what I published in 880858e, where I called 6a and 6b one comparison over identical rows. BOTH TRANSCRIPTS HOLD ZERO ERROR LINES and end in ROLLBACK, with five NOTICE lines carrying the verified refusal messages and reachable-success confirmations. db-terra-ca disclosed that a first arms1-5 attempt failed on a positional child fixture NULL id and was corrected, so the retained transcripts are the successful self-checking runs rather than reruns of already-passing scripts - the second time in a row they have volunteered a failed attempt unprompted. STILL NOT APPLIED, re-checked against eprpywqwzsvrjeaforei AFTER the push at 2026-08-31 20:37:01 UTC: oid null, zero triggers matching IntraComplicacion. The apply decision is db-terra-cc's and is not made. What this row now has that it lacked this morning is a matrix that fails when it passes for the wrong reason, plus one behavioural finding for existing data - a legacy practica may sit at zero intra answers indefinitely but cannot return to zero once it gains one.
• wi-cli-venus blocked · 6w ago
  MEASURED 2026-09-01, re-check before accepting. The draft EXISTS and is substantive: db/migrations/draft/terra_51_practica_intra_complicacion_required.sql defines fn_terraRequireIntraComplicacionAnswer with a DEFERRABLE INITIALLY DEFERRED parent arm plus insert, update and delete arms on terraPracticasComplicaciones, so a later archive cannot leave a live practica empty, and it deliberately preserves existing zero-answer practicas rather than invalidating legacy rows on an unrelated UPDATE. This row is NOT blocked on design. This blockedReason was EMPTY until now, which is its own defect - a row shut with no stated condition cannot be unblocked by anyone and does not expire. TWO CONDITIONS REMAIN. (1) No dry-run transcript: agents/db-terra/evidence/ holds nothing matching terra_51, so there is no rollback evidence and nothing to audit. (2) No Class-A audit PASS is obtainable - audit-terra-ca is at 14 percent context, measured today. NARROWED: NO db-enamel-cc GO IS REQUIRED. Every quoted identifier is terra-owned - terraPracticas, terraPracticasComplicaciones, fase, value, deletedAt, practicaId and the terra-prefixed function and four triggers. Nothing shared is touched and the gate boundary is shared-object TOUCH, not name prefix. BOUND: measured by extracting quoted identifiers from the draft text, not by executing it, so an unquoted or dynamically built reference would not show up. ALSO STILL TRUE, and it is why this row is priority 1 rather than 2: app-side enforcement already shipped ahead of the DB rule, so the invariant currently holds only for callers that go through the app.
• wi-cli-venus note · 6w ago
  El transcripto sigue sin existir. Tres ciclos, unos 25 minutos, contexto de db-terra-ca plano en 36% todo el tiempo, y lo que llego fueron 586 bytes de andamiaje: un .result.txt que dice NOT EXECUTED y un .sql con BEGIN, un comentario y ROLLBACK. Ordene borrar ambos. Un placeholder honesto en la ruta canonica de evidencia se lee como evidencia, porque el lector en riesgo es el que verifica que la ruta EXISTE y nunca abre el archivo; el descargo de la linea 1 solo protege a quien ya lo abrio. Y el .sql es ejecutable y pasaria: una transaccion vacia no es un dry run que falla, es uno VERDE sobre corpus cero. La ausencia era el estado correcto y legible - el row esta blocked con su condicion escrita y un directorio de evidencia vacio coincide con eso exactamente. Pregunta abierta a db-terra-ca, y es de capacidad y no de alcance: si puede ejecutar SQL contra la base de terra. Contexto plano es la senal de que no se ejecuto nada, porque ejecutar quema tokens haga lo que haga. Si la credencial es de solo lectura o la herramienta lo limita a una sentencia, eso cambia quien hace este trabajo.
• wi-cli-venus progress · 6w ago
  Arm 1 de 3 ejecutada y en disco, verificada leyendo el archivo y no el reporte: agents/db-terra/evidence/2026-09-01-terra_51-dryrun.result.txt, 784 bytes, con ATTEMPTED ARM COUNT 1 of 3 en la cabecera para que un archivo corto sea evidentemente incompleto. PASS. Es la arm que discrimina: el INSERT no levanto y SET CONSTRAINTS ALL IMMEDIATE si, lo cual separa DEFERRABLE INITIALLY DEFERRED de una restriccion comun - una arm que solo mostrara el rechazo habria pasado con cualquiera de las dos. El P0001 trae el uuid sintetico de la practica. FALTA el .sql: solo esta el .result.txt, asi que nadie puede re-ejecutar la arm ni confirmar que la sentencia que levanto es la del borrador. Pedido escrito desde las sentencias ejecutadas y no reconstruido de memoria; si el texto exacto ya no esta disponible, la arm 1 baja a reportada-no-reproducible. Quedan sin ejecutar la mixta sin-complicaciones y la de preservacion legacy.
• wi-cli-venus note · 6w ago
  Arm 1 BAJA a reportada-no-reproducible, y la baja la pidio el propio lane que la produjo. El texto SQL expandido no se persistio antes de la llamada MCP, y db-terra-ca se nego a reconstruirlo de memoria y presentarlo como lo que corrio - que es la respuesta correcta: un transcripto reescrito de memoria es un artefacto DISTINTO del que se ejecuto, y si los dos difieren la diferencia es invisible. Lo que queda en pie: la arm se ejecuto de verdad y el P0001 con el uuid sintetico es real, asi que el comportamiento diferido esta observado. Lo que se pierde: nadie mas puede re-ejecutarla ni confirmar que la sentencia que levanto es la del borrador terra_51, asi que no sirve como evidencia de dry-run reutilizable para un audit. Regla operativa que sale de esto y vale para todo el lane: escribir el .sql ANTES de la llamada, no despues - el texto ejecutado solo existe mientras se lo tiene delante, y una vez hecha la llamada el artefacto reproducible ya no se puede fabricar sin mentir. El .result.txt en disco tiene que decirlo en el propio archivo; el descargo no puede vivir solo en un mensaje del hub, que es exactamente el modo de fallar que este row ya registro con los placeholders.
• wi-cli-venus note · 6w ago
  CONDICION (1) DE ESTE BLOCKER ES FALSA Y LA ESCRIBI YO A LAS 00:40. La retiro citando los archivos, y el error costo unos 90 minutos de trabajo de otro lane rehaciendo evidencia que ya estaba en disco. LO QUE ESCRIBI: "No dry-run transcript: agents/db-terra/evidence/ holds nothing matching terra_51, so there is no rollback evidence and nothing to audit." LO QUE HAY, contado con find sobre el repo entero y no sobre un directorio: DIEZ artefactos terra_51 en db/migrations/dryrun/, en pares .sql + .result.md, pusheados ayer como ee74f01 y 7a3fa2f. arms1-5 (17316 B) y su reescritura self-checking (18705 B), arm6 (11982 B) y su self-checking (13014 B), arm7-legacy-child-touch (12189 B), cada uno con su transcripto al lado. LEI DOS TRANSCRIPTOS ENTEROS ANTES DE RETIRAR NADA, porque un .result.md que existe no es un .result.md que corrio. 2026-08-31-terra_51-arms1-5-selfchecking.result.md abre en BEGIN, cierra en ROLLBACK y trae cinco NOTICE verificados con el numero de linea del RAISE: arm1 el rechazo del parent diferido con uuid, arm2 "verified reachable success", arm3 "verified reachable one/two success", arm4 el rechazo de sinComplicaciones combinado con una complicacion real, arm5 el rechazo por UPDATE del hijo. arm6-selfchecking.result.md trae 6a UPDATE 1 sobre el parent legacy y 6b el P0001 de control de alcanzabilidad en la misma transaccion. O SEA QUE LAS DOS ARMS QUE ANDUVE PERSIGUIENDO TODA LA NOCHE COMO "sin ejecutar" ESTAN EJECUTADAS Y VERIFICADAS DESDE AYER. La mixta sinComplicaciones es arm4; la preservacion legacy es arm6a mas arm7. No faltaban. EL MECANISMO, y es el mismo que este row ya documento a las 20:02 con el nombre en vez de la ruta: busque en UN directorio y reporte la ausencia como si fuera el estado del proyecto. agents/db-terra/evidence/ efectivamente no tenia nada terra_51, y eso es literalmente cierto y completamente enganoso. La convencion de este proyecto tiene DOS lugares para transcriptos - agents/<lane>/evidence/ y db/migrations/dryrun/ - y yo trate uno de los dos como si fuera el canon. Una consulta negativa no lleva ninguna senal sobre su propia direccion, que es exactamente la frase que este row tiene escrita cuatro eventos mas arriba sobre el proyecto Supabase equivocado. Reproduje la clase con la variable cambiada. LO QUE COSTO, dicho porque el costo es la razon por la que esto se registra y no se corrige en silencio: sobre esa frase mande a db-terra-ca a producir un transcripto que ya existia. Salieron 586 bytes de placeholders que tuve que ordenar borrar, despues una arm real pero no reproducible, despues una nota de baja adentro del archivo. Tres ciclos, unos 90 minutos, todo recuperacion de algo que estaba a un find de distancia. Nada de eso fue culpa del lane. QUEDA EN PIE 2026-09-01-terra_51-dryrun.result.txt con su REPRODUCIBILITY DOWNGRADE, y no lo borro: es ejecucion real de la arm diferida y su descargo es correcto. Simplemente es redundante con arms1-5-selfchecking, que si es reproducible. CONDICION QUE SOBREVIVE, unica: no hay PASS de audit Clase A. audit-terra-ca esta al 14% de contexto, medido hoy. Ese sigue siendo el blocker real y es el unico. REGLA OPERATIVA: antes de afirmar que un artefacto no existe, buscar por NOMBRE sobre el repo entero, nunca listar el directorio donde uno espera que este. La ausencia en la ruta esperada y la ausencia en el proyecto son dos hechos distintos y el segundo es el unico que justifica mandar a alguien a fabricarlo.
• wi-cli-venus blocked · 6w ago
  MEASURED 2026-09-01 01:52, re-check before accepting. ONE CONDITION, not two - the previous version of this field asserted a second one that was FALSE and I wrote it; see the note event of the same timestamp. The draft EXISTS and is substantive: db/migrations/draft/terra_51_practica_intra_complicacion_required.sql defines fn_terraRequireIntraComplicacionAnswer with a DEFERRABLE INITIALLY DEFERRED parent arm plus insert, update and delete arms on terraPracticasComplicaciones, and it deliberately preserves existing zero-answer practicas. This row is NOT blocked on design and is NOT blocked on dry-run evidence. DRY-RUN EVIDENCE EXISTS AND IS COMPLETE, counted with find over the whole repo rather than by listing one directory: ten paired artifacts under db/migrations/dryrun/, pushed as ee74f01 and 7a3fa2f - arms1-5 and its self-checking rewrite, arm6 and its self-checking rewrite, arm7-legacy-child-touch, each .sql beside its .result.md. I read two transcripts end to end: arms1-5-selfchecking opens BEGIN, closes ROLLBACK, and carries five verified NOTICE lines (arm1 deferred parent refusal, arm2 reachable success, arm3 reachable one/two success, arm4 sinComplicaciones contradiction refusal, arm5 child-UPDATE refusal); arm6-selfchecking carries 6a UPDATE 1 on the legacy parent and 6b's same-transaction reachability P0001. The mixed-sinComplicaciones and legacy-preservation paths I was chasing as unexecuted are arm4 and arm6a/arm7 and have been executed since 2026-08-31. THE ONE REMAINING CONDITION: no Class-A audit PASS is obtainable. audit-terra-ca measured at 14 percent context on 2026-09-01. This is the whole blocker. It clears when that lane starts fresh and issues a PASS over the pushed transcripts - and note TERRA-133, which bounds what such a PASS can mean while the audit lane holds no database connection. NARROWED AND STILL TRUE: NO db-enamel-cc GO IS REQUIRED. Every quoted identifier is terra-owned - terraPracticas, terraPracticasComplicaciones, fase, value, deletedAt, practicaId and the terra-prefixed function and four triggers. The gate boundary is shared-object TOUCH, not name prefix. BOUND: measured by extracting quoted identifiers from the draft text, not by executing it, so an unquoted or dynamically built reference would not show up. ALSO STILL TRUE, and why this is priority 1 rather than 2: app-side enforcement shipped ahead of the DB rule, so the invariant currently holds only for callers that go through the app.
• wi-cli-venus verified · 6w ago
  LOS TRANSCRIPTOS SON REPRODUCIBLES POR UN SEGUNDO LANE, Y POR UN SEGUNDO TRANSPORTE, QUE ES MAS FUERTE QUE LO QUE PEDI. db02-terra-cc re-ejecuto los dos archivos self-checking y dio 5/5 y 2/2 PASS. Lei el artefacto en disco, agents/db02-terra/evidence/2026-09-01-terra_51-independent-rerun.result.txt, 4894 bytes, en vez de aceptar el reporte del hub. INDEPENDENCIA REAL Y NO NOMINAL. Se lo asigne con la instruccion explicita de NO leer los eventos de este row ni preguntarle nada a db-terra-ca antes de correr, porque dos lanes que coinciden despues de que uno leyo la respuesta del otro son una sola medicion con dos nombres. El archivo declara esa restriccion cumplida en su propio pie. Los uuid difieren por corrida, como corresponde a gen_random_uuid(), y el texto de cada NOTICE es identico. Y APARECIO UNA SEGUNDA INDEPENDENCIA QUE YO NO HABIA PEDIDO NI NOTADO: EL CANAL DE EJECUCION ES DISTINTO. Los transcriptos retenidos traen prefijos psql:db/migrations/dryrun/<archivo>:<linea>: NOTICE:, o sea que salieron de psql con el archivo por entrada, y cada NOTICE queda atado al numero de linea de su RAISE. db02 corrio por MCP execute_sql, que NO devuelve la salida del canal de notices en absoluto, asi que tuvo que espejar cada RAISE NOTICE a una tabla TEMP y leerla de vuelta antes del rollback. Dos clientes distintos, dos formas distintas de recuperar el mismo texto, mismo resultado. Eso descarta de paso que el verde original fuera un artefacto del cliente. LO QUE NO TOCO, y es la condicion para que el rerun valga: ni una linea de assertion, fixture o control de flujo. Todos los RAISE EXCEPTION, los GET STACKED DIAGNOSTICS y las comparaciones de SQLSTATE y MESSAGE_TEXT corrieron como estan escritos. El argumento de que eso alcanza es correcto y conviene dejarlo escrito: como cualquier comparacion fallida levanta y hace errar la llamada entera, terminar sin excepcion no capturada YA prueba que toda assertion interna paso - el texto de los NOTICE es color, no la evidencia. UN HALLAZGO PROPIO DEL RERUN, chico pero real: arm 6a NUNCA ASERTA EL ROW COUNT. El "UPDATE 1" que se lee en el transcripto retenido es salida del cliente psql, no una assertion del archivo. db02 le agrego GET DIAGNOSTICS ROW_COUNT para capturarlo como dato y reporto n=1. Coincide con lo que este row ya sabia por otra via desde las 20:21 - la preservacion en 6a es una propiedad de la DEFINICION del trigger, que es AFTER INSERT ONLY, no de un chequeo que corrio y paso - y ahora hay dos lanes que llegaron a esa misma conclusion por caminos distintos. CERRE YO LA UNICA SALVEDAD QUE db02 NOMBRO. Dijo no haber verificado si la poblacion de terraPracticas de la que clonan las fixtures cambio entre los transcriptos retenidos y su corrida, lo cual dejaria a las dos corridas internamente consistentes pero clonando filas distintas. Medido ahora: 6 filas vivas, 6 totales, ninguna con deletedAt, y el createdAt mas nuevo es 2026-08-30 14:21:40 UTC - anterior tanto a los transcriptos retenidos (2026-08-31 20:00 a 20:34) como al rerun (2026-09-01 01:52). La poblacion no se movio entre las dos corridas, asi que el ORDER BY id LIMIT 1 selecciono la misma fila real las dos veces. Y DE PASO QUEDA CONTADA LA POBLACION QUE HAY QUE CONTAR ANTES DE APLICAR, que es exactamente lo que le exigi a TERRA-131 no suponer: las 6 practicas vivas YA SATISFACEN el invariante. Cinco tienen una respuesta intra viva y una tiene dos; NINGUNA tiene cero. O sea que la clausula de preservacion de legacy protege hoy un conjunto VACIO, aplicar terra_51 no invalidaria ninguna fila existente y no hace falta ningun heal de datos previo. Sigue siendo correcto que la clausula exista - protege contra filas que nadie garantiza que no aparezcan antes del apply - pero su poblacion medida es cero y eso hay que re-medirlo inmediatamente antes de aplicar, no citar desde aca. LO QUE ESTO NO ES: no es el PASS de audit Clase A. db02 lo dice en su propio archivo y tiene razon. Establece reproducibilidad por quien no los produjo, que es estrictamente menos. El blocker de este row no se mueve.
• wi-cli-venus note · 6w ago
  MECANISMO DEL BLOCKER, MEDIDO Y NO SUPUESTO: audit-terra-ca NO PUEDE LIMPIAR SU PROPIO CONTEXTO. Le pedi persistir lo no filado y despues resetear. Contesto 'voy a resetear antes de empezar'; cuatro minutos despues el pane seguia en Ready con Context 14% left. Preguntado derecho si PUEDE hacerlo, contesto que no: /clear es un comando de TUI que escribe un humano, y el clear de shell que habia corrido solo limpio la PANTALLA, no el contexto del modelo. Es un limite de capacidad, no una accion diferida. LA TRAMPA ES EL CLEAR DE PANTALLA: deja un pane que parece recien reseteado - scrollback vacio, prompt arriba - con el footer todavia en 14%. Quien lee la FORMA del pane en vez del NUMERO concluye que el reset ocurrio. Se lee Context N% left, nunca el vacio del pane. CONSECUENCIA PARA ESTE ROW: la condicion 'no hay PASS de audit Clase A obtenible porque el lane esta al 14%' no se resuelve sola ni la puede resolver el lane. Necesita una tecla humana en ese pane o un relanzamiento, y eso pertenece a quien es dueno del pane, no a un agente par. NO FILE eq TODAVIA, a proposito: en vez de escalar una suposicion le mande la version MAS ANGOSTA util del audit - un solo archivo, el borrador terra_51, mas un grep de escritores, con la historia del row y los transcriptos EXPLICITAMENTE prohibidos por ser lo que le comeria el contexto restante en background que no necesita. O entrega, o dice BLOCKED con lo que alcanzo. Eso convierte 'alcanza el 14%?' de una conjetura en una medicion, y no cuesta nada si falla. Esta corriendolo ahora. Si vuelve BLOCKED, recien ahi la tecla humana es un pedido fundado y va a eq.
• wi-cli-venus audit-finding · 6w ago
  AUDIT CLASE A ENTREGADO, Y EL LANE LO HIZO AL 14% DE CONTEXTO - o sea que la tecla humana que estaba por pedir NO HACIA FALTA. Veredicto: PASS condicional sobre el diseno de alcance-hacia-adelante, BLOCK sobre la REDACCION del invariante. El BLOCK es correcto y lo verifique en la fuente antes de aceptarlo. QUE PASA (escrituras hacia adelante). Los cuatro constraint triggers son DEFERRABLE INITIALLY DEFERRED. El INSERT del parent encola el arm del parent, asi que la transaccion parent-mas-hijos-intra de la app y de createTerraPractica queda chequeada en el commit. Los triggers de hijo cubren INSERT, UPDATE y DELETE de toda fila cuyo fase viejo O nuevo sea intra - incluye el archivado blando y la reasignacion de practicaId, y la funcion compara OLD y NEW practicaId. Las escrituras postop de la app son solo fase=post, asi que no pueden suprimir el chequeo intra. El grep de escritores no encontro ningun escritor de aplicacion que esquive estos triggers. EL BLOCK, Y ES SOBRE LO QUE EL ROW AFIRMA, NO SOBRE EL DDL. Las lineas 3-8 y 83-85 del borrador omiten A PROPOSITO cualquier trigger de UPDATE sobre el parent, para preservar las practicas legacy con cero respuestas. Consecuencia: ESTO NO ES UN INVARIANTE UNIVERSAL. Un UPDATE del parent no alcanza ninguno de los cuatro arms. Verificado por mi en el borrador: linea 173, AFTER INSERT ON public."terraPracticas", y nada mas sobre esa tabla; los tres de INSERT, UPDATE y DELETE (:179, :186, :193) son todos sobre terraPracticasComplicaciones. EL CAMINO CONCRETO QUE QUEDA ABIERTO: un escritor externo, administrativo o futuro que RESTAURE a viva una practica con cero respuestas que estaba borrada en blando lo hace sin chequeo alguno. Y las legacy vivas con cero respuestas quedan permitidas explicitamente. POBLACION DE ESA BRECHA, MEDIDA AHORA Y NO SUPUESTA: CERO. terraPracticas tiene 6 filas, 6 vivas, NINGUNA borrada en blando, asi que hoy no hay ni una fila que restaurar. Y grepeando src/ no existe ninguna superficie de restauracion para practicas - el unico "reactivar" del codigo es cirugia-retire-core.ts:89 y es de cirugias, otra tabla. Osea que la brecha es real en el DDL y hoy no es alcanzable desde la aplicacion. POR QUE NO SE ARREGLA CON UN TRIGGER Y LA CORRECCION ES DE PALABRAS. Agregar un arm de UPDATE sobre el parent es exactamente lo que el diseno evita a proposito: haria que un UPDATE cualquiera y no relacionado sobre una practica legacy con cero respuestas la invalide, que es el modo de falla que este row viene esquivando desde el principio. El diseno esta bien. Lo que esta mal es como se lo describe. REDACCION QUE MANDO, textual, y reemplaza cualquier frase que hable de invariante global: "los INSERT de practica nueva y los cambios de hijos intra no pueden commitear una practica viva en violacion", con la excepcion legacy dicha explicitamente. NO se lo puede llamar un invariante de toda practica viva. Esa diferencia importa porque la frase sobrevive al contexto: dentro de un ano alguien va a leer "invariante" y concluir que la base garantiza algo que no garantiza, y esa lectura es la que se cita cuando se decide no volver a chequear. BOUND DEL PROPIO AUDIT, declarado por el lane y correcto: sin conexion a base y con el borrador NO APLICADO, esto es adecuacion DE FUENTE unicamente. No hay prueba de estado aplicado, ni de runtime, ni de ejecucion concurrente. Menciono ademas un guard BEFORE TRUNCATE del terra_13 aplicado para la tabla hija, y dijo explicitamente que NO PUEDE PROBAR QUE ESTE VIVO - esa honestidad es la mitad util del reporte y es TERRA-133 otra vez. LO QUE ESTO DESBLOQUEA: la condicion (2) del blocker, la unica que quedaba en pie, esta cumplida - hay PASS de Clase A sobre el diseno hacia adelante. Queda una correccion de redaccion antes de aplicar, que es de db-terra-ca. No hay ninguna razon nueva para que el row siga bloqueado despues de eso.
• wi-cli-venus verified · 6w ago
  CORRECCION DE REDACCION APLICADA POR db-terra-ca Y VERIFICADA POR MI EN LA FUENTE, no aceptada por reporte. El BLOCK del audit queda levantado. QUE DICE AHORA EL BORRADOR. Lineas 3-7: "INSERTs of new practicas and intra-child changes cannot commit a live practica in violation", con la excepcion legacy escrita en la misma frase y diciendo POR QUE existe - no hay trigger de UPDATE sobre el parent que evalue un update no relacionado de ese estado legacy. Lineas 9-14: la brecha medida, con fecha 2026-09-01, 6 filas, 6 vivas, 0 borradas en blando, sin superficie de restauracion en src/ y con la unica coincidencia de "reactivar" nombrada como de otra tabla (cirugia-retire-core.ts:89), cerrando con "This is a measured gap, not not applicable". Lineas 90-92, adentro de la funcion: el trigger del parent esta atado a INSERT solamente y no es una condicion global sobre toda practica viva. VERIFIQUE QUE NO SE TOCO SQL EJECUTABLE, que era la mitad riesgosa del pedido. Los cuatro triggers siguen siendo los mismos cuatro: AFTER INSERT sobre terraPracticas (una sola vez), y AFTER INSERT, AFTER UPDATE y AFTER DELETE sobre terraPracticasComplicaciones. Corrieron de :173 a :180 y de :179/:186/:193 a :186/:193/:200, que es exactamente el corrimiento de siete lineas que agrega el comentario nuevo - o sea que el desplazamiento CONFIRMA que el cambio fue solo prosa en la cabecera. SHA-256 reportada y recalculada por mi, iguales: dae4aa6334df1469a44f552d1b98fdf40f38ecec02b7c4c766babba2273e00cd. DOS USOS DE "invariant" SOBREVIVEN Y LOS REVISE UNO POR UNO EN VEZ DE GREPEAR Y DARLO POR LIMPIO. Linea 30 dice que el trigger de vocabulario existente ni colisiona ni cubre "this invariant", y linea 34 que el bypass de heal-delete no saltea "this deferred invariant". Los dos son referencias A LA REGLA que estos triggers imponen, ya delimitada por la cabecera, no afirmaciones de alcance global. Se quedan. La linea 27 ademas ya decia "forward guarantee rather than a migration of existing state", que es la formulacion correcta y estaba desde antes. DESBLOQUEO. Las dos condiciones del blocker estan cumplidas y verificadas: (1) evidencia de rollback existia todo el tiempo, diez artefactos en db/migrations/dryrun/ - mi afirmacion de que no habia era falsa y ya esta corregida en este row; (2) PASS de Clase A sobre el diseno hacia adelante, con el BLOCK sobre redaccion ahora resuelto. Lo que queda es aplicar, que no es un blocker sino la autoridad de aplicacion de db-terra-ca mas el GO de Elazar. Nada mas espera a nadie.
• wi-cli-venus unblocked · 6w ago
  cleared: MEASURED 2026-09-01 01:52, re-check before accepting. ONE CONDITION, not two - the previous version of this field asserted a second one that was FALSE and I wrote it; see the note event of the same timestamp. The draft EXISTS and is substantive: db/migrations/draft/terra_51_practica_intra_complicacion_required.sql defines fn_terraRequireIntraComplicacionAnswer with a DEFERRABLE INITIALLY DEFERRED parent arm plus insert, update and delete arms on terraPracticasComplicaciones, and it deliberately preserves existing zero-answer practicas. This row is NOT blocked on design and is NOT blocked on dry-run evidence. DRY-RUN EVIDENCE EXISTS AND IS COMPLETE, counted with find over the whole repo rather than by listing one directory: ten paired artifacts under db/migrations/dryrun/, pushed as ee74f01 and 7a3fa2f - arms1-5 and its self-checking rewrite, arm6 and its self-checking rewrite, arm7-legacy-child-touch, each .sql beside its .result.md. I read two transcripts end to end: arms1-5-selfchecking opens BEGIN, closes ROLLBACK, and carries five verified NOTICE lines (arm1 deferred parent refusal, arm2 reachable success, arm3 reachable one/two success, arm4 sinComplicaciones contradiction refusal, arm5 child-UPDATE refusal); arm6-selfchecking carries 6a UPDATE 1 on the legacy parent and 6b's same-transaction reachability P0001. The mixed-sinComplicaciones and legacy-preservation paths I was chasing as unexecuted are arm4 and arm6a/arm7 and have been executed since 2026-08-31. THE ONE REMAINING CONDITION: no Class-A audit PASS is obtainable. audit-terra-ca measured at 14 percent context on 2026-09-01. This is the whole blocker. It clears when that lane starts fresh and issues a PASS over the pushed transcripts - and note TERRA-133, which bounds what such a PASS can mean while the audit lane holds no database connection. NARROWED AND STILL TRUE: NO db-enamel-cc GO IS REQUIRED. Every quoted identifier is terra-owned - terraPracticas, terraPracticasComplicaciones, fase, value, deletedAt, practicaId and the terra-prefixed function and four triggers. The gate boundary is shared-object TOUCH, not name prefix. BOUND: measured by extracting quoted identifiers from the draft text, not by executing it, so an unquoted or dynamically built reference would not show up. ALSO STILL TRUE, and why this is priority 1 rather than 2: app-side enforcement shipped ahead of the DB rule, so the invariant currently holds only for callers that go through the app.
• wi-cli-venus note · 6w ago
  LA UNICA CONDICION QUE QUEDA ESTABA DECLARADA COMO INALCANZABLE Y ESO NUNCA SE MIDIO. El campo de blocker dice que no hay PASS Clase A obtenible porque audit-terra-ca estaba en 14 por ciento de contexto. Eso es una inferencia sobre capacidad sacada de un porcentaje, no una medicion: nadie le pidio el veredicto y recibio una negativa. Un blocker que dice "no se puede" sin haberlo intentado es indistinguible de un blocker que nadie toco. QUE HICE EN VEZ DE ESCALARLO. Medi el estado del carril: audit-terra-ca esta en 16 por ciento y Ready, no colgado. Le mande el pedido acotado a esto y solo esto - veredicto Clase A sobre el draft de terra_51 y sus dos transcripts self-checking, PASS o BLOCK, con motivo pegado a una linea concreta si es BLOCK. Le dije explicitamente que si no le alcanza el contexto lo diga y no empiece, porque un PASS parcial es peor que ninguno, y que hoy db-terra-ca rechazo una tarea por exactamente esa razon y fue la respuesta correcta. Y LE PROHIBI LEER LOS EVENTOS DE ESTA FILA ANTES DE EMITIR EL VEREDICTO. Este row y el de TERRA-113 contienen mis conclusiones y las de db-terra-ca escritas en detalle. Un auditor que las lee primero no emite un veredicto independiente, emite mi lectura con otra firma. Puede contrastar despues de haber escrito el suyo. LO QUE NO CAMBIA CON ESTO: el re-run independiente de db02-terra-cc, 7/7 sobre los dos archivos completos, NO es el PASS Clase A y el propio transcript lo dice con esas palabras. Es reproducibilidad por un carril que no los produjo. Ya esta pusheado y citable en agents/db02-terra/evidence/2026-09-01-terra_51-independent-rerun.result.txt, que hasta hoy existia solo en el disco de un host - o sea que existia y no se podia citar, que para una fila bloqueada por falta de evidencia auditable es lo mismo que no existir. TAMBIEN SIGUE EN PIE, y es el limite que le pase al auditor junto con el resto: que no haga falta GO de db-enamel-cc se midio extrayendo identificadores entre comillas del texto del draft, no ejecutandolo, asi que una referencia sin comillas o construida dinamicamente no habria aparecido en esa medicion.
• wi-cli-venus verified · 6w ago
  PASS CLASE A EMITIDO POR audit-terra-ca (tag audit-terra-ca-mti6nhtsoawa). El blocker que decia que no habia PASS obtenible se despeja, y lo que lo despejo fue pedirlo: el carril estaba en 16 por ciento y Ready, no colgado, y contesto en menos de un minuto. La afirmacion "no es obtenible" nunca se habia medido - salia de un porcentaje de contexto. UNA CONDICION DECLARADA IMPOSIBLE SIN HABERLA INTENTADO ES INDISTINGUIBLE DE UNA QUE NADIE TOCO. EL VEREDICTO SE EMITIO A CIEGAS DE ESTE ROW, a proposito: le pedi que no leyera los eventos de TERRA-136 ni de TERRA-113 antes de escribirlo, porque los dos contienen mis conclusiones y las de db-terra-ca redactadas en detalle y un auditor que las lee primero firma mi lectura en vez de la suya. Confirmo en su respuesta que no los leyo. NO LE CREI EL VEREDICTO: VERIFIQUE LAS CITAS CONTRA EL DRAFT. Las cuatro que da son exactas. Lineas 179-204: cuatro CONSTRAINT TRIGGER DEFERRABLE INITIALLY DEFERRED - padre AFTER INSERT en terraPracticas, e hijo AFTER INSERT / UPDATE / DELETE en terraPracticasComplicaciones, los tres con WHEN sobre fase='intra' (el de UPDATE cubre las dos puntas, OLD o NEW, o sea que una reasignacion de fase entra por cualquier lado). El padre es INSERT y solo INSERT, que es exactamente lo que sostiene la preservacion historica, y el comentario de la funcion en la linea 90 lo dice con esas palabras en vez de dejarlo implicito. Lineas 9-14: la brecha medida esta escrita en el draft por el propio autor y no la encontro el auditor - terraPracticas tiene 6 filas, 6 vivas y 0 borradas logicamente, src/ no tiene superficie de restauracion, y un escritor externo o administrativo que resucite una practica de cero respuestas no pasa por ningun check de este draft. Esta declarada como brecha medida, no como "no aplica", que es la unica forma honesta de dejarla. QUE COMPRUEBA Y QUE NO, en las palabras del propio veredicto: es un PASS acotado a fuente y ensayo. NO es prueba en vivo ni aplicada, NO es confirmacion de gate de objeto compartido, y NO es autorizacion para aplicar. El auditor lo delimito solo; no se lo tuve que pedir. TAMPOCO REEMPLAZA NI ES REEMPLAZADO POR el re-run independiente de db02-terra-cc (7/7 sobre los dos archivos completos), que ya esta pusheado y citable. Son dos cosas distintas: db02 mostro que los transcripts son reproducibles por un carril que no los produjo; audit-terra-ca juzgo el diseño. Ninguno de los dos es el otro y los dos hacen falta. LO QUE QUEDA, y no es un blocker sino autoridad: aplicar. Eso es de db-terra-ca mas el GO de Elazar, que ya esta pedido. Nada mas espera a nadie. UNA OBSERVACION MIA QUE EL VEREDICTO NO HACE Y QUE NO ES DEFECTO: la linea 177 hace GRANT EXECUTE solo a service_role, mientras terra_55 concede a postgres y service_role. No lo levanto como hallazgo porque postgres es superusuario y saltea el chequeo de EXECUTE, y ademas el permiso sobre una funcion de trigger se verifica al crear el trigger y no en cada disparo. Es una inconsistencia de estilo entre dos drafts, no una diferencia de comportamiento. Lo dejo escrito para que nadie lo "arregle" mas adelante creyendo que encontro algo.
• wi-cli-venus blocked · 6w ago
  MEDIDO 2026-09-01 06:25 UTC. La fila estaba en todo y eso ya no describe la realidad: no queda trabajo que alguien pueda tomar. Lo unico pendiente es APLICAR terra_51, que necesita la autoridad de apply de db-terra-ca mas el GO de Elazar, pedido en la eq 72 y todavia abierto. todo dice tomame; blocked dice espera a alguien que no es un agente. Es lo segundo. QUE YA ESTA HECHO Y NO HAY QUE VOLVER A PEDIR, para que nadie lo rehaga: el draft terra_51 existe y es sustantivo; hay diez artefactos de dry-run pareados en db/migrations/dryrun/ pusheados en ee74f01 y 7a3fa2f; hay re-run independiente de db02-terra-cc con 5/5 y 2/2 por un transporte distinto; y hay PASS Clase A de audit-terra-ca acotado a fuente, emitido a ciegas de esta fila a proposito y con sus citas verificadas por mi contra el draft. RE-MEDI LA POBLACION EN VEZ DE CITAR LA MEDICION VIEJA, que es exactamente lo que un evento anterior de esta fila exige hacer antes de aplicar y no citar desde aca. terraPracticas: 6 filas, 6 vivas, createdAt mas nuevo 2026-08-30 14:21:40 UTC, sin movimiento desde la medicion del 2026-09-01 01:54. Y practicas VIVAS sin ninguna respuesta intra viva: CERO. O sea que la clausula de preservacion de legacy sigue protegiendo un conjunto vacio, aplicar no invalidaria ninguna fila existente y no hace falta ningun heal previo. Sigue siendo correcto que la clausula exista - protege contra filas que nadie garantiza que no aparezcan entre hoy y el apply - pero su poblacion medida hoy es cero. POR QUE LO VUELVO A MEDIR Y NO ALCANZA CON HABERLO MEDIDO: una medicion de poblacion es una foto y esta fila espera un GO humano de duracion desconocida. La diferencia entre la medicion vieja y esta no es que la vieja fuera falsa, es que ninguna de las dos autoriza el apply - la que vale es la que se toma inmediatamente antes, y esta anotacion existe para que quien aplique sepa que tiene que sacar la suya y no leer la mia. DESBLOQUEA CON: respuesta a la eq 72. Nada mas espera a ningun agente.
• wi-cli-venus note · 6w ago
  MEDIDO POR db-terra-ca, SELECT solamente, CON DENOMINADOR, 2026-09-01 08:49. Tercera fila de la misma clase medida hoy y la tercera que da cero sobre un corpus minusculo. RESULTADO: sobre SEIS practicas totales, seis vivas y ninguna borrada, hay CERO practicas vivas sin ninguna complicacion intra vigente, y CERO practicas con "sinComplicaciones" conviviendo con una complicacion real. Corpus de complicaciones intra: 7 filas, 7 vivas, cero borradas. EL DENOMINADOR VINO EN EL MISMO MENSAJE Y ESO ES LO QUE HACE QUE EL CERO SE PUEDA CITAR. Lo pedi asi despues de que el cero de TERRA-131 llegara sin poblacion: "cero violaciones" citado solo se lee como "el invariante se sostiene en produccion", cuando lo que se sostiene es que casi nadie escribio todavia. Seis practicas y siete filas de complicaciones no prueban nada sobre un escritor que apenas corrio; prueban que no hay que limpiar nada antes de poner la restriccion. PREDICADOS, nombrados tabla por tabla: practica viva = deletedAt IS NULL, y terraPracticas no tiene isActive. Fila intra vigente = fase='intra' AND deletedAt IS NULL, y esa tabla tampoco tiene isActive. Ausencia = NOT EXISTS de fila intra vigente. Exclusividad rota = mismo practicaId con bool_or(value='sinComplicaciones') Y bool_or(value<>'sinComplicaciones') entre sus intra vigentes. FORMA DEL ARREGLO, contestada y no asumida: NINGUNA de las dos reglas es un CHECK de una sola fila. Las dos miran filas HERMANAS de terraPracticasComplicaciones, y la primera ademas mira la AUSENCIA de hermanas respecto de la practica. Necesitan enforcement cruzado - trigger o constraint trigger. Es la misma respuesta que dio TERRA-131 a la misma pregunta, y por la misma razon: en este esquema las invariantes que importan son entre tablas, no dentro de una fila. NO SE PREPARO MIGRACION, y es deliberado. Hoy hay CUATRO filas de esta clase medidas y ninguna aplicada: terra_55 esperando GO en la eq 78 desde las 04:14, TERRA-131, TERRA-198 y esta. Que las cuatro esten MEDIDAS y ninguna escrita es el estado que quiero: cuando llegue el GO se deciden en orden, en vez de tener cuatro migraciones sin aprobar compitiendo por la misma atencion. Y LO QUE ESTE PATRON EMPIEZA A DECIR, que no es de esta fila sola: cuatro reglas distintas viven hoy unicamente en el codigo de la app, y las cuatro se sostienen porque la app es el unico escritor que existe. Eso no es una propiedad del diseño, es una propiedad del hecho de que terra casi no se uso.
• wi-cli-venus note · 6w ago
  ORDEN DE DISPARO ENTRE terra_50 Y terra_51: DECIDIDO, FUNDAMENTADO Y AHORA ESCRITO EN LOS DOS BORRADORES. 2026-09-01 09:38. Lo escribio db-terra-ca; lo verifique yo contra los archivos antes de darlo por bueno. DE DONDE SALIO: no lo estaba buscando. Pedi un censo de triggers de las seis tablas que tocan las cuatro migraciones medidas, para saber si CHOCAN al aplicarse. Cero colisiones de nombre sobre 29 triggers no internos, y cero cobertura duplicada - ningun trigger vivo impone hoy ni presencia de complicacion intra ni pieza-o-region, y el mas parecido, vocabGuard sobre complicaciones, solo valida que el value resuelva en vocabulario, no cardinalidad ni exclusividad. Pero de paso aparecio algo que ningun borrador comentaba: Postgres corre los triggers de un mismo evento POR ORDEN ALFABETICO DEL NOMBRE, asi que el orden entre los dos constraint triggers nuevos sobre terraPracticas ya estaba decidido - por los nombres, sin que nadie lo decidiera. EL ORDEN MEDIDO: trg_terraPracticas_firstRowMilestone es un AFTER ordinario y corre al statement. Al COMMIT corren los dos constraint triggers diferidos, primero trg_terraPracticas_requireIntraComplicacionAnswer (terra_51) y despues trg_terraPracticas_requireZona (terra_50), porque comparten el prefijo trg_terraPracticas_require y ahi I precede a Z. LA PREGUNTA QUE PEDI QUE CONTESTARA NO ERA CUAL ES EL ORDEN, ERA SI IMPORTA. Le dije explicitamente que si no podia determinarlo sin correr algo, me lo dijera y NO escribiera nada - un comentario que afirma indiferencia sin haberla comprobado es peor que no tener comentario, porque despues nadie lo vuelve a mirar. CONTESTO QUE ES INDIFERENTE, con el argumento: los dos leen el estado final, los dos retornan o hacen RAISE, y NINGUNO ESCRIBE. Invertirlos no puede convertir un rollback en commit ni al reves; si una practica viola los dos invariantes, lo unico que cambia es cual de los dos P0001 aparece primero. NO LO TOME DE PALABRA, PORQUE LA CLAVE DEL ARGUMENTO ES "NINGUNO ESCRIBE" Y ESO SE VERIFICA MIRANDO. Grepee los dos cuerpos por sentencias de escritura: en terra_50 y en terra_51 no hay un solo INSERT, UPDATE ni DELETE dentro de las funciones de trigger - son SELECT count(*), EXISTS y NOT EXISTS, y despues RAISE EXCEPTION o RETURN NULL. El unico INSERT de cualquiera de los dos archivos esta en los preflight y en los bloques de aceptacion, que corren una vez al aplicar y no en el camino del trigger. El argumento se sostiene sobre lo que los archivos realmente dicen. QUE QUEDO ESCRITO: un bloque de comentario identico y fundamentado antes de los CREATE CONSTRAINT TRIGGER de db/migrations/draft/terra_50_practica_zona_required.sql y de terra_51_practica_intra_complicacion_required.sql. Dice la regla de Postgres, el orden resultante con los nombres reales, y - lo unico que de verdad importa - que ese orden es indiferente y POR QUE, que es lo que evita que alguien lo "arregle" renombrando dentro de seis meses. SIN SQL EJECUTABLE TOCADO, sin aplicar y sin pushear: los borradores los pusheo yo. git diff --check pasa. UNA COSA ANOTADA PARA CUANDO YO PUSHEE, que db-terra-ca marco por su cuenta y esta bien que lo haya hecho: terra_51 YA TENIA en el arbol cambios de comentario ajenos a esta edicion. No los toco y no se los atribuye. Cuando pushee este borrador van a viajar en el mismo commit si no los reviso, asi que los miro en el patch antes de mandar en vez de descubrirlos despues.
• wi-cli-venus note · 6w ago
  PUSHEADO a30309f, app v0.31.29. Y ADENTRO VIAJO ALGO QUE NO ERA MIO, cosa que la compuerta me AVISO y yo lei DESPUES de que el commit existiera. Lo escribo entero porque el aviso funciono y el que fallo fui yo. 2026-09-01 09:45. QUE PUSHEE, a proposito: el bloque de comentario del orden de disparo en los dos borradores, db/migrations/draft/terra_50_practica_zona_required.sql y terra_51_practica_intra_complicacion_required.sql. Sin SQL ejecutable tocado, nada aplicado, los dos siguen siendo DRAFT sin aprobar. LO QUE LA COMPUERTA DIJO, textual y antes de commitear: "--only es por ARCHIVO, no por HUNK. Commiteando TODOS los hunks de estos archivos, incluidos los que otra lane haya dejado sin stagear en ellos", y despues listo terra_51 con TRES hunks. db-terra-ca me lo habia avisado por su lado en el mismo mensaje en que entrego el trabajo - dijo que terra_51 ya tenia cambios de comentario ajenos a esta edicion en el arbol, que no los toco y que no se los atribuia. O sea que tuve DOS avisos, uno de una persona y uno de la herramienta, y aun asi el commit salio con un mensaje que no los menciona. CUANTO FUE, medido despues via gh api porque en este carril no corro git a mano: terra_50 +14 -0, terra_51 +29 -8, package.json +1 -1 por el bump de version. Osea que de los 29 agregados y 8 borrados de terra_51, solo 14 son el bloque que yo pedi. El resto es edicion previa de otro. LO QUE VERIFIQUE ANTES DE DARLO POR INOCUO, en vez de aceptar "son comentarios" porque me lo dijeron: baje el patch del commit y filtre las lineas agregadas y borradas que NO son comentario. Queda UNA sola linea y es una linea EN BLANCO. Cero SQL ejecutable cambiado en todo el commit. Asi que el contenido es efectivamente inocuo y la afirmacion de db-terra-ca se sostiene - pero ahora esta medida. LO QUE SI QUEDA MAL Y NO SE ARREGLA SOLO: el mensaje del commit describe UNA edicion y el commit contiene DOS. Dentro de seis meses, el que haga git log sobre terra_51 va a leer un mensaje larguisimo sobre orden de disparo de triggers y va a encontrar hunks que ese mensaje no explica. Los commits son inmutables en la practica, asi que la correccion es esta nota, no un rewrite. LA REGLA QUE ME LLEVO Y QUE ES DISTINTA DE LA QUE YA TENIA: yo ya sabia que --only es por archivo. Lo que no habia internalizado es que el aviso de la compuerta llega en el MISMO stream que 449 tests verdes y 130KB de salida, o sea que llega en el peor momento posible para ser leido. La compuerta no fallo: imprimio exactamente lo que tenia que imprimir. Lo que falta es mirar el estado de los archivos ANTES de invocar el push, no leer el aviso despues. Y cuando otra lane me dice "ese archivo ya tenia cambios ajenos", eso no es un dato de color: es la instruccion de revisar antes, y yo lo trate como una nota al pie.
• wi-cli-venus note · 6w ago
  RE-MEDIDA CONTRA LA BASE VIVA, SIN DRIFT, 2026-09-01 09:52 UTC. Medido por db02-terra-cc y re-corrido por mi contra pg_constraint y pg_trigger - no acepte la descripcion. LA MITAD DE BASE SIGUE VACIA, y lo digo enumerando lo que SI hay para que el cero tenga denominador en vez de ser una afirmacion de ausencia a secas. Sobre terraPracticas, terraPracticasPiezasDentarias y terraPracticasRegionesAnatomicas, el UNICO CHECK que existe en las tres tablas es terraPracticas_syntheticSessionId_check, y su cuerpo no habla de piezas ni de regiones: CHECK ((isSynthetic AND syntheticSessionId IS NOT NULL) OR (NOT isSynthetic AND syntheticSessionId IS NULL)). Nada mas. Los triggers no-internos de esas tablas son los del patron de archivo mas los de numeracion: archive, archiveOnUpdate, archiveSoftDelete, forbidHardDelete, forbidTruncate, requireArchiveCtx, assignPracticaNumber, firstRowMilestone, practicaNumberImmutable, setUpdatedAt. NINGUNO COMPARA EXISTENCIA CRUZADA entre piezas y regiones, que es lo que la invariante necesitaria: la regla es "al menos una de las dos", o sea que ningun trigger que mire UNA SOLA de las dos tablas puede imponerla, y ninguno de estos mira a la otra. CONCLUSION SIN CAMBIO PARA TERRA-131: cero CHECK, cero trigger, cero constraint que imponga pieza-o-region. La regla sigue viviendo solo del lado de la app, y solo en createTerraPractica, que createPractica no llama - o sea que el segundo escritor no encuentra nada. Y LO MISMO PARA TERRA-136, medido aparte sobre terraPracticasComplicaciones: los constraints son el CHECK de fase - fase IN ('intra','post') -, la PK y la FK a terraPracticas. Hay un indice unico parcial sobre (practicaId, fase, value) WHERE deletedAt IS NULL, Y CONVIENE NO CONFUNDIRLO CON LA INVARIANTE: impide cargar DOS VECES EL MISMO value en la misma fase, que no es ni la obligatoriedad de responder ni la exclusividad de "Sin complicaciones". Un indice unico parcial ahi parece que restringe mas de lo que restringe. El unico trigger de contenido es vocabGuard, y db02 leyo el cuerpo de fn_terraComplicacionesVocabGuard en vez de fiarse del nombre - que es la disciplina correcta en esta base, donde ya tenemos dos casos de nombre que promete mas que su cuerpo. Valida UNICAMENTE que el value pertenezca al vocabulario de la categoria segun la fase. No exige que exista al menos una fila por fase, y no impide que "Sin complicaciones" conviva con otras complicaciones en la misma practica. O SEA QUE LAS DOS INVARIANTES DE TERRA-136 SIGUEN SIN EXISTIR EN LA BASE, las dos por separado: ni la respuesta obligatoria ni la exclusividad. NO SE ESCRIBIO NINGUNA MIGRACION POR ESTO Y ES DELIBERADO: terra_55 sigue sin GO en la eq 78, y las invariantes medidas de esta clase esperan a que ese GO las ordene en vez de competir entre si.
• wi-cli-venus decision · 6w ago
  GO GRANTED BY ELAZAR, 2026-09-02. Relayed to db-terra-ca as the applying lane, hub tag coder02-terra-cc-mtjublevyd7f. AUTHORIZATION AND ITS PROVENANCE, written here because the artifact does not exist anywhere else: Elazar gave the GO as a direct CLI message to coder02-terra-cc, answering a numbered/lettered question list. The chosen option was 1a, "GO for both, apply in order after fresh rehearsal", covering terra_50 (TERRA-131) and terra_51 (TERRA-136) in one answer. Elazar is CLI-only and cannot emit a hub tag or an eq answer, so no such artifact will ever exist for this GO. The hub tag above is the RELAY of the authorization, not the authorization. Any applied/ header citing it must say so in the same sentence, the way terra_55 does. CONDITION CARRIED BY THE GO ITSELF, not added by me: a FRESH REHEARSAL per migration before each apply. The earlier preflight (6/6 live practicas, zero violations) was measured against a state of the base that no longer exists - terra_55 has been applied since. A rehearsal whose population predates an intervening apply is not a rehearsal of what will actually run. ORDER, and why it is not cosmetic: terra_50 applies first, then terra_51, and terra_51's rehearsal happens AFTER terra_50 is applied. Rehearsing both up front and then applying both would measure terra_51 against a base without terra_50 - a state that never exists at apply time. WHAT MUST LAND IN THESE ROWS BEFORE THEY CLOSE: rehearsal output per migration, the registration number of each apply, and the post-apply catalog verification. I verify the catalog independently against the live base afterwards - two lanes, not distrust. STANDING INSTRUCTION TO THE APPLYING LANE: if the fresh rehearsal disagrees with the earlier one in any respect, stop and report. Two rehearsals of the same migration disagreeing is a finding, not a discrepancy to reconcile privately.
• wi-cli-venus decision · 6w ago
  BLACKBOARD CONSULTATION, 2026-09-02. Elazar asked three questions about this row AFTER it was applied - is the invariant needed, what problem is it actually the solution to, is there a better mechanism - and asked that all terra lanes work on it. Four lanes were asked in one message and answered in files, not in a DM thread. Directory: /data-venus/terra/brainstorm/2026-09-02-terra136/ VERDICT: THE INVARIANT IS NEEDED AND THE MECHANISM IS THE RIGHT ONE. Three independent lanes reached that without reading each other, and one of them produced the fact that settles it. THE DECIDING MEASUREMENT, from db02-terra-cc, read out of the source rather than assumed: createTerraPractica - the ONLY INSERT path into terraPracticas - builds the complicaciones rows from unnest(COALESCE(complicacionesIntraArg, '{}'::text[])) and performs ZERO validation of that array inside the function. An empty array produces a live practica with zero intra rows and returns 'created' successfully. Nothing in the function raises. So the deferred trigger is not a second opinion on top of the application - IT IS THE ONLY ENFORCEMENT POINT THAT EXISTS for this RPC. The 6-of-6 compliant population is explained by the app form being the only current caller, not by the invalid state being unreachable. Corroborating, from the application lane: practica-complicaciones-core.ts carries the identical rule and its own header says PostgreSQL is the authority once this row is applied and the app copy exists to give the clinician an immediate error instead of waiting for the transaction to reject the same contradiction. The app author already wrote down that the app layer is UX and not the authority. WHY NOT A CHEAPER MECHANISM, and every lane converged here independently: the rule is cross-table and must hold at COMMIT, so a CHECK constraint or generated column cannot express it - Postgres CHECK cannot reference another table. An application-only guard misses SQL, imports, restore paths and any future caller. A scheduled detector cannot refuse a write, only report one that already committed and may already have been read. Moving the check into createTerraPractica would cover the INSERT path but reopen the gap the child-table UPDATE/DELETE arms exist to close - soft-deleting the LAST live intra row through another path. DECLARED BLIND SPOTS, kept because a proposal without one has not been thought through: the rule is forward-only and does not retroactively conform a historical or restored population; an unrelated UPDATE to a pre-existing zero-answer parent is deliberately not a trigger event; and no trigger can stop a privileged actor from disabling triggers. Those are limits of this control, not arguments against it. THE REPLICA SUB-QUESTION IS NOW SETTLED, AND MY EARLIER BLOCK IS LIFTED. db-terra-ca ran the control I asked for. Under current_setting('session_replication_role')='replica' in one rolled-back transaction, an ordinary O trigger (trg_terraPracticas_assignPracticaNumber) skipped AND the O-mode intra constraint trigger also skipped - a parent with a zona child and no intra answer reached SET CONSTRAINTS ALL IMMEDIATE without raising P0001. THE EARLIER CONTRARY REHEARSAL WAS A HARNESS SEQUENCING ERROR AND MUST NOT BE CITED AS EVIDENCE. The O/A asymmetry is therefore BEHAVIOURAL, not catalog cosmetics, and my original premise holds. I record this having been fully prepared to write the opposite: I told the lanes that if the control went the other way I would call my own asymmetry cosmetic and say so in those words. CONSEQUENCE: the ALTER to ENABLE ALWAYS on the four intra triggers is justified and Elazar's GO already covers it, including his condition that the restore bypass be written rather than assumed. That work stays with db-terra-ca. audit-terra-ca answered "SKIPPED - context too low", which is the correct answer at 9% context and was explicitly offered as one. Their lane's question is unanswered, not covered.
• wi-cli-venus decision · 6w ago
  BLACKBOARD CONSULTATION, 2026-09-02. Elazar asked three questions about this row AFTER it was applied - is the invariant needed, what problem is it actually the solution to, is there a better mechanism - and asked that all terra lanes work on it. Four lanes were asked in one message and answered in files, not in a DM thread. Directory: /data-venus/terra/brainstorm/2026-09-02-terra136/ VERDICT: THE INVARIANT IS NEEDED AND THE MECHANISM IS THE RIGHT ONE. Three independent lanes reached that without reading each other, and one of them produced the fact that settles it. THE DECIDING MEASUREMENT, from db02-terra-cc, read out of the source rather than assumed: createTerraPractica - the ONLY INSERT path into terraPracticas - builds the complicaciones rows from unnest(COALESCE(complicacionesIntraArg, '{}'::text[])) and performs ZERO validation of that array inside the function. An empty array produces a live practica with zero intra rows and returns 'created' successfully. Nothing in the function raises. So the deferred trigger is not a second opinion on top of the application - IT IS THE ONLY ENFORCEMENT POINT THAT EXISTS for this RPC. The 6-of-6 compliant population is explained by the app form being the only current caller, not by the invalid state being unreachable. Corroborating, from the application lane: practica-complicaciones-core.ts carries the identical rule and its own header says PostgreSQL is the authority once this row is applied and the app copy exists to give the clinician an immediate error instead of waiting for the transaction to reject the same contradiction. The app author already wrote down that the app layer is UX and not the authority. WHY NOT A CHEAPER MECHANISM, and every lane converged here independently: the rule is cross-table and must hold at COMMIT, so a CHECK constraint or generated column cannot express it - Postgres CHECK cannot reference another table. An application-only guard misses SQL, imports, restore paths and any future caller. A scheduled detector cannot refuse a write, only report one that already committed and may already have been read. Moving the check into createTerraPractica would cover the INSERT path but reopen the gap the child-table UPDATE/DELETE arms exist to close - soft-deleting the LAST live intra row through another path. DECLARED BLIND SPOTS, kept because a proposal without one has not been thought through: the rule is forward-only and does not retroactively conform a historical or restored population; an unrelated UPDATE to a pre-existing zero-answer parent is deliberately not a trigger event; and no trigger can stop a privileged actor from disabling triggers. Those are limits of this control, not arguments against it. THE REPLICA SUB-QUESTION IS NOW SETTLED, AND MY EARLIER BLOCK IS LIFTED. db-terra-ca ran the control I asked for. Under current_setting('session_replication_role')='replica' in one rolled-back transaction, an ordinary O trigger (trg_terraPracticas_assignPracticaNumber) skipped AND the O-mode intra constraint trigger also skipped - a parent with a zona child and no intra answer reached SET CONSTRAINTS ALL IMMEDIATE without raising P0001. THE EARLIER CONTRARY REHEARSAL WAS A HARNESS SEQUENCING ERROR AND MUST NOT BE CITED AS EVIDENCE. The O/A asymmetry is therefore BEHAVIOURAL, not catalog cosmetics, and my original premise holds. I record this having been fully prepared to write the opposite: I told the lanes that if the control went the other way I would call my own asymmetry cosmetic and say so in those words. CONSEQUENCE: the ALTER to ENABLE ALWAYS on the four intra triggers is justified and Elazar's GO already covers it, including his condition that the restore bypass be written rather than assumed. That work stays with db-terra-ca. audit-terra-ca answered "SKIPPED - context too low", which is the correct answer at 9% context and was explicitly offered as one. Their lane's question is unanswered, not covered.
• wi-cli-venus note · 6w ago
  probe short body
• wi-cli-venus decision · 6w ago
  BLACKBOARD CONSULTATION, 2026-09-02. Elazar asked three questions about this row AFTER it was applied - is the invariant needed, what problem is it actually the solution to, is there a better mechanism - and asked that all terra lanes work on it. Four lanes were asked in one message and answered in files, not in a DM thread. Directory: /data-venus/terra/brainstorm/2026-09-02-terra136/ VERDICT: THE INVARIANT IS NEEDED AND THE MECHANISM IS THE RIGHT ONE. Three independent lanes reached that without reading each other, and one of them produced the fact that settles it. THE DECIDING MEASUREMENT, from db02-terra-cc, read out of the source rather than assumed: createTerraPractica - the ONLY INSERT path into terraPracticas - builds the complicaciones rows from unnest(COALESCE(complicacionesIntraArg, '{}'::text[])) and performs ZERO validation of that array inside the function. An empty array produces a live practica with zero intra rows and returns 'created' successfully. Nothing in the function raises. So the deferred trigger is not a second opinion on top of the application - IT IS THE ONLY ENFORCEMENT POINT THAT EXISTS for this RPC. The 6-of-6 compliant population is explained by the app form being the only current caller, not by the invalid state being unreachable. Corroborating, from the application lane: practica-complicaciones-core.ts carries the identical rule and its own header says PostgreSQL is the authority once this row is applied and the app copy exists to give the clinician an immediate error instead of waiting for the transaction to reject the same contradiction. The app author already wrote down that the app layer is UX and not the authority. WHY NOT A CHEAPER MECHANISM, and every lane converged here independently: the rule is cross-table and must hold at COMMIT, so a CHECK constraint or generated column cannot express it - Postgres CHECK cannot referenc
• wi-cli-venus decision · 6w ago
  e another table. An application-only guard misses SQL, imports, restore paths and any future caller. A scheduled detector cannot refuse a write, only report one that already committed and may already have been read. Moving the check into createTerraPractica would cover the INSERT path but reopen the gap the child-table UPDATE/DELETE arms exist to close - soft-deleting the LAST live intra row through another path. DECLARED BLIND SPOTS, kept because a proposal without one has not been thought through: the rule is forward-only and does not retroactively conform a historical or restored population; an unrelated UPDATE to a pre-existing zero-answer parent is deliberately not a trigger event; and no trigger can stop a privileged actor from disabling triggers. Those are limits of this control, not arguments against it. THE REPLICA SUB-QUESTION IS NOW SETTLED, AND MY EARLIER BLOCK IS LIFTED. db-terra-ca ran the control I asked for. Under current_setting('session_replication_role')='replica' in one rolled-back transaction, an ordinary O trigger (trg_terraPracticas_assignPracticaNumber) skipped AND the O-mode intra constraint trigger also skipped - a parent with a zona child and no intra answer reached SET CONSTRAINTS ALL IMMEDIATE without raising P0001. THE EARLIER CONTRARY REHEARSAL WAS A HARNESS SEQUENCING ERROR AND MUST NOT BE CITED AS EVIDENCE. The O/A asymmetry is therefore BEHAVIOURAL, not catalog cosmetics, and my original premise holds. I record this having been fully prepared to write the opposite: I told the lanes that if the control went the other way I would call my own asymmetry cosmetic and say so in those words. CONSEQUENCE: the ALTER to ENABLE ALWAYS on the four intra triggers is justified and Elazar's GO already covers it, including his condition that the restore bypass be written rather than assumed. That work stays with db-terra-ca. audit-terra-ca answered "SKIPPED - context too low", which is the correct answer at 9% context and was explicitly offered as one. Their lane's question is unanswered, not covered.
• wi-cli-venus note · 6w ago
  BLACKBOARD CONSULTATION, 2026-09-02. Elazar asked three questions about this row AFTER it was applied - is the invariant needed, what problem is it actually the solution to, is there a better mechanism - and asked that all terra lanes work on it. Four lanes were asked in one message and answered in files, not in a DM thread. Directory: /data-venus/terra/brainstorm/2026-09-02-terra136/ VERDICT: THE INVARIANT IS NEEDED AND THE MECHANISM IS THE RIGHT ONE. Three independent lanes reached that without reading each other, and one of them produced the fact that settles it. THE DECIDING MEASUREMENT, from db02-terra-cc, read out of the source rather than assumed: createTerraPractica - the ONLY INSERT path into terraPracticas - builds the complicaciones rows from unnest(COALESCE(complicacionesIntraArg, '{}'::text[])) and performs ZERO validation of that array inside the function. An empty array produces a live practica with zero intra rows and returns 'created' successfully. Nothing in the function raises. So the deferred trigger is not a second opinion on top of the application - IT IS THE ONLY ENFORCEMENT POINT THAT EXISTS for this RPC. The 6-of-6 compliant population is explained by the app form being the only current caller, not by the invalid state being unreachable. Corroborating, from the application lane: practica-complicaciones-core.ts carries the identical rule and its own header says PostgreSQL is the authority once this row is applied and the app copy exists to give the clinician an immediate error instead of waiting for the transaction to reject the same contradiction. The app author already wrote down that the app layer is UX and not the authority. WHY NOT A CHEAPER MECHANISM, and every lane converged here independently: the rule is cross-table and must hold at COMMIT, so a CHECK constraint or generated column cannot express it - Postgres CHECK cannot referenc
• wi-cli-venus note · 6w ago
  e another table. An application-only guard misses SQL, imports, restore paths and any future caller. A scheduled detector cannot refuse a write, only report one that already committed and may already have been read. Moving the check into createTerraPractica would cover the INSERT path but reopen the gap the child-table UPDATE/DELETE arms exist to close - soft-deleting the LAST live intra row through another path. DECLARED BLIND SPOTS, kept because a proposal without one has not been thought through: the rule is forward-only and does not retroactively conform a historical or restored population; an unrelated UPDATE to a pre-existing zero-answer parent is deliberately not a trigger event; and no trigger can stop a privileged actor from disabling triggers. Those are limits of this control, not arguments against it. THE REPLICA SUB-QUESTION IS NOW SETTLED, AND MY EARLIER BLOCK IS LIFTED. db-terra-ca ran the control I asked for. Under current_setting('session_replication_role')='replica' in one rolled-back transaction, an ordinary O trigger (trg_terraPracticas_assignPracticaNumber) skipped AND the O-mode intra constraint trigger also skipped - a parent with a zona child and no intra answer reached SET CONSTRAINTS ALL IMMEDIATE without raising P0001. THE EARLIER CONTRARY REHEARSAL WAS A HARNESS SEQUENCING ERROR AND MUST NOT BE CITED AS EVIDENCE. The O/A asymmetry is therefore BEHAVIOURAL, not catalog cosmetics, and my original premise holds. I record this having been fully prepared to write the opposite: I told the lanes that if the control went the other way I would call my own asymmetry cosmetic and say so in those words. CONSEQUENCE: the ALTER to ENABLE ALWAYS on the four intra triggers is justified and Elazar's GO already covers it, including his condition that the restore bypass be written rather than assumed. That work stays with db-terra-ca. audit-terra-ca answered "SKIPPED - context too low", which is the correct answer at 9% context and was explicitly offered as one. Their lane's question is unanswered, not covered.
• wi-cli-venus note · 6w ago
  e another table. An application-only guard misses SQL, imports, restore paths and any future caller. A scheduled detector cannot refuse a write, only report one that already committed and may already have been read. Moving the check into createTerraPractica would cover the INSERT path but reopen the gap the child-table UPDATE/DELETE arms exist to close - soft-deleting the LAST live intra row through another path. DECLARED BLIND SPOTS, kept because a proposal without one has not been thought through: the rule is forward-only and does not retroactively conform a historical or restored population; an unrelated UPDATE to a pre-existing zero-answer parent is deliberately not a trigger event; and no trigger can stop a privileged actor from disabling triggers. Those are limits of this control, not arguments against it. THE REPLICA SUB-QUESTION IS NOW SETTLED, AND MY EARLIER BLOCK IS LIFTED. db-terra-ca ran the control I asked for. Under current_setting('session_replication_role')='replica'
• wi-cli-venus note · 6w ago
  in one rolled-back transaction, an ordinary O trigger (trg_terraPracticas_assignPracticaNumber) skipped AND the O-mode intra constraint trigger also skipped - a parent with a zona child and no intra answer reached SET CONSTRAINTS ALL IMMEDIATE without raising P0001. THE EARLIER CONTRARY REHEARSAL WAS A HARNESS SEQUENCING ERROR AND MUST NOT BE CITED AS EVIDENCE. The O/A asymmetry is therefore BEHAVIOURAL, not catalog cosmetics, and my original premise holds. I record this having been fully prepared to write the opposite: I told the lanes that if the control went the other way I would call my own asymmetry cosmetic and say so in those words. CONSEQUENCE: the ALTER to ENABLE ALWAYS on the four intra triggers is justified and Elazars GO already covers it, including his condition that the restore bypass be written rather than assumed. That work stays with db-terra-ca. audit-terra-ca answered "SKIPPED - context too low", which is the correct answer at 9% context and was explicitly offered as one. Their lanes question is unanswered, not covered.
• wi-cli-venus note · 6w ago
  probeA SET CONSTRAINTS ALL IMMEDIATE
• wi-cli-venus note · 6w ago
  probeB ALTER TABLE t ENABLE ALWAYS TRIGGER x
• wi-cli-venus note · 6w ago
  probeC session_replication_role replica P0001
• wi-cli-venus decision · 6w ago
  REPLICA-CONTROL-20260902. Control run by db-terra-ca settles the replica sub-question and lifts my block. Under session_replication_role set to replica, in one rolled-back transaction, an ordinary O trigger skipped AND the O-mode intra constraint trigger also skipped: a parent with a zona child and no intra answer reached the immediate constraint boundary without raising P0001. The earlier contrary rehearsal was a harness sequencing error and must NOT be cited as evidence. The O versus A difference is therefore BEHAVIOURAL, not catalog cosmetics, and my original premise holds. I record this having been prepared to write the opposite: I told the lanes that if the control went the other way I would call my own asymmetry cosmetic in those words. CONSEQUENCE: the ALTER to ENABLE ALWAYS on the four intra triggers is justified, Elazar GO already covers it including his condition that the restore bypass be WRITTEN and not assumed, and that work stays with db-terra-ca. audit-terra-ca answered SKIPPED at 9 percent context, which was explicitly offered as correct; their lane question is unanswered, not covered.
• wi-cli-venus assigned · 5w ago
  db-terra-cc
• wi-cli-venus assigned · 5w ago
  db02-terra-ca
• wi-cli-venus assigned · 5w ago
  db-terra-cc
• wi-cli-venus assigned · 5w ago
  db02-terra-ca / db
• wi-cli-venus note · 5w ago
  HANDOFF db-terra-cc -> db02-terra-ca, orden directa de Elazar en CLI 2026-09-10. Marker HOFF-136-mtvfq. Estado sin cambios desde el blockedReason: no queda trabajo tomable. terra_51_practica_intra_complicacion_required.sql sigue en db/migrations/draft/, confirmado en disco ahora. Lo unico pendiente es el GO de apply de Elazar, pedido en eq 72 y todavia abierto. No empieces trabajo nuevo aca; el desbloqueo es una decision, no una tarea.
• wi-cli-venus titleChanged · 5w ago
  Intraoperative-complication DB invariant is live; behavior exercise and source provenance need reconciliation
• wi-cli-venus descriptionChanged · 5w ago
  was: Elazar explicitly confirmed on 2026-08-30 that Terra Complicaciones intraoperatorias must adopt the required and logical Sin complicaciones behavior described in the preceding CLI exchange. Add the authoritative PostgreSQL invariant for NEW practice writes: at least one intraoperative-complication answer is required, and sinComplicaciones cannot coexist with any actual complication. Preserve historical practices that legally have zero rows; do not rewrite them or make unrelated updates fail. Design for Terra's transactional parent-plus-child write order; an absence rule cannot be enforced by an ordinary child-row trigger. Draft migration, behavioral dry-run including legacy-row preservation/new empty rejection/contradiction rejection/valid none/valid actuals, obtain required audit and shared-owner gates, then apply. Client and Node validation may mirror this invariant for useful Spanish errors but cannot be its only authority.
• wi-cli-venus unblocked · 5w ago
  Live trigger catalog invalidates the apply-GO blocker; source/provenance and behavior evidence remain.
• wi-cli-venus titleChanged · 5w ago
  Intraoperative-complication DB invariant is ENABLE ALWAYS and replica-tested
• wi-cli-venus descriptionChanged · 5w ago
  was: DB-side status corrected 2026-09-10. Live catalog contains the four deferred requireIntraAnswer constraint triggers: parent INSERT and child INSERT/UPDATE/DELETE. The original blocker stating terra_51 awaits apply is stale.\n\nSource boundary: terra_51 remains under db/migrations/draft/ while untracked apply/provenance artifacts conflict with that source location. Live catalog proves the trigger objects exist; it does not by itself exercise acceptance/rejection behavior or establish a tracked migration registration.\n\nNext: reconcile source/provenance and obtain an independently recorded behavioral exercise before closure. Do not re-apply the migration.
• wi-cli-venus completed · 5w ago
  DB implementation and rollback verification complete; app-path exercise is explicitly outside this DB closure.