@mutmutco/kilo-plugin 3.129.0 → 3.130.0

package/package.json

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

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
@@ -546,12 +559,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 +577,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