@m-kopa/launchpad-cli 0.33.0 → 0.34.1

package/CHANGELOG.md

@@ -6,6 +6,61 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 This project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html);
 pre-1.0 minor bumps may carry breaking changes per ADR 0005.
 
+## 0.34.1 — 2026-06-18
+
+Fix (sp-pvf8r2, Bundle A): `launchpad watch` now shows the **real** provisioning
+failure reason, and both `watch` and `status` advise `recover` when a failed app
+is probably live.
+
+- **`watch` no longer renders `✗ —: unknown`.** When a failure is recorded on the
+  registry but the `AppStatus` Durable Object never got a structured `failedAt`
+  (exactly what happens when the DO write itself is the casualty — e.g. a
+  transient Cloudflare Durable Object reset, the test-app-02 class), the watcher
+  now falls back to the registry's `lifecycleReason`, mirroring what
+  `launchpad status` already showed. The lifecycle endpoint already carried the
+  reason; only the CLI wasn't reading it — no bot change.
+- **Recover-vs-resume advice is now stage-based.** A failure at or after
+  `ready_for_content` (infra/cert/access all completed → the app may already be
+  serving) advises `launchpad recover <slug>` instead of `deploy --resume` /
+  re-running `deploy`. Earlier-stage failures still advise fix-and-redeploy.
+
+(Bundle B — making the provisioning Workflow treat a transient DO reset as
+retryable instead of a terminal failure — ships separately.)
+
+## 0.34.0 — 2026-06-18
+
+New verb: **`launchpad redeploy [<slug>]`** (sp-rdpl41) — trigger a fresh
+deployment of an app's **already-live content** so deploy-time config (a
+just-pushed secret, env var, or binding) re-binds, without editing any files.
+Closes the "pushed a secret, `launchpad deploy` says nothing to deploy, the
+secret stays inactive" foot-gun: a Cloudflare Pages app binds env/secrets only
+on a NEW deployment, but `deploy` is content-hash idempotent and no-ops on
+unchanged content.
+
+- **Distinct from `deploy` (ADR 0025).** `redeploy` makes **no git commit** and
+  never no-ops — it asks the bot to build what's already live. Activation stays
+  in the bot trust boundary (it holds the sole CF token); the verb is a thin
+  client over `POST /apps/<slug>/redeploy`.
+- **Falsifiable success signal.** Reports the **new Cloudflare deployment id**
+  (distinct from the previously-live one — proof the production env was
+  re-snapshotted), then served-verifies the live URL. If CF returns the same id
+  (no new deployment), it says so and exits non-zero — never a phantom
+  activation.
+- **Tier-aware.** Pages apps get a triggered deployment; Worker/container apps
+  bind on next invocation, so `redeploy` is an explicit no-op for them.
+- **`secrets push` offers it.** When a push writes a **Pages** surface, `push`
+  now ends with a tier-aware next-step: an interactive prompt
+  (`Redeploy … now? [y/N]`), `--redeploy`/`--yes` to activate without a prompt,
+  or — non-interactively — the `launchpad redeploy <slug>` hint (no silent prod
+  deploy; push and deploy stay decoupled). Worker-only pushes don't nag.
+- **Honest react verification.** Served-verify now reports a distinct
+  **reachability-only** outcome ("✓ Live and reachable (HTTP 200)") for
+  react/react+api apps instead of falsely claiming "serves exactly what you
+  shipped" — their build transforms source → output, so byte-equality can't be
+  checked. This makes both `deploy` and `redeploy` honest: a redeploy can't
+  silently ship a different build to prod under the guise of "just reactivating
+  a secret".
+
 ## 0.33.0 — 2026-06-17
 
 New verb: **`launchpad watch [<slug>]`** (and `launchpad status <slug> --watch`) —