@m-kopa/launchpad-cli 0.31.0 → 0.32.1

package/CHANGELOG.md

@@ -6,6 +6,34 @@ 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.1 — 2026-06-17
+
+Fix: `launchpad skills install/update` now installs `launchpad-identity`. The
+0.32.0 skill shipped as a `skills/` directory but was missing from the
+installer's `BUNDLED_SKILLS` list, so it was never copied into
+`~/.claude/skills/`. Added it, and added an anti-drift test that fails if any
+`launchpad-*` skill directory is missing from `BUNDLED_SKILLS` (so this can't
+recur). Re-run `launchpad update` (or `launchpad skills update`) to pick it up.
+
+## 0.32.0 — 2026-06-17
+
+New Claude Code skill: `/launchpad-identity` (sp-idnt7k). Teaches app authors how
+to read the signed-in user's identity inside a Launchpad app — verify the
+gateway-forwarded `X-Launchpad-User-Assertion` in a Pages Function with
+`@m-kopa/platform-auth` (RS256 signature + issuer + audience pinned to the app's
+own host), **fail closed**, and read `{ sub, email, name }`. The first
+how-to-build (dev) skill, distinct from the CLI-verb operator skills.
+
+- Covers both app shapes: build-less `type: static` (vendored verifier, documented
+  as interim with a staleness warning + a pointer to the maintained-build
+  follow-up) and `react+api` (`import @m-kopa/platform-auth`).
+- Teaches the `secret_text` env requirement (`GATEWAY_ISSUER` / `GATEWAY_AUD` /
+  `GATEWAY_JWKS_URL`) and the plain-text → deploy-wipe → fail-closed-anonymous
+  failure mode; warns against unsigned `decodeJwtPayload` token-reading.
+- Examples are extracted from the deployed, verified peoplemgr app and pinned by a
+  drift-guard test so they cannot silently diverge from the live contract.
+- Docs: extends the Auth & identity concept page; no new CLI command.
+
 ## 0.31.0 — 2026-06-17
 
 Telemetry: repoint at a fresh PostHog project (sp-phcli2). The prior project was

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.31.0";
+var CLI_VERSION = "0.32.1";
 
 // src/config.ts
 import * as os from "node:os";
@@ -10260,6 +10260,7 @@ var BUNDLED_SKILLS = [
   "launchpad-content-pr",
   "launchpad-status",
   "launchpad-destroy",
+  "launchpad-identity",
   "marquee-share"
 ];
 function isBundleManaged(name) {

package/dist/commands/skills.d.ts

@@ -1,4 +1,11 @@
 import type { Command } from "../dispatcher.js";
+/**
+ * Skills shipped in this version of the CLI. Must match the `launchpad-*`
+ * dirs under `<pkg>/skills/` (plus the cross-repo `marquee-share`); the
+ * "bundled list matches the skills dir" test in `tests/skills-command.test.ts`
+ * enforces this so a newly-added skill dir can't silently go un-installed.
+ */
+export declare const BUNDLED_SKILLS: readonly ["launchpad-onboard", "launchpad-deploy", "launchpad-deploy-status", "launchpad-content-pr", "launchpad-status", "launchpad-destroy", "launchpad-identity", "marquee-share"];
 export declare const skillsCommand: Command;
 interface InstallEnv {
     readonly bundleDir: string;

package/dist/commands/skills.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"skills.d.ts","sourceRoot":"","sources":["../../src/commands/skills.ts"],"names":[],"mappings":"AAiCA,OAAO,KAAK,EAAS,OAAO,EAAY,MAAM,kBAAkB,CAAC;AAoCjE,eAAO,MAAM,aAAa,EAAE,OAK3B,CAAC;AA2CF,UAAU,UAAU;IAClB,QAAQ,CAAC,SAAS,EAAE,MAAM,CAAC;IAC3B,QAAQ,CAAC,aAAa,EAAE,MAAM,CAAC;CAChC;AAED;;;GAGG;AACH,wBAAgB,iBAAiB,IAAI,UAAU,CAQ9C"}
+{"version":3,"file":"skills.d.ts","sourceRoot":"","sources":["../../src/commands/skills.ts"],"names":[],"mappings":"AAiCA,OAAO,KAAK,EAAS,OAAO,EAAY,MAAM,kBAAkB,CAAC;AASjE;;;;;GAKG;AACH,eAAO,MAAM,cAAc,uLAajB,CAAC;AAcX,eAAO,MAAM,aAAa,EAAE,OAK3B,CAAC;AA2CF,UAAU,UAAU;IAClB,QAAQ,CAAC,SAAS,EAAE,MAAM,CAAC;IAC3B,QAAQ,CAAC,aAAa,EAAE,MAAM,CAAC;CAChC;AAED;;;GAGG;AACH,wBAAgB,iBAAiB,IAAI,UAAU,CAQ9C"}

package/dist/version.d.ts

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@m-kopa/launchpad-cli",
-  "version": "0.31.0",
+  "version": "0.32.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/README.md

@@ -15,11 +15,38 @@ skills/
 ├── launchpad-content-pr/SKILL.md
 ├── launchpad-status/SKILL.md
 ├── launchpad-destroy/SKILL.md
+├── launchpad-identity/SKILL.md   # dev / how-to-build skill (see below)
 └── marquee-share/                # vendored from M-KOPA/marquee, do
                                   #  not hand-edit — managed by
                                   #  scripts/sync-marquee-share-skill.sh
 ```
 
+## Two kinds of skill: operator vs dev (how-to-build)
+
+Most skills here are **operator skills** — they wrap a `launchpad` CLI verb
+and walk the user through running it (`launchpad-deploy`, `-status`,
+`-content-pr`, `-destroy`, `-onboard`). Their bash blocks invoke the CLI, so
+they live under the Shell Contract.
+
+`launchpad-identity` is the first **dev / how-to-build skill**: it teaches an
+app author how to write *application code* (here: verifying the
+gateway-forwarded identity in a Pages Function), not how to run a CLI verb. The
+convention for this kind:
+
+- It still ships through `launchpad skills install` and is registered in the
+  same gate enumerations (`tests/skill-contract.test.ts`,
+  `check-skill-bash-dialect.sh`, `check-skill-bash-parse.sh`,
+  `sync-skill-contract.sh`) so `version:` lock-step + the Shell Contract apply.
+- Its code examples are **extracted from a deployed, verified app** (not
+  transcribed) and pinned by a drift-guard test
+  (`tests/skill-identity-extraction.test.ts`), because a how-to-build skill
+  that teaches a security path must not drift from the live contract.
+- It stays a **thin pointer to one source of truth** (the contract doc +
+  `@m-kopa/platform-auth` + the verified example), so it can't fork into a
+  divergent copy.
+
+The next dev-skill should follow this shape.
+
 ## Cross-platform shell contract
 
 Claude Code's `Bash` tool **always** runs `bash`, on every OS — on

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

package/skills/launchpad-identity/SKILL.md

@@ -0,0 +1,307 @@
+---
+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
+---
+
+<!-- BEGIN shell-contract (managed by scripts/sync-skill-contract.sh — edit skills/_partials/shell-contract.md) -->
+## Shell contract — read this first
+
+Every fenced `bash` block below MUST be sent to the `Bash` tool **verbatim**.
+Do not rewrite into PowerShell, cmd, zsh-isms, or "equivalent" forms.
+
+- macOS / Linux: the `Bash` tool runs system bash.
+- Windows: the `Bash` tool runs Git for Windows (MSYS) bash. `$HOME`,
+  forward slashes, `test -f`, `command -v`, heredocs, and `[[ … ]]` all
+  work. There is no reason to translate to `Test-Path`, `$env:USERPROFILE`,
+  `Get-Content`, `Where-Object`, `Get-ChildItem`, or backslash paths —
+  doing so will fail with `/usr/bin/bash: syntax error`.
+
+If a step genuinely needs OS branching, branch *inside* bash:
+
+```bash
+case "$(uname -s)" in
+  Darwin)               : ;;
+  Linux)                : ;;
+  MINGW*|MSYS*|CYGWIN*) : ;;
+esac
+```
+<!-- END shell-contract -->
+
+# /launchpad-identity
+
+How an app author reads **who is signed in** inside a Launchpad app, the
+right way: verify the gateway-forwarded identity token and fail closed.
+
+This is a **how-to-build** skill — it writes app code, it does not wrap a
+`launchpad` CLI verb. (`launchpad whoami` reports your *CLI session*, not the
+end-user signed into your deployed app — different thing; see § Don'ts.)
+
+## What you get, in one sentence
+
+A Launchpad app behind the Entra-OIDC gateway receives the signed-in user's
+**already-verified** identity as a signed token on every request; your app
+verifies that token and reads `{ sub, email, name }`. That is the whole job.
+
+## Prerequisite — you need a Pages Function (not bare static HTML)
+
+**Bare static HTML cannot read request headers**, so it cannot see the
+identity token. To read identity your app needs a server-side **Pages
+Function** (a file under `functions/`). Two app shapes qualify:
+
+- **`type: static` with a `functions/` directory** — a build-less static app
+  that still ships Pages Functions (this is what peoplemgr does).
+- **`react+api`** (or any app with a build) — your `/api/*` is already a
+  Pages Function.
+
+If your app is pure HTML/CSS/JS with no `functions/`, you must add a Pages
+Function first. There is no client-only way to read the verified identity.
+
+## The contract (read this before copying code)
+
+The platform gateway authenticates the user against Entra, then forwards its
+**own RS256-signed user token** to your origin under a dedicated header:
+
+```
+X-Launchpad-User-Assertion: <RS256 JWT minted by the gateway>
+```
+
+The canonical contract — claims, trust model, the header name — lives in ONE
+place: **`docs/identity-forwarding-to-confined-origins.md`** (sp-xush3d) in
+the launchpad-platform repo. This skill is the worked example; that doc is
+the source of truth. If they ever disagree, the contract doc wins.
+
+> **Trust by SIGNATURE, not by network position.** Do **not** trust the
+> header just because it arrived. Cloudflare's origin-confinement locks the
+> origin, but it is *punctured* by the unauthenticated `/.well-known/*` path
+> and any future non-gateway route. The only thing that makes the token
+> trustworthy is that **you verified its RS256 signature** against the
+> gateway JWKS. A forged header on a bypass path fails verification — and you
+> reject it. That is why a signed token exists instead of a plain header.
+
+### The two things you MUST get right
+
+1. **Verify, never decode-and-trust.** Use `@m-kopa/platform-auth`'s
+   `verifyAccessJwt` (it checks the RS256 signature, issuer, and audience).
+   **Never** read claims out of the token with an unsigned
+   `decodeJwtPayload` / base64-split — an unverified payload is attacker-controlled.
+2. **Pin the audience to YOUR app's host.** Verification must require
+   `audience = <your app's hostname>`. If you omit the audience check or share
+   one audience across apps, a token minted for app A is **replayable** against
+   app B (cross-app token replay). Audience-pinning is what stops that.
+
+## The canonical Pages Function — `functions/api/me.js`
+
+Lifted from the **deployed-and-verified** peoplemgr app
+(`repos/m-kopa-peoplemgr-hub/functions/api/me.js`). Copy it; change only the
+app-specific bits called out below.
+
+```js
+import { verifyAccessJwt, createJwksCache } from '../_lib/platform-auth.mjs';
+
+const IDENTITY_HEADER = 'X-Launchpad-User-Assertion';
+
+// Memoise the JWKS cache per isolate (env is only available per-request),
+// keyed by URL so a config change rebuilds it.
+let _jwks = null;
+let _jwksUrl = null;
+function jwksFor(url) {
+  if (!_jwks || _jwksUrl !== url) {
+    _jwks = createJwksCache(url);
+    _jwksUrl = url;
+  }
+  return _jwks;
+}
+
+function json(body) {
+  return new Response(JSON.stringify(body), {
+    headers: { 'content-type': 'application/json', 'cache-control': 'no-store' },
+  });
+}
+
+// Fail-closed anonymous result. The shape your client gates on.
+function anonymous() {
+  return json({ authenticated: false, email: null, name: null, sub: null });
+}
+
+export async function onRequestGet(context) {
+  const { request, env } = context;
+
+  const token = request.headers.get(IDENTITY_HEADER);
+  if (!token) return anonymous(); // no token → anonymous / public path
+
+  const issuer = env.GATEWAY_ISSUER; // gateway iss
+  const audience = env.GATEWAY_AUD; // this app's aud (pin to YOUR host)
+  const jwksUrl =
+    env.GATEWAY_JWKS_URL ||
+    (issuer ? `${issuer.replace(/\/$/, '')}/.well-known/jwks.json` : null);
+
+  // Misconfigured verify env → fail CLOSED. Never trust an unverifiable token.
+  if (!jwksUrl || !issuer || !audience) return anonymous();
+
+  try {
+    const user = await verifyAccessJwt(token, {
+      teamDomain: issuer, // iss
+      audience, // aud (this app) — the replay guard
+      jwks: jwksFor(jwksUrl),
+    });
+    return json({
+      authenticated: true,
+      sub: user.sub,
+      email: user.preferredUsername, // tenant-bound UPN (the verified identity)
+      name: user.name || null, // display name (absent → null; never gates)
+    });
+  } catch {
+    // Forged / expired / wrong-signature / wrong-aud / JWKS failure → anonymous,
+    // NEVER the (possibly forged) user. This is the load-bearing fail-closed.
+    return anonymous();
+  }
+}
+```
+
+What the verified `user` carries (from the contract doc):
+
+| Field returned | From | Notes |
+|---|---|---|
+| `sub` | `user.sub` | Entra `oid` — stable identifier. |
+| `email` | `user.preferredUsername` | Tenant-bound UPN — the stable email-equivalent. |
+| `name` | `user.name` | Display-only (Entra `profile` scope). Fail-soft: `null` if absent — never gate on it. |
+
+> **No groups, no authz here.** This mechanism forwards `sub`/`email`/`name`
+> only — it is read-only identity for **attribution** (analytics, audit,
+> personalisation), **not** an authorization input. Group membership is the
+> gateway's **login-time snapshot**; never make an access decision from these
+> values. Enforce authorization at the gateway (allowed groups) and
+> server-side, not from `/api/me`.
+
+## Reading it from the client
+
+Your front-end calls `/api/me` and personalises on the result. Keep the same
+fail-closed posture: treat `authenticated: false` as anonymous.
+
+```js
+const me = await fetch('/api/me').then((r) => r.json());
+if (me.authenticated) {
+  // show who's logged in
+  document.querySelector('#who').textContent = `${me.name ?? me.email}`;
+  // e.g. analytics identify — attribution only, never authorization
+  // posthog.identify(me.sub, { email: me.email, name: me.name });
+} else {
+  // anonymous / public view
+}
+```
+
+## The two app shapes
+
+### (a) build-less `type: static` — vendored verifier (INTERIM)
+
+A build-less static app has **no `package.json` and no install step at
+deploy**, so its Pages Functions cannot `import` an npm package by name. The
+verifier is **pre-bundled** into a committed file and imported by relative
+path — that is the `import … from '../_lib/platform-auth.mjs'` in the example
+above. To produce that file, esbuild `@m-kopa/platform-auth` into a single
+ESM bundle; the recipe lives in
+`repos/m-kopa-peoplemgr-hub/functions/_lib/README.md`.
+
+> ⚠️ **Vendoring is INTERIM — a pinned copy goes stale.** A hand-vendored
+> `platform-auth.mjs` is frozen at the version you bundled. **A security fix
+> to the verifier does NOT reach it** until someone re-bundles and redeploys.
+> Pin the version in a `_lib/README.md`, watch `@m-kopa/platform-auth`
+> releases, and re-vendor on a security advisory. The maintained replacement
+> for this whole pattern is tracked as **sp-pubvf3** (publish a maintained
+> static/Pages verifier build so a fix propagates via a version bump). Prefer
+> it once it lands; until then, vendoring is the documented reality — with
+> this staleness caveat attached.
+
+### (b) `react+api` / any app with a build — import the package
+
+If your app has a build step, drop the vendored file and import the package
+directly:
+
+```js
+import { verifyAccessJwt, createJwksCache } from '@m-kopa/platform-auth';
+```
+
+Everything else — the header, the verify call, the fail-closed shape, the env
+vars — is identical to the example above.
+
+## Required env vars — `secret_text`, MANDATORY
+
+Verification needs three env vars on your app. **Set them as `secret_text`,
+not plain text:**
+
+| Var | Value | Notes |
+|---|---|---|
+| `GATEWAY_ISSUER` | `https://auth.launchpad.m-kopa.us` | the gateway token issuer (`iss`) |
+| `GATEWAY_AUD` | `<your-slug>.launchpad.m-kopa.us` | **your app's** audience (`aud`) — the replay guard |
+| `GATEWAY_JWKS_URL` | `https://auth.launchpad.m-kopa.us/.well-known/jwks.json` | optional — derived from `GATEWAY_ISSUER` if unset |
+
+> ⚠️ **Why `secret_text` is mandatory — the wipe → fail-closed chain.** If you
+> set these as **plain-text** env, the next `launchpad deploy` **wipes them**
+> (only `secret_text` vars survive a deploy — the CF-Access-env-vars-must-ship
+> runbook). With the env gone, `issuer`/`audience` are `undefined`, the
+> `if (!jwksUrl || !issuer || !audience) return anonymous()` guard fires, and
+> **every** user silently goes anonymous in production. The code is correct —
+> it fails *closed*, never open — but identity is dark until you re-add the
+> vars. Set them `secret_text` from the start and this never happens. Ship the
+> env in the **same** deploy as the consumer, or verification is dark.
+
+The canonical names are **`GATEWAY_ISSUER` / `GATEWAY_AUD` / `GATEWAY_JWKS_URL`**
+— what the deployed app reads and what is live on Cloudflare. (You may see the
+illustrative names `AUTH_ISS` / `APP_AUD` / `JWKS_URL` in older contract-doc
+snippets — the deployed convention is the `GATEWAY_*` set; use it. Note: it is
+`GATEWAY_AUD`, **not** `GATEWAY_AUDIENCE`.)
+
+## Anti-pattern — do NOT do this
+
+Some apps "read" the token by base64-decoding its payload without verifying
+the signature:
+
+```js
+// ❌ WRONG — unsigned, attacker-controlled. Never do this.
+// const payload = decodeJwtPayload(token);   // no signature check!
+// const email = payload.email;               // trusting a forgeable claim
+```
+
+An unverified payload can be forged by anyone who can reach your origin
+(including via the `/.well-known/*` bypass). **Always** `verifyAccessJwt`
+(signature + issuer + audience) and **fail closed** on any error. If you find
+`decodeJwtPayload` on an auth path, it is a bug — replace it with verification.
+
+## Checklist before you ship
+
+- [ ] App has a **Pages Function** (not bare static HTML).
+- [ ] Reads `X-Launchpad-User-Assertion` and **verifies** with
+      `verifyAccessJwt` (signature + issuer + **audience pinned to your host**).
+- [ ] **Fails closed** to anonymous on missing token, missing env, or any
+      verify error — never returns the unverified user.
+- [ ] No unsigned `decodeJwtPayload` on the auth path.
+- [ ] `GATEWAY_ISSUER` / `GATEWAY_AUD` / `GATEWAY_JWKS_URL` set as
+      **`secret_text`**, shipped in the **same** deploy.
+- [ ] No authorization decision is made from `/api/me` — attribution only.
+
+## Don'ts
+
+- Do **not** confuse `launchpad whoami` (your CLI session) with in-app
+  identity. This skill is about the **end-user signed into your deployed
+  app**, read server-side from the forwarded token.
+- Do **not** trust the header without verifying the signature, and do **not**
+  omit the audience check — both open you to forgery / cross-app replay.
+- Do **not** gate access on `/api/me` claims — they are attribution, not
+  authorization. Authorization is the gateway's allowed-groups + your
+  server-side checks.
+- Do **not** invent new claim names — `sub` / `email` (`preferredUsername`) /
+  `name` are the only fields this channel carries. Directory attributes
+  (jobTitle, department, …) are a separate, forthcoming channel (sp-dirat9) —
+  not available here yet.
+
+## Related
+
+- **`docs/identity-forwarding-to-confined-origins.md`** — the canonical
+  contract (claims, trust model, header). Source of truth.
+- [Concepts → Auth & groups](https://get.launchpad.m-kopa.us/concepts/auth-groups)
+  — the gateway, the first-visit bounce, and `/api/me`.
+- `repos/m-kopa-peoplemgr-hub/functions/api/me.js` — the deployed worked
+  example this skill is lifted from.
+- **sp-pubvf3** — the maintained static verifier build that will retire
+  hand-vendoring.

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