@mutmutco/codex-plugin 4.3.7 → 4.3.8

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "mmi",
-  "version": "4.3.7",
+  "version": "4.3.8",
   "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.7",
+  "version": "4.3.8",
   "description": "MMI workflow skills and org gates delivery.",
   "author": {
     "name": "MMI Future",

package/skills/bootstrap/SKILL.md

@@ -541,7 +541,9 @@ mmi-cli devops train doctor --lane release --repo "$OWNER/$REPO" --json
 
 `ready: true` is the bootstrap's train-readiness proof; every finding carries `code`, `severity`, `source`,
 `remedy` and a `docs/Guides/train-troubleshooting.md#<code>` anchor. A full-track repo runs
-`--lane rcand` as well. A `bootstrap-gap` blocker names the apply row still missing.
+`--lane rcand` as well. A `bootstrap-gap` finding names the apply row still missing — a blocker for a
+train branch absent on origin, a warning for a stage with no required status check (#6136): read the
+warnings too, `ready: true` alone does not prove the product ruleset is active.
 
 ## Retro — one check before you finish
 Before your final report, answer one question honestly: did **this skill's own instructions** misfire

package/skills/epic/SKILL.md

@@ -50,9 +50,9 @@ Write a JSON array (one object per child) to a scratch path under `.jerv/tmp/`.
 
 - `type` — `bug` · `feature` · `task` (required; maps to the repo's issue-template label).
 - `title` — required, non-empty; keep it a short, greppable deliverable.
-- `parent` — the umbrella ref (`#N`, `owner/repo#N`, or URL); links each child as a native sub-issue on
-  create, so you do not need a separate `link-child` pass. Cross-repo is fine (a Hub umbrella can parent
-  product-repo children).
+- `parent` — the umbrella ref (`N` or `#N` as a string, a bare JSON number, `owner/repo#N`, or
+  URL); links each child as a native sub-issue on create, so you do not need a separate `link-child`
+  pass. Cross-repo is fine (a Hub umbrella can parent product-repo children).
 - `priority` — `urgent|high|medium|low` (defaults to `medium`); sets the board Priority **field**.
 - `repo` — optional per-row target repo (`owner/repo`); defaults to `--repo`, then the current repo.
   This is how one batch fans children out across repos under a single umbrella.

package/skills/hotfix/SKILL.md

@@ -65,7 +65,7 @@ MMI-Hub adds `--announce-summary-file "$f"` with a fresh 3–6 line neutral summ
 
 Read the receipts, never the exit code (exit `2` = a follow-up pending; exit `1` = a follow-up failed after the tag):
 
-- `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` is a deploy or publish verdict; a `gate` push run is ordinary CI sharing the SHA.
+- `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.
 - `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.