gm-skill 2.0.2030 → 2.0.2032

package/bin/plugkit-slim.wasm.sha256

@@ -1 +1 @@
-99107509c628ff90adf99e131cb139fff6f1ef47b229d36504fb4ab6cac1bdfd  plugkit-slim.wasm
+b54c187a5fed4d0f867ddf329fad57f0ff2da6d72cef0805c29a1461e42b0700  plugkit-slim.wasm

package/bin/plugkit.version

@@ -1 +1 @@
-0.1.939
+0.1.941

package/bin/plugkit.wasm.sha256

@@ -1 +1 @@
-20a8f7e0e2bd774a7aa9d63ba91a91cf0b69f2d44d6277c2cba02205544de95d  plugkit.wasm
+5f6cba08a3bc2a84629d6bff991269cd9350ed5926df183a04d12c1db37a7e72  plugkit.wasm

package/gm-plugkit/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-plugkit",
-  "version": "2.0.2030",
+  "version": "2.0.2032",
   "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": {

package/gm-plugkit/plugkit-slim.wasm.sha256

@@ -1 +1 @@
-99107509c628ff90adf99e131cb139fff6f1ef47b229d36504fb4ab6cac1bdfd  plugkit-slim.wasm
+b54c187a5fed4d0f867ddf329fad57f0ff2da6d72cef0805c29a1461e42b0700  plugkit-slim.wasm

package/gm-plugkit/plugkit.version

@@ -1 +1 @@
-0.1.939
+0.1.941

package/gm.json

@@ -1,6 +1,6 @@
 {
   "name": "gm",
-  "version": "2.0.2030",
+  "version": "2.0.2032",
   "description": "Spool-dispatch orchestration engine with unified state machine, skills, and automated git enforcement",
   "author": "AnEntrypoint",
   "license": "MIT",
@@ -17,5 +17,5 @@
   "publishConfig": {
     "access": "public"
   },
-  "plugkitVersion": "0.1.939"
+  "plugkitVersion": "0.1.941"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-skill",
-  "version": "2.0.2030",
+  "version": "2.0.2032",
   "description": "Canonical universal harness — AI-native software engineering via skill-driven orchestration; bootstraps plugkit for task execution and session isolation. Install in any AI coding agent host.",
   "author": "AnEntrypoint",
   "license": "MIT",

package/skills/gm/SKILL.md

@@ -114,7 +114,7 @@ VERIFY is adversarial, never confirmatory: run the real code path and read its a
 
 `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`.
 
-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.
+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.
 
 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."
 
@@ -124,4 +124,4 @@ Memory via `memorize-fire` dispatch stores in `.gm/rs-learn.db` and is retrieved
 
 Subagent prompts should reference the gm skill and task specifics only, without restating verb names, spool paths, or protocol mechanics already supplied by invocation.
 
-**This file is not gm's whole procedure.** The phase-specific behavioral prose (PLAN/EXECUTE/EMIT/VERIFY/CONSOLIDATE, gate reasons, deviation text) is served live by rs-plugkit's `instruction` verb from compiled Rust consts, per-project-overridable via `.gm/instructions/<key>.md` -- not authored in this file. A skill-improvement pass (e.g. workflow-forge) editing only this file's numbered steps misses that entire layer: changing PLAN/EXECUTE prose means editing `rs-plugkit/crates/plugkit-core/src/orchestrator/instructions/prose/*.md` directly (single-sourced there, `include_str!`'d at build) -> a push+CI+cascade rebuild, never a direct edit here. This file holds only: invocation syntax, transition markers, gate-condition summaries, spool-dispatch mechanics, and constraints -- the boot-edge ABI a skill-runner interacts with before the served prose takes over.
+**This file is not gm's whole procedure.** The phase-specific behavioral prose (PLAN/EXECUTE/EMIT/VERIFY/CONSOLIDATE, gate reasons, deviation text) is served live by rs-plugkit's `instruction` verb from compiled Rust consts -- not authored in this file. Resolution is three-tier, per key, each tier overriding the one before: (1) `.gm/instructions/<key>.md` local vendored override, always wins; (2) a configured source repo synced by the daemon into `.gm/instructions-source-cache/` when `.gm/instructions/source.json` ({repo, branch, path}) is present -- lets an org or project pull shared prose from any git repo without forking rs-plugkit; (3) the compiled-in default, the final fallback. A skill-improvement pass (e.g. workflow-forge) editing only this file's numbered steps misses that entire layer: changing the compiled default means editing `rs-plugkit/crates/plugkit-core/src/orchestrator/instructions/prose/*.md` directly (single-sourced there, `include_str!`'d at build) -> a push+CI+cascade rebuild, never a direct edit here. This file holds only: invocation syntax, transition markers, gate-condition summaries, spool-dispatch mechanics, and constraints -- the boot-edge ABI a skill-runner interacts with before the served prose takes over.