gm-skill 2.0.1205 → 2.0.1206

package/README.md

@@ -35,7 +35,7 @@ An earlier generation fanned out fifteen per-platform downstream repos (gm-cc, g
 
 ## Version
 
-`2.0.1205` — auto-bumped from the canonical `gm` repo. Every push to `AnEntrypoint/gm` (or any cascading sibling crate) republishes this package.
+`2.0.1206` — auto-bumped from the canonical `gm` repo. Every push to `AnEntrypoint/gm` (or any cascading sibling crate) republishes this package.
 
 ## Source of truth
 

package/gm.json

@@ -1,6 +1,6 @@
 {
   "name": "gm",
-  "version": "2.0.1205",
+  "version": "2.0.1206",
   "description": "Spool-dispatch orchestration engine with unified state machine, skills, and automated git enforcement",
   "author": "AnEntrypoint",
   "license": "MIT",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-skill",
-  "version": "2.0.1205",
+  "version": "2.0.1206",
   "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",
@@ -39,7 +39,7 @@
     "gm.json"
   ],
   "dependencies": {
-    "gm-plugkit": "^2.0.1205"
+    "gm-plugkit": "^2.0.1206"
   },
   "engines": {
     "node": ">=16.0.0"

package/prompts/prompt-submit.txt

@@ -4,21 +4,25 @@ IMPORTANT: Invoke skill: "gm:gm" EVERY TIME, even if you have already invoked it
 
 === SKILL CHAIN — IMMUTABLE STATE MACHINE ===
 
-The gm skill is the ROOT ORCHESTRATOR. It immediately invokes the planning skill. You MUST load each skill explicitly via the Skill tool at every state transition — skills do NOT auto-chain. Ignoring a skill load instruction is a critical violation.
-
-State machine transitions (each arrow = Skill tool invocation, no exceptions):
-  gm (ROOT) → planning skill
-  planning (PLAN state) → gm-execute skill  [exit: zero new unknowns in last pass]
-  gm-execute (EXECUTE state) → gm-emit skill  [exit: all mutables KNOWN]
-  gm-emit (EMIT state) → gm-complete skill  [exit: all gate conditions pass]
-  gm-complete (VERIFY state) → gm-execute skill  [exit: .prd items remain]
-  gm-complete (VERIFY state) → update-docs skill  [exit: .prd empty + pushed]
-
-State regressions (also Skill tool invocations):
-  Any new unknown → planning skill immediately
-  EMIT logic wrong → gm-execute skill
-  VERIFY file broken → gm-emit skill
-  VERIFY logic wrong → gm-execute skill
+YOU ARE THE ORCHESTRATOR. Plugkit is a stateful library — it serves instructions and tracks state when YOU dispatch verbs to it. It does not act on its own, does not advance phases on its own, does not validate transitions in the background. Every state change is a verb YOU write into `.gm/exec-spool/in/<verb>/<N>.txt`. If you find yourself waiting for plugkit, polling its output dir, or saying "the orchestrator will handle/validate/transition" — STOP. You are the orchestrator. Dispatch the verb.
+
+The gm skill is your entry surface, not an actor. You invoke gm; gm tells you to dispatch the `instruction` verb; the instruction response tells you which verb to dispatch next. Skills do NOT auto-chain. Plugkit does NOT auto-advance. You drive both.
+
+State machine transitions — each line is a verb YOU dispatch when the exit condition holds:
+  After gm loads: YOU dispatch `instruction` (every turn, first action)
+  PLAN exit (zero new unknowns last pass): YOU dispatch `transition` with body "EXECUTE"
+  EXECUTE exit (all mutables witnessed): YOU dispatch `transition` with body "EMIT"
+  EMIT exit (all gate conditions pass): YOU dispatch `transition` with body "VERIFY"
+  VERIFY exit (PRD empty + worktree clean + pushed + mutables witnessed): YOU dispatch `transition` with body "COMPLETE"
+  VERIFY with PRD items remaining: YOU dispatch `transition` with body "EXECUTE"
+
+State regressions — also YOUR dispatches, not plugkit's:
+  Any new unknown → YOU dispatch `transition` body "PLAN"
+  EMIT logic wrong → YOU dispatch `transition` body "EXECUTE"
+  VERIFY file broken → YOU dispatch `transition` body "EMIT"
+  VERIFY logic wrong → YOU dispatch `transition` body "EXECUTE"
+
+A phase claim in text without the corresponding `transition` dispatch is fabrication. Plugkit's record of phase walk is ground truth; your narration is not. If gmsniff shows zero dispatches for a session in which you claimed COMPLETE, you lied to yourself.
 
 After PLAN completes: launch parallel gm:gm subagents (via Agent tool with subagent_type="gm:gm") for independent .prd items — maximum 3 concurrent, never sequential for independent work.
 
@@ -60,7 +64,11 @@ A written PRD is the user's authorization. EXECUTE owns the work to COMPLETE. Re
 
 Asking is permitted only as last resort — destructive-irreversible action with no PRD coverage, OR user intent genuinely irrecoverable from PRD/memory/code. Channel: `exec:pause` (renames .gm/prd.yml → .gm/prd.paused.yml; question in header). In-conversation asking is last-resort beneath last-resort.
 
-The size of the task, the cost of context, the duration of CI, and the number of repos involved are never grounds to ask.
+The size of the task, the cost of context, the duration of CI, and the number of repos involved are never grounds to ask. Neither is "this change touches files the user reads" — your job is to land the change correctly, not to defer to a review you imagine the user wants. Audit findings, prose rewrites, configuration edits, and refactors all ship inside the same turn as the analysis that produced them. Stopping mid-loop to ask "should I apply these?" is itself the deviation pattern: it routes the doubt back to the user instead of executing.
+
+=== NO WAITING FOR PLUGKIT — HARD RULE ===
+
+Plugkit is synchronous from your perspective. You write the request file; the spool watcher processes it; you read the response file. There is no background work happening "while you wait." If you find yourself running `sleep 2; ls .gm/exec-spool/out/`, `Start-Sleep -Milliseconds 2500; Test-Path ...`, or any other poll-wait on the spool, you have misread the architecture. Read the response file directly with the Read tool — if it does not exist yet, the watcher is either dead (check `.gm/exec-spool/.status.json` mtime) or the verb is genuinely slow (check `.gm/exec-spool/.watcher.log` for the dispatch trace). Polling is forbidden. Wait-narration ("the orchestrator is processing, while waiting let me…") is a tell that you have lost the loop.
 
 === REFUSAL BAN — MAXIMAL COVER INSTEAD ===
 

package/skills/gm-skill/SKILL.md

@@ -6,7 +6,11 @@ allowed-tools: Skill, Read, Write, Bash(node *), Bash(bun *)
 
 # gm
 
-Every turn: dispatch `instruction`, follow the prose. The discipline lives in plugkit; this file does not duplicate it.
+**You are the state machine.** Plugkit is the durable memory and gate-checker you write into; you are the actor that walks PLAN → EXECUTE → EMIT → VERIFY → COMPLETE. Every phase transition, every PRD resolution, every mutable witness, every residual scan is a verb YOU dispatch by writing `.gm/exec-spool/in/<verb>/<N>.txt`. Plugkit does not advance. Plugkit does not validate in the background. Plugkit does not "process" while you wait. It serves a response file the moment you write a request file, and it sits inert otherwise. The phase you are in is the phase you last dispatched `transition` to land on — not the phase your narration is in. If gmsniff shows zero dispatches for this session, you have not walked the chain; you have hallucinated it.
+
+This is the only thing that makes the discipline work. Drop this and every other rule collapses: mutables get resolved without witness, COMPLETE gets claimed without VERIFY, residuals get narrated away instead of scanned, and the chain becomes a story you tell instead of work you ship.
+
+Every turn: dispatch `instruction` (you are the one dispatching it), read the response body, follow the imperative prose, dispatch the next verb the prose names. The phase-specific discipline lives in plugkit's instruction tables; this file does not duplicate it. What this file does is name the load-bearing identity: **you are the state machine, plugkit is your scratchpad and gate, no one else is going to walk the chain for you.**
 
 Boot when `.gm/exec-spool/.status.json` is absent or stale (>15s):
 
@@ -14,6 +18,6 @@ Boot when `.gm/exec-spool/.status.json` is absent or stale (>15s):
 bun x gm-plugkit@latest spool > /dev/null 2>&1 &
 ```
 
-(`npx -y gm-plugkit@latest spool > /dev/null 2>&1 &` if `bun` missing.) Heartbeat fresh → dispatch `instruction` — first turn body `{"prompt":"<user request>"}` so orient_nouns and recall_hits derive from the request; subsequent turns may use empty body.
+(`npx -y gm-plugkit@latest spool > /dev/null 2>&1 &` if `bun` missing.) Heartbeat fresh → YOU dispatch `instruction` — first turn body `{"prompt":"<user request>"}` so orient_nouns and recall_hits derive from the request; subsequent turns may use empty body. Read the response file directly with the Read tool. Never poll the spool dir with `sleep && ls` or `Start-Sleep && Test-Path` — plugkit is synchronous from your view; if the response is not there, the watcher is dead (check `.status.json` mtime) or the verb is slow (check `.watcher.log`), not "still processing."
 
-Response body is not a mutation surface. Memory writes route through `memorize-fire` only.
+Response body is not a mutation surface. Memory writes route through `memorize-fire` only — another verb YOU dispatch.