Schema-qualify the six unqualified fn call sites landed in orphan slices C and D
Add the public. prefix to the six call sites that landed unqualified in f08751e (slice C) and 216d403 (slice D): src/lib/support-queries.ts SELECT "fn_getSupportAdminList"($1,$2,$3,$4) SELECT "fn_getSupportAdminTicketDetail"($1) SELECT "fn_getSupportReporterTicketDetail"($1,$2) src/lib/auth-actions.ts SELECT "fn_submitAccessRequest"($1::jsonb, $2::uuid) src/lib/comentario-actions.ts SELECT "fn_createPracticaComentario"($1,$2,$3) src/lib/legacy-export-actions.ts SELECT * FROM "fn_getLegacyPracticaStats"($1) -- set-returning, keep the FROM form Slices A (87523d0) and B (ad6db96) already use public."fn_..."; this closes the inconsistency. ATTRIBUTION — the reason this is a separate WI and not a fix folded into C/D. The code is audit-pluto-ca's, written 2026-07-21 and landed byte-for-byte so the Authored-By: audit-pluto-ca trailer describes content they actually wrote. Qualifying inline at push time would have silently made that trailer false. This WI's commit is coder-authored and carries NO Authored-By, because by then the edit is mine. pm-pluto-cc directed the split (pm-pluto-cc-msip5rbcailv). NOT A BUG, and do not let the WI title imply otherwise. db-pluto-cc read the live setting (db-pluto-cc-msiox6lbjqdg): the app runtime pool's search_path is the unpinned session default "\$user", public, extensions, so all six resolve to public correctly today. This is defensive hardening against a future search_path change, nothing more. Explicitly NOT the PLUTO-673 class. That outage was SECURITY DEFINER functions carrying an explicit SET search_path TO 'public, pg_temp' GUC, where the quoting collapsed the list into a single identifier and current_schemas(false) returned {}. A plain caller on a default search_path shares the symptom vocabulary and none of the mechanism. Anyone citing 673 as urgency for this WI has matched the wrong thing. Class-S: no schema, auth or email-path change. Suite must stay 390/390.
Questions
Activity
-
Correction from the filer. Two defects in this row, both mine, neither fixable with the wi CLI as it stands: 1. PRIORITY IS WRONG. Reads 2 (normal); intended 3 (low). The positional arg order in 'wi add' is [type] [priority], and I passed a single 3 meaning priority — it landed on TYPE instead, leaving priority at its default. PLUTO-685 has the identical defect from the same mistake (my '2' became type=2). There is no 'wi priority' subcommand, so neither can be corrected in place. Treat this item as LOW priority regardless of what the field says. 2. One escaping artifact in the description: the search_path default renders as "\$user", public, extensions. The backslash is not part of the value — the real setting is "$user", public, extensions. No 'wi' subcommand edits a description either. Both are recorded here rather than by refiling, since a duplicate row costs more than a correction event.
-
3