Sales owner position

The accepted barrier does not require removal of inherited PUBLIC TEMPORARY. Sales withdraws the broader strict-no-DDL prerequisite introduced in packet 020. That packet and its evidence remain unchanged. The revised review-only role retains current inherited CONNECT/TEMPORARY and public USAGE, with no persistent schema CREATE, protected-object ownership, role memberships, superuser, BYPASSRLS, replication, CREATEROLE or CREATEDB. It retains exactly the explicit table, column, sequence and invoker-helper grants from 020. No global PUBLIC revoke is proposed.

The role default search path is now explicitly pg_catalog,sales,pg_temp. The role provisioning transaction also pins that path. This default is not represented as an immutable security boundary: a caller can change its own search path. Tests deliberately did so. Temp objects remain session-local and can cause failures, resource use, or misleading unqualified reads; they do not grant persistent-object privileges. Existing ordinary application write permissions still require trusted application authorization. This is not a proof against arbitrary malicious application code or all future SQL.

Evidence

Source remains the clean pinned 18cb0e8a4fb4999a30f5fe48852d3b221ddc2cda checkout. All tests used a new synthetic clone on the guarded loopback PostgreSQL target. No production role, ACL, environment, deployment, migration, provider or business write occurred.

• Actual packaged Prisma client and scheduling/receipt/order preparation/signing repositories ran with 61 empty same-name temporary tables on their single pooled connection, a hostile pg_temp,public,sales,pg_catalog search path, and temporary jsonb_typeof and current_setting functions. Durable writes reached the qualified Sales tables. All temporary table copies remained empty. Canonical dispatcher insert and rollback behavior also passed.
• Both invoker helpers were tested with temporary table/function shadows and three search paths. The history helper still found the real signed original; the nonsecret helper rejected credentials. Explicit temporary function calls worked, proving the fixture existed; unqualified built-in calls did not select the temporary function.
• Ten trigger functions were exercised in 140 cases: two search paths, seven type-shadow variants (none, jsonb, text, uuid, timestamptz, numeric, int8), and ten guard functions. There were 137 genuine P0001 guard rejections and three type-resolution failures. No invalid operation succeeded. The trigger harness attaches the unchanged real invoker functions to isolated temporary fixture tables using local owner setup, then executes the attempted operation as the restricted role. This measures resolution and guard rejection, not a replacement for the accepted 25-case full persistence proof. The packaged dispatcher execution plus two helpers account for all 13 relevant Sales functions.
• Direct protected UPDATE/DELETE/TRUNCATE, trigger disablement, function ownership, owner SET ROLE, replication mode and persistent-schema creation attempts remained denied. A separate foreign-schema control fixture denied reads, writes and grants and retained epoch 7. Fake SQL settings did not change the process-environment admission/execution controls. Owner epochs remain authenticated producer/configuration inputs, not authority derived from similarly named temporary objects or SQL settings.
• Protected scheduling and ordering rows were compared before and after shadow attacks. Existing cloned migration history remained identical (101 Sales rows and 25 public rows). No history repair or bypass was used.
• Raw SQL review covered active app/lib/modules call sites. Business relations are schema-qualified; the intake query's unqualified intake_contacts is a statement-local CTE. Type casts can fail under a deliberately hostile temporary type, as captured. No persistent-schema CREATE privilege or reachable privileged definer is introduced. The 020 production catalog review remains the evidence for the existing definer inventory; this phase did not repeat production inspection. Effective production privileges and catalog drift must still be checked after provisioning.

Concrete diagnostic finding and smallest fix

The dormant serving-role diagnostic uses unqualified PostgreSQL catalog names. On its actual Prisma connection, a temporary pg_roles table changed its reported superuser flag without changing the real role. This is an evidence-integrity defect, not a demonstrated ability to bypass protected writes. Do not waive it or treat the old diagnostic as robust against a contaminated pooled session.

diagnostic-hardening.review.patch qualifies all catalog relations with pg_catalog and adds a transaction-local trusted search path after entering READ ONLY. The review-only candidate was executed on the same contaminated connection and returned the actual non-superuser role. It normalizes the diagnostic transaction's path; the reported search path describes that normalized transaction. This patch has not been applied to tracked source, committed, deployed, or included in source 18cb. Apply and validate it before reusing that diagnostic for cutover evidence. No historical 019 evidence is rewritten, and this test does not claim the 019 session was contaminated.

Release disposition

Retaining inherited TEMPORARY/CONNECT and public USAGE is compatible with the scoped barrier on the tested source and explicit ACLs. The revised role proposal is supported; no shared-database TEMP revoke is a prerequisite. Diagnostic hardening remains a concrete preparation item. Actual provisioning and cutover remain unauthorized in this phase.

All existing SDK/npm, producer, signing/verifier, supported-flow, actual-workload verification and writer-containment/drain gates remain open. Platform owns the separate retained-deployment containment investigation; Sales did not repeat it.

The coordinator also reported that a same-project session pooler on port 5432 ignored startup options. Local Prisma timeout success, the DIRECT_URL variable name and port 5432 are not production bounds evidence. Preserve actual target and SHOW checks before any future DDL. No URL-only migration helper is approved by this packet. Owner verification must prove effective limits on the actual migration connection, not an unrelated probe connection. No duplicate production connectivity investigation was performed.

The coordinator subsequently reported that Coaching's verified TLS direct connection to db.pfuctqiobbjglpukteei.supabase.co:5432, with the pinned public Supabase CA, honored startup read-only, statement, lock and idle limits and matched Coaching's journal. This supports the direct transport choice but is not Sales native-engine verification. Pin the CA and native-engine transport handling separately and retain the actual direct-target/SHOW gate before Sales DDL.

Root remains the canonical publisher. This is a local owner-authored draft, not a published coordination response. The live mirror/ledger was attempted through the browser tool but was inaccessible; no ledger completion was inferred or edited.