@mutmutco/codex-plugin 4.3.42 → 4.3.43

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "mmi",
-  "version": "4.3.42",
+  "version": "4.3.43",
   "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.42",
+  "version": "4.3.43",
   "description": "MMI workflow skills and org gates delivery.",
   "author": {
     "name": "MMI Future",

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

@@ -33,6 +33,9 @@ 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.
+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.
 
 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.
+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.
 
 ```bash
 r=$(mktemp tmp/release-receipt.XXXXXX)
@@ -41,7 +41,7 @@ mmi-cli devops release --apply --json --out "$r"
 mmi-cli devops release --apply --announce-summary-file "$f" --json --out "$r"     # MMI-Hub
 ```
 
-Add `--dev` for a full-track dev → main release and `--watch` to block on the deploy/publish runs. `mmi-cli devops release --apply --ack <sha>[,<sha>…]` only when the authorized human has verified that a main-only commit the hotfix-coverage guard refused is already in the candidate — never ack to save time. The one command merges, runs the version fold (automatic, inside `mmi-cli devops release --apply`) that bumps the manifests unconditionally before the tag, pushes the tag first (`gate.yml` runs on `v*` tags, so the fold commit earns its required checks), waits for the required contexts, pushes `main`, publishes the Release, dispatches or correlates the deploy (`tenant-deploy.yml` only for tenant-container), announces (Hub), re-syncs project info, and rolls `development` and `rc` forward. Nothing here is done by hand.
+Add `--dev` for a full-track dev → main release and `--watch` to block on the deploy/publish runs. `mmi-cli devops release --apply --ack <sha>[,<sha>…]` only when the authorized human has verified that a main-only commit the hotfix-coverage guard refused is already in the candidate — never ack to save time. The one command merges, runs the version fold (automatic, inside `mmi-cli devops release --apply`) that bumps the manifests unconditionally before the tag, pushes the tag first (`gate.yml` runs on `v*` tags, so the fold commit earns its required checks), waits for the required contexts, pushes `main`, publishes the Release, dispatches or correlates the deploy (`tenant-deploy.yml` only for tenant-container), announces (the org alerts channel for the Hub; the project's own release channel for a product repo), re-syncs project info, and rolls `development` and `rc` forward. Nothing here is done by hand.
 
 ## Verify
 
@@ -51,7 +51,7 @@ Read the receipt at `$r`, never the exit code (exit `2` = shipped with a follow-
 - `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`.
-- `announceNote` (Hub) — `announced`, `skipped`, or the failure note.
+- `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`.
 - A `private` npm surface (`surfaces.json`): the doctor's `npm-token-rejected` finding comes first. A 401 from `npm whoami` through the `_org` `npm/NPM_TOKEN` vault hop means the token is rejected, and every authenticated `npm view` then 404s exactly like an absent package — rotate the token; only after a login is a restricted 404 "unverifiable from here", never "not published" (`publish-private-package`). On a repo whose workflows publish through Trusted Publishing and name no registry token, that row is `info`, not a warning: no lane consumes the org token, so it constrains your manual read only.