@mutmutco/kilo-plugin 3.129.0 → 3.131.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mutmutco/kilo-plugin",
-  "version": "3.129.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/rcand/SKILL.md

@@ -100,8 +100,8 @@ exists — a tag minted before the conflict resolution points at the wrong SHA.
 ## Step 3 — tag the rc
 
 The shared helper derives the next rc tag from existing tags (re-run-safe — `-rc.N` increments). `rc` mode
-requires `MMI_BUMP_INTENT` (PATCH is `/hotfix`-only, so a planned release is `minor` or `major`; the train
-refuses without it):
+reads `MMI_BUMP_INTENT`; unset it resolves to `patch` (#4929) — declare `minor`/`major` explicitly for a
+planned feature cycle:
 ```bash
 TAG=$(MMI_BUMP_INTENT=minor node scripts/next-version.mjs rc)   # -> vX.Y.0-rc.N
 git tag "$TAG"
@@ -191,11 +191,10 @@ Version `vX.Y.0-rc.N` · merged commits · rc deploy run + env URL.
 - **MAJOR / exact-target cycle:** for a release the tag math can't derive (a MAJOR like `2.0.0`, or skipping
   a version already on npm), export `MMI_RELEASE_VERSION=X.Y.Z` before `/rcand` — `next-version.mjs rc` then
   opens that exact cycle (validated to move strictly forward). Keep it exported through `/release`.
-- **`MMI_BUMP_INTENT=major|minor|patch` is required for `next-version.mjs rc`** (Step 3) — it selects the
-  increment for an ordinary release and is never inferred; absence is a hard refusal, not a default.
-  **Export it for the whole run:** `mmi-cli devops rcand --apply` resolves the intent itself and refuses
-  mid-train with the same message, so passing it only as a one-off prefix on the `next-version.mjs` command
-  leaves the apply to fail after the preflight has already passed. This is
+- **`MMI_BUMP_INTENT=major|minor|patch` selects the increment for `next-version.mjs rc`** (Step 3); absent,
+  it defaults to `patch` (#4929). **Export it for the whole run:** `mmi-cli devops rcand --apply` resolves
+  the intent itself with the same default, so a one-off prefix on the `next-version.mjs` command leaves the
+  apply deriving a different increment than the tag you minted. This is
   a different knob from `MMI_RELEASE_VERSION` above: `MMI_BUMP_INTENT` picks the increment,
   `MMI_RELEASE_VERSION` overrides the computed version entirely and is for the exceptional case only.
 

package/skills/release/SKILL.md

@@ -5,6 +5,11 @@ description: Ship rc or direct-track development to main and production.
 
 **Host-native invocation:** Claude `/mmi:release` · Codex `$mmi:release` · jervcode/Kimi `/skill:release` · Kilo `skill` tool. A backticked `/name` in this doc names the matching workflow (this skill or a sibling), not a literal command.
 
+**Argument (#4929):** `/release minor`, `/release major`, or `/release patch` — a bare bump word, never a
+`--flag` or env var. Map it to `MMI_BUMP_INTENT` exported for the whole run (the train and
+`next-version.mjs` both read it). No argument → `patch`: a `/release patch` from development is a
+legitimate ordinary release; `/hotfix` remains the cherry-pick promotion lane.
+
 # /release — ship to main + prod
 
 Full-track repos ship **exactly what is on `rc`** (never pulls `development`): merge `rc → main`, tag
@@ -56,9 +61,13 @@ mean "unverified", never an authority verdict:**
   denial, and retrying will never change it: fix the `{owner}/{repo}` argument, then re-probe. Before the
   fix this string came back `role: master, train: true, verified: true` for anything owner/name-shaped.
 
-- An `unknown command 'org'` error is a STALE CLI — the `org` namespace ships in newer trains, so an old
-  installed CLI can't even parse the probe. Jump to Step 0a, heal the CLI, then re-run this probe; never
-  conclude the command form is wrong from a pre-heal failure (#3150).
+- An `unknown command 'oracle'` error is a STALE CLI — the house-prefixed namespaces ship in newer
+  trains, so an old installed CLI can't even parse the probe. Jump to Step 0a, heal the CLI, then re-run
+  this probe; never conclude the command form is wrong from a pre-heal failure (#3150). The mirror-image
+  failure is a Wave-3 flat alias on a CURRENT CLI: the un-housed `org …`, `secrets …`, and
+  `release …` forms were removed in #4316 and fail closed with a house-prefix error — rewrite to the
+  house form (`mmi-cli oracle org …`, `mmi-cli vault secrets …`, `mmi-cli devops release …`); that is
+  never a stale CLI and never an authority verdict.
 - A **TIMEOUT or network error** (`operation aborted due to timeout`, DNS/socket failures) is **not** a
   `train: false` denial (#3321). Read the probe's own `verified` field: `verified: false` means the verdict
   could not be established, so the `train: false` beside it carries NO authority meaning. The client
@@ -70,8 +79,10 @@ mean "unverified", never an authority verdict:**
 
 Then
 preconditions: clean tree; full-track repos run from `rc` (or from `development` with `--dev`), while
-direct-track repos run from `development`. Ordinary `/release` also needs `MMI_BUMP_INTENT=minor|major`
-exported in the apply environment (patch is `/hotfix`); the train does not infer an open cycle.
+direct-track repos run from `development`. Ordinary `/release` takes its bump intent from the bare
+argument (`/release minor|major|patch` → `MMI_BUMP_INTENT`, exported for the whole run); unstated, the
+train defaults to `patch` (#4929). An invalid intent fails `--apply` closed at intent resolution
+(`MMI_BUMP_INTENT must be one of major|minor|patch`), before any merge, tag, or fold.
 
 **Run from the checkout that already has that branch — never a fresh isolated worktree (#2770).** This is
 a shared-branch train operation (merge/tag/push against origin's protected `main`/`rc`), not an isolated
@@ -288,8 +299,10 @@ Nothing to do by hand; the `--apply` result reports the fold outcome (`versionFo
 ## Step 2 — tag the release
 
 Full-track repos drop the `-rc.N` suffix from the open cycle. Direct-track repos use the next cycle directly
-because they have no rc tag — and `cycle` mode requires `MMI_BUMP_INTENT` (PATCH is `/hotfix`-only, so a
-planned release is `minor` or `major`; the train refuses without it):
+because they have no rc tag — `cycle` mode reads `MMI_BUMP_INTENT` (the `/release` argument; unset →
+`patch`, #4929). The Step 0 export is what covers the apply run — the inline prefix below only resolves
+the tag for display; `mmi-cli devops release --apply` re-derives intent itself and fail-closes before any
+merge, tag, or fold when the value is invalid:
 ```bash
 TAG=$(node scripts/next-version.mjs release)                  # full-track repos -> vX.Y.0
 TAG=$(MMI_BUMP_INTENT=minor node scripts/next-version.mjs cycle)   # direct-track repos -> vX.Y.0
@@ -300,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.
 
@@ -486,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.
@@ -546,12 +568,15 @@ deploy run + URL + **green/red** · branch-alignment note · npm publish run + C
 
 ## Notes
 
-- PATCH-level releases are `/hotfix` only (a hotfix always skips rc — it cherry-picks `development → main`
-  directly); planned releases are MINOR or MAJOR. Never force-push `main`.
-- **`MMI_BUMP_INTENT=major|minor` is required in the apply environment for ordinary `/release`** (patch is
-  `/hotfix`). Absence is a hard refusal — the train never infers an open cycle. Export it for the whole
-  run, not a one-off prefix on `next-version.mjs cycle`: `mmi-cli devops release --apply` (and `rcand
-  --apply`) resolve intent themselves and refuse mid-train if the env is missing. `MMI_RELEASE_VERSION`
+- `/hotfix` stays the cherry-pick promotion lane (a hotfix always skips rc — it cherry-picks
+  `development → main` directly), but a `/release patch` from development is a legitimate ordinary
+  release (#4929). Never force-push `main`.
+- **`MMI_BUMP_INTENT=major|minor|patch` comes from the bare `/release` argument; unstated it defaults to
+  `patch`** (#4929). Export it for the whole run, not a one-off prefix on `next-version.mjs cycle`:
+  `mmi-cli devops release --apply` (and `rcand --apply`) resolve intent themselves **before any merge,
+  tag, or fold** — direct-track included — defaulting to `patch` when the env is absent and failing closed
+  there with `MMI_BUMP_INTENT must be one of major|minor|patch` on an invalid value, so the tree stays
+  clean on the start branch. `MMI_RELEASE_VERSION`
   below is a different knob: it overrides the computed version; it does not replace the intent export
   unless you set that exact-target env instead.
 - **`--dev` (full-track only):** releases `development → main` skipping rc, with the same fold/tag/Release/
@@ -561,8 +586,8 @@ deploy run + URL + **green/red** · branch-alignment note · npm publish run + C
 - **MAJOR / exact-target release:** to ship a version the tag math can't derive (a MAJOR like `2.0.0`, or
   skipping a version already on npm), product repos export `MMI_RELEASE_VERSION=X.Y.Z` for **both** `/rcand`
   and `/release`; MMI-Hub exports it for `/release` only. Steps 1b/2 then fold and tag exactly that
-  version. Unset, the train uses the declared `MMI_BUMP_INTENT` increment — it does not infer an open
-  cycle, and apply fail-closes if that env is also missing.
+  version. Unset, the train uses the declared `MMI_BUMP_INTENT` increment, defaulting to `patch` when
+  neither the argument nor the env declares one (#4929).
 
 ## Retro — one check before you finish
 Before your final report, answer one question honestly: did **this skill's own instructions** misfire