@m-kopa/launchpad-cli 0.32.1 → 0.32.2

package/CHANGELOG.md

@@ -6,6 +6,28 @@ 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.32.2 — 2026-06-17
+
+Docs: skill-accuracy sweep. Audited all bundled skills against the live
+CLI/bot/`platform-auth` source and corrected three stale claims:
+
+- **`launchpad-content-pr`** — the deploy section said `launchpad deploy` is
+  fire-and-forget and "always verify with `launchpad status`". Since sp-dplvfy,
+  a Model-A deploy **verifies the served content in-line by default** (waits for
+  the Pages build, byte-compares the entrypoint, exits non-zero on
+  failure/mismatch). Documented the default-verify behaviour and the
+  `--no-verify` / `--verify-timeout=<secs>` flags; `launchpad status` is now
+  framed as the fallback when verify is skipped or times out at `pending`.
+- **`launchpad-deploy-status` + `launchpad-status`** — the drift-report field
+  list named `access.allowed_entra_group` (singular); the path the CLI actually
+  emits in `driftFields` / the `drift:` line is `access.allowed_entra_groups`
+  (plural, `status.ts:478`). Corrected (3 occurrences).
+- **`launchpad-onboard`** — the sibling-skill list omitted `/launchpad-identity`
+  (added to the bundle in 0.32.1). Added it.
+
+Skill content only — no behaviour change. Re-run `launchpad update` (or
+`launchpad skills update`) to pick up the corrected skills.
+
 ## 0.32.1 — 2026-06-17
 
 Fix: `launchpad skills install/update` now installs `launchpad-identity`. The

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.32.1";
+var CLI_VERSION = "0.32.2";
 
 // src/config.ts
 import * as os from "node:os";

package/dist/version.d.ts

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@m-kopa/launchpad-cli",
-  "version": "0.32.1",
+  "version": "0.32.2",
   "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.32.1
+version: 0.32.2
 ---
 
 <!-- BEGIN shell-contract (managed by scripts/sync-skill-contract.sh — edit skills/_partials/shell-contract.md) -->
@@ -96,11 +96,17 @@ What happens:
   the bundle **directly to `main`** on `launchpad-app-<slug>` via
   the Git Data API — you are the commit author, the bot is the
   committer. No PR, no merge step.
-- The CLI returns at the bot's 202 ack — `✓ Bundle accepted —
-  committed as <sha>`, then "Committed; build pending". It does
-  **not** wait for the Pages build: a successful deploy is **not** a
-  live app yet — the build runs asynchronously and can fail after
-  the commit lands. Always confirm with `launchpad status`.
+- The CLI prints the bot's 202 ack — `✓ Bundle accepted —
+  committed as <sha>`, then "Committed; build pending". By default it
+  then **waits for the Pages build and verifies it** (up to ~180s):
+  it byte-compares the served entrypoint against what you shipped and
+  prints `✓ Verified — the live deployment serves exactly what you
+  shipped`, or exits non-zero if the build fails or the served bytes
+  don't match (sp-dplvfy). Tune with `--verify-timeout=<secs>`, or skip
+  it with `--no-verify` (commit only, return immediately). When verify
+  is skipped or times out (`pending`), the commit landed but the build
+  is still async and can fail afterwards — confirm with
+  `launchpad status`.
 
 Flags worth knowing:
 
@@ -117,11 +123,15 @@ Flags worth knowing:
 Exit codes:
 
 - **0** — bundle accepted and committed (or "nothing to deploy"
-  when `main` already matches the bundle). This is **not** proof the
-  app is live — verify with `launchpad status`.
+  when `main` already matches the bundle), **and** default in-line
+  verification confirmed the live deployment serves it. With
+  `--no-verify`, or if verification times out at `pending`, exit 0
+  means only that the commit landed — confirm with `launchpad status`.
 - **non-zero** — gate rejections are rendered with per-file detail
-  on stderr; fix the bundle and re-run. For provisioning-phase
-  failures see `/launchpad-deploy-status <slug>`.
+  on stderr; fix the bundle and re-run. A build failure or a
+  served-content mismatch caught by default verification also exits
+  non-zero. For provisioning-phase failures see
+  `/launchpad-deploy-status <slug>`.
 
 ## What the bot enforces on every bundle
 
@@ -263,9 +273,11 @@ Once you've shipped first content, the daily-use verbs are:
   hand-rolled change bypasses the bundle policy, secret-scan,
   build-command gates, and the standing-exception ledger. Use
   `launchpad deploy`.
-- Do **not** treat exit 0 from `launchpad deploy` as "live". The
-  commit landed, but the Pages build runs asynchronously and can
-  fail afterwards — always verify with `launchpad status`.
+- Do **not** treat exit 0 from `launchpad deploy --no-verify` (or a
+  run whose verification timed out at `pending`) as "live". The commit
+  landed, but the build is still async and can fail afterwards —
+  verify with `launchpad status`. A default deploy (verification on)
+  already byte-checks the served content before exiting 0.
 - Do **not** re-implement the server-side gates locally.
   `launchpad validate` plus the CLI's own app-boundary pre-flight
   cover the local half; the bot enforces the rest server-side and

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.32.1
+version: 0.32.2
 ---
 
 <!-- BEGIN shell-contract (managed by scripts/sync-skill-contract.sh — edit skills/_partials/shell-contract.md) -->

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). 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", "my app says failed but it's serving", or after `/launchpad-deploy` reports a non-`done` terminal stage.
-version: 0.32.1
+version: 0.32.2
 ---
 
 <!-- BEGIN shell-contract (managed by scripts/sync-skill-contract.sh — edit skills/_partials/shell-contract.md) -->
@@ -90,7 +90,7 @@ Live-app states:
 - **`drift: <field list>`** — local and deployed differ on at least
   one v1 closed-set field (`metadata.name`, `metadata.team`,
   `metadata.owner`, `metadata.description`, `deployment.type`,
-  `access.allowed_entra_group`, `hostnames[0]`, `build.command`,
+  `access.allowed_entra_groups`, `hostnames[0]`, `build.command`,
   `build.destination_dir`, `build.root_dir`, `production_env.*`).
   Run `launchpad deploy` to roll the local manifest out.
 - **`live_no_content`** — provisioned, but no content deployed yet.

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.32.1
+version: 0.32.2
 ---
 
 <!-- BEGIN shell-contract (managed by scripts/sync-skill-contract.sh — edit skills/_partials/shell-contract.md) -->

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.32.1
+version: 0.32.2
 ---
 
 <!-- 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.32.1
+version: 0.32.2
 ---
 
 <!-- BEGIN shell-contract (managed by scripts/sync-skill-contract.sh — edit skills/_partials/shell-contract.md) -->
@@ -39,9 +39,9 @@ a copy-pasteable fix for any red row.
 This is the **only** skill that mutates the user's machine (it can
 trigger `launchpad login` and suggest installs). The other skills
 (`/launchpad-deploy`, `/launchpad-deploy-status`,
-`/launchpad-content-pr`, `/launchpad-status`, `/launchpad-destroy`)
-assume the machine is already onboarded and fail loudly if a prereq is
-missing — pointing back here.
+`/launchpad-content-pr`, `/launchpad-status`, `/launchpad-destroy`,
+`/launchpad-identity`) assume the machine is already onboarded and fail
+loudly if a prereq is missing — pointing back here.
 
 ## Zero non-Launchpad dependencies
 

package/skills/launchpad-status/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: launchpad-status
 description: Show whether a Launchpad app's local launchpad.yaml matches what's deployed, and read the deployed manifest. Wraps `launchpad pull` (fetch deployed YAML) and `launchpad status` (drift report). Use when someone says "is my app in sync", "what's deployed", "show drift", "/launchpad-status", "/launchpad-pull", or after `launchpad deploy` to verify the change landed.
-version: 0.32.1
+version: 0.32.2
 ---
 
 <!-- BEGIN shell-contract (managed by scripts/sync-skill-contract.sh — edit skills/_partials/shell-contract.md) -->
@@ -132,7 +132,7 @@ union of states, not just a drift verdict. The drift pair:
   one field in the v1 closed set:
   `metadata.name`, `metadata.team`, `metadata.owner`,
   `metadata.description`, `deployment.type`,
-  `access.allowed_entra_group`, `hostnames[0]`, `build.command`,
+  `access.allowed_entra_groups`, `hostnames[0]`, `build.command`,
   `build.destination_dir`, `build.root_dir`, `production_env.*`.
 
 The lifecycle states (rendered without needing a local manifest):
@@ -328,7 +328,7 @@ edge-auth + cert re-issuance — the gateway hostname/cert for an
 `auth: gateway` app, or the Cf Access app for an `auth: access` one —
 which the bot handles.)
 
-### "drift: access.allowed_entra_group"
+### "drift: access.allowed_entra_groups"
 
 Group binding changed in your local manifest. This is the
 **load-bearing** drift — it controls who can access the app. After