@m-kopa/launchpad-cli 0.23.0

package/CHANGELOG.md

@@ -0,0 +1,854 @@
+# Changelog
+
+All notable changes to `@m-kopa/launchpad-cli` are documented here.
+
+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.23.0 — 2026-06-11
+
+### Changed
+
+- **`--allowed-group` accepts an Entra Object-ID UUID** (sp-grpid1 / ADR 0024),
+  not just a symbolic key (`G_Product_Security`), on both `launchpad create` and
+  `launchpad deploy --new`. The bot resolves and validates either form against the
+  app-assigned group set at submit (and rejects a typo'd / unassigned group with a
+  clear error before provisioning).
+
+## 0.22.0 — 2026-06-11
+
+### Changed
+
+- **`launchpad status` shows provisioning progress** (sp-st5hw9). Status now
+  queries the app's lifecycle first, so a mid-provision app reads as
+  `provisioning (stage: …)` and a hard failure as `provisioning FAILED at stage
+  …: <reason>` — instead of both showing the misleading "no deployed manifest
+  yet". A live app still diffs local-vs-deployed (`live, in sync` / drift), and a
+  live app with no content deployed reads as `live, no content yet`.
+  Provisioning/failed render without a local `launchpad.yaml` (no more ENOENT
+  mid-provision). `--json` carries a discriminated `state`. Degrades gracefully
+  against an older bot.
+- **`launchpad secrets status` accepts a `[<slug>]` positional** (AC0), matching
+  `launchpad status` — instead of erroring "unknown argument". A slug that
+  doesn't match the directory's manifest is a clear error.
+
+## 0.21.0 — 2026-06-10
+
+### Added
+
+- **React+api (pages) apps can declare a D1 database** (sp-pgd1b7 / ADR 0022
+  amendment). `d1_binding` is now valid on a `pages` target in `launchpad.yaml`,
+  not just a `worker` target — so a pure react+api app (no cron Worker) can
+  declare its database and `launchpad deploy` create-or-adopts the shared
+  `<slug>` D1 and binds it to the Pages app (`env.<BINDING>`), with no manual
+  `wrangler d1 create`. `schedule` remains worker-only (cron is Workers-only).
+  The provisioned DB is empty — schema init stays the app's responsibility.
+  (Requires this CLI version: the manifest is validated client-side against the
+  bundled engine schema, so an older CLI rejects a pages `d1_binding` locally.)
+
+## 0.20.0 — 2026-06-10
+
+### Changed
+
+- **`launchpad update` self-updates through the auth gateway** (sp-gwpub1 /
+  ADR 0023). The platform CLI distribution channel
+  (`get.launchpad.m-kopa.us`) is moving from Cloudflare Access to the
+  platform Entra-OIDC gateway, so the previous `cloudflared access curl`
+  self-update path no longer applies. `launchpad update` now signs in with a
+  **loopback browser flow** (Authorization-Code + PKCE): it binds a localhost
+  listener, opens your browser to sign in once, exchanges a short-lived
+  installer token, fetches the still-staff-gated `install.sh`, and runs it
+  (shebang- + SHA-256-verified). On a headless/SSH host with no browser it
+  prints the browser-installer instruction instead of erroring.
+  `launchpad update --check` is unchanged (anonymous `version.json`).
+  Targeted failure guidance: no browser → "update in a browser at
+  get.launchpad.m-kopa.us"; sign-in didn't complete → retry or browser.
+
+  > **Cutover note:** the loopback flow activates once
+  > `get.launchpad.m-kopa.us` is served by the gateway. Until that cutover
+  > completes, `launchpad update` on this version falls back to the
+  > browser-installer message; `--check` and fresh installs are unaffected.
+
+## 0.18.0 — 2026-05-31
+
+### Changed
+
+- **`launchpad update` now self-updates on the platform channel** — no
+  hand-downloading shell scripts. The platform installer lives behind
+  Cloudflare Access, so a public package manager can't reach it; instead
+  the command runs the Access-gated `install.sh` through the user's
+  `cloudflared` session (`cloudflared access curl … | bash`), which is
+  self-contained + SHA-256 self-verifying. Targeted guidance on failure:
+  `no-cloudflared` → `brew install cloudflared`; no Access session →
+  `cloudflared access login https://get.launchpad.m-kopa.us`; installer
+  error → manual-install fallback. The GitHub-Packages channel is
+  unchanged (`npm i -g`). (One-time bootstrap: an install older than
+  0.18.0 still shows the old "re-run the installer" message — update once
+  to 0.18.0+ and `launchpad update` is self-driving thereafter.)
+
+## 0.17.0 — 2026-05-31
+
+### Added
+
+- **Passive update notifier.** After any command, the CLI prints a
+  one-line notice to **stderr** when a newer version is published —
+  e.g. `▲ launchpad 0.17.0 → 0.18.0 available — …`. It reads a cached
+  marker (`~/.launchpad/update-check.json`) synchronously on the hot
+  path and refreshes it in a **detached background process** at most
+  once per 24h, so it never slows, blocks, or breaks a command. The
+  notice is channel-aware (GitHub Packages → `launchpad update`;
+  platform channel → the `get.launchpad.m-kopa.us` installer) and is
+  suppressed on non-interactive stderr, in CI, under
+  `LAUNCHPAD_NO_UPDATE_NOTIFIER`, with `--json`, and for the `update`
+  command itself. Output goes only to stderr, so scripts and piped /
+  `--json` consumers are unaffected.
+
+## 0.15.0 — 2026-05-26
+
+### Added
+
+- **Model A deploy flow (M-1216).** `launchpad init` scaffolds a
+  `launchpad.yaml` from the current working directory, auto-detecting
+  app shape: Vite presence, package manager (npm / bun / pnpm / yarn),
+  the build command, the destination directory, and `react+api`
+  via a top-level `functions/` directory. Interactive prompts collect
+  slug / display name / team / owner / allowed group; non-interactive
+  flags (`--slug`, `--display-name`, `--app-type`, `--team`,
+  `--owner`, `--group`, `--force`, `--non-interactive`) cover CI use.
+  `launchpad deploy` from CWD bundles the working tree via a pure-JS
+  walker (honours `.gitignore` + a default-ignore list), gzip-streams
+  the tarball, and POSTs to the bot's new
+  `POST /apps/<slug>/deploy/bundle` endpoint.
+- **Server-side bundle policy (M-1216 / bot).** AC8 ingest gate rejects
+  symlinks, traversal paths, special files, oversized files (5 MB),
+  excessive file counts (5000), and aggregate decompressed size over
+  100 MB. AC9 high-signal secret scan flags AWS access keys, GitHub
+  PAT / fine-grained / OAuth / App tokens, Slack tokens, SSH / RSA /
+  EC / PGP private keys, and generic `api_key` patterns at upload
+  time. AC10 build-command allowlist enforces the approved
+  install / build verbs (`npm ci`, `bun install --frozen-lockfile`,
+  `pnpm install --frozen-lockfile`, `yarn install --immutable`,
+  followed by the package's own `build` script), bans standalone `&`
+  background operators, and rejects env-prefix tricks.
+- **In-Worker tar.gz extraction (M-1216 / bot).** Pure-JS USTAR parser
+  + `DecompressionStream("gzip")` extracts the bundle inside the
+  Workers runtime — no `tar` binary, no native deps.
+- **`deployment_verified` lifecycle gate (M-1217).** The bot polls
+  the Cloudflare Pages REST API after a deploy PR merges and only
+  flips the lifecycle to `done` once the production deployment
+  reports `success`. Failures and `canceled` deployments terminate
+  with a clear `cf-pages-poll-unrecoverable` audit event;
+  retryable failures (no-deployments, status 0, status >= 500) walk
+  the bounded poll budget (45 polls × 20 seconds = 15 min) before
+  surfacing as an explicit timeout. Closes the "lying-live" gap
+  where a deploy PR merged but the Pages build failed silently.
+- **Zero-deps CI matrix (M-1216 / T6).** The `launchpad-cli-e2e`
+  workflow's `zero-deps-matrix` job runs every CLI smoke test under
+  a `PATH` that excludes `git`, `gh`, `jq` — guarantees the AC5
+  no-system-dependencies contract is testable, not aspirational. A
+  workflow-dispatch-only E2E job exercises the full
+  `init → deploy → 200 OK → destroy` flow against a committed
+  Vite/React fixture (gated on Cf-Access service-token infra).
+
+### Changed
+
+- **Claude Code skill bundle rewritten to use CLI verbs only
+  (M-1221).** The four legacy launchpad-* skill playbooks
+  (`launchpad-onboard`, `launchpad-deploy`,
+  `launchpad-deploy-status`, `launchpad-content-pr`) no longer shell
+  out to `gh`, `jq`, `curl`, or `git`. Every step routes through a
+  `launchpad` verb: session health via `launchpad whoami`, group
+  resolution via `launchpad groups list/search/show`, status via
+  `launchpad status <slug>` and `launchpad apps`, lifecycle drift
+  via `launchpad status <slug> --json`. External users with no
+  M-KOPA GitHub access are now first-class through every playbook.
+  The M-892 zero-touch modes (`--new` / `--resume` / `--abandon`)
+  remain available as a legacy appendix in `/launchpad-deploy` for
+  M-KOPA-internal apps stuck in the pre-Model-A flow.
+
+## 0.14.1 — 2026-05-26
+
+### Fixed
+
+- **Critical: `install.sh` failed with `EUNSUPPORTEDPROTOCOL` for fresh
+  installs since 0.13.0.** The CLI's published tarball declared
+  `"@m-kopa/launchpad-engine": "workspace:*"` because `npm pack`
+  doesn't substitute workspace protocol references the way
+  `bun publish` does. Consumers running `npm install -g <tarball>`
+  via the get.launchpad.m-kopa.us channel choked on the
+  `workspace:*` token. Users who already had an earlier CLI
+  installed didn't notice because `launchpad update` works from the
+  existing install layout, not via a fresh `npm install`.
+- Engine renamed to `@krsecurity/launchpad-engine` and published to
+  public npm; the CLI now declares a concrete dep
+  (`"@krsecurity/launchpad-engine": "0.3.0"`) so consumer-side
+  resolution works without GitHub Packages auth or workspace
+  context. The package is on `@krsecurity` for the same temporary
+  reason as `@krsecurity/platform-auth` — moves to `@m-kopa` once
+  the org claim lands on npmjs.com.
+
+## 0.14.0 — 2026-05-26
+
+### Added
+
+- **`launchpad destroy [<slug>] [--confirm-slug <slug>] [--yes] [--json]`**
+  — tear down a Launchpad app end-to-end: Cloudflare Pages project,
+  Access app, custom hostname, platform-repo TF entries, and the app
+  repo (archive-renamed, not deleted). Owner-only verb; editor role
+  is rejected with `"you must be an owner — editor role is not
+  sufficient"`. Two-step destructive confirmation matrix per AC4:
+  TTY mode prompts for slug re-type + Y/N (flags short-circuit);
+  non-TTY (CI) mode requires BOTH `--confirm-slug` AND `--yes`,
+  exits 64 (`EX_USAGE`) otherwise. Idempotent re-run on a `destroyed`
+  slug exits 0 with `"already destroyed at <timestamp>"`. Distinct
+  error messages per bot code: `carve_out` (legacy main.tf-resident
+  apps fail closed with a platform-team teardown message),
+  `no_per_app_tf`, `destroy_failed` (suggests retry or platform-team
+  intervention). Thin HTTP client to `POST /apps/<slug>/destroy`;
+  no local Cloudflare, GitHub, or platform-repo credentials needed.
+- **`launchpad-destroy` skill** — Claude Code slash command (and
+  fallback documentation) for the destroy verb. Documents the
+  confirmation matrix, owner-only authz, lifecycle states
+  (`destroying` / `destroyed` / `destroy_failed`), main.tf carve-outs,
+  open-PR handling on the app repo (bot PRs closed; human PRs
+  receive a heads-up comment), and the manual archive-recovery path
+  via `gh repo rename` + `gh repo unarchive`. Bundled by
+  `launchpad skills install`.
+
+### Fixed
+
+- `scripts/sync-skill-contract.sh` now includes `launchpad-status` in
+  its skills array. The launchpad-status SKILL.md was stuck at
+  version 0.13.0 because it was omitted from the sync loop; running
+  `bun run sync:skill-contract` now bumps it alongside the others.
+
+## 0.13.0 — 2026-05-25
+
+### Added
+
+- **`launchpad pull <slug>`** — fetch the deployed `launchpad.yaml`
+  for an app. Thin HTTP client to the bot's
+  `/apps/<slug>/manifest/state?include=manifest` endpoint. No local
+  platform-repo clone, no terraform, no GitHub credentials. Slug
+  from positional arg, `--slug` flag, or cwd inference inside
+  `launchpad-app-<slug>/`. `--out <path>` redirects to a file.
+- **`launchpad status [--slug] [--file] [--json] [--strict]`** —
+  compare local `launchpad.yaml` against the deployed manifest and
+  report drift over a closed v1 field set (metadata, deployment.type,
+  access.allowed_entra_group, hostnames[0], build.*, production_env.*).
+  Three-state surfacing: also reports whether the app-repo's main
+  HEAD is ahead of the deployed sha — surfaces "an apply may be
+  queued (see PR #N)" or "main is ahead of deployed" — the operator
+  equivalent of `git status` knowing about `git fetch`. Equivalence
+  relation is normalised-AST: whitespace, comments, and key ordering
+  are NOT drift. Defence-in-depth: warns on stderr when any
+  `production_env.*` value matches a secret-shape heuristic (known
+  prefix AND length ≥ 32 in a base64-shaped character set).
+- **`/launchpad-status` skill** in the Claude Code skills bundle.
+  Walks operators through pull vs status, the three states, the
+  HEAD-vs-deployed annotation, and `--strict` for CI guards.
+  Cross-linked from `/launchpad-content-pr`'s "ongoing deploys"
+  section.
+
+### Changed
+
+- Bot's `GET /apps/<slug>/manifest/state` response now carries
+  `appRepoHeadSha` (additive field; older clients ignore unknown
+  fields). Powers the new three-state surfacing in status without
+  a second round-trip.
+
+### Notes
+
+- Per-app authz on the state endpoint is owner/editor-scoped (the
+  existing `authzRole` gate at the router level already enforced
+  this before M-1188 — confirmed in T1's investigation). Non-owners
+  get 403; clients distinguish 401 / 403 / 404 with actionable
+  messages.
+- Exit codes on `launchpad status`: `0` = in sync OR drift in
+  default report-only mode. `1` = drift, but ONLY when `--strict`
+  is passed. `2` = error. Default is intentionally report-only so
+  interactive use never surprises; CI guards opt in via
+  `launchpad status --strict && launchpad deploy`.
+
+Closes M-1188.
+
+## 0.12.0 — 2026-05-21
+
+### Added
+
+- `container` is now an accepted value for `--app-type` on
+  `launchpad create` and `launchpad deploy --new`. Mirrors the
+  closed taxonomy in `portal-bot/src/review/gate.ts` after M-1071
+  chunk F (`#139`) added `container` as the fourth app-type for
+  container-shape apps on Cloudflare Containers (ADR 0015). The
+  CLI's `APP_TYPES` array — single-sourced into the `--app-type`
+  validator AND the usage-banner rendering on both `create` and
+  `deploy --new` — was the last hand-maintained mirror still
+  carrying the three-type list; this bump closes the chunk F
+  bot/CLI gap (chunk F-bis). The wire-format change is additive:
+  `static | react | react+api` submissions are unchanged, and the
+  bot's `POST /apps` already accepts `appType: "container"`. (M-1071)
+
+### Changed
+
+- The `--app-type` help line on both verbs is now rendered from
+  `APP_TYPES.join("|")` rather than a hand-edited literal, so a
+  future fifth app-type only needs one line in `create.ts` to
+  appear in every help banner the CLI emits.
+
+## 0.11.7 — 2026-05-19
+
+### Fixed
+
+- Skills no longer fail on Windows when the agent tries to translate
+  the fenced `bash` blocks into PowerShell. Claude Code's `Bash` tool
+  always invokes `bash` (Git for Windows / MSYS bash on Windows), so
+  PowerShell idioms like `Test-Path`, `$env:USERPROFILE`, `Get-Content`
+  produced `/usr/bin/bash: syntax error` instead of running. Each
+  launchpad-* SKILL.md now opens with an explicit **Shell contract**
+  preamble telling the agent not to transliterate, and the bash
+  inside the skills has been hardened so every block is unambiguously
+  bash (`$HOME` instead of `~`, quoted expansions, `${TMPDIR:-/tmp}`
+  instead of bare `/tmp`, etc.). The contract block is single-sourced
+  from `skills/_partials/shell-contract.md` and stamped into each
+  skill by `scripts/sync-skill-contract.sh`; CI rejects any drift.
+  (M-1070)
+
+### Changed
+
+- Skill `version:` frontmatter is now stamped from `package.json`
+  by `scripts/sync-skill-contract.sh`, not hand-bumped. Historically
+  the four `launchpad-*` skills tagged `version: 0.11.0` while the
+  CLI shipped at `0.11.6`, surfacing as a spurious "drift" warning
+  in `/launchpad-onboard`. The sync step and a new CI gate
+  (`bun run check:skills`) make that class of drift impossible to
+  ship. (M-1070)
+- `/launchpad-onboard` step 2 (`gh / jq / curl`) now branches on
+  `uname -s` *inside bash* (`Darwin`, `Linux` with apt/dnf probe,
+  `MINGW*|MSYS*|CYGWIN*` for Git Bash on Windows) instead of
+  printing per-OS prose. The agent can execute the right command
+  directly without having to interpret the prose.
+- `/launchpad-onboard` step 4 (session freshness) now computes age
+  in days using `jq`'s `fromdate` builtin, which is portable across
+  macOS BSD `date`, GNU `date`, and Git Bash on Windows. The previous
+  check only verified file existence.
+- `/launchpad-deploy` pre-flight now also verifies `gh auth status`
+  succeeds against `github.com`, not just that the `gh` binary is on
+  PATH. The resume/abandon branches need a working `gh`, and the
+  earlier check missed the most common failure mode (binary present,
+  not authenticated).
+- `/launchpad-deploy` work-directory is now `${TMPDIR:-/tmp}/launchpad-<slug>`
+  instead of a hard-coded `/tmp/launchpad-<slug>`. `$TMPDIR` is the
+  cross-platform canonical knob (macOS auto-sets it; Git Bash points
+  it at a Windows-side temp area).
+- `/launchpad-content-pr` clone target is now
+  `${LAUNCHPAD_WORKDIR:-$HOME/projects}` so users who don't keep code
+  under `~/projects` can override without forking the skill.
+- Every `curl` against the bot now extracts the token via
+  `jq -r '.accessToken // empty' "$HOME/.launchpad/session.json"` and
+  bails with a clear "run /launchpad-onboard" message on empty
+  output, instead of silently sending `Authorization: Bearer null`
+  and getting a confusing 401 back.
+
+### Added
+
+- `scripts/sync-skill-contract.sh` — re-stamps the Shell Contract
+  block + `version:` frontmatter into each `launchpad-*/SKILL.md`
+  from canonical sources (`skills/_partials/shell-contract.md` +
+  `package.json`). Idempotent. Run via `bun run sync:skill-contract`.
+- `scripts/check-skill-bash-dialect.sh` — fails the build if any
+  `launchpad-*/SKILL.md` contains a PowerShell token inside a fenced
+  `bash` block. Wired via `bun run check:skill-bash-dialect`.
+- `scripts/check-skill-bash-parse.sh` — runs `bash -n` against every
+  fenced `bash` block in each `launchpad-*/SKILL.md`, with
+  `<placeholder>` segments sanitised so the parser doesn't misread
+  them as here-strings. Catches stray syntax errors at PR time.
+  Wired via `bun run check:skill-bash-parse`.
+- `tests/skill-contract.test.ts` — twelve vitest cases asserting the
+  contract is present, byte-identical, and free of forbidden tokens
+  in each `launchpad-*` skill. Surfaces violations in
+  `vitest --watch` the moment a SKILL.md is saved, ahead of the
+  CI shell gate.
+- `launchpad-cli` CI gate composite action runs
+  `bun run check:skills` (the three skill guards in one step)
+  immediately after the existing `check:version-sync` step.
+
+## 0.11.6 — 2026-05-19
+
+### Changed
+
+- `launchpad skills install` now creates `~/.claude/skills/` (and any
+  missing parent — typically `~/.claude/`) when the target directory
+  does not yet exist, instead of aborting with an `mkdir -p` hint.
+  The platform-channel installer (`install.sh` / `install.ps1` step
+  7) invokes `skills install` on every fresh CLI install, and the
+  abort path produced confusing output on machines where Claude Code
+  had never been launched — the user saw "launchpad-cli installed"
+  immediately followed by "skills install failed: directory does not
+  exist", with no indication that the CLI itself was fine. The auto-
+  create is safe: the command was explicitly invoked, the directory
+  is named after a product the user is clearly setting up, and
+  `fs.mkdir({ recursive: true })` is idempotent. (M-1061)
+- Platform-channel `install.ps1` on Windows now adds the npm global
+  directory to the user's PATH automatically when it isn't already
+  there, instead of printing a warning and leaving the user to
+  manage it. Previously the installer printed
+  `'C:\Users\...\AppData\Roaming\npm\launchpad.cmd' was installed,
+  but 'launchpad' is not yet on your PATH` and stopped — completing
+  the install but leaving `launchpad --version` broken until the
+  user found the System Properties dialog and added the entry by
+  hand. The fix writes to user-scope `HKCU\Environment` via
+  `[Environment]::SetEnvironmentVariable('PATH', …, 'User')` (not
+  `setx`, which truncates user PATH to 1024 chars and silently
+  mangles long PATHs), updates the current process's `$env:PATH`
+  so an immediate follow-up command in the same shell works, and
+  detects the case where the entry is already in the user / machine
+  PATH but the current PowerShell session was spawned before the
+  registry write — in that case no second write happens, just a
+  clear "open a new PowerShell window" message. The PATH-shadow
+  branch (M-1058) is unchanged: when a different `launchpad` binary
+  is winning the PATH race, adding to PATH won't help — the user
+  has to remove the shadowing binary, and the existing warning
+  tells them how. (M-1062)
+
+## 0.11.5 — 2026-05-19
+
+### Fixed
+
+- Platform-channel `install.ps1` aborted on Windows during the very
+  first prerequisite check with `SyntaxError: Unexpected token '.'`
+  from a `node -p` invocation, followed by a spurious
+  `Node.js >= 20 required; found vX.Y.Z` (even on Node 24 — comfortably
+  above the floor). Root cause: the Node-major-detection line read
+  `& node -p 'process.versions.node.split(".")[0]'`. PowerShell on
+  Windows builds the Win32 command line for native executables via a
+  separate arg-quoting pass that mishandles embedded double quotes —
+  the inner `"."` were stripped, so node actually received
+  `process.versions.node.split(.)[0]`, which is invalid in both JS
+  and (on Node 22.6+) the new built-in TypeScript evaluator. The fix
+  reads `node --version` and parses the major in PowerShell, with
+  no native-command argument crossing the boundary — only pure
+  PowerShell single-quoted literals (`'v'`, `'.'`). This bug had
+  been latent in the script since the first release of the platform
+  channel (M-1042); the prior M-1059 PowerShell-parser bug masked it
+  on Windows until the script could actually be loaded. (M-1060)
+
+### Added
+
+- `packages/launchpad-cli/scripts/check-installer-syntax.sh` — runs
+  `bash -n` on `install.sh` and the PowerShell parser
+  (`[System.Management.Automation.Language.Parser]::ParseFile`) on
+  `install.ps1`. Prefers system `pwsh` (pre-installed on GitHub's
+  `ubuntu-latest`) and falls back to the official
+  `mcr.microsoft.com/powershell` Docker image so the check still runs
+  on macOS contributor laptops without PowerShell installed. Wired
+  into the `launchpad-cli-gate` composite action, so every PR and
+  pre-publish gate now parse-checks the installer templates before
+  the channel deploys them. This wouldn't have caught M-1059 (the
+  encoding bug is a Windows-PowerShell-5.1 runtime behaviour the
+  cross-platform pwsh parser does not reproduce) but it
+  unambiguously catches M-1060 and any future syntax regression.
+
+## 0.11.4 — 2026-05-19
+
+### Fixed
+
+- Platform-channel `install.ps1` failed to parse on Windows with a
+  cascading "TerminatorExpectedAtEndOfString / Missing closing }"
+  error far from any real syntax problem. Root cause: the file ships
+  as UTF-8 without a BOM, and Windows PowerShell 5.1 reads BOM-less
+  script files using the system ANSI codepage (CP1252 on most English
+  Windows installs), not UTF-8. The script contains UTF-8 multibyte
+  sequences for box-drawing characters (`─`, `U+2500` = `e2 94 80`)
+  in section dividers and em dashes (`—`, `U+2014` = `e2 80 94`) in
+  comments and `Write-Host` strings. Under CP1252, byte `\x94`
+  decodes to `U+201D` (RIGHT DOUBLE QUOTATION MARK), which
+  PowerShell's parser recognises as a string delimiter — every such
+  character injects a phantom quote, the running parity of double
+  quotes desynchronises across the whole file, and the failure
+  surfaces at the final `Write-Host "…"` even though the script is
+  structurally correct. The channel workflow now prepends a UTF-8
+  BOM to `install.ps1` only (the `.sh` installer is unaffected — bash
+  on macOS/Linux reads UTF-8 unconditionally), forcing PS 5.1 to
+  decode the file as UTF-8 regardless of host locale. Without this
+  fix, no Windows user can complete a platform-channel install — and
+  therefore no Windows user gets the `~/.launchpad/channel` marker
+  written, so every `launchpad update` falls through to the GitHub
+  Packages path and re-asks for a `read:packages` token, defeating
+  the whole point of ADR 0014. (M-1059)
+
+## 0.11.3 — 2026-05-19
+
+### Fixed
+
+- `launchpad update` on Windows. The earlier M-1056 fix resolved the
+  `npm` shim name to `npm.cmd` so libuv could find it, but
+  `CreateProcess` still cannot execute a `.cmd` script directly — every
+  Windows invocation failed with `spawn EINVAL` instead of the previous
+  `ENOENT`. The fix adds a `pmSpawnOptions` helper that returns
+  `{ shell: true }` on win32 and applies it at all three PM spawn sites
+  (`npm view` for the registry query, `<pm> root -g` for PM detection,
+  `<pm> install -g` for the upgrade). Non-Windows platforms are
+  unchanged. Every PM arg in `update.ts` is hardcoded, so no user input
+  reaches the shell.
+
+## 0.11.2 — 2026-05-19
+
+### Fixed
+
+- `launchpad login` on Windows. The M-1055 fix swapped the broken
+  `cmd /c start "" <url>` opener for `explorer.exe <url>`, but
+  `explorer.exe` interprets argv as a filesystem path, not a URL.
+  When `https://...` failed to resolve as a path, explorer silently
+  fell back to opening File Explorer at the user's Documents folder
+  — never the browser. The opener now invokes
+  `rundll32.exe url.dll,FileProtocolHandler <url>`, the
+  Microsoft-documented Windows URL-protocol entrypoint: no shell, so
+  cmd metacharacters (`&`, `|`, `^`) are never parsed, and argv is
+  passed verbatim to the URL handler which dispatches to the
+  user's registered default browser. macOS (`open`) and Linux
+  (`xdg-open`) are unchanged. (M-1057)
+
+- Platform-channel installers (`install.sh` / `install.ps1`) silently
+  installed `launchpad-cli` "successfully" while `launchpad
+  --version` continued to report the previous version. Root cause:
+  the install ran `npm install -g <tarball>` which writes to npm's
+  global prefix, but the user's shell resolved `launchpad` to an
+  older shim earlier on PATH (typically a previous `bun add -g` /
+  `pnpm add -g` install, or a stale npm prefix). The new install
+  was correct on disk; PATH ordering hid it. The installers now (a)
+  call the just-installed binary by absolute path for
+  `skills install` — so the bundled skills always match the CLI
+  being installed, not the shadowed one — and (b) compare the
+  resolved `launchpad` against `$(npm prefix -g)/bin/launchpad`
+  (`<prefix>\launchpad.cmd` on Windows) and print a loud, actionable
+  warning when they differ, telling the user exactly which binary is
+  shadowing and how to remove it. (M-1058)
+
+## 0.11.1 — 2026-05-19
+
+### Fixed
+
+- `launchpad update` on Windows. `update.ts` invoked `execFile("npm",
+  …)` / `spawn("npm", …)`, but Node's `child_process` on Windows uses
+  `CreateProcess`, which does NOT consult `PATHEXT` — it only tries
+  the literal filename and `<name>.exe`. `npm` (and `pnpm`) ship as
+  `.cmd` shims on Windows, so the call always failed with `ENOENT`,
+  and the catch branch surfaced this as the misleading message
+  "`npm` was not found on PATH (it ships with Node.js)" — even on
+  machines where `npm` worked perfectly from `cmd` / PowerShell. A
+  new `resolvePmBin` helper appends `.cmd` for `npm` / `pnpm` on
+  `win32`; the registry query, the `<pm> root -g` detection probes,
+  and the upgrade `spawn` all go through it. `bun` (a real
+  `bun.exe`) and every non-Windows platform are unchanged. The
+  ENOENT branch's user-facing message has been rewritten to point at
+  a missing Node install rather than mis-blaming PATH. (M-1056)
+
+## 0.11.0 — 2026-05-19
+
+### Added
+
+- Platform distribution channel. The CLI can now be installed from
+  `get.launchpad.m-kopa.us` behind M-KOPA SSO — download one
+  self-extracting installer for your OS (`install.sh` / `install.ps1`)
+  and run it; no GitHub-org membership and no npm-registry setup
+  required. GitHub Packages remains the engineer / CI channel. See
+  `docs/adr/0014-cli-distribution-channel.md`.
+- `launchpad update` resolves the latest version from whichever
+  channel installed the CLI. A platform-channel install reads the
+  public `version.json` over plain HTTP with no GitHub Packages auth;
+  the GitHub Packages path is unchanged. (SCOPE-M-1042)
+
+### Fixed
+
+- `launchpad login` on Windows. The browser opener ran
+  `cmd /c start "" <url>`, and `cmd.exe` split the OAuth URL on its
+  `&` characters — the browser received only the URL up to the first
+  `&`, dropping the PKCE `code_challenge`, so Cloudflare Access
+  rejected the login (`code_challenge is required for public
+  clients`). The CLI now opens the browser via `explorer.exe`, which
+  involves no shell. (M-1055)
+
+## 0.10.0 — 2026-05-17
+
+### Added
+
+- `launchpad update` — self-update the CLI to the latest published
+  release. Reads the latest version from GitHub Packages via
+  `npm view @m-kopa/launchpad-cli version --registry=https://npm.pkg.github.com`,
+  reusing the
+  user's existing `~/.npmrc` auth — the command never writes npmrc or
+  handles tokens. Detects which package manager owns the global
+  install by prefix-matching the running package directory against the
+  npm / pnpm / bun global roots; on a unique match it runs that PM's
+  global upgrade, and on an ambiguous match it prints the three
+  explicit upgrade commands rather than guessing. `--via npm|bun|pnpm`
+  forces the package manager. On success it reminds the user to run
+  `launchpad skills update`, since the CLI and the skill bundle are
+  version-locked.
+- `launchpad update --check` — report the running version against the
+  latest published; install nothing. Exit `0` when up to date, exit
+  `10` when an update is available — scriptable.
+
+### Notes
+
+- Closes SCOPE-M-1007, the follow-up to SCOPE-M-760's deferred "CLI
+  autoupdate" out-of-scope item. Zero new runtime dependencies — the
+  command uses only `node:child_process` + `node:*` stdlib.
+
+## 0.8.0 — 2026-05-13
+
+### Added
+
+- `launchpad create` — file a new app from the terminal, mirroring
+  the portal wizard's `POST /apps` wire format byte-for-byte. The
+  flag set is `--slug`, `--display-name`, `--app-type`,
+  `--allowed-group` (repeatable), and optional `--description`.
+  Same closed three-type taxonomy as the wizard
+  (`static | react | react+api`); no slug pre-flight (the bot's
+  registry is the authoritative gate); no env-var seeding (use
+  `launchpad envvars set` post-creation). Unblocks SCOPE-M-881's
+  AC5 self-service path for users who can't or won't open the SPA.
+
+## 0.7.3 — 2026-05-11
+
+### Fixed
+
+- `launchpad deploy` failed mid-run with `invalid_client: Client ID
+  is required` (HTTP 401 from Cf Access token endpoint) whenever
+  the access token expired before the deploy POST. The bytes-fetcher
+  used by `deploy` overrode `init.body` on every request the
+  caller-supplied fetcher saw — including the silent refresh-token
+  call that `api-client` threads through `getValidAccessToken`.
+  Cf then received the gzip tarball with an
+  `application/x-www-form-urlencoded` content-type and rejected the
+  request because it couldn't find `client_id` in the binary body.
+  Make the bytes-fetcher URL-aware: only override `body` when the
+  request targets the deploy-pr path; pass everything else (token
+  endpoint, anything else the auth stack fires) through untouched.
+
+## 0.7.2 — 2026-05-11
+
+### Fixed
+
+- `launchpad deploy` failed with `protected_paths` whenever the
+  cloned working tree contained `.github/workflows/ci.yml`,
+  `wrangler.toml`, or any other bot-owned file — i.e. every clone,
+  every time. The bot rejects the deploy if those paths appear in
+  the tarball regardless of content; the CLI was happily shipping
+  the full working tree via `git ls-files`. Mirror the bot's
+  `PROTECTED_PATHS` set client-side and filter them out before
+  packing. The bot uses `base_tree` mode on the commit, so files
+  we omit keep their base-branch contents — no destructive
+  consequence to the filter.
+
+## 0.7.1 — 2026-05-11
+
+### Fixed
+
+- `launchpad login` failed against Cloudflare Access with
+  `error=invalid_target: No resource parameter found`. Cf Access
+  requires the [RFC 8707](https://datatracker.ietf.org/doc/html/rfc8707)
+  resource indicator on the authorization request; the previous
+  release built the auth URL without it. The protected-resource
+  metadata's `resource` field is now read at discovery time and
+  threaded through the auth URL, the code-for-token exchange, AND
+  the refresh-token grant. Cached in the session so silent refresh
+  can reuse it.
+
+### Migration
+
+- Sessions written by 0.7.0 don't carry the `resource` field, so a
+  silent refresh would fail. Those sessions surface as
+  `LoginRequiredError` on the next bot call; the user re-runs
+  `launchpad login` to mint a fresh session in the new shape.
+
+## 0.7.0 — 2026-05-11
+
+### Added
+
+- `launchpad envvars list [--slug <slug>]` — render production env
+  vars on the app's Pages project as a `NAME / TYPE / VALUE` table.
+  `secret_text` values are rendered as `•••` because the bot never
+  returns them (Cf redacts server-side).
+- `launchpad envvars set <KEY>=<value> [<KEY>=<value> ...] [--secret] [--slug <slug>]`
+  — write env vars. `--secret` flips all pairs in the call to
+  `secret_text`; default is `plain_text`. Mirrors the bot's
+  `[A-Z][A-Z0-9_]*` key constraint client-side so bad keys fail
+  before the round-trip.
+- `launchpad envvars rm <KEY> [<KEY> ...] [--slug <slug>]` — drop
+  env vars by name. PATCHes `{envVars: {<KEY>: null}}` per the
+  bot's edit contract.
+- `launchpad logs [--slug <slug>] [--lines <n>]` — render recent
+  Pages deployment history (ID / ENV / STATUS / STAGE / CREATED).
+  Default 10 lines, max 25 per call. **Not a runtime log tail** —
+  the bot's surface today is deployment metadata only. Helpful for
+  the common "my deploy didn't go live, what happened?" failure
+  mode; the CHANGELOG flags the gap explicitly so users aren't
+  surprised.
+- `.github/workflows/launchpad-cli-publish.yml` — publish workflow
+  modelled on `package-publish.yml`. Path-filter on
+  `packages/launchpad-cli/package.json`. Re-runs the full gate
+  (typecheck + lint + test + audit + version-sync + license +
+  build), checks whether the version is already published, and
+  publishes + tags `launchpad-cli@<version>` if new.
+- `scripts/check-version-sync.sh` — fail-fast guard that ensures
+  `version` in package.json and `CLI_VERSION` in src/version.ts
+  agree. Wired in as `check:version-sync` so the publish workflow
+  catches a forgotten bump before pushing to the registry.
+- Wire types in `src/types/api.ts`: `EnvVarEntry`,
+  `EnvVarsListResponse`, `DeploymentSummary`, `DeploymentsResponse`.
+
+### Deferred
+
+- Runtime log tailing. Cf Pages doesn't expose a stable HTTP API
+  for tailing function logs; the dashboard uses an authenticated
+  WebSocket that the bot doesn't proxy. v1's `launchpad logs`
+  surfaces deployment history instead — the highest-signal
+  diagnostic the bot CAN return today. Tracked as a follow-up
+  scope once Cf publishes a tailable surface (or once the bot
+  acquires a log-relay shim).
+
+## 0.6.0 — 2026-05-10
+
+### Added
+
+- `launchpad review [<prNumber>] [--slug <slug>]` — render the
+  per-PR review state (aggregate status + per-source findings).
+  - If `<prNumber>` is omitted, defaults to the newest open PR
+    via `GET /apps/<slug>/prs` (server-sorted `updated_at desc`).
+  - Findings are rendered ranked by severity (blocker_hard first).
+  - Empty findings list collapses to a single-line "No findings."
+- `launchpad merge <prNumber> [--slug <slug>]` — squash-merge a
+  review-passed PR via the bot.
+  - PR number is REQUIRED (no inference) — merging the wrong PR
+    is a load-bearing mistake, the extra keystroke is cheap.
+  - Tailored exit messages per `error` discriminator:
+    `review_running` (wait), `review_blocked` (see findings),
+    `merge_conflict` (rebase), `sha_mismatch` (retry),
+    `pipeline_unavailable` (push to trigger workflow), etc.
+- `src/http/api-client.ts` — `nonThrowingStatuses` option on
+  `apiRaw` so callers (currently just `merge`) can opt out of the
+  shared `ApiError` mapping for statuses where the structured
+  envelope is the load-bearing signal. 401 / 403 / 404 still
+  throw typed errors regardless.
+- `src/types/api.ts` — wire shapes for the review tab + merge
+  endpoint (`ReviewStatePayload`, `PrSummary`, `MergeSuccessResponse`,
+  `BotErrorEnvelope`). Hand-maintained alongside the portal SPA's
+  copy of the same types.
+
+## 0.5.0 — 2026-05-10
+
+### Added
+
+- `launchpad deploy [--message <text>] [--slug <slug>]` — package
+  the working tree + open/update a PR via the bot.
+  - Enumerates files via `git ls-files -co --exclude-standard` so
+    `.gitignore` semantics are honoured exactly the way git does.
+    No hand-rolled matcher.
+  - Packs into a POSIX ustar tarball; gzips via Web Streams
+    `CompressionStream`. Deterministic byte output (zero mtimes,
+    zero uid/gid, lex-sorted entries).
+  - Executable bit preserved end-to-end so committed scripts at
+    100755 stay executable through deploy → review → live.
+  - 50MB compressed cap enforced client-side; the bot's
+    100MB-uncompressed + 5MB-per-file caps apply server-side too.
+  - Per-file 5MB cap on the client matches the bot's reader.
+  - Slug defaults to the cwd's `launchpad-app-<slug>` suffix;
+    `--slug` overrides.
+  - `--message` threaded as `x-launchpad-message` header for
+    forward-compat with a bot that consumes it.
+- `src/deploy/git-files.ts` — `git ls-files -co --exclude-standard
+  -z` wrapper. Sorts lex for reproducible tarballs.
+- `src/deploy/tar-pack.ts` — POSIX ustar writer + gzip pipeline.
+  Round-trips against `src/clone/tar-extract.ts` (slice-4 reader)
+  so we don't independently mis-implement the format on both
+  sides.
+
+### Deferred
+
+- `git merge-base` staleness check against bot-served `main` HEAD.
+  No bot endpoint exposes the HEAD SHA cheaply today; the bot's
+  deploy-pr handler produces a reasonable PR diff regardless.
+  Tracked for a follow-up; clearly marked TODO in
+  `src/commands/deploy.ts`.
+
+## 0.4.0 — 2026-05-10
+
+### Added
+
+- `launchpad clone <slug>` — streams the app's source tarball
+  from the bot's `/apps/<slug>/source-bundle`, decompresses gzip,
+  walks the POSIX ustar entries, strips GitHub's
+  `<owner>-<repo>-<sha>/` prefix, writes files to
+  `./launchpad-app-<slug>/`, and runs `git init -b main` + an
+  initial commit. No remote configured (deploys go via
+  `launchpad deploy`, not `git push`).
+- `src/clone/tar-extract.ts` — Node-side port of the bot's
+  hand-rolled ustar reader. Same MAX_ENTRY_SIZE / MAX_ENTRY_COUNT
+  caps. Path-traversal guard rejects entries that resolve outside
+  the destination dir. `DestinationNotEmptyError` is distinct from
+  `TarballParseError` so the verb refuses cleanup when the dest is
+  the user's pre-existing dir.
+- `src/clone/git-init.ts` — minimal `git init` runner via
+  `node:child_process.spawn`. Uses inline `-c user.email` /
+  `-c user.name` so a missing global git config doesn't break
+  the initial commit. `--no-gpg-sign` defends against
+  mandatory-sign configs failing on a fresh repo.
+
+## 0.3.0 — 2026-05-10
+
+### Added
+
+- `launchpad apps` — list apps the caller has access to via
+  `GET /me/apps`. Renders a fixed-width table sorted by the bot's
+  `provisioning → failed → live` order. Empty result prints a
+  friendly "no apps yet" hint rather than a blank table.
+- `launchpad whoami` — show the current session's email + sub
+  (decoded from the access-token JWT payload, no signature check —
+  display only), session expiry both relative and absolute, and a
+  per-app role summary.
+- Shared HTTP layer (`src/http/api-client.ts`):
+  - `apiJson<T>` for typed JSON-returning calls.
+  - `apiRaw` for streaming consumers (slice 4's `clone` will use
+    this; the body stays a stream rather than a buffered string).
+  - Status mapping: 401 → `UnauthenticatedError` ("run `launchpad
+    login`"), 403 → `ForbiddenError`, 404 → `NotFoundError`,
+    other non-2xx → `ApiError` with status, network failures →
+    `TransportError`.
+  - `getValidAccessToken` is called up front, so the bearer is
+    refreshed silently before every request.
+- Tiny payload-only JWT decoder (`src/auth/jwt.ts`) — used by
+  `whoami`. Does NOT validate signatures; the bot does that.
+
+## 0.2.0 — 2026-05-10
+
+### Added
+
+- `launchpad login` — Cloudflare Access Managed OAuth (PKCE) flow:
+  discovery, dynamic client registration, code-challenge regen quirk
+  (Cloudflare requires the challenge to start with `[a-zA-Z0-9]`),
+  loopback-bound callback server (`127.0.0.1:0`, OS-assigned port),
+  cross-platform browser opener, code-for-token exchange, persisted
+  session at `~/.launchpad/session.json` (mode `0600`).
+- `launchpad logout` — zero-out the persisted session. Idempotent.
+- `getValidAccessToken(sessionPath)` — symmetric read path for
+  subsequent slices: returns the current access token if still valid,
+  otherwise silently refreshes via `refresh_token`. 4xx on refresh
+  surfaces as `LoginRequiredError` ("session expired — run
+  `launchpad login`"); 5xx propagates the underlying error.
+- `LAUNCHPAD_BOT_URL` and `LAUNCHPAD_SESSION_PATH` env-var overrides
+  for local-dev / preview / integration-test scenarios.
+
+## 0.1.0 — 2026-05-10
+
+### Added
+
+- Initial package scaffolding under SCOPE-M-760 / T5 (M-765) slice 1.
+- Bin entry `launchpad` with `--help` / `-h` and `--version` / `-v`.
+- Hand-rolled argument dispatcher (no `commander` / `yargs` dep) —
+  the verb table is small enough that a switch is more legible than
+  another runtime dependency. Real commands wire in via subsequent
+  slices.
+- TypeScript strict, ESM-only, Node ≥ 20.