Enamel cannot register any paciente: the ForApp write path is fail-closed and enamel has no documentoType vocabularyScopes row - needs one product decision on which document types enamel accepts

Sub-tickets

Activity

• wi-cli-venus created · 5w ago
  parent=#2557
• wi-cli-venus verified · 4w ago
  MEASURED LIVE 2026-09-12 on eprpywqwzsvrjeaforei. Item (1) IS DONE: ENAMEL-34 phase 2 landed - enamel_054 (ENAMEL-36) dropped the ungated 9-arg public.resolveOrCreatePaciente, applied 2026-09-11 16:52 UTC, pushed 0d4171b, Class-A PASS by audit-terra-cc. The 9-arg is absent in every schema at every arity and no pg_proc body still names it. Item (2) STANDS AND IS CORRECTLY STATED AS FAIL-CLOSED - I initially read it the other way and was wrong. Forced both control arms in one aborted DO block, so nothing was written: resolveOrCreatePacienteForApp(enamel,dni,...) raises "no documentoType scope defined for appKey enamel: refusing to fall through to the global catalog (ENAMEL-34). Add a vocabularyScopes include row for this app before it may register pacientes." and resolveOrCreatePacienteForApp(terra,cedula,...) raises "documentoType cedula is not offered to appKey terra". The gate is TWO steps and only step 2 goes through resolveScopedVocabulary: step 1 reads vocabularyScopes DIRECTLY and refuses on zero rows, precisely because resolveScopedVocabulary is default-open on a LEFT JOIN miss. Measuring resolveScopedVocabulary alone says enamel is offered all five and terra two, which is TRUE and DOES NOT DESCRIBE THE CALLER - the function refuses enamel before it ever consults it. So enamel cannot register any paciente today, by design, until the scope row exists. THE FIX, unchanged from the description: one vocabularyScopes row (enamel, documentoType, include) plus vocabularyScopeMembers for the chosen values. Zero users and zero pacientes rows hold any of the three unscoped values (cedula, libretaCivica, libretaEnrolamiento), so it orphans nothing and needs no data migration. DO NOT instead deactivate those three lookupOptions rows - ownerAppKey is NULL on all five so they are SHARED vocabulary, and deactivating makes the global catalog the arbiter of a per-tenant product decision, the exact category error ENAMEL-34 was filed against. REMAINING BLOCKER is one enamel product call: which document types enamel accepts. Terra equivalent is a catedra decision on TERRA-217. It is data in a shared table, so it needs the announce-before + ACK VERIFIED path under enamel-commons Auth Co-Tenancy rule 3, not a unilateral DB-lane change.
• wi-cli-venus priorityChanged · 4w ago
  1
• wi-cli-venus assigned · 4w ago
  db-enamel-cc
• wi-cli-venus blocked · 4w ago
  Blocked on ONE enamel product decision: which documentoType values enamel accepts (of dni, pasaporte, cedula, libretaCivica, libretaEnrolamiento). The DB side is done and measured - resolveOrCreatePacienteForApp is fail-closed and refuses every enamel call until a vocabularyScopes row exists, so enamel patient creation is hard-blocked, not degraded. The fix is one insert once someone decides, and it orphans nothing (zero users and zero pacientes rows hold any unscoped value). Not a unilateral DB-lane change: shared table, needs announce-before + ACK VERIFIED under enamel-commons Auth Co-Tenancy rule 3. Terra equivalent is TERRA-217.
• wi-cli-venus titleChanged · 4w ago
  Enamel cannot register any paciente: the ForApp write path is fail-closed and enamel has no documentoType vocabularyScopes row - needs one product decision on which document types enamel accepts
• wi-cli-venus blocked · 4w ago
  coder02-enamel-cc declines the documentoType list from the coder lane: same class as ENAMEL-51..55, product/legal not engineering default. Routed to pm-enamel-cc (NO ROSTER ROW on the hub - unregistered, DM returns stored_partial/recipient_not_registered) or Elazar. Blocker stands unchanged: which of dni, pasaporte, cedula, libretaCivica, libretaEnrolamiento enamel accepts. Probe residue re-measured after the forced gate control: 0 rows in pacientes matching probe-never-commits% - nothing was written.
• wi-cli-venus decision · 4w ago
  RULED by pmmaster-evolutiva-cc under Elazar's standing GO 2026-09-11 09:22/09:27, not escalated: enamel accepts documentoType dni and pasaporte only. Excluded: cedula, libretaCivica, libretaEnrolamiento. Coverage reasoning: DNI is mandatory for residents, so any holder of a libreta civica or de enrolamiento (issuance ended 1968, holders 58+) also holds a DNI, and cedula is provincial or foreign rather than a national identity document - none of the three reaches a patient DNI plus pasaporte does not. The decisive argument is duplication, not coverage: every additional documentoType is another axis on which one human becomes two pacientes rows, and enamel has NO same-person merge - ENAMEL-40 established that the admin surface cannot tell two accounts are one person and now states that limitation in its own caption. Adding a type later is a single vocabularyScopeMembers row and orphans nothing; un-creating duplicate patient records is not reversible, so narrow-now is the recoverable direction. Build constraints: one vocabularyScopes (enamel, documentoType, include) row plus vocabularyScopeMembers for dni and pasaporte; announce-before and ACK VERIFIED per enamel-commons Auth Co-Tenancy rule 3 since the table is shared; do NOT deactivate the unscoped lookupOptions rows, ownerAppKey is NULL on all five and terra reads them. TERRA-217 is the same decision and must not diverge by accident - db-enamel-cc reports whether terra's answer should differ and I rule that separately rather than letting it be inherited. Decidable in one message because db-enamel-cc forced BOTH arms of the fail-closed gate, quoted the exact raise text for each, and re-measured that zero probe rows were written.
• wi-cli-venus unblocked · 4w ago
  cleared: Blocked on ONE enamel product decision: which documentoType values enamel accepts (of dni, pasaporte, cedula, libretaCivica, libretaEnrolamiento). The DB side is done and measured - resolveOrCreatePacienteForApp is fail-closed and refuses every enamel call until a vocabularyScopes row exists, so enamel patient creation is hard-blocked, not degraded. The fix is one insert once someone decides, and it orphans nothing (zero users and zero pacientes rows hold any unscoped value). Not a unilateral DB-lane change: shared table, needs announce-before + ACK VERIFIED under enamel-commons Auth Co-Tenancy rule 3. Terra equivalent is TERRA-217.
• wi-cli-venus spec · 4w ago
  RULED + AUTHORED, apply gated on co-tenancy ACK. pmmaster-evolutiva-cc (tag pmmaster-evolutiva-cc-mtxr7645ux2b, Elazar standing GO): enamel accepts dni + pasaporte only; NOT cedula/libretaCivica/libretaEnrolamiento. Argument is DUPLICATION not coverage - documentoType is half of ux_pacientes_documento_live and enamel has no same-person merge (ENAMEL-40), so every extra type is another axis on which one human becomes two pacientes rows; adding a type later is one row and orphans nothing, un-creating duplicates is not reversible. TERRA-217 is already done at the identical pair (T217-dec-mtwz08, 2026-09-11) so the two tenants converge by independent decision, not by copying. File db/migrations/enamel_062_enamel_documentotype_scope.sql authored: one vocabularyScopes include row + two vocabularyScopeMembers rows, scope first per fk_vocabularyScopeMembers_scope, zero writes to lookupOptions (all five rows are ownerAppKey NULL i.e. shared, terra reads them). Dry run of the full file in one rolled-back transaction: ACC0-ACC6 green - members=dni,pasaporte, enamel/cedula refused at STEP 2 with "documentoType cedula is not offered to appKey enamel" where the pre-state was the step-1 no-scope-row text on BOTH arms, terra member set unchanged as a measured before/after difference, 0 probe pacientes rows. Post-rollback re-measured clean: enamel_scopes=0, enamel_members=0. Announce-before sent to db-terra-cc per Auth Co-Tenancy rule 3, tag db-enamel-cc-mtxrj6f9xymc; apply + push on ACK VERIFIED.
• wi-cli-venus completed · 4w ago
  completed
• wi-cli-venus commit · 4w ago
  enamel_062 applied + registered in one transaction (version 20260912023021, md5 6d442d02e507c20675b5b7f9373aa2f1 byte-exact against the file) and pushed af35802 / v0.13.1. Live: vocabularyScopes('enamel','documentoType','include') + members {dni, pasaporte}; ACC0-ACC6 green in-file; zero lookupOptions writes; terra/documentoType unchanged at {dni,pasaporte}; 0 probe rows. Ruled dni+pasaporte only by pmmaster-evolutiva-cc (tag pmmaster-evolutiva-cc-mtxr7645ux2b) on the DUPLICATION axis, not coverage: documentoType is half of ux_pacientes_documento_live's identity pair and enamel has no same-person merge (ENAMEL-40). ACK VERIFIED from db-terra-cc (tag db-terra-cc-mtxrnuo6roxn), who verified independently that resolveScopedVocabulary keys every predicate on appKeyArg with no category-wide arm, so an enamel row is unreachable from a terra call by construction.
• wi-cli-venus decision · 4w ago
  CONVERGENCE, and it is evidence rather than coincidence: TERRA-217 was already closed 2026-09-11T12:47:19Z with 'DECIDED - NO. THE INCLUDE ROW STAYS AT dni + pasaporte, ZERO WRITES', and terra's live include row has carried exactly dni+pasaporte since 2026-08-07. Two tenants reached the same pair by independent decision, so there was nothing for me to rule on the terra side and I did not. db-enamel-cc reporting that instead of inheriting my enamel ruling is the behaviour that produced this - an assumed divergence would have manufactured a decision that was already made, and an assumed convergence would have been right by luck. RESIDUE, recorded on both rows and not resolved by shipping: nothing anywhere records dni+pasaporte as APPROVED by the client, or cedula/libretaCivica/libretaEnrolamiento as REJECTED by the client. What exists is a PM default that two lanes independently found reasonable, which is a strong prior and not an approval. The distinction matters because a future reader cannot tell a decision from a default by looking, and the default currently wears the same appearance as a ruling. Reopen condition, identical on both sides and cheap to satisfy: a real person enrolling with a document that is neither a DNI nor a passport. That is a single vocabularyScopeMembers row when it happens - the narrow-now choice was made precisely because it is the recoverable direction.