Unsigned stop and completed retirement

Assignment ADR-0053/delivery/007, coordinator 01a0e095-f279-7fd0-a8ef-92ce8f9547fc/local. Root authorized one execution of source 248db5c24caa05a2acc066088c01521424e06e91, manifest 65ff9306235ebfaa7b6094f085ec2df0cec5ec83ac20cbe21e73980a1d6bffec, runner 504c0646ae8dd9b4117d0b1ce3f31bc409959998cf33706c00f323de76eeeb6d. Unsigned UUID d6f098a6-4643-4d7c-93e1-e52c5cf47181 passed baseline checks and exact-role activation COMMIT at 2026-10-03T08:41:03.626Z. The first actual restricted login failed with SQLSTATE 28P01, password authentication failed for user "delivery_proof_audit_adr0053". There was no login retry.

Immediate retirement passed at 2026-10-03T08:41:34.554Z: exact OID 13362275 is NOLOGIN/password NULL, explicit grants revoked, no dependencies or sessions. The accepted creator-admin relation and PUBLIC-derived baseline remain unchanged. Custody exited cleanly. This attempt is permanently stopped. No private signing key, temporary project env entry, diagnostic deployment, approval, acquisition POST or audit row was created. No Phase C or business call occurred.

Canonical delivery.sguildswim.com remains READY cleanup dpl_6kMSVcQWqehL1sT6xAb78DjRrbPi, source 5c36fd2021069d766b17f97032b4266c8d0b4f5a, exact project/team. Canonical proof-route POST returns 404 without authorization and with an invalid unsigned header. No former signed approval exists. Retained deployment URLs return protection 302, which does not prove route absence. All seven diagnostic env names are absent. The original 28 business env rows and settings retain SHA256 70223ace4a67985e33435fe636fb505b7eca2bdf4f524fa8b523b0c9ad79c82b and 1c659e643ec78fd56236f192798ea19d9cbf9958cc0a8d6db75a1d442184ee62.

Investigation result and limits

The current SCRAM-generation and URL/Pool construction blocks are byte-identical to the last successful restricted login, UUID 8be1d3a1-c4ee-4eac-ac78-0d5c7b3b6a94, activation 08:28:56.009Z, actual role/database verified and five denial probes passed. Block hashes are e7df2fdc3bc706f176a6b013e2306880b3dc227edf5900927795a72008d0490d and 66995c8b61ecc6c8dedd743a7a0f3637a5b2a47d16a9f35a92167cfab1dc4ea4 respectively.

An offline execution of the actual SCRAM block against installed pg 8.20.0 SASL passed client-proof/stored-key matching and server-signature validation. Its random unused password was ASCII hex, and URL password roundtrip passed. No secret or verifier was persisted or printed. PostgreSQL documents SASLprep handling; this ASCII input does not introduce normalization ambiguity. PostgreSQL 17 SASL documentation.

Fresh owner READ ONLY catalog checks established PostgreSQL 17.6, database postgres, exact role OID and retired flags. Server clock 08:45:33.840879Z precedes retained VALID UNTIL 09:11:03.216Z; the failure is not explained by that recorded expiry. This is post-retirement evidence, not a readback of LOGIN/password at the failed authentication instant.

The actual endpoint is shared Supavisor session mode, aws-1-us-east-1.pooler.supabase.com:5432, project pfuctqiobbjglpukteei, database postgres, schema delivery. Restricted username delivery_proof_audit_adr0053.pfuctqiobbjglpukteei retains target fingerprint 7ea5e8e561ff22e18793d0a1988d2c7acd4899218d1af94d1a81f06e94c7c913. Owner fingerprint remains d6b56c9972cc8c0c67476f060a2af8cd995c7d2b9e97bd1a27f84e5866f8d44c. Direct hostname db.pfuctqiobbjglpukteei.supabase.co resolves only IPv6 in the observed DNS readback; TCP reachability and direct authentication have not been tested.

Supabase documents temporary shared-pooler credential caching after custom-role password rotation, including SCRAM. Its recommended discrimination is a direct connection with the same credential followed by bounded pooler reconnects without repeated rotations. This makes caching a technically supported candidate, not an observed cause here. Supabase rotation guidance. Custom LOGIN roles require no separate pooler registration; shared and direct usernames differ. Supabase authentication guidance.

The failed credential and verifier were revoked and destroyed before comparison or direct login. Provider authentication logs were not available through the installed tools. The retained error metadata establishes 28P01 only. Neither cache state, wrong stored credential, nor provider fault is proven retrospectively.

Concrete preflight proposed for coordinator review

This is an authentication-only procedure, separate from the one acquisition POST. It creates no proof window, signing key, project env row, deployment, proof audit row or business-domain write. No procedure below has been executed or authorized yet.

1. Prepare a dedicated one-shot helper and review its exact source/hash before production execution. Preserve the existing custody runner and every stopped directory. Capture the exact revoked role/PUBLIC/membership/session baseline and pinned owner/pooler identities. A five-second unauthenticated TCP probe may establish direct IPv6 feasibility before activation. Do not change the production audit target, TLS verification or existing app artifacts.
2. Generate exactly one fresh random ASCII-hex credential and its SCRAM verifier in live memory. Activate only existing role OID 13362275 once, with LOGIN/password and a five-minute server-clock expiry. Add no audit grants or memberships; accepted PUBLIC CONNECT suffices for identity SELECT. Confirm COMMIT. Before any restricted login, an owner parameterized query returns only booleans for stored-verifier equality, exact OID/flags, LOGIN and future expiry. Compare the generated password with both URL-decoded and actual pg parsed connection parameters in memory. Persist booleans only. Any mismatch stops and retires the role immediately.
3. If direct IPv6 transport is available with the existing verified TLS policy, attempt one direct login with the same credential and unsuffixed role username. Read only current_user, current_database and server clock. Record separate diagnostic endpoint identity, sanitized outcome and latency; this does not substitute for the approved pooler fingerprint. A direct 28P01 stops before pooler retries. A transport/TLS failure is recorded as inconclusive, not invalid credentials or cache evidence.
4. Attempt the unchanged approved shared-pooler target at fixed elapsed offsets 0, 20 and 60 seconds from the pooler phase start, at most three connections, each with a five-second connection deadline and identity SELECT timeout. Stop at the first exact-role/database success. Retry only 28P01; circuit-breaker, transport, TLS or other errors stop. End the phase within 90 seconds and do not rekey. If direct transport is unavailable, these bounded pooler attempts can establish login readiness but cannot prove a cache cause. Direct success followed by initial pooler 28P01 and later same-credential success supports a transient pooler explanation; persistent failure stays unresolved.
5. In unconditional finally, close all helper clients, revoke LOGIN/password on the exact OID, terminate only its sessions, and verify password NULL, NOLOGIN, zero sessions, no new grants/dependencies and the accepted baseline. Persist sanitized outcomes, timestamps, SQLSTATE/message class and booleans only; destroy live secret references and exit. Any uncertain activation outcome still invokes owner teardown/readback. The helper has no path to deploy, sign or call the acquisition route.

Successful preflight is evidence for root review, not authority to start another proof window. A later window would require a separately reviewed sequence and credential lifetime, without reopening d6 or any other stopped attempt. The explicit-team CLI correction remains valid; its publication package in the preceding scope memo is unchanged. Root remains sole canonical publisher. G2, old runtimes and both ADR deadlines remain preserved.

Evidence pins

All evidence below is retained under the owned checkout .tmp/production007/prepared-scoped/; immutable STOP files were not rewritten.

The cleanup proof omitted its window field because activation stopped before that state field was assigned. The separate STOP annotation identifies d6 explicitly and pins both state and cleanup proof. Its actual audit query used the planned unsigned UUID. Its negative header was invalid, not a former signed header. These limits do not change zero POST/audit or verified retirement.