@mutmutco/claude-plugin 4.0.16 → 4.0.18

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "mmi",
   "displayName": "MMI",
-  "version": "4.0.16",
+  "version": "4.0.18",
   "mmiCompat": "4.x",
   "description": "MMI workflow skills and org gates delivery.",
   "author": {

package/package.json

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

package/skills/bootstrap/seeds/gate.template.yml

@@ -59,6 +59,15 @@ jobs:
       run: { working-directory: {{GATE_WORKDIR}} }
     steps:
       - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
+      # #5427: per-job npm cache under $RUNNER_TEMP — never the shared ~/.npm. Twelve mmi-live lanes
+      # share the gha-runner home; npm hardlinks from that cache into node_modules, so one job's
+      # `npm ci` can make another job's vitest/dist/workers/forks.js vanish mid-suite (Cannot find
+      # module). Job-local cache ⇒ no cross-job hardlinks. Must land BEFORE setup-node (`cache: npm`
+      # follows `npm config get cache`). Job-level `env:` cannot use the `runner` context — write
+      # via GITHUB_ENV from the shell `$RUNNER_TEMP` instead.
+      - name: Isolate npm cache (per-job)
+        shell: bash
+        run: echo "NPM_CONFIG_CACHE=$RUNNER_TEMP/npm-cache" >> "$GITHUB_ENV"
       # MMI-Hub#5111: Windows CRLF in tracked shell scripts breaks Linux runners before the real
       # check can explain it. Inspect only tracked files before install; .gitattributes is the fix.
       - name: Line-ending guard

package/skills/mmi-resume/SKILL.md

@@ -108,6 +108,11 @@ janitor prose. Catalog: `docs/Architecture/compute-at-read.md` (in MMI-Hub).
 | Docs index freshness | `mmi-cli oracle docs index --check` |
 | Path / symbol / meaning pointers | `mmi-cli oracle repo-index search <q>` (Hub cloud; `--semantic` optional) |
 
+**Code orientation after a handoff (#5420):** a memory handoff orients by story, not by structure. Route
+cross-repo “where does X live / how does Y flow” questions through `mmi-cli oracle find <q>` (semantic) or
+`mmi-cli oracle repo-index search <q>` (hybrid) as the first-class step — before trusting recall or grepping a
+host-native index — and open the cited source to verify a pointer hit before acting on it.
+
 ## Notes
 
 - `/mmi-resume` is read-only session orientation. It never claims, moves, or writes.

package/skills/onboard/SKILL.md

@@ -66,8 +66,11 @@ mmi-cli oracle repo-index status --cloud                        # is the estate
 ```
 
 Host indexes (Cursor / Kilo) stay local helpers; **Hub `repo-index` is the org SSOT structure door**.
-Living current-state still comes from live verbs (`org schedules`, `board read`, …) — see
-`docs/Architecture/compute-at-read.md`. Do not invent wiki prose from pointer hits.
+After any memory handoff, cross-repo code-orientation questions go through `mmi-cli oracle find <q>` (semantic)
+or the `repo-index search` door above as the first-class step (#5420), and every pointer hit gets verified
+against the cited source before you act on it. Living current-state still comes from live verbs
+(`org schedules`, `board read`, …) — see `docs/Architecture/compute-at-read.md`. Do not invent wiki prose
+from pointer hits.
 
 ## Notes
 

package/skills/rcand/SKILL.md

@@ -57,8 +57,11 @@ primary checkout.
 
 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
---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;
+--porcelain` on the paths it named and read both columns. For `?? .jerv/` / `?? .pi/` (org-managed agent
+scratch), run `mmi-cli doctor --apply` to write the managed `.gitignore` block — do not hand-edit
+`.gitignore` (#5409). The train CLI already ignores those live-session dirs (#5397); doctor is the durable
+heal so `git status` stays clean. For other `??` scratch, gitignore it (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).
@@ -125,7 +128,13 @@ Required status checks are **per-repo branch protection, not a fixed list** —
 SHA has no check-runs yet, so when checks ARE required, pushing the branch *first* is structurally rejected
 until CI catches up (it then succeeds on a retry — avoidable noise). Push the **tag first**: it lands the
 SHA and triggers the repo's CI without touching the protected branch ref. Then probe what `rc` actually
-requires and wait only for those contexts:
+requires and wait only for those contexts.
+
+**Preflight (#5428):** before the immutable tag, `mmi-cli devops rcand --apply` inspects each required
+context's workflow `on:` triggers. If a required context (e.g. `py-gate` / `web-gate`) is pull_request-only
+and cannot fire on a tag push, the train **refuses before tagging** with a teaching error — never publish a
+candidate tag then wait on an event that cannot fire. Fix the gate to also trigger on `push: tags: ['v*']`
+(see MMI-Hub `gate.yml`), or remove those contexts from the rc ruleset (`ci audit` / reconcile).
 
 ```bash
 git push origin "vX.Y.0-rc.N"                 # lands the SHA + triggers the repo's CI

package/skills/release/SKILL.md

@@ -38,6 +38,9 @@ nothing deploys before the protected `main` push accepts that checked SHA.
   branch's lineage and every tag-anchored check (coverage trailers, misalignment guard, version probes)
   re-flags or mis-reads forever after. Any merge that carries an already-tagged commit — the Step 5
   `main → development` roll-forward, any alignment PR — lands as a **true merge** (`--merge`), never squash.
+  `--wait` does not relax this: use `mmi-cli devops pr merge <n> --wait --merge` (or the policy-gated
+  `--auto --merge`). `--wait` alone still defaults the CLI merge method to squash and must not land an
+  alignment / tagged-commit-carrying PR.
 - **A refused train is a stop, never a license to finish by hand.** Every fail-closed halt below — authority
   probe, coverage guard, untolerated conflict, required checks, stray tag — ends the run. The recovery is
   always to fix the cause and re-run the train; it is never hand-resolving on `main`, bare-pushing a train
@@ -109,7 +112,10 @@ The clean-tree check rejects UNTRACKED scratch too, not just modified tracked fi
 `--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.
+- `??` — untracked scratch. For `?? .jerv/` / `?? .pi/` (org-managed agent scratch), run
+  `mmi-cli doctor --apply` to write the managed `.gitignore` block — do not hand-edit `.gitignore`
+  (#5409). The train CLI already ignores those live-session dirs (#5397); doctor is the durable heal.
+  For other `??` paths, gitignore them, or move them 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>`
@@ -294,7 +300,8 @@ why (a hotfix freezes a snapshot that `development` can keep rewriting).
 Alignment PRs are the exception to the org's squash default: land them with a true merge —
 `mmi-cli devops pr merge <n> --auto --merge` (not squash; a squash discards the merge parentage, so the
 misalignment guard re-flags the same divergence on the next run). `--auto` clears the checks the PR
-triggers, which block an immediate merge right after a release.
+triggers, which block an immediate merge right after a release. When awaiting checks inline, keep
+`--merge`: `mmi-cli devops pr merge <n> --wait --merge` — `--wait` alone is not enough (merge floor above).
 
 **Exception — version-manifest and `.gitignore` paths.** `mmi-cli devops release --apply` tolerates
 conflicts confined to the version-fold paths (Step 1b) and `.gitignore` (#1037 — a
@@ -506,6 +513,12 @@ correct). Read the model from the registry (`mmi-cli oracle org project get {own
 - **repository-owned serverless / registry-publish** (e.g. Jerv-PowerTools' `Deploy Jerv Memory`) — there is
   no `runtime tenant redeploy` for these; re-run the repo's OWN declared `workflow_dispatch` deploy workflow at
   the promoted-equivalent ref: `gh workflow run <deploy-workflow> --repo {owner}/{repo} --ref <ref>`.
+- **hub-serverless** (MMI-Hub) — when `deploy.yml` fails the repo-index v4 readiness gate (`stale-commit` /
+  not-ready authorities), the promoted ref is fine; repair cloud v4 authorities first (#5405). List failing
+  authorities with `mmi-cli oracle repo-index status --cloud`, run
+  `mmi-cli oracle repo-index sync-estate --repo <owner/repo>` for each, re-probe with
+  `mmi-cli oracle repo-index health --live --queries-only`, then `gh run rerun --failed` on the failed
+  deploy run. Do not re-tag.
 
 Name the sanctioned dispatch mechanism you used in the train report.
 
@@ -529,7 +542,8 @@ mmi-cli oracle org project sync-info --apply   # omit --apply for the read-only
   PR with a true merge** — `mmi-cli devops pr merge <number> --auto --merge` (never squash — a squash drops the merge
   parentage and the misalignment guard re-flags the divergence). `--auto` is what makes it land right after a
   release: the alignment PR's own `cli`/`infra`/`docs` checks are still running, so a plain immediate merge is
-  policy-blocked — `--auto` merges once they pass. Never force.
+  policy-blocked — `--auto` merges once they pass. If you await with `--wait` instead, still pass `--merge`
+  (`mmi-cli devops pr merge <number> --wait --merge`); `--wait` alone must not land the alignment PR. Never force.
 - Full-track repos: `mmi-cli devops release --apply` already aligned `rc` to the released `main` (#1036 — the
   push runs inside the authority-gated train; the result reports it as `rcAlignment`). No manual `rc`
   push — if the result reports a failed alignment, investigate and rerun via the train, never bare-push.