Cedula y libreta de enrolamiento: activas en el catalogo y fuera del scope include de documentoType - TERRA-203 se cancelo sin contestar si eso es deliberado

Sub-tickets

Activity

• wi-cli-venus created · 5w ago
• wi-cli-venus audit-finding · 5w ago
  LIVE CATALOG READ DONE - THE GAP IS REAL, AND IT IS WIDER THAN THE QUESTION ASKED. Marker: T217-catalog-mtwxq1. Read against the live database 2026-09-11, not against src/ or a migration file. ANSWER TO THE QUESTION AS PUT: yes, both values are still ACTIVE and still out of scope. public.lookupOptions category documentoType holds five rows, all isActive=true, all deletedAt NULL, all with createdAt = updatedAt = 2026-07-27 13:39:51.852809+00 - so not one of them has been touched since the original seed: dni(10), pasaporte(20), cedula(30), libretaCivica(40), libretaEnrolamiento(50). public.vocabularyScopeMembers for that category holds exactly two rows, terra:dni and terra:pasaporte, both created 2026-08-07 18:27:09.544829+00. No other appKey scopes this category at all - enamel included. So cedula and libretaEnrolamiento are active-and-unscoped, and libretaCivica is in the identical state despite the 2026-09-10 ruling that removed it from the product. Nothing in the catalog distinguishes deliberate from forgotten; the three unscoped rows are byte-identical in every column that could carry an intention. AND THE ASYMMETRY IS NOT READ-ONLY, WHICH IS THE PART WORTH ESCALATING. The form list and the write path do not consult the same object. getTerraPracticaFormCatalogs builds the documentoType picker from resolveScopedVocabulary(appKeyArg,'documentoType'), which returns exactly dni and pasaporte - verified by calling it live. resolveOrCreatePaciente validates with a bare EXISTS against lookupOptions on category + value + deletedAt IS NULL + isActive, and NEVER READS vocabularyScopeMembers. So the scope include governs what the form OFFERS and governs nothing about what the database ACCEPTS: any caller reaching the boundary function with documentoType='libretaCivica' creates that paciente successfully, on a value Elazar removed from the product yesterday. The function's own comment says this is the column that decides which identity NAMESPACE the number lives in, so a value the product does not recognise partitions the uniqueness index in a namespace nobody will search. There is no trigger guard on either table for this column - public.pacientes carries no non-internal triggers at all, and public.users carries only tg_users_closeGroupsOnDelete, trg_users_setUpdatedAt and the new tg_users_recordEmailHistory. The four routines mentioning documentoType are createTerraPractica, getTerraPracticaFormCatalogs, lookupTerraPaciente and resolveOrCreatePaciente. Validation lives entirely in the boundary function, and that is the one place the scope is not checked. USAGE, so the decision is not taken in the abstract: users.documentoType is dni x153 and NULL x6 across 159 rows; pacientes.documentoType is dni x6 across 6 rows. Zero rows anywhere hold cedula, libretaCivica or libretaEnrolamiento. So deactivating any of the three today orphans no existing record, and no data migration is implied by any option below. lookupOptions.ownerAppKey is NULL on all five rows - this is shared vocabulary, not terra-owned, so a change to the option rows themselves is not terra's unilateral write. WHAT IS NOW OWED, and it is two separate decisions, not one. (A) The catedra question coder02 filed this for: does terra accept Cedula de Identidad and Libreta de Enrolamiento? If both are no, the close is to deactivate them and the include needs no change. If either is yes, the include gains a member, which is a guarded vocabulary write through the citation gate per terra_209 - explicitly out of scope for this row. (B) The one this read surfaced and nobody has ruled on: should resolveOrCreatePaciente validate against the app's scope rather than against the global option list? Today libretaCivica is writable by construction. That is a code change in an enamel-owned boundary function, so it is a db-enamel-cc ask, not a terra edit. NOT COVERED, stated so this is not read as exhaustive: I read the catalog, the two routines named above and the row counts. I did not exercise the write path - this lane is SELECT-only on this database - so 'libretaCivica is accepted' is derived from the function's literal validation predicate, not from an observed insert. I also did not check terra's src/ for a second client-side filter; a TypeScript-level allowlist could narrow the form further without appearing in either object above.
• wi-cli-venus blocked · 5w ago
  The live read is DONE and is on the row (marker T217-catalog-mtwxq1); what remains is a decision, not a measurement, so nothing here is waiting on this lane. MEASURED: cedula and libretaEnrolamiento are both isActive=true, deletedAt NULL, untouched since the 2026-07-27 seed, and absent from the terra scope include, which has held exactly dni and pasaporte since 2026-08-07. libretaCivica is in the identical state despite being ruled out of the product on 2026-09-10. Zero rows in users or pacientes hold any of the three, so deactivating any of them orphans nothing. BLOCKED ON (A), ELAZAR/CATEDRA: does terra accept Cedula de Identidad and Libreta de Enrolamiento? Both no closes this row by deactivating them and leaves the include alone. Either yes adds a member to the include, which is a guarded vocabulary write through the citation gate per terra_209 and is out of scope here. SURFACED, NOT BLOCKING THIS ROW - needs its own: resolveOrCreatePaciente validates documentoType with a bare EXISTS against lookupOptions and never reads vocabularyScopeMembers, while the form picker comes from resolveScopedVocabulary. The include therefore governs what is OFFERED and nothing about what is ACCEPTED, so libretaCivica is writable today. That is a change to an enamel-owned boundary function and belongs to db-enamel-cc. lookupOptions.ownerAppKey is NULL on all five rows: shared vocabulary, so the option rows are not terra's unilateral write either.
• wi-cli-venus note · 5w ago
  THE CATEDRA PREMISE OF THIS ROW IS GONE, AND THE ROW SURVIVES IT SMALLER. Marker: T217-premise-mtwy1. WHAT THIS ROW ASKED: are cedula and libreta de enrolamiento still active in the catalog and still outside terra's documentoType scope, and if so does the catedra want each one in or out. Both halves rested on the assumption that a value active in the catalog but outside the scope is a live product hole. WHAT THE LIVE READ FOUND (db-terra-cc, marker T217-catalog-mtwxq1, then re-verified by db-enamel-cc before filing ENAMEL-34): the drift is real - all five options are isActive, ownerAppKey NULL, untouched since the 2026-07-27 seed, and terra's include scope holds exactly dni and pasaporte since 2026-08-07. But the scope include governs the PICKER and nothing else. resolveOrCreatePaciente validates with a bare EXISTS against lookupOptions and never reads vocabularyScopeMembers, so all three unscoped values are creatable through the boundary function today, one day after libreta civica was removed from the product. documentoType is half the identity pair in ux_pacientes_documento_live, so an unrecognised value partitions the uniqueness index into a namespace nobody searches. pacientes has no non-internal triggers, no CHECK on documentoType and no outgoing FKs, so validation lives entirely in that one function. THE FIX IS ENAMEL-34 AND IT IS NOT A DECISION ABOUT VALUES. Validate the write path through resolveScopedVocabulary(appKeyArg, 'documentoType') so accept equals offer per appKey by construction. No catedra call, no shared-row mutation, no data migration. I PROPOSED THE WRONG LEVER FIRST AND THE CORRECTION IS THE DURABLE PART. I suggested deactivating the three unscoped options, on the measurement that zero rows anywhere hold any of them. The counts are right and the conclusion does not follow: I measured blast radius on stored rows when the damage lands on another tenant's offer. resolveScopedVocabulary is DEFAULT-OPEN - its own SQL reads that a null mode means all active values - and enamel holds no scope row for documentoType at all, so enamel is offered all five right now. Deactivating the three strips them from enamel too, which makes the global catalog the arbiter of a per-tenant product call: the same category error the bug is made of. Before proposing to deactivate a shared vocabulary row, enumerate every appKey the resolver would answer for, including the unscoped ones, because those are precisely the ones silently receiving everything. WHAT IS LEFT ON THIS ROW, AND IT IS SMALL: whether terra wants cedula or libreta de enrolamiento ADDED to its own include scope. That is a picker change against terra's own scope row, not a shared-row mutation and not a question about the catalog. It is still a product call and still not mine, but it is no longer blocking anything, because under ENAMEL-34 an unscoped value stops being writable regardless of how it is answered. NOT IN SCOPE HERE: libreta civica, resolved by Elazar on 2026-09-10; the ENAMEL-34 migration itself, which is db-enamel-cc's and needs the old 9-arg signature DROPped in the same transaction rather than CREATE OR REPLACE, since the ungated overload stays live and granted to service_role; and the terra-side call site in createTerraPractica, which moves in the same window and whose lane is being settled with db-terra-cc now.
• wi-cli-venus assigned · 5w ago
  db02-terra-cc
• wi-cli-venus note · 5w ago
  T217-provenance-mtwy4 - documentary half answered by db02-terra-cc. The live catalog half is db-terra-cc's (T217-catalog-mtwxq1) and was NOT re-run; this lane has no DB (Supabase MCP at the OAuth wall). VERDICT: the narrowing IS deliberate at the CATEGORY level and the citation exists - it is src/lib/lookups.ts:429-444, which quotes Elazar directly via brainstorm bs-msj85aianit: 'a ton of options that nobody approved'. Same brainstorm, same day, a second category: terra_30_piezas_exclude_deciduous.sql:10 flips piezasDentarias exclude->include 'on 2026-08-07 (bs-msj85aianit)'. The documentoType include row was created 2026-08-07 18:27:09.544829+00 - the same day. 2026-08-07 was a vocabulary-narrowing session with Elazar covering more than one category, and that is the link terra_209 never makes. STOP CITING terra_209:33-37. Its 'terra's scope deliberately does not select' cites nothing - it is the author's own characterization of a state they observed. libretaCivica sat in that identical 'deliberate' state and still needed a separate Elazar ruling on 2026-09-10; had it been a decision on record, that ruling would have been a lookup. INDEPENDENT HALF (db-terra-cc, TERRA-198, 2026-09-05): all five options share createdAt 2026-07-27 13:39:51.852809+00, the scope row landed eleven days later - the scope was chosen with all five already visible and stable, which is the signature of a decision and not a forgotten sync. I re-confirmed its stated limit: no terra migration writes those two membership rows. Only 'dni' hits in applied are test probes (terra_27:199, a comment at terra_42:193); terra_1_seed_vocabulary.sql has no documentoType at all. Terra never authored the include. WHAT IS STILL NOT DOCUMENTED, and do not overstate the verdict: Elazar ordered the NARROWING. Nothing anywhere names dni+pasaporte as the approved pair, and nothing records cedula or libretaEnrolamiento as considered and rejected. lookups.ts's own line cuts both ways - 'the default is open, which makes approved-all-of-them and never-considered-it the same state from outside' applies equally to the two that were kept. CLIENT COMMUNICATIONS: terra/pm/** has zero occurrences of cedula, libreta or enrolamiento. The one client-authored artefact is an xlsx, which grep cannot see into; opened it - xl/sharedStrings.xml holds 13 DNI, zero cedula/libreta/pasaporte. The client's own form is DNI-only. That does not authorise removing pasaporte (the identity key is the pair (documentoType, normalized documentoNumber) and a foreign student is why it is there), but it is where the client material sits. COVERAGE: all 1823 events on all 216 terra rows (full history to 2026-07-30, not a window), terra/pm/** including the xlsx interior, src/**, migrations applied+draft, db/schema-live.md, shared/. NOT searched and it is the only place a contradicting record could still live: enamel's repo and WI board - documentoType is enamel's category and the membership rows were not written from here. CONSEQUENCE: this row asks two questions and only one is terra's. Whether terra OFFERS the values is terra's and a 'no' closes it with ZERO writes. Whether the catalog rows are deactivated is enamel's regardless - and deactivation is the wrong lever three ways: ownerAppKey NULL, resolveScopedVocabulary is DEFAULT-OPEN and enamel holds no scope row so enamel is offered all five today and would lose them too, and lookups.ts:437-441 already records coder-enamel-cc's ruling that terra NEVER deactivates one of these rows. Terra's only reversible lever is its own include row. Refile precedent for the enamel half is TERRA-216 -> ENAMEL-31. Full evidence: terra/agents/db02-terra/evidence/2026-09-11-TERRA-217-documentotype-provenance.md
• wi-cli-venus assigned · 5w ago
  coder-terra-cc
• wi-cli-venus unblocked · 5w ago
  cleared: The live read is DONE and is on the row (marker T217-catalog-mtwxq1); what remains is a decision, not a measurement, so nothing here is waiting on this lane. MEASURED: cedula and libretaEnrolamiento are both isActive=true, deletedAt NULL, untouched since the 2026-07-27 seed, and absent from the terra scope include, which has held exactly dni and pasaporte since 2026-08-07. libretaCivica is in the identical state despite being ruled out of the product on 2026-09-10. Zero rows in users or pacientes hold any of the three, so deactivating any of them orphans nothing. BLOCKED ON (A), ELAZAR/CATEDRA: does terra accept Cedula de Identidad and Libreta de Enrolamiento? Both no closes this row by deactivating them and leaves the include alone. Either yes adds a member to the include, which is a guarded vocabulary write through the citation gate per terra_209 and is out of scope here. SURFACED, NOT BLOCKING THIS ROW - needs its own: resolveOrCreatePaciente validates documentoType with a bare EXISTS against lookupOptions and never reads vocabularyScopeMembers, while the form picker comes from resolveScopedVocabulary. The include therefore governs what is OFFERED and nothing about what is ACCEPTED, so libretaCivica is writable today. That is a change to an enamel-owned boundary function and belongs to db-enamel-cc. lookupOptions.ownerAppKey is NULL on all five rows: shared vocabulary, so the option rows are not terra's unilateral write either.
• wi-cli-venus decision · 5w ago
  DECIDED - NO. THE INCLUDE ROW STAYS AT dni + pasaporte, ZERO WRITES. Marker: T217-dec-mtwz08. Decided by the terra PM lane 2026-09-11 under Elazar's 09:27 ART standing delegation, on db02-terra-cc's measurement (T217-provenance-mtwy4). Not Elazar's wording; overrule this row specifically if wrong. THE QUESTION: whether terra's vocabularyScopeMembers include row for the documento-type vocabulary should be widened to admit cedula and libretaEnrolamiento alongside dni and pasaporte. WHY NO: 1. ZERO DEMAND IN REAL DATA. The client's own roster xlsx is DNI-only - 13 DNI, zero cedula, zero libretaEnrolamiento, zero pasaporte. Not one person in the material the catedra actually supplied presents a document the current pair cannot record. Widening would add options nobody has asked for and nobody would select. 2. THE NARROWING IS TRACEABLE TO A RULING, and the ruling is against exactly this move. src/lib/lookups.ts:429-444 quotes Elazar via bs-msj85aianit: "a ton of options that nobody approved". Adding two more unrequested options is the thing that sentence refuses. The same brainstorm flipped piezasDentarias the same day, so the narrowing is a pattern applied deliberately across vocabularies, not an accident on one. 3. A NO COSTS NOTHING AND IS FULLY REVERSIBLE. It closes with zero writes. A YES is a guarded vocabulary write that needs a GO through the citation gate, on behalf of a user who does not exist yet. THE RESIDUE IS REAL AND IS RECORDED RATHER THAN RESOLVED: nothing in terra/pm/ names dni+pasaporte as the APPROVED pair, and nothing records cedula or libretaEnrolamiento as REJECTED. db02-terra-cc is right that the "deliberate" reading rests on the brainstorm quote and not on a documented decision about these four values specifically - libretaCivica sat in that same state and still needed Elazar's 2026-09-10 ruling. So this answer is a PM default standing in for a decision the client never made, not the discovery of one. THE CONDITION THAT REOPENS IT, so nobody has to re-derive it: a real person enrolling who presents a document that is neither DNI nor passport. On 1/10 that is a foreign or provincial student. When it happens the fix is one include-row write, and the requester exists, which is the whole difference. WHAT THIS DOES NOT TOUCH, per db02-terra-cc and not re-litigated here: deactivation is not the lever. ownerAppKey is NULL, resolveScopedVocabulary is default-open, enamel holds no scope row, so deactivating would strip all three from enamel too - and lookups.ts:437-441 already carries coder-enamel-cc's ban on it. Terra's only lever is its own include row, and this decision leaves it untouched. Also correcting a citation that would otherwise propagate: stop citing terra_209:33-37 for the narrowing. It cites nothing itself. The citable source is lookups.ts:429-444 quoting bs-msj85aianit, plus terra_30:10 for the same-day piezasDentarias flip; the include row landed 2026-08-07 18:27:09Z. lookups.ts:429-444 is STALE AS STATE - it says "UNSCOPED TODAY" and that is no longer true - so read it as the ask and cite it only for the quotation.
• wi-cli-venus completed · 5w ago
  Policy call answered NO (T217-dec-mtwz08): documento-type include row stays dni+pasaporte, zero writes. Both measurement halves were already done by db02-terra-cc; nothing remained but the decision. Reopen condition written on the row: a real enrollee presenting neither DNI nor passport.