@mutmutco/cursor-plugin 4.1.12 → 4.1.14

package/.cursor-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "mmi",
-  "version": "4.1.12",
+  "version": "4.1.14",
   "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.1.12",
+  "version": "4.1.14",
   "description": "MMI workflow skills and organisation gates for Cursor.",
   "author": {
     "name": "MMI Future",

package/skills/release/SKILL.md

@@ -488,6 +488,18 @@ For other direct-track repos, the train dispatches nothing centrally: a `registr
 event fires its own `publish.yml` (npm / plugin marketplace); a `solo-container` repo deploys via its own
 workflow. Publish the GitHub Release, then watch/report that repo's own release-triggered run.
 
+**Jerv-Hub has one additional fail-closed operator-host phase (#5699).** Only for exact repository
+`mutmutco/Jerv-Hub`, after its release-triggered `publish.yml` is proven green, the train runs
+`scripts/jerv-gateway-release-deploy.sh --tag <resolved-tag>`. That repository helper keeps root SSH in
+Jerv Vault custody, deploys the exact tagged commit to jerv-central, and requires systemd, `/livez`, and
+`/readyz` health. Its validated receipt is appended to `workflowRuns` as `jerv-gateway`; a missing helper,
+refusal, malformed receipt, unhealthy activation, or failed rollback sets `deployStatus: failure`. An
+unwatched/pending publish defers Gateway deployment and keeps `deployStatus: pending` — it never runs the
+host mutation before publication is proven. `release --resume --watch` re-derives the historical publish
+verdict and invokes the idempotent helper once it is green; it never re-tags or republishes the release.
+Do not move this phase into GitHub Actions: no supported Actions identity reaches personal jerv-central
+without moving root SSH custody out of its owning vault.
+
 `mmi-cli devops release --apply --json` returns the relevant run id/url data with `deployStatus`; `--watch` blocks
 on the run(s) and resolves `deployStatus` to `success`/`failure`. For tenant-container repos, that is the
 dispatched `tenant-deploy.yml` run. For Hub serverless, that is the auto-fired release `deploy.yml` and
@@ -687,6 +699,29 @@ Off the publish environment, either:
 - skip the registry identity read with
   `node scripts/release-distribution.mjs verify "X.Y.0" --skip-npm-view` and verify published content
   by hand the same way (including the staged-payload split above when applicable).
+
+**Unpacked proof scratch must not pollute the checkout (#5702).** npm unpack copies full package trees
+including staged `skills/` into whatever directory you choose. Those copies are **not** registered skill
+payloads — if they remain anywhere scannable under the repo root when the next release fold runs
+`check-skill-payload`, the gate fails with `unregistered authored or copied skills`. Prefer unpacking
+**outside** the repository:
+```bash
+PROOF=$(mktemp -d "${TMPDIR:-/tmp}/mmi-release-proof.XXXXXX")
+# unpack both tarballs under $PROOF, diff -r, then:
+rm -rf "$PROOF"
+```
+If you must unpack inside the checkout, use the org-managed gitignored scratch at repo-root `tmp/`
+(`mktemp -d tmp/mmi-release-proof.XXXXXX`) — **not** `.jerv/tmp/` (agent session scratch still lives on
+disk and must not carry npm proof trees between releases). Remove the proof tree **immediately** after the
+diff succeeds; do not leave it for the next `--apply`.
+
+Before the next `release --apply`, confirm no leftover proof copies remain outside org scratch:
+```bash
+node scripts/check-skill-payload.mjs --contract
+```
+A failure naming `unregistered authored or copied skills` means a proof tree (or other rogue copy) is
+still on disk — delete it and rerun the contract check before retrying the train.
+
 Do not treat an off-runner SSRI mismatch as a broken release, and do not change how the runner publishes
 to paper over a local packer difference.
 
@@ -719,6 +754,8 @@ reports the publish as failed. A run whose log never shows the version landed st
 
 Report: Release `$TAG` (the resolved tag from Step 2 — never a placeholder) + the GitHub Release URL · prod
 deploy run + URL + **green/red** · branch-alignment note · npm publish run + CLI version (Hub releases).
+For Jerv-Hub, also report the `jerv-gateway` exact-commit deployment and health verdict; npm green without
+Gateway green is a failed follow-up, never a complete Jerv-Hub release.
 
 ## Notes