@mutmutco/cursor-plugin 4.3.47 → 4.3.49

package/.cursor-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "mmi",
-  "version": "4.3.47",
+  "version": "4.3.49",
   "mmiCompat": "4.x",
   "description": "MMI workflow skills and organisation gates for Cursor.",
   "author": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mutmutco/cursor-plugin",
-  "version": "4.3.47",
+  "version": "4.3.49",
   "description": "MMI workflow skills and organisation gates for Cursor.",
   "author": {
     "name": "MMI Future",

package/skills/org-guide/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: org-guide
-description: Read MMI org rules before project work; load only the topic needed.
+description: Read org rules for project work and reporting MMI CLI, plugin, or workflow bugs.
 ---
 
 # MMI organization guide
@@ -19,6 +19,9 @@ the [MMI help skill](../mmi-help/SKILL.md).
   Do not commit AGENTS.md, CLAUDE.md, or copied plugin instructions.
 - Claim approved work through the board, use the repository's checks, and land through MMI.
   A request for help or a plan does not authorize a change or a production release.
+- When an MMI tooling bug affects a developer other than `jervaise`, ask before filing a Hub report.
+  Respect a decline. Follow [Work and releases](references/work-and-releases.md#report-mmi-tooling-bugs)
+  for consent, duplicate handling, and optional released-fix Slack notifications.
 - Read the registry for release tracks, domains, and OAuth configuration. Use MMI provisioning
   and release workflows rather than inventing parallel deployment or credential paths.
 
@@ -27,6 +30,7 @@ the [MMI help skill](../mmi-help/SKILL.md).
 | Task | Local reference |
 | --- | --- |
 | Install, update, reload, or diagnose tooling | [Getting started](references/getting-started.md) |
+| Report an MMI 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) |
 | Consume, declare, rotate, or request a secret | [Vault and keyless access](references/vault.md) |
 | Register domains or configure Google OAuth | [Domains and OAuth](references/domains-and-oauth.md) |

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

@@ -10,6 +10,12 @@ The organization ruleset restricts AGENTS.md, CLAUDE.md, GEMINI.md, the .claude,
 directories, and .cursor/rules at any depth in covered repositories. Designated distribution-source
 repositories have centrally managed exceptions; a product developer must not invent a bypass.
 Do not force-add ignored files or commit plugin caches to work around delivery problems.
+Never disable an org ruleset (`mmi-branch-protection`, `mmi-train-floor`, `mmi-no-agent-files-org`)
+by hand to push past it. When the owner has approved a bounded relaxation window, the restore is
+unconditional, not a later step in the same chain: a failed push after the disable must still
+re-enable the ruleset (shell `trap`/`finally`), and the run ends by reading the ruleset back as
+`enforcement: active`. A one-liner of `disable && push` leaves protection off the moment the push
+is rejected.
 
 Do not create repository environment files to hold runtime configuration or secrets.
 Use the declared vault and supported [keyless workflows](vault.md), including for local stages.

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

@@ -18,6 +18,47 @@ 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.
 
+## Report MMI tooling bugs
+
+This workflow covers bugs in MMI tooling, including its CLI, plugin, and shared workflows.
+Product bugs stay with their product; do not automatically file them on the Hub board.
+For every developer other than authenticated GitHub login `jervaise`, ask for consent before
+filing a tooling bug through `mmi-cli learning report`. Do not infer identity from a display name
+or Slack email. The owner exemption skips this consent workflow and its released-fix DMs.
+
+Show a safe summary, affected MMI version, and minimal reproduction. Explain that approval files
+or attaches the report to an existing Hub issue and notifies Jervaise through the MMI-Future Slack app.
+Wait for explicit approval; a decline means no
+report, no alternate filing command, and no repeated consent prompt for the same incident.
+Remove secrets and private data from the title, reproduction, and logs before sending anything.
+Write the approved report body to a UTF-8 file; never put it in command arguments.
+
+Use `mmi-cli learning report --type bug --title "<safe summary>" --body-file <path>`.
+Let the existing report command handle duplicates; reuse its returned issue and never add
+`--force` to bypass matching or file another issue for the same incident. Do not claim or poll
+the issue; the Hub team owns the fix.
+
+On the first approved report without a saved Slack destination, ask once whether the developer
+wants a DM when the fix is released. If they agree, ask them to confirm their Slack workspace
+email and append `--slack-email <confirmed-email>`. This email is a notification destination,
+not verified identity or authorization. Never guess it from GitHub profile data, use another
+person's address, or include it in the public issue body. The Hub stores the confirmed email privately
+until scheduled Slack lookup succeeds, then replaces it with the Slack user ID for later reports.
+Declining notifications does not prevent filing the approved bug report.
+
+Read the returned `notification.status`: `tracked` means the released-fix notification is
+registered for scheduled processing, not delivered, `needs-slack-email` means no saved destination
+was found, `unavailable` means the
+issue was filed but notification registration failed, and `owner-excluded` means no owner DM.
+If `needs-slack-email` follows a report where the notification question was not yet asked, ask
+once; use the same report with the confirmed email so dedup retains its issue. Never retry an
+ambiguous report submission. Do not claim a DM is registered when the status is unavailable,
+and do not replay a valid report merely to repair notification failure. Unresolved Slack
+lookup remains pending in the notification record; it must not use an old destination.
+The MMI-Future app sends a fix DM only after the issue's closing merge is included in a stable
+Hub release whose publication and deployment both succeeded. Closing an issue alone is not enough.
+An uncertain Slack send is recorded for operator review and never replayed automatically.
+
 ## Choose the declared train
 
 Read `mmi-cli oracle org project get <owner/repo> --json` and `mmi-cli status` for the resolved track.

package/skills/release/SKILL.md

@@ -50,7 +50,7 @@ Read the receipt at `$r`, never the exit code (exit `2` = shipped with a follow-
 - `releaseVerdict.releaseStatus` + `followUpStatus` — `succeeded` + `pending` is shipped with the follow-up unresolved: neither failed nor done.
 - `deployStatus` — `pending` is never terminal; `promoted: true` holds even when a deploy failed.
 - `workflowRuns` — every run on the release SHA (deploy-model runs, any `push: main` deploy, the repo's own `gate`). Watch each non-success entry to conclusion: `gh run watch <run-id> --repo {owner}/{repo} --exit-status`. Name which run is red: `deploy.yml` / `publish.yml` / `tenant-deploy.yml` / `jerv-gateway` is a deploy or publish verdict; a `gate` push run is ordinary CI sharing the SHA.
-- With `--watch` the train waits for its own alignment PR to land (true merge) and folds the ledger in the same run, so the receipt ends `succeeded` / `complete`. An external `gh run watch` never folds anything: if the receipt still shows a `pending` leg (no `--watch`, or the alignment PR outlived the bounded wait), fold it live before declaring the cut done or starting any new train: `mmi-cli devops release --resume --watch --json --out <fresh-receipt>`; the NEXT train's doctor otherwise refuses with `ledger-pending`.
+- With `--watch` the train waits for its own alignment PR to land (true merge) and folds the ledger in the same run, so the receipt ends `succeeded` / `complete`. An external `gh run watch` never folds anything: if the receipt still shows a `pending` leg (no `--watch`, the alignment PR outlived the bounded wait, or a release-event `publish.yml` run on a registry-publish repo had not been correlated by the time the receipt was written — `--watch` waits for the alignment PR, not for that run, so a `publish` leg `pending` with no run URL after `--watch` is the expected direct-track shape, not a failure), fold it live before declaring the cut done or starting any new train: `mmi-cli devops release --resume --watch --json --out <fresh-receipt>`; the NEXT train's doctor otherwise refuses with `ledger-pending`.
 - `announceNote` — `announced` (to the alerts channel for the Hub, to the project release channel for a product repo), `skipped`, or the failure note. The channel id itself is never printed.
 - `devRollForward` / `rcAlignment` — `pushed`, or `pr-pending` with the alignment PR to land by true merge (Merge floor). An enqueued auto-merge is not evidence of the method; before reporting, read the enqueued method back — `gh pr view <n> --json autoMergeRequest --jq .autoMergeRequest.mergeMethod` — and prove it is `MERGE`. An enqueued `SQUASH` is a stop under the Merge floor, not something to wait out.
 - `versionFold`, `rcRetirement`, `checkout` — `returned`, or the named reason you are still on `main`.