@mutmutco/codex-plugin 4.6.4 → 4.6.6

package/cli/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mutmutco/cli",
-  "version": "4.6.4",
+  "version": "4.6.6",
   "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/codex-plugin",
-  "version": "4.6.4",
+  "version": "4.6.6",
   "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
 
@@ -165,7 +165,11 @@ that actually ships in the cut: the train refuses an issue or PR number the rele
 commit, so build and verify the lines from one pass over that range —
 `git log --stat --format='%h %s%n%b' origin/main..origin/development`, which carries each commit's
 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
+in that output does not go in the file. Release recovery can re-cut the same `v*` tag on a new SHA, so
+other checkouts still holding the old tag reject a plain `git fetch origin --tags` (`would clobber existing tag`);
+refresh tags with `git fetch origin --tags --force` (or `git fetch origin '+refs/tags/*:refs/tags/*'`) and
+never chain a plain tag fetch with `&&` ahead of a read-only `git log <tag>..origin/<branch>` range (#9517).
+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. 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.