@mutmutco/kilo-plugin 3.83.0 → 3.84.0

package/package.json

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

package/skills/hotfix/SKILL.md

@@ -38,7 +38,11 @@ mmi-cli doctor --no-repo-writes
 ```
 
 Stop on a red authority or CLI-version result. The worktree must be clean; move scratch into `tmp/` or
-gitignore it rather than widening the hotfix diff.
+gitignore it rather than widening the hotfix diff. A TRACKED path named in a `working tree must be clean
+before …` refusal is not scratch: read both `git status --porcelain` columns, treat every state except
+exactly ` M` as real work to commit or stash, and for ` M` discard only when
+`git diff HEAD --numstat -- <paths>` is empty, and only with `git checkout -- <paths>`. Plain
+`git diff --numstat` prints nothing for a merely staged change, so it cannot make that call (#4004).
 
 ## 1. Start from the merged development fix
 

package/skills/rcand/SKILL.md

@@ -43,8 +43,12 @@ primary checkout.
 ## Step 1 — development ahead of rc?
 
 Preconditions: on `development`, clean tree. The clean-tree check rejects UNTRACKED scratch too, not just
-modified tracked files — if `--apply` stops with `working tree must be clean before …`, run `git status` and
-gitignore the `??` scratch (or move it to a gitignored path like `tmp/`) before retrying (#1472).
+modified tracked files — if `--apply` stops with `working tree must be clean before …`, run `git status
+--porcelain` on the paths it named and read both columns. Gitignore the `??` scratch (or move it to a
+gitignored path like `tmp/`). Treat every tracked state except exactly ` M` as real work to commit or stash;
+for ` M`, discard only when `git diff HEAD --numstat -- <paths>` is empty, and only with
+`git checkout -- <paths>`. Plain `git diff --numstat` prints nothing for a merely staged change, so it
+cannot tell real work from line-ending churn (#1472, #4004).
 ```bash
 git fetch origin
 git rev-list --count origin/rc..origin/development

package/skills/release/SKILL.md

@@ -72,9 +72,22 @@ breaks here: the new worktree's branch is never literally named `development`/`r
 development` inside it fails outright when `development` is already checked out in the primary checkout (git
 worktrees cannot have the same branch checked out twice). If you are in such a worktree, exit it first and
 run the release from the primary checkout.
-The clean-tree check rejects UNTRACKED scratch too, not just modified tracked files — if `--apply` stops
-with `working tree must be clean before …`, run `git status` and gitignore the `??` scratch (or move it to a
-gitignored path like `tmp/`) before retrying (#1472).
+The clean-tree check rejects UNTRACKED scratch too, not just modified tracked files. When `--apply` or
+`--resume` stops with `working tree must be clean before …`, run `git status --porcelain` on the paths it
+named and read BOTH status columns before touching anything (#1472, #4004):
+
+- `??` — untracked scratch. Gitignore it, or move it to a gitignored path like `tmp/`, then retry.
+- exactly ` M` (blank staged column) — the only state that can be churn rather than work. Test it with
+  `git diff HEAD --numstat -- <paths>`: non-empty is a real edit to commit or stash; empty means the
+  worktree normalizes straight back to HEAD (an LF↔CRLF rewrite, say), and `git checkout -- <paths>`
+  then clears the refusal without discarding anything.
+- anything else — `M `, `MM`, `A`, `D`, `R`, `T`, or any `U` conflict — is real work or an exceptional
+  index state. Commit, stash or resolve it; do not try to classify it.
+
+Do not substitute plain `git diff --numstat` for the `HEAD` form. It compares the worktree against the
+INDEX, so a change that is merely staged prints nothing at all, and reading that emptiness as
+"line-ending churn" throws the change away. The remedy is the index form of `git checkout` for the same
+reason: `git checkout HEAD -- <paths>` would overwrite a staged edit that was misread as churn.
 
 Full-track repos:
 ```bash
@@ -471,6 +484,19 @@ mmi-cli org project sync-info --apply   # omit --apply for the read-only plan
   channel — #3630 took SessionStart off the hook surface) runs the
   same fast-forward first thing, so a stale local `development`/`main`/`rc` self-heals to origin before you
   work — no manual `git pull`. Nothing here ever blocks or fails the release.
+- **Read the `checkout:` clause — it does not always say "returned" (#4006).** The report always prints
+  one, and restoration is deliberately skipped rather than forced when the repo is not in a fit state.
+  A release leaves the repo on `main` until the train moves it back, so a non-`returned` outcome means
+  you are still there and must return by hand once the cause is cleared:
+  - `checkout restoration skipped: working tree changed after release` — the tree went dirty DURING the
+    train, so the train declined to move you. Diagnose those paths with the Step 0 clean-tree rules,
+    then `git checkout <start branch>` yourself. The release itself already shipped; this is a
+    deliberate, harmless decline, not a failed release.
+  - `checkout restoration failed while returning to …` / `origin/<branch> fast-forward failed` — the
+    checkout or the pull errored. Read the appended git message; the release is unaffected.
+
+  `--resume` prints no `checkout:` clause at all, so after a resumed release check `git branch
+  --show-current` rather than assuming you were moved back.
 
 ## Step 6 — collect deploy verdict + report
 
@@ -478,6 +504,10 @@ Collect the backgrounded prod-deploy watch from Step 4 (it has typically finishe
 healthy (the central deploy workflow smoke step / a health check); **red** → report the failure prominently and flag
 that the release shipped on a failed deploy (re-run just the deploy — `main` is already correct).
 
+**This distribution verifier is Hub-only.** It assumes the Hub release fold has already committed its
+generated artifacts. Non-Hub `registry-publish` repositories must not run `release-distribution.mjs
+verify`: use their own release-workflow evidence and the publish-visibility contract below.
+
 Hub releases always carry a distribution bump (the Step 1b fold), so the **publish workflow**
 (`publish.yml`) ships every registry-declared public npm artifact on the GitHub Release from Step 4 —
 don't publish by hand.