@mutmutco/kimi-plugin 4.1.12 → 4.1.13

package/.kimi-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "mmi",
-  "version": "4.1.12",
+  "version": "4.1.13",
   "description": "MMI workflow skills and org gates delivery.",
   "author": {
     "name": "MMI Future",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mutmutco/kimi-plugin",
-  "version": "4.1.12",
+  "version": "4.1.13",
   "description": "MMI workflow skills and org gates delivery.",
   "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
@@ -719,6 +731,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