npm - @mutmutco/codex-plugin - Versions diffs - 4.5.204 → 4.5.205 - Mend

@mutmutco/codex-plugin 4.5.204 → 4.5.205

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (6) hide show

package/.codex-plugin/plugin.json +1 -1
package/cli/dist/main.cjs +7 -7
package/cli/package.json +1 -1
package/package.json +1 -1
package/skills/bootstrap/seeds/suite-guide.template.md +50 -2
package/skills/org-guide/references/work-and-releases.md +57 -6

package/.codex-plugin/plugin.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "mmi",
-  "version": "4.5.204",
+  "version": "4.5.205",
   "mmiCompat": "4.x",
   "description": "MMI workflow skills and org gates delivery.",
   "author": {

package/cli/dist/main.cjs CHANGED Viewed

@@ -19309,10 +19309,10 @@ var rollout_plan_default = {
     note: "The v4.0.0 stamp happens at cut time (D6e #4463); until then the candidate is the origin/development head artifacts (built cli/dist + npm pack), identity proven by dist content hash (D6a)."
   },
   baseline: {
-    version: "4.5.204",
-    tag: "v4.5.204",
-    commit: "571bd6b94824",
-    npm: "@mutmutco/cli@4.5.204"
+    version: "4.5.205",
+    tag: "v4.5.205",
+    commit: "218692afd196",
+    npm: "@mutmutco/cli@4.5.205"
   },
   exitCriterion: "fleet-n-of-n",
   hubOnlyShortcut: "forbidden",
@@ -19329,14 +19329,14 @@ var rollout_plan_default = {
           repo: "mutmutco/mmi-hub",
           role: "canary",
           schedule: "train",
-          v3Target: "v4.5.204"
+          v3Target: "v4.5.205"
         }
       ],
       rollbackTrigger: "Any red inside the post-contract soak window: `devops train gate` FAIL attributable to the v4 doors, Hub endpoint health probe failure, a pre-v4 client admitted instead of receiving actionable HTTP 426, or npm consumer install/doctor failure on the v4-only dist.",
       rollback: {
         independent: true,
-        mechanism: "npm dist-tag latest -> 4.5.204 and redeploy the Hub Lambda from tag v4.5.204 (571bd6b94824); installed clients repair via `mmi-cli doctor`. No other cohort is touched.",
-        v3Target: "v4.5.204 (@mutmutco/cli@4.5.204, tag commit 571bd6b94824 \u2014 last known-good release carrying the repo-index v4-only contract)"
+        mechanism: "npm dist-tag latest -> 4.5.205 and redeploy the Hub Lambda from tag v4.5.205 (218692afd196); installed clients repair via `mmi-cli doctor`. No other cohort is touched.",
+        v3Target: "v4.5.205 (@mutmutco/cli@4.5.205, tag commit 218692afd196 \u2014 last known-good release carrying the repo-index v4-only contract)"
       }
     },
     {

package/cli/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "@mutmutco/cli",
-  "version": "4.5.204",
+  "version": "4.5.205",
   "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 CHANGED Viewed

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

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

@@ -21,7 +21,7 @@ The server exposes `/health` and `/module.js`. Register the module's bundle URL,
 ## The MM Open Design System Bible (owner, 2026-10-25; Hub#8837 / Hub#8839)
-The bible for the MM open design system; every agent doing UI, design or MM Artifact work in this module treats it as second nature. Part 1 is how the system is built and used; Part 2 is how agents improve it when it fails them; Part 3 governs A/B choosing architecture and viewer behavior.
+The bible for the MM open design system; every agent doing UI, design or MM Artifact work in this module treats it as second nature. Part 1 is how the system is built and used; Part 2 is how agents improve it when it fails them; Part 3 governs A/B choosing architecture and viewer behavior; Part 4 makes design-spec requests a visual A/B choice before any kit change.
 ### Part 1 — The five pillars (owner, 2026-10-25; Hub#8837)
@@ -42,7 +42,7 @@ Four owner decisions (2026-10-25T15:35:52Z):
 Craft essentials (owner, 2026-10-25; Hub#8839):
-- **Rich module colour and frosted glass — never graywashed.** Use purposeful module tones (`blue`, `coral`, `teal`, `purple`, `terracotta`, `green`, `pink`, `lime`, `cyan`, `magenta`, `fuchsia`) through kit props on `Card` (`tone`, `icon`/`mark`, `edge="bite"`), `Badge`, `Mark` and `Checkbox` (`lead`), backed by the kit's `--card-tint-dark: 34%`, `--card-tint-light: 22%` and `--card-blur`. Never override these tokens locally.
+- **Sleek translucent glass cards and zero GPU usage — never color-washed (`2026-10-25T16:21:19.344Z`).** Cards use sleek, modern translucent glass material (neutral translucent surface with a crisp glass rim, `--card-tint-dark: 0%`, `--card-tint-light: 0%`) rather than color-washed card fills in any theme, and zero GPU-compositing blur or shadow (`--card-blur: none`, `--card-blur-frost: none`, `--frost-see-blur: 0px`, `--glass-blur: none`, `--card-shadow-dark: none`; never `backdrop-filter: blur(...)`). Module tones (`blue`, `coral`, `teal`, `purple`, `terracotta`, `green`, `pink`, `lime`, `cyan`, `magenta`, `fuchsia`) belong on `Badge`, `Mark`, `Checkbox` (`lead`), and card `icon`/`mark` accents (`edge="bite"`).
 - **Surface modes.** After `impeccable context --target <path>`, `DESIGN.md` and `reference/craft-floor.md`, choose the surface mode (`Operate`, `Read`, `Persuade` or `Experience`) and load the matching playbooks (`shape`, `distill`, `typeset`, `layout`, `colorize`, `clarify`, `polish`, `harden`, `adapt`) before writing markup.
 - **Restraint and hierarchy.** Group related items into section `Card`s (`heading: 2` under the page `<h1>`), keep main-column rows concise (`Cluster` with `fill` = `Checkbox` plus one trailing action), and put multi-line inspector detail in the right-hand `HelperCard` as `Stack` + `Text` — never `DataList`, which clips multi-line prose.
 - **Verify SSR pre-rendered HTML.** `impeccable detect --json` is blind on an unrendered `<div id="root"></div>` file; verify the output of `review.mjs <folder> --standalone --open`, which pre-renders into `#root`. An empty `#root`, missing fonts or an unrendered detector run is a failure, not a pass.
@@ -86,6 +86,54 @@ Settled owner ruling: present clear, distinct choices in the existing MM Artifac
    viewer zoom controls must keep the outer A/B selector shell, question bar and controls at a fixed
    1:1 UI size.
+### Part 4 — Visual A/B Choice via Designer Subagent Before Kit Implementation — Never Prose Specs (owner ruling 2026-10-25T16:29:46.339Z, #8844, #8846, #8848)
+Settled owner ruling (verbatim): "You should use a designer to create a couple card designs with my
+specifications and then let me choose then build the complete spec into the design system, replacing
+any other card available atomically. That's the proper way to do it. Learn from this mistake of yours,
+requests like this should follow this structure, not prose guide."
+1. **Never reply with a prose specification in chat or jump straight to kit implementation.**
+   When the owner asks to "design the spec for X and add it to the design system" (for example, The One
+   Card), writing a markdown or prose spec in chat violates Principle 7 ("Choices for Jervaise go only
+   on the A/B canvas"). Building one guessed design straight into the kit skips the owner's choice.
+2. **Always follow the visual spec pipeline:**
+   - **Phase 0 — Inspiration via Better Design MCP (`https://better-design.com/api/mcp`) and 21st.dev MCP (`https://21st.dev/api/mcp`) (owner ruling 2026-10-25T16:48:00Z, #8848).**
+     Before building visual A/B boards, query the two owner-selected prebuilt design inspiration MCP
+     servers — **Better Design MCP** (`https://better-design.com/api/mcp`) and **21st.dev MCP**
+     (`https://21st.dev/api/mcp`, verbatim selection: `"21st.dev MCP Better Design MCP"`) — alongside
+     front-loaded Impeccable to study high-craft reference patterns, layout proportions, and interaction
+     details. 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 an internal tool
+     for designing the MM-Work app or its design system.
+   - **Stage 1 — a designer subagent builds visual A/B alternatives on an MM Artifact canvas.**
+     Dispatch a `designer` subagent with front-loaded Impeccable (`impeccable context`, `craft-floor`,
+     `distill`, `typeset`, `layout`, `colorize`, `polish`) to create 2–3 genuinely distinct visual
+     designs that honor every constraint in the owner's brief: Option A, Option B and optionally
+     Option C, each its own full-resolution `1440x900` live HTML board in one MM Artifact A/B canvas
+     (Part 3 rules: content-only `Ctrl + Mousewheel` zoom, 1:1 or side-by-side live comparison). Open
+     the verified canvas in the browser automatically with
+     `node artifacts/review/review.mjs <folder> --standalone --open`. Spawn a dedicated, fresh
+     `designer` subagent for each distinct design task (item 3); never reuse a busy designer seat.
+   - **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. 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,
+     **atomically replacing** every other legacy or competing variant of that piece across the design
+     system, publish it to `Canlı belgeler` / MM-Work, and propagate it to all 10 suite modules.
+3. **One dedicated `designer` subagent per distinct design task — never overload a designer seat
+   (owner ruling 2026-10-25T16:33:00Z, #8846).**
+   Settled owner ruling (verbatim): "The lead designer sent the card building to the same designer
+   agent, overloading it. I don't think it was a wise idea. Please learn from this."
+   Spawn a separate, fresh `designer` subagent in its own isolated lane for each distinct design task
+   or visual A/B canvas (for example, a theme A/B exploration vs. a unified Card spec A/B). Never steer
+   or queue a second unrelated design task onto an active `designer` seat: overloading one
+   `designer` subagent serializes work that should run in parallel, bloats its context window, and
+   degrades craft quality.
 ## Mandatory Impeccable workflow (owner, 2026-10-25; Hub#8814 / MM-Work#7629)
 UI and design verification uses `@mutmutco/mmwork-ds` (`mmwork-check-ui`) plus Impeccable on every design task: inspect the toolkit for applicable capabilities, work directly on the live app, and use our own MM Artifacts A/B canvas only when an owner A/B choice is needed. Functional journeys, where separately permitted, stay opt-in `workflow_dispatch`-only and never act as design checks.

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

@@ -39,7 +39,7 @@ Functional browser journeys remain opt-in `workflow_dispatch`-only, never design
 This is the bible for the MM open design system: every agent doing UI, design, document or MM
 Artifact work reads it first and treats it as second nature. Part 1 says how the system is built and
 used; Part 2 says how agents improve it when it fails them; Part 3 governs A/B choosing architecture
-and viewer behavior.
+and viewer behavior; Part 4 makes design-spec requests a visual A/B choice before any kit change.
 ### Part 1 — The five pillars of the MM Open Design System
@@ -103,11 +103,14 @@ Impeccable **v4.7.0 / engine v0.1.16** details:
 Craft essentials every agent applies (owner, 2026-10-25, #8839):
-- **Rich module colour and frosted glass — never graywashed.** Give surfaces purposeful module
-  tones (`blue`, `coral`, `teal`, `purple`, `terracotta`, `green`, `pink`, `lime`, `cyan`, `magenta`,
-  `fuchsia`) through kit props: `Card` (`tone`, `icon`/`mark`, `edge="bite"`), `Badge`, `Mark` and
-  `Checkbox` (`lead`). The kit backs them with `--card-tint-dark: 34%`, `--card-tint-light: 22%`
-  and `--card-blur`; never override these tokens locally or flatten a module to gray.
+- **Sleek translucent glass cards and zero GPU usage — never color-washed
+  (`2026-10-25T16:21:19.344Z`).** Cards use sleek, modern translucent glass material (neutral
+  translucent surface with a crisp glass rim, `--card-tint-dark: 0%`, `--card-tint-light: 0%`)
+  rather than color-washed card fills in any theme, and zero GPU-compositing blur or shadow
+  (`--card-blur: none`, `--card-blur-frost: none`, `--frost-see-blur: 0px`, `--glass-blur: none`,
+  `--card-shadow-dark: none`; never `backdrop-filter: blur(...)`). Module tones (`blue`, `coral`,
+  `teal`, `purple`, `terracotta`, `green`, `pink`, `lime`, `cyan`, `magenta`, `fuchsia`)
+  belong on `Badge`, `Mark`, `Checkbox` (`lead`), and card `icon`/`mark` accents (`edge="bite"`).
 - **Front-loaded Impeccable v4.7.0, in front of creation.** Run `impeccable context --target <path>`,
   read `DESIGN.md` and `reference/craft-floor.md`, choose the surface mode (`Operate`, `Read`,
   `Persuade` or `Experience`) and load the matching playbooks (`shape`, `distill`, `typeset`,
@@ -178,6 +181,54 @@ Settled owner ruling: present clear, distinct choices in the existing MM Artifac
    viewer zoom controls must keep the outer A/B selector shell, question bar and controls at a fixed
    1:1 UI size.
+### Part 4 — Visual A/B Choice via Designer Subagent Before Kit Implementation — Never Prose Specs (owner ruling 2026-10-25T16:29:46.339Z, #8844, #8846, #8848)
+Settled owner ruling (verbatim): "You should use a designer to create a couple card designs with my
+specifications and then let me choose then build the complete spec into the design system, replacing
+any other card available atomically. That's the proper way to do it. Learn from this mistake of yours,
+requests like this should follow this structure, not prose guide."
+1. **Never reply with a prose specification in chat or jump straight to kit implementation.**
+   When the owner asks to "design the spec for X and add it to the design system" (for example, The One
+   Card), writing a markdown or prose spec in chat violates Principle 7 ("Choices for Jervaise go only
+   on the A/B canvas"). Building one guessed design straight into the kit skips the owner's choice.
+2. **Always follow the visual spec pipeline:**
+   - **Phase 0 — Inspiration via Better Design MCP (`https://better-design.com/api/mcp`) and 21st.dev MCP (`https://21st.dev/api/mcp`) (owner ruling 2026-10-25T16:48:00Z, #8848).**
+     Before building visual A/B boards, query the two owner-selected prebuilt design inspiration MCP
+     servers — **Better Design MCP** (`https://better-design.com/api/mcp`) and **21st.dev MCP**
+     (`https://21st.dev/api/mcp`, verbatim selection: `"21st.dev MCP Better Design MCP"`) — alongside
+     front-loaded Impeccable to study high-craft reference patterns, layout proportions, and interaction
+     details. 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 an internal tool
+     for designing the MM-Work app or its design system.
+   - **Stage 1 — a designer subagent builds visual A/B alternatives on an MM Artifact canvas.**
+     Dispatch a `designer` subagent with front-loaded Impeccable (`impeccable context`, `craft-floor`,
+     `distill`, `typeset`, `layout`, `colorize`, `polish`) to create 2–3 genuinely distinct visual
+     designs that honor every constraint in the owner's brief: Option A, Option B and optionally
+     Option C, each its own full-resolution `1440x900` live HTML board in one MM Artifact A/B canvas
+     (Part 3 rules: content-only `Ctrl + Mousewheel` zoom, 1:1 or side-by-side live comparison). Open
+     the verified canvas in the browser automatically with
+     `node artifacts/review/review.mjs <folder> --standalone --open`. Spawn a dedicated, fresh
+     `designer` subagent for each distinct design task (item 3); never reuse a busy designer seat.
+   - **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. 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,
+     **atomically replacing** every other legacy or competing variant of that piece across the design
+     system, publish it to `Canlı belgeler` / MM-Work, and propagate it to all 10 suite modules.
+3. **One dedicated `designer` subagent per distinct design task — never overload a designer seat
+   (owner ruling 2026-10-25T16:33:00Z, #8846).**
+   Settled owner ruling (verbatim): "The lead designer sent the card building to the same designer
+   agent, overloading it. I don't think it was a wise idea. Please learn from this."
+   Spawn a separate, fresh `designer` subagent in its own isolated lane for each distinct design task
+   or visual A/B canvas (for example, a theme A/B exploration vs. a unified Card spec A/B). Never steer
+   or queue a second unrelated design task onto an active `designer` seat: overloading one
+   `designer` subagent serializes work that should run in parallel, bloats its context window, and
+   degrades craft quality.
 ## Documentation preflight
 Before each push or PR, follow this order: