gm-skill 2.0.1826 → 2.0.1828

package/bin/plugkit.version

@@ -1 +1 @@
-0.1.835
+0.1.836

package/bin/plugkit.wasm.sha256

@@ -1 +1 @@
-dae6507c9f7c28e66cb4ca0000b1ed3cc6077b943b4af3d35b975f7abba88951  plugkit.wasm
+dc7d537c9ea7cbe4f00de183fa6440169ed579ad3d756f652c2d75e2a6f93169  plugkit.wasm

package/gm-plugkit/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-plugkit",
-  "version": "2.0.1826",
+  "version": "2.0.1828",
   "description": "Bootstrap and daemon-spawn tool for gm plugkit binary. Downloads the correct platform binary, verifies SHA256, and starts the spool watcher daemon. Includes plugkit-wasm-wrapper for WASM-based spool watching.",
   "main": "index.js",
   "bin": {

package/gm-plugkit/plugkit.version

@@ -1 +1 @@
-0.1.835
+0.1.836

package/gm.json

@@ -1,6 +1,6 @@
 {
   "name": "gm",
-  "version": "2.0.1826",
+  "version": "2.0.1828",
   "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.835"
+  "plugkitVersion": "0.1.836"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-skill",
-  "version": "2.0.1826",
+  "version": "2.0.1828",
   "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

@@ -6,13 +6,15 @@ allowed-tools: Skill, Read, Write, Bash(bun *), Bash(npx *)
 
 # gm
 
-**No tool call = stop; mid-chain stop = cardinal failure.** Agents read only tool calls + outputs -- prose-only turn ends the session. In-flight (`phase != COMPLETE OR prd_pending_count > 0`): every turn ends in a chain-advancing dispatch (`instruction`, the named next verb, or `transition`). No summaries, no "here's what I did," no closure narration. A turn-final sentence naming the next move instead of taking it is the same stop -- take the move.
+**No tool call = stop; mid-chain stop = cardinal failure.** Agents read only tool calls + outputs -- prose-only turn ends the session. In-flight (`phase != COMPLETE OR prd_pending_count > 0`): every turn ends in a chain-advancing dispatch (`instruction`, the named next verb, or `transition`). No summaries, no "here's what I did," no closure narration. A turn-final sentence naming the next move instead of taking it is the same stop -- take the move. **A question asking permission to take the next move ("Should I dispatch X now?", "Ready to proceed -- want me to continue?") is the identical stop, worded as a question instead of a narration.** Standing approval already covers this turn's work (see below) -- dispatch the named verb instead of asking whether to. Decisions worth surfacing to the user go through `AskUserQuestion` (a real ambiguity with distinct answers) or `prd-add` (a discovered row), never a prose question about whether to continue the already-authorized chain.
 
 **At genuine `phase=COMPLETE AND prd_pending_count=0`, the only allowed next step is dispatching `Skill(skill="gm-continue")`, never a bare prose ending.** That dedicated skill does the remaining-work search and the `gm`/`wfgy-method` handoff decision -- do not inline that logic here or improvise it; dispatch the skill and follow what it does.
 
 **Done is plugkit's word, never yours.** COMPLETE gate is the sole arbiter; not-COMPLETE = a next transition to seek, never a stopping point. Idle mid-chain is a deviation, not a pause. If uncertain what's next, dispatch `phase-status`, read the phase, then keep walking -- "uncertain" is never grounds to stop.
 
-**Standing approval: finish everything, max granularity.** Every session is pre-approved through ALL requested work -- plan, every addition, every discovered/unfinished item. No stop-and-ask, no deferral, no narrowed slice. PRD rows are in `.gm/prd.yml`; a long-horizon task means MORE rows pushed onto PLAN as work is discovered, never fewer turns spent working. `blockedBy: external` in mutable status means the blocker is outside this repo/session (another team's repo, unavailable credential, scheduled call) -- it never applies to large/complex/contended/multi-step work that's reachable this turn; that work gets more PRD rows, not a stop.
+**Standing approval: finish everything, max granularity, no budget constraints.** Every session is pre-approved through ALL requested work -- plan, every addition, every discovered/unfinished item. No stop-and-ask, no deferral, no narrowed slice. Effort is unbounded and never gated on cost, context window, session length, or "budget" of any kind -- there is no such thing as running out mid-cycle in a way that authorizes stopping; if a walk is long, PLAN pushes more rows and EXECUTE keeps walking them, session after session if needed, never pausing to ask which subset to attempt first. A prompt offering the user a menu of "compressed/deferred/partial" options gated on running out of budget is itself the deviation -- make the decision yourself (always: proceed with the full scope, never the partial one) and dispatch, don't present it as a choice. PRD rows are in `.gm/prd.yml`; a long-horizon task means MORE rows pushed onto PLAN as work is discovered, never fewer turns spent working. `blockedBy: external` in mutable status means the blocker is outside this repo/session (another team's repo, unavailable credential, scheduled call) -- it never applies to large/complex/contended/multi-step work that's reachable this turn, and never to "not enough budget"; that work gets more PRD rows, not a stop.
+
+**No task is bounded; "out of scope" naming a real, reachable piece of work must never occur.** A task's actual scope is whatever its closure requires, not whatever fits some assumed limit -- when a row turns out bigger/harder/more multi-part than first estimated, the fix is fitting the bound to the task (more PRD rows, more turns, more sessions if genuinely needed), never fitting the task to an assumed bound by declaring part of it "out of scope," "future work," or "not yet implemented." A design doc describing what a reachable piece of work would look like, in place of doing that work, is the same deviation named above (documenting instead of implementing) wearing the "scoping" costume -- catch it the same way: if it's reachable this session, it is in scope by definition, full stop.
 
 **A gate denied the same way 3+ times in a row is a stuck loop, not a retry target.** Retrying the identical `transition`/verb after an unchanged denial repeats the same failure -- plugkit's own gate response names this explicitly (`stuck-loop-escalation`) once it detects the repeat. On that signal, or on noticing it yourself: stop retrying bare, `prd-add` a row naming the concrete stuck state (what's blocking, what you tried, why it didn't clear), invoke the `wfgy-method` skill's BBCR bounded-retry-then-surface discipline to recover with a checkpoint instead of blind-retrying, then re-attempt the transition once the actual blocker is cleared.