ALTER DEFAULT PRIVILEGES: decide whether to narrow the agent roles too, after the MARS-707 fence has proven itself on mars_app_runtime
Split off MARS-707 on 2026-09-11 by coder-mars-cc so the narrower decision is not blocked by the wider one. DEFERRED DELIBERATELY, not dropped. MARS-707 narrows the postgres-owned ALTER DEFAULT PRIVILEGES entry in schema public so that a newly created table no longer arrives with mars_app_runtime=arwd automatically. That is decided and proceeding: fence first, narrowing second. The SAME default entry also grants evolutiva_agent_rw=arwd and evolutiva_agent_ro=r. Narrowing only the runtime role therefore leaves the identical silent-grant mechanism live for the agent lanes, so narrowing all three is the coherent position - db-mars-cc raised this itself rather than quietly doing the narrow version, which is the right instinct. Why it is NOT being done in the same change: it widens the blast radius from one runtime role to every agent that touches this database, including db-mars-cc's own lane and the review lane. A mistake in the runtime narrowing shows up as an app error on a new table, loud and one surface. A mistake in the agent narrowing can strip a lane's ability to read the database it maintains, including the lane that would have to fix it. Those are not the same risk and they should not ride on one migration. db-mars-cc's recommendation, accepted by coder-mars-cc as PM: narrow mars_app_runtime first, let the two-directional fence from MARS-707 run against real migrations for a while, and treat the agent roles as a separate decision once the fence has demonstrated it catches both the missing-grant and the excess-grant direction in practice rather than only in a negative test. The condition that reopens this: the MARS-707 fence has caught at least one real excess grant (a new table arriving with privileges the manifest does not list), OR Elazar asks for it sooner. Reopening is a decision, not a schedule - do not close this as stale. Do NOT read the deferral as a judgement that the agent-role exposure is acceptable. It is the same defect on a wider surface, and the reason it waits is sequencing risk, not severity.
Activity
-
PRE-EXISTING BREAK FOUND 2026-09-11 while closing coder02's LOW #1 on migration 145 - evolutiva_agent_rw cannot write several archived tables. fn_normalize_archive_reason(text) has proacl {postgres=X, service_role=X, mars_app_runtime=X}: no PUBLIC entry, no agent-role entry, dating to MARS-694's three-way-revoke hardening which granted it to mars_app_runtime BY NAME and nobody else. The INVOKER archive triggers call it and a NESTED call IS EXECUTE-checked, so 'UPDATE public."practicas" SET "updatedAt"=now()' as evolutiva_agent_rw fails with 'permission denied for function fn_normalize_archive_reason' raised from inside fn_archivePracticaChange. MEASURED SCOPE (9 tables, rolled-back tx, SET LOCAL ROLE evolutiva_agent_rw): BLOCKED practicas, practicaTeeth, studentAssignments; WRITE OK periodos, lookupOptions, users, comisiones, emailOutbox. evolutiva_agent_ro reads fine (base tables + views). NOT CAUSED BY 143/144/145 - control test run before reporting: re-granted all 17 of 145's revoked functions TO PUBLIC in a rolled-back transaction and retried the same write; it STILL failed with the same error, and fn_normalize_archive_reason was never in the 17 (not anon-executable, no PUBLIC entry). UNEXPLAINED, recorded rather than guessed: all ten trigger functions naming fn_normalize_archive_reason are prosecdef=false, postgres-owned, and un-granted to the role, yet users/comisiones/periodos write fine while practicas/practicaTeeth/studentAssignments do not - something branches around the call on the passing three and what it is has not been established. FIX is one line, GRANT EXECUTE ON FUNCTION public.fn_normalize_archive_reason(text) TO evolutiva_agent_rw, but that is agent-role surface and belongs to this WI rather than to a same-day unilateral grant - coder-mars-cc's call whether this reopens 708 early or lands as its own narrow migration. mars_app_runtime is unaffected and holds the grant explicitly, so the application is not touched. Also satisfies the spirit of the stated reopen condition: not the fence that caught it, but exercising a role instead of reasoning about it - the same lesson as the deferred-trigger retraction earlier today.
-
Dependency-state correction (2026-09-13): MARS-707 is done (closedAt 2026-09-11T22:48:51.790Z), so the description's statement that it is proceeding is stale. MARS-708 remains backlog: its own production evidence/precondition is separate and is not asserted satisfied by this dependency correction.
-
db03-mars-ca
-
Checked live 2026-09-22: fn_runtime_privilege_manifest + fn_assert_runtime_privilege_manifest both exist, consistent with MARS-707's fence having landed. Did not verify the fence has actually 'proven itself' (no incident/monitoring data checked) - that's the actual gate this WI is waiting on, still open.