@mutmutco/codex-plugin 4.3.1 → 4.3.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "mmi",
3
- "version": "4.3.1",
3
+ "version": "4.3.2",
4
4
  "mmiCompat": "4.x",
5
5
  "description": "MMI workflow skills and org gates delivery.",
6
6
  "author": {
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@mutmutco/codex-plugin",
3
- "version": "4.3.1",
3
+ "version": "4.3.2",
4
4
  "description": "MMI workflow skills and org gates delivery.",
5
5
  "author": {
6
6
  "name": "MMI Future",
@@ -449,8 +449,8 @@ background-task harness surfacing exit codes misreads it as "release failed" whe
449
449
  shipped. Classify from the verdict fields, never the exit code alone: `succeeded` + `pending` means
450
450
  shipped with the follow-up unresolved — watch the enumerated `workflowRuns` to conclusion; only a
451
451
  resolved failure there is a failed follow-up. Read the live release verdict and verify these four
452
- facts instead: the `main..development` count, the tag on `origin`, `gh release view`, and the runs on
453
- the release SHA.
452
+ facts instead: the `main..development` count, the tag on `origin`, the bounded Latest Release read in
453
+ Step 6, and the runs on the release SHA.
454
454
 
455
455
  Required status checks are **per-repo branch protection, not a fixed list** — MMI-Hub's `main` requires
456
456
  `cli` · `infra` · `docs`, but a product repo may require different contexts or none at all (#1045). The
@@ -614,12 +614,13 @@ Before running `--apply` for MMI-Hub, resolve the real tag first:
614
614
  - **Benefits, active voice, addressed to the reader** — no hype, no internal identifiers.
615
615
 
616
616
  Write the curated summary to a fresh temp file (`f=$(mktemp tmp/release-summary.XXXXXX)`, so a stale prior
617
- summary is never reused). Source from **Hub PR titles only** (`origin/main..origin/development` on
617
+ summary is never reused) and point `--out` at an equally fresh result receipt
618
+ (`r=$(mktemp tmp/release-receipt.XXXXXX)`, #5983). Source from **Hub PR titles only** (`origin/main..origin/development` on
618
619
  `mutmutco/MMI-Hub`), but **rewrite** each line in neutral Hub-subsystem terms (CLI, skills, plugin,
619
620
  workflows, registry, deploy hub) and to the release-type depth the guide demands — **never** a
620
621
  product or brand name (FoFu, Katip, etc.) anywhere in the summary file, Slack post, chat, or release
621
622
  report. Product names are allowed only when releasing **that product's repo**. Then pass the file through:
622
- `mmi-cli devops release --apply --announce-summary-file "$f"`. After the GitHub Release publishes, the CLI posts
623
+ `mmi-cli devops release --apply --announce-summary-file "$f" --json --out "$r"`. After the GitHub Release publishes, the CLI posts
623
624
  the summary to the org alerts channel as the MMI-Future Slack app (token + channel from SSM at run time).
624
625
  For a new MMI-Hub `--apply`, the CLI refuses before promotion when the file is missing, unreadable, or does
625
626
  not contain 3–6 non-empty lines; generated-note fallback is not an agent release path. `--resume` never
@@ -627,6 +628,13 @@ requires or republishes a summary, and non-Hub repos skip the announcement autom
627
628
  summary is accepted, Slack delivery remains best-effort: a transport failure is reported in the result and
628
629
  never rolls back an otherwise completed release.
629
630
 
631
+ **Write the result receipt before bounded monitoring (#5983).** A background-task harness that bounds its
632
+ output retains only the tail of the apply run — exactly where the accepted announcement outcome
633
+ (`announceNote`) can be dropped. With `--out <path>`, the CLI itself writes the full apply result to the
634
+ file as BOM-free UTF-8 (never a shell `>` redirect — see #5802), so the receipt survives any monitor
635
+ bound. `--resume` proves the Release and deploy but does not and should not re-announce, so this receipt
636
+ is the only durable record of the accepted Slack delivery — verify it in Step 6.
637
+
630
638
  **Don't block on the deploy.** Start the watch as a background task and proceed to Steps 4b–5 (docs, project
631
639
  info, branch alignment) while prod deploys. The verdict is collected in Step 6 — verification is not
632
640
  skipped, only un-blocked. Deploy failure → report plainly, then **retry the existing promoted ref by deploy
@@ -702,13 +710,26 @@ mmi-cli oracle org project sync-info --apply # omit --apply for the read-only
702
710
 
703
711
  ## Step 6 — collect deploy verdict + report
704
712
 
713
+ Verify the Slack announcement from the receipt, not from memory (#5983). The `--out` receipt written at
714
+ Step 4 is the durable record of the initial apply result; read its `announceNote` field before the final
715
+ report and state the delivery verdict (`announced`, `skipped`, or the failure note). A monitor that kept
716
+ only the apply output's tail may have dropped that line — the receipt is what keeps that from losing the
717
+ outcome.
718
+
705
719
  The `release --apply` exit code is **not** the release verdict. A nonzero exit with
706
720
  `releaseStatus=succeeded` and `followUpStatus=pending` is the unresolved-follow-up case from Step 3 —
707
721
  the release shipped; the runs enumerated in `workflowRuns` are the outstanding verdict, so watch them
708
722
  to conclusion here rather than re-running or alarming. Report the live release verdict from
709
- the four checks that matter: the `main..development` count, the tag on `origin`, `gh release view`,
710
- and the runs on the release SHA; an alignment PR is normal follow-up work when those checks confirm
711
- the release shipped.
723
+ the four checks that matter: the `main..development` count, the tag on `origin`, the bounded Latest
724
+ Release read, and the runs on the release SHA; an alignment PR is normal follow-up work when those
725
+ checks confirm the release shipped.
726
+
727
+ Use only this bounded Latest Release read:
728
+ ```bash
729
+ gh api repos/{owner}/{repo}/releases/latest --jq '{tagName:.tag_name,targetCommitish:.target_commitish,publishedAt:.published_at,url:.html_url}'
730
+ ```
731
+ Require its `tagName` to equal the expected `$TAG`; a mismatch means Latest does not identify this
732
+ release and is unverified.
712
733
 
713
734
  Collect the backgrounded prod-deploy watch from Step 4 (it has typically finished by now). Confirm prod is
714
735
  healthy (the central deploy workflow smoke step / a health check); **red** → report the failure prominently and flag