pluto
PLUTO-437
Plan: paciente DNI + HC central store — autocomplete, dedup warning, estadísticas
Todo normal
unassigned
Sub-tickets — 1/2 done
PLUTO-764 Backlog high
dpdb-pluto-cc
PLUTO-766 Canceled high
dpdb-pluto-cc
Activity
-
wi cli
-
Current state: practicas.numeroHistoriaClinica (HC) stored per-practica; NO dniPaciente column exists. Patients have no separate entity — identity only through HC + fechaNacimientoPaciente + sexoPaciente. Plan needed: (1) new 'pacientes' table with DNI + HC + nombre + apellido + fechaNacimiento; (2) FK practicas.pacienteId → pacientes.id; (3) autocomplete endpoint for HC/DNI lookup; (4) server-side warning on create-practica if DNI matches a different HC (or vice versa); (5) statistics queries (distinct patient count vs practica count). DB-first design; coder implements autocomplete + warning on practica form.
-
q#35 to=elazar: DNI obligatorio o opcional? (algunos pacientes podrían ser anónimos o extranjeros sin DNI argentino)
-
awaiting elazar
-
q#36 to=elazar: Key de dedup: ¿numeroHistoriaClinica es único por paciente, o DNI es el key canónico? ¿O ambos opcionales con warning si difieren?
-
awaiting elazar
-
q#37 to=elazar: Migración: ¿backfill practicas existentes creando una fila pacientes por HC existente, o solo aplica a prácticas nuevas?
-
awaiting elazar
-
OPTIONAL — app prompts for DNI once, user may leave empty if insisted. (Elazar 2026-07-03)
-
DNI+HC both lookup keys; typing one autocompletes the other from the matched patient (user can overwrite, free text); warn on DNI<->HC conflict. PM-interpretation of Elazar's 'find two values, whatever not typed' — coder confirms exact UX at design.
-
BACKFILL existing prácticas into pacientes rows. (Elazar 2026-07-03)
-
All 3 product Qs answered by Elazar 2026-07-03; ready for db-first design (new pacientes table + autocomplete/dedup-warn).
-
2026-07-20: patient-DB centralization is now enamel's lane (EVO-80). Elazar: enamel = central hub for auth + patient storage. Re-point this to CONSUME the enamel-hosted patient store rather than building a pluto-local one. Coordinate with pm-enamel-cc / EVO-80 before implementing.
-
CAVEAT 2026-07-20 (EVO-80 discovery, pm-enamel): pluto captures NO patient DNI or name - patient identity is a single free-text numeroHistoriaClinica (NHC) on the practica row (no documentoType/documentoNumber, no patient name in schema). 100% NHC coverage, clean format, but same-NHC dup rate (49/417 groups) is UNCLASSIFIABLE (no name/DNI to corroborate). So the 'DNI autocomplete / DNI ya existe con otro nombre' framing does NOT apply to pluto as specified - it's an identity-MODEL mismatch vs the shared-DNI assumption. DO NOT re-point PLUTO-437 to 'consume a central DNI-keyed store' until Elazar decides: pluto adopts DNI+name capture (schema+workflow change) vs central identity keys on what pluto holds. Blocked on that design fork.
-
Design fork per 2026-07-20 note: pluto adopts DNI+name capture (schema+workflow change) vs consumes the enamel-hosted central patient store (EVO-80). Awaiting Elazar's choice before re-scoping. Prior blockedReason text was stale (referred to q36/q37, answered 2026-07-03).
-
coder-pluto-cc
-
coder-pluto-cc
-
unassigned
-
Assignee cleared by pmmaster-evolutiva-cc 2026-09-12: coder-venus-cc / db-venus-cc / coder-pluto-cc / db-pluto-cc are absent from the hub roster and have no pane, and venus and pluto have no staffed coder or db lane. STATUS DELIBERATELY LEFT AS blocked - the blocker is a fact about the work and does not depend on who was holding the row, so it survives the unassignment. The blockedReason has NOT been re-verified in this pass; treat its age as unknown until someone reads the rows own events. Restaffing is Elazars call.
-
Unblocked and ruled by pmmaster-evolutiva-cc 2026-10-06. The fork is not a fork. Measured: EVO-80 (the enamel central patient store PLUTO-437 was told to wait for) is status=backlog, no assignedRole, design-first and untouched since 2026-09-11 - 2.5 months after Elazar's 2026-07-20 note re-pointing this row at it. There is nothing to consume and no design to consume it by, so 'await Elazar's choice' is parked on an option that does not exist yet. DECISION: Pluto builds LOCAL DNI + name capture now. This is not the opposing branch of the fork - it is the prerequisite for either branch, because consuming a central store keyed on DNI requires Pluto to be capturing DNI in the first place. Shape it so the migration is cheap, and match Terra's ruled shape rather than inventing a second one: DNI is the canonical identity anchor; the duplicate warning is ADVISORY only (warn, never block, never reveal a candidate identity, never auto-merge); the creating actor is resolved server-side from the session and never a request field; and the row carries a confirmed-vs-provisional distinction so a later central-store reconciliation can tell which local rows were ever verified by a human. If EVO-80 ever lands, the local table migrates behind the same anchor. Do NOT build cross-app reads, a shared schema, or anything that assumes the enamel hub. Class-A on the identity-anchor column; pre-apply audit review on the DDL.
-
GO received 2026-10-06, premise re-verified against db/schema.md before designing. Confirmed: NO pacientes table or view exists; patient identity on practicas is numeroHistoriaClinica (text NOT NULL) plus fechaNacimientoPaciente, sexoPaciente, nacionalidadOptionId, provincia, partidoLocalidad. No patient DNI and no patient name anywhere. The two numeroDocumento columns in schema.md (lines 115, 1002) are on accessRequests and users - PEOPLE, not patients - so they are not a partial implementation of this. The 2026-07-20 identity-model caveat still holds exactly as written. DESIGN TENSION the ruling does not resolve, flagged before anyone writes DDL: 'DNI as canonical identity anchor' and Elazar's 2026-07-03 BACKFILL decision are in direct tension, because no historical practica carries a DNI - a NOT NULL anchor cannot be satisfied by backfilled rows, and the same-NHC duplicate rate (49/417 groups) was measured UNCLASSIFIABLE precisely because there is no name or DNI to corroborate it. So a backfill cannot mint one paciente per distinct NHC without asserting identity it cannot verify. Resolution I am proposing to the db lane: DNI NULLABLE with unique-when-present, numeroHistoriaClinica retained as the local secondary key, and every backfilled row PROVISIONAL by construction - which is exactly what the ruled confirmed-vs-provisional distinction is for. Schema work is db-lane per agent boundaries; DDL spec dispatched to db-pluto-cc. App-side capture/advisory-dup-warning starts once the column contract is agreed - building a form against an unagreed schema is waste, not progress.
-
Readback complete (coder-pluto-cc, GO muwcr8e63mdz), five reads as coder_pluto_cc_ro against prod post-apply 07:36Z. R1 both tables exist, owner postgres, permanent. R2 relacl non-null both, 46 rows, grantees postgres/service_role/evolutiva_agent_rw/evolutiva_agent_ro/support_evolutiva_cc_ro/coder_pluto_cc_ro, all grantor postgres, all is_grantable=f, NO anon/authenticated/PUBLIC. R3 anon+authenticated are members of nothing (0 rows) and transitive closure to any grant-holding role is 0 rows. R4 NOT COVERED: permission denied for schema supabase_migrations for this role; also 131 was applied by raw psql not apply_migration so a row may never have been written - absent vs unreadable is indistinguishable from this seat, needs postgres or the claim comes off the row. R5 RLS off, 0 policies, both tables, matching the users/practicas archive baseline; trg_archive_pacientes attached and enabled. ADJACENT (not in the assigned five, supautils hazard class): all three fns 131 creates have EXECUTE for postgres+service_role ONLY, no PUBLIC, prosecdef=f, search_path pinned, 1 overload each checked by signature. Negative instruments FORCED RED first: membership query reseeded at authenticator returns 3 rows, the grantee=0 PUBLIC branch returns 5 rows against fns that do carry PUBLIC EXECUTE, existence read returns 0 for a nonexistent name. NOT exercised: the registry row, and all behaviour - no insert, no confirm call, no archive fire; SELECT-only seat plus the residue rules, so this says the objects exist with the intended grants and nothing about whether they work.
-
Record commit landed: 585c8b7 / v2.23.134. Paths: db/migrations/applied/131-pluto-437-pacientes-identity-anchor.sql (new, sha256 8e105c7a4ef4fefb1517fa3527512de0d832716a7d554aba90d274e456c45734, re-verified against the GO digest immediately before the commit) + db/schema.md (tables 55->57, both new tables documented). db/reference-data.sqlite was regenerated but is gitignored at .gitignore:64, so it is NOT and cannot be in the commit - noting that rather than leaving it to look forgotten. Local-Author: db-pluto-cc trailer set (that lane wrote the SQL and holds no push lane). No draft twin existed - db-pluto-cc moved the file rather than copying it - so the terra-style draft/applied stem-overlap case never arose, and pluto has no such check in .gitpush-pre.sh anyway. Pre-push hook passed, 85 test files / 1084 tests green. PTD: version-match PASS against the REMOTE package.json on main read at check time (2.23.134) vs live /api/health 2.23.134, deploymentId moved dpl_cuNvArb1->dpl_5DPYktHj, dbOk true. COVERAGE LIMIT, stated not papered over: Class-A normally requires reading the Vercel build and runtime logs for the SHA, and I could not - the Vercel MCP connection on this seat resolves zero projects (wrong account scope) and no vercel CLI is installed on this host. What that leaves unexercised is build/runtime log inspection; what structurally bounds it is that this commit changes no runtime code path - it adds an already-applied .sql file and a regenerated markdown doc - so the deploy carries no app-behaviour delta, and dbOk plus the version match cover what remains. Someone with Vercel reach should confirm if that is not accepted.
-
ROW STATE for the next reader, so this does not read as an untouched p-row: the DDL half is DONE and the row is open ONLY on the app-layer confirmation gate. Done: migration 131 applied in prod 2026-10-06 07:36:22-07:36:28Z by db-pluto-cc under GO muwd4ycro8sv; independent five-read readback by coder-pluto-cc PASS on existence/owner, ACL with grantor+is_grantable, role membership incl transitive closure, RLS, trigger attachment, plus function EXECUTE (all three fns postgres+service_role only, no PUBLIC - the REVOKEs held against supautils); recorded in git at 585c8b7 / v2.23.134. OPEN: (a) the app-layer confirmation gate - fn_confirmPaciente has no caller, so the feature does not exist for a user yet; (b) ALL BEHAVIOUR IS UNEXERCISED - no insert, no confirm call, no archive fire; the readback says the objects exist with the intended grants and says nothing about whether they work; (c) R4, the migration registry row, UNRESOLVED - coder_pluto_cc_ro gets permission denied for schema supabase_migrations, and since 131 was applied by raw psql rather than apply_migration a row may never have been written, so absent vs unreadable is indistinguishable without a postgres-held read; that read sits with db-pluto-cc. Spun out, NOT blocking this row: PLUTO-772 (export-db.py counts functions via privilege-filtered information_schema.routines, 39 vs a live 116, which is why the three new fns are missing from schema.md).
-
DDL applied 2026-10-06T07:36Z, hash 8e105c7a4ef4fefb1517fa3527512de0d832716a7d554aba90d274e456c45734 (db/migrations/applied/131-pluto-437-pacientes-identity-anchor.sql). Audit source PASS muwci3mkyozi, confirm-diff PASS muwd49w1n1k5, GO muwd4ycro8sv, readback PASS muwdh0xlitlc. Row stays OPEN: app-layer confirmation gate (fn_confirmPaciente UI/action surface) not landed by this DDL alone. R4 (supabase_migrations registry row for 131) unresolved - coder_pluto_cc_ro lacks read; needs a postgres-held read.
feature
2026-05-22
1w ago