@mutmutco/codex-plugin 4.6.24 → 4.6.25

package/cli/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mutmutco/cli",
-  "version": "4.6.24",
+  "version": "4.6.25",
   "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.24",
+  "version": "4.6.25",
   "description": "MMI workflow skills and org gates delivery.",
   "author": {
     "name": "MMI Future",

package/skills/org-guide/SKILL.md

@@ -11,6 +11,7 @@ Read this entry before MMI work, then **only the relevant topic**. Human intro:
 
 - Install `@mutmutco/hub` via npm, run `mmi-hub install`, keep auto-updates enabled, check `mmi-hub status`.
 - Use the two-tier vault and keyless workflows; never put secrets in chat, logs, CLI args, or env files.
+- Never build products on the owner's personal Jerv tooling ([rules](references/repository-rules.md#personal-tooling-is-never-a-product-dependency)).
 - Agent instructions and host settings stay local/gitignored; never commit AGENTS.md, CLAUDE.md, or copied plugin instructions.
 - Update affected `docs/Guides/operator.md` instructions with code; commit, then fast preflight before pushes/PRs.
 - Claim work via the board, run repo checks, land via MMI. Help/plan requests never authorize edits or releases.
@@ -24,7 +25,6 @@ Read this entry before MMI work, then **only the relevant topic**. Human intro:
 | Task | Local reference |
 | --- | --- |
 | Install, update, reload, or diagnose tooling | [Getting started](references/getting-started.md) |
-| Report a tooling bug with developer consent | [Tooling bug reports](references/work-and-releases.md#report-mmi-tooling-bugs) |
 | Work an issue, test, merge, or release | [Work and releases](references/work-and-releases.md) |
 | Do UI, design, docs, or MM Artifact work, incl. the Design System Bible | [Design](references/design.md) |
 | Consume, declare, rotate, or request a secret | [Vault and keyless access](references/vault.md) |

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

@@ -166,6 +166,12 @@ Craft essentials every agent applies (owner, 2026-10-25, #8839):
   `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).
+- **Live-URL detect runs through the checked matrix mode (#9785):** call
+  `node scripts/design-pack-render.mjs --detect <url[,url...]> --widths 1440,390 --themes dark,light`
+  instead of looping `impeccable detect` with shell redirection — it runs one
+  `detect <url> --viewport WxH --json` per URL x width x theme (theme merged into the URL query),
+  writes one validated `check.json`, and treats empty or unparseable detect output as an operational
+  failure that names the run with the captured stderr, never a clean pass.
 
 ### Shared support-script invocation
 
@@ -301,7 +307,8 @@ requests like this should follow this structure, not prose guide."
    - **Stage 2 — the owner chooses visually on the A/B canvas.** Wait while the owner inspects the
      live HTML alternatives, zooms into details and picks the preferred design or asks for
      adjustments, then presses `Send answers` on the live review server page; `review.mjs` writes
-     `answers.json` into the canvas folder and exits. Record the canvas choice ID and the
+     `answers.json` and delivers it as an issue comment and an intercom `answer` to the session named in
+     `artifact.json` `review.requester`, so the asking agent wakes. Record the canvas choice ID and the
      owner-decision reference.
    - **Stage 3 — atomic replacement in the kit source.** Only AFTER the owner picks on the A/B canvas,
      build the chosen design into the source folder of packages/mmwork-ds in mutmutco/MM-Work,

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

@@ -29,3 +29,7 @@ Use `mmi-cli tests policy --base <comparison-base>` and the repository's own che
 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.
+
+## Personal tooling is never a product dependency
+
+MM-Work and its modules are a SaaS product built by several developers. The Jerv stack (Jerv Gateway, JervCode, Jerv-Hub and the Jerv vault) is the owner's personal tooling. The owner may use it while he develops. No code, integration, grant request, runtime data path, CI job, script or setup step in a non-Jerv repository may depend on it: other developers do not have it, and customers never will. Product integrations (Slack, Google, mail, storage) get their own app registration and credentials through the org vault and keyless workflows. If a feature seems to need Jerv tooling, file the missing product capability on the owning board instead. Origin: 2 Nov 2026, MM-Chat Slack pins were wired through the Jerv Gateway (Jerv-Hub#2623, MM-Chat#2119); the owner ruled it out.