Antecedente provenance has no reader: terra_52 records merge history that nothing renders, and the surface the row originally specified (a shared ficha) does not exist in Terra at all - reader hangs off /practicas/[id]

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus blocked · 6w ago
  terra_52 is DRAFT: needs rollback dry run + db-enamel shared-owner GO before the table exists
• wi-cli-venus parentChanged · 6w ago
  parent=TERRA-113
• wi-cli-venus note · 6w ago
  GO REQUESTED from db-enamel-cc 2026-08-31 (tag coder02-terra-cc-mthq4rdr42jo), which had never been asked. Scoped explicitly: INSERT+UPDATE on pacienteAntecedentes through fn_terraMergePacienteAntecedentes only, SELECT on vUserGroups and antecedentesCatalog, and a separate yes/no on the FK at terra_52:25 into pacienteAntecedentes(id) - offered to drop the FK for a bare uuid if they prefer, since it costs us a guarantee we want but do not require. The request also carries the finding about THEIR trigger as a finding, not a request: tg_pacienteAntecedentes_requireDetalle is BEFORE INSERT OR UPDATE with no WHEN and no UPDATE OF, so it validates detalle on statements that do not modify it, and setting requiresDetail true on any catalogue row retroactively freezes every pre-existing NULL-detalle row for that antecedente against ALL updates by ANY writer - theirs included. Offered the rolled-back transcript before any apply. THE BLOCKER ON THIS ROW IS NOW A QUESTION THAT HAS BEEN PUT, rather than one nobody asked, which is what it was from the moment the row was filed.
• wi-cli-venus note · 6w ago
  GO SCOPE COMPLETE AND EXPLICIT, no inference left in it. db-enamel-cc (tag db-enamel-cc-mthq8glptnza) extended the grant: fn_terraMergePacienteAntecedentes may ALSO SELECT public.antecedentesCatalog for the requiresDetail pre-check. Their reason is worth keeping because it is about their users rather than a concession to ours - a clinician-facing refusal in terra's vocabulary beats surfacing enamel's raw P0001 text. FULL GRANTED SCOPE, all four items, none assumed: INSERT and UPDATE on public.pacienteAntecedentes through fn_terraMergePacienteAntecedentes only; SELECT on public.vUserGroups; SELECT on public.antecedentesCatalog; and the FK at terra_52:25 into pacienteAntecedentes(id) KEPT on their instruction, because enamel never hard-deletes those rows - they close ranges with toAt exactly as our merge function does - so NO ACTION costs them nothing and buys a real guarantee. I had offered to drop it and the offer was declined. They also agreed the close-path pre-check has nothing left to guard under enamel_042 and that inverting the dry-run arm into a regression guard on THEIR trigger is the right shape, so the cross-owner coupling is acknowledged from both sides rather than being a surprise the first time it fires. STILL BLOCKED, and only on this: the draft is not yet updated and not yet dry-run. The rolled-back transcript goes to db-enamel-cc before any apply, as offered and as they asked for. NOTHING IS APPLIED.
• wi-cli-venus unblocked · 6w ago
  BLOCKER EXPIRED AND NOTHING WAS WATCHING IT. This row's blockedReason read "terra_52 is DRAFT: needs rollback dry run + db-enamel shared-owner GO before the table exists". Every clause of that is now false. terra_52 was applied 2026-08-31 by db-enamel-cc under hub tag db-enamel-cc-mthudjxcwhhy, pushed as 80f3712, and I verified the objects live myself: fn_terraMergePacienteAntecedentes present with proconfig pinned and an ACL of exactly postgres plus service_role, and terraPacienteAntecedenteChanges present with all five constraints including changedBy REFERENCES users(id). The GO was given, the dry run exists as a 13-arm transcript, and the table exists. The row sat blocked on a condition that had already been satisfied, and it would have kept sitting there because a blockedReason is a sentence nobody re-reads until someone opens the row. THE ROW IS ALSO NOW MORE URGENT THAN WHEN IT WAS FILED, AND IN A WAY ITS OWN TEXT DID NOT ANTICIPATE. It was written while terra_52 was draft, so the gap it names - append-only storage that nothing renders - was purely prospective: no table, no writer, no rows, nothing to be invisible. As of e2a6a4c and 0f7027b (v0.30.79, live and confirmed at /api/health 23:50:06Z, deploymentId dpl_3Ks3rRodXZWwfDYHbwc8jpXB7mte) the WRITE PATH IS IN PRODUCTION. createPractica now calls the boundary function inside its transaction on every submission. So the table stops being empty at the first real merge, and from that moment the system is accumulating audit rows that no seat in the application can read. VERIFIED IN CODE RATHER THAN ASSUMED FROM THE ROW'S TITLE: grep over src/ for terraPacienteAntecedenteChanges returns ZERO files. The claim the row was filed on is still exactly true, now with a live writer behind it. WHY THIS MATTERS MORE THAN A MISSING SCREEN. The row's own argument holds and is worth restating because the premise has now shipped: the shared ficha is writable by cualquiera que carga una practica, which is the most permissive option Puia was offered, and the reason that answer is safe to implement is that a later reader can see WHO changed an antecedente and on the authority of WHICH practica. That safety argument is currently unbacked in the product. A provenance record nobody renders is indistinguishable from no provenance record from every seat that matters, and the permissive write policy was accepted on the strength of a traceability that exists only in a table. STATUS: unblocked to todo. Not started, not designed - the scope is unchanged, a read path rendering who changed an antecedente, when, and from which attested source practica, placed where a docente looking at a ficha that disagrees with their memory will actually find it.
• wi-cli-venus descriptionChanged · 6w ago
  was: Split from TERRA-113 on 2026-08-31 at db-terra-ca's request, so that append-only storage is not mistaken for user-visible traceability. terra_52 (DRAFT, unapplied) creates terraPacienteAntecedenteChanges and records append-only opened / detail_replaced events binding each merge to an attested source practica authored by the actor. db-terra-ca confirmed by repository search, and states it plainly: NOTHING READS THAT TABLE. It exists only in the draft; the ficha and the UI have no provenance-reader path at all. WHY THIS IS ITS OWN ROW RATHER THAN A LINE IN TERRA-113: a provenance record nobody renders is indistinguishable from no provenance record, from every seat that matters. The shared ficha is writable by "cualquiera que carga una practica" (Puia, 2026-08-30, the most permissive option he was offered). The whole reason that answer is safe to implement is that a later reader can see WHO changed an antecedente and on the authority of WHICH practica. If the history is only in a table, the person holding the question - a docente looking at a ficha that disagrees with what they remember - cannot reach it, and the storage silently does nothing for the case it was built for. It would also have closed invisibly: TERRA-113 can ship, be correct, pass every check, and leave this undone with nothing anywhere reading as incomplete. That is the exact shape of a row closing on work it never named. SCOPE: a read path for antecedente provenance. Who changed it, when, from which attested source practica, rendered where a person looking at the shared ficha will find it. Not started, not designed. BLOCKED ON: terra_52 is DRAFT ONLY. Rollback dry run plus db-enamel shared-owner GO are required before apply, and I have not asked for that GO. This row cannot start before the table exists, but it is filed NOW precisely so the gap is tracked while TERRA-113 is still in flight rather than discovered after it closes.
• wi-cli-venus decision · 6w ago
  THE ROW'S SCOPE SENTENCE PRESUPPOSES A PAGE THAT DOES NOT EXIST, AND THAT IS THE DESIGN DECISION THIS ROW ACTUALLY NEEDED. It says the provenance must be rendered "where a person looking at the shared ficha will find it". There is no shared ficha in Terra. Measured 2026-09-01 against src/app: the route directories are administrar, administrar/usuarios, alumnos, api, api/health, auth/callback, cirugias, identidad-en-revision, informes, login, mi-cursada, mi-perfil, panel, practicas, practicas/[id], practicas/nueva, sin-acceso, solicitar-acceso. There is no pacientes route and no patient page of any kind. A grep for pacienteAntecedentes across src returns exactly two files - practica-actions.ts, which WRITES, and its own test. There is no reader anywhere, which is what the row says, but the reason is one level deeper than the row states: it is not that a reader was omitted from an existing page, it is that the page the reader was specified to live on has never been built. WHY THIS MATTERS RATHER THAN BEING A WORDING FIX. Taken literally, the row asks for a patient-wide ficha - a new route, a patient lookup, an authorization audience for who may open an arbitrary patient's shared record, and a decision about what else that page shows once it exists. That is a substantially larger piece of work than "add a read path", it is nobody's filed row, and it would have been absorbed silently into a task whose title says provenance has no reader. That is the shape this row was itself split out of TERRA-113 to prevent, arriving one level up. DECISION, MINE, AND SCOPED DELIBERATELY NARROW. The provenance reader hangs off /practicas/[id], in or beside the antecedentes section that already renders the attestation, scoped to the antecedentes THAT PRACTICA touched. Reasons, in order of weight. It is the only surface that exists. Its audience already has both the patient and the authority context in front of them, so it needs no new authorization question - the row is reachable to exactly whoever can already open that practica. And it answers the actual question the row was filed for: a docente reading a practica whose antecedentes disagree with what they remember can see, on that same screen, who changed each one and on the authority of which source practica. WHAT THIS DELIBERATELY DOES NOT DO, stated so it is not later read as done. It does not give a patient-wide history: from /practicas/[id] you see the changes touching that practica's antecedentes, not every change ever made to that patient's shared record. A person holding a question that spans practicas still cannot answer it. That is a real remaining gap and it belongs to the unbuilt patient page, not here. Do not close the patient-ficha question by pointing at this reader. THE EMPTY STATE IS THE PRIMARY CASE, NOT AN EDGE CASE, AND IT IS THE PART MOST LIKELY TO BE GOT WRONG. terraPacienteAntecedenteChanges holds ZERO rows today, measured on the live database. Every practica opened between shipping this and the first real merge will render the empty state, so the empty state IS the feature for that whole period. It must read as "no recorded changes" and must not read as an error, a spinner, or a blank region that looks like a failed load - an empty provenance panel that looks broken is worse than no panel, because it invites someone to file a defect against a working feature. Distinguish it in copy from the genuinely different state where the row itself has no antecedentes. CONSTRAINTS ON THE IMPLEMENTATION. Read-only: this row adds no writer, and terraPacienteAntecedenteChanges is append-only by construction. changedBy is a uuid into shared users and must be resolved to a display name through whatever path the practica detail already uses for actor names - do not add a second, differently-shaped user lookup, and do not query shared users directly from a new call site. previousDetail and nextDetail are the only nullable columns of the ten, so the renderer must handle a null on either side; an opened action legitimately has no previous.
• wi-cli-venus assigned · 6w ago
  coder-terra-ca
• wi-cli-venus titleChanged · 6w ago
  Antecedente provenance has no reader: terra_52 records merge history that nothing renders, and the surface the row originally specified (a shared ficha) does not exist in Terra at all - reader hangs off /practicas/[id]
• wi-cli-venus decision · 6w ago
  PLACEMENT CONFIRMED AND THE FILTER CORRECTED, 2026-09-01. coder-terra-ca returned the three source facts I asked for and I read all of them rather than accepting the citations. getPracticaDetail already resolves an actor uuid to a display name twice - postopBy at src/lib/practica-detail.ts:125-129 joins users through terraPracticasArchive.archivedBy, and the participantes aggregate at 178-184 returns nombre and apellido the same way - so changedBy reuses that shape and no second user lookup is added. PRACTICA_ACCESS_SQL is applied inside that same query at 190-193. The attestation renders at src/app/practicas/[id]/page.tsx:113-128, gated on antecedentes.length > 0. The provenance block hangs immediately after it, as one more JSON aggregate in the existing one-round-trip reader. THE PROPOSED FILTER WAS WRONG AND IT IS THE LOAD-BEARING PART. The proposal keyed the aggregate on sourcePracticaId = p.id, which returns only the changes THIS practica authored. That is very nearly the attestation being rendered directly above it - the panel would restate what the reader had just read. The case this row was filed for is a docente whose patient's antecedentes disagree with what they remember, and the change that answers them was almost always authored by somebody else. A provenance panel that structurally cannot show another author is not a provenance panel, and it would have passed every check while answering nothing. CORRECTED SCOPE: the change history OF THE ANTECEDENTES THIS PRACTICA TOUCHED, regardless of which practica authored each change - keyed on antecedente identity for this patient, restricted to the set this practica attested, ordered by changedAt. sourcePracticaId stops being the filter and becomes a rendered column; it is what makes each row attributable rather than what limits the set. THAT DECISION OPENS AN AUTHORIZATION QUESTION AND IT IS RULED ON HERE RATHER THAN INHERITED. PRACTICA_ACCESS_SQL gates the practica being VIEWED. It does not gate the other source practicas whose changes this panel now surfaces, so a viewer can see changedBy, changedAt and previousDetail originating from a practica they cannot open. RULING, mine: the history is visible to anyone who can open this practica. The shared ficha is writable by "cualquiera que carga una practica" (Puia, 2026-08-30, the most permissive option offered), and the stated justification for accepting that permissive write was precisely that a later reader can see who changed an antecedente and on whose authority. A record everyone may write and only some may read does not deliver that, so the read follows the write. THE RULING MUST BE WRITTEN INTO THE QUERY, NOT INTO A COMMIT MESSAGE. A comment at the aggregate stating that the access boundary is deliberately the viewed practica and not the source practica, that this is a decision and not an oversight, and naming the ruling it rests on. A boundary that is merely inherited is the next reader's silent bug, and a commit message is the one artifact that can never be corrected. CHECKED INDEPENDENTLY RATHER THAN AGREED. previousDetail is the one field with no other route to this viewer - current values already reach them through the merge, superseded ones do not. db02-terra-cc has been asked to measure the exposure delta as a DATA question, explicitly without being told what coder-terra-ca proposed and without reading these events, because two lanes agreeing after one has seen the other's answer is one measurement wearing two names. The ruling above stands unless that measurement contradicts it.
• wi-cli-venus decision · 6w ago
  THE INDEPENDENT MEASUREMENT CAME BACK AND IT CHANGES THE RULING IN ONE FIELD. db02-terra-cc measured the exposure delta as a data question, without being told what coder-terra-ca had proposed and under instruction not to read this row's events, so the two lanes are genuinely independent rather than one measurement wearing two names. It confirmed zero rows in terraPacienteAntecedenteChanges first, so everything below is against the schema and access model and not against observed data. WHAT NARROWS THE QUESTION, AND I HAD NOT ACCOUNTED FOR IT. PRACTICA_ACCESS_SQL, verified by me at src/lib/practica-postop-core.ts:54-69, has three branches: createdBy, a live participante row, and membership in vUserGroups for appKey terra in docente, jtp, bedel or admin. THE THIRD BRANCH IS APP-WIDE, NOT PRACTICA-SCOPED. Anyone in the teaching tier can already open any practica, so for that population there is no cross-practica exposure to create - they could reach the source practica directly. The exposure question bites only for a plain alumno who is the creator or a participante of the practica being viewed and holds no teaching-tier group. That is a much smaller population than the ruling was written against. PER FIELD, MEASURED. action, changedAt, changedBy and sourcePracticaId are ALL new - no existing surface returns any of them. Every antecedente surface in the codebase deliberately omits the authoring identity and the date. previousDetail is new and is the strongest case: lookupPaciente, activePacienteAntecedentes and the per-practica attestation join all return only the CURRENT active value, never a superseded one, so a detail_replaced row's previousDetail is clinical text that a practica-scoped viewer has no other route to. nextDetail is the ambiguous one: on the most recent change row for a still-live antecedente it equals what lookupPaciente already returns to any PRACTICA_ROLES holder patient-wide, but on an older row it is itself a superseded value and the reader cannot tell the two cases apart without comparing to the live row. I CHECKED THE APPARENT COUNTER-PRECEDENT MYSELF RATHER THAN LETTING IT STAND. practica-actions.ts carries a comment refusing to resolve recordedBy because "resolving it would disclose an identity Terra does not own", and refusing the date because "this form needs the fact and its clinician-entered detail, not a provenance display". Read whole, it does NOT argue against this row, for two reasons. It is scoped to THAT FORM, and it names the exact thing TERRA-144 is - a provenance display - as the different case rather than as a forbidden one. And recordedBy sits on pacienteAntecedentes, which is enamel's, so the identity genuinely is not Terra's to resolve; changedBy on terraPacienteAntecedenteChanges is a Terra actor writing through Terra's own path, an identity Terra does own. The precedent does not transfer, and it would have read as though it did. REVISED RULING: previousDetail IS NOT RENDERED, and the reason is not privacy. Render action, changedAt, changedBy and sourcePracticaId to anyone who can open the viewed practica, per the read-follows-write reasoning already recorded. Leave previousDetail out. It is the only value with no other route for the alumno case, AND it is not needed to answer the question this row was filed for - a docente whose ficha disagrees with memory needs who changed it, when, and on which practica's authority, not the superseded string. Dropping it costs nothing material and removes the entire exposure argument without introducing a per-tier branch, which would have meant new authorization logic written to protect a field nobody needs. nextDetail follows the same disposition for a different reason: the reader cannot distinguish current-and-already-public from superseded-and-not without a comparison the panel would have to perform. Not worth the branch either. WHAT THIS DOES NOT SETTLE, from db02's own bounds. It grepped src/app and src/lib only, so a surface outside those trees exposing these fields would not have been found. It did not read the table's RLS or grants, which have never been exercised because the table holds no rows. And no part of this is observed behaviour - it is a reading of schema and access code.
• wi-cli-venus completed · 6w ago
  SHIPPED AND VERIFIED AT THE PRIMARY, NOT FROM THE REPORT. cbafac7, "2026-09-01-0100 feat(terra): show shared antecedentes change provenance (TERRA-144)", confirmed on main through the GitHub API with exactly four files - src/lib/practica-detail.ts, src/app/practicas/[id]/page.tsx, the new src/lib/practica-antecedente-provenance.test.ts, and the automatic package.json version bump. Nothing outside the authorised scope. v0.30.88 is live at dpl_24d2gzfRcDPiTurBEjUsXGNCAhTr with dbOk true, checked against the running deployment rather than inferred from the push. WHAT SHIPPED. One additional JSON aggregate inside the existing getPracticaDetail one-round-trip reader, hung immediately after the antecedentes attestation block on /practicas/[id]. It renders, per change: the antecedente label, the action (opened or detail_replaced) in Spanish, the actor's name resolved through the same LEFT JOIN users shape the participantes aggregate already uses, the timestamp, and the SOURCE PRACTICA NUMBER. Two distinct empty states: one for a practica that attested no antecedentes at all, one for attested antecedentes with no recorded changes. THE ROW OPENED WITH TWO FALSE PREMISES AND BOTH ARE RECORDED RATHER THAN QUIETLY DROPPED. Its blocker said terra_52 was DRAFT ONLY and the row could not start; terra_52 is in applied/ and the table is live. Its scope sentence said the reader belongs on "the shared ficha"; Terra has no ficha, no pacientes route, and no patient page of any kind - taken literally the row was requesting a new route with its own authorization audience, hidden in a prepositional phrase. Neither was a wording problem. Each was measured, and the second changed what this row IS. THE DESIGN DECISION THAT MATTERED WAS THE FILTER, AND THE FIRST IMPLEMENTATION HAD IT BACKWARDS. It scoped the aggregate to sourcePracticaId = p.id, which returns only the changes THIS practica authored - very nearly the attestation rendered directly above it. The case this row exists for is a docente whose patient's antecedentes disagree with what they remember, and that change was almost always authored by somebody else. A provenance panel that structurally cannot show another author is not a provenance panel, and it would have passed every check while answering nothing. Corrected to key on the antecedente identity for this patient, restricted to the set attested here, irrespective of author; sourcePracticaId became a rendered column instead of the filter. THE AUTHORIZATION QUESTION IS RULED ON IN THE SOURCE, NOT INHERITED. PRACTICA_ACCESS_SQL gates the VIEWED practica only, so the panel surfaces changes authored from practicas the viewer may not be able to open. Ruling: the history is visible to anyone who can open this practica, because the shared ficha is writable by cualquiera que carga una practica (Puia, 2026-08-30) and the stated justification for accepting that permissive write was precisely that a later reader can see who changed what. The read follows the write. That reasoning is now a comment at the aggregate naming the ruling it rests on, rather than a commit message - a boundary that is merely inherited is the next reader's silent bug. DETAIL VALUES ARE WITHHELD, AND THE REASON IS NOT PRIVACY. db02-terra-cc measured the exposure delta independently, without being told what the implementing lane had proposed and under instruction not to read this row's events, so the two lanes are genuinely independent. It found all four rendered fields are equally new exposure - no existing surface returns an authoring identity or a date for any antecedente - and that previousDetail is the only value with no other route for the exposed population. It also found the narrowing I had missed: PRACTICA_ACCESS_SQL's third branch is APP-WIDE vUserGroups membership in docente/jtp/bedel/admin, not practica-scoped, so the teaching tier can already open any practica and the exposure only ever concerned a plain alumno. previousDetail and nextDetail are dropped because neither is needed to answer the row's question, which removes the entire exposure argument without adding a per-tier authorization branch to protect a field nobody needs. FOUR DEFECTS WERE CAUGHT BEFORE PUBLICATION AND NONE BY THE LANE THAT WROTE THEM, which is the part worth carrying forward. A raw uuid rendered to clinicians on a page whose own heading uses practicaNumber. A React key and an ORDER BY both built on changedAt, which is now() and therefore TRANSACTION-START CONSTANT - an opened and a detail_replaced row written in one merge carry identical timestamps, so the key could collide and the order was non-deterministic across loads with no data change. A backtick around an identifier inside an SQL comment, which TERMINATED the enclosing JS template literal and made the file fail to parse. And a static test whose slice began below the projection list it was asserting against. git diff --check reported clean through all four; it checks whitespace, not syntax and not semantics, and was twice reported to me as though it were verification. WHAT THIS DOES NOT PROVE, and it is most of what would matter. terraPacienteAntecedenteChanges holds ZERO rows. The aggregate has never run against data, no browser has rendered the panel, and the only state any user can currently reach is the empty one. The evidence here is static source assertions, a clean typecheck, 447/447 unit tests and a live health check - it establishes that the query says what was decided, not that it returns what is expected once rows exist. The first real antecedente merge is what tests this, and nothing in this repo can produce one. STILL OPEN AND DELIBERATELY NOT CLOSED BY THIS: the patient-wide view. From /practicas/[id] a reader sees changes touching THAT practica's attested antecedentes, not every change ever made to that patient's shared record. A question spanning practicas remains unanswerable, and that belongs to the unbuilt patient page. Do not treat this row as having closed it.
• wi-cli-venus verified · 6w ago
  ENDURECIDO EL ARM DE ESTE ROW, y la asimetria que se corrigio era silenciosa. practica-antecedente-provenance.test.ts tenia dos negativas sobre el SQL escritas con comillas - doesNotMatch(sql, /'previousDetail'/) y /'nextDetail'/ - o sea que solo atrapaban la forma de clave JSON, mientras las dos negativas equivalentes sobre PAGE estaban sin comillas. El arm de SQL era ESTRICTAMENTE MAS ANGOSTO que el de la pagina sin ninguna razon escrita: una referencia a la columna pelada previousDetail o nextDetail dentro de ese SQL pasaba el test. Nada lo senalaba porque las cuatro lineas se leen iguales de un vistazo y las comillas son un detalle tipografico, no una diferencia visible de intencion. Ahora las cuatro prueban lo mismo. LO PEDI CON CONTROL MUST-FAIL Y coder-terra-ca LO CORRIO: inserto previousDetail pelado en el json_build_object del SQL acotado de este row, el test fallo en la assertion ensanchada (1 fail), restauro la fuente y volvio a 3/3. Verificado por mi en la fuente y no por el reporte: lineas 35-36 ahora sin comillas, node --test da 3 pass 0 fail. Un arm que nunca fallo no registra nada, asi que la prueba de que puede fallar es la mitad que hace que el ensanchamiento cuente. SIN COMMIT TODAVIA - el cambio esta en el arbol de trabajo, que es estado expuesto: cualquier commit de otro agente sobre src/ se lo lleva puesto sin nombrarlo.