@mutmutco/kilo-plugin 3.130.0 → 3.132.0

package/package.json

@@ -1,6 +1,7 @@
 {
   "name": "@mutmutco/kilo-plugin",
-  "version": "3.130.0",
+  "version": "3.132.0",
+  "mmiCompat": "3.x",
   "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/mmi/SKILL.md

@@ -53,16 +53,13 @@ Still run it in the foreground and wait. The lock stops corruption, not confusio
 that reports "skipped — lock busy" has healed nothing, and an agent that does not read that line will
 carry on believing its tooling was fixed.
 
-`doctor --no-repo-writes` heals a stale npm global or a stale/unresolved plugin install (the **env**
-half of the interactive doctor, #3485/#3975) — it never touches the repo working tree. When it prints
+`doctor --no-repo-writes` heals a stale/unresolved plugin install (the **env** half of the interactive
+doctor, #3485/#3975) — it never touches the repo working tree. When it prints
 `↻ Updating mmi tooling, one moment…`, relay that before waiting; when it prints `↻ MMI tooling
 updated — …`, relay the reload/restart guidance.
 
 What the env half heals:
 
-- a behind npm global → `npm install -g @mutmutco/cli@<released version>`, pinned, never the floating
-  `@latest`, which npm can resolve off a cached packument and reinstall the stale version right after a
-  publish (#3422). Effective on the next invocation.
 - a stale or unresolved Claude plugin → `claude plugin marketplace remove mmi` → `… remove mutmutco` →
   `claude plugin marketplace add mutmutco/MMI-Hub` → `claude plugin install mmi@mutmutco`. A fresh
   reinstall, never `claude plugin update`, which nests into itself past MAX_PATH on Windows and wipes the
@@ -72,6 +69,10 @@ What the env half heals:
   docs/doctor-contract.md § Guarded cache prune): never the running/newest/installed version, a cache a
   live session holds is named "still held" and never forced.
 
+What it does **not** do since #4954: install anything. A behind npm global is REPORTED (the `mmi-cli`
+row names `npm install -g @mutmutco/cli@<released>`) and the `fleet` row reads the scheduled
+`mmi-updater`'s journal — that reconciler is the single writer of CLI and plugin versions.
+
 - **Fast path** → `whoami` then `board read`; no foreground doctor.
 - **Hard setup signal** → run `doctor --no-repo-writes`, relay `↻` lines, then retry `board read` when appropriate.
 - **`mmi-cli: command not found`** → plugin PATH provisioning has not applied, or the standalone CLI is not installed.

package/skills/mmi-doctor/SKILL.md

@@ -13,10 +13,15 @@ One command. Run it when a session opens messy or before a handoff.
 mmi-cli doctor
 ```
 
-By default this **heals and cleans** (MMI-Hub#3975): CLI/plugin/marketplace env repairs, managed
-`.gitignore`, merged-branch / dead-worktree reap (including deferred IDE-locked removals), light board
-mechanical fixes, docs-index working-tree heal, and related full-lane checks. Secrets stay **out** of
-default doctor — use `mmi-cli vault secrets diff` when you need a catalog gap check.
+By default this **heals and cleans** (MMI-Hub#3975): plugin env repairs, managed `.gitignore`,
+merged-branch / dead-worktree reap (including deferred IDE-locked removals), light board mechanical
+fixes, docs-index working-tree heal, and related full-lane checks. Secrets stay **out** of default
+doctor — use `mmi-cli vault secrets diff` when you need a catalog gap check.
+
+Doctor does **not** update the CLI or the host plugins (MMI-Hub#4954). The scheduled `mmi-updater`
+reconciler is the single writer of those versions; doctor only REPORTS — the `mmi-cli` row names the
+version gap and the `npm install -g @mutmutco/cli@<released>` that closes it, and the `fleet` row reads
+the reconciler's journal (installed / expected / drift per surface).
 
 ## Flags
 

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

@@ -125,7 +125,7 @@ git rev-list --count origin/main..origin/development
 
 Before local gates or `release --apply`, ensure the repo-local / PATH `mmi-cli` matches the released train
 path — a stale checkout (e.g. 2.32.0 while 2.32.4 is released) fails release gates with opaque errors.
-Self-heal in place without repo writes (heals run by default since #3975; the flag suppresses only
+Read the gap without repo writes (plugin/env repairs run by default since #3975; the flag suppresses only
 mutations of the working tree you are about to release from):
 ```bash
 mmi-cli doctor --no-repo-writes
@@ -136,10 +136,11 @@ inverse is also true: a run can exit **0** while printing ✗ lines (report-only
 direction is a gate. Read the rows.
 
 - **Blocking:** a red `mmi-cli` / `Claude plugin` version line, or a reported `minClientVersion` gap.
-  `--no-repo-writes` does not block the env heals — the step above self-updates the npm global CLI
-  (#3272) and reinstalls the plugin (#3282), suppressing only repo-file writes — so the re-run should clear
-  it. If a gap persists, fix it — `mmi-cli doctor`, or `npm install -g @mutmutco/cli` — before
-  continuing. Do **not** proceed to Step 0b while the installed CLI is behind the Hub's `minClientVersion`.
+  **Doctor does not update the CLI (#4954).** The scheduled `mmi-updater` owns npm installs now; doctor
+  REPORTS the lag (the `mmi-cli` row) and reads the reconciler's journal (the `fleet` row). So the remedy
+  here is the explicit install below — `npm install -g @mutmutco/cli@<released>` — not a doctor re-run.
+  `--no-repo-writes` still heals the plugin install (#3282), suppressing only repo-file writes. Do **not**
+  proceed to Step 0b while the installed CLI is behind the Hub's `minClientVersion`.
 - **Not blocking:** every other red check is hygiene, not a train gate. Stale branches and scratch heal with
   a plain `mmi-cli doctor` (after the release); `plugin cache` needs a different verb,
   `mmi-cli plugin prune --apply` — saying doctor cleared it was wrong. Both still exit 1 until you run the
@@ -313,7 +314,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 +506,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.