@mutmutco/kilo-plugin 3.87.0 → 3.89.0

package/package.json

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

package/skills/bootstrap/seeds/manifest.json

@@ -8,7 +8,7 @@
     { "target": ".github/ISSUE_TEMPLATE/config.yml", "source": "self", "ownership": "repo", "classes": ["deployable", "content"] },
     { "target": "scripts/next-version.mjs", "source": "self", "ownership": "org", "classes": ["deployable"] },
     { "target": ".github/workflows/gate.yml", "source": "seed:gate.template.yml", "ownership": "org", "classes": ["deployable"] },
-    { "target": ".github/workflows/agent-pr.yml", "source": "self", "ownership": "org", "classes": ["deployable"], "waivers": { "jerv-jervcode": "runs a hardened variant the org copy does not carry — pull_request_target off the trusted base branch, an immutable BASE..HEAD compare with a file-count equality wall, a repo-scoped App token, and a certified-head merge that re-asserts base/head/state. Its own scripts/workflow-boundary-core.test.mjs pins those properties, so a seed refresh both weakens the repo and reds its gate. Widen the org seed to match before lifting this (#4033)." } },
+    { "target": ".github/workflows/agent-pr.yml", "source": "self", "ownership": "org", "classes": ["deployable"], "waivers": { "jerv-jervcode": "pins this workflow's EXACT step shapes in its own scripts/workflow-boundary-core.mjs — a literal repositories: Jerv-JervCode token scope, and whole-step equality for the surface and verdict legs. #4040 widened the org seed to the same hardened boundary (pull_request_target off the trusted base, an immutable BASE..HEAD compare with a file-count equality wall, a per-repo App token scope, and a certified-head merge), so the two now agree on substance. They cannot agree on bytes: a seed serving 16 repos resolves its token scope and its required contexts at run time, which exact-step equality rejects by construction. The waiver is permanent by design, not a deferral — lifting it would mean weakening the strictest repo to match a fleet file." } },
     { "target": ".github/rulesets/mmi-product-required-checks.json", "source": "seed:mmi-product-required-checks.template.json", "ownership": "org", "classes": ["deployable"] },
     { "target": ".gitignore", "source": "managed-block", "ownership": "org", "classes": ["deployable", "content"] },
     { "target": "README.md", "source": "seed:README.template.md", "ownership": "repo", "classes": ["deployable", "content"] },

package/skills/release/SKILL.md

@@ -314,6 +314,12 @@ git tag "$TAG"
 
 ## Step 3 — push tag, wait for the REQUIRED checks, then push main (the gate)
 
+`mmi-cli release --apply`'s exit code is **not** the release verdict: exit `2` can mean the release
+shipped successfully while protected-branch alignment remains pending, and exit `1` can mean a
+post-release follow-up failed after promotion. Read the live release verdict and verify these four
+facts instead: the `main..development` count, the tag on `origin`, `gh release view`, and the runs on
+the release SHA.
+
 Required status checks are **per-repo branch protection, not a fixed list** — MMI-Hub's `main` requires
 `cli` · `infra` · `docs`, but a product repo may require different contexts or none at all (#1045). The
 release SHA is always fresh (the Step 1b fold commits on local `main`), so when checks ARE required,
@@ -500,6 +506,11 @@ mmi-cli org project sync-info --apply   # omit --apply for the read-only plan
 
 ## Step 6 — collect deploy verdict + report
 
+The `release --apply` exit code is **not** the release verdict. Report the live release verdict from
+the four checks that matter: the `main..development` count, the tag on `origin`, `gh release view`,
+and the runs on the release SHA; an alignment PR is normal follow-up work when those checks confirm
+the release shipped.
+
 Collect the backgrounded prod-deploy watch from Step 4 (it has typically finished by now). Confirm prod is
 healthy (the central deploy workflow smoke step / a health check); **red** → report the failure prominently and flag
 that the release shipped on a failed deploy (re-run just the deploy — `main` is already correct).