@mutmutco/codex-plugin 4.3.14 → 4.3.16

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "mmi",
-  "version": "4.3.14",
+  "version": "4.3.16",
   "mmiCompat": "4.x",
   "description": "MMI workflow skills and org gates delivery.",
   "author": {

package/package.json

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

package/skills/bootstrap/SKILL.md

@@ -366,9 +366,13 @@ collaborator list + the per-branch allowlist are the record — no separate rost
   `pytest` / `pip install -e ".[dev]"` with `--var GATE_PY_VERSION=` (3.11 default). The runtime selects
   which setup step (`setup-node` vs `setup-python`) the rendered `if:` fires. The check command runs
   under the org **wall-clock budget** (#3178): the render pins `run-with-budget` to the CLI's blessed SHA
+  (since #6256 that one pin also covers the `zeroci-verify` step — both actions ship from the same Hub commit)
   with `--var GATE_MAX_SECONDS=` (300s onboarding default — tighten once the gate is measured, via
   `--var` or `org project set <repo> --var gate={"maxSeconds":N}`); `ci audit` and the release train
-  both enforce the step, so do not remove it. `bootstrap apply --execute` installs that JSON as the
+  both enforce the step, so do not remove it. ZeroCI C3 (#6254): `--var GATE_AFFECTED_CMD=...` (or
+  `gate={"affectedCmd":"..."}`) runs an affected-only selection on pull_request instead of `GATE_CMD`;
+  empty (default) keeps the full suite on PRs. Pushes, tags and the rendered nightly `schedule`
+  (`17 3 * * *` on the default branch) always run the full `GATE_CMD` — that nightly is the drift catcher. `bootstrap apply --execute` installs that JSON as the
   repository ruleset itself (#6070) and reports one `product-ruleset` row: `PARK` (the gate file is not on
   the base branch yet — installed disabled), `WAIT` (the gate exists but has not emitted a proven-green
   `gate` context — kept disabled; re-run apply after the gate passes), `ACTIVATE` (gate green — enforcement
@@ -550,6 +554,7 @@ Before your final report, answer one question honestly: did **this skill's own i
 this run — ambiguous wording, a misleading message, or an environment failure it should have warned
 about? (Process only — never the user's code or task; e.g. an ambiguous seed, registry, or OIDC step, or
 a guard that fired on a healthy repo.) If yes, file **one** lesson and move on; a clean run is silent
-(hard cap: one per run). It lands on the Hub board (deduped) and is fixed only via a reviewed PR — never
-edit the skill live; the retro is advisory, so if the call fails, note it and continue:
-`mmi-cli learning skill-lesson --skill bootstrap --title "<what misfired>" --body "<what; evidence; proposed amendment>"`
+(hard cap: one per run). It lands on the owning board (deduped) and is fixed only via a reviewed PR — never
+edit the skill live; the retro is advisory, so if the call fails, note it and continue. In-session, call the
+`jerv_learning_note` tool with origin retro; the machine fallback is:
+`jervcode learn --origin retro --surface skills --title "bootstrap: <what misfired>" --body "<what; evidence; proposed amendment>"`

package/skills/bootstrap/seeds/gate.template.yml

@@ -1,6 +1,9 @@
 name: gate
 # Org-standard green-before-merge gate for product repos (#1333). Runs on PRs, train-branch pushes,
 # and v* tags so /release and /hotfix can discover required contexts on the tagged SHA.
+# ZeroCI C3 (#6254): a nightly `schedule` run on the default branch executes the FULL GATE_CMD even when
+# a signed receipt already proves the tree — the drift catcher for affected-only PR selection
+# (GATE_AFFECTED_CMD) and for stale receipts. The job `if:` below admits `schedule` (it is not a push).
 #
 # Runner: self-hosted mmi-runner (mmi-live) — see docs/Guides/gh-runner-runbook.md in MMI-Hub.
 # #4118: if GATE_CMD runs tsgo or other memory-heavy typecheck / browser work, pin this job to
@@ -11,6 +14,9 @@ name: gate
 # bootstrap with --var):
 #   GATE_RUNTIME       — node | python (selects which setup step fires)
 #   GATE_CMD           — the check command ({{GATE_CMD}})
+#   GATE_AFFECTED_CMD  — affected-only check command run on pull_request instead of GATE_CMD (#6254);
+#                        empty (default) renders GATE_CMD here too, so the PR gate stays the full suite.
+#                        Pushes, tags and the nightly schedule always run GATE_CMD. ({{GATE_AFFECTED_CMD}})
 #   GATE_INSTALL_CMD   — the dependency-install command ({{GATE_INSTALL_CMD}})
 #   GATE_WORKDIR       — app working directory when not the repo root ({{GATE_WORKDIR}})
 #   GATE_CACHE_DEP_PATH— npm lockfile path for runner-checkout heal ({{GATE_CACHE_DEP_PATH}})
@@ -22,7 +28,8 @@ name: gate
 #   GATE_FULL_RUN_BRANCH — train branch whose PUSHES run the full gate job (development on full/direct;
 #                        main on trunk). `main` is ALWAYS included in the job `if:` below so a required-
 #                        checks ruleset on main cannot be silently skipped by a future bootstrap (#4113).
-# GATE_BUDGET_SHA is rendered by the CLI from its blessed run-with-budget pin — not an operator knob.
+# GATE_BUDGET_SHA is rendered by the CLI from its blessed run-with-budget pin — not an operator knob. It
+# also pins zeroci-verify (MMI-Hub#6253): both actions ship from the same Hub commit.
 # GATE_RUNNER_SHA pins the org runner-checkout / runner-node-toolchain actions (#5610).
 # Estate policy 2026-08-23: GitHub-hosted Windows (`windows-latest` / windows-*) is forbidden org-wide.
 # Do not add a windows-compat (or any other) job that runs-on GH-hosted Windows. Linux self-hosted
@@ -34,6 +41,9 @@ on:
   push:
     branches: {{GATE_PUSH_BRANCHES_YAML}}
     tags: ['v*']
+  # #6254: nightly full run on the default branch — catches affected-only drift and stale receipts.
+  schedule:
+    - cron: '17 3 * * *'
 
 env:
   FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
@@ -48,6 +58,8 @@ concurrency:
 
 permissions:
   contents: read
+  # MMI-Hub#6253: ZeroCI receipts are commit statuses on the PR head; the gate reads them, never writes them.
+  statuses: read
 
 jobs:
   gate:
@@ -115,10 +127,31 @@ jobs:
         if: ${{ '{{GATE_RUNTIME}}' == 'python' }}
         run: |
           python3 --version || { echo "::error title=CI runner toolchain::RUNNER NOT PROVISIONED — python3 not on PATH after setup-python. This is the runner, not your diff; no install or test ran. Re-run the job; if it persists the mmi-runner python toolchain needs attention (docs/Guides/gh-runner-runbook.md in MMI-Hub)."; exit 1; }
+      # MMI-Hub#6253 ZeroCI: skip the install and the budgeted run when a trusted seat already ran this
+      # exact command on this exact tree (receipt = commit status zeroci/<command> on the PR head). It
+      # needs only git and gh, so it sits before the install. Only `verified=true` skips;
+      # absent/stale/unreadable fall through to the install and the budgeted run below.
+      - id: zeroci
+        uses: mutmutco/MMI-Hub/.github/actions/zeroci-verify@{{GATE_BUDGET_SHA}}
+        with:
+          command: {{GATE_CMD}}
+          working-directory: {{GATE_WORKDIR}}
+          head-sha: ${{ github.event.pull_request.head.sha || github.sha }}
       - run: {{GATE_INSTALL_CMD}}
+        if: ${{ steps.zeroci.outputs.verified != 'true' || github.event_name == 'schedule' }}
       # #3178: the check runs under the org wall-clock budget — a hung suite dies at the ceiling instead
       # of squatting a runner lane for GitHub's 6h default. ci-audit + the release train enforce this step.
-      - uses: mutmutco/MMI-Hub/.github/actions/run-with-budget@{{GATE_BUDGET_SHA}}
+      # #6254 (ZeroCI C3): two complementary budget steps. pull_request runs GATE_AFFECTED_CMD (rendered
+      # equal to GATE_CMD until the knob is set); every other trigger runs the full GATE_CMD. The nightly
+      # schedule runs even when the zeroci receipt already proves the tree — that is its whole point.
+      - if: ${{ steps.zeroci.outputs.verified != 'true' && github.event_name == 'pull_request' }}
+        uses: mutmutco/MMI-Hub/.github/actions/run-with-budget@{{GATE_BUDGET_SHA}}
+        with:
+          command: {{GATE_AFFECTED_CMD}}
+          max-seconds: {{GATE_MAX_SECONDS}}
+          working-directory: {{GATE_WORKDIR}}
+      - if: ${{ github.event_name != 'pull_request' && (steps.zeroci.outputs.verified != 'true' || github.event_name == 'schedule') }}
+        uses: mutmutco/MMI-Hub/.github/actions/run-with-budget@{{GATE_BUDGET_SHA}}
         with:
           command: {{GATE_CMD}}
           max-seconds: {{GATE_MAX_SECONDS}}

package/skills/epic/SKILL.md

@@ -123,6 +123,7 @@ Before your final report, answer one question honestly: did **this skill's own i
 this run — ambiguous wording, a misleading message, or an environment failure it should have warned
 about? (Process only — never the user's code or task; e.g. a batch schema that rejected a valid row, or a
 link that attached to the wrong parent.) If yes, file **one** lesson and move on; a clean run is silent
-(hard cap: one per run). It lands on the Hub board (deduped) and is fixed only via a reviewed PR — never
-edit the skill live; the retro is advisory, so if the call fails, note it and continue:
-`mmi-cli learning skill-lesson --skill epic --title "<what misfired>" --body "<what; evidence; proposed amendment>"`
+(hard cap: one per run). It lands on the owning board (deduped) and is fixed only via a reviewed PR — never
+edit the skill live; the retro is advisory, so if the call fails, note it and continue. In-session, call the
+`jerv_learning_note` tool with origin retro; the machine fallback is:
+`jervcode learn --origin retro --surface skills --title "epic: <what misfired>" --body "<what; evidence; proposed amendment>"`

package/skills/hotfix/SKILL.md

@@ -95,8 +95,8 @@ Title first, verdict first. Name the resolved tag (never a placeholder like `vX.
 
 ## Retro
 
-Before the final report, answer one question honestly: did this skill's own instructions misfire this run — ambiguous wording, a misleading message, or an environment failure it should have warned about? Process only, never the user's code or task. If yes, file one lesson and move on; a clean run is silent (hard cap: one per run). It lands on the Hub board, deduplicated, and is fixed only through a reviewed PR — never edit the skill live. The retro is advisory: if the call fails, note it and continue. The amendment itself stays reference-free: the skill-drift gate rejects issue references in any section outside Merge floor, so carry the evidence in words or point at the guide entry — never inline reference markers.
+Before the final report, answer one question honestly: did this skill's own instructions misfire this run — ambiguous wording, a misleading message, or an environment failure it should have warned about? Process only, never the user's code or task. If yes, file one lesson and move on; a clean run is silent (hard cap: one per run). It lands on the owning board, deduplicated, and is fixed only through a reviewed PR — never edit the skill live. The retro is advisory: if the call fails, note it and continue. In-session, call the `jerv_learning_note` tool with origin retro and let it queue the lesson; the command below is the machine fallback. The amendment itself stays reference-free: the skill-drift gate rejects issue references in any section outside Merge floor, so carry the evidence in words or point at the guide entry — never inline reference markers.
 
 ```bash
-mmi-cli learning skill-lesson --skill hotfix --title "<what misfired>" --body "<what; evidence; proposed amendment>"
+jervcode learn --origin retro --surface skills --title "hotfix: <what misfired>" --body "<what; evidence; proposed amendment>"
 ```

package/skills/rcand/SKILL.md

@@ -73,8 +73,8 @@ Title first, verdict first. Name the resolved tag (never a placeholder like `vX.
 
 ## Retro
 
-Before the final report, answer one question honestly: did this skill's own instructions misfire this run — ambiguous wording, a misleading message, or an environment failure it should have warned about? Process only, never the user's code or task. If yes, file one lesson and move on; a clean run is silent (hard cap: one per run). It lands on the Hub board, deduplicated, and is fixed only through a reviewed PR — never edit the skill live. The retro is advisory: if the call fails, note it and continue. The amendment itself stays reference-free: the skill-drift gate rejects issue references in any section outside Merge floor, so carry the evidence in words or point at the guide entry — never inline reference markers.
+Before the final report, answer one question honestly: did this skill's own instructions misfire this run — ambiguous wording, a misleading message, or an environment failure it should have warned about? Process only, never the user's code or task. If yes, file one lesson and move on; a clean run is silent (hard cap: one per run). It lands on the owning board, deduplicated, and is fixed only through a reviewed PR — never edit the skill live. The retro is advisory: if the call fails, note it and continue. In-session, call the `jerv_learning_note` tool with origin retro and let it queue the lesson; the command below is the machine fallback. The amendment itself stays reference-free: the skill-drift gate rejects issue references in any section outside Merge floor, so carry the evidence in words or point at the guide entry — never inline reference markers.
 
 ```bash
-mmi-cli learning skill-lesson --skill rcand --title "<what misfired>" --body "<what; evidence; proposed amendment>"
+jervcode learn --origin retro --surface skills --title "rcand: <what misfired>" --body "<what; evidence; proposed amendment>"
 ```

package/skills/release/SKILL.md

@@ -82,8 +82,8 @@ Title first, verdict first. Name the resolved tag (never a placeholder like `vX.
 
 ## Retro
 
-Before the final report, answer one question honestly: did this skill's own instructions misfire this run — ambiguous wording, a misleading message, or an environment failure it should have warned about? Process only, never the user's code or task. If yes, file one lesson and move on; a clean run is silent (hard cap: one per run). It lands on the Hub board, deduplicated, and is fixed only through a reviewed PR — never edit the skill live. The retro is advisory: if the call fails, note it and continue. The amendment itself stays reference-free: the skill-drift gate rejects issue references in any section outside Merge floor, so carry the evidence in words or point at the guide entry — never inline reference markers.
+Before the final report, answer one question honestly: did this skill's own instructions misfire this run — ambiguous wording, a misleading message, or an environment failure it should have warned about? Process only, never the user's code or task. If yes, file one lesson and move on; a clean run is silent (hard cap: one per run). It lands on the owning board, deduplicated, and is fixed only through a reviewed PR — never edit the skill live. The retro is advisory: if the call fails, note it and continue. In-session, call the `jerv_learning_note` tool with origin retro and let it queue the lesson; the command below is the machine fallback. The amendment itself stays reference-free: the skill-drift gate rejects issue references in any section outside Merge floor, so carry the evidence in words or point at the guide entry — never inline reference markers.
 
 ```bash
-mmi-cli learning skill-lesson --skill release --title "<what misfired>" --body "<what; evidence; proposed amendment>"
+jervcode learn --origin retro --surface skills --title "release: <what misfired>" --body "<what; evidence; proposed amendment>"
 ```

package/skills/secrets/SKILL.md

@@ -163,6 +163,7 @@ Before your final report, answer one question honestly: did **this skill's own i
 this run — ambiguous wording, a misleading message, or an environment failure it should have warned
 about? (Process only — never the user's code or task; e.g. a canonical-name or tier mix-up, or a step
 that risked echoing a value.) If yes, file **one** lesson and move on; a clean run is silent (hard cap:
-one per run). It lands on the Hub board (deduped) and is fixed only via a reviewed PR — never edit the
-skill live; the retro is advisory, so if the call fails, note it and continue:
-`mmi-cli learning skill-lesson --skill secrets --title "<what misfired>" --body "<what; evidence; proposed amendment>"`
+one per run). It lands on the owning board (deduped) and is fixed only via a reviewed PR — never edit the
+skill live; the retro is advisory, so if the call fails, note it and continue. In-session, call the
+`jerv_learning_note` tool with origin retro; the machine fallback is:
+`jervcode learn --origin retro --surface skills --title "secrets: <what misfired>" --body "<what; evidence; proposed amendment>"`

package/skills/stage/SKILL.md

@@ -173,6 +173,7 @@ Before your final report, answer one question honestly: did **this skill's own i
 this run — ambiguous wording, a misleading message, or an environment failure it should have warned
 about? (Process only — never the user's code or task; e.g. a teardown that left a port bound, or a
 Playwright output path aimed at the repo root.) If yes, file **one** lesson and move on; a clean run is
-silent (hard cap: one per run). It lands on the Hub board (deduped) and is fixed only via a reviewed PR —
-never edit the skill live; the retro is advisory, so if the call fails, note it and continue:
-`mmi-cli learning skill-lesson --skill stage --title "<what misfired>" --body "<what; evidence; proposed amendment>"`
+silent (hard cap: one per run). It lands on the owning board (deduped) and is fixed only via a reviewed PR —
+never edit the skill live; the retro is advisory, so if the call fails, note it and continue. In-session, call the
+`jerv_learning_note` tool with origin retro; the machine fallback is:
+`jervcode learn --origin retro --surface skills --title "stage: <what misfired>" --body "<what; evidence; proposed amendment>"`