@m-kopa/launchpad-cli 0.26.1 → 0.27.1

package/dist/commands/login.d.ts

@@ -1,3 +1,13 @@
+import { login } from "../auth/flow.js";
+import { gatewayLogin } from "../auth/gateway-flow.js";
 import type { Command } from "../dispatcher.js";
+/** Injectable seams so the dual-path order, fallback messaging and
+ *  kill-switch are testable without a live browser or network. The
+ *  production command wires the real flows. */
+export interface LoginCommandDeps {
+    readonly gatewayLogin: typeof gatewayLogin;
+    readonly legacyLogin: typeof login;
+}
 export declare const loginCommand: Command;
+export declare function makeLoginCommand(deps?: LoginCommandDeps): Command;
 //# sourceMappingURL=login.d.ts.map

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

@@ -1 +1 @@
-{"version":3,"file":"login.d.ts","sourceRoot":"","sources":["../../src/commands/login.ts"],"names":[],"mappings":"AAIA,OAAO,KAAK,EAAE,OAAO,EAAmB,MAAM,kBAAkB,CAAC;AAEjE,eAAO,MAAM,YAAY,EAAE,OAI1B,CAAC"}
+{"version":3,"file":"login.d.ts","sourceRoot":"","sources":["../../src/commands/login.ts"],"names":[],"mappings":"AAiBA,OAAO,EAAE,KAAK,EAAE,MAAM,iBAAiB,CAAC;AACxC,OAAO,EAAE,YAAY,EAAE,MAAM,yBAAyB,CAAC;AACvD,OAAO,KAAK,EAAE,OAAO,EAAmB,MAAM,kBAAkB,CAAC;AAEjE;;+CAE+C;AAC/C,MAAM,WAAW,gBAAgB;IAC/B,QAAQ,CAAC,YAAY,EAAE,OAAO,YAAY,CAAC;IAC3C,QAAQ,CAAC,WAAW,EAAE,OAAO,KAAK,CAAC;CACpC;AAID,eAAO,MAAM,YAAY,EAAE,OAA4B,CAAC;AAExD,wBAAgB,gBAAgB,CAAC,IAAI,GAAE,gBAA4B,GAAG,OAAO,CAM5E"}

package/dist/commands/logout.d.ts

@@ -1,3 +1,10 @@
+import { revokeGatewaySession } from "../auth/gateway-flow.js";
 import type { Command } from "../dispatcher.js";
+/** Injectable seam so the server-side revoke (and its offline
+ *  failure path) is testable without a live gateway. */
+export interface LogoutCommandDeps {
+    readonly revoke: typeof revokeGatewaySession;
+}
 export declare const logoutCommand: Command;
+export declare function makeLogoutCommand(deps?: LogoutCommandDeps): Command;
 //# sourceMappingURL=logout.d.ts.map

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

@@ -1 +1 @@
-{"version":3,"file":"logout.d.ts","sourceRoot":"","sources":["../../src/commands/logout.ts"],"names":[],"mappings":"AAIA,OAAO,KAAK,EAAE,OAAO,EAAmB,MAAM,kBAAkB,CAAC;AAEjE,eAAO,MAAM,aAAa,EAAE,OAI3B,CAAC"}
+{"version":3,"file":"logout.d.ts","sourceRoot":"","sources":["../../src/commands/logout.ts"],"names":[],"mappings":"AAuBA,OAAO,EAAE,oBAAoB,EAAE,MAAM,yBAAyB,CAAC;AAC/D,OAAO,KAAK,EAAE,OAAO,EAAmB,MAAM,kBAAkB,CAAC;AAEjE;wDACwD;AACxD,MAAM,WAAW,iBAAiB;IAChC,QAAQ,CAAC,MAAM,EAAE,OAAO,oBAAoB,CAAC;CAC9C;AAID,eAAO,MAAM,aAAa,EAAE,OAA6B,CAAC;AAE1D,wBAAgB,iBAAiB,CAAC,IAAI,GAAE,iBAA6B,GAAG,OAAO,CAM9E"}

package/dist/config.d.ts

@@ -1,7 +1,18 @@
 /** Production bot URL (Cloudflare Workers `*.workers.dev` host). */
 export declare const DEFAULT_BOT_URL = "https://launchpad-portal-bot.mkopa-launchpad.workers.dev";
+/** Production auth gateway — the issuer of the cli-session credential
+ *  (`launchpad login`'s default front-channel, ADR 0026). Endpoints
+ *  are FIXED paths on this host (no discovery). Override with
+ *  `LAUNCHPAD_AUTH_GATEWAY_URL` for tests / preview gateways. */
+export declare const DEFAULT_AUTH_GATEWAY_URL = "https://auth.launchpad.m-kopa.us";
 export interface CliConfig {
     readonly botUrl: string;
+    /** Base URL of the auth gateway minting cli-session credentials. */
+    readonly authGatewayUrl: string;
+    /** Kill-switch: `LAUNCHPAD_AUTH_LEGACY=1` forces `launchpad login`
+     *  onto the legacy Cloudflare Access flow, skipping the gateway
+     *  entirely (dual-auth window escape hatch — AC-WINDOW). */
+    readonly authLegacy: boolean;
     readonly sessionPath: string;
     readonly cacheDir: string;
     readonly stateDir: string;

package/dist/config.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"config.d.ts","sourceRoot":"","sources":["../src/config.ts"],"names":[],"mappings":"AA4CA,oEAAoE;AACpE,eAAO,MAAM,eAAe,6DACgC,CAAC;AAE7D,MAAM,WAAW,SAAS;IACxB,QAAQ,CAAC,MAAM,EAAE,MAAM,CAAC;IACxB,QAAQ,CAAC,WAAW,EAAE,MAAM,CAAC;IAC7B,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAC;IAC1B,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAC;IAC1B,QAAQ,CAAC,gBAAgB,EAAE,MAAM,GAAG,IAAI,CAAC;CAC1C;AAED,wBAAgB,UAAU,CAAC,GAAG,GAAE,MAAM,CAAC,UAAwB,GAAG,SAAS,CAgB1E"}
+{"version":3,"file":"config.d.ts","sourceRoot":"","sources":["../src/config.ts"],"names":[],"mappings":"AAkDA,oEAAoE;AACpE,eAAO,MAAM,eAAe,6DACgC,CAAC;AAE7D;;;iEAGiE;AACjE,eAAO,MAAM,wBAAwB,qCAAqC,CAAC;AAE3E,MAAM,WAAW,SAAS;IACxB,QAAQ,CAAC,MAAM,EAAE,MAAM,CAAC;IACxB,oEAAoE;IACpE,QAAQ,CAAC,cAAc,EAAE,MAAM,CAAC;IAChC;;gEAE4D;IAC5D,QAAQ,CAAC,UAAU,EAAE,OAAO,CAAC;IAC7B,QAAQ,CAAC,WAAW,EAAE,MAAM,CAAC;IAC7B,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAC;IAC1B,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAC;IAC1B,QAAQ,CAAC,gBAAgB,EAAE,MAAM,GAAG,IAAI,CAAC;CAC1C;AAED,wBAAgB,UAAU,CAAC,GAAG,GAAE,MAAM,CAAC,UAAwB,GAAG,SAAS,CA2B1E"}

package/dist/version.d.ts

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@m-kopa/launchpad-cli",
-  "version": "0.26.1",
+  "version": "0.27.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": {
@@ -28,7 +28,7 @@
   "homepage": "https://github.com/M-KOPA/launchpad-platform/tree/main/packages/launchpad-cli#readme",
   "license": "UNLICENSED",
   "dependencies": {
-    "esbuild": "0.27.3",
+    "esbuild": "0.28.1",
     "yaml": "2.9.0",
     "zod": "4.4.3"
   },

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) and the stack-fit pre-flight that the bot enforces server-side. 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.26.1
+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.27.1
 ---
 
 <!-- BEGIN shell-contract (managed by scripts/sync-skill-contract.sh — edit skills/_partials/shell-contract.md) -->
@@ -33,17 +33,23 @@ esac
 Push a content change to an already-provisioned Launchpad app, then
 verify it shipped.
 
+The slash-command name is historical: subsequent deploys do **not**
+open a content PR any more. The bot commits the bundle **directly to
+the app repo's `main`** and Cloudflare Pages builds from that commit
+asynchronously — so "ship" and "verify" are two separate steps, and
+this skill covers both.
+
 Under Model A the first deploy and the first content are the same
 event — `launchpad init` + `launchpad deploy` from the user's CWD
-opens a PR that contains their working tree, the bot waits for the
-Cloudflare Pages deployment to come up green (`deployment_verified`
-lifecycle gate), and the lifecycle flips to `live`. There is no
-separate "now push content" step.
+stages the working tree with the provisioning run: the workflow's
+`content_seeded` stage commits it straight onto the app repo's
+`main`, the bot waits for the Cloudflare Pages deployment to come up
+green (`deployment_verified`), and the lifecycle flips to `live`.
+There is no separate "now push content" step.
 
 This skill is therefore the **iteration** companion to
 `/launchpad-deploy`: once an app is live, how do you ship the next
-change? It is also the canonical place to find the stack-fit
-pre-flight (the rules the bot enforces server-side on every bundle).
+change — and how do you know it's actually serving.
 
 ## Pre-flight
 
@@ -65,7 +71,10 @@ Look for the slug in the `live` lifecycle bucket. If it's in
 `provisioning` / `failed` / `destroying` / `destroyed`, the
 iteration loop is not the right tool — route to
 `/launchpad-deploy-status` (in-flight) or `/launchpad-destroy`
-(teardown) instead.
+(teardown) instead. If it shows `failed` but the app is actually
+serving (e.g. a verification timed out after the real deploy
+succeeded), `launchpad recover <slug>` reconciles the record against
+live Cloudflare state.
 
 ## Edit and ship
 
@@ -75,92 +84,84 @@ The iteration loop is two verbs:
 # 1. Edit your working tree.
 
 # 2. Ship it.
-launchpad deploy --message "<one-line description>"
+launchpad deploy
 ```
 
-The CLI bundles the CWD (using `git ls-files -co --exclude-standard`
-where available; falling back to a pure-FS walker honouring
-`.gitignore` and a default-ignore set), gzips it, uploads to the
-bot, and the bot opens a content PR on `launchpad-app-<slug>`.
-Cloudflare Pages auto-deploys on merge to `main`; the bot waits for
-the deploy to come up green via the `deployment_verified` lifecycle
-gate before reporting `done`.
-
-Common flags:
-
-- **`--slug <slug>`** — explicit override. Defaults to the slug from
-  `./launchpad.yaml`, or the cwd-name parse if you're in a
-  `launchpad-app-<slug>/` clone.
-- **`--message <text>`** — threaded as the PR description. Useful
-  for change logs and audit trails.
-- **`--file <path>`** — point at a non-default manifest path.
+What happens:
+
+- The CLI bundles the CWD with a **pure-FS walker** (no `git`
+  needed) honouring `.gitignore` plus a default-ignore set; symlinks
+  are never followed. The bundle is gzipped and uploaded to the bot.
+- The bot runs its server-side gates (next section), then commits
+  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`.
+
+Flags worth knowing:
+
+- The slug comes from `./launchpad.yaml` (`metadata.slug` /
+  `metadata.name`). On this path `--slug` does **not** override it —
+  it only overrides directory-name inference on the legacy clone
+  flow (no local manifest).
+- **`--message`** is sent as a forward-compat header on the legacy
+  path only, and **the bot currently ignores it**. Don't rely on it
+  for change logs or audit trails.
+- **`--file`** is valid only with `--dry-run` / `--apply`
+  (manifest-driven modes), not with a content deploy.
 
 Exit codes:
 
-- **0** — content PR opened + Cloudflare Pages deployment verified.
-- **non-zero** — see `/launchpad-deploy-status <slug>` for the
-  failure reason.
-
-## Stack-fit — what the bot enforces server-side
-
-The bot rejects bundles that contain shapes the Cloudflare Pages +
-Workers runtime cannot host. The validation runs on every
-`launchpad deploy`; you do not need to pre-flight it locally, but
-**knowing what's enforced saves the round-trip when a bundle is
-going to fail**.
-
-The accepted Launchpad stack is the single source of truth in:
-
-- `launchpad-platform/ARCHITECTURE.md § Tech Stack`
-- `launchpad-platform/PATTERNS.md § Approved Libraries`
-- `launchpad-platform/ANTI-PATTERNS.md`
-
-### Forbidden runtime dependencies
-
-The bot rejects bundles whose `package.json` declares any of these
-runtime dependencies — they do not work in the Workers runtime
-without a non-trivial port:
-
-| Forbidden | Replacement on Launchpad |
-|---|---|
-| `fastify` / `express` / `koa` / `hapi` / `@nestjs/*` | `hono` mounted at `functions/api/[[path]].ts` — the only server framework (PATTERNS.md). |
-| `better-sqlite3` / native `sqlite3` | Cloudflare D1 binding (`wrangler.toml [[d1_databases]]`). |
-| `pg` / `mysql2` / `mongodb` / `mongoose` / `redis` / `ioredis` | Neon (Postgres over HTTP) or another HTTP-driver backend. Native TCP drivers do not work in the Workers runtime. |
-| `dotenv` | `c.env.*` bindings; `wrangler secret put` (or `launchpad envvars` / `launchpad secrets push`) for secrets. |
-| `pm2` / `forever` / `nodemon` | Cloudflare Cron Triggers (`wrangler.toml [triggers] crons`). |
-
-### Forbidden top-level files
-
-The bot rejects bundles whose root contains any of these (on non-
-container app-types):
-
-```
-Dockerfile · docker-compose.yml · docker-compose.yaml · nginx.conf
-pm2.config.js · ecosystem.config.js · Procfile
-```
-
-Their presence is the smoking gun that the app was copied from a
-long-running-server stack without removing the legacy infra.
-
-### Forbidden source patterns
-
-The bot's secret-scan + build-command policy rejects bundles where
-the source tree contains:
-
-- `process.env.X` / `process.env['X']` reads — switch to `c.env.*`
-  bindings.
-- `setInterval` / `setTimeout` daemons — Workers do not run between
-  requests; use Cron Triggers for periodic work.
-- High-signal secret patterns (AWS access keys, GitHub PATs / OAuth
-  / app tokens, Slack tokens, SSH/RSA/EC/PGP keys, generic
-  `api_key` shapes). These never belong in a bundle — push them
-  through `launchpad secrets push` instead.
-
-### `react+api` requires `nodejs_compat`
-
-The bot checks that `wrangler.toml` declares
-`compatibility_flags = ["nodejs_compat"]` for any `react+api` app
-(ADR-0011 carve-out).
+- **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`.
+- **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>`.
+
+## What the bot enforces on every bundle
+
+The canonical gate list and caps live in `/launchpad-deploy
+§ Constants (single source of truth)`. In user-visible terms, every
+upload passes:
+
+- **Bundle policy** — file-count / bundle-size / per-file-size caps,
+  symlink and path-traversal/absolute-path rejection, and auth-file
+  rules (`.github/workflows`, CODEOWNERS, `.npmrc`/`.yarnrc`
+  carrying auth tokens, `.git/`).
+- **Secret scan** — high-signal secret patterns (AWS access keys,
+  GitHub PATs / OAuth / app tokens, Slack tokens, SSH/RSA/EC/PGP
+  private keys, generic `api_key` shapes). These never belong in a
+  bundle — push them through `launchpad secrets push` instead.
+- **Build-command allowlist** — `build.command` must match the
+  bot's allowlist.
+- **App boundary (CLI-side, before upload)** — files outside
+  `app.root` / `app.include` are stripped with a warning, and
+  key/cert-shaped files (`*.pem`, `*.key`, `id_rsa*`, `*.p12`) are
+  denied client-side.
+
+Gates are **delta-judged** (ADR 0025): they evaluate what your
+deploy *changes* relative to `main`, not everything the workspace
+contains. A pre-existing violation already live on `main` becomes a
+non-blocking **standing exception** — recorded by the bot and
+surfaced by both `launchpad deploy` and `launchpad status` (the bot
+serves the inventory at `GET /apps/<slug>/exceptions`). So "my old
+violation didn't block this deploy" is by design, not a missed gate.
+
+There is **no** server-side scan of `package.json` dependencies,
+top-level files, or source patterns. Express/Koa-style servers,
+native DB drivers (`pg`, `better-sqlite3`, …), `dotenv`, and
+pm2/Docker artefacts are not rejected at deploy time — they simply
+won't run on the Cloudflare Pages + Workers runtime and fail at
+build or runtime instead. Likewise `react+api`'s
+`compatibility_flags = ["nodejs_compat"]` in `wrangler.toml`
+(ADR-0011) is **required but not validated** — a missing flag fails
+at runtime. Treat the stack-constraints table in `/launchpad-deploy`
+as advisory architecture guidance, not an enforced gate.
 
 ### Verifying locally before you ship
 
@@ -172,34 +173,47 @@ launchpad validate
 launchpad plan
 ```
 
-Neither verb talks to the bot. Catch what you can locally; the bot
-catches the rest server-side.
+Both are offline by default (no bot). `launchpad validate
+--strict-groups` opts in to an online check that resolves
+`access.allowed_entra_group` (needs a session).
 
-## Verify after merge
+## Verify the deploy
 
 ```bash
 launchpad status <slug>
 ```
 
-Three possible states (see `/launchpad-status` for the canonical
-reference):
-
-- **`in sync`** — local matches deployed; the deploy landed and
-  `deployment_verified` is green. You're done.
-- **`drift: <fields>`** — your local manifest diverges from what was
+`launchpad status` reports manifest drift **and** the live
+Cloudflare Pages build truth — last deployment, what triggered it,
+build outcome, and a failure-log excerpt when the build broke. (See
+`/launchpad-status` for the full state list.) What you're looking
+for after a deploy:
+
+- **`live, in sync`** with `last deployment: build success` — your
+  commit landed and the build is serving. You're done.
+- **`last deployment: build FAILED at stage "<stage>"`** (+ log
+  excerpt) — the commit landed but the build broke; the previous
+  successful deployment is still serving. Fix the cause and re-run
+  `launchpad deploy`.
+- **`build IN PROGRESS`** — re-run `launchpad status` shortly to
+  confirm the outcome.
+- **`drift: <fields>`** — your local manifest diverges from what's
   deployed. Either re-run `launchpad deploy` to ship the local, or
   `launchpad pull <slug> --out launchpad.yaml` to bring the local
   into line with deployed.
-- **`no deployed manifest yet`** — the deploy is still in flight or
-  failed. Re-check in a minute, or run `/launchpad-deploy-status
-  <slug>`.
+- **provisioning / failed / destroy states** — route to
+  `/launchpad-deploy-status` or `/launchpad-destroy`.
+
+Do not declare a change shipped until `status` shows the build
+outcome for your commit.
 
 You can also point a browser at `https://<slug>.launchpad.m-kopa.us`
-once status reports `in sync`. An SSO gate sits in front of the app:
-for a gateway-fronted app (the default, `auth: gateway`) expect a
-redirect to the Entra-OIDC gateway (Microsoft sign-in) on the first
-request; for an `auth: access` app expect a redirect to
-`*.cloudflareaccess.com`. Either way you land on your app after sign-in.
+once status reports the build green. An SSO gate sits in front of
+the app: for a gateway-fronted app (the default, `auth: gateway`)
+expect a redirect to the Entra-OIDC gateway (Microsoft sign-in) on
+the first request; for an `auth: access` app expect a redirect to
+`*.cloudflareaccess.com`. Either way you land on your app after
+sign-in.
 
 If the URL serves the wrong thing:
 
@@ -218,16 +232,23 @@ If the URL serves the wrong thing:
 Once you've shipped first content, the daily-use verbs are:
 
 - **`launchpad status`** (`/launchpad-status`) — is my local
-  `launchpad.yaml` in sync with what's deployed?
+  `launchpad.yaml` in sync with what's deployed, and did the last
+  build succeed?
 - **`launchpad pull <slug>`** (`/launchpad-status`) — read the
   currently-deployed `launchpad.yaml`.
-- **`launchpad deploy`** — package the working tree + open an
-  update PR via the bot.
+- **`launchpad deploy`** — bundle the working tree; the bot commits
+  it directly to the app repo's `main`.
 - **`launchpad envvars`** — list / set / remove non-secret
   production env vars.
-- **`launchpad secrets push`** — push secrets (never via git).
-- **`launchpad logs <slug>`** — recent Cloudflare Pages deployment
-  history.
+- **`launchpad secrets template`** — emit `.env.example` from the
+  manifest's secret bindings.
+- **`launchpad secrets push`** — push secret values from `.env`
+  (never via git).
+- **`launchpad secrets status`** — names-only PRESENT/MISSING audit
+  per binding.
+- **`launchpad logs --slug <slug>`** — recent Cloudflare Pages
+  deployment history (default 10 entries, max 25 via `--lines`).
+  Note: the slug is flag-only, not positional.
 - **`launchpad rollback`** — revert manifest to a prior git SHA +
   re-apply.
 
@@ -237,17 +258,18 @@ Once you've shipped first content, the daily-use verbs are:
   skill. Every step is a `launchpad` verb. External users without
   M-KOPA GitHub access need this skill to work end-to-end on the
   CLI alone.
-- Do **not** open content PRs by hand against the app repo — the
-  bot's bootstrap ruleset gates auto-merge, and a hand-rolled PR
-  bypasses the bundle scan, secret-scan, and build-command policy.
-  Use `launchpad deploy`.
-- Do **not** treat the stack-fit pre-flight as something the user
-  re-implements locally. The bot enforces it server-side on every
-  bundle; the playbook describes what's enforced, not how to
-  re-implement it.
-- Do **not** force-merge if the bot's PR checks are red. The
-  bundle-policy / secret-scan / build-command checks are detecting
-  real things; surface the failure verbatim and let the user fix
+- Do **not** push commits or open PRs by hand against the app repo.
+  The bot commits through a ruleset bypass it alone holds, and a
+  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** 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
+  renders violations verbatim — surface them and let the user fix
   the bundle.
 - Do **not** edit `launchpad.yaml`'s `production_env:` block to
   contain secret values. That block is non-secret by contract;