# Shared-Development External Retirement Runbook ## Status And Scope Repository runtime policy retired the permanent shared environment at `https://dev.stratofusion.io` on August 5, 2026. This runbook governs the remaining external shutdown. It does not authorize any external mutation. Local Windows development, optional local-VM rehearsal, CI, and production at `https://stratofusion.io` remain. Do not replace the retired environment with a permanent staging deployment on the production VM. Temporary staging requires separate, time-bounded migration or rehearsal approval. ## Approval Boundary Obtain explicit approval for each exact external target before changing it: - DNS record(s) for `dev.stratofusion.io`. - Vercel project/domain assignment for `stratofusion-dev`. - Neon development project, branch, database, and retained backups. - stopped Fly app `stratofusion-rclone-dev`. - development Clerk instance, allowed origins, and social connections. - Stripe test webhook endpoint and any dev-only test resources. - Google OAuth client, Microsoft Entra registration, and Dropbox app used by the retired origin. - dev-only secrets, tokens, credentials, and callback registrations. - Git `dev` branch deletion or repurposing. Do not probe or start stopped Fly Machines. Never print or copy secret values, tokens, auth codes, full database URLs, or env-file contents into evidence. ## Current Retention And Tombstone Defaults - Neon development data: **retain by default** until an owner records either retention value and export requirements or an explicit discard decision. Unknown value is not approval to delete. - DNS transition: a controlled static `410 Gone` tombstone for about two weeks is recommended because the hostname was long-lived. The tombstone must have no sign-in, API, cron, webhook, database, rclone, or background-writer path. An operator may choose immediate NXDOMAIN instead only with a recorded rationale and confirmation that no client, webhook, callback, or support workflow still relies on the hostname. ## Ordered Procedure ### 1. Establish A Read-Only Baseline And Retention Decision 1. Record the exact project/app/resource identifiers without recording secret values. 2. Identify owners, last observed use, data classes, retention obligations, export format, and recovery expectations for Neon development data. 3. Confirm local `.env.local` and the local-VM configuration use local PostgreSQL and test Clerk/provider/Stripe resources independently of the retired Vercel origin. 4. Record one decision: `retain`, `export then delete`, or `discard`. A delete decision needs explicit approval naming the exact Neon target. Stop if local or local-VM work consumes any candidate integration. Separate or document that dependency before continuing. ### 2. Disable Writers Before Data Or Routing Changes 1. In Vercel, verify the dev project's Git integration is disconnected. 2. Enumerate dashboard cron schedules. Disable each dev schedule and record its path, former cadence, time, and verification evidence. 3. Enumerate other writers: Stripe webhooks, provider webhooks, queue workers, scheduled jobs, external monitors with write callbacks, and manual deploy hooks. Disable or prove each inactive. 4. Verify the authoritative VM still has exactly one production cron replica and that local replay remains localhost-only. Repository `vercel.json` having no schedules is useful evidence, but it is not proof that dashboard schedules are absent. ### 3. Export Or Record Explicit Discard Of Neon Development Data If retention is approved, create a dated, encrypted export in an approved location, record its checksum, access owner, retention period, and a restore test that does not touch production. If discard is approved, record the exact project/branch/database, approver, date, and known recovery loss. Do not delete Neon resources in this stage. Do not treat a connection string or DNS switch as a backup. ### 4. Remove Dev Stripe Webhook Writers 1. Identify the Stripe **test-mode** endpoint whose destination is `https://dev.stratofusion.io/api/webhooks/stripe`. 2. Confirm local development uses Stripe CLI forwarding to localhost and that production live mode still targets the apex endpoint. 3. With approval for the exact test endpoint, disable/delete it and verify no delivery retries remain. 4. Do not modify live-mode products, prices, customers, subscriptions, endpoints, or secrets. ### 5. Remove Retired OAuth Origins And Redirects After local and local-VM independence is proven, obtain approval for the exact entries and remove only the retired origin from: - Clerk allowed origins and dev social-connection configuration. - Google direct callback and any dev Clerk callback no longer used locally. - Microsoft Entra Web redirect and any dev Clerk callback no longer used. - Dropbox redirect URI. Verify localhost, exact local-VM callbacks (when intentionally retained), the apex production callbacks, and the controlled production-rehearsal callbacks remain unchanged. Never infer that a resource named `dev` is unused. ### 6. Revoke Dev-Only Credentials And Secrets Inventory secret *names and consumers*, not values. After callbacks and writers are inactive, approve and revoke only credentials proven exclusive to the retired environment. Remove their references from Vercel, the stopped Fly dev app, CI, Clerk, and provider dashboards as applicable. Verify local and production startup/auth paths still use their intended credentials. ### 7. Optional Time-Bounded `410 Gone` Tombstone If approved, replace the old application with a static no-write tombstone on the existing dev project for 14 days (maximum 28). Verify: - normal pages and former API/callback/webhook/cron paths return `410`; - no Clerk, database, Stripe, provider, rclone, cron, or background-worker configuration is present; - production and local traffic are unaffected; - the removal date and owner are recorded. This is a retirement notice, not a shared development deployment. If immediate NXDOMAIN is chosen, record why a tombstone provides no operational value. ### 8. Detach The Vercel Domain Before DNS Or Project Deletion At the end of the tombstone window (or immediately for approved NXDOMAIN), detach `dev.stratofusion.io` from the Vercel project first. Verify the project no longer claims the custom domain and that no other project claims it. This ordering prevents a dangling-domain condition when the DNS target or project is removed. ### 9. Remove DNS With separate DNS approval, remove only the exact retired record(s). Verify authoritative and public resolution reaches NXDOMAIN/no-answer after TTL expiry and that the apex, `www`, rclone, observability, email, and approved rehearsal records are unchanged. ### 10. Delete External Resources Only With Separate Approvals After observation and verification, request separate approvals before deleting: - Vercel `stratofusion-dev`. - the exact Neon development project/branch/database. - stopped Fly app `stratofusion-rclone-dev`. - unused Clerk instance or social connections. - unused Google, Microsoft, Dropbox, Stripe test, or other identity resources. Deletion approval for one resource does not authorize another. Capture the platform's deletion result and known recovery limits without copying secrets. ### 11. End-To-End Verification Verify all of the following after every destructive stage: - production app, PostgreSQL, rclone, TLS, observability, backups, and exactly one VM cron replica are healthy; - production Google, Microsoft, Dropbox, Clerk, and Stripe live flows retain apex callbacks and expected modes; - local app, local PostgreSQL, local rclone, local cron replay, and Stripe CLI forwarding still work; - local-VM rehearsal still uses its exact hosts-file origin and test resources; - CI passes environment, host, CORS, cron, OAuth, type, lint, and relevant worker tests; - the retired hostname returns the intended `410` during the window or no longer resolves afterward; - stopped Fly production recovery resources were not probed, started, or altered. ### 12. Closeout Evidence Record: - every deleted, disabled, detached, revoked, exported, and retained item; - exact targets, approvals, timestamps, operator, and verification result; - data-retention decision, export checksum/location owner, and restore proof; - tombstone choice, dates, and NXDOMAIN verification; - production and local/local-VM smoke results; - recovery limitations and residual cost/ownership. ## Rollback Limits Before destructive deletion, rollback may re-enable a schedule, reattach a domain, or restore a callback only if doing so does not reintroduce writers or mix environments. After credential revocation, resource deletion, or database deletion, recovery may require new credentials, a platform support request, or a tested export restore. DNS-only rollback is never sufficient after any replacement database accepts writes. Database state must be reconciled deliberately before traffic moves. ## Git `dev` Branch Recommendation The branch is not an application deployment source. Review unique commits, open work, protection rules, CI consumers, and references. Then request explicit approval to either archive/delete it or document a CI-only purpose. Do not delete, rename, or repurpose it as part of this runbook without that approval.