@mutmutco/cursor-plugin 4.3.48 → 4.3.49

package/.cursor-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "mmi",
-  "version": "4.3.48",
+  "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.48",
+  "version": "4.3.49",
   "description": "MMI workflow skills and organisation gates for Cursor.",
   "author": {
     "name": "MMI Future",

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/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`.