@mutmutco/claude-plugin 4.0.16 → 4.0.17

package/.claude-plugin/plugin.json

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

package/package.json

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

package/skills/release/SKILL.md

@@ -38,6 +38,9 @@ nothing deploys before the protected `main` push accepts that checked SHA.
   branch's lineage and every tag-anchored check (coverage trailers, misalignment guard, version probes)
   re-flags or mis-reads forever after. Any merge that carries an already-tagged commit — the Step 5
   `main → development` roll-forward, any alignment PR — lands as a **true merge** (`--merge`), never squash.
+  `--wait` does not relax this: use `mmi-cli devops pr merge <n> --wait --merge` (or the policy-gated
+  `--auto --merge`). `--wait` alone still defaults the CLI merge method to squash and must not land an
+  alignment / tagged-commit-carrying PR.
 - **A refused train is a stop, never a license to finish by hand.** Every fail-closed halt below — authority
   probe, coverage guard, untolerated conflict, required checks, stray tag — ends the run. The recovery is
   always to fix the cause and re-run the train; it is never hand-resolving on `main`, bare-pushing a train
@@ -294,7 +297,8 @@ why (a hotfix freezes a snapshot that `development` can keep rewriting).
 Alignment PRs are the exception to the org's squash default: land them with a true merge —
 `mmi-cli devops pr merge <n> --auto --merge` (not squash; a squash discards the merge parentage, so the
 misalignment guard re-flags the same divergence on the next run). `--auto` clears the checks the PR
-triggers, which block an immediate merge right after a release.
+triggers, which block an immediate merge right after a release. When awaiting checks inline, keep
+`--merge`: `mmi-cli devops pr merge <n> --wait --merge` — `--wait` alone is not enough (merge floor above).
 
 **Exception — version-manifest and `.gitignore` paths.** `mmi-cli devops release --apply` tolerates
 conflicts confined to the version-fold paths (Step 1b) and `.gitignore` (#1037 — a
@@ -529,7 +533,8 @@ mmi-cli oracle org project sync-info --apply   # omit --apply for the read-only
   PR with a true merge** — `mmi-cli devops pr merge <number> --auto --merge` (never squash — a squash drops the merge
   parentage and the misalignment guard re-flags the divergence). `--auto` is what makes it land right after a
   release: the alignment PR's own `cli`/`infra`/`docs` checks are still running, so a plain immediate merge is
-  policy-blocked — `--auto` merges once they pass. Never force.
+  policy-blocked — `--auto` merges once they pass. If you await with `--wait` instead, still pass `--merge`
+  (`mmi-cli devops pr merge <number> --wait --merge`); `--wait` alone must not land the alignment PR. Never force.
 - Full-track repos: `mmi-cli devops release --apply` already aligned `rc` to the released `main` (#1036 — the
   push runs inside the authority-gated train; the result reports it as `rcAlignment`). No manual `rc`
   push — if the result reports a failed alignment, investigate and rerun via the train, never bare-push.