@mutmutco/pi-plugin 4.6.30 → 4.6.32

package/package.json

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

package/skills/board/SKILL.md

@@ -13,17 +13,23 @@ permission to take anything.
 
 ```bash
 mkdir -p .jerv/tmp
-mmi-cli oracle board read --json --out .jerv/tmp/board.json
+mmi-cli oracle board read --json --flat --out .jerv/tmp/board.json
 ```
 
-One call; the JSON carries `viewer`, `repo` and the project title. Use `primary` for this repo and
-`secondary` for other repos on the Project. Without `--flat`, `board read --json` returns an object
+One call; `--flat` gives one array of rows to iterate. A routine read already excludes Done and closed
+items, so no status post-filter is needed. The detailed form (`--json` without `--flat`) carries `viewer`,
+`repo` and the project title; use its `primary` for this repo and `secondary` for other repos on the
+Project. Without `--flat`, `board read --json` returns an object
 `{project, viewer, repo, primary, secondary, warnings, partial}` whose `primary` and `secondary` are bucket
 objects `{userOwned, claimable, taken, unownedInFlight}` of item arrays (no top-level `items` array), so filter
-a bucket (e.g. `report.primary.claimable`) or pass `--json --flat`, never `(j.items||j).filter`. `--flat` rows
-are `{ref,number,title,status,assignees,labels,bucket,claim,openPullRequests}` (`claim` is the parsed mmi-claim
-evidence object, null when unclaimed; `openPullRequests` lists the OPEN PRs whose closing-issue body links name
-the item — on the full JSON object that list lives at `report.pullRequests`, never `openPullRequests`). Partial reads
+a bucket (e.g. `report.primary.claimable`) or pass `--json --flat`, never `(j.items||j).filter`. Never sniff
+for the list (`j.items ?? j.rows ?? j`, `Object.values`, any generic "find the list" wrapper): it throws
+`items is not iterable` before any row is read. For a number|status|claim|title projection across non-Done
+rows, run `mmi-cli oracle board read --json --flat --out .jerv/tmp/board.json` and filter that array locally.
+`--flat` rows are `{ref,number,title,status,assignees,labels,bucket,claim,openPullRequests}` (`claim` is the
+parsed mmi-claim evidence object, null when unclaimed; `openPullRequests` lists the OPEN PRs whose
+closing-issue body links name the item — on the full JSON object that list lives at `report.pullRequests`,
+never `openPullRequests`). Partial reads
 exit nonzero; `--allow-partial` only when the dev accepts an incomplete board. The CLI partitions rows into
 **Yours**, **Free to claim** and **Taken**; stale stamps (4 hours without work) hold nothing. Recovery
 moves: a zero-byte or empty `.jerv/tmp/*.json` (`Unexpected end of JSON input`) means a shell-redirected
@@ -33,7 +39,7 @@ item is `mmi-cli oracle board move <status> <ref>`, never a hand-written `gh api
 lookup. 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 list --event`/`--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`, `run list --event <event>`, or `MMI_ACTOR=app mmi-cli devops api get "repos/<owner>/<repo>/actions/runs?event=<event>&per_page=<n>"`); `--jq '<expr>'` on that typed read filters locally. A single issue or PR item (`repos/<owner>/<repo>/issues/<n>` and `pulls/<n>`) has no `devops api get` route — `MMI_ACTOR=app mmi-cli devops read issue view <n> --repo <owner>/<repo> --json <fields>` (and `pr view`) is the only read. Those typed reads take **one** number per call, exactly like native gh: a second number is refused as `too many arguments`, so read several issues by repeating the typed read once per number (one `--jq` each, joined `&&`). 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 `mmi-cli oracle issue edit <ref> --body-file .jerv/tmp/issue-body.md`. 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.
+**Under the App pool, never type raw `gh` for a read** (`gh issue list/view --jq`, `gh run list --event`/`--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`, `run list --event <event>`, or `MMI_ACTOR=app mmi-cli devops api get "repos/<owner>/<repo>/actions/runs?event=<event>&per_page=<n>"`); `--jq '<expr>'` on that typed read filters locally. A single issue or PR item (`repos/<owner>/<repo>/issues/<n>` and `pulls/<n>`) has no `devops api get` route — `MMI_ACTOR=app mmi-cli devops read issue view <n> --repo <owner>/<repo> --json <fields>` (and `pr view`) is the only read. Those typed reads take **one** number per call, exactly like native gh: a second number is refused as `too many arguments`, so read several issues by repeating the typed read once per number (one `--jq` each, joined `&&`). Filter in a pipe or save output (`--out`, or `>`; never `2>&1` into a JSON parser) 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 `mmi-cli oracle issue edit <ref> --body-file .jerv/tmp/issue-body.md`. 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
 

package/skills/board/reference.md

@@ -15,7 +15,10 @@ the gate again.
 Prefer `--out` for a shell-independent UTF-8 receipt. Windows PowerShell 5.1's `>` writes
 UTF-16LE with a BOM (#5802); Bash redirects preserve the CLI's UTF-8 output.
 
-One call. Its JSON carries `viewer`, `repo` and the project title — do not spend extra calls on
+The canonical read is `mmi-cli oracle board read --json --flat --out .jerv/tmp/board.json`: one array of
+rows to iterate. A routine read already excludes Done and closed items, so no status post-filter is needed.
+
+One call. The detailed form (`--json` without `--flat`) carries `viewer`, `repo` and the project title — do not spend extra calls on
 `gh api user` or `gh repo view`. Use `primary` for this repo and `secondary` for other repos on the same
 Project. Without `--flat`, `board read --json` returns an object
 `{project, viewer, repo, primary, secondary, warnings, partial}` whose `primary` and `secondary` are bucket

package/skills/bootstrap/seeds/runbook-unaffected.json

@@ -1,7 +1,7 @@
 {
   ".github/workflows/agent-pr.yml": {
-    "blob": "dff394ae296224bc1d40f2ab4953d30a89bc5a91",
-    "reason": "runs-on only: the two seconds-long guard legs moved off the busy CI pool to the reserved journey/deploy pool with a 5-minute cap (#9211); job logic, steps, permissions and operator responsibilities unchanged"
+    "blob": "e85a80c65b26531a330917fb4b5d8f563a0f0d0c",
+    "reason": "sole-write-path guard reads retry transient GitHub API 5xx/429/transport failures up to 3 attempts, then fail closed with the same messages (#9911); permissions, refs, guarded paths and operator responsibilities unchanged"
   },
   "scripts/next-version.mjs": {
     "blob": "2c1985b59edc779695479559074e7654c1574a11",

package/skills/release/SKILL.md

@@ -11,7 +11,7 @@ Bare `minor|major|patch` (default `patch`), never a flag. A production release n
 
 ## Lane
 
-Read `mmi-cli oracle org project get {owner}/{repo} --json` and name the lane ([verification.md](verification.md) Lane rules); unreadable META → stop. [suite.md](suite.md) for MM-Work; [vercel.md](vercel.md) for Vercel.
+Read `mmi-cli oracle org project get {owner}/{repo} --json` and name the lane ([verification.md](verification.md) Lane rules); unreadable META → stop. On `releaseTrack: single` (MM-Work and its modules) or `trunk` there is no release lane. On single track a merge to development auto-deploys the `main` stage, and release, rcand and hotfix refuse. A merged single-track change is live once that deploy is green. A trunk repo follows its own declared publishing workflow. Never tell the owner a landed change waits on a release. [suite.md](suite.md) for suite cuts; [vercel.md](vercel.md) for Vercel.
 
 ## Preflight
 

package/skills/release/suite.md

@@ -1,3 +1,5 @@
+MM-Work and most of its modules are `releaseTrack: single` ([work-and-releases.md](../org-guide/references/work-and-releases.md)). A merge to development auto-deploys their `main` stage, so a landed change is live once that deploy is green. Never tell the owner such a change waits on a release. Read each repo's `releaseTrack` with `mmi-cli oracle org project get <owner/repo> --json` before naming any cut. A suite cut also cuts the MM-Work lead's rcand, which refuses while MM-Work is single track.
+
 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. A suite member never asks for, proposes or prompts an rc, release or hotfix — the suite orchestrator is the only voice that brings a cut to Jervaise, so a member session states what landed and stops instead of offering a cut.
 
 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, and under the owner's 2026-11-01 ruling each support session strives during a suite run to finish its own board and cut a patch release for landed-but-unreleased merges so suite members pick the update up in that run instead of waiting for a later cut, keeping all standard release preflight, gate, and verification checks.