@mutmutco/claude-plugin 4.5.200 → 4.5.202

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "mmi",
   "displayName": "MMI",
-  "version": "4.5.200",
+  "version": "4.5.202",
   "mmiCompat": "4.x",
   "description": "MMI workflow skills and org gates delivery.",
   "author": {

package/cli/dist/main.cjs

@@ -1595,7 +1595,6 @@ __export(index_exports, {
   argvWantsJson: () => argvWantsJson3,
   awsCallerArn: () => awsCallerArn,
   ciAuditDeps: () => ciAuditDeps2,
-  classifyParseError: () => classifyParseError,
   commandOwnLongFlags: () => commandOwnLongFlags,
   envHealLockPath: () => envHealLockPath,
   isOrgRegisteredRepo: () => isOrgRegisteredRepo,
@@ -6299,6 +6298,31 @@ function excessArgumentMessage(extra, corrected) {
   const head = `unexpected positional argument ${list} \u2014 this command does not take it`;
   return corrected ? `${head}. Did you mean \`${corrected}\`?` : head;
 }
+function boardClaimStatusFlagRecovery(flag, canonicalPath, argv) {
+  if (canonicalPath !== "oracle board claim") return void 0;
+  if (flag !== "--status" && !flag.startsWith("--status=")) return void 0;
+  const kept = [];
+  for (let i = 0; i < argv.length; i++) {
+    const tok = argv[i];
+    if (tok.startsWith("--status=")) continue;
+    if (tok === "--status") {
+      if (i + 1 < argv.length && !argv[i + 1].startsWith("-")) i++;
+      continue;
+    }
+    kept.push(tok);
+  }
+  return {
+    message: "unknown option '--status' \u2014 `oracle board claim` automatically sets status to In Progress; retry without --status and its value",
+    corrected: `mmi-cli ${kept.join(" ")}`
+  };
+}
+function classifyParseError(plain) {
+  if (/unknown command/i.test(plain)) return "unknown-command";
+  if (/unknown option|missing required argument|too many arguments|argument missing|is invalid\. Allowed choices are|cannot be used with/i.test(plain)) {
+    return "bad-arguments";
+  }
+  return "other";
+}
 
 // src/released-version-cache.ts
 var import_node_fs10 = require("node:fs");
@@ -19279,10 +19303,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.200",
-    tag: "v4.5.200",
-    commit: "331035205b9a",
-    npm: "@mutmutco/cli@4.5.200"
+    version: "4.5.202",
+    tag: "v4.5.202",
+    commit: "e1fe495d9b63",
+    npm: "@mutmutco/cli@4.5.202"
   },
   exitCriterion: "fleet-n-of-n",
   hubOnlyShortcut: "forbidden",
@@ -19299,14 +19323,14 @@ var rollout_plan_default = {
           repo: "mutmutco/mmi-hub",
           role: "canary",
           schedule: "train",
-          v3Target: "v4.5.200"
+          v3Target: "v4.5.202"
         }
       ],
       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.200 and redeploy the Hub Lambda from tag v4.5.200 (331035205b9a); installed clients repair via `mmi-cli doctor`. No other cohort is touched.",
-        v3Target: "v4.5.200 (@mutmutco/cli@4.5.200, tag commit 331035205b9a \u2014 last known-good release carrying the repo-index v4-only contract)"
+        mechanism: "npm dist-tag latest -> 4.5.202 and redeploy the Hub Lambda from tag v4.5.202 (e1fe495d9b63); installed clients repair via `mmi-cli doctor`. No other cohort is touched.",
+        v3Target: "v4.5.202 (@mutmutco/cli@4.5.202, tag commit e1fe495d9b63 \u2014 last known-good release carrying the repo-index v4-only contract)"
       }
     },
     {
@@ -57958,13 +57982,7 @@ var DISCOVERY_HINT = "run `mmi-cli commands` for the agentic-coding map, `mmi-cl
 var STALE_HINT = `(${DISCOVERY_HINT}). If you expected this command to exist, your installed tooling may be stale \u2014 run \`mmi-hub update\`, then retry`;
 var lastParseErrorKind = "other";
 var lastUnknownCommand;
-function classifyParseError(plain) {
-  if (/unknown command/i.test(plain)) return "unknown-command";
-  if (/unknown option|missing required argument|too many arguments|argument missing|is invalid\. Allowed choices are/i.test(plain)) {
-    return "bad-arguments";
-  }
-  return "other";
-}
+var lastParseErrorConflict = false;
 function parseInvalidChoiceError(plain) {
   const m = /option '([^']+)' argument '([^']*)' is invalid\. Allowed choices are ([^.]+)\./.exec(plain);
   if (!m) return void 0;
@@ -58045,7 +58063,7 @@ function resolveParseHint() {
   const path2 = canonicalPathFor(commandPath3(cmd));
   return [
     `Usage: mmi-cli ${path2} ${cmd.usage()}`,
-    "This command exists and your mmi-cli is not the problem \u2014 the ARGUMENTS did not parse.",
+    lastParseErrorConflict ? "This command exists and your mmi-cli is not the problem \u2014 two of the options conflict. Choose one of them and retry." : "This command exists and your mmi-cli is not the problem \u2014 the ARGUMENTS did not parse.",
     `Run \`mmi-cli ${path2} --help\` for its signature, \`mmi-cli explain ${path2} --json\` for exact detail, or \`mmi-cli commands\` for the task map.`
   ].join("\n");
 }
@@ -58101,6 +58119,7 @@ function envelopeAwareWriteErr(str2) {
     return;
   }
   lastParseErrorKind = classifyParseError(plain);
+  lastParseErrorConflict = /cannot be used with/i.test(plain);
   lastUnknownCommand = /unknown command '?([\w:-]+)'?/.exec(plain)?.[1];
   const badChoice = parseInvalidChoiceError(plain);
   if (badChoice) {
@@ -58141,6 +58160,24 @@ function envelopeAwareWriteErr(str2) {
     const flag = match[1];
     const argv = process.argv.slice(2);
     const invoked = resolveCommandFromArgv(program2, argv);
+    const claimStatus = invoked ? boardClaimStatusFlagRecovery(flag, canonicalPathFor(commandPath3(invoked)) ?? commandPath3(invoked), canonicalArgvFor(argv)) : void 0;
+    if (claimStatus) {
+      if (argvWantsJson3()) {
+        process.stderr.write(
+          formatErrorEnvelope(claimStatus.message, {
+            code: ERROR_CODES.ERR_UNKNOWN_FLAG,
+            offending_flag: "--status",
+            corrected_command: claimStatus.corrected
+          }) + "\n"
+        );
+        unknownFlagJsonHandled = true;
+        return;
+      }
+      writeHumanParseError(
+        str2.replace(/unknown option '[^']+'/, `${claimStatus.message}: run \`${claimStatus.corrected}\``)
+      );
+      return;
+    }
     const positional = TARGET_SELECTOR_FLAGS.has(flag) ? positionalTargetForm(invoked, { flag, argv }) : void 0;
     if (argvWantsJson3()) {
       const ownFlags = commandOwnLongFlags(invoked);
@@ -59367,7 +59404,6 @@ program2.parseAsync(process.argv).then(() => finishCliRun()).catch((e) => failGr
   argvWantsJson,
   awsCallerArn,
   ciAuditDeps,
-  classifyParseError,
   commandOwnLongFlags,
   envHealLockPath,
   isOrgRegisteredRepo,

package/cli/package.json

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

package/skills/bootstrap/seeds/browser-pass.template.yml

@@ -2,6 +2,9 @@ name: browser-pass
 # OPT-IN: copy to .github/workflows/browser-pass.yml, edit the dev URL, and replace
 # {{BROWSER_PASS_SHA}} with a reviewed 40-character Hub commit containing browser-pass.yml.
 # Never add PR, push, merge_group or gate callers. Not installed by bootstrap/propagation.
+# Owner 2026-10-25 (#8814, #8816): functional journeys only, workflow_dispatch-only, never design checks.
+# UI/design verification uses @mutmutco/mmwork-ds (mmwork-check-ui) and the Impeccable v4.7.0 toolkit
+# (context, hooks on, detect --json, critique, audit, playbooks); MM Artifacts A/B canvas for owner choices.
 on:
   workflow_dispatch:
     inputs:

package/skills/bootstrap/seeds/gate.template.yml

@@ -3,10 +3,12 @@ name: gate
 # and v* tags so /release and /hotfix can discover required contexts on the tagged SHA.
 #
 # Runner: self-hosted mmi-runner (mmi-live) — see docs/Guides/gh-runner-runbook.md in MMI-Hub.
-# #7914 (owner, 2026-10-06): this gate holds only fast, deterministic checks. Browser and long suites
-#   (screens, geometry/motion, synthetic, Chrome renders and tests) never go here; they run in their own
-#   workflow, nightly through the Hub schedule plane and on demand (docs/decisions/2026-10-06-browser-checks-nightly.md).
-# #4118: if GATE_CMD runs tsgo or other memory-heavy typecheck / browser work, pin this job to
+# #8814 / #8816 (owner, 2026-10-25): fast deterministic checks only (lint, types, build, unit/db tests).
+# UI/design uses @mutmutco/mmwork-ds (mmwork-check-ui) plus the Impeccable v4.7.0 skill/toolkit:
+# context, hooks on, detect --json, critique, audit and refinement playbooks. Use our own MM Artifacts
+# A/B canvas only when an owner A/B choice is needed.
+# Functional browser journeys remain opt-in workflow_dispatch-only, never a required gate.
+# #4118: if GATE_CMD runs tsgo or other memory-heavy typecheck/build work, pin this job to
 #   runs-on: [self-hosted, linux, x64, mmi-heavy]
 # instead — standard lanes are MemoryMax=1200M and will cgroup-OOM those workloads.
 # Stack-aware (#1550): the runtime is rendered into the setup-step `if:` — both the Node and Python

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

@@ -1,6 +1,6 @@
 # MM-Work module
 
-Read the matching `module/node_modules/@mutmutco/mmwork-ds/GUIDE.md` before changing this module. The starter entry and Vite setting come from MM-Work's `examples/example-module`; replace the example screens with your product's screens using only the shared design system.
+Use the MM-Work Atomic Design v1.1.0 contract and Designer Card. Query only task pieces/import ancestry through kit MCP or `catalog.json`, then the relevant contract/GUIDE section, never the whole registry or GUIDE. The starter entry and Vite setting come from MM-Work's `examples/example-module`; replace the example screens using only existing shared kit pieces, templates and tokens. Report the installed kit version and available checks separately from contract identity; missing information stays unknown with a lookup action.
 
 Sign-in belongs to MM-Work: verify its pass before adding protected backend routes. Do not provision a Google OAuth client or implement a separate login. Google and other shared services are reached through `ctx.act`, not module-owned credentials.
 
@@ -8,4 +8,26 @@ Before the first CI/deploy, an org admin must grant this repo **Read** on `@mutm
 
 The server exposes `/health` and `/module.js`. Register the module's bundle URL, id, name and capabilities with MM-Work following the GUIDE. The seed deliberately exposes no authenticated product API yet.
 
-`gate` installs and checks the backend and module. Product repos carry no screenshot or browser tests (owner ruling 2026-10-15, MM-Work#5388).
+`gate` installs and checks the backend and module, including `mmwork-check-ui` from `@mutmutco/mmwork-ds`. Gates run fast deterministic checks only (owner rulings 2026-10-15, MM-Work#5388, and 2026-10-25, MM-Work#7629).
+
+## How the design pipeline reaches this module (owner, 2026-10-25; MM-Work#7651 / MM-Work#7654 / Hub#8827)
+
+1. **Single source of truth:** the source folder of `packages/mmwork-ds` in `mutmutco/MM-Work`, owned by the MM-Work Design Lead (tokens, layers, component bundle, component docs, `DESIGN.md` and its `design.json` sidecar). Never edit the kit or its copies here; a missing piece or variant is built there first, or requested via kit MCP `request_piece`.
+2. **MM Artifact on Live Docs:** Live Docs (`Canlı belgeler / MM-Work`) displays document `3a5c79df-5274-40ad-a1b5-a75e67a74dac` (ATOMIC, module `mm-work-kit`), an MM Artifact in the `design-system` format rebuilt from the kit source on every kit release: Overview, Guide (kit README + `DESIGN.md`), Tokens, Atoms, Molecules, Organisms, Templates and Files. Browse it to see every piece live.
+3. **Impeccable knows Atomic Design at boot:** `impeccable context` loads `PRODUCT.md`, `DESIGN.md` and the `design.json` sidecar in `.impeccable`, which carry the Atomic Design contract 1.1.0: `Atoms -> Molecules -> Organisms -> Templates -> Pages`, upward-only composition enforced by `npx mmwork-check-ui --rules=all`. Pages arrange exported `@mutmutco/mmwork-ds` pieces around one template and never paint custom controls, raw `<button>`/`<input>`, `mw-*` classes, inline visual styles or raw hex/px values.
+4. **Automatic propagation:** on every kit release the Hub kit-adopt workflow opens an adoption PR here that bumps `@mutmutco/mmwork-ds`, runs `mmwork-sync-impeccable`, and writes `DESIGN.md`, the `.impeccable` design manifest and `.impeccable/config.json` (`hook.enabled: true`) at the repository root, and deletes any stale copies under `module/`. These files are kit-owned: do not hand-edit them, and keep them committed even if `.impeccable/` is ignored (the adoption PR force-stages them).
+5. **Root only:** `PRODUCT.md`, `DESIGN.md`, the `.impeccable` design manifest and `.impeccable/config.json` live only at this repository's root, never duplicated under `module/`; a copy there makes Impeccable treat `module/` as a separate root without `PRODUCT.md` and the config. Run `impeccable context` from the root. Any suite-wide propagation of these files needs an explicit intercom ACK handshake with the MM-Work Design Lead naming the files written and removed, `impeccable context` + `impeccable doctor --json` verification, and the issue/PR reference.
+
+## 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.
+
+Impeccable v4.7.0 (engine v0.1.16) workflow; CLI verbs and agent playbooks are distinct:
+
+1. Boot once with `impeccable context --target <path>`. Use the `init` playbook for durable PRODUCT.md context, `document` for DESIGN.md + `.impeccable/design.json`, `impeccable doctor --json` to report drift, and `extract` to identify reuse. Read `reference/craft-floor.md` immediately before UI edits and `reference/operate.md` for task-oriented app UI. Extract through the existing kit; only the Design Lead can authorize kit changes.
+2. Run `impeccable hooks on`: shared `.impeccable/config.json` enables hooks; private overrides/consent live in gitignored `.impeccable/config.local.json`. Tier 1 scans mechanical issues per edit; Tier 2 runs a deep scan at turn-end `Stop` on supported hosts. Hook support is host-specific: verify `hooks status`; hosts without automatic hooks must run the manual detector. `impeccable detect --json <target>` exits **0 clean / 2 findings**; crashes or malformed output are failures, not clean passes. Source scans need markup files/directories, not CSS-only targets.
+3. Use the dual-subagent `critique` playbook, persisting through `critique-storage`, and `audit` (accessibility, performance, theming, responsive design, implementation integrity; five dimensions scored 0–4, **20 points** total). Keep independent design judgment separate from detector evidence; disclose degraded runs and unavailable checks. Still inspect the live result.
+4. Select applicable refinement/enhancement/fix playbooks, not every playbook blindly: `polish`, `bolder`, `quieter`, `distill`, `harden`, `onboard`, `layout`, `typeset`, `colorize`, `animate`, `delight`, `overdrive`, `clarify`, `adapt`, `optimize` (15 names in v4.7.0).
+5. Iterate live with `live` and `generate` (`live-generate`, `live-poll`, `live-server`). `serve-question` supports choices; MM-Work owner choices use the MM Artifacts review canvas with live kit pieces, never loose pictures. Record canvas choice ID and owner-decision reference; no A/B needed means no canvas. Stop temporary servers when finished.
+
+Check installed skill/engine versions and the approved upstream update channel before design work; apply available updates through the owning installer, not by modifying shared skill files from a module task. Shared config alone does not prove hook installation or CI toolkit availability. Record piece/import provenance and command + exit + findings in the task/PR; neither agent reports nor detector success establish conformance.

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

@@ -27,11 +27,36 @@ Open a PR through `mmi-cli devops pr create` with a closing issue link, and land
 `mmi-cli devops pr land`. Verify required checks, merge, issue closure, and cleanup before calling
 the implementation complete. A merged implementation is not a production release.
 
-Browser checks and long CI run nightly, never as PR checks (owner, 2026-10-06;
-`docs/decisions/2026-10-06-browser-checks-nightly.md`). The required `gate` holds only fast,
-deterministic checks. Screen, geometry, motion, synthetic and Chrome suites run in a separate
-workflow armed nightly through the Hub schedule plane and on demand; it is never required, and a red
-run updates one `ci-heavy-red` issue. Never add such a suite to a gate or a local test policy.
+Owner ruling 2026-10-25 (#8814, #8816, MM-Work#7629; `docs/decisions/2026-10-06-browser-checks-nightly.md`):
+the required `gate` holds fast deterministic checks only; UI/design uses `@mutmutco/mmwork-ds`
+(`mmwork-check-ui`) and the mandatory Impeccable skill/toolkit. Inspect all applicable toolkit
+capabilities for every design task. Work on the live app; use our own MM Artifacts A/B canvas only
+for owner choices, with live kit pieces and recorded choice ID / owner-decision reference.
+Functional browser journeys remain opt-in `workflow_dispatch`-only, never design checks or gates.
+
+Impeccable **v4.7.0 / engine v0.1.16** workflow:
+
+- 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
+  `reference/craft-floor.md` before UI edits and `reference/operate.md` for app UI.
+- `impeccable hooks on` enables shared `.impeccable/config.json`; local overrides/consent belong in
+  ignored `.impeccable/config.local.json`. Tier 1 scans mechanical problems per edit; Tier 2 deep-scans
+  at turn-end `Stop` on supported hosts. Verify `hooks status` and host support, not config alone.
+  If automatic hooks are unavailable, run `impeccable detect --json <target>` manually on markup
+  files/directories (not CSS-only): **0 clean / 2 findings**. Unavailable or broken scans are not passes.
+- Dual-subagent `critique` keeps design assessment independent from detector evidence and persists via
+  `critique-storage`; disclose degraded runs. `audit` scores accessibility, performance, theming,
+  responsive design and implementation integrity 0–4 each (**20 points**). These evaluations are
+  agent playbooks, not standalone engine CLI verbs; still inspect the live result.
+- Pick relevant playbooks: `polish`, `bolder`, `quieter`, `distill`, `harden`, `onboard`, `layout`,
+  `typeset`, `colorize`, `animate`, `delight`, `overdrive`, `clarify`, `adapt`, `optimize` (15 names in
+  v4.7.0, despite the requested “14”). Do not apply conflicting playbooks blindly.
+- Iterate with `live` / `generate` (`live-generate`, `live-poll`, `live-server`); `serve-question`
+  supports choices, while owner A/B decisions use the MM Artifacts canvas.
+  Stop temporary servers. Check installed versions and approved upstream updates via the owning
+  installer; do not modify shared skills from a module task. Record command + exit + findings,
+  kit version and available checks separately from contract identity; reports are not conformance.
 
 ## Documentation preflight
 

package/skills/rcand/suite.md

@@ -1,2 +1,4 @@
 In the suite lead (MM-Work) a plain rcand, release or hotfix refuses: run `mmi-cli devops suite rcand --owner-go` or `mmi-cli devops suite release --owner-go` instead (a lead-only cut needs `--suite-solo --owner-go`). A suite member cannot run standalone rcand, release or hotfix: cut from the suite lead; only a backward-compatible solo backend release/hotfix with explicit owner approval may pass `--suite-solo --owner-go`, and its MM-Work development pin PR must land before the suite is in sync.
 
+Support sessions (MMI-Hub, Jerv-Hub, Jerv-JervCode) are not suite members and hold standing owner authorization (2026-10-25) to cut and ship releases at their discretion during suite runs without repeated per-release approval; record this standing rule in every suite session's working note and briefing while keeping all standard release preflight, gate, and verification checks.
+

package/skills/release/SKILL.md

@@ -7,7 +7,7 @@ description: Ship rc or direct-track development to main and production.
 
 # /release — ship to main + prod
 
-Bare `minor|major|patch` (default `patch`), never a flag; needs Jervaise's yes (principle 12). `minor`: `MMI_BUMP_REASON`. `major`: also `MMI_MAJOR_APPROVED=<exact version>` after the yes ([docs/versioning.md](../../docs/versioning.md)).
+Bare `minor|major|patch` (default `patch`), never a flag; needs Jervaise's yes (principle 12). Support sessions (`MMI-Hub`, `Jerv-Hub`, `Jerv-JervCode`) hold standing owner authorization (2026-10-25) to release at their discretion during active suite runs without repeated per-release approval; record this standing rule in every suite session's working note and briefing ([suite.md](suite.md)). All standard release preflight, gate, and verification checks still apply. `minor`: `MMI_BUMP_REASON`. `major`: also `MMI_MAJOR_APPROVED=<exact version>` after the yes ([docs/versioning.md](../../docs/versioning.md)).
 
 ## Lane
 

package/skills/release/suite.md

@@ -1,5 +1,7 @@
 In the suite lead (MM-Work) a plain rcand, release or hotfix refuses: run `mmi-cli devops suite rcand --owner-go` or `mmi-cli devops suite release --owner-go` instead (a lead-only cut needs `--suite-solo --owner-go`). A suite member cannot run standalone rcand, release or hotfix: cut from the suite lead; only a backward-compatible solo backend release/hotfix with explicit owner approval may pass `--suite-solo --owner-go`, and its MM-Work development pin PR must land before the suite is in sync.
 
+Support sessions (MMI-Hub, Jerv-Hub, Jerv-JervCode) are not suite members and hold standing owner authorization (2026-10-25) to cut and ship releases at their discretion during suite runs without repeated per-release approval; record this standing rule in every suite session's working note and briefing while keeping all standard release preflight, gate, and verification checks.
+
 Every new mm-work suite Release (including solo and hotfix releases) requires both `--announce-summary-file <path>` (English) and `--announce-summary-file-tr <path>` (Turkish, "sen" form) in the update-notes template. The canonical wording lives in the [MM-Work GUIDE, "Update notes"](https://github.com/mutmutco/MM-Work/blob/development/packages/mmwork-ds/GUIDE.md#update-notes); this repo links it and never copies it. Each file has the section word `Fixed` / `Düzeldi` (what works now, never the problem: "Drive: Scans of large drives now finish without timing out."; a line without now / again / no longer, or artık / yeniden / tekrar / yine, is refused) and/or `New` / `Yeni` (what you can now do) on its own line, Fixed first, each only when it has lines. Under them go 1–8 lines of `<Area>: <sentence>.`, each at most 120 characters, with no issue numbers, versions or commit prefixes. Off-template or missing files refuse before tagging. Do not write the head (app · date · time) or the thanks line: MM-Work renders both from the Release date and credits. Suite release also requires a valid `--member-summary-file <owner/repo=path>` and `--member-summary-file-tr <owner/repo=path>` for every member being released, before promoting any member. Carried, held and already-released members need none, and existing Releases can resume without new files.
 The `/user-releases` feed serves template notes as `updateNotes: {en?, tr?: {fixed[], new[]}}`. Older title-and-notes bodies keep `plainWords` and get `updateNotes: null`.
 

package/skills/stage/SKILL.md

@@ -33,7 +33,7 @@ mmi-cli stage run --apply --port 5180            # pin a port
 mmi-cli stage run --apply --timeout-ms 120000    # slow stacks
 ```
 
-All artifacts (build output, screenshots, traces, local DB files) stay under untracked `tmp/stage/`. When grinding or issue acceptance criteria exist, read [smoke.md](smoke.md) and run its post-smoke panel before teardown.
+All artifacts (build output, traces, local DB files) stay under untracked `tmp/stage/`. When grinding or issue acceptance criteria exist, read [smoke.md](smoke.md) and run its post-smoke panel before teardown.
 
 ## Step 2 — stop when done