Enamel is default-open on documentoType: no vocabularyScopes row, so it accepts all five while terra accepts two
ENAMEL-34's NAMED RESIDUAL, filed so closing the parent does not drop it. Both engineering phases are done: enamel_049 (phase 1, applied c8d78c5, amended 29566f4) introduced public.resolveOrCreatePacienteForApp(appKey,...) validating documentoType through resolveScopedVocabulary, and enamel_054 (phase 2, ENAMEL-36, applied 2026-09-11 16:52 UTC, pushed 0d4171b, Class-A PASS by audit-terra-cc) dropped the ungated 9-arg public.resolveOrCreatePaciente. MEASURED LIVE 2026-09-12 on eprpywqwzsvrjeaforei: the 9-arg is absent in EVERY schema at EVERY arity, createTerraPractica's body calls the ForApp name, and no pg_proc body anywhere still names the old one. WHAT IS LEFT, and it is a product decision rather than a defect. vocabularyScopes holds exactly ONE row for category documentoType: (terra, include, dni+pasaporte). ENAMEL HOLDS NO ROW, and resolveScopedVocabulary is default-open on a LEFT JOIN miss, so resolveScopedVocabulary('enamel','documentoType') returns ALL FIVE (dni, pasaporte, cedula, libretaCivica, libretaEnrolamiento) while terra now returns exactly dni+pasaporte. ACCEPT == OFFER holds for enamel, because both sides are the full catalog - so this is NOT the accept-is-a-superset-of-offer bug ENAMEL-34 fixed, and nothing is currently miswritable. It is an UNMADE DECISION: enamel accepts three document types that terra deliberately removed, and it accepts them by DEFAULT rather than by choice. THE FIX WHEN SOMEONE DECIDES: one insert into vocabularyScopes (enamel, documentoType, include) plus the vocabularyScopeMembers rows for the chosen values. Zero users and zero pacientes rows hold any of the three unscoped values, so it orphans nothing and needs no data migration. DO NOT instead deactivate the 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, which is the exact category error ENAMEL-34 was filed against. BLOCKED ON: an enamel product call about which document types enamel should accept. Terra's equivalent is a catedra decision tracked on TERRA-217. Not a unilateral DB-lane change - it is data in a shared table, so it needs the announce-before + ACK VERIFIED path under enamel-commons Auth Co-Tenancy rule 3.
Activity
-
Duplicate of ENAMEL-50, which was filed 17 minutes earlier and states the premise correctly. ENAMEL-58 framed the same missing vocabularyScopes row as a default-OPEN unmade decision with nothing currently miswritable; measured live, the caller is FAIL-CLOSED and enamel cannot register any paciente at all. The error was measuring resolveScopedVocabulary(enamel,documentoType) - which does return all five - and generalising to resolveOrCreatePacienteForApp without reading its gate, which refuses on zero vocabularyScopes rows BEFORE consulting that function. The full measurement, the fix and the remaining product decision are now on ENAMEL-50 as a verified event. Nothing is lost by cancelling this row.