@mutmutco/pi-plugin 4.5.170 → 4.5.171

package/package.json

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

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

@@ -118,6 +118,10 @@ Production changes require explicit authorization from the authorized human.
 Read the selected release skill before operating the train. Let it choose versions, run gates,
 publish, deploy, and verify the resulting release. A refusal requires fixing its cause; do not
 finish by hand, bypass checks, or start a duplicate release.
+Versions: patch is the default for fixes and small compatible additions. Minor is a deliberate call
+for a real feature, with a one-line reason. Major is a new start or direction and needs the owner's
+fresh approval before tagging. A breaking change refuses until it is shimmed or made an approved
+major. The [release](../../release/SKILL.md) skill names the exact switches.
 A release announces itself in Slack once its deploy and publish are green: the Hub to the org alerts channel, a product to its own
 project channel when the project's registry META sets `releaseChannel`; never post release notes
 by hand. The Hub always needs a curated `--announce-summary-file`, and so does any product whose

package/skills/release/SKILL.md

@@ -7,6 +7,8 @@ description: Ship rc or direct-track development to main and production.
 
 **Argument:** `/release minor`, `/release major`, or `/release patch` — a bare bump word, never a `--flag` or env var. No argument → `patch`; a `/release patch` from development is a legitimate ordinary release, `/hotfix` stays the cherry-pick promotion lane.
 
+**Bump rules** ([docs/versioning.md](../../docs/versioning.md)): patch is the default and needs nothing. `minor` only for a real feature or significant change, with a one-line reason exported as `MMI_BUMP_REASON`. `major` only with Jervaise's fresh approval in this turn: export `MMI_BUMP_REASON` and `MMI_MAJOR_APPROVED=<exact target version>` (e.g. `5.0.0`) only after that approval, never earlier or from a prior turn. A breaking signal in the range (`feat!:`, `BREAKING CHANGE:`) makes the train refuse until it is shimmed (patch) or declared an owner-gated major.
+
 # /release — ship to main + prod
 
 Full-track repos ship exactly what is on `rc` (never `development`): merge `rc → main`, tag `vX.Y.0`, publish the GitHub Release, deploy prod, roll `development` forward. Direct-track repos ship `development → main`, and the release event fires the repo's own deploy/publish workflow (MMI-Hub: `deploy.yml` + `publish.yml`). `rc` is ephemeral: `/rcand` creates its runtime, `/release` retires it after a confirmed prod deploy (`rcRetirement`). A prod release needs the authorized human's explicit go in the current turn — an agent never self-initiates it. The board needs no touch: items reached `Done` when their PRs merged to `development`.