@mutmutco/pi-plugin 4.5.223 → 4.5.225

package/package.json

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

package/skills/board/SKILL.md

@@ -21,7 +21,7 @@ accepts an incomplete board. The CLI partitions rows into **Yours**, **Free to c
 stamps (4 hours without work) hold nothing. Partition rules, stamp details and `--out` rationale:
 [reference.md](reference.md).
 
-**Under the App pool, never type raw `gh` for a read** (`gh issue list/view --jq`, `gh run view --jq`, `gh api -q` all bounce). Use `MMI_ACTOR=app mmi-cli devops read issue view <n> --repo <owner/repo> --json <fields>` (or `issue list`, `pr view`, `run view`); `--jq '<expr>'` on that typed read filters locally. Filter in a pipe or save output (`>`, `2>&1`, `--out`) under this worktree's `.jerv/tmp/` (`mkdir -p .jerv/tmp` first), never `../` or a sibling path: the workspace output guard refuses those. Body edits are read-then-edit: `MMI_ACTOR=app mmi-cli devops read issue view <n> --repo <owner/repo> --json body > .jerv/tmp/issue-body.json`, append or filter the JSON locally (`node -e`; the typed read's own `--jq` also filters locally), then write back with `gh issue edit <n> --repo <owner/repo> --body-file .jerv/tmp/issue-body.md` — `gh` writes pass under the pool.
+**Under the App pool, never type raw `gh` for a read** (`gh issue list/view --jq`, `gh run view --jq`, `gh api -q` all bounce). Use `MMI_ACTOR=app mmi-cli devops read issue view <n> --repo <owner/repo> --json <fields>` (or `issue list`, `pr view`, `run view`); `--jq '<expr>'` on that typed read filters locally. Filter in a pipe or save output (`>`, `2>&1`, `--out`) under this worktree's `.jerv/tmp/` (`mkdir -p .jerv/tmp` first), never `../` or a sibling path: the workspace output guard refuses those. Body edits are read-then-edit: `MMI_ACTOR=app mmi-cli devops read issue view <n> --repo <owner/repo> --json body > .jerv/tmp/issue-body.json`, append or filter the JSON locally (`node -e`; the typed read's own `--jq` also filters locally), then write back with `gh issue edit <n> --repo <owner/repo> --body-file .jerv/tmp/issue-body.md` — `gh` writes pass under the pool. When `node -e` reads saved JSON, pass an absolute path or use `JSON.parse(require('fs').readFileSync(process.argv[1],'utf8'))`: `require()` of a relative path (e.g. `tmp\board.json` from `cygpath -w`) throws MODULE_NOT_FOUND.
 
 ## Step 2 — render it
 
@@ -60,7 +60,12 @@ mmi-cli oracle board claim <ref> <ref> <ref> --json
 
 Announce issue/PR counts; refresh `mmi-cli oracle board read` this session and select ordinary claims from **Free to claim**. Read every result: failures exit nonzero. On conflict, do not blindly retry: refresh, pick another candidate or coordinate a handoff; `--force` only for an owner-authorized intentional takeover. Run writes separately, never `;`; dependent follow-ups use `&&`.
 
-Follow printed owner rulings; record new ones with `mmi-cli oracle issue decision`. One concurrent worktree per batch: [reference.md](reference.md).
+Run each `mmi-cli oracle issue create` as its own simple command with plain double-quoted arguments — never a shell
+helper function or nested escaped quotes around a long body in the same call: the workspace env-enumeration guard
+blocks any command whose quoting it cannot prove inert. Write the body to a file under `.jerv/tmp/` and pass
+`--body-file` (`--title-file` for titles with backticks).
+
+Follow printed owner rulings; record new ones with `mmi-cli oracle issue decision`. One concurrent worktree per batch: [reference.md](reference.md). Always pass `--surface <value>` explicitly on every `mmi-cli oracle issue create` (surface inference is strict and bounces when the body merely mentions a path); use `--no-surface` only for genuinely exempt filings.
 
 With several task lanes in one session, pass `worktree: <the mmi-worktrees/<Repo>/<issue>-<slug> path jerv_worktree_create reported>` to `jerv_worktree_exec` / `jerv_worktree_land` every time; they refuse to guess (#5629). While any mmi-worktrees lane is registered for this repo, run focused tests/gates from the task-worktree root `jerv_worktree_create` reported — never the primary checkout; the test policy refuses it (`test-command-untrusted-worktree-cwd`).
 

package/skills/board/reference.md

@@ -65,6 +65,10 @@ and PR facts.
 full `closingIssuesReferences` list and moves **each** issue to Done, verifying every one and naming any
 that did not move. So a bundle is a first-class landing, not a trick.
 
+Preflight: when the lane changed `docs/`, run `mmi-cli oracle docs index --write`, then commit and push BEFORE
+`mmi-cli devops pr create` — freshness is checked at the pushed commit even under an active merge queue, so never
+defer index regeneration to after merge.
+
 Materialize the body as a real UTF-8 file and pass its path; do not pipe it to `--body-file -`. Read
 `mmi-cli explain devops pr create --json` before the write — flags change.
 

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

@@ -70,6 +70,10 @@ jobs:
         if: ${{ steps.development-gate.outputs.reuse != 'true' }}
         env:
           NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      # Suite only: generic product gates must not load or require design-agent content.
+      - name: Check kit agent-file drift
+        if: ${{ steps.development-gate.outputs.reuse != 'true' }}
+        uses: mutmutco/MMI-Hub/.github/actions/check-kit-agent-files@{{GATE_RUNNER_SHA}}
       - uses: mutmutco/MMI-Hub/.github/actions/run-with-budget@{{GATE_BUDGET_SHA}}
         if: ${{ steps.development-gate.outputs.reuse != 'true' }}
         with:

package/skills/hotfix/suite.md

@@ -1,2 +1,2 @@
-In the suite lead (MM-Work) a plain rcand, release or hotfix refuses: run `mmi-cli devops suite rcand --owner-go` or `mmi-cli devops suite release --owner-go` instead (a lead-only cut needs `--suite-solo --owner-go`). A suite member cannot run standalone rcand, release or hotfix: cut from the suite lead; only a backward-compatible solo backend release/hotfix with explicit owner approval may pass `--suite-solo --owner-go`, and its MM-Work development pin PR must land before the suite is in sync.
+In the suite lead (MM-Work) a plain rcand, release or hotfix refuses: run `mmi-cli devops suite rcand --owner-go` or `mmi-cli devops suite release --owner-go` instead (a lead-only cut needs `--suite-solo --owner-go`). On your own, run only the read-only previews `mmi-cli devops suite rcand --dry-run` and `mmi-cli devops suite hotfix <member> --dry-run`; `suite release` and `suite abandon` have no dry-run, so never run them yourself. A real suite rcand, release, hotfix or abandon runs only on the owner's go, executed by the owner or the suite orchestrator. A suite member cannot run standalone rcand, release or hotfix: cut from the suite lead; only a backward-compatible solo backend release/hotfix with explicit owner approval may pass `--suite-solo --owner-go`, and its MM-Work development pin PR must land before the suite is in sync.
 

package/skills/org-guide/references/work-and-releases.md

@@ -414,7 +414,7 @@ commit, so build and verify the lines from one pass over that range —
 subject, body and changed files — never from subjects, PR titles or memory; a line whose claim is not
 in that output does not go in the file. A Hub summary never mentions a Jerv-side project; the train
 refuses such a line.
-Every new MM-Work suite Release, solo and hotfix included, requires `--announce-summary-file` and `--announce-summary-file-tr` in the bilingual update-notes template of the [MM-Work GUIDE, "Update notes"](https://github.com/mutmutco/MM-Work/blob/development/packages/mmwork-ds/GUIDE.md#update-notes) (`Fixed`/`Düzeldi`, then `New`/`Yeni`, with `<Area>: <sentence>.` lines; a Fixed line states what works now, never the problem). A suite release requires `--member-summary-file owner/repo=path` and `--member-summary-file-tr owner/repo=path` for every member it releases. A suite cut's `--owner-go` records the owner's explicit go for that one cut, never an agent's own decision: a held train or stale MM-Work cut goes to the suite orchestrator with the exact owner-gated commands. Details: the release skill.
+Every new MM-Work suite Release, solo and hotfix included, requires `--announce-summary-file` and `--announce-summary-file-tr` in the bilingual update-notes template of the [MM-Work GUIDE, "Update notes"](https://github.com/mutmutco/MM-Work/blob/development/packages/mmwork-ds/GUIDE.md#update-notes) (`Fixed`/`Düzeldi`, then `New`/`Yeni`, with `<Area>: <sentence>.` lines; a Fixed line states what works now, never the problem). A suite release requires `--member-summary-file owner/repo=path` and `--member-summary-file-tr owner/repo=path` for every member it releases. A suite cut's `--owner-go` records the owner's explicit go for that one cut, never an agent's own decision: a held train or stale MM-Work cut goes to the suite orchestrator with the exact owner-gated commands. On its own an agent runs only `suite rcand --dry-run` and `suite hotfix <member> --dry-run`; it never runs `suite release` or `suite abandon`, which have no dry-run. Details: the release skill.
 
 Announcement delivery uses the developer's GitHub-authenticated Hub session. The Hub checks project
 authority, resolves the registered channel, and reads the MMI Future Slack key inside its vault boundary.

package/skills/rcand/suite.md

@@ -1,4 +1,4 @@
-In the suite lead (MM-Work) a plain rcand, release or hotfix refuses: the suite path is `mmi-cli devops suite rcand --owner-go` or `mmi-cli devops suite release --owner-go` (a lead-only cut needs `--suite-solo --owner-go`). `--owner-go` records Jervaise's explicit go for that one cut; it is never the agent's own flag. Never pass it on your own authority: a held train or a stale MM-Work cut (`suite abandon --owner-go`, then `suite rcand --owner-go`) is handed to the suite orchestrator with that exact command sequence, and runs only after the owner says go. A suite member cannot run standalone rcand, release or hotfix: cut from the suite lead; only a backward-compatible solo backend release/hotfix with explicit owner approval may pass `--suite-solo --owner-go`, and its MM-Work development pin PR must land before the suite is in sync.
+In the suite lead (MM-Work) a plain rcand, release or hotfix refuses: the suite path is `mmi-cli devops suite rcand --owner-go` or `mmi-cli devops suite release --owner-go` (a lead-only cut needs `--suite-solo --owner-go`). `--owner-go` records Jervaise's explicit go for that one cut; it is never the agent's own flag. Never pass it on your own authority: a held train or a stale MM-Work cut (`suite abandon --owner-go`, then `suite rcand --owner-go`) is handed to the suite orchestrator with that exact command sequence, and runs only after the owner says go. On your own, run only the read-only previews `mmi-cli devops suite rcand --dry-run` and `mmi-cli devops suite hotfix <member> --dry-run`; `suite release` and `suite abandon` have no dry-run, so never run them yourself. A real suite rcand, release, hotfix or abandon runs only on the owner's go, executed by the owner or the suite orchestrator. A suite member cannot run standalone rcand, release or hotfix: cut from the suite lead; only a backward-compatible solo backend release/hotfix with explicit owner approval may pass `--suite-solo --owner-go`, and its MM-Work development pin PR must land before the suite is in sync.
 
 Support sessions (MMI-Hub, Jerv-Hub, Jerv-JervCode) are not suite members and hold standing owner authorization (2026-10-25) to cut and ship releases at their discretion during suite runs without repeated per-release approval; record this standing rule in every suite session's working note and briefing while keeping all standard release preflight, gate, and verification checks.
 

package/skills/release/suite.md

@@ -1,4 +1,4 @@
-In the suite lead (MM-Work) a plain rcand, release or hotfix refuses: the suite path is `mmi-cli devops suite rcand --owner-go` or `mmi-cli devops suite release --owner-go` (a lead-only cut needs `--suite-solo --owner-go`). `--owner-go` records Jervaise's explicit go for that one cut; it is never the agent's own flag. Never pass it on your own authority: a held train or a stale MM-Work cut (`suite abandon --owner-go`, then `suite rcand --owner-go`) is handed to the suite orchestrator with that exact command sequence, and runs only after the owner says go. A suite member cannot run standalone rcand, release or hotfix: cut from the suite lead; only a backward-compatible solo backend release/hotfix with explicit owner approval may pass `--suite-solo --owner-go`, and its MM-Work development pin PR must land before the suite is in sync.
+In the suite lead (MM-Work) a plain rcand, release or hotfix refuses: the suite path is `mmi-cli devops suite rcand --owner-go` or `mmi-cli devops suite release --owner-go` (a lead-only cut needs `--suite-solo --owner-go`). `--owner-go` records Jervaise's explicit go for that one cut; it is never the agent's own flag. Never pass it on your own authority: a held train or a stale MM-Work cut (`suite abandon --owner-go`, then `suite rcand --owner-go`) is handed to the suite orchestrator with that exact command sequence, and runs only after the owner says go. On your own, run only the read-only previews `mmi-cli devops suite rcand --dry-run` and `mmi-cli devops suite hotfix <member> --dry-run`; `suite release` and `suite abandon` have no dry-run, so never run them yourself. A real suite rcand, release, hotfix or abandon runs only on the owner's go, executed by the owner or the suite orchestrator. A suite member cannot run standalone rcand, release or hotfix: cut from the suite lead; only a backward-compatible solo backend release/hotfix with explicit owner approval may pass `--suite-solo --owner-go`, and its MM-Work development pin PR must land before the suite is in sync.
 
 Support sessions (MMI-Hub, Jerv-Hub, Jerv-JervCode) are not suite members and hold standing owner authorization (2026-10-25) to cut and ship releases at their discretion during suite runs without repeated per-release approval; record this standing rule in every suite session's working note and briefing while keeping all standard release preflight, gate, and verification checks.