@mutmutco/kilo-plugin 3.105.7 → 3.105.9

package/package.json

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

package/scripts/hook-run.mjs

@@ -168,7 +168,14 @@ function adaptOutput(surface, stdout) {
   try {
     const payload = JSON.parse(stdout);
     const decision = payload?.hookSpecificOutput;
-    if (decision?.permissionDecision !== 'deny') return '';
+    // #4331: a gate that DECIDES anything other than deny must still leave cursor a parseable envelope.
+    // #4300 fixed the no-envelope path and stopped here, so an explicit `allow`/`ask` envelope still
+    // adapted to EMPTY stdout — the exact byte stream cursor's failClosed reader grades as a hook
+    // failure, denying the call the gate had just passed. Same no-op as the empty case: `{}` is
+    // cursor's documented "no decision, defer to the host". It must NOT become `permission: 'allow'`
+    // — on cursor only an explicit decision overrides the host's own permission flow, so that would
+    // auto-approve calls the user would otherwise be prompted for. Deny stays byte-identical below.
+    if (decision?.permissionDecision !== 'deny') return '{}\n';
     const reason = decision.permissionDecisionReason || 'MMI policy denied this tool call.';
     return `${JSON.stringify({ permission: 'deny', user_message: reason, agent_message: reason })}\n`;
   } catch {

package/skills/hotfix/SKILL.md

@@ -11,8 +11,14 @@ preserves the cherry-pick audit trail, and performs the PATCH release. Never aut
 Never author the fix on a branch off `main`. The main-base branch is only the orchestrated port of a fix
 that is already merged to `development`.
 
-There is no back-merge: `development` already contains the fix, and `rc` absorbs it at the next `/rcand`.
-The release hotfix-coverage guard blocks a later candidate that omits the production fix.
+The FIX is never back-merged: `development` already contains it, and `rc` absorbs it at the next
+`/rcand`. The release hotfix-coverage guard blocks a later candidate that omits the production fix.
+
+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.
 
 ## Merge floor (#3167 — non-negotiable)
 
@@ -49,9 +55,16 @@ exactly ` M` as real work to commit or stash, and for ` M` discard only when
 Use the orchestrator with an explicit source every time:
 
 ```bash
-mmi-cli hotfix start --from <development-pr-number-or-merge-sha> --json
+mmi-cli hotfix start --from <development-pr-or-sha>[,<development-pr-or-sha>...] --json
 ```
 
+**One hotfix cycle carries as many merged fixes as you name.** `--from` takes a comma-separated list in
+pick order, and every sha it picks goes into the PR's carries marker, so the release proves each one
+present before tagging. Do not open one hotfix per fix: batch everything ready for production into the
+single PATCH. A fix that only becomes ready mid-cycle rides the same tag — cherry-pick it with `-x` onto
+a `hotfix/<tag>-<n>` continuation branch, merge that PR, and rerun `hotfix release` with the full
+`--carries` list; the release pins the newest merged SHA (#1025).
+
 `hotfix start` resolves the PATCH version, branches from `origin/main`, performs the cherry-pick with `-x`,
 prepares Hub distribution artifacts when applicable (stamping BOM `sourceCommit` at the durable
 `origin/main` merge-base so a squash merge cannot orphan it — #4361; and for `registry-publish`
@@ -88,9 +101,12 @@ Derive the tag from `mmi-cli hotfix status`, then release with the same declared
 
 ```bash
 mmi-cli hotfix status
-mmi-cli hotfix release <vX.Y.Z> --carries <development-pr-number-or-merge-sha>
+mmi-cli hotfix release <vX.Y.Z> --carries <development-pr-or-sha>[,<development-pr-or-sha>...]
 ```
 
+Name **every** fix the cycle carries. Each is proven an ancestor of the tagged SHA before tagging; a
+missing one refuses the release and names the continuation path.
+
 For MMI-Hub, pass a fresh 2-4 line neutral summary file with `--announce-summary-file`; never reuse a
 stale file and never put a product or brand name in the summary. Hub release scope never includes another
 repo's board or `ds-propagate.yml`. The orchestrator creates the tag and GitHub Release, selects the
@@ -109,9 +125,13 @@ branch facts:
 - `main`: the tag commit is on `origin/main`.
 - `development`: the source fix was already merged before the hotfix began.
 - `rc`: intentionally untouched; the next release coverage gate prevents regression.
+- the development fold PR the release opened (`hotfix-fold/<tag>`), and whether it landed.
 
-Do not open a manifest-alignment or back-merge PR. This is explicitly NOT a back-merge: the next normal
-release folds version manifests and branch alignment.
+Do not hand-open a manifest-alignment PR: the version fold is already ported by `hotfix release` — land
+its PR instead of authoring one. That port is explicitly NOT a back-merge — nothing from `main` is
+merged into `development`; the fold is regenerated on a branch cut from `development` itself. If the run
+reported `development fold port FAILED`, follow the manual remedy it named; never improvise a merge from
+`main`.
 
 ## Retro
 

package/skills/mmi-doctor/SKILL.md

@@ -52,4 +52,4 @@ about? (Process only — never the user's code or task; e.g. a doctor run that p
 branch.) If yes, file **one** lesson and move on; a clean run is silent (hard cap: one per run). It
 lands on the Hub board (deduped) and is fixed only via a reviewed PR — never edit the skill live; the
 retro is advisory, so if the call fails, note it and continue:
-`mmi-cli skill-lesson --skill mmi-doctor --title "<what misfired>" --body "<what; evidence; proposed amendment>"`
+`mmi-cli skill-lesson --skill doctor --title "<what misfired>" --body "<what; evidence; proposed amendment>"`

package/skills/worktree/SKILL.md

@@ -41,10 +41,14 @@ open — never move it by hand.
 
 ```bash
 git push origin <branch>:<branch>              # explicit feature refspec — see below
-mmi-cli pr create --title "<title>" --body-file PR_BODY.md --base development
+mmi-cli pr create --title "<title>" --body-file .jerv/PR_BODY.md --base development
 mmi-cli pr checks-wait <PR-number>              # wait for required CI to go green
 ```
 
+Write the PR body under `.jerv/` (#4405), never at the worktree root. `.jerv/` is the agent-artifact
+prefix `worktree land` treats as removable; a stray untracked `PR_BODY.md` anywhere else classifies the
+tree as `untracked-files` and Step 4 then skips cleanup entirely.
+
 The push must be the explicit `<branch>:<branch>` refspec (the branch Step 1 derived, e.g.
 `git push origin 3795-my-slice:3795-my-slice`). The #1660 protected-push gate denies the
 `HEAD`/remote-only form (`git push -u origin HEAD`) — its target cannot be proven safe. And never
@@ -65,6 +69,16 @@ worktree, deletes the merged branch (local + origin), and prunes tracking refs.
 locked is queued and retried by `mmi-cli worktree gc sweep-deferred`. Self-authored merges need an explicit
 per-session merge grant — ask early if you don't have one.
 
+**`not-attempted (untracked-files)` (#3500 / #4405):** the usual cause of a merged PR that left its
+worktree behind. Any untracked path outside `.jerv/` — a hand-written `PR_BODY.md`, notes, a scratch
+script — makes removal refuse, because an unadded file can be real work. Delete or move the file, then
+re-run cleanup **from inside the worktree** (`worktree land` has no `--path`; it acts on the tree you
+are standing in):
+
+```bash
+mmi-cli worktree land --apply
+```
+
 **Cwd-safe land (#4140):** `worktree land --apply` (what `pr land` runs) is designed to be invoked from
 inside the worktree you are landing. Before removal it releases the process cwd to the primary checkout
 (#1444/#2747) — on Windows, leaving cwd inside the target tree makes `rmdir` fail with `EBUSY` and leaks