@mutmutco/claude-plugin 4.6.5 → 4.6.7

package/cli/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mutmutco/cli",
-  "version": "4.6.5",
+  "version": "4.6.7",
   "description": "MMI Future CLI — the org dev toolbox and shared cross-IDE engine for every registry-declared MMI coding surface.",
   "type": "module",
   "license": "UNLICENSED",

package/package.json

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

package/skills/board/SKILL.md

@@ -75,7 +75,7 @@ quote-light body may instead be piped as a quoted heredoc straight into the inte
 script, then `JS` — but a heredoc over six lines, or one carrying backslashes, backticks or `${…}`, is refused,
 so the file form is the one that always works.
 
-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.
+Follow printed owner rulings; record new ones with `mmi-cli oracle issue decision`. Status, findings and handoffs go on the owning issue as a comment (`mmi-cli oracle issue comment <n> --repo <owner/repo> --body-file .jerv/tmp/<file>`, which runs on the App token by default); intercom carries only actionable coordination, never ACK or status chatter (#9547). 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, name the lane's worktree path (the `mmi-worktrees/<Repo>/<issue>-<slug>` path your host reported when it created the worktree) on every worktree exec or land call; the host refuses to guess (#5629). While any mmi-worktrees lane is registered for this repo, run focused tests/gates from the task-worktree root your host reported — never the primary checkout; the test policy refuses it (`test-command-untrusted-worktree-cwd`). A fresh worktree has no `.jerv/`, so `mkdir -p .jerv/tmp` before writing scratch files there (PR bodies, batches).
 

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

@@ -94,13 +94,11 @@ Impeccable **v4.7.0 / engine v0.1.16** details:
   `NODE_AUTH_TOKEN=$(gh auth token) npm view @mutmutco/mmwork-ds@<v> version --registry https://npm.pkg.github.com`;
   from a root without that line, pass the token directly —
   `npm view @mutmutco/mmwork-ds@<v> version --registry https://npm.pkg.github.com --//npm.pkg.github.com/:_authToken=$(gh auth token)`.
-  To see **which** kit versions are actually published, run MMI-Hub's
-  `node scripts/kit-adopt.mjs --list-versions [--limit 5] [--json]` (#9426) instead of deriving it: it reads GitHub
-  Packages `/orgs/mutmutco/packages/npm/mmwork-ds/versions` (newest first, falling back to `npm view` against
-  `https://npm.pkg.github.com` with `GH_PACKAGES_READ_TOKEN`/`NODE_AUTH_TOKEN`), reports the local cache's latest
-  version, and never hits the `registry.npmjs.org` 404 of a bare `npm view @mutmutco/mmwork-ds` (#9264). That is the supported listing read:
-  `mmi-cli devops packages` covers consumer adoption (`adopt-export`) only, so it never names a published
-  version — never carry the packages API as a stopgap.
+  To see **which** kit versions are actually published, run `mmi-cli devops packages versions --package mmwork-ds [--limit 5] [--json]`
+  (#9542; or MMI-Hub's `node scripts/kit-adopt.mjs --list-versions [--limit 5] [--json]`, #9426) instead of deriving it: both read GitHub
+  Packages `/orgs/mutmutco/packages/npm/mmwork-ds/versions` (newest first; `kit-adopt.mjs` also falls back to `npm view` against
+  `https://npm.pkg.github.com` with `GH_PACKAGES_READ_TOKEN`/`NODE_AUTH_TOKEN` and reports the local cache's latest
+  version), and neither ever hits the `registry.npmjs.org` 404 of a bare `npm view @mutmutco/mmwork-ds` (#9264, #9542).
 - Boot once: `impeccable context --target <path>`; `init` captures PRODUCT.md, `document` maintains
   `DESIGN.md` and its `design.json` sidecar, `impeccable doctor --json` reports drift, and `extract`
   identifies reusable candidates (kit additions still need the Design Lead). Read

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

@@ -64,7 +64,7 @@ Never defer a live check waiting for real data (owner ruling 2026-10-27T20:04Z,
 state it verifies with the module's dev/admin tools (MDT verbs, admin endpoints, module CLI,
 synthetic accounts); if a needed verb is missing, add it in the same lane, then verify now.
 
-UI, design, document and MM Artifact work follows the [design topic](design.md): the required `gate` holds fast deterministic checks only, and owner A/B choices go on an MM Artifacts canvas, never as prose.
+UI, design, document and MM Artifact work follows the [design topic](design.md): the required `gate` holds fast deterministic checks only, and owner A/B choices go on an MM Artifacts canvas, never as prose. To inspect published `@mutmutco/*` package versions (e.g. `@mutmutco/mmwork-ds`), run `mmi-cli devops packages versions --package mmwork-ds [--limit 5] [--json]` (`orgs/mutmutco/packages/npm/<pkg>/versions`); never run a bare `npm view @mutmutco/...`, which queries the public `registry.npmjs.org` and fails with `E404` (#9238, #9542).
 
 ## Documentation preflight
 

package/skills/rcand/SKILL.md

@@ -38,7 +38,7 @@ mkdir -p .jerv/tmp && r=$(mktemp .jerv/tmp/rcand-receipt.XXXXXX)
 mmi-cli devops rcand --apply --json --out "$r"
 ```
 
-`--watch` blocks on the deploy. Version-manifest merge conflicts take `development` (any other refuses); the `-rc.N` tag is re-run-safe. Deploy by model: `tenant-deploy.yml` for tenant-container; serverless, registry-publish and solo-container deploy via their push-triggered workflow. Never push, force or commit to `rc` by hand.
+`--watch` blocks on the deploy. Version-manifest merge conflicts take `development` (any other refuses); the `-rc.N` tag is re-run-safe. Deploy by model: the Hub's central deployer `mutmutco/MMI-Hub/.github/workflows/tenant-deploy.yml` for tenant-container (a tenant repo carries no deploy workflow in its own `.github/workflows/`, so read deploy status from the receipt's `runUrl` or `mmi-cli devops read run watch <run-id> --repo mutmutco/MMI-Hub --exit-status --interval 60`); serverless, registry-publish and solo-container deploy via their push-triggered workflow. Never push, force or commit to `rc` by hand.
 
 ## Verify
 

package/skills/rcand/recovery.md

@@ -1 +1 @@
-Every refusal and every doctor blocker names its `code` and `anchor`: open the finding's `anchor` URL and follow that entry, nothing else ([shared recovery](../release/train-common.md#recovery)). A candidate whose immutable rc tag passed policy but whose `origin/rc` was not pushed continues with `mmi-cli devops rcand --resume --watch --json --out <fresh-receipt>` — the only continuation form: `--resume` never re-tags, and `--apply` mints the next `-rc.N` for a new cut only. A promoted candidate whose rc deploy failed retries it, once the cause is fixed, with `mmi-cli devops rcand --retry-deploy --watch --json --out <fresh-receipt>` — same tag and SHA, never re-cut or re-pushed; `--resume` only re-reads that failed leg. Supersede is the last resort, with the authorized human's fresh approval. A refused train is a stop (Merge floor): fix the cause on `development` through a normal PR, then rerun; a rejected protected push leaves the local tag for an authorized rerun, never a force.
+Every refusal and every doctor blocker names its `code` and `anchor`: open the finding's `anchor` URL and follow that entry, nothing else ([shared recovery](../release/train-common.md#recovery)). A candidate whose immutable rc tag passed policy but whose `origin/rc` was not pushed continues with `mmi-cli devops rcand --resume --watch --json --out <fresh-receipt>` — the only continuation form: `--resume` never re-tags, and `--apply` mints the next `-rc.N` for a new cut only. A promoted candidate whose rc deploy failed retries it, once the cause is fixed, with `mmi-cli devops rcand --retry-deploy --watch --json --out <fresh-receipt>` — same tag and SHA, never re-cut or re-pushed; `--resume` only re-reads that failed leg. For `tenant-container` repos, the deploy runs on the Hub's central deployer (`mutmutco/MMI-Hub/.github/workflows/tenant-deploy.yml`, never a local `.github/workflows/` file in the tenant repo): inspect or watch it via the receipt's `runUrl` or `mmi-cli devops read run watch <run-id> --repo mutmutco/MMI-Hub --exit-status --interval 60`. Supersede is the last resort, with the authorized human's fresh approval. A refused train is a stop (Merge floor): fix the cause on `development` through a normal PR, then rerun; a rejected protected push leaves the local tag for an authorized rerun, never a force.

package/skills/release/verification.md

@@ -19,7 +19,7 @@ Read the saved result, never the exit code (`1` = a follow-up failed after promo
 
 - `releaseVerdict.releaseStatus` + `followUpStatus`: `succeeded` + `pending` is shipped, follow-up unresolved. `--resume` receipts carry the same `releaseVerdict` (`command: release-resume`) plus `mode` and `state`.
 - `deployStatus`: `pending` is never terminal; `promoted: true` holds even when a deploy failed.
-- `workflowRuns`: every run on the release SHA (discover them with the bounded run-list read at the top, filtered locally by the receipt SHA); watch each non-success entry to conclusion with `mmi-cli devops read run watch <run-id> --repo {owner}/{repo} --exit-status --interval 60`. `parallel: true` marks legs run together. Name the red run: `deploy.yml`, `publish.yml`, `tenant-deploy.yml` and `jerv-gateway` are deploy/publish verdicts; a `gate` push run is ordinary CI.
+- `workflowRuns`: every run on the release SHA (discover them with the bounded run-list read at the top, filtered locally by the receipt SHA); watch each non-success entry to conclusion with `mmi-cli devops read run watch <run-id> --repo {owner}/{repo} --exit-status --interval 60` (or `--repo mutmutco/MMI-Hub` for the central tenant deployer). `parallel: true` marks legs run together. Name the red run: `deploy.yml`, `publish.yml`, `mutmutco/MMI-Hub/.github/workflows/tenant-deploy.yml` (the Hub's central deployer — a tenant repo carries no local deploy workflow, so read its status from the receipt's `runUrl` or `mmi-cli devops read run watch <run-id> --repo mutmutco/MMI-Hub`) and `jerv-gateway` are deploy/publish verdicts; a `gate` push run is ordinary CI.
 - `announceNote`: `announced`, `skipped`, `not announced` (deploy/publish not green; a `--resume` with the same `--announce-summary-file` posts it), or the failure note. A failed announcement keeps its summary file; an uncertain delivery is never replayed automatically. Never install AWS, ask for AWS credentials, or copy the Slack key.
 - `devRollForward` / `rcAlignment`: `pushed`, or `pr-pending` with an alignment PR to land by true merge; read `autoMergeRequest.mergeMethod` from `mmi-cli devops read pr view <n> --repo {owner}/{repo} --json autoMergeRequest`: it must be `MERGE`, and `SQUASH` is a stop.
 - `versionFold`, `rcRetirement`, `checkout`: `returned`, or the reason you are still on `main`.