@m-kopa/launchpad-cli 0.56.0 → 0.56.1

package/CHANGELOG.md

@@ -8,6 +8,14 @@ pre-1.0 minor bumps may carry breaking changes per ADR 0005.
 
 ## Unreleased
 
+## 0.56.1 - 2026-08-17
+
+**Destroy now removes bot-owned resources without sacrificing D1 recovery.**
+
+- After Terraform succeeds, the portal bot exports the recorded D1 UUID to private R2, verifies the stored SQL object, deletes that database and declared cron Workers, and only then archives the app repository.
+- D1 exports are retained for 30 days under `destroy-exports/<slug>/<uuid>.sql`, with a platform runbook for restoring an accidentally destroyed database.
+- Unknown resource identity, export failure, cross-app Worker ownership conflict, or deletion failure leaves the app in `destroy_failed` with its repository unarchived.
+
 ## 0.56.0 - 2026-08-17
 
 **Container runtime validation and deploy status pages are now available from the CLI.**

package/dist/cli.js

@@ -19,7 +19,7 @@ var __toESM = (mod, isNodeMode, target) => {
 var __require = /* @__PURE__ */ createRequire(import.meta.url);
 
 // src/version.ts
-var CLI_VERSION = "0.56.0";
+var CLI_VERSION = "0.56.1";
 
 // src/config.ts
 import { readFileSync } from "node:fs";

package/dist/version.d.ts

@@ -1,2 +1,2 @@
-export declare const CLI_VERSION = "0.56.0";
+export declare const CLI_VERSION = "0.56.1";
 //# sourceMappingURL=version.d.ts.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@m-kopa/launchpad-cli",
-  "version": "0.56.0",
+  "version": "0.56.1",
   "description": "Launchpad CLI — clone / deploy / review / merge against Launchpad-managed apps. Talks to the portal-bot endpoints (SCOPE-M-760 / T4).",
   "type": "module",
   "bin": {

package/skills/launchpad-content-pr/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: launchpad-content-pr
 description: Push a content change to a Launchpad app via `launchpad deploy` and verify it shipped via `launchpad status`. Covers the post-first-deploy iteration loop (edit → deploy → verify) — subsequent deploys commit directly to the app repo's main and the Pages build runs asynchronously, so verification is its own step. Use when someone says "push a content change", "ship an update", "/launchpad-content-pr", "verify my deploy", or after `/launchpad-deploy` reports `done` and they want to follow up with an edit.
-version: 0.56.0
+version: 0.56.1
 ---
 
 <!-- BEGIN shell-contract (managed by scripts/sync-skill-contract.sh — edit skills/_partials/shell-contract.md) -->

package/skills/launchpad-deploy/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: launchpad-deploy
 description: Walk a Launchpad user through deploying an app from their local working directory (Model A — `launchpad init` + `launchpad deploy`). Wraps the CLI verbs end-to-end: detects the app shape, scaffolds `launchpad.yaml`, resolves the allowed Entra group via `launchpad groups`, bundles the CWD via `launchpad deploy`, and watches the rollout via `launchpad status`. Use when someone says "deploy a new app", "ship my app to Launchpad", "/launchpad-deploy", "I have an app locally — get it on Launchpad", or any variant. Resume/abandon for legacy in-flight provisioning is at the bottom.
-version: 0.56.0
+version: 0.56.1
 ---
 
 <!-- BEGIN shell-contract (managed by scripts/sync-skill-contract.sh — edit skills/_partials/shell-contract.md) -->
@@ -458,13 +458,8 @@ targets:
     d1_binding: DB        # env binding name your /api code reads
 ```
 
-On `launchpad deploy` the bot auto-provisions the shared D1 named after the
-slug (**create-or-adopt by slug, never deleted** — a re-provision adopts the
-existing database) and binds it to the Pages app, so `env.DB` works with no
-manual `wrangler d1 create`. The bot also pins the matching
-`[[d1_databases]]` block into the **committed** `wrangler.toml` — Pages
-git-source builds read bindings from that file, and a build without the
-block silently resets the binding to empty.
+On `launchpad deploy` the bot auto-provisions the shared D1 named after the slug (**create-or-adopt by slug during deploy** - a successful destroy exports and deletes the recorded UUID before repository archive, so platform recovery creates a fresh destination database) and binds it to the Pages app, so `env.DB` works with no manual `wrangler d1 create`.
+The bot also pins the matching `[[d1_databases]]` block into the **committed** `wrangler.toml` - Pages git-source builds read bindings from that file, and a build without the block silently resets the binding to empty.
 
 **Empty-DB gotcha:** the platform provisions an **empty** database — schema
 and migrations are the app's job. The usual pattern is idempotent

package/skills/launchpad-deploy-status/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: launchpad-deploy-status
 description: Show the current provisioning stage + failure reason for a Launchpad app via `launchpad status` (Model A drift + deployment_verified) and `launchpad apps` (lifecycle bucket), or watch provisioning live with `launchpad watch`. Renders the M-892 stage trace for in-flight provisioning, and is the canonical home for `launchpad recover` (repair a terminal-failed app record that is actually live). Use when someone says "what's the status of demo-X", "/launchpad-deploy-status", "is my deploy stuck", "watch my deploy go live", "watch provisioning", "my app says failed but it's serving", or after `/launchpad-deploy` reports a non-`done` terminal stage.
-version: 0.56.0
+version: 0.56.1
 ---
 
 <!-- BEGIN shell-contract (managed by scripts/sync-skill-contract.sh — edit skills/_partials/shell-contract.md) -->

package/skills/launchpad-destroy/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: launchpad-destroy
 description: Tear down a Launchpad app end-to-end via `launchpad destroy` — Cloudflare Pages project, edge-auth wiring (gateway KV/audience entries, or the Access app for `auth: access` apps), custom hostname, platform-repo TF, and the app repo (archive-renamed). Owner-only verb with a two-step destructive confirmation. Use when someone says "destroy this app", "/launchpad-destroy", "tear down `<slug>`", "delete the app", or asks to clean up a smoke-test / orphan / retired app.
-version: 0.56.0
+version: 0.56.1
 ---
 
 <!-- BEGIN shell-contract (managed by scripts/sync-skill-contract.sh — edit skills/_partials/shell-contract.md) -->
@@ -162,15 +162,15 @@ Still shipped, for apps whose TF is the shared-root `<slug>.tf` +
    before (AC8). If tf-apply fails, the repo is untouched and
    lifecycle moves to `destroy_failed`.
 
-## What destroy does NOT remove
+## D1 export and recovery window
 
-**The app's D1 database is never dropped.** D1 databases are
-bot-API-created (not in the app's TF), and no destroy path touches
-them. The bot's D1 handling is create-or-adopt **by name**: the data
-survives the destroy, and a later `launchpad init` + `launchpad
-deploy` of the **same slug** re-adopts the existing database — your
-data is still there. If you genuinely need the data gone, that is a
-platform-team request, not a destroy side-effect.
+The bot owns D1 databases and declared cron Workers that Terraform cannot remove.
+After Terraform succeeds, destroy exports the recorded D1 UUID to the private `mkopa-launchpad-registry-snapshots-prod` R2 bucket, verifies the stored SQL object, deletes the D1 and Workers, then archive-renames the repo.
+The deterministic object key is `destroy-exports/<slug>/<uuid>.sql` and the bucket lifecycle retains it for 30 days.
+
+Unknown D1 identity, a failed R2 export, a failed delete, or an ownership conflict leaves the app in `destroy_failed` with the repo unarchived.
+Never bypass that failure by deleting a D1 by name.
+Use the platform runbook `docs/runbooks/d1-destroy-export-restore.md` to recover an accidentally destroyed database within the retention window.
 
 ## Lifecycle states
 
@@ -180,7 +180,7 @@ platform-team request, not a destroy side-effect.
 | `provisioning` | Initial create still running. | Wait, then destroy. |
 | `failed` | Provisioning failed. | Destroy works (cleans up partial state). If the app is actually live and serving, consider `launchpad recover <slug>` first — it repairs the record instead of tearing down. |
 | `destroying` | Teardown in flight (workspace: destroy run dispatched; legacy: destroy PR open, tf-apply pending). | Re-running `launchpad destroy` is idempotent — workspace: re-dispatches the run; legacy: returns the existing PR. |
-| `destroyed` | Teardown succeeded + repo archive-renamed. | Re-running exits 0 with `already destroyed at <ts>`. Slug is free for re-use. |
+| `destroyed` | Teardown succeeded + repo archive-renamed. | Re-running exits 0 with `already destroyed at <ts>`. The slug remains retired until platform recovery proves live infrastructure. |
 | `destroy_failed` | The teardown failed or hung. | **Workspace path:** re-run `launchpad destroy` — it re-dispatches from the failure point. **Legacy path:** re-run is rejected with `platform-team intervention required` (409). On both, the app repo is **not** archive-renamed (recovery path stays clean). |
 
 ## Carve-outs
@@ -234,24 +234,22 @@ GitHub's `archived: true` flag set. **There is no `launchpad
 undestroy` verb.** Recovery is operator self-service via `gh`:
 
 ```bash
-# Rename back + unarchive (within ~30 days; check org policy).
+# Unarchive, then rename back while the dated repository still exists.
 # `gh repo rename` takes a single positional <new-name>; the OLD
 # repo is specified via --repo (or -R).
+gh repo unarchive M-KOPA/launchpad-app-<slug>-archived-<YYYYMMDD>
 gh repo rename launchpad-app-<slug> \
   --repo M-KOPA/launchpad-app-<slug>-archived-<YYYYMMDD>
-gh repo unarchive M-KOPA/launchpad-app-<slug>
 ```
 
-This restores the **repo**, not the Cloudflare infrastructure — you
-would still need a fresh `launchpad init` + `launchpad deploy` (or a
-hand-rolled platform-repo PR re-adding the per-app TF) to bring the
-app back online. Remember the app's D1 database survived the destroy
-(see "What destroy does NOT remove") — a same-slug re-provision
-re-adopts it.
+This restores the **repo**, not the Cloudflare infrastructure.
+The destroyed tombstone blocks `launchpad init` and `launchpad deploy` until live infrastructure is proven.
+Follow `docs/runbooks/d1-destroy-export-restore.md`: create and seed the replacement D1, commit its new UUID in the restored app repository, restore the app's last per-app Terraform workspace through a reviewed platform PR, verify the resulting Pages deployment and gateway route, then run `launchpad recover <slug>`.
 
-**The 30-day window is informational, not enforced by Launchpad** —
-the actual horizon is whatever GitHub's org policy is. If you
-suspect a destroy was a mistake, recover within hours, not weeks.
+**Recovery has two independent horizons.**
+The configured R2 lifecycle expires the D1 SQL export after 30 days and is the authoritative database recovery limit.
+The archived GitHub repository follows the organisation's separate retention policy.
+Start either recovery within hours, not weeks.
 
 ## Exit codes
 

package/skills/launchpad-identity/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: launchpad-identity
 description: Teach an app author how to use the signed-in user's identity inside a Launchpad app — read the gateway-forwarded X-Launchpad-User-Assertion in a Pages Function, VERIFY it with @m-kopa/platform-auth (fail-closed), and show who's logged in (sub/email/name). Use when someone says "who is logged in", "show the current user", "get the user's email in my app", "auth in my launchpad app", "read the user identity", "/launchpad-identity", or is wiring up an /api/me for a gateway-fronted app.
-version: 0.56.0
+version: 0.56.1
 ---
 
 <!-- BEGIN shell-contract (managed by scripts/sync-skill-contract.sh — edit skills/_partials/shell-contract.md) -->

package/skills/launchpad-onboard/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: launchpad-onboard
 description: One-time setup for the Launchpad CLI + Claude Code skill bundle. Verifies the `launchpad` CLI is installed and current, runs `launchpad whoami` to confirm the session is fresh, and checks the bundled skills are installed and in lock-step with the CLI. Idempotent — safe to re-run any time. Use when someone says "set me up for Launchpad", "I just got a new machine and want to use Launchpad", "/launchpad-onboard", or any of the other launchpad-* skills fails on a prereq check.
-version: 0.56.0
+version: 0.56.1
 ---
 
 <!-- BEGIN shell-contract (managed by scripts/sync-skill-contract.sh — edit skills/_partials/shell-contract.md) -->

package/skills/launchpad-report/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: launchpad-report
 description: File a bug report or feature request to the Launchpad team's tracker from the CLI. Use when someone reports something broken, hits an error in a launchpad command, or wishes a feature existed — e.g. "this is broken", "report a bug", "can you file that", "I wish launchpad could…", "/launchpad-bug", "/launchpad-feature". Always confirm and show exactly what you'll send before filing; never file silently.
-version: 0.56.0
+version: 0.56.1
 ---
 
 <!-- BEGIN shell-contract (managed by scripts/sync-skill-contract.sh — edit skills/_partials/shell-contract.md) -->

package/skills/launchpad-status/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: launchpad-status
 description: Safely refresh a Launchpad clone, show manifest drift, or read the deployed manifest. Wraps bare `launchpad pull` for source sync, `launchpad pull --manifest` for deployed YAML, and `launchpad status` for drift. Use for "sync my clone", "what's deployed", "show drift", "/launchpad-status", "/launchpad-pull", or post-deploy verification.
-version: 0.56.0
+version: 0.56.1
 ---
 
 <!-- BEGIN shell-contract (managed by scripts/sync-skill-contract.sh — edit skills/_partials/shell-contract.md) -->