@mutmutco/codex-plugin 4.3.43 → 4.3.44

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "mmi",
-  "version": "4.3.43",
+  "version": "4.3.44",
   "mmiCompat": "4.x",
   "description": "MMI workflow skills and org gates delivery.",
   "author": {

package/package.json

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

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

@@ -34,8 +34,10 @@ Read the selected release skill before operating the train. Let it choose versio
 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.
 A release announces itself in Slack: the Hub to the org alerts channel, a product to its own
-project channel when the project vault declares `SLACK_RELEASE_CHANNEL`; never post release notes
-by hand.
+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
+META sets `releaseChannel` — 3–6 plain lines in the project's `releaseLanguage` (default `en`),
+written for that project's audience, never the raw PR titles.
 
 For local or private live testing, read [stage](../../stage/SKILL.md).
 For a new product repository, use [bootstrap](../../bootstrap/SKILL.md).

package/skills/release/SKILL.md

@@ -33,7 +33,7 @@ Read `ready`, then `findings[]`: each carries `code`, `severity` (`blocker` · `
 
 Run from the primary checkout on the lane's start branch (`rc`; `development` for direct-track and `--dev`). Export the bump intent once from the bare argument — `MMI_BUMP_INTENT=minor|major|patch`, unset → `patch`; `MMI_RELEASE_VERSION=X.Y.Z` only for an exact target the tag math cannot derive.
 
-MMI-Hub only: write a fresh 3–6 line neutral summary to `f=$(mktemp tmp/release-summary.XXXXXX)` — sourced from Hub PR titles only (`origin/main..origin/development`), rewritten in Hub-subsystem terms, never a product or brand name. Hub scope is only `mutmutco/MMI-Hub`: never a product's board, `ds-propagate.yml`, or a product's deploy state. A product repo may pass `--announce-summary-file` too (optional): its notes post to the project's own release channel from the declared `SLACK_RELEASE_CHANNEL` vault key, in that product's own names — with no key declared the announcement is `skipped` and nothing else changes.
+Two cases need a summary file. (1) **MMI-Hub** — always: write a fresh 3–6 line neutral summary to `f=$(mktemp tmp/release-summary.XXXXXX)` — sourced from Hub PR titles only (`origin/main..origin/development`), rewritten in Hub-subsystem terms, never a product or brand name. Hub scope is only `mutmutco/MMI-Hub`: never a product's board, `ds-propagate.yml`, or a product's deploy state. (2) **Any product repo whose META carries `releaseChannel`** (`mmi-cli oracle org project get {owner}/{repo} --json`) — required too: read `releaseLanguage` (default `en`) and write 3–6 lines IN THAT LANGUAGE, in plain words for the project's audience: what changed and why it matters to a user; no commit prefixes, no issue or PR numbers, no file names, no product-internal jargon. The train refuses `--apply` without the file, and raw release notes are never posted to a project channel. A repo with no `releaseChannel` announces nothing and needs no file.
 
 ```bash
 r=$(mktemp tmp/release-receipt.XXXXXX)