@mutmutco/pi-plugin 4.6.13 → 4.6.15

package/package.json

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

package/skills/board/SKILL.md

@@ -25,10 +25,15 @@ are `{ref,number,title,status,assignees,labels,bucket,claim,openPullRequests}` (
 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. Partition rules,
+**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
+read FAILED — re-run with `--out` and check the exit code before parsing; a Status change on an existing
+item is `mmi-cli oracle board move <status> <ref>`, never a hand-written `gh api graphql`
+`updateProjectV2ItemFieldValue` mutation with copied `PVT_`/`PVTI_` node ids and a manual Status field-id
+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. 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 (`>`, `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.
 
 ## Step 2 — render it
 

package/skills/bootstrap/seeds/suite-guide.template.md

@@ -14,7 +14,7 @@ The server exposes `/health` and `/module.js`. Register the module's bundle URL,
 
 1. **Single source of truth:** the source folder of `packages/mmwork-ds` in `mutmutco/MM-Work`, owned by the MM-Work Design Lead (tokens, layers, component bundle, component docs, `DESIGN.md` and its `design.json` sidecar). Never edit the kit or its copies here; a missing piece or variant is built there first, or requested via kit MCP `request_piece`.
 2. **MM Artifact on Live Docs:** Live Docs (`Canlı belgeler / MM-Work`) displays document `3a5c79df-5274-40ad-a1b5-a75e67a74dac` (ATOMIC, module `mm-work-kit`), an MM Artifact in the `design-system` format rebuilt from the kit source on every kit release: Overview, Guide (kit README + `DESIGN.md`), Tokens, Atoms, Molecules, Organisms, Templates and Files. Browse it to see every piece live.
-3. **Impeccable knows Atomic Design at boot:** `impeccable context` loads `PRODUCT.md`, `DESIGN.md` and the `design.json` sidecar in `.impeccable`, which carry the Atomic Design contract 1.1.0: `Atoms -> Molecules -> Organisms -> Templates -> Pages`, upward-only composition enforced by `npx mmwork-check-ui --rules=all`. Pages arrange exported `@mutmutco/mmwork-ds` pieces around one template and never paint custom controls, raw `<button>`/`<input>`, `mw-*` classes, inline visual styles or raw hex/px values.
+3. **Impeccable knows Atomic Design at boot:** `impeccable context` loads `PRODUCT.md`, `DESIGN.md` and the `design.json` sidecar in `.impeccable`, which carry the Atomic Design contract 1.1.0: `Atoms -> Molecules -> Organisms -> Templates -> Pages`, upward-only composition enforced by `npm --prefix module run lint` (or `npm run lint` inside `module/`; `mmwork-check-ui` and `mmwork-check-i18n` are bins of `@mutmutco/mmwork-ds`, so a bare `npx mmwork-check-ui` outside that project's installed `node_modules` is resolved as a package name and 404s). Pages arrange exported `@mutmutco/mmwork-ds` pieces around one template and never paint custom controls, raw `<button>`/`<input>`, `mw-*` classes, inline visual styles or raw hex/px values.
 4. **Automatic propagation:** on every kit release the Hub kit-adopt workflow opens an adoption PR here that bumps `@mutmutco/mmwork-ds`, runs `mmwork-sync-impeccable`, and writes `DESIGN.md`, the `.impeccable` design manifest and `.impeccable/config.json` (`hook.enabled: true`) at the repository root, and deletes any stale copies under `module/`. These files are kit-owned: do not hand-edit them, and keep them committed even if `.impeccable/` is ignored (the adoption PR force-stages them).
 5. **Root only:** `PRODUCT.md`, `DESIGN.md`, the `.impeccable` design manifest and `.impeccable/config.json` live only at this repository's root, never duplicated under `module/`; a copy there makes Impeccable treat `module/` as a separate root without `PRODUCT.md` and the config. Run `impeccable context` from the root. Any suite-wide propagation of these files needs an explicit intercom ACK handshake with the MM-Work Design Lead naming the files written and removed, `impeccable context` + `impeccable doctor --json` verification, and the issue/PR reference.
 6. **Front-loaded harmony (owner, 2026-10-25; Hub#8837 / MM-Work#7668):** design work runs one workflow — Front-Loaded Impeccable v4.7.0 + MM Artifacts + Live Docs (`Canlı belgeler`, `3a5c79df-5274-40ad-a1b5-a75e67a74dac`) + Atomic Design Kit (`@mutmutco/mmwork-ds`). The former local stage skill is retired; preview and verify through these tools only.

package/skills/org-guide/SKILL.md

@@ -30,7 +30,7 @@ Read this entry before MMI work, then **only the relevant topic**. Human intro:
 | Consume, declare, rotate, or request a secret | [Vault and keyless access](references/vault.md) |
 | Register domains or configure Google OAuth | [Domains and OAuth](references/domains-and-oauth.md) |
 | Decide what belongs in a product repository | [Repository rules](references/repository-rules.md) |
-| Build an MM-Work module | not bundled — [MM-Work module guide](https://github.com/mutmutco/MM-Work/blob/development/packages/mmwork-ds/GUIDE.md) in `@mutmutco/mmwork-ds`; read `pieces.json`, `mmwork.d.ts`, `FOR-AGENTS.md`, and `docs/components/<Piece>/guide.md` from the npm project declaring it (`module/node_modules/@mutmutco/mmwork-ds/`), never repo-root `node_modules`; when absent, fall back to `~/.jerv/cache/mmwork-ds/latest` or MM-Work `packages/mmwork-ds`, treat capability as unknown |
+| Build an MM-Work module | [Module guide](https://github.com/mutmutco/MM-Work/blob/development/packages/mmwork-ds/GUIDE.md): from consumer, run `node <MMI-Hub>/scripts/design-pack-render.mjs --resolve-kit [<Piece>]` for kit root and `docs/components/<Piece>/guide.md`; prefers `module/node_modules/@mutmutco/mmwork-ds/`, falls back to `~/.jerv/cache/mmwork-ds/latest`. Read returned `piecesJson`, `types`, `forAgents`; absent means unknown capability. Never guess repo-root paths. |
 | Produce company-facing documents in the MM brand | not bundled — MM-Strategy MCP serves the brand kit (`mm_brand_guide`); install `@mutmutco/strategy` |
 
 Bundled guidance matches the installed plugin, not Jerv/JervCode; resolve current values/flags via live CLI.

package/skills/org-guide/references/design.md

@@ -49,6 +49,13 @@ design work follows one harmonized **Front-Loaded Impeccable v4.7.0 + MM Artifac
 - **Live Docs** (`Canlı belgeler` viewer) carry the living references, including the live
   design-system artifact `3a5c79df-5274-40ad-a1b5-a75e67a74dac`.
 - **Atomic Design Kit** (`@mutmutco/mmwork-ds`): kit pieces and tokens only, checked with `mmwork-check-ui`.
+  From the consumer, run `node <MMI-Hub>/scripts/design-pack-render.mjs --resolve-kit [<Piece>]`
+  to resolve the kit root and `docs/components/<Piece>/guide.md` in one JSON response. It prefers
+  `module/node_modules/@mutmutco/mmwork-ds/`, then the consumer's install, then
+  `~/.jerv/cache/mmwork-ds/latest`. Read the returned `piecesJson`, `types` and `forAgents` paths
+  before choosing pieces; `exists` reports whether the requested guide exists. Never guess
+  repo-root `node_modules/@mutmutco/mmwork-ds/docs/components/<Piece>.md`; component guides
+  live in `<Piece>/guide.md`. No install/cache means capability remains unknown.
 
 How the five pillars fit together (owner, 2026-10-25):
 
@@ -146,7 +153,19 @@ Craft essentials every agent applies (owner, 2026-10-25, #8839):
   `node scripts/design-pack-render.mjs --page-spec <spec.mjs>` (it SSR-renders `renderPage(ctx)` per
   theme mode and runs `impeccable detect --json` on the HTML), or `node artifacts/review/review.mjs
   <folder> --standalone` for a pack; never hand-roll an inline `node -e` SSR script, which evaluates
-  as CommonJS and fails on the spec's ESM `import` lines (#8876).
+  as CommonJS and fails on the spec's ESM `import` lines (#8876). For a folder of self-contained
+  static HTML boards (pre-rendered, every asset inside the folder), run
+  `node scripts/design-pack-render.mjs --pack <pack-dir> --boards <b-first.html,b-thread.html> --widths 1440,390`:
+  it serves `<pack-dir>` on `127.0.0.1`, measures each named board per width and theme, runs
+  `impeccable detect --json` over the board files and writes `check.json`. `--boards` takes one
+  comma-separated list (an unquoted shell glob passes only its first match); the server serves only
+  files directly inside `<pack-dir>`; and the run always exits 2 because rhythm and alignment stay
+  unmeasured, so it is not a full kit pass on its own. Boards that load `/kit/kit.css` and
+  `/kit/kit.js` are canvas boards: use `review.mjs <folder> --no-open`, which serves the kit beside
+  each board on `127.0.0.1` and runs live-DOM `impeccable detect` per board.
+  `artifacts/review/kit-assets.mjs`, `review.mjs`'s kit and board serving, and
+  `artifacts/format/check.mjs` are internals of the review server: no agent imports them or
+  re-implements them in an inline script (#9672).
 
 ### Shared support-script invocation
 

package/skills/org-guide/references/repository-rules.md

@@ -28,3 +28,4 @@ rules. Preserve product-owned content when updating managed sections.
 Use `mmi-cli tests policy --base <comparison-base>` and the repository's own checks before landing.
 For tooling repair, `mmi-hub status` reads state and `mmi-hub update` updates installed tooling;
 repository cleanup is a separate, explicit action, not an automatic consequence of asking for help.
+To find where `mmi-cli` emits a message or refusal, search the MMI-Hub checkout's `cli/src/**`; the installed tool is the published `@mutmutco/cli` and ships only bundled `dist`, so the global npm install root is not a searchable source tree.

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. 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.
+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.