Historia clinica: the stated initial focus, zero app surface, pacientes table empty

Sub-tickets — 3/8 done

Activity

• wi-cli-venus created · 2026-08-10
• wi-cli-venus assigned · 4w ago
  coder02-enamel-cc
• wi-cli-venus decision · 4w ago
  Reassigned coder-enamel-cc -> coder02-enamel-cc by pmmaster-evolutiva-cc under Elazar's standing GO (2026-09-11 09:22/09:27). Load, not performance: coder-enamel-cc holds ENAMEL-16/1/38/24 and is measured BUSY at ctx=316k against a 250k window, while coder02-enamel-cc is free - ENAMEL-40 shipped at ffde6e5 and ENAMEL-47 is pushed at 01c0845 and parked on a client-side browser round-trip no agent can perform. ENAMEL-24 is the lowest-priority of coder-enamel-cc's four and the only one with no collision surface: it is greenfield with zero existing app surface, so it does not touch ENAMEL-34 (resolveOrCreatePaciente, db-enamel-cc inProgress) or ENAMEL-38's resolver work. coder-enamel-cc keeps ENAMEL-16, ENAMEL-1 and ENAMEL-38.
• wi-cli-venus statusChanged · 4w ago
  Orientation complete: read enamel-historia-clinica-standards.md + enamel-design-lessons.md, read live schema (enamel_002/006/049/054). v1 scope: keyed lookup by (documentoType,documentoNumber) - no browse/list surface exists on pacientes (no appKey/ownerAppKey axis); antecedentes lifecycle (open/resolve/erroneous) via existing trigger+views, never in-place edit. No create-patient flow in v1 (structurally blocked - zero vocabularyScopes row for appKey=enamel/documentoType, and resolveOrCreatePacienteForApp is ENAMEL-34/db-enamel-cc's in-progress function, not touched). Filing deferred legal/architecture items as child rows per pmmaster's scope boundary (no export/third-party/off-platform copy baked in here).
• wi-cli-venus completed · 4w ago
  v1 pushed d21720b, app v0.13.0. Delivered: /historia-clinica keyed lookup by (documentoType,documentoNumber) - no browse (pacientes has no appKey/ownerAppKey axis, so a list would be a cross-tenant sensitive-data read); /historia-clinica/[id] antecedentes lifecycle (open/resolve/erroneous) over existing vPacienteAntecedentes/vAntecedentesCatalog/requireDetalle trigger, never in-place edit per Ley 26.529. Gated on admin:enamel specifically (stricter than ADMIN_OF_ANY) - renders empty today, zero admin:enamel grants exist. No create-patient flow: blocked structurally (no vocabularyScopes row for appKey=enamel/documentoType; resolveOrCreatePacienteForApp is ENAMEL-34's, not touched) - filed as ENAMEL-50. Deferred legal/architecture gaps filed as their own rows, not comments: ENAMEL-50 create-flow block, ENAMEL-51 HC-export(Ley 26.529) vs no-export scope boundary tension, ENAMEL-52 firma digital+consent+minors banding, ENAMEL-53 FHIR/SNOMED interop, ENAMEL-54 mental-health RBAC tier, ENAMEL-55 retention-floor enforcement. Verification: 21 new whitebox tests (279 total, tsc clean), mocked db, pin gate SQL + lifecycle column-set invariants. NOT exercised, and not claimed as such: requireDetalle trigger firing, gate filtering a real row, any live admin:enamel identity - pacientes is 0 rows fleet-wide with no reachable write path, so none of this has ever round-tripped live.