gm-plugkit 2.0.2253 → 2.0.2255

package/SKILL.md

@@ -116,11 +116,11 @@ VERIFY is adversarial, never confirmatory: run the real code path and read its a
 
 **Noticing is a planning event, every phase, not just PLAN.** Anything observed mid-walk -- outstanding work, an unfinished surface, an improvable shape, drift from these rules -- is `prd-add` this turn; response-body-only observations evaporate at turn end. Density grows along the whole walk, not just at PLAN; exiting VERIFY or CONSOLIDATE with the same row-count PLAN started with is lost discoveries, not a clean run.
 
-`git push` only when `git status --porcelain` is empty. Dirty tree blocks CONSOLIDATE/COMPLETE gate. Prefer `git_push` verb over Bash git commands; git via Bash records as `deviation.bash-git-bypass`.
+`git push` only when `git status --porcelain` is empty. Dirty tree blocks the DECIDE -> COMPLETE gate. Prefer `git_push` verb over Bash git commands; git via Bash records as `deviation.bash-git-bypass`.
 
-Phase transitions: PLAN -> EXECUTE, EXECUTE -> EMIT, EMIT -> VERIFY, VERIFY -> CONSOLIDATE, CONSOLIDATE -> COMPLETE. Each requires `transition {to:"PHASE"}` dispatch. EXECUTE resolves mutables in `.gm/mutables.yml` before EMIT. EMIT writes file changes. VERIFY validates via `exec_js`/`browser`. CONSOLIDATE pushes changes via `git_finalize` or `git_push`, then witnesses CI/CD pipeline green. COMPLETE gate requires: worktree clean, remote pushed, mutables resolved, and `.ci-validated` marker written with current commit SHA. This is the built-in default graph, not an exhaustive list of legal phase names -- a project's `.gm/instructions/fsm/graph.json` (written by the `fsm-vendor` verb) can define a different phase set, additional states, or a different edge/gate shape entirely. Never assume this exact chain; dispatch `instruction` and read its `phase`/`next_phase_hint` fields to discover the live graph's actual state, whatever a specific project's graph happens to define.
+Phase transitions (the built-in default graph, not an exhaustive list of legal phase names): SPECIFY -> PROVE -> EMIT -> STATE -> CONC -> SEC -> RES -> DECIDE -> COMPLETE, with feedback edges from every later stage back to SPECIFY (reshaping), EMIT (repair), STATE (boundary enforcement), and PROVE (empirical fitness). Each requires `transition {to:"PHASE"}` dispatch. SPECIFY writes the PRD. PROVE drains `.gm/mutables.yml` (gated). EMIT writes file changes (gated on source hygiene). STATE/CONC/SEC/RES audit the diff per stage (functional core, concurrency, security, resilience; each boundary gated on its mechanically-checkable subset). DECIDE validates adversarially via `exec_js`/`browser`, pushes via `git_finalize` or `git_push`, then witnesses CI/CD pipeline green. COMPLETE gate requires: worktree clean, remote pushed, PRD empty, mutables resolved, residual-scan fired, CI green (`.ci-validated` marker matching current HEAD), browser-witness coverage, submodules clean, claim-audit clean, no hedge language. A project's `.gm/instructions/fsm/graph.json` (written by the `fsm-vendor` verb) can define a different phase set, additional states, or a different edge/gate shape entirely. Never assume this exact chain; dispatch `instruction` and read its `phase`/`next_phase_hint` fields to discover the live graph's actual state, whatever a specific project's graph happens to define.
 
-CI/CD validation in CONSOLIDATE phase: After push succeeds, watch the triggered workflow. When pipeline goes green, dispatch `fs_write {path:".gm/exec-spool/.ci-validated", content:"{\"head_sha\":\"<current commit SHA>\"}"}` to mark validation complete -- the marker's file CONTENT is the JSON string `{"head_sha":"<SHA>"}`, passed under the `content` field the fs_write handler reads (not a `body`/`head_sha` object, which the handler ignores). `.ci-validated`'s head_sha must match current HEAD; COMPLETE gate refuses if stale or missing. Red runs require fix + re-push + re-watch; no skip for "it looked safe."
+CI/CD validation in DECIDE phase: After push succeeds, watch the triggered workflow. When pipeline goes green, dispatch `fs_write {path:".gm/exec-spool/.ci-validated", content:"{\"head_sha\":\"<current commit SHA>\"}"}` to mark validation complete -- the marker's file CONTENT is the JSON string `{"head_sha":"<SHA>"}`, passed under the `content` field the fs_write handler reads (not a `body`/`head_sha` object, which the handler ignores). `.ci-validated`'s head_sha must match current HEAD; COMPLETE gate refuses if stale or missing. Red runs require fix + re-push + re-watch; no skip for "it looked safe."
 
 Memory via `memorize-fire` dispatch stores in `.gm/rs-learn.db` and is retrieved via `recall` and `auto_recall`. `discipline-note {discipline, text}` writes `.gm/disciplines/<name>/policy.md`; `instruction` auto-surfaces policies from disciplines listed in `.gm/disciplines/enabled.txt`.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-plugkit",
-  "version": "2.0.2253",
+  "version": "2.0.2255",
   "description": "Bootstrap and daemon-spawn tool for gm plugkit binary. Downloads the correct platform wasm, verifies SHA256, and launches agentplug-runner (the native wasm host) as the spool watcher daemon.",
   "main": "index.js",
   "bin": {