Who may create a practica is an undecided policy the source itself flags: page and action both gate on all five PRACTICA_ROLES and that default also authorises a write into enamel's shared pacientes registry

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus blocked · 6w ago
  Blocked on a product ruling from Elazar, and probably the client after him. No agent may pick the five-role set or narrow it. Filed blocked rather than backlog so it is not chosen as next work: nothing in the code can decide it, and the source comment at nueva/page.tsx:31-32 already records that the gate below it is not a ruling.
• wi-cli-venus blocked · 6w ago
  Blocked on a product ruling from Elazar, and probably the client after him. No agent may pick the five-role set or narrow it. Filed blocked rather than backlog so it is not chosen as next work: nothing in the code can decide it, and the source comment already records that the gate below it is not a ruling. CITA CORREGIDA 2026-09-01: este campo decia nueva/page.tsx:31-32 y ESA RUTA NO EXISTE. La real es src/app/practicas/nueva/page.tsx:27-33. Hallazgo de coder-terra-ca en su barrido de codigo contra tablero, verificado por mi con ls y leyendo el archivo antes de aceptarlo: el comentario esta ahi y dice textualmente que cuales roles DEBERIAN poder registrar una practica sigue siendo un item de producto ABIERTO, y que el gate es la frontera de tenencia mas una lista nombrada, no un fallo. O sea que el bloqueo es correcto y lo unico que estaba roto era el puntero. POR QUE SE CORRIGE Y NO SE DEJA: una cita rota manda al lector a buscar y le devuelve nada, y de eso no se concluye la ruta cambio sino la evidencia no existe o la cita es inventada. Hoy ya paso tres veces en este proyecto por caminos distintos.
• wi-cli-venus note · 6w ago
  VIGENTE, con un LIMITE que audit-terra-ca marco sin que se lo pidiera y que corrige como hay que citar esta fila. Releida a ciegas contra fuente el 2026-09-01 08:34. LAS DOS MITADES, verificadas por separado como pedi: la pagina gatea con requireAppUserPage(PRACTICA_ROLES) en src/app/practicas/nueva/page.tsx:27-34, y la accion gatea con LA MISMA constante a traves de requireAppUserAction en practica-actions.ts:265-276. O sea que no hay un segundo gate mas estrecho del lado del servidor: los cinco roles - alumno, docente, jtp, bedel, admin - autorizan las dos superficies. Y LA SEGUNDA MITAD TAMBIEN SE SOSTIENE: la accion invoca resolveOrCreatePaciente de enamel DENTRO de su transaccion de escritura, en practica-actions.ts:380-415, explicitamente ANTES del INSERT de la practica. Asi que el camino que autorizan esos cinco roles si alcanza el registro COMPARTIDO de pacientes de enamel. DOS FRASES, PORQUE LA CORTA ES FALSA Y ES LA QUE SE VA A CITAR SOLA. La exacta: el gate de cinco roles autoriza un camino que PUEDE CREAR una fila en el registro compartido de pacientes. La falsa: "cada practica que se carga crea un paciente en enamel". La fuente no prueba eso - la funcion RESUELVE o crea, y un paciente ya existente se resuelve sin escribir nada nuevo. La diferencia importa para el argumento de la fila: el riesgo es que un alumno pueda CAUSAR una escritura en una tabla compartida, no que la cause siempre. LO QUE audit DECLARO NO EXPLORADO, y lo dejo escrito en vez de taparlo: no leyo el cuerpo de la funcion de enamel, ni su comportamiento desplegado, ni ningun dato vivo de pacientes. O sea que "puede crear" sale del nombre y del lugar de la llamada, no de haber visto la funcion crear una fila. Medir cuantas filas de pacientes nacieron por este camino, y con que rol del actor, es una medicion de base que NO se hizo y que decidiria si esto ya paso. LO QUE LA FILA SIGUE PIDIENDO: la decision de politica. Si alumno debe poder cargar una practica es lo que la fuente misma marca como indefinido, y el que ese default alcance una tabla compartida con otra app es lo que lo vuelve una pregunta de frontera y no de comodidad. No es mia.
• wi-cli-venus assigned · 5w ago
  coder02-terra-ca
• wi-cli-venus assigned · 5w ago
  coder02-terra-cc
• wi-cli-venus decision · 5w ago
  DECIDED. Marker: T150-dec-mtwz01. Decided by the terra PM lane on 2026-09-11 under Elazar's 09:27 ART standing delegation, carrying pmmaster-evolutiva-cc's eq#67 ruling. This is NOT Elazar's own wording - he can overrule this specific row without distrusting the rest of the queue. THE ROW FUSED TWO DECISIONS THAT HAVE DIFFERENT ANSWERS, because one form does both things. (1) WHO MAY CREATE A PRACTICA: all five PRACTICA_ROLES. NO CHANGE. Terra's premise is that the person who was in the surgery records it; narrowing that breaks the primary flow three weeks before 1/10 with zero evidence of abuse. The point of recording it is that today the current behaviour is an accident of the code rather than a ruling - it is now a ruling, and the row closes on this half. (2) WHO MAY CREATE A PATIENT FROM INSIDE THAT FORM: narrows to docente / bedel / admin. An alumno whose patient is not already in the registry gets the record-and-request shape terra already uses elsewhere, not a silent write. WHY THE SPLIT: "who records a surgery" does not imply "who may write a new person into the shared clinical registry". The two only look like one question because createPractica and lookupPaciente sit behind a single submit. BEFORE BUILDING HALF 2: clear it with db-enamel-cc and coder-enamel-cc. The pacientes registry is enamel-owned and shared, so this is not a terra-local change. If enamel's side already tolerates alumno writes, overrule this and say so on the row with the reason - do not silently keep the narrower gate against their design. Half 1 needs no code. Half 2 is implementable once enamel answers.
• wi-cli-venus unblocked · 5w ago
  policy decided T150-dec-mtwz01: all 5 PRACTICA_ROLES may create a practica (no code); patient creation narrows to docente/bedel/admin, needs db-enamel-cc + coder-enamel-cc clearance before building
• wi-cli-venus decision · 5w ago
  CLEARANCE RECEIVED, HALF 2 IS UNBLOCKED, BUILD THE NARROWING. Marker: T150-dec-mtx15a. coder-enamel-cc answered 2026-09-11 11:07 ART, measured live, NOT OVERRULED. T150-dec-mtwz01 was explicitly conditional on this and the condition is now met. THE ANSWER IS WORSE THAN "ENAMEL ALLOWS IT" AND WORSE THAN "ENAMEL FORBIDS IT". Enamel CANNOT SEE ROLES AT ALL. resolveOrCreatePaciente is SECURITY INVOKER, EXECUTE granted to service_role only, and it takes NO actor argument - every terra user reaches it as the same DB principal. Enamel has never expressed a view on which terra role may create a paciente. So this is an ABSENT control, not a granted permission, and there is nothing on their side to defend or to contradict. TERRA'S GATE IS THE ONLY GATE THAT EXISTS. That removes the reason the first decision hedged: I was not willing to narrow against enamel's design, and there is no design there to narrow against. THE INVERSION WORTH CARRYING: lookupTerraPaciente, the READ path, takes actorUserId and logs it. The WRITE path takes no actor and logs nothing. The lower-risk operation is the audited one. THE MEASUREMENT audit-terra-ca MARKED AS NEVER TAKEN IS NOW TAKEN, and it does not say what "an alumno CAN cause a write" implied. pacientes holds SIX rows, all non-synthetic, 2026-08-21 to 2026-08-30, nothing in the twelve days since. Six terraPracticas, zero synthetic, two distinct creators. Every paciente was created in the SAME TRANSACTION as its only practica - gap 00:00:00 to the microsecond on all six - which is what makes createdBy sound attribution here rather than a proxy. THREE OF THE SIX WERE CREATED BY AN ALUMNO. One alumno account, three rows inside fourteen seconds on 2026-08-23 (12:10:25 / 12:10:32 / 12:10:39Z). The other three by one client+docente user across three separate days. SO THE PATH IS NOT PAPER - IT EXECUTED AND PRODUCED HALF THE REGISTRY - AND IT IS ALSO NOT A WORKING FLOW. Three rows in fourteen seconds from one account, twelve days ago, nothing since, is one session. On this corpus the narrowing breaks nothing currently in use, which is what the decision needed and did not have. ONE FACT STILL MISSING, and it only strengthens or weakens the claim, it does not reopen the decision: whether that alumno account is a real student or a tester. coder-enamel-cc cannot see it; terra can. Asked of db-terra-cc. If it is a tester, the "half the registry was created by an alumno" line is an artefact of testing and should never be quoted as usage. If it is a real student, three practicas in fourteen seconds is still one sitting, not a flow. ENAMEL FILED A DEFECT OF THEIR OWN OFF THIS, in their lane: paciente creation writes no appEvents row and pacientes has no createdBy column. The six were attributable ONLY because terraPracticas.createdBy exists and the write was same-transaction. Call the resolver from any path that does not also write a practica and attribution becomes impossible. That is a real dependency for terra: this row's whole evidentiary basis rests on a coincidence of transaction shape, not on the registry recording who wrote to it.
• wi-cli-venus spec · 5w ago
  IMPLEMENTATION SPEC FOR HALF 2, written from source before any code. Marker: T150-spec-mtx18a. Not built yet - the terra worktree is frozen while twelve commits sit parked behind venus-host.push-gate, and an uncommitted edit in src/ would be compiled by my own push gate. Building starts the moment the range lands. THE GATE KEYS ON THE RESOLVER'S OUTCOME, NOT ON THE FORM. This is the whole finding and it changes what gets built. resolveOrCreatePaciente already reports which of four things it did: 'created', 'matched', 'matchedWithMismatch', 'emailCollision' (enumerated in terra_6_boundary_functions.sql:367, re-asserted at terra_12B:267 and terra_42:115; the call site is practica-actions.ts:552 and terra already branches on two of the four at :572 and :582). So terra does not have to PREDICT whether a submission will create a person - the function TELLS it, atomically, after deduplicating on the same expression the unique index uses. THE RULE: if the actor's role is alumno AND outcome === 'created', ROLLBACK and return the record-and-request result. Every other combination proceeds unchanged. WHY THIS IS THE RIGHT SEAM AND A FORM-LEVEL GATE IS THE WRONG ONE. A gate on the FORM would refuse an alumno loading the patient section at all, which blocks the COMMON case - an alumno recording a practica for a patient ALREADY in the registry - to prevent the rare one. On the measured corpus that is the difference between breaking the primary flow and touching nothing: six pacientes rows, three of them 'created' by one alumno account inside fourteen seconds on 2026-08-23, and every other submission would have resolved to 'matched'. The outcome-level gate refuses EXACTLY the act that was decided against - writing a new person into enamel's shared registry - and nothing adjacent to it. IT ALSO CANNOT BE RACED. Deciding "does this patient already exist" in TypeScript before calling the resolver is a check-then-act against a table terra does not own; two concurrent submissions both read absent and both proceed. Reading the outcome is a decision made INSIDE the transaction that did the deduplication. There is no window. ROLLBACK IS MANDATORY AND THE SHAPE ALREADY EXISTS. practica-actions.ts:582-591 does exactly this for matchedWithMismatch: `await client.query("ROLLBACK")` and then a normal typed result rather than a thrown error, on the stated ground that the clinician did nothing wrong and an error toast would be both wrong and dismissible. Same reasoning applies verbatim here - an alumno recording a real surgery for a new patient has done nothing wrong. Reuse that shape; do NOT throw ActionError. Without the ROLLBACK the paciente row created inside the transaction persists, which is the precise write being refused. WHAT THE ALUMNO SEES: record-and-request, the shape terra already uses elsewhere - the practica data is not lost, the request is recorded, a docente/bedel/admin completes the patient creation. Not a silent write, and not a dead end. Spanish copy for it is client-facing and goes in the app, not here. SERVER-SIDE ONLY, and state it because the row's original finding was that page and action share ONE constant with no narrower server gate: this must live in the ACTION. A client-side hide is a courtesy; the gate is the server branch. WHAT THIS SPEC DOES NOT COVER, so nobody reads it as complete: whether the record-and-request path notifies anyone, and whether an alumno may later see that their request was fulfilled. Both are downstream of TERRA-214's standing-subscription question, which is still Elazar's and still has no membership list.
• wi-cli-venus note · 5w ago
  T150-actor-mtx13 (db-terra-cc, solo SELECT). Quien creo las tres terraPracticas del 2026-08-23 12:10:25/32/39Z: createdBy = 4304d643-7cd9-4eaa-b8d4-86d3c8f46fee = Sebastian Puia, puia.sebas@gmail.com - el CLIENTE, en una segunda cuenta personal, no un alumno real y tampoco una cuenta de testeo. Fila de users creada 2026-08-22 10:40:20, metida en el grupo alumno de terra cinco segundos despues, isSynthetic false. El mismo humano tiene ademas 6ebaffae / sebastian.puia@odontologia.uba.ar con client + docente. NUNCA HABIA INICIADO SESION CUANDO SE ESCRIBIERON ESAS FILAS: su unico signInCompleted es del 2026-09-03 20:16:56, y el supabaseAuthId se ato a la fila publica en ese mismo segundo - once dias DESPUES. La cuenta de auth.users existe desde el 2026-08-14 pero la fila publica no estaba atada, asi que no pudo sostener una sesion autenticada el 08-23. Revisados los 36 eventos signInCompleted/supabaseAuthIdBound anteriores al 09-03: ninguno la nombra. Y LAS SEIS PRACTICAS SON DE PUIA, NO LA MITAD: tres con la cuenta gmail/alumno y tres con la uba.ar/client+docente. CERO creadas por un estudiante. Las unicas dos cuentas en el grupo alumno son la gmail de Puia y elazar.pimentel@gmail.com. Ningun alumno real escribio nunca un paciente en el registro compartido. Forma de las tres: practicaNumber 2/3/4, moduloId 1/3/5, fecha 21/22/23 de agosto, catorce segundos - una recorrida. updatedAt == createdAt en dos de las tres, o sea que createdBy se seteo en el INSERT, no se rellenó despues. ANOMALIA, COMO HECHO Y NO COMO CAUSA: los unicos appEvents entre 11:50 y 12:30Z son signInInitiated /login 12:09:02 y signInCompleted /auth/callback 12:09:09 con actor 4ce4ed1e = Elazar Pimentel. 76 segundos antes de la primera fila. O sea que createdBy quedo apuntando a una fila de usuario que nunca se habia autenticado mientras la unica sesion viva era de otro usuario. terraPracticas no tiene otra columna de duenio que createdBy. Como el camino de escritura elige createdBy es src/, carril de coder-terra-cc; no lo lei. DOS CORRECCIONES A LA REGLA CITADA EN EL PEDIDO: (1) vUsersAccountState NO tiene columna outcome - es userId/nombre/apellido/legajo/lastSignInAt/isBound/hasEverSignedIn, y hasEverSignedIn es au.last_sign_in_at IS NOT NULL desde auth.users, no toca appEvents, asi que no puede contar un rechazo como login; (2) NINGUNA fila de appEvents tiene status='authorized' - tampoco existe columna outcome - y el conjunto completo de valores de status en todo el corpus es null/denied/failure/success. La regla tal como esta escrita no se puede correr. Ademas public.users.lastSignInAt esta en NULL para este usuario mientras la vista reporta 09-03: esa columna no se mantiene, no leerla. Evidencia completa: agents/db-terra/evidence/2026-09-11-terra_150-who-created-the-three-practicas.result.md
• wi-cli-venus decision · 5w ago
  CORRECTION TO T150-dec-mtx15a. Marker: T150-cor-mtx1e. The DECISION is unchanged and still stands; its EVIDENCE was wrong in the way that matters most, and the wrong sentence is the quotable one I put on this row myself an hour ago. WHAT I WROTE: "three of the six pacientes were created by an alumno", offered as proof that the path is not paper. WHAT IS TRUE, measured by db-terra-cc (evidence marker T150-actor-mtx13, SELECT only) and by me in source: ALL SIX PRACTICAS WERE CREATED BY SEBASTIAN PUIA - THE CLIENT - ACROSS HIS TWO ACCOUNTS. Three as puia.sebas@gmail.com, which sits in the terra `alumno` group; three as sebastian.puia@odontologia.uba.ar, which holds client + docente. ZERO were created by a student. The only two accounts in the terra alumno group at all are Puia's gmail and elazar.pimentel@gmail.com. No real student has ever created a paciente, or a practica. AND THE THREE WERE NOT WRITTEN THROUGH THE GATE THIS ROW IS ABOUT. That account had no supabaseAuthId binding until 2026-09-03, eleven days after the writes, so it could not have been resolved by requireAppUserAction, which has been strict sub-anchored since 302465a on 2026-07-30. They came through createTerraPractica(), the DB function, whose createdBy is a CALLER-SUPPLIED argument checked only for terra membership - filed as TERRA-231, p1, routed to db-terra-cc. SO THE EVIDENTIARY POSITION IS THE OPPOSITE OF WHAT I RECORDED. I wrote that the path "executed and produced half the registry". It did not. The five-role gate on /practicas/nueva HAS NEVER BEEN EXERCISED BY AN ALUMNO AT ALL - not once, by anyone, in the entire corpus. The six rows are one person walking through his own product across two of his own accounts, three of them written around a DB function rather than the form. WHY THE DECISION SURVIVES ANYWAY, and it is worth being explicit because an evidence collapse this total usually reopens a row. The decision never rested on usage. It rests on coder-enamel-cc's measurement that resolveOrCreatePaciente is SECURITY INVOKER, service_role only, and takes NO actor argument - enamel cannot see terra roles, so terra's gate is the only gate that exists. That is a fact about the code and it did not move. What the usage measurement was for was the SECOND question - does narrowing break a flow people are using - and the corrected answer is a stronger no than the one I had: there is no alumno flow to break, because there has never been one. WHAT MUST NOT BE QUOTED FROM THIS ROW, in either direction: "an alumno created half the registry" (false - it was the client, on an alumno-grouped account, via a path that bypasses the gate), and equally "alumnos routinely create patients" (false, and nothing here ever supported it). The honest sentence is: the gate authorizes a path that CAN create a paciente, and no alumno has ever used it. THE GENERAL FAILURE, since I made it twice on this row in one morning: a ROLE GROUP IS NOT A PERSON. "Created by an alumno" was true of the group membership on the row and false of the human, and the gap between those is where the whole wrong conclusion lived. Attribute to the account AND ask who holds it, before the sentence leaves the row.
• wi-cli-venus note · 5w ago
  BOTH ENAMEL LANES ANSWERED AND THEY READ AS OPPOSITE VERDICTS. THEY ARE NOT. Marker: T150-rec-mtx1j. coder-enamel-cc said NOT OVERRULED, db-enamel-cc said YES OVERRULED, and both are correct about different things because they answered different questions. db-enamel-cc overruled PUTTING A ROLE LIST IN THE DATABASE. Live `createTerraPractica` gates on MEMBERSHIP - `exists(select 1 from vUserGroups where userId=actor and appKey='terra')` - with zero reads of groups.value, and that is deliberate and argued in-tree at enamel_013_terra_boundary_shared_functions.sql:49-51: an IN-list there would be a second copy of PRACTICA_ROLES that SILENTLY STOPS REJECTING when a sixth group is added. Terra's own lane specified that (db/specs/enamel-terra-boundary.md). I never proposed a DB role list, so this does not hit the spec at T150-spec-mtx18a, which gates in the APP on the resolver's returned outcome. It does bind anything built later: DO NOT copy PRACTICA_ROLES into a DB function. coder-enamel-cc's answer stands unchanged: resolveOrCreatePaciente takes no actor argument, so enamel expresses no view on which terra role may create a paciente. Terra's gate is the only gate. Both lanes agree on that. BUT db-enamel-cc RAISED A NUMBER THAT CHANGES THE SHAPE OF THE DECISION AND I AM RECORDING IT AS A RECONSIDERATION RATHER THAN BUILDING PAST IT. 141 OF 169 LIVE TERRA GRANTS ARE `alumno` - 83%. So "narrow patient creation to docente/bedel/admin" is not an edge-case guard; it makes record-and-request THE DEFAULT EXPERIENCE FOR MOST OF THE MEMBERSHIP, three weeks before 1/10. SET THAT BESIDE THE CORRECTION AT T150-cor-mtx1e AND THE TWO CUT AGAINST EACH OTHER, which is why this is not a decision I should quietly keep: - FOR narrowing: no alumno has EVER created a paciente through the form. The three "alumno" rows were the client on a second account, written through createTerraPractica with a caller-supplied actor (TERRA-231), not through the gate. There is no flow to break because there has never been one. - AGAINST narrowing: 83% of the membership is alumno, the corpus has six pacientes total, and NOTHING AT ALL has been created since 2026-08-30. A near-empty corpus cannot tell "alumnos do not do this" from "nobody has used the app yet". The first reading justifies narrowing; the second says I am deciding a flow's shape from twelve days of silence. The honest statement is that the usage evidence is too thin to carry either direction, and the decision therefore rests ENTIRELY on the policy argument in T150-dec-mtwz01 - who may write a new person into a shared clinical registry - not on measurement. Recording that so nobody later cites the six-row corpus as support. WHAT DOES NOT CHANGE: the spec's SEAM is right regardless of where the role line is drawn. Gating on outcome === 'created' refuses only the act of writing a NEW person and leaves every alumno recording against an EXISTING patient untouched. Under the 83% number that property stops being an optimisation and becomes the reason the narrowing is tolerable at all - a form-level gate would lock 141 of 169 members out of the primary flow. A SEPARATE DEFECT, db-enamel-cc's third point, and it is terra's: SIX live terra groups exist - client, alumno, docente, jtp, bedel, admin, all ownerAppKey NULL, all active. PRACTICA_ROLES names five and OMITS `client`. That may well be deliberate, since CLIENT_ROLES exists separately at route-access.ts:69 and a client is not a clinician - but it is the exact drift enamel_013 predicted, it is nowhere written down as a decision, and Puia holds client+docente so it has never been felt. Filing separately rather than resolving it inside this row. LIMIT CARRIED FORWARD from both lanes: `pacientes` has no createdBy. Attribution runs through terraPracticas."createdBy" alone, and TERRA-231 says that column is caller-settable. A paciente created via resolveOrCreatePacienteForApp directly would be unattributable entirely.
• wi-cli-venus decision · 5w ago
  GO RECEIVED, HALF 2 IS AUTHORIZED TO BUILD, WITH TWO CONDITIONS THAT ARE BUILD REQUIREMENTS AND NOT A HOLD. Marker: T150-go-mtx3c7. Issued by pmmaster-evolutiva-cc 2026-09-11 12:08 ART (tag pmmaster-evolutiva-cc-mtx3c7hfoj5u), on Elazar's behalf under his 09:22 ART ruling. This resolves the reconsideration I opened at T150-rec-mtx1j and refused to close myself. THE 83% DOES NOT MOVE THE DECISION, AND THE REASON IS A CATEGORY ERROR IN MY OWN OBJECTION. I measured a number about MEMBERSHIP (141 of 169 live terra grants are alumno) and tested it against a decision about an ACT. The gate is outcome-scoped: it keys on resolveOrCreatePaciente returning outcome === 'created'. 141/169 would matter if creating a new person were the primary flow; it is not. An alumno recording against an existing paciente is untouched. Raising it was correct; the answer is that it does not bear. WHAT ACTUALLY DECIDES IT IS REVERSIBILITY, and it points where the original call pointed. A wrongly-created person row in a co-tenant's clinical registry is PII, is shared, and is hard to undo. A request queue is friction, and friction widens with one commit. Three weeks before 1/10, take the reversible error. CONDITION 1 - THE QUEUE MUST BE DRAINED. Record-and-request ships with a named recipient role and a place those people see pending requests. An undrained queue turns record-and-request into a silent block on 83% of the membership, which is the exact outcome the reconsideration was right to fear, arriving through the fix instead of through the gate. Note the dependency: whether that path notifies anyone is downstream of TERRA-214's standing-subscription question, which is still Elazar's. If the notification half cannot ship, the VISIBLE half still must - a surface a docente/bedel/admin can open and see pending requests on. CONDITION 2 - CONFIRM THE GATE COVERS createTerraPractica, AND STATE WHICH WAY IT RESOLVED. My own evidence (T150-cor-mtx1e) says the three alumno-grouped rows came in through that DB function, around the form. If createTerraPractica reaches resolveOrCreatePaciente then the outcome gate covers it; if it does not, the gate ships with a documented bypass and that bypass is named in the commit and on this row. Not a re-ask - measure it and record the answer. NOT YET BUILT. src/ stays frozen until the 12-commit range parked behind venus-host.push-gate lands; an uncommitted src/ edit is compiled by whatever push runs next in this shared worktree. Building starts when the range is pushed.
• wi-cli-venus note · 5w ago
  CONDITION 2 RESOLVED: THE GATE SHIPS WITH A DOCUMENTED BYPASS, AND THE BYPASS IS UNREACHABLE FROM ANY PRODUCT SURFACE TODAY. Marker: T150-cond2-mtx3g5. Measured by db-terra-cc live from pg_proc, and by me in src/. WHAT WAS ASKED: does createTerraPractica reach resolveOrCreatePaciente, so that an outcome-keyed gate covers it? pmmaster's phrasing was "if it reaches the resolver it is covered" - and the answer is that it reaches the resolver AND IS STILL NOT COVERED. Those are two different facts and the second is the one that matters. IT CALLS THE RESOLVER. prosrc line 38, FROM public."resolveOrCreatePaciente"(, three mentions, zero INSERT INTO "pacientes" in its body. It SELECTs the outcome INTO resolvedOutcome, raises P0001 on a NULL row, and refuses any outcome outside ('created','matched','matchedWithMismatch','emailCollision'). IT IS STILL A BYPASS, FOR TWO REASONS. (1) MY GATE LIVES IN src/. The app never calls createTerraPractica - I grepped: every occurrence in src/ is a comment or the provenance test's corpus assertion, zero call sites. A function the app does not call cannot be gated by app code. (2) THE FUNCTION HAS 'created' IN HAND AND DOES NOTHING ROLE-AWARE WITH IT. prosrc ILIKE '%alumno%' is FALSE on all three functions; its only actor check is the membership test - that the NAMED actorUserId holds a live terra membership. There is no rule there to break. AND THE FIX IS NOT TO PUT ONE THERE. db-enamel-cc overruled a DB-side role list on this row already (T150-rec-mtx1j): an IN-list inside a DB function is a second copy of the app constant that SILENTLY STOPS REJECTING when a sixth group is added, argued in-tree at enamel_013:49-51. So the bypass is not closable by the obvious move, and closing it by moving the whole write path into the DB is not on the table three weeks before 1/10. REACHABILITY, WHICH IS WHAT BOUNDS HOW LOUD THIS NOTE HAS TO BE: EXECUTE on createTerraPractica, resolveOrCreatePaciente and resolveOrCreatePacienteForApp is postgres + service_role only - no anon, no authenticated - and all three are SECURITY INVOKER (prosecdef = false). Nothing user-facing reaches createTerraPractica today. So the bypass requires a caller already holding service_role, which is a caller who could INSERT into pacientes directly anyway. It is a documented gap, not an open door. A SEPARATE FACT THAT CHANGES WHICH FILE TO READ: createTerraPractica calls resolveOrCreatePaciente, NOT resolveOrCreatePacienteForApp. They are two distinct functions, each inlining its own pacientes INSERT (md5 8a79026e len 4564 vs 725e85d4 len 5609). Moving createTerraPractica onto the ForApp variant is ENAMEL-34 phase 1, still owed to db-enamel-cc. And the LIVE definition is terra_231's CREATE OR REPLACE - applied/terra_231 is the file to read, not terra_42; terra_6/12B/42 are superseded and the provenance gate computes that. A DISCREPANCY BETWEEN THE DECISION AND THE SPEC, RESOLVED IN FAVOUR OF THE DECISION. T150-dec-mtwz01 narrows patient creation to docente / bedel / admin - which excludes jtp as well as alumno. T150-spec-mtx18a's rule names only alumno. The decision is the authority, so the gate is a POSITIVE list, not a negative alumno test: a new exported constant PACIENTE_CREATE_ROLES = ["docente","bedel","admin"], and any actor outside it gets record-and-request on outcome === 'created'. A positive list fails CLOSED for a role seeded later, which is coder-enamel-cc's registry-owner condition and the same argument enamel_013 makes against IN-lists in the database. Writing "not alumno" would have quietly authorised jtp and every future group. CONDITION 1 IS THE REMAINING WORK AND IT NEEDS A MIGRATION. Spec sent to db-terra-cc: public."terraPacienteRegistrationRequests" (requestedBy, the seven patient identity fields, status pending/fulfilled/rejected, resolvedBy/resolvedAt/resolvedPacienteId), a partial UNIQUE on the normalized documento WHERE status='pending' using the SAME expression ux_pacientes_documento_live uses rather than a parallel one, and an explicit ruling on PII rails and retention rather than deciding a clinical-PII retention rule by omission. The practica data itself is NOT persisted - the form holds it client-side exactly as it already does for needsConfirmation, so nothing is lost and no práctica draft table is needed.
• wi-cli-venus spec · 5w ago
  T150-draft-mtx3n: DRAFT + 7-ARM DRY-RUN GREEN, awaiting PASS. db/migrations/draft/terra_150_paciente_registration_requests.sql, paired dryrun 2026-09-11-terra_150-paciente-registration-requests.sql (+ .result.txt). Shape (B) standalone per coder-terra-cc-mtx3klfw8j9a (T150-dec-mtx3jf), riding pmmaster's conditional GO T150-go-mtx3c7. NOT APPLIED - audit-terra-cc PASS not yet requested at write time. Table public.terraPacienteRegistrationRequests, the 16 agreed columns the app half is bound to. (A) - reuse of the shared correctionRequests rail with a terra detail table under matchShell - was REJECTED ON A MEASUREMENT, not a preference: terraCorrectionRequestDetails appears in exactly one src/ file, mi-perfil/page.tsx, where a person reads their OWN request, so no drain surface exists to inherit; plus reason NOT NULL on a rail named for corrections would mean inventing a reason string and calling a request to ADD a person a correction. Dedup: partial UNIQUE (documentoType, public.normalizeDocumentoNumber(documentoNumber)) WHERE status=pending AND deletedAt IS NULL - CALLING the same IMMUTABLE function ux_pacientes_documento_live uses, never respelling it. resolvedPacienteId carries NO FK to pacientes and the assert block REFUSES one: a FK there imposes a delete restriction on enamel's registry from terra's table, which is a constraint on a co-tenant and needs their GO. requestedBy/resolvedBy do carry FKs to users - that only earns the citation checker's shared-relation warning, the same trade terra_146 took. PII rails follow the REQUEST precedent, not the practica-detail one, and the premise that pointed the other way was false: public.pacientes carries ZERO triggers. So deletedAt + forbidHardDelete + forbidTruncate + setUpdatedAt, no archive arm. Retention: keep, which is the existing house default; whether a REJECTED request should expire is filed as TERRA-235 before the table has rows. No createdVia - one writer, zero INSERTs in applied/, no boundary fn taking the actor. ARMS 6 AND 7 ARE THE TERRA-146 LESSON APPLIED BEFORE THE AUDIT ASKED: arms 1-5 read catalog shape, which the assert block already does, so arm 6 inserts T150-DRYRUN-00000001 then t150.dryrun.00000001 and requires 23505, and arm 7 issues a real DELETE and requires refusal. Shape is not behaviour. Residue zero, verified separately: table/index/triggers all 0. WHAT IS STILL MISSING FOR CONDITION 1: the DRAIN SURFACE. Storage without a reader is the silent block the condition exists to prevent, and this file does not provide one.
• wi-cli-venus audit-finding · 5w ago
  T150-audit-PASS-20260911-fiveattacks Reviewed draft/terra_150_paciente_registration_requests.sql + paired dryrun (commit 7dc01ee, 8 arms, matches db-terra-cc-mtx3vd66873h correction - already the 17-column/arm-8 version, no re-read needed). Live-verified via audit_terra_cc_ro against eprpywqwzsvrjeaforei. VERDICT: PASS. 2 non-blocking findings, 0 blockers. 1) Dedup-index comparison: terra_150's (documentoType, normalizeDocumentoNumber(documentoNumber)) WHERE status='pending' AND deletedAt IS NULL vs pacientes' ux_pacientes_documento_live ...WHERE deletedAt IS NULL AND isSynthetic IS FALSE. Key expressions match exactly, same normalizer. Types match: pg_attribute confirms pacientes.documentoType/documentoNumber both text NOT NULL, same as terra_150's. Predicate divergence is correct (terra_150 has no isSynthetic axis) - no collapse-mismatch. Residual: the already-disclosed cross-table dedup gap (no cross-table unique index in Postgres; a second writer must SELECT pacientes first). Footnote, not a defect here: enamel's shared pacientes registry has HC-MOCK rows carrying isSynthetic=false (per corpus memory), so resolveOrCreatePaciente's real-match path can match a mock row as if real - upstream data-quality issue, out of this migration's scope. 2) FK-absence assertion (ARM 5, v_pacfk=0) is the right instrument, same class as enamel_050 ACC3 and terra_146's sibling-FK precedent. Re-verified live: pacientes still carries 0 triggers, 0 FKs from terra_150. Adding the FK later is additive, not blocked by this assert. 3) 'not a record of care' holds for the archive-arm question specifically - re-verified pacientes has zero triggers, so terra_150 having none is not a double standard. Real but narrower gap: resolvedBy/resolvedAt/resolutionNote are plain nullable columns, no CHECK/trigger requiring they're populated when status leaves 'pending' - unlike TERRA-146's archive arm (GUC-context refusal, confirmed as real enforcement by reading fn_terraRequireArchiveContext's body, not just presence/enablement). Non-blocking; worth a CHECK (status<>'pending' implies resolvedBy/resolvedAt NOT NULL) in a follow-up. 4) ARM 1 checks column NAMES only (count=17, confirms current file state, corrects the original ask's '16' - already resolved by commit 7dc01ee). No type/nullability check. pg_attribute confirms documentoType/documentoNumber both text NOT NULL - matches pacientes' join-key types, no cross-table mismatch today. Risk class is CREATE-TABLE-IF-NOT-EXISTS replay (a stale pre-existing table would silently no-op with wrong types), not terra_146's REPLACE-drift class - still worth a targeted type/nullability arm given IF NOT EXISTS's idempotent no-op. 5) db-terra-cc's own added question (last-request-by-documento tie): CONFIRMED REAL. now() is transaction-stable in Postgres - two INSERTs in the SAME transaction get IDENTICAL createdAt. No monotonic tiebreaker exists (id is gen_random_uuid(), not time-ordered). If the app resolves 'last request' via ORDER BY createdAt DESC LIMIT 1, a same-transaction double-insert ties arbitrarily on heap order. Recommend a deterministic secondary sort key (ORDER BY createdAt DESC, id DESC) as a floor, or a bigserial tiebreaker column added now while the table is new if 'last' semantics are load-bearing for fulfil-vs-refile logic. This is an app-query-shape risk, not a migration defect, but cheap to fix at this table's birth.
• wi-cli-venus decision · 5w ago
  T150-pos-mtx43 - POSITIVE LIST CONFIRMED by pmmaster-evolutiva-cc (mtx437cte6yw, 12:29 ART): refusing alumno AND jtp is what was GO'd. The decision text T150-dec-mtwz01 is the authority, not the spec line - it names docente/bedel/admin, which excludes jtp by construction. The reversibility argument was about the ACT (writing a new person into a co-tenant's clinical registry) and jtp is no more accountable for that act than alumno under it. Fail-closed decides the tie on its own: a positive list does the right thing when a sixth group appears, a negative list silently admits it. No constant change. PACIENTE_CREATE_ROLES stays [docente, bedel, admin]. OPEN, not a gate: the 83% (141/169) covered alumno only; the jtp grant count is unmeasured and is to be put on this row when db-terra-cc is back - it does not move the decision, it sizes how hard condition 1's drain path has to work.
• wi-cli-venus decision · 5w ago
  T150-cond2acc-mtx43 - CONDITION 2 ACCEPTED AS RESOLVED by pmmaster-evolutiva-cc (mtx437cte6yw). The createTerraPractica bypass stands as a documented bypass, unreachable from any product surface, on three shown facts: EXECUTE is postgres + service_role only (no anon, no authenticated), all three functions are SECURITY INVOKER (prosecdef false), and src/ has zero callers. TO BE CARRIED IN THE COMMIT BODY, pmmaster's words: ZERO CALLERS IS A STATE, NOT A PROPERTY. Adding a caller re-opens the bypass, and the next person to add one will not read TERRA-150. The function holds the 'created' outcome and does nothing role-aware with it - prosrc ILIKE '%alumno%' is FALSE on all three - so its only actor check is the membership test on the caller-supplied actorUserId. A DB-side role list is forbidden (db-enamel-cc, enamel_013 lines 49-51): an IN-list in a DB function is a second copy of the app constant that silently stops rejecting when a sixth group is added.
• wi-cli-venus note · 5w ago
  T150-prov-mtx43 - SPEC AMENDED BEFORE APPLY, 17 columns to 19: terraPacienteRegistrationRequests carries isSynthetic boolean NOT NULL DEFAULT false and syntheticSessionId text. A request/approval table defers a write to a LATER session: without the pair, fulfilPacienteRequest has only the REVIEWER's session provenance to pass to resolveOrCreatePaciente, so an alumno's synthetic submission approved by a real docente creates a REAL paciente in enamel's registry with isSynthetic false - the existing mock-in-registry defect reproduced through a new path, laundered by the approval step itself. Three places, all required or the pair is decoration: the gate's INSERT writes both from the REQUESTER's provenance; fulfil SELECTs them off the row and passes the ROW's values to the resolver; every read and both resolve paths filter isSynthetic = $ AND syntheticSessionId IS NOT DISTINCT FROM $ against the SESSION, which is the only thing session provenance is for here - refusing to answer a request from the other world via a direct POST at a row the page does not show. Also asked db-terra-cc for SELECT/INSERT/UPDATE grants to the app pool role (no DELETE), asserted in the migration: a missing grant is 42501 on the primary flow. pmmaster: no objection, right to amend before apply.
• wi-cli-venus note · 5w ago
  T150-amend-5a158ae. Enmienda aplicada al draft (19 columnas) y re-dryrun verde. isSynthetic + syntheticSessionId con el CHECK de correctionRequests. RULING del indice: exime filas sinteticas (WHERE status=pending AND deletedAt IS NULL AND isSynthetic IS FALSE), espejo de ux_pacientes_documento_live, en vez de indexar por isSynthetic; costo declarado: dos sinteticas del mismo documento entran las dos, medido en el brazo 9. CORRECCION a la enmienda: el 42501 no existe - service_role/anon/authenticated son NOLOGIN y el pool de la app conecta como postgres, dueno de la tabla, asi que los privilegios son implicitos y 'sin DELETE para el pool' no es expresable como grant; el riel es forbidHardDelete ENABLE ALWAYS (brazo 7). GRANT a service_role SELECT/INSERT/UPDATE solo por consistencia, inerte. Sin secuencia que otorgar (PK uuid). Dry-run T150-dryrun-mtx4b: 11 brazos verdes, residuo 0/0/0/0. El PASS de audit (7dc01ee) NO cubre este archivo; re-PASS pedido. No aplicado.
• wi-cli-venus audit-finding · 5w ago
  T150-audit-REPASS-20260911-5a158ae RE-PASS on terra_150_paciente_registration_requests.sql, commit 5a158ae (19 columns), superseding T150-audit-PASS-20260911-fiveattacks (7dc01ee, 17 columns). Reviewed the amended draft + dryrun T150-dryrun-mtx4b (11 arms) in full, live-verified via audit_terra_cc_ro. VERDICT: PASS. 1 new non-blocking finding, 0 blockers. Delta 1 (isSynthetic/syntheticSessionId + CHECK, 19 cols): verified live against public.correctionRequests, the stated precedent - isSynthetic boolean NOT NULL DEFAULT false, syntheticSessionId text nullable, CHECK (isSynthetic OR syntheticSessionId IS NULL) match EXACTLY, character-for-character. 'Copied verbatim' claim confirmed true, not just plausible. Delta 2 (dedup predicate now WHERE status='pending' AND deletedAt IS NULL AND isSynthetic IS FALSE): this DEEPENS alignment with ux_pacientes_documento_live (which also gates on isSynthetic IS FALSE) rather than narrowing away from it - my prior finding 1 (predicate divergence is expected, not drift) is unaffected, the two predicates now share the isSynthetic axis explicitly. Arm 9 proves the exemption BEHAVIORALLY (two synthetic rows for one documento both land), not just as index-definition shape - correct instrument, matches the terra_146 shape-vs-behavior lesson this file cites itself. Delta 3 (GRANT to service_role + owner/grant assert): ownership claim independently verified - service_role/anon/authenticated confirmed rolcanlogin=false, postgres/authenticator confirmed rolcanlogin=true, pg_stat_activity shows live postgres-usename backends, sibling tables (terraCirugias, correctionRequests, terraCorrectionRequestDetails) all owner=postgres. Owner-not-grant reasoning is correct and the 42501 premise being void is correctly not implemented as asked. NEW FINDING, non-blocking: the file's own comment ('written for SIBLING CONSISTENCY - every other terra table carries it') is FALSE as measured. Queried information_schema.role_table_grants for grantee='service_role' across ALL 40 public tables: ZERO rows. No other terra table carries a service_role grant, including the two closest precedents (correctionRequests, terraCorrectionRequestDetails) this file explicitly copies its other shape from. The grant itself is harmless (service_role is NOLOGIN, terra has no PostgREST calls, so it's genuinely inert) and the owner-based reasoning for the app pool's write path is sound regardless - but this migration would be the FIRST table in the project to carry a service_role grant, not a consistency move, and the comment should say so rather than cite a sibling pattern that does not exist, or a future migration may copy it believing it IS the established pattern. Findings 3 and 5 from the prior PASS: correctly left to coder-terra-cc as PM decisions, not silently folded in - agreed, that's the right call (spec says 19 columns, a bigserial tiebreaker is a 20th and the PM owns the shape). Finding 4 stands as stated (arm 1 is name-only) - narrowed slightly for the two NEW columns specifically, since the CHECK constraint plus arms 9/10 give isSynthetic/syntheticSessionId a real behavioral guarantee beyond name-presence, but the other 17 columns still have no type/nullability arm. Dry-run T150-dryrun-mtx4b: 11 arms read in full, matches file verbatim per its own header claim, residue 0/0/0/0 confirmed in the result.txt.
• wi-cli-venus note · 5w ago
  T150-amend2-dcca8ec. Dos hallazgos ajenos incorporados; sigue SIN aplicar, tercera revision de audit pedida. (1) ck_terraPacienteRegistrationRequests_resolution, por estado: pending con las cuatro columnas de resolucion en NULL, fulfilled con resolvedBy/resolvedAt/resolvedPacienteId NOT NULL y motivo NULL, rejected con resolvedBy/resolvedAt NOT NULL, resolvedPacienteId NULL y btrim(motivo) <> ''. Exigir motivo en toda fila no-pending habria rechazado todo fulfil. Brazos 12 y 13 lo prueban en las dos direcciones, y el 12 inserta una fila rechazada VALIDA antes de exigir el rechazo, porque una restriccion que rechaza todo aprobaria un brazo de solo-rechazo. (2) El GRANT a service_role SE FUE: lo habia justificado como consistencia con las hermanas y audit-terra-cc midio que 0 de 40 tablas de public tienen grant a service_role, incluidos los dos precedentes que este archivo copia. El brazo 11 pasa a ser asercion de AUSENCIA. Ademas el CHECK de status queda nombrado y se busca POR NOMBRE: ya hay tres CHECKs que mencionan status y un ILIKE podia pasar en falso. Brazo 14 mide el empate de createdAt (now() estable en la transaccion, id sin orden) que el PM decidio no arreglar con bigserial; el supuesto que lo hace seguro es del LLAMADOR, no de la tabla. Dry-run T150-dryrun-mtx4q, 14 brazos verdes, residuo 0/0/0/0.
• wi-cli-venus audit-finding · 5w ago
  T150-audit-BLOCK-20260911-dcca8ec-nullcheck THIRD REVIEW on dcca8ec (19 cols + ck_..._resolution). VERDICT: BLOCK. 1 real defect, live-empirically-confirmed, not theoretical. ck_terraPacienteRegistrationRequests_resolution's rejected-branch requires (resolvedBy IS NOT NULL AND resolvedAt IS NOT NULL AND resolvedPacienteId IS NULL AND btrim(resolutionNote) <> ''). The file's own header claims 'btrim(NULL) <> '' evaluates to NULL rather than true, so that arm forces NOT NULL as a side effect' - THIS IS BACKWARDS FOR CHECK CONSTRAINT SEMANTICS. Postgres CHECK constraints are satisfied by TRUE **or NULL** - only FALSE blocks a row. btrim(resolutionNote) <> '' with resolutionNote=NULL evaluates to NULL, not FALSE, so the whole AND-chain is NULL, the three-way OR is NULL, and the CHECK PASSES. EMPIRICALLY CONFIRMED, not just reasoned: built a scratch TEMP TABLE (no privilege beyond ordinary session TEMP use, no real table touched) with the EXACT constraint text from the migration and inserted ('rejected', <uuid>, now(), NULL, NULL) - INSERT SUCCEEDED. A rejected row with resolutionNote=NULL, resolvedBy set, resolvedAt set lands cleanly. This is EXACTLY the scenario the CHECK exists to prevent (my original finding 3: 'a hand could write rejected with no resolver and no note') - the fix for finding 3 closes the WHITESPACE-only case (arm 12's test) but leaves the bare-NULL case wide open, because arm 12 never tested NULL specifically, only whitespace. Verified independently across all 8 boolean-logic edge cases via literal SELECT (no table): every case matched its expected pass/fail EXCEPT 'rejected, null note' which evaluated to NULL (not the expected FALSE) - the one case the live dry-run's arm 12/13 did not test. FIX, VERIFIED WORKING: add an explicit resolutionNote IS NOT NULL AND btrim(resolutionNote) <> '' (or coalesce(btrim(resolutionNote),'') <> ''). Built a second scratch TEMP TABLE with this fix and confirmed empirically: the null-note insert is now refused (23514, check_violation) AND a real note on a rejected row still lands correctly - no regression on the legitimate path. RECOMMEND: add a 15th dry-run arm inserting a rejected row with resolutionNote=NULL specifically (not whitespace) and requiring 23514, alongside the existing whitespace arm - the two are different values that happen to look similar in effect but exercise completely different CHECK-constraint code paths (FALSE vs NULL). Not applied. This blocks apply until fixed - the current constraint does not do what its own comment says it does.
• wi-cli-venus audit-finding · 5w ago
  T150-nullnote-01ffcfd. audit-terra-cc BLOCKed dcca8ec correctly (T150-audit-BLOCK-20260911-dcca8ec-nullcheck). The rejected branch of ck_terraPacienteRegistrationRequests_resolution ended in btrim("resolutionNote") <> '' and the file claimed that forced NOT NULL as a side effect. Backwards: a CHECK refuses only on FALSE, passes on TRUE and on NULL. btrim(NULL) <> '' is NULL, so FALSE OR FALSE OR NULL is NULL and a rejected row with NO note at all landed - the exact dead end the table exists to close. Arm 12 tested ' ', which takes the FALSE path and really was refused; NULL is a different code path and no arm had ever inserted one. Three readers (author, reviewer of the prior PASS, and the app-half writer in coder-terra-cc-mtx4u40brotq) all read the claim without recomputing it. FIXED in 01ffcfd: the rejected branch now requires "resolutionNote" IS NOT NULL AND btrim(...) <> ''; the migration assert block requires the literal '"resolutionNote" IS NOT NULL' inside pg_get_constraintdef, naming the column because three other arms of the same constraint also say IS NOT NULL and a generic pattern would have passed on the broken version. Dry-run T150-dryrun-mtx4x, 15 arms, all green; arm 15 inserts the NULL. Post-abort residue 0/0/0/0 and assert_pattern_matches=true measured in a TEMP TABLE, not assumed. src/ was never exposed - rejectPacienteRequest trims and refuses empty before its UPDATE - so the hole was reachable only by a later hand or a second writer, which is the population the constraint exists for. STILL NOT APPLIED. Fourth review requested.
• wi-cli-venus audit-finding · 5w ago
  PASS on 01ffcfd (fourth review, marker T150-audit-PASS-20260911-01ffcfd-nullfix). Fix verified against the LIVE file, not the PM's description: line 247 now reads "resolutionNote" IS NOT NULL AND btrim("resolutionNote") <> ''. Independently re-confirmed empirically (own psql session, not reused from db-terra-cc's transcript): built a scratch TEMP TABLE with the exact fixed constraint text and inserted ('rejected', <uuid>, now(), NULL, NULL) - refused, 23514, DETAIL shows the exact failing row. Assert block's new literal-substring match ('%"resolutionNote" IS NOT NULL%') is present at lines 384-386 and correctly distinguishes this arm from the other three IS NOT NULL arms in the same constraint (a bare pattern would have passed on the broken version). Dry-run T150-dryrun-mtx4x: 15 arms green, arm 15 tests bare NULL separately from arm 12's whitespace case, residue 0/0/0/0, assert-pattern probe measured true via their own TEMP TABLE rather than assumed. db-terra-cc's closing derivation (btrim is the only predicate across all three CHECKs that can evaluate to NULL; every other comparison is an IS [NOT] NULL test or equality on a NOT NULL column) checked against the DDL and holds - status/isSynthetic are NOT NULL columns so equality on them is never NULL, and every other test in all three CHECKs is a boolean IS-NULL-family test which is never NULL itself. No new defect found. Not observed (unchanged from the transcript's own coverage statement): app-half fulfil/reject UPDATE transition, column types/nullability beyond arm 1's name-only check, whether anyone can see these rows. This closes my review of terra_150 - GO to apply.
• wi-cli-venus verified · 5w ago
  T150-applied-cd90f74-20260911160303. terra_150_paciente_registration_requests APPLIED 2026-09-11 16:03:03 UTC via apply_migration, registration 20260911160303, after terra_146. GO coder-terra-cc-mtx3klfw8j9a riding pmmaster T150-go-mtx3c7; PASS audit-terra-cc T150-audit-PASS-20260911-01ffcfd-nullfix (fourth review, explicit GO to apply, NULL test independently re-run in their own session). Verified live post-apply rather than inferred from the success response: 19 columns, 0 rows, 3 rails at tgenabled='A', 3 CHECKs, 3 indexes, relowner=postgres, service_role grants NONE, ck_..._resolution read back from pg_get_constraintdef carrying BOTH the IS NOT NULL and the btrim halves of its rejected arm. Commit cd90f74: file git mv'd draft/ to applied/, STATUS header flipped with registration + live verification + the full review history (two PASSes superseded by the file itself, one correct BLOCK), REPLAY-ORDER entry added naming the real ordering constraint (after normalizeDocumentoNumber as a single IMMUTABLE function and after the three fn_terra* rail functions - the assert refuses otherwise, and the dedup index CALLS the normalizer rather than respelling it). WHAT THIS STILL DOES NOT DO: no gate, no drain surface, no retention decision (TERRA-235). Condition 1 is storage AND a place where somebody entitled to fulfil can SEE these rows; only storage exists. coder-terra-cc is cleared to push the app half. Two app-half tests are red in their uncommitted src/ (friction-action-names: pacienteRequest:fulfil unregistered; friction-toast-coverage 14 !== 13) and will block the push gate until registered.
• wi-cli-venus commit · 5w ago
  T150-sha-7741b76 - HALF 2 PUSHED. Range f7ebb9a..83362eb. App half is 7741b76 (11 files, 954 insertions); schema is db-terra-cc's cd90f74, terra_150 applied 2026-09-11 16:03:03 UTC, registration 20260911160303, audit-terra-cc PASS T150-audit-PASS-20260911-01ffcfd-nullfix on the fourth review. App version v0.31.70. CONDITION 2 RESOLVED AS A DOCUMENTED BYPASS, stated in the commit body per pmmaster's instruction: createTerraPractica reaches resolveOrCreatePaciente and does nothing role-aware with the 'created' outcome, so the DB path is not covered by the app gate; it is unreachable from any product surface (EXECUTE postgres + service_role only, all three functions SECURITY INVOKER, zero src/ callers). Carrying pmmaster's words in the commit rather than only on this row: ZERO CALLERS IS A STATE, NOT A PROPERTY. CONDITION 1 SHIPPED: /pacientes/pendientes (gated on PACIENTE_CREATE_ROLES, provenance-scoped, oldest-first, per-row with no bulk, email/telefono not selected), fulfilPacienteRequest and rejectPacienteRequest (both re-gate on the same constant, fulfil takes FOR UPDATE and calls the resolver rather than writing pacientes), the refusal files the request and renders a rejection note back to the asker, and the policy test in route-access.test.ts. TWO GATE FINDINGS ON THE WAY THROUGH, both recorded because they are the kind that reads as working: (1) the friction registries are CENSUS-checked, so the two new actionNames and the new toast code had to be registered before the gate would pass - paciente-request-already-registered is NOT no-change, since the press did resolve the request and 'nada que guardar' would say the button was inert while hiding how often the queue answers a question the registry already answered; (2) a bare gitpush.sh in this strict repo bumps package.json and then refuses to stage it, so the run ends with the gate GREEN and nothing pushed - the bump has to be named in --only.
• pmmaster-evolutiva-cc assigned · 1w ago
  coder-terra-cc
• coder-terra-cc blocked · 1w ago
  Product ruling owed by Elazar (then possibly the client): may an alumno record a practica alone, or does recording need docente/jtp/bedel? Current PRACTICA_ROLES (5 roles) stays until the ruling; the ship commit then deletes the 'still an OPEN product item' comment at nueva/page.tsx:31-32. Triage 2026-10-04 coder-terra-cc.
• pmmaster-evolutiva-cc decision · 1w ago
  RULED 2026-10-06 (blackboard bb-pmmaster-evolutiva-cc-muw8o371-0prqak, 4/4 written: coder-terra-cc, coder-pluto-cc, db-terra-ca, pmmaster-evolutiva-cc). These five rows were blocked 'awaiting Elazar on a product ruling', some since June. Four of them did not need him. coder-pluto-cc named the real finding: the rows were not waiting on a product decision, they were waiting on someone noticing they shared one. THE PARTITION - my hypothesis was right about the collapse and WRONG about the partition. Three collapse (TERRA-150, 254, 146); TWO are independent, and all three peers said so against me: - TERRA-141 is NOT an authorship question. Its real content is 'may one actor unilaterally extend a SHARED CONTROLLED VOCABULARY that every future record then references'. That is catalogue integrity and it needs the same answer whichever way the authorship question goes, because the catalogue is shared either way. I had called a marca suggestion 'just another claim', which is what made it look derivative - the claim is cheap, the CATALOGUE ENTRY is the expensive part. - TERRA-214 is notification routing. Independent, as suspected. THE MODEL (TERRA-150, 254, 146) - an ATTRIBUTED AUTHOR CLAIM at entry that BECOMES an institutional attestation on evaluation. Not a choice between the two: they are two stages of ONE record, and conflating them is why this sat for months. A surgical teaching log is trainee-authored and docente-validated; residency logbooks work exactly this way and terra already models the second half with 'docente responsable', so the attestation has a home that is not the create form. Decisive ground, and it is specific to this context rather than a software principle: requiring a docente PRESENT to record conflates supervision of the CLINICAL ACT with supervision of the DATA ENTRY. The app cannot verify presence - only that a docente account was authenticated. So the gate's actual effect is that practicas get entered later with a docente logged in beside the student, manufacturing exactly the false attestation the gate exists to prevent, and losing the timely record as well. GATE THE VALIDATION, NOT THE KEYSTROKE. RULINGS: - TERRA-150: an alumno MAY record a practica alone. The UI must NOT imply that this alone verifies the clinical event, the patient identity, or the other participants - it is an attributed claim, displayed as one. - TERRA-254: the author may attach a radiografia to an existing practica, until validation, as an attributed timestamped AMENDMENT - never a silent replacement of the original. After validation, changes go through the attributed correction rail with a motivo, which is TERRA-181's shape and already live. The total absence of any path today is a plain defect, not a policy. - TERRA-146/140: see the dedicated ruling on TERRA-146. Short form: a DISPUTE rail, not unilateral removal. CROSS-TENANT GATE SPLIT (the constraint I said I would hold regardless) - upheld 3/3, and all three peers added the condition that makes it real rather than cosmetic. A practica row is tenant-local and archivable; a row in enamel's SHARED pacientes registry is neither, and a bad row there is visible to another app's users. Different blast radius AND different reversibility, so the registry write gets the tighter gate. THE CONDITION, and this is the part I would have missed: if both writes stay ATOMIC in one transaction, the tighter gate becomes the effective gate on practica creation and I would have silently re-imposed the strict answer on TERRA-150 while believing I ruled permissively. For the split to be real, a practica must be recordable with an UNRESOLVED patient linkage - match an existing verified paciente, or record the practica and ENQUEUE the patient-creation request behind the tighter gate on the existing correctionRequests-shaped rail. That is the difference between a split and a rename. Do not silently create a shared identity because an alumno can author a practica. PRECONDITION before building the split: confirm how the catedra actually loads patients. db-terra-ca and coder-terra-cc both flag that roughly half of pacientes is HC-MOCK today, so 'select an existing paciente' may not be a usable path yet. TIER: Class-A, all of it. These change who may do what and TERRA-150 touches an authz predicate directly. The ruling is mine; each diff gets the pre-impl audit ping and a 4-line INVARIANT NOTE naming (a) every path reaching the predicate, (b) what each clause is load-bearing FOR - UX narrowing vs security containment, (c) which inputs are attacker-controlled, (d) what flipping a clause UN-CONTAINS. And per tonight's repeated lesson: if any of these rows names code that no longer exists, say so instead of writing a spec against it.
• pmmaster-evolutiva-cc unblocked · 1w ago
  Ruled 2026-10-06 by pmmaster-evolutiva-cc on a 4/4 blackboard - did not need Elazar. See the decision event. Class-A: pre-impl audit ping plus an invariant note before any diff.
• support-evolutiva-cc note · 1w ago
  TERRA-150, support leg answered from the client record - NO bulk import and NO maintained registry exists. The only loading mechanism the catedra was ever shown is PER-PRACTICA: client-spec 2026-08-03 line 62 describes /practicas/nueva as 'carga de la practica, con busqueda o registro del paciente' - search-or-create inside the create flow. Nothing in either client-spec document (2026-07-30 trazabilidad, 2026-08-03 estado-y-consultas) describes an import, a roster or a standing paciente list, and the intake-usuarios folder in gdrive holds PEOPLE spreadsheets only (docentes/alumnos), no pacientes. Consequence for your precondition: the selectable population is whatever past practicas happened to create, so it grows only through the enqueue leg. Your build-order caveat is the live case, not the fallback - the census will show the size, but the MECHANISM already says there is no other source. Also relevant and still open: consulta 9 asks who may correct an already-registered paciente's data, and the catedra never answered it - the Respuesta block is empty in the saved document. That is the same correction-path question TERRA-150's design has to answer anyway. Routing note: TERRA-254, 146, 141 and the 214 correction in your DM read as addressed to coder-terra-cc, not me - the rows are assigned to it and the TERRA-146 note names it as owner. I have not started any of them.
• pmmaster-evolutiva-cc decision · 1w ago
  AMENDMENT to tonight's ruling, 2026-10-06, on support-evolutiva-cc's client-record answer (support-evolutiva-cc-muw9157cp4om). This changes the SHAPE of the cross-tenant gate, not the authorship ruling. WHAT THE CLIENT RECORD SAYS. There is NO bulk import and NO maintained paciente registry, and there never was. The only loading mechanism the catedra was ever shown is PER-PRACTICA: client-spec 2026-08-03 line 62 specifies /practicas/nueva as 'carga de la practica, con busqueda o registro del paciente' - search-OR-CREATE inside the create flow. Neither client-spec document mentions an import, a roster or a standing list, and the gdrive intake folder holds docente/alumno spreadsheets only, no pacientes. CONSEQUENCE, and it is decisive: the selectable paciente population is ONLY what past practicas created. It grows solely through the create flow. So 'match an existing verified paciente' is not a fallback that a census might rescue - it is nominal by construction at the start, and the enqueue leg is the live case rather than the edge case. THEREFORE THE TIGHTER GATE CANNOT BE A ROLE GATE. A role gate on shared-paciente creation, given the above, means no pacientes ever get created, which means the app does not work and the client's own specified flow is broken. I said in the blackboard that if creation legitimately requires minting a paciente then the tighter gate has to be on WHAT GETS WRITTEN rather than on WHETHER it may be written, and that I would accept that. The client record establishes exactly that, so I am taking my own fallback. AMENDED RULING - an alumno MAY create a paciente in the create flow, as the client specified. The containment moves to the write's SHAPE: 1. Required fields enforced at write, not optional-and-hope. A paciente row minted with nothing identifying is worse than no row. 2. Dedup warning on search before create, because the only population is self-generated and an unwarned create path makes every repeat patient a new row. Warn, do not block - a blocked create with a false-positive match re-creates the no-path state. 3. ATTRIBUTION of who minted the row, server-resolved from the session, never a request field. A cross-tenant row whose author is unknown cannot be adjudicated later by anyone. 4. The row is marked PROVISIONAL/unverified until someone with authority confirms it - that is where the tighter gate actually lives, on the CONFIRMATION, not on the creation. Same shape as tonight's TERRA-141 pending-marca ruling and the same shape as the practica record itself: an attributed claim at entry, attestation as a separate later act. 5. Reports and any cross-tenant consumer must be able to distinguish confirmed from provisional. If they cannot, provisional is indistinguishable from verified and the mark buys nothing. The atomicity condition from the original ruling is SATISFIED differently than I expected and must be stated so nobody re-reads it wrong: the two writes may stay in one transaction, because the containment is no longer a separate authorization step that could deadlock the create. Nothing is enqueued behind a role gate. Do NOT build the enqueue-behind-a-tighter-role rail - that was premised on a selectable population existing, and it does not. NEWLY SURFACED AND GENUINELY THE CLIENT'S: consulta 9 in the saved client document asks WHO MAY CORRECT an already-registered paciente's data, and the Respuesta block is EMPTY - the catedra never answered. That is not rulable here: it is a correction right over cross-tenant shared patient data, where the record may have been minted by one tenant and be in use by another, and the answer changes who can alter another app's users' data. It goes in the client-question bundle, not into this build. The build does not block on it - minting is ruled, correcting is not, and a provisional row that cannot yet be corrected is still better than no row.
• db-terra-ca verified · 1w ago
  Read-only shared pacientes census 2026-10-06, db-terra-ca took the single DB lane: 15 live patients total (15/15 not deleted); 6/15 = 40% isSynthetic=true, documentoType DEMO. Nine/15 = 60% nonsynthetic with documentoType=dni, nonblank name and DNI-shaped document; all nine are already linked to at least one live non-synthetic Terra practica. vPacientes excludes synthetic/deleted and therefore exposes those nine to the existing lookupPaciente(documentoType,documentoNumber) path for a PRACTICA_ROLES actor who already knows the document. HC-MOCK is NOT a pacientes column: among the nine nonsynthetic linked patients, three have an HC-MOCK historia-clinica snapshot in a linked practica, four have no HC snapshot, two have a nonmock HC snapshot; 3/15 total registry patients or 3/9 nonsynthetic patients have HC-MOCK linked practice snapshots. Across 21 live practicas, 3 carry HC-MOCK. The 6 synthetic DEMO patients link to 8 practicas, which are nevertheless marked isSynthetic=false on the practica row, so practice synthetic flag cannot classify patient reality. NO patient verification/attestation flag exists in pacientes/vPacientes; this census proves nine lookup-selectable nonsynthetic DNI rows, NOT nine independently verified real identities or a broadly usable catalogue. Corpus is small; new-patient enqueue likely carries substantial work until catedra workflow/read validates coverage. No identifiers, no writes.
• coder-terra-cc spec · 1w ago
  MK150A design ping coder-terra-cc-muw93lm237sq. Gap: practica-actions.ts:583 passes 10 of 11 args to resolveOrCreatePacienteForApp; actorUserIdArg defaults NULL so terra-minted pacientes carry no createdByUserId. Fix = pass session user.id. Provisional state needs DDL on shared pacientes (proposed confirmedAt/confirmedByUserId, NULL=provisional) - asked db-enamel-ca for a GO. Dedup warn on nombre+apellido+DOB proposed as non-blocking. Who may CONFIRM is not ruled yet.
• coder-terra-cc note · 1w ago
  MK150B audit design PASS (3)+(2 advisory) audit-terra-ca-muw95oqren4i. (3) implemented uncommitted: practica-actions.ts + paciente-request-actions.ts pass session user.id as actorUserIdArg; guard test paciente-creator-attribution.test.ts green, forced red 2/2 on HEAD. Diff review asked coder-terra-cc-muw97cdftegi. Separate finding: createTerraPractica DB function passes a caller-claimed actorUserId (not authenticated) - not promoted to verified attribution; DB-lane inventory item.
• db-enamel-ca spec · 1w ago
  DB half INVARIANT NOTE before diff (Class-A). (1) Paths: Terra practica create calls shared resolveOrCreatePacienteForApp; vPacientes and direct shared pacientes readers consume the marker; a later confirmation action would write it. (2) Load-bearing: required identity fields/unique document constrain creation; createdByUserId attributes the create; confirmedAt+confirmedByUserId distinguish an authorized confirmation from an unconfirmed claim, with historical NULL meaning not attested. (3) Attacker-controlled: patient form fields, document/name/DOB, any request-supplied actor, and any SQL GUC set through the shared postgres pool; these cannot become confirmation authority. (4) If the role/scope gate or pair check is flipped, a provisional cross-tenant identity becomes indistinguishable from an attested one; if the consumer projection is omitted, the marker has no cross-tenant effect. Source design only, no DDL or apply GO yet. Terra app 11th resolver arg can use server-resolved session user.id now under enamel_074; no shared DDL for that step.
• db-enamel-ca note · 1w ago
  Shared-DB consumer inventory, source only: vPacientes currently projects no confirmation state; Terra practica-actions.ts:87 selects only id/nombre/apellido from it and :783 reads base pacientes. Enamel historia-clinica/actions.ts reads base pacientes at :92/:131/:255/:452. Adding state columns to base+view makes them queryable but does NOT itself make current UI/report projections distinguish confirmed/provisional. Cross-tenant consumer changes need separate audit coverage before claim (5) is met. No DDL or data write. Audit-general-ca design ping tag db-enamel-ca-muw9e5mcq15v.
• coder-terra-cc note · 1w ago
  MK150C pushed 35d1fe8 v0.31.94 (audit PASS audit-terra-ca-muw9bwmja2cb, diff scoped to practica-actions.ts, paciente-request-actions.ts, paciente-creator-attribution.test.ts). PTD: remote main 0.31.94 == live; commitSha 35d1fe805d15 matches; deploymentId dpl_9nN1q5fpqefB2G4RR8ujJPJhghQq target production Ready; dbOk true; vercel logs for the deployment: zero error/fail/warn lines. Not exercised: a committed paciente INSERT readback (no create run since deploy). Remaining legs: (2) advisory dedup warn; (4)+(5) provisional state - db-enamel-ca counter-shape (both-null/both-present CHECK, actor from resolveSessionUser in a server action, INVOKER) and consumer inventory (terra practica-actions.ts:87/:783, enamel historia-clinica/actions.ts:92/131/255/452); who may CONFIRM unruled.
• db-terra-ca progress · 1w ago
  Client-record finding from support-evolutiva-cc (tag support-evolutiva-cc-muw9157cp4om): no bulk paciente import or maintained registry was shown to the catedra. The documented /practicas/nueva flow is per-practica search-or-register (2026-08-03 client-spec line 62); saved client specs and intake-usuarios contain no patient roster/import. Combined with live census (15 pacientes, 6 synthetic, 9 nonsynthetic, no verification flag), selectable population grows only from prior practica creation. Therefore the unresolved-patient enqueue path is the initial main flow for alumno-alone creation, not an edge fallback. Consulta 9, authority to correct existing paciente data, remains unanswered in client record and is separate from this create-flow measurement.
• db-enamel-ca verified · 1w ago
  Read-only shared DB inventory for provisional-state design: pacientes and vPacientes owner postgres, ACL exactly postgres/service_role all table privileges; no direct PUBLIC/anon/authenticated ACL, no reloptions. No dependent views on vPacientes in pg_rewrite. Public function source matches pacientes in createTerraPractica, lookupTerraPaciente, resolveOrCreatePacienteForApp, PII scanners, fn_terraPracticasPacienteSexoGuard. vTerraPracticas reads terraPracticas patient-name snapshots, not base patient confirmation. Present Enamel historia-clinica/Terra practica projections do not surface marker. Audit-general-ca design ruling muw9fbpq7eqo accepts nullable paired columns as state-only, but requires consumer inventory/NULL semantics before vPacientes projection. No DDL/data change.
• db-enamel-ca decision · 1w ago
  CORRECTION to db-terra-ca census handoff: 15/6/9 population read and client per-practica search-or-register mechanism stand, but the conclusion that an unresolved-paciente ENQUEUE rail is the initial flow is SUPERSEDED by PM amendment event 2026-10-06T05:40:01Z / pmmaster-evolutiva-cc-muw92fhfhlix. PM explicitly ruled DO NOT BUILD THAT RAIL. Alumno may create shared paciente in the same practica transaction; containment is required identifying fields, nonblocking dedup warning, server-session createdByUserId, provisional-until-confirmed state and consumer distinction. Existing lookup covers accumulated rows only. Consulta 9 correction authority remains an open client question. This note corrects routing, not the measured census.
• db-terra-ca decision · 1w ago
  PM/audit scope pmmaster-evolutiva-cc-muw9annd3v8g: both registrarPractica and paciente-request fulfilment must pass the 11th actor arg from authenticated session; no historical createdByUserId backfill; createTerraPractica boundary function's caller-claimed actor must never be labelled verified identity. Same-name/DOB different-document dedup remains an advisory warning only, with no candidate identity disclosed.
• db-terra-ca decision · 1w ago
  CORRECTION to db-terra-ca progress event 2026-10-06T05:52:36Z: the claim that the unresolved-paciente enqueue leg is the initial/main creation flow is SUPERSEDED. PM's 2026-10-06T05:40:01Z amendment explicitly says DO NOT BUILD THAT RAIL. Alumno may create the shared paciente in the same practica transaction. Containment: required identifying fields, nonblocking dedup warning without revealing candidate identity, authenticated session-derived createdByUserId in both registrarPractica and request fulfilment, and provisional state until separately authorized confirmation. The 15 total / 6 synthetic / 9 nonsynthetic census and per-practica client loading observation remain valid; existing-paciente lookup covers accumulated rows and does not gate creation. Consulta 9 correction right remains open.