@mutmutco/codex-plugin 4.3.1 → 4.3.3

package/.codex-plugin/plugin.json

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

package/skills/release/SKILL.md

@@ -449,8 +449,8 @@ background-task harness surfacing exit codes misreads it as "release failed" whe
 shipped. Classify from the verdict fields, never the exit code alone: `succeeded` + `pending` means
 shipped with the follow-up unresolved — watch the enumerated `workflowRuns` to conclusion; only a
 resolved failure there is a failed follow-up. Read the live release verdict and verify these four
-facts instead: the `main..development` count, the tag on `origin`, `gh release view`, and the runs on
-the release SHA.
+facts instead: the `main..development` count, the tag on `origin`, the bounded Latest Release read in
+Step 6, and the runs on the release SHA.
 
 Required status checks are **per-repo branch protection, not a fixed list** — MMI-Hub's `main` requires
 `cli` · `infra` · `docs`, but a product repo may require different contexts or none at all (#1045). The
@@ -525,8 +525,29 @@ For `tenant-container` repos, publish the GitHub Release and dispatch the centra
 gh release create "vX.Y.0" --target main --generate-notes --latest
 gh workflow run tenant-deploy.yml --repo mutmutco/MMI-Hub \
   -f slug={slug} -f repo={owner}/{repo} -f ref=main -f stage=main
-gh run watch "$(gh run list --workflow tenant-deploy.yml --limit 1 --json databaseId -q '.[0].databaseId')" \
-  --exit-status   # the central prod-deploy run — run this in the BACKGROUND (Bash run_in_background)
+```
+
+On PowerShell, read the run as a structured receipt and filter it natively; do not nest a
+`gh run list` query inside `gh run watch`:
+```powershell
+$runs = gh run list --workflow tenant-deploy.yml --limit 10 --json databaseId,createdAt,url,status,conclusion | ConvertFrom-Json
+$run = $runs |
+  Where-Object { $_.databaseId -and $_.createdAt } |
+  Sort-Object { [DateTimeOffset]$_.createdAt } -Descending |
+  Select-Object -First 1
+if (-not $run) { throw 'tenant-deploy workflow run was not found' }
+$run | Select-Object databaseId,createdAt,url,status,conclusion | ConvertTo-Json -Compress
+# Run this in the BACKGROUND (PowerShell Start-Job / task runner).
+gh run watch $run.databaseId --exit-status
+```
+
+When several run receipts need collecting, assign the loop output before serializing it; a top-level
+`foreach (...) { ... } | ConvertTo-Json` is a PowerShell parser trap:
+```powershell
+$out = foreach ($run in $runs) {
+  gh run view $run.databaseId --json databaseId,url,status,conclusion,createdAt | ConvertFrom-Json
+}
+$out | ConvertTo-Json -Compress
 ```
 
 For `hub-serverless` (MMI-Hub), publish the GitHub Release but do **not** dispatch `tenant-deploy.yml`:
@@ -614,12 +635,13 @@ Before running `--apply` for MMI-Hub, resolve the real tag first:
 - **Benefits, active voice, addressed to the reader** — no hype, no internal identifiers.
 
 Write the curated summary to a fresh temp file (`f=$(mktemp tmp/release-summary.XXXXXX)`, so a stale prior
-summary is never reused). Source from **Hub PR titles only** (`origin/main..origin/development` on
+summary is never reused) and point `--out` at an equally fresh result receipt
+(`r=$(mktemp tmp/release-receipt.XXXXXX)`, #5983). Source from **Hub PR titles only** (`origin/main..origin/development` on
 `mutmutco/MMI-Hub`), but **rewrite** each line in neutral Hub-subsystem terms (CLI, skills, plugin,
 workflows, registry, deploy hub) and to the release-type depth the guide demands — **never** a
 product or brand name (FoFu, Katip, etc.) anywhere in the summary file, Slack post, chat, or release
 report. Product names are allowed only when releasing **that product's repo**. Then pass the file through:
-`mmi-cli devops release --apply --announce-summary-file "$f"`. After the GitHub Release publishes, the CLI posts
+`mmi-cli devops release --apply --announce-summary-file "$f" --json --out "$r"`. After the GitHub Release publishes, the CLI posts
 the summary to the org alerts channel as the MMI-Future Slack app (token + channel from SSM at run time).
 For a new MMI-Hub `--apply`, the CLI refuses before promotion when the file is missing, unreadable, or does
 not contain 3–6 non-empty lines; generated-note fallback is not an agent release path. `--resume` never
@@ -627,6 +649,13 @@ requires or republishes a summary, and non-Hub repos skip the announcement autom
 summary is accepted, Slack delivery remains best-effort: a transport failure is reported in the result and
 never rolls back an otherwise completed release.
 
+**Write the result receipt before bounded monitoring (#5983).** A background-task harness that bounds its
+output retains only the tail of the apply run — exactly where the accepted announcement outcome
+(`announceNote`) can be dropped. With `--out <path>`, the CLI itself writes the full apply result to the
+file as BOM-free UTF-8 (never a shell `>` redirect — see #5802), so the receipt survives any monitor
+bound. `--resume` proves the Release and deploy but does not and should not re-announce, so this receipt
+is the only durable record of the accepted Slack delivery — verify it in Step 6.
+
 **Don't block on the deploy.** Start the watch as a background task and proceed to Steps 4b–5 (docs, project
 info, branch alignment) while prod deploys. The verdict is collected in Step 6 — verification is not
 skipped, only un-blocked. Deploy failure → report plainly, then **retry the existing promoted ref by deploy
@@ -702,13 +731,32 @@ mmi-cli oracle org project sync-info --apply   # omit --apply for the read-only
 
 ## Step 6 — collect deploy verdict + report
 
+Verify the Slack announcement from the receipt, not from memory (#5983). The `--out` receipt written at
+Step 4 is the durable record of the initial apply result; read its `announceNote` field before the final
+report and state the delivery verdict (`announced`, `skipped`, or the failure note). A monitor that kept
+only the apply output's tail may have dropped that line — the receipt is what keeps that from losing the
+outcome.
+
 The `release --apply` exit code is **not** the release verdict. A nonzero exit with
 `releaseStatus=succeeded` and `followUpStatus=pending` is the unresolved-follow-up case from Step 3 —
 the release shipped; the runs enumerated in `workflowRuns` are the outstanding verdict, so watch them
 to conclusion here rather than re-running or alarming. Report the live release verdict from
-the four checks that matter: the `main..development` count, the tag on `origin`, `gh release view`,
-and the runs on the release SHA; an alignment PR is normal follow-up work when those checks confirm
-the release shipped.
+the four checks that matter: the `main..development` count, the tag on `origin`, the bounded Latest
+Release read, and the runs on the release SHA; an alignment PR is normal follow-up work when those
+checks confirm the release shipped.
+
+Use only this bounded Latest Release read:
+```bash
+gh api repos/{owner}/{repo}/releases/latest --jq '{tagName:.tag_name,targetCommitish:.target_commitish,publishedAt:.published_at,url:.html_url}'
+```
+Require its `tagName` to equal the expected `$TAG`; a mismatch means Latest does not identify this
+release and is unverified.
+
+**`gh release view` has no `isLatest` field (#6019).** Never request Latest status through
+`gh release view`: the field is not in its JSON schema, so gh rejects the whole read and lists its
+supported fields — the check errors instead of answering, and Latest stays unverified. This bounded
+read is the supported Latest probe; `gh release list --json <fields>,isLatest` is the supported form
+only when a list receipt is genuinely the right shape.
 
 Collect the backgrounded prod-deploy watch from Step 4 (it has typically finished by now). Confirm prod is
 healthy (the central deploy workflow smoke step / a health check); **red** → report the failure prominently and flag
@@ -729,9 +777,17 @@ verify`: use their own release-workflow evidence and the publish-visibility cont
 Hub releases always carry a distribution bump (the Step 1b fold), so the **publish workflow**
 (`publish.yml`) ships every registry-declared public npm artifact on the GitHub Release from Step 4 —
 don't publish by hand.
-Watch it, then confirm npm caught up:
-```bash
-gh run watch "$(gh run list --workflow publish.yml --event release --limit 1 --json databaseId -q '.[0].databaseId')" --exit-status
+Watch the release-triggered `publish.yml` receipt with the same structured PowerShell probe above
+(`--workflow publish.yml --event release`), then confirm npm caught up:
+```powershell
+$runs = gh run list --workflow publish.yml --event release --limit 10 --json databaseId,createdAt,url,status,conclusion | ConvertFrom-Json
+$run = $runs |
+  Where-Object { $_.databaseId -and $_.createdAt } |
+  Sort-Object { [DateTimeOffset]$_.createdAt } -Descending |
+  Select-Object -First 1
+if (-not $run) { throw 'release-triggered publish workflow run was not found' }
+$run | Select-Object databaseId,createdAt,url,status,conclusion | ConvertTo-Json -Compress
+gh run watch $run.databaseId --exit-status
 node scripts/release-distribution.mjs verify "X.Y.0"   # bare semver — asserts registry versions, BOM identities, and published npm artifacts
 ```
 **verify takes bare semver (#5379).** Pass `X.Y.Z`, not the git-tag form `vX.Y.Z`. Checkout still