@mutmutco/pi-plugin 4.5.3 → 4.5.5

package/package.json

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

package/skills/hotfix/SKILL.md

@@ -19,7 +19,7 @@ Read META and name the lane before describing or executing anything:
 mmi-cli oracle org project get {owner}/{repo} --json
 ```
 
-A hotfix always skips rc on every track: it cherry-picks `development → main` directly, MMI-Hub included. `deployModel` decides the release-triggered runs the train watches; on `vercel` nothing is dispatched — Vercel builds `main` on the merge and the train reads its Production Deployment, same as `/release`. Unreadable META → stop; never infer the lane from branch names, tags or release history.
+A hotfix always skips rc on every track: it cherry-picks `development → main` directly, MMI-Hub included. `deployModel` decides the release-triggered runs the train watches; on `vercel` nothing is dispatched — Vercel builds `main` on the push and the hotfix waits for its Production Deployment and probes the URL, same as `/release --watch`; a leg left pending settles on the next doctor `--heal`. Unreadable META → stop; never infer the lane from branch names, tags or release history.
 
 ## Preflight
 
@@ -27,7 +27,7 @@ A hotfix always skips rc on every track: it cherry-picks `development → main`
 mmi-cli devops train doctor --lane hotfix --heal --json
 ```
 
-Read `ready`, then `findings[]`: each carries `code`, `severity` (`blocker` · `warning` · `healed` · `info`), `source` (`local` · `origin`), `remedy` and `anchor`. `ready: false` → stop and quote every blocker's `code` and `remedy`; an unread origin is never green. `hotfix start` and `hotfix release` re-run this doctor as their step 0 with heal on.
+The JSON is on stdout alone; a stale CLI first prints its self-update notice on stderr and re-runs itself, so parse stdout only, never `2>&1`. Read `ready`, then `findings[]`: each carries `code`, `severity` (`blocker` · `warning` · `healed` · `info`), `source` (`local` · `origin`), `remedy` and `anchor`. `ready: false` → stop and quote every blocker's `code` and `remedy`; an unread origin is never green. `hotfix start` and `hotfix release` re-run this doctor as their step 0 with heal on.
 
 ## Apply
 

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

@@ -76,10 +76,11 @@ development. A trunk repository follows its single branch and declared workflow
   then [release](../../release/SKILL.md) for promotion. The release workflow also describes its
   supported development-source route.
 - Direct track: development → main. Use [release](../../release/SKILL.md); do not invent an rc lane.
-- Vercel-hosted repos (registry `deployModel: vercel`) are direct track: merging development → main
-  is the go-live, Vercel deploys main itself, and the release train waits for that deploy and checks
-  the live URL before it tags and announces. No version-file bump on these repos. Every branch has a
-  Vercel preview URL; [stage](../../stage/SKILL.md) reports it. No rc, no box stage.
+- Vercel-hosted repos (registry `deployModel: vercel`) keep their track (direct or full): the push to
+  main is the go-live, Vercel deploys each branch itself, and the train waits for that deploy and checks
+  the live URL before it announces; on full track rcand does the same for the rc deploy. No version-file
+  bump on these repos. Every branch has a Vercel preview URL; [stage](../../stage/SKILL.md) reports it.
+  No box stage.
 - Trunk track: one main branch, without an rc/development promotion train. Follow the repository's
   declared publishing workflow rather than manufacturing train branches.
 - Urgent already-merged fixes: use [hotfix](../../hotfix/SKILL.md), which carries selected development
@@ -98,7 +99,8 @@ that actually ships in the cut: the train refuses an issue or PR number the rele
 commit, so build and verify the lines from one pass over that range —
 `git log --stat --format='%h %s%n%b' origin/main..origin/development`, which carries each commit's
 subject, body and changed files — never from subjects, PR titles or memory; a line whose claim is not
-in that output does not go in the file.
+in that output does not go in the file. A Hub summary never mentions a Jerv-side project; the train
+refuses such a line.
 
 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.
@@ -117,7 +119,9 @@ AWS is the org control plane and the vaults only; Hetzner boxes run every long-r
 links (`vercel`); Cloudflare owns all DNS, TLS and tunnels; one-line installers are served
 from the product family's own box — `get.mutmut.work/<product>` for MMI and MM products, `get.jerv.ai/<product>`
 for Jerv products — never mixed. Whether a repo ships one, its family and its sign-in are registry
-facts (META `installer`, `docs/decisions/2026-09-23-installer-platform.md`). `hub-serverless` is the Hub control plane itself, and `registry-publish`/`none` are not
+facts (META `installer`, `docs/decisions/2026-09-23-installer-platform.md`). MMI-Hub serves the
+shared installer and face; it follows no repo. Each repo's own release refreshes its installer lock
+and proves its own channel. `hub-serverless` is the Hub control plane itself, and `registry-publish`/`none` are not
 hosted services. Sign-in gates and signed payloads stay on each product's own server. Do not move a
 workload to a different provider, or add a second one for the same job, without an explicit owner
 decision.

package/skills/rcand/SKILL.md

@@ -19,7 +19,7 @@ Read META and name the lane before describing or executing anything:
 mmi-cli oracle org project get {owner}/{repo} --json
 ```
 
-`releaseTrack: direct` (product repos with explicit META, plus MMI-Hub, and every `deployModel: vercel` repo) has no `rc`: stop here and run `/release` from `development`; `rcand --apply` refuses direct-track at its own preflight. Full-track runs from `development`, and a full-track repo may skip rc entirely with `/release --dev`. Unreadable META → stop; never infer the lane from branch names, a stale `rc` ref, or release history.
+`releaseTrack: direct` (product repos with explicit META, plus MMI-Hub) has no `rc`: stop here and run `/release` from `development`; `rcand --apply` refuses direct-track at its own preflight. Full-track runs from `development`, and a full-track repo may skip rc entirely with `/release --dev`. A full-track `deployModel: vercel` repo runs rcand as usual; the train dispatches nothing and, with `--watch`, waits for the non-Production Deployment Vercel builds for the rc push, then probes its URL. Unreadable META → stop; never infer the lane from branch names, a stale `rc` ref, or release history.
 
 Authority is structural and server-checked: the doctor asks the Hub, and the protected `rc` push allowlist carries the same people (master + that repo's project-admins). Gate ordering: the tag lands the rc SHA for checks, and every deploy side-effect waits until the protected `rc` push accepts that checked SHA.
 
@@ -29,7 +29,7 @@ Authority is structural and server-checked: the doctor asks the Hub, and the pro
 mmi-cli devops train doctor --lane rcand --heal --json
 ```
 
-Read `ready`, then `findings[]`: each carries `code`, `severity` (`blocker` · `warning` · `healed` · `info`), `source` (`local` · `origin`), `remedy` and `anchor`. `ready: false` → stop and quote every blocker's `code` and `remedy`; an unread origin is never green. `--apply` re-runs this doctor as its step 0 with heal on.
+The JSON is on stdout alone; a stale CLI first prints its self-update notice on stderr and re-runs itself, so parse stdout only, never `2>&1`. Read `ready`, then `findings[]`: each carries `code`, `severity` (`blocker` · `warning` · `healed` · `info`), `source` (`local` · `origin`), `remedy` and `anchor`. `ready: false` → stop and quote every blocker's `code` and `remedy`; an unread origin is never green. `--apply` re-runs this doctor as its step 0 with heal on.
 
 ## Apply
 
@@ -50,14 +50,14 @@ Read the receipt at `$r`, never the exit code (exit `1` = the deploy failed afte
 - `promoted` — `true` even when the deploy failed; promotion and deploy are separate outcomes.
 - `tag` — the minted `vX.Y.0-rc.N`; `resumeNote` says an existing rc tag was resumed rather than minted.
 - `deployStatus` — `pending` is never terminal. `runId` / `runUrl` / `workflowRuns` name the run: the dispatched `tenant-deploy.yml` for tenant-container, the auto-fired `deploy.yml` for serverless. Watch each non-success entry to conclusion: `gh run watch <run-id> --repo {owner}/{repo} --exit-status`.
-- `environments` — the rc edge domain(s) from META, the env URL the report names.
-- `checkout`, `localSync`, `ledger` — `returned` and phases-green, or the named reason you are still on `rc`.
+- `releaseVerdict` — `followUpStatus` (`complete` · `pending` · `failed`) and one `legs` row per follow-up; a failed row carries its error.
+- `checkout`, `localSync`, `ledger` — `checkout.status: returned` to `development` and phases-green, or the named reason it is not.
 
-Then confirm origin: `git rev-list --count origin/rc..origin/development` is `0` and the rc tag is on origin. There is no GitHub Release at rc; the bounded Latest read belongs to `/release`. A red deploy after a green promotion is a deploy retry of the existing rc ref, never a re-tag or re-merge.
+Then confirm origin: `git rev-list --count origin/rc..origin/development` is `0` and the rc tag is on origin. There is no GitHub Release at rc; the bounded Latest read belongs to `/release`. A red deploy after a green promotion is a deploy retry of the same candidate, never a re-tag or re-merge (Recovery).
 
 ## 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 candidate whose immutable rc tag passed policy but whose `origin/rc` was not pushed continues with `mmi-cli devops rcand --resume --watch --json --out <fresh-receipt>` — the only continuation form: `--resume` never re-tags, and `--apply` mints the next `-rc.N` for a new cut only. A refused train is a stop (Merge floor): fix the cause on `development` through a normal PR, then rerun; a rejected protected push leaves the local tag for an authorized rerun, never a force.
+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 candidate whose immutable rc tag passed policy but whose `origin/rc` was not pushed continues with `mmi-cli devops rcand --resume --watch --json --out <fresh-receipt>` — the only continuation form: `--resume` never re-tags, and `--apply` mints the next `-rc.N` for a new cut only. A promoted candidate whose rc deploy failed retries it, once the cause is fixed, with `mmi-cli devops rcand --retry-deploy --watch --json --out <fresh-receipt>` — same tag and SHA, never re-cut or re-pushed; `--resume` only re-reads that failed leg. Supersede is the last resort, with the authorized human's fresh approval. A refused train is a stop (Merge floor): fix the cause on `development` through a normal PR, then rerun; a rejected protected push leaves the local tag for an authorized rerun, never a force.
 
 ## Merge floor
 

package/skills/release/SKILL.md

@@ -21,7 +21,7 @@ mmi-cli oracle org project get {owner}/{repo} --json
 
 `releaseTrack: direct` → `development → main`, no `/rcand`. Absent → full (`rc → main`), except MMI-Hub, which is direct by the Hub-control special case. Full-track `--dev` ships `development → main` skipping rc and fails closed when `origin/rc` carries content not in `development`. Unreadable META → stop; never infer the lane from branch names, tags or release history.
 
-`deployModel: vercel` (always with `releaseTrack: direct`): the same `development → main` merge is the go-live — Vercel builds `main` on the push. The train dispatches nothing; with `--watch` it waits for the **Production** GitHub Deployment the Vercel GitHub app posts for the release SHA, probes the served URL once, then tags, publishes the Release and announces. No version-file bump on a vercel repo — the tag is the version. The receipt's `workflowRuns` carries a `vercel` row with the Vercel log URL; `pending` with "is the Vercel GitHub app connected?" means no Deployment was ever posted — connect the app, never re-tag.
+`deployModel: vercel` (on either track): the push to `main` is the go-live — Vercel builds `main` itself. The train dispatches nothing; with `--watch` it waits for the **Production** GitHub Deployment the Vercel GitHub app posts for the release SHA, probes the served URL once, and announces once it is green. Unwatched or timed out, the deploy leg stays `pending` and settles on `release --resume` or the next doctor `--heal`, which re-read the Deployment. No version-file bump on a vercel repo — the tag is the version. The receipt's `workflowRuns` carries a `vercel` row with the Vercel log URL; `pending` with "is the Vercel GitHub app connected?" means no Deployment was ever posted — connect the app, never re-tag.
 
 ## Preflight
 
@@ -29,13 +29,13 @@ mmi-cli oracle org project get {owner}/{repo} --json
 mmi-cli devops train doctor --lane release --heal --json
 ```
 
-Read `ready`, then `findings[]`: each carries `code`, `severity` (`blocker` · `warning` · `healed` · `info`), `source` (`local` · `origin`), `remedy` and `anchor`. `ready: false` → stop and quote every blocker's `code` and `remedy`; an unread origin is never green. `--apply` re-runs this doctor as its step 0 with heal on.
+The JSON is on stdout alone; a stale CLI first prints its self-update notice on stderr and re-runs itself, so parse stdout only, never `2>&1`. Read `ready`, then `findings[]`: each carries `code`, `severity` (`blocker` · `warning` · `healed` · `info`), `source` (`local` · `origin`), `remedy` and `anchor`. `ready: false` → stop and quote every blocker's `code` and `remedy`; an unread origin is never green. `--apply` re-runs this doctor as its step 0 with heal on.
 
 ## Apply
 
 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.
 
-Two cases need a summary file. (1) **MMI-Hub** — always: write a fresh 3–6 line neutral summary to `f=$(mkdir -p .jerv/tmp && mktemp .jerv/tmp/release-summary.XXXXXX)` — sourced from the range `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. **Build and verify every line from ONE command's output**, never from commit subjects or PR titles alone: `git log --stat --format='%h %s%n%b' origin/main..origin/development` gives each commit's subject, its full body (where a bundled PR records `Closes #N`) and the files it changed in a single pass. A line whose claim you cannot point to in that output does not go in the file, and every `#N` a Hub line cites must appear there: the train refuses `--apply` on a citation that ships in no commit of the cut. (2) **Any product repo whose META carries `releaseChannel`** (`mmi-cli oracle org project get {owner}/{repo} --json`) — required too: read `releaseLanguage` (default `en`) and write 3–6 lines IN THAT LANGUAGE, in plain words for the project's audience: what changed and why it matters to a user; no commit prefixes, no issue or PR numbers, no file names, no product-internal jargon. The train refuses `--apply` without the file, and raw release notes are never posted to a project channel. A repo with no `releaseChannel` announces nothing and needs no file.
+Two cases need a summary file. (1) **MMI-Hub** — always: write a fresh 3–6 line neutral summary to `f=$(mkdir -p .jerv/tmp && mktemp .jerv/tmp/release-summary.XXXXXX)` — sourced from the range `origin/main..origin/development`, rewritten in Hub-subsystem terms, never a product or brand name, and never a Jerv-side project (the train refuses such a line). Hub scope is only `mutmutco/MMI-Hub`: never a product's board, `ds-propagate.yml`, or a product's deploy state. **Build and verify every line from ONE command's output**, never from commit subjects or PR titles alone: `git log --stat --format='%h %s%n%b' origin/main..origin/development` gives each commit's subject, its full body (where a bundled PR records `Closes #N`) and the files it changed in a single pass. A line whose claim you cannot point to in that output does not go in the file, and every `#N` a Hub line cites must appear there: the train refuses `--apply` on a citation that ships in no commit of the cut. (2) **Any product repo whose META carries `releaseChannel`** (`mmi-cli oracle org project get {owner}/{repo} --json`) — required too: read `releaseLanguage` (default `en`) and write 3–6 lines IN THAT LANGUAGE, in plain words for the project's audience: what changed and why it matters to a user; no commit prefixes, no issue or PR numbers, no file names, no product-internal jargon. The train refuses `--apply` without the file, and raw release notes are never posted to a project channel. A repo with no `releaseChannel` announces nothing and needs no file.
 
 ```bash
 mkdir -p .jerv/tmp
@@ -75,7 +75,7 @@ Read the saved result, never the exit code (exit `1` = a follow-up failed after
 
 - `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`.
 - `deployStatus` — `pending` is never terminal; `promoted: true` holds even when a deploy failed.
-- `served-channel(<product>)` row — the release's proof that new installs get it: the public `/release/version` pointer of the Hub's `mmi`, `mm-strategy`, `jerv` or `jervcode` channel, read after deploy and publish are green. `success` names the version read. `failure` is either a channel still on the previous version or a stale served process (the route answers 401/404): the note names what moves that channel and the exact remedy; run it, then re-read the pointer. `pending` means not probed (legs not green) or unreadable, never proof. The row is receipt evidence only, never a ledger leg, so it never blocks the next train.
+- `served-channel(<product>)` row — the release's proof that new installs get it: the public `/release/version` pointer of the releasing repo's OWN channel (the Hub's `mmi`, or the product its registry `installer` declaration names; no declaration → no row), read after deploy and publish are green. `success` names the version read. `failure` is either a channel still on the previous version or a stale served process (the route answers 401/404): the note names what moves that channel and the exact remedy; run it, then re-read the pointer. `pending` means not probed (legs not green) or unreadable, never proof. The row is receipt evidence only, never a ledger leg, so it never blocks the next train.
 - `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`, `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.