@mutmutco/pi-plugin 4.5.214 → 4.5.216
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.
package/package.json
CHANGED
package/skills/board/SKILL.md
CHANGED
|
@@ -21,7 +21,7 @@ accepts an incomplete board. The CLI partitions rows into **Yours**, **Free to c
|
|
|
21
21
|
stamps (4 hours without work) hold nothing. Partition rules, stamp details and `--out` rationale:
|
|
22
22
|
[reference.md](reference.md).
|
|
23
23
|
|
|
24
|
-
|
|
24
|
+
**Under the App pool, never type raw `gh` for a read** (`gh issue list/view --jq`, `gh run view --jq`, `gh api -q` all bounce). Use `MMI_ACTOR=app mmi-cli devops read issue view <n> --repo <owner/repo> --json <fields>` (or `issue list`, `pr view`, `run view`); `--jq '<expr>'` on that typed read filters locally. Filter in a pipe or save output (`>`, `2>&1`, `--out`) under this worktree's `.jerv/tmp/` (`mkdir -p .jerv/tmp` first), never `../` or a sibling path: the workspace output guard refuses those.
|
|
25
25
|
|
|
26
26
|
## Step 2 — render it
|
|
27
27
|
|
|
@@ -36,7 +36,7 @@ The bible for the MM open design system; every agent doing UI, design or MM Arti
|
|
|
36
36
|
Four owner decisions (2026-10-25T15:35:52Z):
|
|
37
37
|
|
|
38
38
|
1. **Doc vs. app kit — add a Document Design System too.** Keep the MM-Work Atomic Design System (`3a5c79df-5274-40ad-a1b5-a75e67a74dac`) for MM-Work and module app UI (and as the fallback for now), and add a dedicated Document/Editorial Design System Artifact in Live Docs for reports, checklists, decks and client documents made by Junior or agents.
|
|
39
|
-
2. **Where to save — local HTML for dev, Live Docs for shared.** Coding agents build
|
|
39
|
+
2. **Where to save — local HTML for dev, Live Docs for shared.** Coding agents build local `.html` MM Artifacts for fast iteration. Interactive owner A/B reviews use the live loopback HTTP review server (`http://127.0.0.1:<port>/` with `Send answers`); seats send the orchestrator only the review URL and issue number, keep the server running until the owner answers, and never open the owner's browser (#8987, relay wording). Publish to Live Docs only for a shared deliverable, an A/B decision canvas or a Design System. Junior inside MM-Work saves directly to Live Docs.
|
|
40
40
|
3. **Artifact shape — single HTML by default, Canvas for A/B.** A single self-contained HTML view for documents, checklists and single-screen work; a multi-board spatial Canvas only for A/B choices or `1440`/`1024`/`390` side-by-side comparisons.
|
|
41
41
|
4. **Kit binding — Live Docs hosts kits; npm only for MM-Work.** Every Design System Artifact in Live Docs stores its tokens/CSS/components and `DESIGN.md` so any HTML artifact can bind to it (`kit: { id, version }`); only the MM-Work app design system is also exported as `@mutmutco/mmwork-ds`, because the MM-Work app and the 10 suite modules compile against it.
|
|
42
42
|
|
|
@@ -62,6 +62,10 @@ Autolearn watches for ad-hoc build/render/verify scripts under `tmp/`, empty `#r
|
|
|
62
62
|
Settled owner ruling: present clear, distinct choices in the existing MM Artifact viewer, not a
|
|
63
63
|
"shell over a shell". These are authoring and viewer requirements, not proof of installed capabilities.
|
|
64
64
|
|
|
65
|
+
**Canvases carry design choices only (Hub#8986, relay wording).** An A/B canvas asks how something
|
|
66
|
+
looks or works on screen. Approvals for keys, releases, deletions, data access or tooling never go on
|
|
67
|
+
a canvas: send them to the orchestrator, who asks the owner in plain words.
|
|
68
|
+
|
|
65
69
|
1. **No "shell over a shell" — designer agents build only the alternatives, never their own A/B switcher.**
|
|
66
70
|
The outer MM Artifact viewer (the local review shell and `CanvasStage` / `CompareView` in Live Docs)
|
|
67
71
|
already IS the A/B selector shell: it renders the question prompt, Option A / Option B / Neither
|
|
@@ -112,11 +116,12 @@ requests like this should follow this structure, not prose guide."
|
|
|
112
116
|
`distill`, `typeset`, `layout`, `colorize`, `polish`) to create 2–3 genuinely distinct visual
|
|
113
117
|
designs that honor every constraint in the owner's brief: Option A, Option B and optionally
|
|
114
118
|
Option C, each its own full-resolution `1440x900` live HTML board in one MM Artifact A/B canvas
|
|
115
|
-
(Part 3 rules: content-only `Ctrl + Mousewheel` zoom, 1:1 or side-by-side live comparison).
|
|
116
|
-
the verified canvas
|
|
117
|
-
`
|
|
118
|
-
review
|
|
119
|
-
|
|
119
|
+
(Part 3 rules: content-only `Ctrl + Mousewheel` zoom, 1:1 or side-by-side live comparison). Serve
|
|
120
|
+
the verified canvas on the live loopback HTTP review server without opening the owner's browser,
|
|
121
|
+
so the owner's `Send answers` posts straight back to `POST /answers`. Once review passes, send
|
|
122
|
+
the orchestrator only the review URL and issue number and keep the server running through Stage 2;
|
|
123
|
+
the orchestrator opens it on the owner's screen (#8987, relay wording). Never open a `--standalone`
|
|
124
|
+
`file://` export (`Download answers.json`) for an
|
|
120
125
|
interactive owner A/B decision: `--standalone [<out.html>]` is only for offline previews/exports
|
|
121
126
|
and SSR detector checks. Spawn a dedicated, fresh
|
|
122
127
|
`designer` subagent for each distinct design task (item 3); never reuse a busy designer seat.
|
|
@@ -141,9 +146,9 @@ requests like this should follow this structure, not prose guide."
|
|
|
141
146
|
|
|
142
147
|
## Mandatory Impeccable workflow (owner, 2026-10-25; Hub#8814 / MM-Work#7629)
|
|
143
148
|
|
|
144
|
-
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.
|
|
149
|
+
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 design A/B choice is needed (approvals for keys, releases, deletions, data access or tooling go to the orchestrator in plain words, never on a canvas; Hub#8986). Functional journeys, where separately permitted, stay opt-in `workflow_dispatch`-only and never act as design checks.
|
|
145
150
|
|
|
146
|
-
Front-load Impeccable before any UI or MM Artifact authoring: `impeccable context --target <path>`, `DESIGN.md` + the `design.json` sidecar in `.impeccable`, `.impeccable/config.json` (`hook.enabled: true`), `reference/craft-floor.md` + `reference/operate.md`, and `impeccable detect --json <target>`. Local/canvas MM Artifacts (`mm-artifact` v3 format) are checked with one command, `node artifacts/review/review.mjs <folder>`, which runs `check.mjs`, `check-ui.mjs` and `geometry.mjs`, pre-renders the board in `node:vm` (`ReactDOMServer.renderToStaticMarkup` into `#root`) and runs `impeccable detect --json` on that rendered HTML. Interactive owner A/B reviews use
|
|
151
|
+
Front-load Impeccable before any UI or MM Artifact authoring: `impeccable context --target <path>`, `DESIGN.md` + the `design.json` sidecar in `.impeccable`, `.impeccable/config.json` (`hook.enabled: true`), `reference/craft-floor.md` + `reference/operate.md`, and `impeccable detect --json <target>`. Local/canvas MM Artifacts (`mm-artifact` v3 format) are checked with one command, `node artifacts/review/review.mjs <folder>`, which runs `check.mjs`, `check-ui.mjs` and `geometry.mjs`, pre-renders the board in `node:vm` (`ReactDOMServer.renderToStaticMarkup` into `#root`) and runs `impeccable detect --json` on that rendered HTML. Interactive owner A/B reviews use the live loopback HTTP review server (`http://127.0.0.1:<port>/`), where the owner presses `Send answers`; seats never open the owner's browser. Once review passes, send the orchestrator only the review URL and issue number, and keep the server running until the owner answers. The orchestrator opens it on the owner's screen (#8987, relay wording). `--standalone [<out.html>]` is only for offline HTML previews/exports and SSR pre-render verification, never for an interactive owner decision.
|
|
147
152
|
|
|
148
153
|
Impeccable v4.7.0 (engine v0.1.16) workflow; CLI verbs and agent playbooks are distinct:
|
|
149
154
|
|
|
@@ -41,7 +41,10 @@ Owner ruling 2026-10-25 (#8814, #8816, MM-Work#7629; `docs/decisions/2026-10-06-
|
|
|
41
41
|
the required `gate` holds fast deterministic checks only; UI/design uses `@mutmutco/mmwork-ds`
|
|
42
42
|
(`mmwork-check-ui`) and the mandatory Impeccable skill/toolkit. Inspect all applicable toolkit
|
|
43
43
|
capabilities for every design task. Work on the live app; use our own MM Artifacts A/B canvas only
|
|
44
|
-
for owner choices, with live kit pieces and recorded choice ID / owner-decision reference.
|
|
44
|
+
for owner design choices, with live kit pieces and recorded choice ID / owner-decision reference.
|
|
45
|
+
A canvas is for how something looks or works on screen only (#8986, relay wording): approvals for
|
|
46
|
+
keys, releases, deletions, data access or tooling never go on a canvas; send them to the
|
|
47
|
+
orchestrator, who asks the owner in plain words.
|
|
45
48
|
Functional browser journeys remain opt-in `workflow_dispatch`-only, never design checks or gates.
|
|
46
49
|
|
|
47
50
|
## The MM Open Design System Bible (#8837, #8839)
|
|
@@ -65,11 +68,14 @@ design work follows one harmonized **Front-Loaded Impeccable v4.7.0 + MM Artifac
|
|
|
65
68
|
`node artifacts/review/review.mjs <folder>`. It runs `check.mjs`, `check-ui.mjs` and
|
|
66
69
|
`geometry.mjs`, pre-renders the board in `node:vm` via `ReactDOMServer.renderToStaticMarkup` into
|
|
67
70
|
`#root` and runs `impeccable detect --json` on that SSR-rendered HTML. Interactive owner A/B
|
|
68
|
-
reviews use
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
71
|
+
reviews use the live loopback HTTP review server (`http://127.0.0.1:<port>/`), where the owner's
|
|
72
|
+
`Send answers` posts back to `POST /answers`; a seat must not open the owner's browser. An A/B is
|
|
73
|
+
shown as the live canvas link, never as prose (#8987, relay wording). Once the canvas passes review,
|
|
74
|
+
send the orchestrator only the review URL and issue number, and keep the server running until the
|
|
75
|
+
owner answers. The orchestrator opens it on the owner's screen. `--standalone [<out.html>]` is only
|
|
76
|
+
for offline HTML previews/exports and SSR pre-render verification, never for an interactive owner
|
|
77
|
+
decision.
|
|
78
|
+
**Headless seat rule:** `--open` is review.mjs-only; never pass `--open` to `vite`, and never use it from a seat to open the owner's browser for an A/B review.
|
|
73
79
|
Vite parses its value as a URL path, so `vite --open false` opens the owner's real browser at `/false`;
|
|
74
80
|
run dev/preview servers with `BROWSER=none` and no `--open` flag.
|
|
75
81
|
- **Live Docs** (`Canlı belgeler` viewer) carry the living references, including the live
|
|
@@ -89,7 +95,7 @@ How the five pillars fit together (owner, 2026-10-25):
|
|
|
89
95
|
Four owner decisions (2026-10-25T15:35:52Z):
|
|
90
96
|
|
|
91
97
|
1. **Doc vs. app kit — add a Document Design System too.** Keep the MM-Work Atomic Design System (`3a5c79df-5274-40ad-a1b5-a75e67a74dac`) for MM-Work and module app UI (and as the fallback for now), and add a dedicated Document/Editorial Design System Artifact in Live Docs for reports, checklists, decks and client documents made by Junior or agents.
|
|
92
|
-
2. **Where to save — local HTML for dev, Live Docs for shared.** Coding agents build
|
|
98
|
+
2. **Where to save — local HTML for dev, Live Docs for shared.** Coding agents build local `.html` MM Artifacts for fast iteration. For interactive owner A/B reviews, serve the canvas on the live loopback HTTP review server (`http://127.0.0.1:<port>/` with `Send answers`) without opening the owner's browser; relay the URL and issue number to the orchestrator and keep the server running until the owner answers (#8987, relay wording). Use `node artifacts/review/review.mjs <folder> --standalone [<out.html>]` for offline HTML previews/exports or SSR pre-render verification. Publish to Live Docs only for a shared deliverable, an A/B decision canvas or a Design System. Junior inside MM-Work saves directly to Live Docs.
|
|
93
99
|
3. **Artifact shape — single HTML by default, Canvas for A/B.** A single self-contained HTML view for documents, checklists and single-screen work; a multi-board spatial Canvas only for A/B choices or `1440`/`1024`/`390` side-by-side comparisons.
|
|
94
100
|
4. **Kit binding — Live Docs hosts kits; npm only for MM-Work.** Every Design System Artifact in Live Docs stores its tokens/CSS/components and `DESIGN.md` so any HTML artifact can bind to it (`kit: { id, version }`); only the MM-Work app design system is also exported as `@mutmutco/mmwork-ds`, because the MM-Work app and the 10 suite modules compile against it.
|
|
95
101
|
|
|
@@ -211,6 +217,10 @@ agent, and is that improvement filed?
|
|
|
211
217
|
Settled owner ruling: present clear, distinct choices in the existing MM Artifact viewer, not a
|
|
212
218
|
"shell over a shell". These are authoring and viewer requirements, not proof of installed capabilities.
|
|
213
219
|
|
|
220
|
+
**Canvases carry design choices only (#8986, relay wording).** An A/B canvas asks how something
|
|
221
|
+
looks or works on screen. Approvals for keys, releases, deletions, data access or tooling never go on
|
|
222
|
+
a canvas: send them to the orchestrator, who asks the owner in plain words.
|
|
223
|
+
|
|
214
224
|
1. **No "shell over a shell" — designer agents build only the alternatives, never their own A/B switcher.**
|
|
215
225
|
The outer MM Artifact viewer (the local review shell and `CanvasStage` / `CompareView` in Live Docs)
|
|
216
226
|
already IS the A/B selector shell: it renders the question prompt, Option A / Option B / Neither
|
|
@@ -261,11 +271,12 @@ requests like this should follow this structure, not prose guide."
|
|
|
261
271
|
`distill`, `typeset`, `layout`, `colorize`, `polish`) to create 2–3 genuinely distinct visual
|
|
262
272
|
designs that honor every constraint in the owner's brief: Option A, Option B and optionally
|
|
263
273
|
Option C, each its own full-resolution `1440x900` live HTML board in one MM Artifact A/B canvas
|
|
264
|
-
(Part 3 rules: content-only `Ctrl + Mousewheel` zoom, 1:1 or side-by-side live comparison).
|
|
265
|
-
the verified canvas
|
|
266
|
-
`
|
|
267
|
-
|
|
268
|
-
|
|
274
|
+
(Part 3 rules: content-only `Ctrl + Mousewheel` zoom, 1:1 or side-by-side live comparison). Serve
|
|
275
|
+
the verified canvas on the live loopback HTTP review server without opening a browser from the
|
|
276
|
+
seat, so the owner's `Send answers` posts straight back to `POST /answers`. Once review passes,
|
|
277
|
+
send the orchestrator only the review URL and issue number, and keep the server running through
|
|
278
|
+
Stage 2; the orchestrator opens it on the owner's screen (#8987, relay wording). Never open a
|
|
279
|
+
`--standalone` `file://` export (`Download answers.json`) for an
|
|
269
280
|
interactive owner A/B decision: `--standalone [<out.html>]` is only for offline previews/exports
|
|
270
281
|
and SSR detector checks. Spawn a dedicated, fresh
|
|
271
282
|
`designer` subagent for each distinct design task (item 3); never reuse a busy designer seat.
|