@mutmutco/cursor-plugin 4.3.56 → 4.3.58

package/.cursor-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "mmi",
-  "version": "4.3.56",
+  "version": "4.3.58",
   "mmiCompat": "4.x",
   "description": "MMI workflow skills and organisation gates for Cursor.",
   "author": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mutmutco/cursor-plugin",
-  "version": "4.3.56",
+  "version": "4.3.58",
   "description": "MMI workflow skills and organisation gates for Cursor.",
   "author": {
     "name": "MMI Future",

package/skills/hotfix/SKILL.md

@@ -62,6 +62,10 @@ MMI-Hub adds `--announce-summary-file "$f"` with a fresh 3–6 line neutral summ
 
 ## Verify
 
+Slack announcements use the GitHub-authenticated Hub service and its server-side MMI vault access.
+Developers need no local AWS tools, AWS identity, or shared Slack key. Preserve a failed summary
+for the supported continuation; never replay a delivery whose result is uncertain.
+
 Read the receipts, never the exit code (exit `1` = a follow-up failed after the tag; a pending follow-up exits `0`, so a clean exit alone never means every leg resolved):
 
 - `runs[]` — the release-triggered runs on the tagged SHA (workflow, conclusion, url). 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. `jerv-gateway` is the operator-host deploy leg: it has no run id to watch, so read its `deployNote` / `ledger.phases.deploy` — `pending` there means production was never deployed and blocks the next train run.

package/skills/org-guide/references/vault.md

@@ -1,5 +1,8 @@
 # Vault and keyless access
 
+GitHub repository admins are project-admins on that repository without duplicate registry
+enrollment. Registry-listed admins with repository write access remain supported.
+
 The two tiers describe authority and blast radius, not separate storage products:
 
 - **Your project:** a project-admin can manage their own product's full vault tree, including

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

@@ -1,5 +1,11 @@
 # Work and releases
 
+GitHub repository admins hold project-admin authority on their own projects without duplicate
+registry enrollment. Registry-listed admins with repository write access remain supported.
+Use `mmi-cli oracle org access role <owner/repo> --json` to verify authority for release,
+candidate, hotfix, and runtime operations. Organization membership role alone is not this check.
+The Hub distribution train remains organization-master-only.
+
 Start with `mmi-cli onboard` and the [board skill](../../board/SKILL.md).
 Reading or discussing the board is read-only until the developer authorizes work.
 Claim approved work with `mmi-cli oracle board claim <issue>`, then prepare an isolated task
@@ -85,6 +91,12 @@ by hand. The Hub always needs a curated `--announce-summary-file`, and so does a
 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.
 
+Announcement delivery uses the developer's GitHub-authenticated Hub session. The Hub checks project
+authority, resolves the registered channel, and reads the MMI Future Slack key inside its vault boundary.
+Developers need no AWS CLI, AWS identity, or copy of the shared bot key. Keep a failed announcement's
+summary for the supported resume path. A delivery-unknown response requires checking the existing
+message; never resend blindly. Confirmed delivery is recorded per repository and release tag.
+
 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

@@ -64,6 +64,11 @@ Use the actual current stage, never a guessed sequence. Explain a pending result
 
 ## Verify
 
+Slack announcements use the GitHub-authenticated Hub service and its server-side MMI vault access.
+Never install AWS, ask for AWS credentials, or copy the shared Slack key to unblock a developer.
+The Hub chooses the registered channel and checks project authority. A failed announcement keeps
+its summary file; an uncertain delivery is never automatically replayed.
+
 Read the saved result, never the exit code (exit `1` = a follow-up failed after promotion; a pending follow-up exits `0`, so a clean exit alone never means every leg resolved):
 
 - `releaseVerdict.releaseStatus` + `followUpStatus` — `succeeded` + `pending` is shipped with the follow-up unresolved: neither failed nor done. A `--resume` receipt carries the same `releaseVerdict` (`command: release-resume`), plus its own `mode` and `state`.

package/skills/secrets/SKILL.md

@@ -150,7 +150,7 @@ Prefer this over manual copy piping — audit-logged, blocklist enforced.
 
 - **Never echo a value** — not in chat, a commit, a log, or an issue. No command emits a value to stdout;
   consume one keyless with `secrets use <KEY> -- <cmd>` (#2844). Treat every secret as write-once.
-- Authority is **GitHub**: project-admin = repo `write` plus the registry `projectAdmins` entry, master =
+- Authority is **GitHub**: project-admin = repo `admin`, or repo `write`/`maintain` plus the registry `projectAdmins` entry; master =
   org owner. The backend checks both with the org App token, so the decision is server-side (your token
   scope can't widen it).
 - Runtime consumes declared keys through its scoped broker token (and central deploy injects the declared

package/skills/stage/SKILL.md

@@ -48,8 +48,9 @@ compose logs`/`down` fails the same `required variable … is missing a value`.
 `NODE_AUTH_TOKEN=@github-packages-token` for `@mutmutco/fofu-ds` on GitHub Packages), `/stage` injects those
 BuildKit ids into the **`docker compose build`** process env only — not into the running container. Central
 deploy mints the packages sentinel from Actions `GITHUB_TOKEN`; a laptop cannot. Resolution order: existing
-process env → stageless project vault secret under the BuildKit id (a `read:packages` PAT at
-`NODE_AUTH_TOKEN`). If both are missing, `/stage` fails with a teaching error before npm's opaque 401.
+process env → stageless project vault secret under the BuildKit id → existing GitHub sign-in
+(`GH_TOKEN`, `GITHUB_TOKEN`, or `gh auth token`). Package read access is still required and is enforced
+by GitHub Packages during the build. If every source is missing, `/stage` fails before the build.
 Setup: [`docs/Guides/tenant-runtime.md`](../../docs/Guides/tenant-runtime.md) § Local `/stage`. Never commit
 or print the PAT.