@mutmutco/claude-plugin 4.5.20 → 4.5.21

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "mmi",
   "displayName": "MMI",
-  "version": "4.5.20",
+  "version": "4.5.21",
   "mmiCompat": "4.x",
   "description": "MMI workflow skills and org gates delivery.",
   "author": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mutmutco/claude-plugin",
-  "version": "4.5.20",
+  "version": "4.5.21",
   "description": "MMI workflow skills and org gates delivery.",
   "author": {
     "name": "MMI Future",

package/skills/bootstrap/SKILL.md

@@ -310,15 +310,17 @@ Provision the repo's vault namespace and deploy substrate from the Hub, not from
 secrets. Runtime config names live in the two-tier vault (`/mmi-future/<slug>/dev|rc|main/*`) and are
 managed through `/secrets`; never use `gh secret set` for product runtime config.
 
-The default `tenant-container` substrate is a **Hetzner box** (`hetzner-ssh`): the box writes the release
-`.env` from the registry + vault and runs the container via docker-compose, deployed over the Hub's bounded
+The default `tenant-container` substrate is a **Hetzner box** (`hetzner-ssh`): the deploy streams the stage's
+vault values into a tmpfs runtime env (no `.env` file) and runs the container via docker-compose, deployed over the Hub's bounded
 SSH lane. Do **not** create an AWS OIDC deploy role or a repo deploy Action for it. **Ask the master for the
 box assignment** — the `sshHost` (and the loopback port) per stage — then write the `DEPLOY#<stage>` rows with
 `mmi-cli oracle org project set-deploy <owner/repo> --stage <dev|rc|main> --ssh-host <host> [--port <p>]` (defaults:
 `substrate: hetzner-ssh`, deploy path `/opt/mmi/<slug>/<stage>`, service = slug, ssh-user `root`). Without those
 rows the tenant cannot deploy (`tenant-deploy.yml` errors on missing `DEPLOY#` coords), so do not skip this.
 `bootstrap apply` prints one `deploy-row` row per track stage for container models (#6070): `SKIP` when the
-registry row exists, `GAP` (`bootstrap-gap`) with the exact `set-deploy` command otherwise — a box
+registry row exists, `GAP` (`bootstrap-gap`) with the exact `set-deploy` command otherwise (for
+`tenant-container` it carries `--no-env-file true`, matching the fileless compose seed; run it from the tenant
+checkout once that compose is on the stage branch) — a box
 assignment cannot be invented, so this row is the one train-readiness fact the apply never writes itself.
 Keep every runtime config value in the vault; never paste secret values into logs.
 
@@ -485,9 +487,9 @@ mmi-cli devops bootstrap apply "$OWNER/$REPO" --class deployable \
 Tenant-container repos must carry a `docker-compose.yml` and Dockerfile that build from the shipped source
 archive; the train does not ship a prebuilt `dist/`. **Bootstrap seeds both files** for
 `deployModel: tenant-container` from `skills/bootstrap/seeds/` (rendered from
-the bootstrap seed Dockerfile and compose templates). The box
-writes the release `.env` from the registry + vault at deploy time; the compose file carries `env_file: .env`
-and the app reads plain env vars — it must **not** self-load SSM and must **not** ship a committed `.env`.
+the bootstrap seed Dockerfile and compose templates). The seeded compose is fileless: its service carries
+`labels: { mmi.runtime-env: "true" }`, no `env_file`, and a loopback-only port; the deploy injects the stage's
+vault values at runtime (`DEPLOY#<stage>.noEnvFile: true`) and the app reads plain env vars — it must **not** self-load SSM and must **not** ship a committed `.env`.
 
 For a `web-app` that declares `oauth` META, print the canonical OAuth surface and provision the client once:
 

package/skills/bootstrap/seeds/docker-compose.template.yml

@@ -7,9 +7,11 @@ services:
       # secrets:
       #   - NODE_AUTH_TOKEN
     restart: unless-stopped
-    # The box control document writes registry coords + stage-scoped SSM secret values into the
-    # release ./.env before `docker compose up`; env_file is what delivers them into the container.
-    env_file: .env
+    # Fileless deploy (DEPLOY#<stage>.noEnvFile: true): no .env exists. tenant-deploy.yml streams the
+    # stage-scoped vault values over SSH into a tmpfs (/dev/shm) runtime env, and the box injects them
+    # into every service labelled mmi.runtime-env. Never add env_file.
+    labels:
+      mmi.runtime-env: "true"
     environment:
       NODE_ENV: production
       MMI_STAGE: ${MMI_STAGE:-dev}
@@ -17,7 +19,8 @@ services:
       PORT: ${PORT:-3000}
       MMI_EDGE_DOMAIN: ${MMI_EDGE_DOMAIN:-}
     ports:
-      - "${MMI_PORT:-3000}:${PORT:-3000}"
+      # Loopback only: the box Caddy is the one public door (TLS), never the bare port.
+      - "127.0.0.1:${MMI_PORT:-3000}:${PORT:-3000}"
 
 # Build-time secret opt-in. Requires registry META:
 # requiredBuildSecrets: ["NODE_AUTH_TOKEN=@github-packages-token"]

package/skills/hotfix/SKILL.md

@@ -68,7 +68,7 @@ for the supported continuation; never replay a delivery whose result is uncertai
 
 Read the receipts, never the exit code (exit `1` = a follow-up failed after the tag; a pending follow-up exits `0`, so a clean exit alone never means every leg resolved):
 
-- `runs[]` — the release-triggered runs on the tagged SHA (workflow, conclusion, url). Watch each non-success entry to conclusion: `gh run watch <run-id> --repo {owner}/{repo} --exit-status`. Name which run is red: `deploy.yml` / `publish.yml` / `tenant-deploy.yml` / `jerv-gateway` is a deploy or publish verdict; a `gate` push run is ordinary CI sharing the SHA. `jerv-gateway` is the operator-host deploy leg: it has no run id to watch, so read its `deployNote` / `ledger.phases.deploy` — `pending` there means production was never deployed and blocks the next train run.
+- `runs[]` — the release-triggered runs on the tagged SHA (workflow, conclusion, url). Watch each non-success entry to conclusion: `gh run watch <run-id> --repo {owner}/{repo} --exit-status --interval 30`. Name which run is red: `deploy.yml` / `publish.yml` / `tenant-deploy.yml` / `jerv-gateway` is a deploy or publish verdict; a `gate` push run is ordinary CI sharing the SHA. `jerv-gateway` is the operator-host deploy leg: it has no run id to watch, so read its `deployNote` / `ledger.phases.deploy` — `pending` there means production was never deployed and blocks the next train run.
 - `foldStatus` + `foldNote` — the `hotfix-fold/<tag>` development PR; land it by true merge (Merge floor) and say whether it landed.
 - `announceNote` (Hub), `verifyNote`, `checkout`, `localSync`, `ledger` — the durable phase legs; a pending or failed leg is unresolved, never done.
 

package/skills/rcand/SKILL.md

@@ -49,7 +49,7 @@ Read the receipt at `$r`, never the exit code (exit `1` = the deploy failed afte
 
 - `promoted` — `true` even when the deploy failed; promotion and deploy are separate outcomes.
 - `tag` — the minted `vX.Y.0-rc.N`; `resumeNote` says an existing rc tag was resumed rather than minted.
-- `deployStatus` — `pending` is never terminal. `runId` / `runUrl` / `workflowRuns` name the run: the dispatched `tenant-deploy.yml` for tenant-container, the auto-fired `deploy.yml` for serverless. Watch each non-success entry to conclusion: `gh run watch <run-id> --repo {owner}/{repo} --exit-status`.
+- `deployStatus` — `pending` is never terminal. `runId` / `runUrl` / `workflowRuns` name the run: the dispatched `tenant-deploy.yml` for tenant-container, the auto-fired `deploy.yml` for serverless. Watch each non-success entry to conclusion: `gh run watch <run-id> --repo {owner}/{repo} --exit-status --interval 30`.
 - `releaseVerdict` — `followUpStatus` (`complete` · `pending` · `failed`) and one `legs` row per follow-up; a failed row carries its error.
 - `checkout`, `localSync`, `ledger` — `checkout.status: returned` to `development` and phases-green, or the named reason it is not.
 

package/skills/release/SKILL.md

@@ -76,7 +76,7 @@ Read the saved result, never the exit code (exit `1` = a follow-up failed after
 - `releaseVerdict.releaseStatus` + `followUpStatus` — `succeeded` + `pending` is shipped with the follow-up unresolved: neither failed nor done. A `--resume` receipt carries the same `releaseVerdict` (`command: release-resume`), plus its own `mode` and `state`.
 - `deployStatus` — `pending` is never terminal; `promoted: true` holds even when a deploy failed.
 - `served-channel(<product>)` row — the release's proof that new installs get it: the public `/release/version` pointer of the releasing repo's OWN channel (the Hub's `mmi`, or the product its registry `installer` declaration names; no declaration → no row), read after deploy and publish are green. `success` names the version read. `failure` is either a channel still on the previous version or a stale served process (the route answers 401/404): the note names what moves that channel and the exact remedy; run it, then re-read the pointer. `pending` means not probed (legs not green) or unreadable, never proof. The row is receipt evidence only, never a ledger leg, so it never blocks the next train.
-- `workflowRuns` — every run on the release SHA (deploy-model runs, any `push: main` deploy, the repo's own `gate`). Watch each non-success entry to conclusion: `gh run watch <run-id> --repo {owner}/{repo} --exit-status`. Name which run is red: `deploy.yml` / `publish.yml` / `tenant-deploy.yml` / `jerv-gateway` is a deploy or publish verdict; a `gate` push run is ordinary CI sharing the SHA.
+- `workflowRuns` — every run on the release SHA (deploy-model runs, any `push: main` deploy, the repo's own `gate`). Watch each non-success entry to conclusion: `gh run watch <run-id> --repo {owner}/{repo} --exit-status --interval 30`. Name which run is red: `deploy.yml` / `publish.yml` / `tenant-deploy.yml` / `jerv-gateway` is a deploy or publish verdict; a `gate` push run is ordinary CI sharing the SHA.
 - With `--watch` the train waits for its own alignment PR to land (true merge) and folds the ledger in the same run, so the receipt ends `succeeded` / `complete`. An external `gh run watch` never folds anything: if the receipt still shows a `pending` leg (no `--watch`, the alignment PR outlived the bounded wait, or a release-event `publish.yml` run on a registry-publish repo had not been correlated by the time the receipt was written — `--watch` waits for the alignment PR, not for that run, so a `publish` leg `pending` with no run URL after `--watch` is the expected direct-track shape, not a failure), fold it live before declaring the cut done or starting any new train: `mmi-cli devops release --resume --watch --json --out <fresh-receipt>`; the NEXT train's doctor otherwise refuses with `ledger-pending`.
 - `announceNote` — `announced` (to the alerts channel for the Hub, to the project release channel for a product repo), `skipped`, `not announced` (deploy or publish not green; the note says whether a `--resume` carrying the same `--announce-summary-file` will post it), or the failure note. The channel id itself is never printed.
 - `devRollForward` / `rcAlignment` — `pushed`, or `pr-pending` with the alignment PR to land by true merge (Merge floor). An enqueued auto-merge is not evidence of the method; before reporting, read the enqueued method back — `gh pr view <n> --json autoMergeRequest --jq .autoMergeRequest.mergeMethod` — and prove it is `MERGE`. An enqueued `SQUASH` is a stop under the Merge floor, not something to wait out.