@mutmutco/pi-plugin 4.6.24 → 4.6.26

package/package.json

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

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

@@ -114,7 +114,11 @@ requests like this should follow this structure, not prose guide."
      Before building visual A/B boards, use front-loaded **Impeccable v4.7.0** alongside **21st.dev MCP**
      (`https://21st.dev/api/mcp`; verbatim owner ruling: `"we don't need the mcp better design yet,
      impeccable and 21st is enough"`, dropping Better Design MCP) to study high-craft reference patterns,
-     layout proportions, and interaction details. Always translate inspired patterns into zero-GPU
+     layout proportions, and interaction details. Actually query the 21st.dev MCP; in the Phase 0
+     handoff/A-B brief, report the queries issued and returned component/pattern names and IDs
+     (where provided). If unreachable, report the exact error; if empty, report "no results".
+     Neither case supports a 21st inspiration claim. Never describe patterns as 21st-inspired
+     without this query/result record. Always translate inspired patterns into zero-GPU
      `@mutmutco/mmwork-ds` tokens (`--card-blur: none`, `--card-tint-dark: 0%`, `--card-tint-light: 0%`,
      sleek translucent glass cards) and Atomic Design layers; never copy raw third-party CSS/HTML or
      GPU-heavy effects. `MM-Inspo` is strictly a customer/tenant module inside the MM-Work suite, never

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
 
@@ -279,7 +285,11 @@ requests like this should follow this structure, not prose guide."
      Before building visual A/B boards, use front-loaded **Impeccable v4.7.0** alongside **21st.dev MCP**
      (`https://21st.dev/api/mcp`; verbatim owner ruling: `"we don't need the mcp better design yet,
      impeccable and 21st is enough"`, dropping Better Design MCP) to study high-craft reference patterns,
-     layout proportions, and interaction details. Always translate inspired patterns into zero-GPU
+     layout proportions, and interaction details. Actually query the 21st.dev MCP; in the Phase 0
+     handoff/A-B brief, report the queries issued and returned component/pattern names and IDs
+     (where provided). If unreachable, report the exact error; if empty, report "no results".
+     Neither case supports a 21st inspiration claim. Never describe patterns as 21st-inspired
+     without this query/result record. Always translate inspired patterns into zero-GPU
      `@mutmutco/mmwork-ds` tokens (`--card-blur: none`, `--card-tint-dark: 0%`, `--card-tint-light: 0%`,
      sleek translucent glass cards) and Atomic Design layers; never copy raw third-party CSS/HTML or
      GPU-heavy effects. `MM-Inspo` is strictly a customer/tenant module inside the MM-Work suite, never
@@ -301,7 +311,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.