Nada avisa cuando una cirugia nueva entra a un modulo con alcance ya definido: una exclusion deliberada y una olvidada son la misma fila ausente

Sub-tickets — 1/1 done

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus assigned · 6w ago
  ASIGNADA UNA MEDICION A db02-terra-cc QUE PUEDE EVITAR UNA CONSULTA AL CLIENTE, y por eso va antes de escribir la pregunta y no despues. Hora leida del reloj en esta corrida. ESTA FILA IBA A SALIR COMO PREGUNTA CLINICA - si esas 9, 9 y 10 cirugias DEBEN recibir tipoBarrera, tipoInjerto y zonaDadora - porque la fila afirma, correctamente, que hoy "excluida a proposito" y "nadie agrego la fila" SE VEN IDENTICAS. Antes de gastar una decision del cliente quiero saber si la ambiguedad es real o si se disuelve con una consulta. LA HIPOTESIS SALE DE LA FILA MISMA: la lista blanca se poblo contra el conjunto CONFIRMADO de entonces - 10 en modulo 1 y 7 en modulo 2, ya verificado que esas eran exactamente las confirmadas y que el comentario de la fuente midio bien - y hoy hay 16 y 14 vivas. Si eso es lo que paso, el corte no es clinico: es la foto del dia que se escribio. LA MEDICION, y esta armada para que el resultado DECIDA en vez de describir: para cada uno de los tres campos, el conjunto EXCLUIDO contra el conjunto NO-CONFIRMADO de su modulo. Si excluidas es exactamente no-confirmadas, esto es DERIVA MECANICA y no hay nada que preguntarle al cliente, hay algo que arreglar. Si el corte CRUZA la confirmacion - alguna confirmada excluida, o alguna no-confirmada incluida - entonces alguien eligio cirugia por cirugia, es criterio clinico, y la pregunta se justifica. DOS CONDICIONES EXPLICITAS. Por campoId real y nunca por key, porque "tipoBarrera" y "tipoInjerto" existen en los DOS modulos con campoId distinto - hallazgo del propio db02 y la razon por la que un censo agrupado por nombre daria cifras que parecen consistentes. Y los conjuntos CON NOMBRE E ID, no solo los tamaños: dos conjuntos del mismo tamaño que no son el mismo conjunto se leen identicos en un conteo, que es precisamente el error que esta medicion existe para no cometer. SOLO SELECT. Sin DDL y sin escrituras; terra_55 sigue sin GO en la eq 78 y esto no lo necesita.
• wi-cli-venus verified · 6w ago
  MEDIDO: MI HIPOTESIS ERA FALSA, PERO LA CONCLUSION DEL CARRIL SE QUEDA CORTA Y LA CORRIJO EN LA DIRECCION CONTRARIA. Medido por db02-terra-cc, RE-VERIFICADO POR MI contra la base - consulte las seis filas yo mismo, no le tome la palabra. LO QUE YO PROPUSE: que el conjunto EXCLUIDO fuera exactamente el NO-CONFIRMADO, lo que habria significado que la lista blanca se congelo el dia de la confirmacion y que esto era deriva mecanica sin nada que preguntarle al cliente. EL RESULTADO, con los conjuntos completos y no con los tamaños: tipoBarrera modulo 1 excluye {172,179,180,3,4,5,6,7,8}; tipoInjerto modulo 1 excluye EL MISMO conjunto; zonaDadora modulo 2 excluye {181,182,183,9,10,11,12,13,14,15}. Las no-confirmadas son {3,4,5,6,7,8} en modulo 1 y {9,10,11,12,13,14,15} en modulo 2. EL CARRIL CONCLUYO "no es deriva mecanica". ES MAS QUE ESO Y ES MENOS QUE ESO A LA VEZ, y la relacion exacta entre los conjuntos lo dice: EXCLUIDAS ES UN SUPERCONJUNTO ESTRICTO DE NO-CONFIRMADAS. O sea que TODAS las no-confirmadas estan excluidas - eso ES el congelamiento, y sigue estando ahi - MAS TRES confirmadas por modulo que estan excluidas ademas. Los dos mecanismos estan SUPERPUESTOS, no compiten. Descartar el congelamiento porque aparecio un segundo mecanismo seria perder la mitad del hallazgo. LO QUE ESO LE HACE A LA PREGUNTA, y es la ganancia real de esta medicion: la pregunta al cliente ya NO es sobre 9, 9 y 10 cirugias. Las no-confirmadas no hay que preguntarlas - se resuelven solas cuando se confirmen, si es que el alta las agrega a la lista blanca, y ese es el defecto que la fila ya describe. LO UNICO QUE LLEVA SEÑAL DELIBERADA SON SEIS CIRUGIAS CONFIRMADAS Y ACTIVAS QUE HOY QUEDAN FUERA, y ahora tienen nombre. LAS SEIS, verificadas por mi con isConfirmedByClient y isActive en true y deletedAt nulo: modulo 1 - 172 "En reborde alveolar cicatrizado sin ROG", 179 "Cigomaticos", 180 "Pterigoideos", las tres excluidas de LOS DOS campos, tipoBarrera y tipoInjerto. Modulo 2 - 181 "ROG vertical", 182 "ROG horizontal", 183 "EPS", excluidas de zonaDadora. QUE LAS TRES DE CADA MODULO SEAN LAS MISMAS PARA AMBOS CAMPOS ES EN SI UNA SEÑAL: un olvido campo por campo daria conjuntos distintos. Coincidir exactamente sugiere una decision tomada sobre la CIRUGIA, no sobre el campo. UNA ASIMETRIA QUE NOMBRO SIN RESOLVER PORQUE ES CLINICA Y NO ME CORRESPONDE, pero que es justamente lo que hace que la pregunta valga la pena: en modulo 1 los tres nombres se leen coherentes con la exclusion - "sin ROG" dice explicitamente que no hay regeneracion guiada, y cigomaticos y pterigoideos son tecnicas que se eligen para EVITAR el injerto. En modulo 2 apunta al reves: ROG vertical, ROG horizontal y EPS son las tres que mas obviamente involucran injerto, y son justo las que quedaron sin zona dadora. Si esa lectura es correcta, un modulo esta bien excluido y el otro esta mal, y hoy los dos se ven identicos - ausencia de fila. NO AFIRMO NINGUNA DE LAS DOS COSAS: es exactamente la distincion que esta fila dice que el sistema no puede hacer, y la traigo con nombres para que quien sepa la conteste en una linea. SIN CAMBIO DE CODIGO NI DE DATOS. Solo SELECT.
• wi-cli-venus assigned · 5w ago
  db02-terra-ca
• wi-cli-venus blocked · 5w ago
  Clinical-policy decision required; no safe DB mutation can infer it. Fresh live read confirms active confirmed exclusions: modulo 1, cirugias 172/179/180 are excluded from both tipoBarrera and tipoInjerto; modulo 2, 181/182/183 are excluded from zonaDadora. A clinician/product owner must decide whether each exclusion is intentional before adding or changing terraCirugiaCampos scope rows.
• wi-cli-venus assigned · 5w ago
  db-terra-cc
• wi-cli-venus verified · 5w ago
  RE-MEASURED LIVE by db-terra-cc 2026-09-11, marker SCOPE201-mtwrt8. The MECHANISM this row describes is real and correctly analysed. The INSTANCE COUNT in the title and description is wrong in two independent ways, and the drift it claims has ZERO occurrences. (1) THE 9/9/10 FIGURES COUNT INACTIVE CIRUGIAS. They were taken over cirugias 'vivas' = deletedAt IS NULL, which includes isActive=false rows. Live: modulo 1 has 16 vivas = 10 activas + 6 inactivas; modulo 2 has 14 vivas = 7 activas + 7 inactivas. An inactive cirugia is not offered in any form, so it cannot be silently excluded from one - counting it inflates the harm. Measured against ACTIVE cirugias the exclusions are tipoBarrera modulo 1 3 of 10, tipoInjerto modulo 1 3 of 10, zonaDadora modulo 2 3 of 7. Not 9, 9 and 10. (2) THE DRIFT HAS NOT HAPPENED - and this is the discriminating check the row never ran. The thesis is that adding a CIRUGIA to a module where a field already has scope silently leaves it outside the whitelist. Tested directly: for every excluded active cirugia, compare its createdAt against the last-written terraCirugiaCampos row for that campoId. ALL NINE PAIRS RETURN added_after_whitelist = FALSE. Every whitelist row was written 2026-08-22 19:04:40.950711Z; all six excluded cirugias (172 'En reborde alveolar cicatrizado sin ROG', 179 'Cigomaticos', 180 'Pterigoideos', 181 'ROG vertical', 182 'ROG horizontal', 183 'EPS') were created 2026-08-22 14:48:45.903403Z, four hours EARLIER. So not one cirugia has ever been added to a scoped module after the fact. The nine exclusions are not drift - they are exactly the deliberate TERRA-97 correction, and they reconcile 1:1 with what campo-scope-core.ts:9-11 says that pass did. (3) WHAT SURVIVES, and the row should be re-scoped to it rather than closed: the mechanism remains undetectable if it ever fires, because a deliberate exclusion and a forgotten one are still the same observable - an absent row - and nothing warns on a new cirugia. That is a LATENT risk with zero instances to date, not present silent drift. The clinical decision the blockedReason asks for is therefore narrower than stated: it covers six named pre-existing cirugias already documented as intentional by TERRA-97, not nine or ten unreviewed ones. Method, repeatable: cirugia counts split by isActive; exclusions via terraModuloCampos JOIN terraCirugiaCampos on campoId with deletedAt IS NULL, anti-joined to active terraCirugias; drift via max(cc.createdAt) per campoId vs c.createdAt. NOT COVERED: I did not re-measure the terraPracticasCampos load, so the row's separate finding that these columns carry almost no real data is untouched.
• wi-cli-venus unblocked · 5w ago
  RESCOPED AND UNBLOCKED by pmmaster-evolutiva-cc under Elazar's delegated GO, 2026-09-11. db-terra-cc's own re-measurement (marker SCOPE201-mtwrt8) removes the clinical blocker: all nine excluded pairs return added_after_whitelist=FALSE, every whitelist row was written 2026-08-22 19:04:40Z and all six excluded cirugias were created four hours EARLIER, so zero cirugias have ever been added to a scoped modulo after the fact. The exclusions are the deliberate TERRA-97 correction and are already documented as intentional. There is nothing for a clinician to review that TERRA-97 did not already decide. What survives is the sentence db-terra-cc wrote at point 3 and it needs no clinical input at all: a deliberate exclusion and a forgotten one are the same observable - an absent row - and nothing warns when a new cirugia lands in a scoped modulo. THIS ROW IS NOW THAT DETECTOR, latent risk with zero instances, buildable today. Acceptance: a check that FAILS LOUDLY when an active cirugia in a modulo that has scope rows for campo X has no terraCirugiaCampos row for X, with an explicit allowlist of the six known-intentional ids (172, 179, 180, 181, 182, 183) so a real new one is not lost in their noise. A detector that passes green because it counted the intentional six as normal is the defect it exists to catch. The clinical question about WHICH cirugias should ask tipoBarrera/tipoInjerto/zonaDadora stays with Elazar as eq#84 and is NOT this row - do not merge them. Counting note that must not be re-lost: cirugia counts split by isActive, not by deletedAt IS NULL; the 9/9/10 figures counted inactive rows and inflated the harm.
• wi-cli-venus titleChanged · 5w ago
  Nada avisa cuando una cirugia nueva entra a un modulo con alcance ya definido: una exclusion deliberada y una olvidada son la misma fila ausente
• wi-cli-venus assigned · 5w ago
  db02-terra-cc
• wi-cli-venus statusChanged · 5w ago
• wi-cli-venus note · 5w ago
  T201-detector-mtwzf1 - detector built, committed locally as 70fa403, NOT yet pushed and NOT yet run live. db02-terra-cc, 2026-09-11. THREE FILES, no app behaviour, no DDL, no data: `src/lib/campo-scope-drift-core.ts` (pure decision logic), `src/lib/campo-scope-drift-core.test.ts` (12 tests), `scripts/check-cirugia-campo-scope-drift.ts` (the live wrapper, modelled on its sibling `check-vocabulary-scope-integrity.ts`). Run deliberately, outside `pnpm test` and `.gitpush-pre.sh`, exactly like that sibling: `DATABASE_URL='postgresql://...' node scripts/check-cirugia-campo-scope-drift.ts`. Nothing schedules it; there is no systemd unit for the sibling either, so this one is on-demand by the same convention. THE VERDICT COMES FROM THE FORM'S OWN READER, NOT FROM MY SQL. The core calls `camposForCirugia` - the same function `practica-form.tsx` renders from - so a finding means literally "the form would not render this campo for this cirugia". A detector that re-derived "scoped" in its own SQL could drift from the reader, which is the defect class TERRA-97's header already warns about. The SQL fetches three raw row sets and decides nothing. DELIBERATE DEVIATION FROM THE ACCEPTANCE TEXT, stated rather than silently upgraded. The acceptance names "an explicit allowlist of the six known-intentional ids (172, 179, 180, 181, 182, 183)". Six bare ids is the wrong shape and I did not implement it. 172/179/180 are excluded from BOTH tipoBarrera and tipoInjerto in modulo 1, and 181/182/183 from zonaDadora in modulo 2 - that is NINE (moduloId, key, cirugiaId) triples. A bare-id list would forgive cirugia 172 newly dropping out of a THIRD campo, which is exactly the event this exists to catch. Overrule it if you disagree; it is one constant. THE ALLOW-LIST FAILS WHEN IT GOES STALE, which is the row's own sentence made executable: "A detector that passes green because it counted the intentional six as normal is the defect it exists to catch." The comparison is a symmetric difference, not a subset test. An entry matching no live exclusion fails in three named directions: `no_such_campo` (its (moduloId,key) resolves to no active campo), `campo_not_scoped` (that campo has zero live scope rows, so it is default-open and the entry describes nothing), `not_excluded` (the cirugia is inactive, or it now HAS a row). Without that arm the list rots and each dead entry is a standing licence to miss one real exclusion. campoId IS NEVER HARDCODED. It is a uuid - per-database, non-portable. The allow-list is keyed on `terraModuloCampos (moduloId, key)`, the portable unique constraint, and the script resolves the uuid in SQL. `tipoBarrera` and `tipoInjerto` exist in BOTH modulos under DIFFERENT uuids, so keying on `key` alone merges two campos governed by opposite regimes. COUNTING NOTE HONOURED: cirugias are filtered by `isActive`, NOT `deletedAt IS NULL`; scope rows by `deletedAt IS NULL` (matching `uq_terraCirugiaCampos_live`); campos by `isActive` (that table has no deletedAt). Empty corpus is a FAILURE, never a pass - no active campos, no active cirugias, no live scope rows and zero scoped campos each exit non-zero, because "nothing to check" must not read as "nothing wrong". `addedAfterWhitelist` IS AN OUTPUT COLUMN, NEVER AN ASSERTION. Per finding it reports `cirugia.createdAt > max(scope row createdAt for that campo)` - the signature that separated the historical nine from drift in the SCOPE201-mtwrt8 measurement. Asserting on it would let a same-transaction backfill pass, and a forgotten exclusion is a defect either way. Printing it makes a future red run self-classifying. WHAT I VERIFIED: 12 unit tests pass, and the whole suite is green (543 pass, 0 fail) with typecheck and build clean through `.gitpush-pre.sh`. The arms that matter are the ones that must FAIL - a new cirugia in a scoped modulo, an old cirugia dropped from a list, a cirugia excluded from a third campo, a deleted allow-list entry, and all three stale directions. The unscoped arm is pinned too: `marcaImplante` and modulo 2's tipoInjerto/tipoBarrera must never appear as findings, and a suite made only of scoped arms would pass against a detector that hides every unscoped campo. WHAT I COULD NOT DO, AND IT IS NOT A DETAIL. I never ran it against the database. There is no `~/.config/postgres/db02-terra-cc.env` and my Supabase MCP is still at the OAuth wall (apply_migration, execute_sql and list_tables all absent). So THE SQL IS UNEXERCISED: it sits in template strings, invisible to tsc and to eslint, and a statement that fails at PARSE time would still show 543 green tests. Do not read the green suite as a green detector. The unit tests prove the decision logic only. WHO CAN CLOSE THIS: db-terra-cc holds DATABASE_URL and already did the SCOPE201-mtwrt8 measurement. Expected live result on today's data: scopedCampos=3, activeCirugias=17, exclusions=9, allowlisted=9, findings=0, staleAllowlist=0, exit 0, printing "OK: every exclusion is accounted for". Any other number is either a real finding or a defect in my SQL, and the first run cannot tell those apart without reading the table it prints. STILL LOCAL: 70fa403 is committed but the push is blocked by push-scope-guard - 7 commits ahead of origin/main belong to db-terra-cc, coder-terra-cc, coder02-terra-cc and coder03-terra-cc. Clearance asked of all four (tag db02-terra-cc-mtwzf0nud1zn). The files are on disk and the commit is real regardless of who publishes the range. NOT MERGED, deliberately: the clinical question of WHICH cirugias should ask tipoBarrera/tipoInjerto/zonaDadora is Elazar's, refiled by coder-terra-cc as eq 95. Adding an entry to INTENTIONAL_EXCLUSIONS asserts a clinical fact and is not this row's business; the file says so in place.
• wi-cli-venus note · 5w ago
  T201-fix-mtwzq4 - db-terra-cc ran the three SELECTs live (their evidence file 2026-09-11-terra_201-detector-sql-live-results.result.md, marker T201-sqlrun-mtwzm). ALL THREE PARSE AND RUN, so the template-string risk I flagged is retired. The live rows match the predicted shape exactly: 6 active campos, 18 live scope rows all created 2026-08-22 19:04:40.950711+00, 172/179/180 absent from modulo 1's tipoInjerto and tipoBarrera, 181/182/183 absent from zonaDadora, and marcaImplante m1 plus tipoInjerto/tipoBarrera m2 carrying no scope rows at all. THEIR ONE DISCREPANCY, RESOLVED: CIRUGIAS_SQL returns 49, not the 17 I predicted. The query carries no moduloId predicate, so it fetches every active cirugia across all six modulos. The VERDICT is unaffected - computeExclusions skips any cirugia whose moduloId differs from the campo's, and modulos 3-6 have no campos, so their 32 cirugias can never produce a finding. The missing predicate is deliberate and stays: narrowing the query to the scoped modulos would make this check blind on the day a third modulo gains its first campo, which is this same defect one level up. BUT THE PRINTED COUNT WAS WRONG AND THEIR QUESTION IS WHAT FOUND IT. The script would have logged activeCirugias=49 while examining 17. A number that conflates FETCHED with EXAMINED is how 'the check ran' gets read as 'the check covered everything'. DriftReport now carries both activeCirugiaCount and consideredCirugiaCount, the log line prints activeCirugias=49 considered=17, and a new test pins the gap with a third modulo that has cirugias and no campos. SECOND DEFECT, MINE, AND IT WAS ALREADY IN 70fa403: four LITERAL NUL BYTES sat in campo-scope-drift-core.ts where the source reads \u0000. file(1) called it 'data' rather than text. tsc, eslint and 543 tests all passed, because a NUL is a legal character inside a JavaScript string - what breaks is every TEXT tool: git classifies the file binary so there are no line diffs and nothing reviewable in a hunk, and grep refuses it outright. Found only because 'command grep -n' answered 'binary file matches' when I went to quote one of my own lines into a message. Repaired with perl -0pi -e; all three files are UTF-8 text now. STATE: both fixes are on disk and UNCOMMITTED, on top of 70fa403. 13 tests green. Not committing while coder-terra-cc holds the serialized push - a new commit would lengthen the blocked range again. 70fa403 publishes as-is and this lands as a follow-up patch; rewriting shared history to tidy it is the worse trade, same call already made twice today on the TERRA-149 and TERRA-201 duplicates. STILL UNEXERCISED, unchanged by any of this: the script's own wiring - DATABASE_URL handling, the pg client, the camposForCirugia call as the script assembles it, the printed table and the exit codes. Neither lane has a DATABASE_URL; db-terra-cc reached the database through the Supabase MCP, which exercises the SQL and not the script. A role for one of our lanes is worth its own row.
• wi-cli-venus note · 5w ago
  T201-liverun-mtxle: the only gap left is the SCRIPT WIRING, never executed - pg client, DATABASE_URL guard, the detectCampoScopeDrift call as the script assembles it, console.table, exit codes. 13 unit tests reach none of it. db02-terra-cc holds no DB role (TERRA-241, child of this row, db-enamel-cc); db-terra-cc was provisioned db_terra_cc_ro at 15:13 and has been asked to run it once with DATABASE_URL="$PGURI" node scripts/check-cirugia-campo-scope-drift.ts. Expected: scopedCampos=3 activeCirugias=49 considered=17 exclusions=9 allowlisted=9 findings=0 staleAllowlist=0, exit 0. Not closing on green unit tests. END-T201-liverun-mtxle
• wi-cli-venus note · 5w ago
  T201-tls-mtxm9q | LIVE RUN, first ever, by db-terra-cc 2026-09-11 20:38Z with the provisioned db_terra_cc_ro DSN. RUN 1 (DSN exactly as provisioned, sslmode=require), exit 1: pg printed 'SECURITY WARNING: The SSL modes prefer, require, and verify-ca are treated as aliases for verify-full' and the script died before its first SELECT with '[cirugia-campo-scope-drift] FAIL: self-signed certificate in certificate chain'. RUN 2 (same DSN + uselibpqcompat=true), exit 0: '[cirugia-campo-scope-drift] scopedCampos=3 activeCirugias=48 considered=17 exclusions=9 allowlisted=9 findings=0 staleAllowlist=0' then 'OK: every exclusion is accounted for'. NO permission error in either run - db_terra_cc_ro reads terraModuloCampos, terraCirugias and terraCirugiaCampos fine, so nothing here feeds TERRA-241's role ask. activeCirugias=48 where I predicted 49: ordinary data movement since 11:xx, verdict unaffected because consideredCirugiaCount and the per-modulo guard make the total non-load-bearing; NOT diffed, and nobody should spend a query on it. The gap this row was held open for - the SCRIPT WIRING, never executed: pg client, DATABASE_URL guard, the detectCampoScopeDrift call as the script assembles it, console.table, exit codes - is now CLOSED by RUN 2. The defect the run found is OUTSIDE the decision core and is a DSN/TLS fact, not SQL.
• wi-cli-venus note · 5w ago
  T201-close-mtxmbh | CLOSING. The gap this row was held open for was the SCRIPT WIRING, never executed - pg client, DATABASE_URL guard, the detectCampoScopeDrift call as the script assembles it, console.table, exit codes. RUN 2 closed it (exit 0, scopedCampos=3 activeCirugias=48 considered=17 exclusions=9 allowlisted=9 findings=0 staleAllowlist=0, 'OK: every exclusion is accounted for'), and db-terra-cc has since re-run it clean on a verify-full DSN through node-pg. The one defect the live run surfaced was OUTSIDE the decision core - pg 8.22 aliasing sslmode=require to verify-full against a pooler chain signed by Supabase's own private root - and it is now documented IN the script rather than left as tribal knowledge. Pushed: 20a5d08 (parse table for every DSN form incl. the no-sslmode=plaintext case, public CA URL, the sslrootcert PARSE-time ENOENT and absolute-path traps, TLS-not-permissions hint on the connect path matching /certificate/i only so a pg_hba rejection is not mislabelled as non-permissions, exercised against a bogus-credential DSN; same short note on the vocabulary sibling) and faf2b44 (the acceptance standard corrected: \conninfo's SSL line prints identically under prefer so it does NOT discriminate verify-full - it takes two negative controls, a nonexistent sslrootcert path to prove the CA is read and an IP connection to prove the hostname check is enforced). NO ssl config is set in either script, deliberately: the DSN owns the transport posture and a detector that weakens TLS to get itself green is worse than one that fails. SIN CAMBIO DE CODIGO NI DE DATOS held throughout - three SELECTs, no DDL, no writes, no transaction. Counting note preserved: cirugia counts split by isActive, not by deletedAt IS NULL. The clinical question about WHICH cirugias should ask tipoBarrera/tipoInjerto/zonaDadora remains eq 95 with Elazar and was NOT merged into this row. Not diffed: activeCirugias moved 49->48 between 11:xx and the live run, ordinary data movement, verdict unaffected because consideredCirugiaCount and the per-modulo guard make the total non-load-bearing.
• wi-cli-venus completed · 5w ago
• wi-cli-venus verified · 4w ago
  CONTROL-A-DID-NOT-FIRE-DB02-2026-09-12-Q4M8: the acceptance control in the pushed header (577fdb4) certified file-open, not TLS verification. A nonexistent sslrootcert dies before any chain check - psql 'root certificate file ... does not exist', node-pg a bare ENOENT from the DSN parser. The control that fires needs an EXISTING file with WRONG roots (/etc/ssl/certs/ca-certificates.crt): psql 'SSL error: certificate verify failed', node-pg 'self-signed certificate in certificate chain'. Both forms exit non-zero, so it read as green. Caught by db-enamel-cc. Header fixed in a88549a (local, Local-Author: db02-terra-cc, with coder-terra-cc to push); nonexistent-path form demoted to A' and labelled a typo check. Positive run re-verified: scopedCampos=3 activeCirugias=48 considered=17 exclusions=9 allowlisted=9 findings=0 staleAllowlist=0, exit 0. Rule persisted: a control that refuses EARLIER than the stage it certifies is not a control - read the wording, never the exit code.
• wi-cli-venus note · 4w ago
  PUSHED-A88549A-DB02-2026-09-12-R2N6: the control-A correction is on main - coder-terra-cc pushed 577fdb4..ffefbac, a88549a alone in the range plus the version bump. Supersedes the 'local, with coder-terra-cc to push' line in the preceding verified event. Nothing further outstanding on this row from db02-terra-cc.
• wi-cli-venus note · 4w ago
  STOP-PARK-DB02-2026-09-12-S8L4: fleet-wide STOP received from pmmaster-evolutiva-cc (relayed Elazar, 2026-09-11 23:57 ART), stopping at a natural break. DONE: TERRA-201 header corrections shipped - 01f4775 (client-specific control-B refusal text, node-pg SNI mechanism) and a88549a (control A certified file-open not TLS verification; wrong-roots form promoted to A, nonexistent-path form demoted to A' as a typo check), both on main via coder-terra-cc, range ends ffefbac. TERRA-241 acceptance verified and DM'd. Schema-hop correction measured on db_terra_cc_ro and db02_terra_cc_ro together and persisted. NOT DONE: nothing in flight, no uncommitted work of mine, no unpushed commits, not broken. Two untracked db/migrations/dryrun/2026-09-01-terra_182-* files predate this session and are not this lane's - left alone deliberately. NEXT ACTION on resume (needs Elazar's word, not pmmaster's): none owned on this row; open items routed elsewhere are db-venus-cc.env sslmode=require (nw-venus-cc), the 13 unencrypted DSNs in .config/applog + .config/dbperf + .config/pm-triage needing an owner named, mars.env.bak-2026-09-12 holding a cleartext DSN, and rotation of the postgres owner role which is Elazar's call and explicitly not an agent action.