@mutmutco/pi-plugin 4.3.55 → 4.3.57

package/package.json

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

package/skills/hotfix/SKILL.md

@@ -58,7 +58,7 @@ mmi-cli devops hotfix status --json
 mmi-cli devops hotfix release vX.Y.Z --carries <pr|sha>[,<pr|sha>…] --json --out "$r2"
 ```
 
-MMI-Hub adds `--announce-summary-file "$f"` with a fresh 3–6 line neutral summary — never a product or brand name; Hub scope is only `mutmutco/MMI-Hub`, never a product's board or `ds-propagate.yml`. `hotfix release` tags, publishes the Release, watches the release-triggered runs, verifies distribution, announces (Hub), and opens the `hotfix-fold/<tag>` development fold PR. Do not hand-dispatch a second publish or deploy path: duplicate release events race or double-publish.
+MMI-Hub adds `--announce-summary-file "$f"` with a fresh 3–6 line neutral summary — never a product or brand name; Hub scope is only `mutmutco/MMI-Hub`, never a product's board or `ds-propagate.yml`. `hotfix release` tags, publishes the Release, watches the release-triggered runs, announces once they are green (Hub), verifies distribution, and opens the `hotfix-fold/<tag>` development fold PR. Do not hand-dispatch a second publish or deploy path: duplicate release events race or double-publish.
 
 ## Verify
 

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
@@ -79,7 +85,7 @@ 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
+A release announces itself in Slack once its deploy and publish are green: the Hub to the org alerts channel, a product to its own
 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`),

package/skills/release/SKILL.md

@@ -54,7 +54,7 @@ For MMI-Hub or a product with a release channel, also substitute the saved summa
 mmi-cli devops release --apply --watch --announce-summary-file "<summary-path>" --json --out "<result-path>"
 ```
 
-Add `--dev` for a full-track dev → main release. Keep `--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.
+Add `--dev` for a full-track dev → main release. Keep `--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 only after the deploy and publish runs are green (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.
 
 **Progress narration.**
 
@@ -70,7 +70,7 @@ Read the saved result, never the exit code (exit `1` = a follow-up failed after
 - `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`, the alignment PR outlived the bounded wait, or a release-event `publish.yml` run on a registry-publish repo had not been correlated by the time the receipt was written — `--watch` waits for the alignment PR, not for that run, so a `publish` leg `pending` with no run URL after `--watch` is the expected direct-track shape, not a failure), 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` — `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.
+- `announceNote` — `announced` (to the alerts channel for the Hub, to the project release channel for a product repo), `skipped`, `not announced` (deploy or publish not green; the note says whether a `--resume` carrying the same `--announce-summary-file` will post it), 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.
@@ -85,7 +85,7 @@ Four facts close the verdict: the `origin/main..origin/development` count, the t
 
 ## Recovery
 
-Every refusal and every doctor blocker names its `code` and `anchor`: open `docs/Guides/train-troubleshooting.md#<code>` and follow that entry, nothing else. That guide is test-parsed, never free text — the infra drift and plugin-set suites validate every anchor cited here and assert policy from its wording — so an edit to it re-runs the infra suite (`npm --prefix infra test`) in the same PR: a heading or slug change is a code change. A pre-tag abort with no finding code (for example, a transient secrets-preflight timeout) is a transient stop: nothing was promoted and no tag was cut. Confirm no tag reached origin (`git ls-remote --tags origin` or `gh api repos/{owner}/{repo}/tags`), then rerun `mmi-cli devops release --apply` as a fresh cut, never `--resume`; resume is only for a partial release with the tag already on origin. A partial release (tag on origin, later phases pending or failed) continues with `mmi-cli devops release --resume --watch --json --out <fresh-receipt>` — the only continuation form: `--resume` never re-tags, republishes or re-announces, and `--apply` belongs to a new cut only. A refused train is a stop (Merge floor): fix the cause on `development` through a normal PR, then rerun.
+Every refusal and every doctor blocker names its `code` and `anchor`: open `docs/Guides/train-troubleshooting.md#<code>` and follow that entry, nothing else. That guide is test-parsed, never free text — the infra drift and plugin-set suites validate every anchor cited here and assert policy from its wording — so an edit to it re-runs the infra suite (`npm --prefix infra test`) in the same PR: a heading or slug change is a code change. A pre-tag abort with no finding code (for example, a transient secrets-preflight timeout) is a transient stop: nothing was promoted and no tag was cut. Confirm no tag reached origin (`git ls-remote --tags origin` or `gh api repos/{owner}/{repo}/tags`), then rerun `mmi-cli devops release --apply` as a fresh cut, never `--resume`; resume is only for a partial release with the tag already on origin. A partial release (tag on origin, later phases pending or failed) continues with `mmi-cli devops release --resume --watch --json --out <fresh-receipt>` — the only continuation form: `--resume` never re-tags or republishes, posts a deferred announcement only when it is the run that first proves deploy and publish green, and `--apply` belongs to a new cut only. A refused train is a stop (Merge floor): fix the cause on `development` through a normal PR, then rerun.
 
 A **content-caused failed deploy leg on a published release** has no rerun that can succeed: the promoted tag is immutable, redeploying it rebuilds the same broken SHA, and the unresolved ledger blocks every lane — release, hotfix and candidate alike — while `--abort` is unavailable because the release is published. When the doctor's ledger blocker names `deploy` as the only unresolved leg and the deploy failure is proven content-caused (the deploy-time validator rejected the shipped content itself), the sanctioned exit is `mmi-cli devops release --supersede-deploy --apply` — an explicitly master-approved closure, run only after the cause fix is merged on `development`. It closes the deploy leg as superseded (the ledger turns phases-green), and the next patch train — usually `/hotfix`, which carries the fix to main — runs normally; its lifecycle gate archives the closed ledger aside. Never hand-edit the ledger file, never delete it to unblock a train.
 

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