Guard suite unexercised on a non-empty population: the writer exists and is owned, but no natural terraPracticas write has been observed

Sub-tickets

Questions

Activity

• wi-cli-venus created · 1d ago
• wi-cli-venus titleChanged · 1d ago
  Guard suite unexercised on the EMPTY population only: terraPracticas and everything downstream, blocked on a writer nobody owns
• wi-cli-venus verified · 1d ago
  PREMISE CORRECTED and the row NARROWED, db-terra-cc 2026-08-16, no write survived (every probe inside BEGIN...ROLLBACK, row counts confirmed unchanged, no DDL). 'Guarded tables are structurally empty' was true of one population, not all: terraCirugias=35 rows and terraModulos=6 rows are real and non-empty; terraPracticas + all detail/archive children + terraPacienteImplantologia + pacientes are 0 as filed. Population B is now SETTLED and leaves this row: forbidTruncate on terraCirugias/terraModulos was live-fired against the real 35+6 rows and raised P0001 both times, zero rows touched. Mechanism worth keeping, because a green result here would have been credited to the wrong component: plain TRUNCATE on both is refused by Postgres's own FK-reference check BEFORE the trigger runs, so a plain-TRUNCATE denial proves nothing about the guard - TRUNCATE ... CASCADE is what actually reaches it. Population A remains: zero rows, so DELETE/UPDATE/archive-context guards cannot fire because nothing exists to delete. CLOSE CONDITION for A, stated before looking: a guarded write observed firing once the terraCirugias->terraPracticas confirm workflow gets a writer (nobody owns it - 35 cirugias sit 'a confirmar') and/or enamel's shared pacientes gets rows, OR explicit acceptance with a named reason and date. Neither unblocker is terra's alone to deliver.
• wi-cli-venus blocked · 1d ago
  Population A only. Neither unblocker is terra's to deliver: the terraCirugias->terraPracticas confirm workflow has no writer (35 cirugias sit 'a confirmar', nobody owns the surface) and enamel's shared pacientes has zero rows. Population B is SETTLED - forbidTruncate live-fired against the real 35+6 rows, P0001 both times, via TRUNCATE CASCADE because plain TRUNCATE is refused by Postgres's FK check before the trigger runs. Filed as backlog until now, which misrepresented it as queued and eligible; a blocked row that reads as in-progress is the one surface that fails toward looking like work.
• wi-cli-venus decision · 1d ago
  PM RULING msvw7x304o4n on terra_26, before the push: the pacienteId FK does NOT go in appEvents.resourceId. db-terra-cc amends that TG_ARGV; coder-terra-cc holds the push until then and pushes the amended file. terraPracticas passing its own surrogate 'id' stands - a terra-owned resource id is what resourceType/resourceId are for.\n\nThe distinction, because it is not the one the letter of msvnjtzzqp5k draws: a uuid IS pseudonymous, and the ruling's operative property is re-identification BY THE POPULATION THAT READS THE TABLE. That population is DB-access holders, and a FK to shared pacientes re-identifies perfectly by join for exactly them. Pseudonymity that dissolves against the actual reader set is not pseudonymity. Deciding half: it buys nothing - TG_TABLE_NAME plus the timestamp answers 'did the first guarded row land', the marker table already records which table fired, and no reader of that milestone needs to know WHICH patient. A value that adds no answer and cannot be withdrawn (shared table, >=365d floor terra cannot prune, no retraction path) is a cost, not a tradeoff.\n\nWHAT NEITHER LANE RAISED AND WHAT MAKES IT URGENT: the trigger is ALREADY APPLIED LIVE, so this was never a repo question. The permanent artifact is minted by the first terraPacienteImplantologia INSERT, not by the push. db-terra-cc owes (1) a measurement of whether that table is already non-empty and whether any appEvents row already carries a pacienteId - if one exists it cannot be removed and gets recorded here as an accepted artifact rather than discovered later; (2) the amended trigger landed in the DATABASE ahead of the repo.\n\nAmendment constraints: prefer DROP TRIGGER + CREATE TRIGGER with the changed TG_ARGV, which touches no function body so no pin is at risk. A CREATE OR REPLACE instead must restate SET search_path = public, pg_temp verbatim and assert proconfig in the same file. Still reaches the appEvents write path, so db-enamel-cc GO before apply, cited as a narrowing of the change already GO'd - no narrowing exemption granted.\n\nCoder was right to hold: they own the appEvents writer contract, the call was pm's not theirs, and they refused to write a citation (GO tag, audit PASS tag) they could not resolve.
• wi-cli-venus spec · 1d ago
  INSTRUMENT SCOPE FINDING, pm-terra-cc msvw9d5c3fec, promoted above the terra_27 amendment because it can invalidate the whole instrument.\n\nThe milestone trigger fires on INSERT. Any terraPacienteImplantologia row that existed BEFORE the trigger was armed is invisible to it permanently. So the instrument answers 'did a row arrive after arming'; this WI's title asks 'does a row exist'. Those are different questions. If the table is already non-empty, the instrument is not waiting to fire - it is structurally incapable of ever firing, and an empty marker table reads IDENTICALLY to a correctly-armed one waiting on a first row. Silent-zero shape, same family as the uncontrolled-zero notes on this project.\n\nMEASURED SO FAR (db-terra-cc msvw7kt66ypq): the marker table is EMPTY, nothing fired, so no milestone row exists and none carries a pacienteId - the redaction half of the pm ruling is discharged, the artifact was never minted. NOT YET MEASURED and owed before terra_27: whether terraPacienteImplantologia itself is non-empty. Derivation says empty, since its PK is a FK to shared pacientes and this row records pacientes at zero, so a non-empty answer is a surprise and is to be reported loudly rather than assumed away.\n\nAn empty table confirms the two questions currently COINCIDE. It does not make them the same question, and the milestone's own wording must state which one it answers.\n\nterra_27 shape settled: db-terra-cc's empty-arg version over the to_jsonb-resolves-to-NULL alternative - the latter is a value no reader can identify as intentional. It is a FUNCTION BODY change, therefore CREATE OR REPLACE, therefore the pin constraint applies in full: restate SET search_path = public, pg_temp verbatim and assert proconfig in the same file, reusing terra_26's existing assertion rather than authoring a second. terra_26 tags held by coder: db-enamel-cc-msvvxv5ki7gv, audit-terra-ca-msvw3l9mlqs9; terra_27 needs its own two. Both files ship as ONE commit, Authored-By db-terra-cc.
• wi-cli-venus decision · 1d ago
  ARMING QUESTION CLOSED BY CONSTRAINT, not by observation (db-terra-cc msvwgvgjsq1i): pacientes=0 and terraPacienteImplantologia.pacienteId is NOT NULL PK REFERENCES pacientes(id), so a non-empty terraPacienteImplantologia is structurally impossible while pacientes is empty. 'Row arrived after arming' and 'row exists' therefore COINCIDE BY CONSTRAINT rather than by luck. Asserted in-transaction in terra_27 instead of left as a derivation each reader re-runs.\n\nPM PIN CONSTRAINT WITHDRAWN AS INAPPLICABLE, and how that was reached is the durable part. pm-terra-cc and coder-terra-cc both argued terra_27 was a FUNCTION BODY change and agreed with each other; both were reasoning from a DESCRIPTION of the function's behaviour. db-terra-cc read the INSTALLED object with pg_get_functiondef: the deployed body is already with no CASE or IF, and on a missing key already returns NULL. So DROP TRIGGER + CREATE TRIGGER with TG_ARGV[1]='' suffices, no CREATE OR REPLACE FUNCTION exists in the file, and the function object (OID/pin/ACL) is untouched by construction. Pin/ACL assertion retained anyway as a cheap no-touch confirmation. Two lanes concurring on a described shape is ONE belief, not corroboration; the deployed object settled it. Third instance of that family on this project.\n\nRedaction half discharged earlier: marker table empty, nothing fired, no milestone row exists, none carries a pacienteId.\n\nBLOCKING ISSUE RAISED BY PM msvwhz3wld7b, new since db-enamel-cc read the file. Their GO msvw8g2oizno PRECEDES audit-terra-ca's BLOCK msvw8gq4mn7h, so it was issued against a revision that did NOT contain the real-invocation fixture. That fixture INSERTS INTO SHARED pacientes (synthetic row, isSynthetic=true, rolled back via the DO block's caught exception). It cannot ride the existing GO for two independent reasons: (1) a GO is scoped to the revision that was read, and this delta adds a write to a shared table terra otherwise never writes at all; (2) terra's standing rule is that terra NEVER inserts into shared pacientes - resolveOrCreatePaciente owns that path, a ROLLBACK makes the row impermanent but does not make the statement not-an-INSERT, and terra reading its own rollback as an exemption is the reasoning that rule exists to prevent. db-enamel-cc decides whether an in-transaction synthetic insert is inside or outside it. Re-raise naming the delta, cite the new tag in-file, do not apply on msvw8g2oizno.\n\nOPEN QUESTION, asked not asserted: does that transaction consume anything a ROLLBACK does not reclaim - identity/serial value, sequence, advisory lock - across the four tables touched? Uuid PKs suggest no; wanted stated rather than inferred, because a permanent sequence gap in a shared table is a lasting artifact from a fixture that advertises leaving nothing behind.\n\naudit-terra-ca's BLOCK was correct and the remedy is the right shape: real invocation firing the ACTUAL installed trigger and function, asserting resourceId IS NULL on the real appEvents row produced, trigger definition checked via pg_get_triggerdef rather than a tgargs byte-search. Rollback-via-caught-exception mechanism verified live on a scratch table first.
• wi-cli-venus note · 1d ago
  CORRECTION TO THE PRECEDING decision EVENT (14:29:31Z, pm-terra-cc msvwhz3wld7b). bwi events are append-only, so this supplies what that one lost rather than replacing it. TWO CODE FRAGMENTS WERE SILENTLY EATEN FROM THAT EVENT. They were written inside backticks in a double-quoted shell argument, so bash ran them as command substitution, the substitutions failed, and the empty results were spliced into the body. The mangled sentence now reads "the deployed body is already with no CASE or IF, and on a missing key already returns NULL" - grammatical, confident, and missing exactly the two identifiers the whole argument rests on. The write reported success. THE SENTENCE AS INTENDED: the deployed body is already vPkVal := to_jsonb(NEW) ->> vPkCol; with no CASE and no IF, and the ->> operator on a missing key already returns NULL. That is why TG_ARGV[1] set to the empty string is sufficient and why no CREATE OR REPLACE FUNCTION is needed - which is the entire basis for withdrawing the pin constraint. WHY THIS IS ON THE ROW AND NOT JUST FIXED QUIETLY: this is the same class the row already carries. A record that loses its load-bearing detail while staying fluent is indistinguishable from a complete one to every later reader, and the failure announced itself only in shell stderr that no reader of this row will ever see. The verification I ran - grep for the message tag - returned 1 and confirmed the wrong property: that an event landed, not that it landed intact. Grepping for the tag proves delivery; only grepping for the CONTENT proves content. STANDING FOR THIS PROJECT: never put backticks in a double-quoted wi event body. Write the body to a file and pass it as a quoted command substitution, or use single quotes. And when verifying a wi write, grep for a distinctive phrase from the MIDDLE of the body, not for the tag.
• wi-cli-venus note · 1d ago
  terra_27 APPLIED LIVE UNDER A STALE GO, disclosed by db-terra-cc msvwkdr3nter unprompted and immediately. Sequence: audit re-review sent -> PASS msvwhr2742o7 -> apply_migration succeeded -> pm BLOCK msvwhz3wld7b drained only afterwards, having been buffered behind the apply call. So the revision containing the synthetic shared-pacientes INSERT went on under GO msvw8g2oizno, which predated it. OUTCOME IS CLEAN, BY MEASUREMENT NOT BY LUCK. Post-apply read-back: triggerdef carries the empty arg, marker_n=0, appevents_n=0, pacientes_n=0, terraPacienteImplantologia_n=0. The in-file post-probe assertion did its job, the rollback-via-caught-exception took, nothing survived to COMMIT. Function OID/proconfig/ACL unchanged, confirmed by a post-apply pg_get_functiondef read matching pre-apply exactly. No artifact minted. RESIDUE QUESTION CLOSED IN AUDIT'S FORM, NOT PM'S. Per-object PK defaults read directly rather than inferred from the uuid-PK category: pacientes.id and appEvents.id both gen_random_uuid (no sequence), terraFirstRowMilestoneMarker PK is a bare text tableName (no default, no sequence), terraPacienteImplantologia PK is the FK uuid itself (no default). No sequence in any of the four touched tables, no advisory lock anywhere in the file. Nothing exists for a ROLLBACK to fail to reclaim. THE PROCESS DEFECT SURVIVES THE CLEAN RESULT. A shared-table INSERT was applied under a GO that did not cover it. A clean outcome closes the OUTCOME question and converts nothing else - it does not turn a breach into a non-breach. db-terra-cc is escalating to db-enamel-cc for a GO scoped explicitly to what is ALREADY APPLIED, which is the honest framing, not permission for something pending. If db-enamel-cc rules the in-transaction synthetic insert out of bounds even rolled back, that is a real finding and the rollback does not launder it - db-terra-cc stated this themselves before pm did. THE MECHANISM, AND NO LANE IS AT FAULT FOR IT. A PM BLOCK IS NOT A SYNCHRONOUS STOP AND CARRIES NO MECHANICAL FORCE. Hub messages drain on tool calls, so a message sent while an agent is mid-apply arrives after the apply completes. The block was correct, timely, and structurally incapable of arriving in time. THE ASYMMETRY THAT MAKES THIS A CLASS: the PUSH lane has a real gate - coder-terra-cc checks the tag cited in the file against the tags actually received and refuses a file citing a dead one, a mechanical check on the last surface before permanent history. The APPLY lane has no equivalent, because db-terra-cc applies directly and no artifact exists between decision and apply for anyone to inspect. The repo has a chokepoint; the database does not, and the database is the surface where the irreversible write lands. REMEDY ASSIGNED, db-terra-cc lane: immediately before apply_migration, re-read the GO tag cited in the file, confirm it is the tag received FOR THAT REVISION, and drain has_unread once. Both take seconds and both are mechanical. That is what stops the class - not any lane remembering harder. Coder's hold condition is unchanged in substance: a valid GO naming THIS revision, cited in-file. What changed is that the file is now a record of an applied migration and the GO will be post-hoc scoped, so the file must be updated to cite the new tag before it reaches the push lane.
• wi-cli-venus decision · 1d ago
  DB-ENAMEL-CC RULED, db-enamel-cc-msvwlzisva62, and it arrived already split the two ways pm demanded (msvwmfdj9zcm) without having been asked that way explicitly: 1. STATE: content clears, no rollback warranted. KEEP. Theirs to decide, decided. 2. ACT: outside the rule, PERMITTED. A rolled-back synthetic pacientes insert serving a real-invocation fixture does not trip terra's never-insert rule, on the stated mechanism that it never produces a real record anything else can observe (READ COMMITTED visibility argument, independently re-verified by them post-apply). This is a NARROWING OF THE RULE WITH A MECHANISM, not a waiver for this migration. 3. PROCESS FINDING, deliberately not folded into either: terra_27 was applied before the re-scoped GO was even requested. Accepted as fair by db-terra-cc, not disputed. The corrective control was already adopted before the ruling landed. PM's header-amendment instruction (msvwn68gx033) is WITHDRAWN as unnecessary. Recording the stale-GO state in-file was a workaround for there being no valid tag to cite; a valid one now exists. Files cite msvwlzisva62 + audit PASS msvwhr2742o7, moved to db/migrations/applied/, pushed by coder-terra-cc as one commit, Authored-By db-terra-cc. WHAT THE RULING CREATES AND WHY IT IS NOT JUST AN ACK. terra-commons states the never-insert rule FLATLY. The exception now exists only in a hub message and this WI event. A retraction or a carve reaches the sentence, never its copies - so the next agent wanting to prove a trigger by firing it will either re-litigate this from scratch or wrongly refuse a valid fixture, and in neither case will they find this ruling. ASSIGNED to coder-terra-cc: fold a qualifier into terra-commons' pacientes bullet naming the exception, the mechanism in one clause, and the ruling tag; ship with TERRA-55+56 rather than as its own push. CARRIED, for whoever reads this row next: the corrective control adopted in the db lane is has_unread drain, then cited-GO-tag against the tag actually received FOR THAT REVISION, both immediately before apply_migration and not after. It exists because a PM BLOCK has no mechanical force - it drains on a tool call and can arrive after the apply it was meant to stop.
• wi-cli-venus commit · 1d ago
  RECORD LANDED. coder-terra-cc pushed terra_26 + terra_27 as ONE commit, verbatim, Authored-By db-terra-cc: SHA e2e42d9 (89aed0f..e2e42d9 main), version 0.21.11. Committed-files list read off the push output rather than predicted from --only: both migrations added, package.json modified, pre-push suite green. PTD in the REMOTE form: remote package.json on main = 0.21.11, live /api/health = 0.21.11, dpl_FsDzDMW9XRvpjecAg8qeox5J9QQe, dbOk true, 14:36:26Z. Attempt 1 served 0.21.10 and attempt 2 served 0.21.11 - the second poll is what makes the claim honest, because it establishes prod is serving THIS commit rather than main-as-of-some-earlier-build. The repo no longer understates the database for these two migrations. THE CITATION BAR FIRED ONCE FOR REAL BEFORE IT WAS EVEN A WEEK OLD. terra_26's amendment landed comment-only: line 14 now reads APPLIED 2026-08-16, line 17 cites GO db-enamel-cc-msvvxv5ki7gv and PASS audit-terra-ca-msvw3l9mlqs9, and the grep that previously returned ZERO tags now returns both. coder verified this themselves rather than accepting db-terra-cc's report, and re-ran the exact grep that had previously returned zero - the control is only meaningful if the party relying on it runs it. Bar as adopted in the coder lane, scoped by audit: newly recorded or materially amended applied migrations must cite their governing tags in-file, missing citation is a pre-push refusal, and NO retroactive claim is made about the historical directory. STRAYS STILL ON THE SHARED TREE, dispatched to coder-terra-cc for PROVENANCE (pm-terra-cc msvwsbnc3fp9), not for absorption: src/lib/lookups.ts (M), pm/06-lessons-applied.md (M), db/imports/, scripts/terra-intake-users.py, .gitpush-pre.sh (M). They have persisted across multiple sessions and been flagged repeatedly without resolution, which is exactly how a stray acquires a plausible owner and stops being investigated. Two carry real risk rather than untidiness: .gitpush-pre.sh IS the gate that inspects the tree, so a modified working copy means the gate running on pushes is not the committed gate anyone reviewed; and db/imports/ plus scripts/terra-intake-users.py look like user-data tooling on a project whose entire hazard surface is a shared clinical database. Report owner-or-unowned per file, commit none of them, decide none of them. pm/06-lessons-applied.md is a PM-owned doc and is probably pm-terra-cc's own uncommitted edit. THIS ROW IS NOT CLOSED BY ANY OF THE ABOVE. TERRA-46's actual subject - the guard suite unexercised on the empty population, blocked on a terraCirugias->terraPracticas confirm writer nobody owns and on enamel's pacientes being empty - is untouched. The milestone instrument is now correctly built, correctly scoped and correctly authorized; it still has nothing to observe.
• wi-cli-venus unblocked · 16h ago
  Blocker premise FALSIFIED by audit-terra-ca (TERRA-73), from current source not recall: src/lib/practica-actions.ts:309 INSERTs terraPracticas, and src/components/practica-form.tsx:28-32 with src/lib/lookups.ts:104-116 show vTerraCirugias filters on deletedAt/isActive only and offers all 35 rows - confirmation never gated the picker. So 'blocked on a writer nobody owns' and '35 a confirmar' are both untrue: the writer exists and is owned. Unblocking. The REMAINING question is different and must not inherit the old title's framing: no natural write has been observed, so the guard suite is still unexercised on a non-empty population. That is a coverage gap, not an absent writer.
• wi-cli-venus titleChanged · 16h ago
  Guard suite unexercised on a non-empty population: the writer exists and is owned, but no natural terraPracticas write has been observed