@mutmutco/codex-plugin 4.3.27 → 4.3.29

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "mmi",
-  "version": "4.3.27",
+  "version": "4.3.29",
   "mmiCompat": "4.x",
   "description": "MMI workflow skills and org gates delivery.",
   "author": {

package/package.json

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

package/skills/stage/SKILL.md

@@ -29,9 +29,20 @@ facts all live in the Hub registry — no repo-local control-plane file.
 **Secrets are vault-native — no `.env` on disk (#2655).** The org forbids *using* `.env` files, not just
 committing them. A repo **without** `.env.example` stages vault-native: `mmi-cli stage --apply` resolves the
 declared dev runtime secrets (registry `requiredRuntimeSecrets[dev]`) from the vault and injects them straight
-into the compose **process environment** — the compose file reads them via `environment:` passthrough, and no
-secret ever touches disk. A repo that still ships `.env.example` keeps the legacy `.env` bootstrap for
-back-compat until its compose migrates to passthrough; new repos should ship **no** `.env.example`.
+into the compose **process environment**, which Compose interpolates the file with — no secret ever touches
+disk. A repo that still ships `.env.example` keeps the legacy `.env` bootstrap for back-compat until its
+compose migrates to passthrough; new repos should ship **no** `.env.example`.
+
+**Runtime env reaches the container through the generated passthrough (#6345).** Interpolation is not
+delivery: a container receives only what its own `environment:` declares. So `/stage` mirrors the box deploy —
+it generates `tmp/stage/runtime-env.override.yml` (gitignored, **key names only**, values stay in the process
+env) passing every runtime key through to each service the compose marks `labels: {"mmi.runtime-env": "true"}`,
+and loads it beside `docker-compose.yml` for the whole stage. Mark the app service with that label; a repo
+that hand-declares its variables needs nothing. Unmarked sidecars (db, cache) keep getting only what they
+interpolate themselves. Never wrap an individual `docker compose` call in `mmi-cli vault secrets use` to work
+around a missing value (#6344) — that value is scoped to the one child process it wraps, so the next `docker
+compose logs`/`down` fails the same `required variable … is missing a value`. Declare the key in registry
+`requiredRuntimeSecrets[dev]` and let `/stage` carry it across the whole lifecycle.
 
 **Build-time secrets (#5381).** When META declares `requiredBuildSecrets` (e.g. Katip's
 `NODE_AUTH_TOKEN=@github-packages-token` for `@mutmutco/fofu-ds` on GitHub Packages), `/stage` injects those
@@ -108,7 +119,9 @@ Stop the stage when the work is done, before switching context, or before replac
 If the user clearly wants the preview to stay up, leave it running and report that. The next `/stage` also
 stops the previous recorded stage before starting, so a stale server does not linger between runs. For the
 registry-derived Docker Compose default, stop also runs the recorded compose teardown (`docker compose down`)
-from the original stage working directory.
+from the original stage working directory. Stop re-fetches the declared dev runtime secrets so that `down`
+can interpolate the same file (`${POSTGRES_PASSWORD:?}`, `${PORT:?}`) — secrets never come from the state
+file (#6351). A vault-native repo with no `.env` gets `PORT` defaulted to the bound stage port.
 
 ## /stage --live — personal cloud dev stage