ENAMEL-34 phase 2: drop the ungated 9-arg resolveOrCreatePaciente

Sub-tickets

Activity

• wi-cli-venus created · 5w ago
  parent=#3653
• wi-cli-venus note · 5w ago
  PHASE 2 HELD (db-enamel-cc, 2026-09-11). db-terra-cc measured terra's src/ and found TWO live application call sites on the ungated 9-arg public.resolveOrCreatePaciente(text,text,text,text,text,text,date,boolean,text), both raw SQL through the pool: src/lib/practica-actions.ts:566 (primary practica-creation flow) and src/lib/paciente-request-actions.ts:100 (TERRA-150 half-2, pushed 83362eb). Dropping the 9-arg signature is a 42883 on terra's main write path and on the new registration-request fulfil path. I accept the evidence and hold; no counter. THE PREMISE THIS ROW WAS WRITTEN ON IS STALE, and that is the durable part: createTerraPractica has ZERO call sites in terra's src/ (only comments and a test corpus scan). The app writes terraPracticas directly and resolves the paciente itself. So phase 1 removes a dependency nothing live exercises - worth doing, still db-terra-cc's, but it fires nothing and it does NOT clear phase 2. Zero callers is a state, not a property. UNBLOCK CONDITION, in order: coder-terra-cc moves both src/ call sites to resolveOrCreatePacienteForApp with 'terra' leading, reports both moved, THEN phase 2 drops the 9-arg. Schema-first does not apply in reverse here - the ForApp function already exists, so the app change ships safely before the drop and is the thing that unblocks it. Gate trap db-terra-cc flagged for that change: src/lib/practica-documento-type-guard.test.ts:50 asserts on the literal FROM "resolveOrCreatePaciente" including the closing quote, so the swap makes the test fail on 'call not found' rather than on the ordering it checks. Live signatures as measured by db-terra-cc, recorded so phase 2 can be checked against them rather than re-derived: resolveOrCreatePaciente 9 args md5 8a79026e0fa4120a56de30d45eacb01c; resolveOrCreatePacienteForApp 10 args md5 725e85d45b81b083b537546b94a4b1fc; createTerraPractica 24 args INVOKER search_path=public,pg_temp md5 5c72dacd9baff936c27110a341a2ca96; all three prosecdef=false. I did not re-run these - they are db-terra-cc's measurement, attributed, and phase 2 re-measures before it drops anything.
• wi-cli-venus statusChanged · 5w ago
  UNBLOCKED. Both firing facts are now met AND both were verified by my own reads rather than accepted from the DM that reported them. FACT (b), the applied terra migration: db-terra-cc reported md5(prosrc)=f2bc7169692340907c12ff5c18c40fdf length=5999 for createTerraPractica, applied 2026-09-11 16:32:16 UTC as terra_151_createTerraPractica_scoped_resolver, registration 20260911163216. I re-read pg_proc live: EXACT MATCH on both, pronargs=24, one overload. Further, I re-ran the caller sweep the row requires and it is stronger than a name grep - counting occurrences of the two QUOTED identifiers separately, exactly one function in public references the resolver family at all, createTerraPractica, with 0 hits on "resolveOrCreatePaciente" and 1 on "resolveOrCreatePacienteForApp". No database caller of the old name remains. FACT (a), a DEPLOYED terra app: the row asks for a deployed version, not a pushed one, and that distinction is load-bearing. Read terra's src/ at local HEAD 72b8305: both SQL call sites - practica-actions.ts:585 and paciente-request-actions.ts:109 - are the 10-placeholder ForApp form, and every other match of the old name in src/ is a comment or a log label, not a call. Then read the running app rather than the tree: https://terra-enamel.pensanta.com/api/health returns version 0.31.73, deploymentId dpl_4ddDXUb1DEiUrkZ5JRST1j5eyFkm, dbOk true. 0.31.73 is the version at 72b8305, the ENAMEL-36 resolver commit. The deployed app is the one whose call sites moved. PRE-APPLY CHECKS THE ROW REQUIRES, both done: to_regprocedure on the 10-arg ForApp signature is not null, and to_regprocedure on the 9-arg signature is not null either - so the drop has a target and the replacement exists. db-terra-cc's caveat is correct and does NOT hold this: the suite compiles TypeScript while these are SQL strings, so a wrong positional arity is a runtime 42883 under a green suite, and neither path has been exercised with a real authenticated session (TERRA-213). But that risk is about whether the NEW path works, and it exists identically whether or not I drop the old signature - terra's deployed code already calls only the new name, so the 9-arg overload is already dead to terra. Dropping it cannot make that failure more likely; it can only close the hole the row names, where any service_role caller still reaches the ungated name and registers a paciente with any documentoType in the global catalog. Waiting on TERRA-213 would hold a security drop open on evidence that does not bear on it. NEXT: author enamel_054 dropping public.resolveOrCreatePaciente(text,text,text,text,text,text,date,boolean,text), restating both facts above in the header per the row's instruction, and send it for review before apply.
• wi-cli-venus note · 5w ago
  enamel_054 authored, dry-run green, sent to audit-terra-cc for Class-A pre-apply review (hub tag db-enamel-cc-mtx6wmniktf2). Drops public.resolveOrCreatePaciente(text,text,text,text,text,text,date,boolean,text). Both required facts are restated in the header and both were re-derived by me rather than accepted from the DM that reported them. FACT (a) gained the link it was missing: a version string matching a commit is not the same as that commit containing the change, so git merge-base --is-ancestor 1425140 72b8305 returns true AND at 72b8305 itself git grep -c on the quoted old name in src/ returns 0 files while the ForApp spelling returns 2. The deployed commit CONTAINS the move, it does not merely postdate it. FACT (b): my own pg_proc read returns md5(prosrc) f2bc7169692340907c12ff5c18c40fdf, length 5999, pronargs 24, one overload - exact match to db-terra-cc's reported terra_151 apply. CALLER INVENTORY IS THREE SURFACES and the header names what none of them sees: pg_proc 0 hits on the old spelling; terra src/ at the DEPLOYED commit 0; list_edge_functions returns [] so no edge function exists. None of the three is a statement about an ad-hoc caller - any holder of a service_role or postgres credential can call the 9-arg name from outside every repo, and that is not an argument against the drop, it is the argument FOR it and the only thing the drop removes. ACCEPTANCE: ACC1 replacement exists or refuse, ACC2 notice on replay, ACC3 sweeps pg_proc for DB callers counting the two QUOTED identifiers separately because the old name is a PREFIX of ForApp and a LIKE sweep false-positives on every caller of the fix, and REFUSES the drop on any hit; ACC4 exact signature gone, ACC5 zero functions under that name at ANY signature, ACC6 exactly one ForApp so two untyped candidates raise 42725, ACC7 anon/authenticated/authenticator still false and service_role still true, ACC8 search_path pin survives. DROP is RESTRICT, never CASCADE. ACC3 and ACC5 were each forced to raise against a planted quoted-name caller and a planted 1-arg overload before sending; the unforced run is clean with residue old_left=1 new_left=1 probe_left=0. BLOCKED ON audit-terra-cc review, then apply and push.
• wi-cli-venus audit-finding · 5w ago
  enamel_054 (phase 2 drop) PASS (audit-terra-cc-mtx70dp7m36e). Independently verified live: pre-drop 9-arg ACL/owner/search_path exact match, zero pg_depend non-internal dependents (RESTRICT genuinely safe), ForApp's ACL matches ACC7/ACC8 targets, re-ran the ACC3 quoted-identifier caller sweep myself (zero hits, prefix-collision-safe same reasoning as terra_151's attack-3), cross-confirmed from my own terra_151 close that live createTerraPractica and terra src/ at HEAD call ForApp only. Non-blocking note: recommended a REPLAY-ORDER.md line for this drop for documentation parity with terra_209/enamel_052; does not affect correctness (plpgsql doesn't validate callee existence at CREATE time). No blockers. Apply cleared.
• wi-cli-venus completed · 5w ago
• wi-cli-venus note · 5w ago
  enamel_054 applied, catalog-verified, audit-terra-cc PASS, pushed 0d4171b. Old 9-arg signature gone (old_sig null, any_old_name 0), forApp overload intact with search_path=public, pg_temp, EXECUTE to service_role only, 0 db callers of the old name.