La base no tiene marcador de vocabulario provisorio, asi que una direccion del chequeo es indetectable
AUTHORIZED by pmmaster-evolutiva-cc on Elazar's behalf 2026-09-11. SPLIT OUT of TERRA-192, which stays blocked. Read that carefully before touching either row: TERRA-192's sentence is 'tipoBarrera fuera de /informes y la justificacion de agrupamiento que solo cubre la mitad de los casos' and it is genuinely the catedra's - whether tipoBarrera enters /informes and how its two categories group. THIS row's sentence is the other half db-terra-cc named: the database carries no marker saying a vocabulary is PROVISIONAL, so one direction of the check cannot be observed at all. Closing this must not close TERRA-192, and TERRA-192's eventual answer does not close this. WHY IT IS AUTHORIZED WITHOUT THE CATEDRA. The blockedReason said 'producto debe autorizar el marcador persistente y su semantica antes de una migracion'. I am product for this purpose under Elazar's 09:27 grant, and this is the reversible direction: a marker is metadata about a vocabulary, it changes no clinical value, it is droppable, and while it is absent nobody can tell a settled vocabulary from a provisional one - which is exactly the undetectable direction db-terra-cc identified. Adding it costs a migration; not adding it costs the ability to ever ask the question. SEMANTICS, so they are not invented later: the marker states that the SET OF ALLOWED VALUES is provisional and may be replaced, NOT that any individual stored value is doubtful. It lives with the vocabulary definition, not on the practica rows. Default for an existing vocabulary is provisional=TRUE, because every vocabulary currently in the database arrived without anyone being asked to ratify it, and defaulting to settled would silently certify all of them. Clearing the flag is an act someone performs, with a date and an actor. ACCEPTANCE: after the migration, a query can answer 'which vocabularies are provisional' and return a non-empty set, and the answer for a vocabulary nobody has ratified is provisional rather than absent. NULL is not an acceptable third state here - a nullable flag reproduces the undetectable direction this row exists to remove. Class-A review before apply, as usual. Do not apply anything to /informes; that is TERRA-192.
Activity
-
Draft written: db/migrations/draft/terra_224_vocabulary_provisional_ratification.sql. Design B (audit-terra-cc-mtwz39idi4va): new terra-owned table terraVocabularyRatifications, FK to vocabularyScopes(appKey,category), view vTerraVocabularyProvisional derives isProvisional via NOT EXISTS - no third state, no backfill. No enamel GO taken (new terra-owned table, vocabularyScopes structure untouched). Sent to audit-terra-cc for Class-A review.
-
Class-A PASS (audit-terra-cc-mtwzd0z9ow2y): live schema matched draft's stated facts, users.id uuid PK confirmed, scope guard doubly enforced. Cleared to apply. Handed off to db-terra-cc.
-
db-terra-cc did not apply: f8b667c ships a code-side detection gate for TERRA-192 item 2 (lookupCategory must be classified in terraModuloCampos or npm test fails), so the original premise (detection needs a DB marker) no longer holds. What terraVocabularyRatifications could still be for is narrower - recording WHO ratified a vocabulary and WHEN, which the gate does not do. db-terra-cc put that to pmmaster as a new product decision rather than deciding unilaterally. Draft untouched in draft/. Blocked on pmmaster ruling.
-
NO SE APLICA, Y NO SE CANCELA. Fallo de pmmaster-evolutiva-cc 2026-09-11 10:25 ART, relayado a db-terra-cc que tenia el handoff de apply de db03-terra-cc. Marcador T224-hold-mtwzn. POR QUE NO SE APLICA: la ratificacion persistente de vocabulario provisorio NO hace falta para DETECTAR. Una lookupCategory solo llega a terraModuloCampos por una migracion aplicada, asi que el corpus de migraciones ES la lista completa de categorias que existieron alguna vez, y un chequeo de TOTALIDAD sobre esa enumeracion obliga a clasificar cada una en codigo - provisional, confirmada o retirada - o npm test se pone rojo. Eso ya esta verde en f8b667c (src/lib/campo-provenance-migration-guard.test.ts, TERRA-192). O sea que esta migracion no arregla nada que hoy este roto. POR QUE TAMPOCO SE CANCELA NI SE RE-FILA: 'quien ratifico un vocabulario y cuando' es una pregunta REAL que el gate no contesta y no puede contestar - el gate obliga a que el juicio se haga, no registra quien lo hizo ni en que fecha ni contra que fuente. Eso puede valer una tabla. Pero es una decision de producto sobre una tabla nueva, por sus propios meritos, y NO heredada del bloqueo de TERRA-192 que la pedia, porque ese bloqueo ya no existe. No es urgente y no la fuerza este carril. ESTADO DEL ARCHIVO: db/migrations/draft/terra_224_vocabulary_provisional_ratification.sql se queda donde esta, sin tocar, con su revision de audit-terra-cc intacta. Tabla nueva terra-owned mas vista, sin cambios a vocabularyScopes, asi que no necesita GO de enamel el dia que se decida.
-
Espera UN fallo de pmmaster-evolutiva-cc y nada mas: si terraVocabularyRatifications sigue queriendose para registrar QUIEN ratifico un vocabulario provisorio y CUANDO. La premisa original - que hacia falta un marcador en la base para DETECTAR - murio con f8b667c, que pone la deteccion en codigo via un chequeo de totalidad sobre el corpus de migraciones. La Class-A PASS ya esta dada (audit-terra-cc-mtwzd0z9ow2y) y el draft esta intacto en draft/, asi que un SI se aplica sin re-auditar. Un NO cancela la fila. Nadie mas esta bloqueado por esto.
-
CANCELLED. The reversal condition was tested and it is FALSE. Marker: T224-cancel-mtx26. RULING: pmmaster-evolutiva-cc 2026-09-11 11:34 ART, on Elazar's behalf. terraVocabularyRatifications is not built. Detection moved into code as a totality check over the migration corpus (f8b667c), so a vocabulary's ratified state is expressed AS A MIGRATION - and git already records who and when, authoritatively, for every migration. A ratifications table would be a SECOND record of the same fact that can drift from the first, with zero consumers today. A provenance table that disagrees with git is WORSE than no provenance table, because the disagreement is silent and the reader cannot tell which side is wrong. THE NAMED REVERSAL CONDITION: "ratification can occur WITHOUT a corresponding migration - someone can ratify a provisional vocabulary through a path that leaves no commit." I was told to settle it with one grep and reverse on my own authority if it came back true. IT CAME BACK FALSE. Measured: - ZERO write paths in src/ or scripts/. Every hit for INSERT/UPDATE on lookupOptions, terraModuloCampos, vocabularyScopeMembers, vocabularyScopes or terraCirugiaCampos is a TEST ASSERTING A GUARD AGAINST SUCH A WRITE - vocabulary-scope-migration-guard.test.ts and campo-provenance-migration-guard.test.ts. The app cannot write vocabulary at all. - Every real INSERT lives inside an applied migration: terra_1, terra_31, terra_33, terra_35, terra_38. - No DB function inserts vocabulary. The functions matching those names are GUARDS and triggers - fn_vocabularyScopeMembersIntegrityGuard, fn_lookupOptionsForbidOrphaningScopeMembers, fn_terraModuloCamposDefinitionGuard, fn_terraComplicacionesVocabGuard, fn_terraParticipantesVocabGuard - which refuse writes rather than perform them. So every sanctioned ratification IS a commit, and git carries it. The ruling stands without reversal. THE ONE RESIDUAL, STATED RATHER THAN HIDDEN, BECAUSE IT ALSO ARGUES FOR CANCEL: a human with direct database access could INSERT a vocabulary row by hand, outside any migration, and neither git nor a ratifications table would record it - THE HAND-INSERT WOULD SKIP THE RATIFICATIONS TABLE TOO. So the table does not close that hole either; it would only create a second place to be silently incomplete. What actually covers it is the existing guard layer plus the standing rule that agents hold SELECT only and the db lane applies through migrations. WHAT SURVIVES THE CANCEL: nothing is lost that anyone was using. The narrower purpose db-terra-cc raised when it declined to apply - recording WHO ratified and WHEN, which the code-side gate does not do - is exactly the fact git records, and that is the whole of the ruling's reasoning. Class-A PASS (audit-terra-cc-mtwzd0z9ow2y) stood and stays on the record; the draft in db/migrations/draft/ is untouched and unapplied. If the premise ever revives - a genuine ratification path that leaves no commit - the PASS means it applies without re-auditing. That is the only condition that reopens this.
-
cleared: Espera UN fallo de pmmaster-evolutiva-cc y nada mas: si terraVocabularyRatifications sigue queriendose para registrar QUIEN ratifico un vocabulario provisorio y CUANDO. La premisa original - que hacia falta un marcador en la base para DETECTAR - murio con f8b667c, que pone la deteccion en codigo via un chequeo de totalidad sobre el corpus de migraciones. La Class-A PASS ya esta dada (audit-terra-cc-mtwzd0z9ow2y) y el draft esta intacto en draft/, asi que un SI se aplica sin re-auditar. Un NO cancela la fila. Nadie mas esta bloqueado por esto.
-
completed