Drop createVenusSupportTicket(text,text,text,text) - decision gate 2026-09-19, after the enamel_060 revoke has had a week to produce a signal
DUE 2026-09-19. Step 2 of the two-step retirement pmmaster-evolutiva-cc ruled 2026-09-11 (REVOKE NOW, DROP LATER). Step 1 is DONE: enamel_060, applied and pushed 4a2b912, revoked EXECUTE from venusApp and service_role; post-apply ACL re-read independently and pasted to pmmaster - proacl is exactly postgres=X/postgres, and the reach check over every non-superuser role other than postgres returns NONE. THE DECISION GATE ON 2026-09-19, AND ITS INSTRUMENT WAS CORRECTED 2026-09-12 - THIS PARAGRAPH SUPERSEDES THE ORIGINAL TEXT AND enamel_060 HEADER, BOTH OF WHICH NAMED THE APPLOG RAIL AND WERE WRONG. Run this query: source=postgres_logs and sql_state_code=42501 and query like %createVenusSupportTicket%, read as day-sized slices because the log API caps one query at 24h. Diff it against the baseline taken 2026-09-12: 29 log rows mention the function in 24h, ALL 29 are this lane own mgmt-api traffic as postgres, and ZERO are at 42501. If a 42501 denial has surfaced from any other user_name: DO NOT DROP - re-grant EXECUTE to venusApp and reopen this row. If none has: drop it, in its own migration, never bundled, KEEPING THE FULL DEFINITION IN THE FILE so the object is restorable from the tree; the verbatim definition is already preserved in the RESTORE BLOCK at the foot of enamel_060. WHY THE APPLOG RAIL IS NOT THE INSTRUMENT, measured not reasoned: pg_stat_statements CANNOT SEE A REFUSED CALL AT ALL (forced control - two uniquely marked statements of the same shape on one connection seconds apart, one refused at 42501 and one succeeding, and ONLY THE SUCCESSFUL ONE registers, because the counter hangs off ExecutorEnd and a statement dying on a privilege check never reaches it), so the 47-day window below is evidence about the PAST and says nothing about the observation week; and the applog rail carries only what the enamel APP writes, so a caller that is not the enamel app writes nothing to it, and enamel own relay was once down 16.8 days unnoticed. postgres_logs is the exact complement - measured logging the refusal and NOT the Supavisor-path success - with attribution in parsed.user_name, parsed.sql_state_code, parsed.query verbatim, parsed.application_name and parsed.connection_from, and retention measured at 23 days or more by positive row counts in old windows. It is READABLE, NOT WATCHED: nothing alerts on it, so the gate depends on someone running the query on 09-19. Say that in the drop migration header rather than inheriting the live-and-watched claim. WHAT THE DROP MIGRATION MUST SAY IN ITS HEADER, as specified: the function derived the caller app from callerApps.dbRole = session_user, a derivation that only ever worked for venus; it is removed because the client write path has settled on the in-statement vUserGroups appKey gate in app/src/lib/support-core.ts createTicket(), so there is ONE write gate on supportTickets and not two. The header must also carry the instrument correction above, the enamel_053 route, because enamel_060 header and the live COMMENT ON FUNCTION both still name the applog rail and the drop removes that comment. LAYERS SEARCHED for a caller, all clean: six fleet source trees; enamel app/src including exported constants with zero call sites; pg_proc bodies on this ref; supabase_migrations.schema_migrations statement TEXT. BOTH GATED CHECK RESULTS: check 1 (no live caller) CLEAN on four legs; check 2 (is the grant void by construction?) NOT CLEAN - venusApp is rolcanlogin=true with a password, held EXECUTE alongside postgres and service_role, callerApps carries venus -> venusApp, so the grant was live and that argues FOR removal. COVERAGE CAVEAT that must travel with the evidence: the load-bearing fact is no production call pattern in 47 days of extensions.pg_stat_statements (only this lane DDL and three one-shot probes), and 47 days is NOT all time - the view was reset 2026-07-27 13:29:09+00, which postdates enamel_019 creating the function; pg_stat_statements EVICTS under pressure so its window is a LOWER BOUND; track_functions is none on this ref so pg_stat_user_functions is empty and is not an instrument. Zero rows in supportTickets / supportTicketCounters is explicitly NOT offered as evidence - the table is virgin so it is equally true of every writer including the one shipped this week.
Activity
-
INSTRUMENT PLAN, measured 2026-09-12 - the description above names the applog rail as the 09-19 signal and that is the WRONG instrument on two counts, both measured, not reasoned. (1) pg_stat_statements CANNOT SEE A REFUSED CALL. Forced the control: one statement that parses and is refused (42501) and one of the same shape that succeeds, both uniquely marked, issued seconds apart on the same connection. Only the SUCCESSFUL one is in extensions.pg_stat_statements. So the 47-day window in the description is valid evidence about the PAST (a successful call would have registered) and is WORTHLESS for the observation week - reading 'still nothing in pg_stat_statements on 09-19' as clean is exactly the false silence this two-step exists to prevent. (2) The applog rail carries what the ENAMEL APP writes; an unknown caller that is not the enamel app writes nothing to it, and enamel's own relay was down 16.8 days unnoticed once already, so rail silence is evidence only after confirming rail uptime across the window. THE INSTRUMENT THAT ACTUALLY SEES IT is the Supabase unified log stream, source postgres_logs, which is the exact COMPLEMENT of pg_stat_statements - measured: it logged the refused statement and did NOT log the successful one (Supavisor path). Attribution is complete on the denial row: parsed.user_name, parsed.sql_state_code = 42501, parsed.query verbatim, parsed.application_name, parsed.connection_from. RETENTION MEASURED AT >= 23 DAYS (5550 postgres_logs rows present for 2026-08-20, 5555 for 2026-09-04), so a 09-19 read still reaches 09-12 with margin; the per-query window is capped at 24h, so the week is read as day-sized slices, not one call. THE 09-19 QUERY: source=postgres_logs and sql_state_code=42501 and query like createVenusSupportTicket. BASELINE TAKEN NOW so the 09-19 read has something to diff against: 29 log rows mention the function in the last 24h and ALL 29 are this lane's own mgmt-api traffic as postgres (enamel_059/060 DDL text plus my own forced-red ACC0/ACC1 raises); ZERO are 42501, and zero are from any non-postgres role. Also measured and worth carrying: mgmt-api statements ARE logged at 00000 on this ref while Supavisor-path successes are NOT, so log coverage differs by CONNECTION PATH, not only by severity.
-
was: DUE 2026-09-19. Step 2 of the two-step retirement pmmaster-evolutiva-cc ruled 2026-09-11 (REVOKE NOW, DROP LATER). Step 1 is DONE: enamel_060, applied and pushed 4a2b912, revoked EXECUTE from venusApp and service_role; post-apply ACL re-read independently and pasted to pmmaster - proacl is exactly postgres=X/postgres, and the reach check over every non-superuser role other than postgres returns NONE. WHAT THE DROP MIGRATION MUST SAY IN ITS HEADER, as specified: the function derived the caller app from callerApps.dbRole = session_user, a derivation that only ever worked for venus; it is removed because the client write path has settled on the in-statement vUserGroups appKey gate in app/src/lib/support-core.ts createTicket(), so there is ONE write gate on supportTickets and not two. LAYERS SEARCHED for a caller, all clean: six fleet source trees; enamel app/src including exported constants with zero call sites; pg_proc bodies on this ref; supabase_migrations.schema_migrations statement TEXT. BOTH GATED CHECK RESULTS: check 1 (no live caller) CLEAN on four legs; check 2 (is the grant void by construction?) NOT CLEAN - venusApp is rolcanlogin=true with a password, held EXECUTE alongside postgres and service_role, callerApps carries venus -> venusApp, so the grant was live and that argues FOR removal. COVERAGE CAVEAT that must travel with the evidence: the load-bearing fact is no production call pattern in 47 days of extensions.pg_stat_statements (only this lane DDL and three one-shot probes), and 47 days is NOT all time - the view was reset 2026-07-27 13:29:09+00, which postdates enamel_019 creating the function; pg_stat_statements EVICTS under pressure so its window is a LOWER BOUND; track_functions is none on this ref so pg_stat_user_functions is empty and is not an instrument. Zero rows in supportTickets / supportTicketCounters is explicitly NOT offered as evidence - the table is virgin so it is equally true of every writer including the one shipped this week. THE DECISION GATE on 2026-09-19: if a permission-denied on this function has surfaced on the applog rail, do not drop - re-grant to venusApp and reopen. If nothing surfaced, drop it and KEEP THE FULL DEFINITION IN THE MIGRATION so the object is restorable from the file; the verbatim definition is already preserved in the RESTORE BLOCK at the foot of enamel_060.
-
FLEET-WIDE STOP parked (pmmaster-evolutiva-cc-mtxsnm01fjv7-db-enamel-cc, relayed Elazar direct 2026-09-11 23:56 ART). DONE this session: ENAMEL-50 closed - enamel_062 applied + registered in one transaction (version 20260912023021, md5 byte-exact) and pushed af35802 / v0.13.1; enamel accepts documentoType dni + pasaporte, zero lookupOptions writes, terra unchanged, ACK VERIFIED by db-terra-cc; TERRA-217 confirmed non-divergent (already done, T217-dec-mtwz08); one report sent to pmmaster. NOT DONE / SUSPENDED: ENAMEL-49 itself (the createVenusSupportTicket DROP gate, due 2026-09-19), ENAMEL-45, ENAMEL-41, ENAMEL-28, ENAMEL-44, ENAMEL-16, and db-terra-cc's appEvents authorized-implies-actorUserId BEFORE INSERT check awaiting my review. NEXT ACTION on resume: ENAMEL-49 - query postgres_logs source='postgres_logs' sql_state_code='42501' query like '%createVenusSupportTicket%' in day-sized slices against the baseline of 29 own-lane mgmt-api rows / zero at 42501; a denial from any user_name other than my own lane means DO NOT DROP, re-grant to venusApp and reopen. STATE IS CLEAN: nothing mid-push, no uncommitted work of mine, no broken state. One untracked file in db/ is NOT mine and is not being pushed - db/per-tenant-role-design.md, owner coder-enamel-cc, mtime 2026-07-31, predates this session. Resume needs Elazar's own word.
-
db-enamel-ca
-
Decision-gate log read, 2026-09-12 00:00 through 2026-09-20 00:00 UTC, queried as nine day-sized postgres_logs windows: zero SQLSTATE 42501 rows matching createVenusSupportTicket in every window. Positive log volume in each daily window (7,641–8,595 rows) confirms the source had data throughout. Gate condition is clean for this period; no DDL has been applied. Drop remains a separate migration with the saved restore definition and registry/readback requirements.
-
Review stalled: audit-general-ca cannot be reached via the hub - confirmed defect (MSG-437, coder-llmmsgsrv-cc 2026-10-04), a loaded/turning codex session consuming zero queued items for 6 days, scope every -ca agent. 43 messages stuck undeliverable incl. this row's review ask. Fix escalated to Elazar by coder-llmmsgsrv-cc. No alternate pluto/enamel audit lane live. Held pending the fix or a manually-typed-in-pane review (not yet attempted).
-
CORRECTION (bin-venus-cc, measured across my pane-poke): not lost, DELAYED. Queue drains exactly 1 item/turn, enqueues ~13+/3h - backlog cannot close at current rate, 3 days deep at head. This row's ask is intact in the queue, just far back. Do NOT re-send via hub - duplicates add to the backlog, not speed it up. Fix (coalesce to 1 queue item/poll + queue-depth gate) assigned to coder-llmmsgsrv-cc, MSG-437. Held pending that fix; no alternate pluto/enamel audit lane live.
-
audit-general-ca verdict on the PRE-revision MD5 c4fceb23: source-only BLOCK - SECURITY DEFINER fn recreated without immediate ACL revocation, no body-drift pin before DROP. Superseded: db-enamel-ca already pushed fix (commit 5de4784, MD5 adec1a1d) addressing both gaps, re-review requested at that exact HEAD per audit's own note. No apply GO either way.
-
audit-general-ca confirms the newer MD5 adec1a1d (commit 5de4784) has NOT yet been requested/reviewed by it - still pending, not a second BLOCK. Its repeated BLOCK answers this hour were all re-litigating the OLD c4fceb23; db-enamel-ca's fix is still awaiting first review.
-
Applied amended enamel_072 at HEAD cd3b0837d94c8c5abbc4429660331e614403ab57; md5 adec1a1d4ae043149ad8c15f69e33040, blob d7a667b834fa9c2ee2742fd01a3d22d1b123abf1. Supabase apply_migration returned success. Live preflight matched pinned function definition hash 044268d32fc2235691b6452c202b9618, owner postgres, SECURITY DEFINER, pinned path, owner-only ACL, no nonowner EXECUTE holders, no existing ledger row. Postflight: exact function absent, zero same-name overloads, migration version 20261004201745 registered. Artifact was already pushed at 5de4784.
-
PASS citation confirmed: audit-general-ca tag audit-general-ca-muu8trda2wxg, 2026-10-04 17:05 ART (20:05Z), PASS on MD5 adec1a1d/blob d7a667b8, landed 3min after my 20:02Z 'not yet reviewed' note (stale info on my end). db-enamel-ca applied correctly after a real exact-artifact PASS, not off the apply-order ruling alone. No process gap on this row.
-
Exact source PASS for applied enamel_072 artifact: audit-general-ca-muu8trda2wxg, 2026-10-04 17:05 ART (20:05Z), PASS MD5 adec1a1d4ae043149ad8c15f69e33040 / blob d7a667b834fa9c2ee2742fd01a3d22d1b123abf1. Follow-up audit-general-ca-muu9920r7lmb at 17:10 ART reconfirmed same committed blob. Exact-artifact audit preceded apply; PM apply-order ruling was separate and not used as a substitute.