Memory
PLATFORM-SIDE SECRETS STORE PLAN (Sep 2, 2026, underway — admin Worker changes, not yet implemented). KEY FINDING: secrets_store_secrets is a TOP-LEVEL metadata field in the CF multipart upload API, NOT an entry in the bindings array. Shape: {binding, store_id, secret_name}. Sphere reads at runtime via await env.PLATFORM_SERVICE_TOKEN.get() — no secret_text binding needed on the admin side. Changes: 1. admin/src/pages/api/customers/[id]/deploy-worker.ts — remove the secret_text binding for PLATFORM_SERVICE_TOKEN (line 131), remove it from the locals.runtime.env destructuring (line 93), add top-level secrets_store_secrets: [{binding: 'PLATFORM_SERVICE_TOKEN', store_id: '0cf654598e6d4511ba6e8b5c50134ab6', secret_name: 'PLATFORM_SERVICE_TOKEN'}] to the deploy metadata. 2. admin/src/workflows/sphere_update_all.ts — add 'secret_store' to keep_bindings (currently ['secret_text','secret_key'] at line 62) AND add secrets_store_secrets metadata to both canary (~line 63) and rollout (~line 119) deploys so the binding survives re-uploads. 3. admin/src/workflows/sphere_revectorize.ts — add 'secret_store' to keep_bindings (line 102). 4. admin/src/lib/cloudflare.ts — NO change; deployUserWorkerDirect passes metadata through to the CF API as-is. 5. admin/src/workflows/sphere_provision.ts — remove PLATFORM_SERVICE_TOKEN: string from the Env type (line 17). 6. admin/wrangler.jsonc — remove PLATFORM_SERVICE_TOKEN from secrets.required (line 54); the admin Worker no longer needs the secret since spheres read it from Secrets Store directly. Verification: provision new customer via POST /api/customers → deploy via POST /api/customers/{id}/deploy-worker → confirm secrets_store_secrets binding present in CF dashboard → verify env.PLATFORM_SERVICE_TOKEN.get() works inside a sphere endpoint.
[Update Sep 2, 2026]: Update (Sep 2, 2026, ~5:48pm BST): PLAN EXECUTED + VERIFIED. All six changes landed as planned: deploy-worker.ts injects secrets_store_secrets as top-level metadata (store 0cf654598e6d4511ba6e8b5c50134ab6) instead of the secret_text binding; sphere_update_all.ts and sphere_revectorize.ts both have 'secret_store' in keep_bindings; sphere_provision.ts Env type and admin wrangler.jsonc secrets.required no longer carry PLATFORM_SERVICE_TOKEN. Verified end-to-end: 'test-secrets' sphere deployed with the Secrets Store binding, health check passes, customer status active. Sphere reads the token at runtime via env.PLATFORM_SERVICE_TOKEN.get(); no plaintext on the admin side anywhere. Bonus evidence: the CF API deploy path accepted secrets_store_secrets metadata without auth errors — the CF_API_TOKEN Secrets Store permission concern (workers-sdk 8964) did not bite in practice, and this same injection mechanism is now proven for future per-customer Cloudflare OS deployments (the $SECRET placeholders map onto it directly). STILL OPEN: the manual extraction-flow smoke test from the ingestion deploy report (55c99e86) — needs the token fetched from the CF dashboard + one authorised curl to /extract.
Tags: docuclear, secrets-store, platform, admin-worker, plan, underway, volatility:state, project:docuclear, kind:episodic — Source: mcp — 2026-09-02 16:09:39 UTC