Practicas N19 y N20 son fixtures de prueba en produccion a ocho dias de la demo del 1/10, y ningun script las borra
proxy-general-cc creo las practicas N19 y N20 el 2026-09-28 10:51 ART para ejercer TERRA-252 (orientacion EXIF). El ejercicio era correcto y cerro la fila. Lo que queda es el residuo: son filas de produccion reales, sobre pacientes reales, creadas con imagenes de prueba (barras roja/azul y un triangulo verde), y van a estar visibles en /practicas y contadas en los agregados de /informes durante la demo del 1/10. NADA LAS VA A BORRAR. db/cleanup-demo-sample-data.sql selecciona por un manifiesto de ids fijo (25120000-0000-4000-8000-00000000000{1..8}); N19 y N20 no estan ahi. Tampoco llevan isSynthetic ni syntheticSessionId - se crearon por el camino normal de la app, que es precisamente lo que las hacia buen instrumento de prueba y ahora las hace indistinguibles de datos reales por consulta. DECIDIR: (a) borrarlas antes del 1/10, lo que exige un id manifest propio y contexto de archivo (app.terraUserId + app.terraArchiveReason) porque el trigger de archivo es AFTER UPDATE sin alcance limitado, o (b) dejarlas y aceptar que la catedra vea dos practicas con imagenes de prueba, o (c) fijar la regla general de que un ejercicio autenticado en produccion declara su limpieza ANTES de correr. El punto que sobrevive a esta fila: un ejercicio autenticado real escribe en produccion, y hoy ningun camino de prueba declara como se revierte lo que escribio.
Activity
-
MARKER-t255-board-mulb6: blackboard bb-coder-terra-cc-mulb4yju-gnq74r, four written, complete 10:53 ART. RAW SPLIT: A - coder-terra-cc, audit-general-ca. C - db-enamel-ca, coder-terra-ca. Two-two, no majority. BUT THE SPLIT IS NOT ABOUT THE OUTCOME. Nobody argued the rows should stay; B drew zero. Both C answers explicitly leave the disposition of N19/N20 open as 'an explicit authorized decision' rather than defending the rows. And audit-general-ca's A is conditional on precisely what the C answers say is missing: 'If no legitimate actor is nominated, stop the write and escalate; do not fabricate attribution.' So all four converge: the rows are removed, and the removal is blocked on ONE input - a named person who authorizes it and is therefore the honest editor of record. My question failed to nominate one, which is what produced the apparent disagreement. That is a defect in the question, not a tie. WHAT THE BOARD SETTLED: - Remove exactly N19 and N20, selected by verified uuid, never by a state or content predicate. - One transaction, preflighting row identity, paciente links, image evidence and current state. - app.terraArchiveReason names TERRA-252 test residue. Preserve the archive rows. - Verify both leave /practicas AND the /informes aggregates. - Never borrow an unsuspecting clinician's identity. - The C rule is real and gets its own row; it does not substitute for this cleanup. BLOCKED ON: the two uuids (asked of proxy-general-cc, which created them) and the actor nomination (Elazar's, same as TERRA-251).
-
MARKER-t255-sql-mulbv: db/terra-255-remove-test-practicas.sql written, ready to run the moment an actor is nominated. Manifest is the two verified uuids from proxy-general-cc: N19 = 3b1fcdd9-bca7-4d25-94f5-32986b714a7a N20 = 47e98e3e-0e23-4a70-b2e5-f0eae5aeb685 SOFT delete, not a purge. vTerraPracticas is deletedAt IS NULL AND NOT isSynthetic (terra_1_initial_schema.sql:167-168), so setting deletedAt drops both rows out of /practicas and out of every /informes aggregate in one move while terraPracticasArchive keeps the record that they existed and who removed them. A hard DELETE would destroy the evidence that the correction happened, which is the opposite of what Ley 26.529 asks. practicaImages rows are deliberately left: they hang off practicaId, are unreachable once the practica is invisible, and are the only artifact proving what the rows contained. Implements the board method point for point - uuid selection only, one transaction, preflight of identity/state, image evidence, and manifest separation from the TERRA-251 fixture; archive context via the post-rename GUCs; postflight on the VIEW rather than re-reading the column just written, plus an archive-row check so a trigger that did not fire cannot pass as success. TWO COLUMN NAMES CORRECTED AGAINST THE SCHEMA rather than assumed: the archive table keys on rowId, not practicaId (it is the generic archiveOp/rowBefore/rowAfter shape, terra_1:220-229, and terra_5:105-106 writes it); practicaImages.practicaId confirmed at terra_208:119. NOT RUN. Blocked on the actor nomination only. The placeholder aborts on the syntax regex, so the file cannot run unattributed.
-
MARKER-t255-paciente-mulc9: CORRECTING MY OWN FRAMING. I said repeatedly, including in the blackboard question and the commit body, that these rows sit on REAL pacientes. They do not. proxy-general-cc, read-only preflight 11:17 ART: both N19 and N20 belong to paciente 'Synthetic TERRA207', DNI 90000002. Each carries exactly one test radiograph, both image endpoints return 200 - N19 terra252-orientation6.jpg at 800x1200, N20 terra252-orientation1-control.jpg at 1200x800 - and both show only 'Sin complicaciones'. proxy cannot read the paciente uuid from the UI and suggests resolving pacienteId by DNI 90000002 in the DB preflight. WHAT THIS CHANGES: the strongest version of my argument is gone. These are not false clinical records about a real person; they are test prácticas on a synthetic demo paciente. The board answered a question containing a fact I had not verified, and had B been argued on that basis it would have been a stronger case than it got. WHAT IT DOES NOT CHANGE: the practica rows themselves are NOT synthetic - isSynthetic is false, which is why they appear in vTerraPracticas, in /practicas and in every /informes aggregate. On 1/10 the catedra sees twenty practicas of which two are red and blue bars. The removal still stands, on the weaker and sufficient ground that the aggregates should not count test rows. PREFLIGHT TO ADD before this runs: assert both manifested practicas hang off the DNI 90000002 paciente, so a manifest that has drifted onto a real patient's record aborts instead of soft-deleting it.
-
MARKER-t255-preflight-mulcz PUSHED ec425f0. The paciente-identity preflight this row asked for is now IN the file: resolve the one live synthetic DNI 90000002 paciente, then assert both manifested practicas link to that exact row; anything else raises and rolls the statement back. Added by a peer on the shared checkout, reviewed and pushed unaltered. Same commit corrects the file's rationale: my repeated claim that N19/N20 sit on REAL pacientes was wrong - proxy-general-cc put both on synthetic paciente Synthetic TERRA207. The removal now rests on the weaker sufficient ground that these are ordinary non-synthetic practicas counted in /practicas and every /informes aggregate. Objects the preflight names were verified against the corpus before pushing: terraPracticas.pacienteId (terra_1:117,138) and public.normalizeDocumentoNumber(text) via the live index expression it is called from (terra_150:67-69). STILL NOT RUN - blocked on Elazar nominating the archive actor; the placeholder aborts on the uuid regex.
-
MARKER-t255-aggpostflight-mulde ec425f0 carries MORE than my commit body describes. The file changed on the shared checkout between my read and the push, so an /informes aggregate section shipped under a body that names only the preflight. Reviewed after the fact, it is sound: v_report_before/v_report_after are DECLAREd as jsonb; terraModulos/terraCirugias exist with 'nombre' (terra_1:81-110); vTerraPracticas is SELECT * so moduloId/cirugiaId/complicacionesCompletedAt (terra_1:136,137,151) are exposed; and the comment's claim that this is the same source set /informes reads is TRUE, verified at src/lib/informe-query.ts:16,268, not taken from the comment. Two limits, neither a gate: (1) only 'total' is asserted (before-after = 2); porModulo/porCirugia are NOTICE evidence only, which is what the comment says, so no overclaim. (2) the breakdowns join the BASE terraModulos/terraCirugias while the app has vTerraModulos/vTerraCirugias (isActive AND deletedAt IS NULL) - an inactive module would label differently here than in /informes. Evidence quality only; the asserted total is unaffected. No change needed. STILL NOT RUN.
-
MARKER-t255-imgpin-muldg PUSHED be8c1ef. PREFLIGHT 3 now pins the exact proxy mapping (N19 -> 2026_2e56edd0-a8c0-45f8-ab69-ecf297987e5f, N20 -> 2026_14dbf0b5-0941-4bf3-b49c-e1ec06fa92f3) instead of 'at least one image each', which any later upload would have satisfied. imageId text / practicaId uuid FK verified against terra_208_practica_images.sql. LIMIT, not changed: neither the count nor the join filters deletedAt, which practicaImages has - a soft-deleted image row on either practica makes v_images 3 and refuses a run that should proceed. Fail-closed, so no wrong write is possible; the cost is a false refusal with the actor in hand. db-terra-ca holds the file, so the call is theirs.
-
MARKER-t255-labelnote-muldk CORRECTION to MARKER-t255-aggpostflight-mulde. I recorded that the aggregate breakdowns join base terraModulos/terraCirugias while /informes uses the isActive views, and called it an evidence-quality gap. That is wrong. informe-query.ts:287,291 LEFT JOINs the BASE terraModulos and terraCirugias, not vTerraModulos/vTerraCirugias, so the script's snapshot mirrors current /informes labelling exactly, inactive labels included. db-terra-ca caught it; verified at the named lines rather than taken from the DM. No limit on the aggregate section stands. The deletedAt limit on PREFLIGHT 3 (MARKER-t255-imgpin-muldg) is unaffected and still open.
-
MARKER-t255-imgdel-muldp PUSHED 3529754, closing the deletedAt limit from MARKER-t255-imgpin-muldg. My proposed fix was WRONG and coder-terra-ca caught why: filtering deletedAt on the v_images count alone is worse than not filtering at all. A deleted expected image row plus one unrelated live row gives v_images=2, while the unfiltered VALUES join still matches the deleted expected row and gives v_image_matches=2 - both assertions pass on a pair that is not intact. Unfiltered failed closed; half-filtered passes wrongly. Both queries now filter deletedAt IS NULL and the comment at the query says they have to move together. db-terra-ca re-read and confirmed. Edited by me because both peers stood down and the tree was clean. STILL NOT RUN - actor placeholder aborts on the uuid regex.
-
MARKER-t255-authbb-muldr Blackboard bb-coder-terra-cc-muldn4b7-r0511e opened on the actor question, because a fact surfaced that made it worth contesting rather than assuming: TERRA-251 did NOT run under the named service actor. It ran at 10:06 ART under Elazar's OWN live users row 8157954d-7a79-48c2-a67b-87a37970d688, group=admin, on an authorisation he gave for an administrative UPDATE to terraPracticas archived under his id. TERRA-255 is the same shape. So the question was whether that authorisation covers it. At 2/4 written the answer is B, NOT COVERED, from me and audit-general-ca independently, on the same reasoning neither of us took from the other: archivedBy has no FK and nothing revalidates it, so the column's only guarantee is that a named human decided THIS edit and accepts being named for it. That is an assertion about one act, not a grant of access to an id. The new archiveReason names a different act on its face. Reusing the id would make the trail attest a decision Elazar has not made, and the fact that it is his own id rather than a stranger's makes the reuse harder to catch, not more legitimate. I opened this expecting to argue A. The deadline argues for asking him today, not for deciding without him. THE ASK, reduced to one narrow question per audit-general-ca: may this exact two-id TERRA-255 correction be attributed to your users.id 8157954d-7a79-48c2-a67b-87a37970d688? Yes runs the reviewed statement; no nominates the actual consenting editor.
-
MARKER-t255-bbclose-muldw Blackboard bb-coder-terra-cc-muldn4b7-r0511e COMPLETE, 4/4 written, UNANIMOUS B - not covered. db-terra-ca, audit-general-ca, coder-terra-ca and me, independently, and all four state they hold no fact contradicting the five premises. The convergence is on one point and it is worth recording because it is the reusable part: an authorisation names an ACT, not a role or an id. archivedBy has no FK and nothing revalidates it, so the column's only guarantee is that a named human decided this specific edit and accepts being named for it. TERRA-251's archiveReason names a different act on its face. Reusing 8157954d-7a79-48c2-a67b-87a37970d688 would make the trail attest a decision Elazar has not made. This row is therefore not blocked on ambiguity, on a missing credential, or on a peer. It is blocked on one sentence from one person, and every path around it has now been examined and closed by four seats. Nobody run it. Do not re-open this question; it has been asked and answered, and re-asking it is how a closed board becomes a loop. THE ASK, and it is the whole ask: may this exact two-id TERRA-255 correction be attributed to your users.id 8157954d-7a79-48c2-a67b-87a37970d688? Yes runs the statement as pushed at 3529754; no nominates the consenting editor instead.
-
Unanimous 4/4 blackboard bb-coder-terra-cc-muldn4b7-r0511e: TERRA-251's authorisation does not carry over. Blocked on ONE sentence from Elazar - may the two-id TERRA-255 correction be attributed to his users.id 8157954d-7a79-48c2-a67b-87a37970d688? Statement written, reviewed by three seats and pushed (3529754), five flights, fail-closed on the placeholder. Runs and self-verifies in one transaction the moment an id arrives.
-
READ-ONLY DRIFT 2026-10-06: current exact manifest practices N19/N20 remain live and both link the test-DNI 90000002 paciente, but that linked public.pacientes row has isSynthetic=false. The reviewed db/terra-255-remove-test-practicas.sql preflight at lines 103-112 requires the same DNI AND isSynthetic IS TRUE, so it now resolves count=0 and would RAISE before any archive/delete even if the separate named-actor authorization arrived. My earlier TERRA-277 statement that neither row had a test-name marker was false; both have it, and their exact IDs match this manifest. Do not run or silently loosen the predicate. Reconcile exact patient identity/state, re-review changed bytes, and retain Elazar's separate consenting-actor hold before any correction. No SQL executed.
-
PM ruling pmmaster-evolutiva-cc-muwapn90gwxf: HOLD, not a script fix. The existing SQL preflight requiring test DNI AND pacientes.isSynthetic=true MUST NOT be loosened by the party it constrains; live linked patient has isSynthetic=false, so count=0/abort is the intended fail-closed result. The exact N19/N20 manifest remains the ONLY deletion scope, still under the independent named consenting-actor hold and renewed exact-byte review if any script changes. Four OTHER live admin-attributed Sep-28 prácticas are unresolved test-looking residue, owner coder-terra-cc: N7=a7e55490-e820-4e86-aae1-eb3b52a0c8ab, N8=34cf6299-41e6-4363-b2c5-81571652b45f, N9=0c4b1ed3-bcfa-45f4-ba63-cfb2e115f001, N18=f656ad71-db83-4483-a8bb-d55da083902d. They link to test-named patients but lack located exact-ID provenance; do NOT delete, relabel or infer they are clinical, because clinical rows/participants may be real. All six practice rows remain live and isSynthetic=false (fresh readback), despite test exercise/appearance; the test path did not set the flag. Exact manifests, not a new test flag/view/branch, are the required future exercise residue mechanism. No data write performed.