Local orchestration ready for coordinator review
Assignment ADR-0053/delivery/007, coordinator 01a0e095-f279-7fd0-a8ef-92ce8f9547fc/local. This memo and corrected local helper are staged for root's review and sole publication. No further production mutation occurred. The previous unsigned UUID 467b399c-e19c-40d3-829f-da3530ae300c remains stopped.
The original POST response was not retained, so its exact envelope cannot be claimed as observed. Its observed GET recovery metadata proves that the single encrypted entry existed and was removed. Vercel's current primary documentation shows created as an object for a single-entry request: Create one or more environment variables. The former response.created?.[0] ?? response discarded that documented object and selected the outer envelope. This is a source-supported explanation of the observed parser failure, rather than a new production experiment.
The correction accepts one created object, one-element created array, or one flat entry, validates exact key/ID/production target, and records only selected nonsecret metadata. Before any create POST it persists the exact requested key, timestamp and preexisting IDs, without the value. The same key is never POSTed again after that intent, including after timeout, malformed response, process restart or late readback. A GET must recover exactly one new matching entry with production target and proven creation chronology; ambiguous, old or absent entries stop. API-reported failures still stop while retaining any attributable ID for cleanup.
Deletion likewise persists its exact ID before DELETE, then verifies that ID is absent. A lost successful delete response can be reconciled without another delete. It never removes a different ID or business key. The revised helper exposes readback recovery, preserves stopped-attempt files in a separate fresh directory, consumes the prepared unsigned UUID, and points to the pinned Linux CLI helper. Close explicitly ends the input reader and releases live references. Role drain now handles the observed Supavisor application name only for the exact owned role and sessions created after this provisioning attempt; unrelated session names or chronology stop.
The before/after custody files and minimal unified diff are pinned in docs/adr0053-workload-proof/orchestration/fix-manifest.json, SHA256 8b070adaacbf0f4b3ff0b22726ab03948493ddcfae8c2a254124e38f7567a148. Corrected runner custody.mjs SHA256 is 53522f77180f5f2a986ab614bbb6a2410a6703864782c81b6a039864d09d648b; journal env-journal.mjs SHA256 is b2fc7bc617654f73fbb42d832d8f41bff1e7d3313d13fe78e08cfa3ed437c6de. Fixtures exercise actual recovery decisions rather than mirroring just the successful parser path: all 16 pass. Node syntax checks, npm test and npm run typecheck pass. The reviewed packaged route and artifacts were not rebuilt or changed.
Fresh GET-only control-plane and local-byte preparation at 2026-10-03T08:14:16.446Z confirms canonical READY baseline dpl_7d4kFJiqwn5nxo6C35iS2bT7jkDL at source 51cf142c1e24863fafadc09f5b5541ce068246f0; cleanup dpl_6kMSVcQWqehL1sT6xAb78DjRrbPi remains READY and unaliased at reviewed source 5c36fd2021069d766b17f97032b4266c8d0b4f5a. All 508 cleanup uploaded regular files match, contained links reuse prior evidence, both reviewed local artifacts match their pinned manifests, and all 28 business entries/settings retain their exact prior hashes. Diagnostic source remains fb4bf54cf033cf47f2642bdcafe28e4498e5e951.
Fresh planned unsigned UUID is ebe659cf-6da2-4d35-9fa3-aa003ab0a762. No key, credential or signed approval was created for it. Preparation evidence .tmp/production007/prepared-next/preparation-readback.json SHA256 is db367a425ace887ed4ea6dc7931a606f397196f86014280ba2263f6b4a3e9a05.
The retained exact role is NOLOGIN/revoked. The corrected helper deliberately preserves the CREATE-only preflight and cannot run a new attempt against that existing role. Root review must explicitly choose the exact owned-role preparation before further execution, either removal after verifying no owned dependencies and recreation under the accepted privileges, or an explicitly reviewed reactivation after verifying the exact revoked role, no existing sessions, ownership, memberships and effective grants. No such mutation or authority expansion has been implemented or attempted here. The helper also requires an explicit execution flag, so loading this preparation does not initiate production work.
After root reviews that concrete role preparation and corrected orchestration, the proposed sequence remains: fresh baseline/settings/role checks, retained cleanup byte verification, ephemeral restricted credential and live Ed25519 custody, exact seven journaled env creates, diagnostic READY unaliased with exact artifact checks, deletion/readback of only created IDs and original business snapshot, one signed bounded acquisition window and one empty canonical POST, immediate cleanup promotion on every outcome, exact role revocation/drain, canonical 404 and honest retained-URL status, audit retention and expiry of that same window. No retry of the stopped attempt, diagnostic redeploy to guess output, Phase C exchange or business mutation is authorized by this preparation.
All prior G2 evidence and isolated runtimes remain preserved. ADR-0052 and ADR-0053 deadlines are unchanged. This is local orchestration and read-only preparation, not evidence of successful production workload acquisition.