@mutmutco/kilo-plugin 3.130.0 → 3.131.0

package/package.json

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

package/skills/hotfix/SKILL.md

@@ -18,9 +18,9 @@ The FIX is never back-merged: `development` already contains it, and `rc` absorb
 
 The VERSION FOLD is different, and `hotfix release` ports it for you (#4410). `hotfix start` commits the
 fold onto the main-base branch, so after the tag `main` declares the new version while `development`
-still declares the old one — and on a repo whose branch-pinned files carry that version (the Hub's
-`.claude-plugin/marketplace.json` pins plugin content to `main`) catalog-lockstep then reds **every** PR
-into development until it is ported. Step 3 opens that development-base fold PR automatically; land it.
+still declares the old one. The Hub's catalogs now pin exact npm packages (#4948), so there is no
+branch/content lockstep red; the fold still must land so the next release starts from production's real
+version, BOM, and package pins. Step 3 opens that development-base fold PR automatically; land it.
 
 ## Merge floor (#3167 — non-negotiable)
 
@@ -144,19 +144,17 @@ merged into `development`; the fold is regenerated on a branch cut from `develop
 reported `development fold port FAILED`, follow the manual remedy it named; never improvise a merge from
 `main`.
 
-### Catalog-lockstep vs development prepare (#4517)
+### Development fold after a hotfix (#4517 / #4948)
 
-Hub docs catalog-lockstep refuses PRs into `development` that advance
-`.claude-plugin/marketplace.json` ahead of `origin/main`. That gate is correct for main-anchored catalog
-truth. When Publish-Truth / a version bump must advance the marketplace, do **not** land
-`release-distribution prepare` as a development PR — use this hotfix door:
+The Hub's thin catalogs now pin exact npm packages, so the old main-anchored catalog-lockstep gate is
+retired: an unreleased branch cannot deliver a package version the release train has not published.
+Hotfix versioning still belongs on the main-base train, never in an improvised development prepare PR:
 
 1. `mmi-cli devops hotfix start --from <merged-dev-pr-or-sha>` (prepare + distribution bump on `hotfix/vX.Y.Z` from `main`)
 2. merge the hotfix PR → `mmi-cli devops hotfix release vX.Y.Z` (publish)
 3. land the automatic `hotfix-fold/<tag>` development fold PR (or follow its printed remedy)
 
-A development prepare PR that only exists to move marketplace ahead of main will keep failing
-catalog-lockstep; that is not a false red — switch to the hotfix path above.
+The fold is now required for version/BOM/package-pin continuity, not to clear a branch-content gate.
 
 ## Retro
 

package/skills/onboard/SKILL.md

@@ -24,15 +24,14 @@ first gap:
 - **Board** — is the Project board reachable, and how many items are on it.
 - **Registry** — is the repo registered in the Hub (`PROJECT#<slug>` META).
 - **Secrets** — is a GitHub token available for the vault path.
-- **Plugin** — will this machine ever pick up a new MMI plugin release, and from which branch (#3485).
-
-The **Plugin** row is the one nothing else catches, and it is per machine, not per repo. Claude Code
-leaves auto-update **off** for third-party marketplaces, and a marketplace registered with no
-`source.ref` serves its catalog from the repo's default branch while pinning plugin content to `main`.
-Both are hand edits in the developer's own Claude config — org tooling deliberately does not write them
-(owner ruling on #3485) — so a machine nobody tells stays silently a release behind from day one. The row
-names both fixes verbatim; it never takes `Next command`, because a stale plugin does not stop the work in
-front of you.
+- **Plugin** — is `mmi-updater` the single writer, and does its journal show every present surface at
+  the gated fleet version (#4945).
+
+The **Plugin** row is per machine, not per repo. The Hub's thin Claude/Codex catalogs pin exact npm
+packages; Git no longer transports plugin content, and background marketplace auto-update stays **off**
+so it cannot race the scheduled updater. The updater gates a release tag+BOM, converges each present host,
+and writes the journal stamp (`fleet <V> ✓`). A red row names `mmi-updater verify` or
+`mmi-updater reconcile`; no marketplace ref or hand-edited auto-update ceremony remains.
 
 A `✗` on any line comes with a `Next command:` — run **that** first. Common ones:
 

package/skills/release/SKILL.md

@@ -313,7 +313,13 @@ git tag "$TAG"
 
 `mmi-cli devops 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
+post-release follow-up failed after promotion — **or that the follow-up is merely unresolved** (#4939):
+a verdict of `releaseStatus=succeeded` with `followUpStatus=pending` (the release-triggered runs — e.g.
+the Hub's `deploy.yml` + `publish.yml` — had only just auto-fired) also exits nonzero, and a
+background-task harness surfacing exit codes misreads it as "release failed" when the release actually
+shipped. Classify from the verdict fields, never the exit code alone: `succeeded` + `pending` means
+shipped with the follow-up unresolved — watch the enumerated `workflowRuns` to conclusion; only a
+resolved failure there is a failed follow-up. 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.
 
@@ -499,7 +505,10 @@ mmi-cli oracle org project sync-info --apply   # omit --apply for the read-only
 
 ## Step 6 — collect deploy verdict + report
 
-The `release --apply` exit code is **not** the release verdict. Report the live release verdict from
+The `release --apply` exit code is **not** the release verdict. A nonzero exit with
+`releaseStatus=succeeded` and `followUpStatus=pending` is the unresolved-follow-up case from Step 3 —
+the release shipped; the runs enumerated in `workflowRuns` are the outstanding verdict, so watch them
+to conclusion here rather than re-running or alarming. 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.