gm-skill 2.0.1931 → 2.0.1933

package/gm-plugkit/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-plugkit",
-  "version": "2.0.1931",
+  "version": "2.0.1933",
   "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-wasm-wrapper.js

@@ -4788,6 +4788,7 @@ async function runSpoolWatcher(instance, spoolDir) {
         phase,
         last_skill: lastSkill,
         prd_pending: prdPending,
+        prd_pending_count: prdPending,
         last_instruction_ts: lastInstructionTs,
         last_instruction_age_ms: lastInstructionAgeMs,
         long_gap_threshold_ms: 300000,

package/gm-plugkit/supervisor.js

@@ -6,12 +6,11 @@ const path = require('path');
 const os = require('os');
 const crypto = require('crypto');
 const { spawn, spawnSync } = require('child_process');
+const { gmToolsDir } = require('./bootstrap');
 
 function wrapperSha12OnDisk() {
   try {
-    const primary = path.join(os.homedir(), '.gm-tools', 'plugkit-wasm-wrapper.js');
-    const fallback = path.join(os.homedir(), '.claude', 'gm-tools', 'plugkit-wasm-wrapper.js');
-    const wp = fs.existsSync(primary) ? primary : fallback;
+    const wp = path.join(gmToolsDir(), 'plugkit-wasm-wrapper.js');
     return crypto.createHash('sha256').update(fs.readFileSync(wp)).digest('hex').slice(0, 12);
   } catch (_) { return null; }
 }
@@ -200,9 +199,7 @@ function spawnWatcher(bootReason) {
     return;
   }
 
-  const primaryWrapper = path.join(os.homedir(), '.gm-tools', 'plugkit-wasm-wrapper.js');
-  const fallbackWrapper = path.join(os.homedir(), '.claude', 'gm-tools', 'plugkit-wasm-wrapper.js');
-  const wrapper = fs.existsSync(primaryWrapper) ? primaryWrapper : fallbackWrapper;
+  const wrapper = path.join(gmToolsDir(), 'plugkit-wasm-wrapper.js');
   if (!fs.existsSync(wrapper)) {
     logEvent('supervisor.wrapper-missing', { wrapper, severity: 'critical' });
     writeSupervisorStatus('error', { error: 'wrapper-missing' });
@@ -379,10 +376,7 @@ function checkWatcherHealth() {
       severity: 'critical',
     });
     try {
-      const home = process.env.USERPROFILE || process.env.HOME || require('os').homedir();
-      const gmTools = fs.existsSync(path.join(home, '.gm-tools'))
-        ? path.join(home, '.gm-tools')
-        : path.join(home, '.claude', 'gm-tools');
+      const gmTools = gmToolsDir();
       for (const f of ['plugkit.wasm', 'plugkit.version', 'plugkit.wasm.sha256']) {
         try { fs.unlinkSync(path.join(gmTools, f)); } catch (_) {}
       }

package/gm.json

@@ -1,6 +1,6 @@
 {
   "name": "gm",
-  "version": "2.0.1931",
+  "version": "2.0.1933",
   "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.1931",
+  "version": "2.0.1933",
   "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

@@ -1,7 +1,7 @@
 ---
 name: gm
 description: The primary driver for any non-trivial coding, refactoring, debugging, or multi-step engineering task in a project using this harness -- use it first, for the whole task, not just a piece of it. Plugkit-served instruction stream. Three-layer admission (witness, single-writer, direction) over every possible mutation; effort unbounded, never gated on cost. Closure on first emit; partial = non-monotonic. Not for the post-completion remaining-work check (that is `gm-continue`) or for drift-recovery mid-task (that is `wfgy-method`) -- this skill is the work itself.
-allowed-tools: Skill, Read, Write, Bash(bun *), Bash(npx *), Bash(cat *), Bash(date *)
+allowed-tools: Skill, Read, Write, AskUserQuestion, Bash(bun *), Bash(npx *), Bash(cat *), Bash(date *)
 ---
 
 # gm
@@ -72,7 +72,7 @@ The `Resolving dependencies` / `Saved lockfile` chatter before the JSON payload
 
 **Waiting out a real `busy_until` window (a long `browser`/`exec_js` dispatch genuinely still running) is not the same thing as the banned bare-`sleep`-then-`ls` poll above -- the ban is on blind, unconditional sleeping when nothing indicates work is actually in flight; a live `busy_until` in the future is exactly the condition that licenses a bounded wait for it.** On a host with a background-monitor primitive (a tool that runs a shell condition and notifies on completion rather than blocking the turn), the correct shape is a condition loop over the OUT file's existence, not a fixed-duration sleep: `until [ -f .gm/exec-spool/out/<verb>-<N>.json ]; do sleep 2; done` handed to that primitive, so the wait happens off-turn and a completion notification (not a guessed delay) resumes work. On a host with no such primitive, a single bounded `sleep` no longer than the dispatch's own declared `busy_until` remaining-window (never an arbitrary guess, never chained/repeated past that one wait) is the fallback -- re-check `.status.json`'s `ts`/`busy_until` once after it elapses, do not loop blind sleeps. Either way: never poll faster than realistic verb latency (sub-second loops are themselves a form of the banned pattern), and never fall back to declaring the watcher dead just because a wait felt long -- dead is defined structurally (stale `ts` AND no future `busy_until`), not by elapsed wall-clock alone.
 
-**Reboot-loop escape (watcher dies ~30-90s after every boot).** If a fresh `bun x gm-plugkit@latest spool` boots but the watcher dies again shortly after (heartbeat `ts` goes stale >30s with no future `busy_until`, then a new pid appears, repeatedly), a plain re-boot cannot fix it -- the on-disk index has not finished embedding and each boot re-triggers the same synchronous code-index embed that blocks the heartbeat past the supervisor's 30s stale limit (`STATUS_STALE_MS`), so the supervisor kills the watcher mid-rebuild every time. Confirm by reading `.gm/exec-spool/.watcher.log` for repeated `codeinsight_rebuild` + `partial pass (wall budget) ... deferred_files=N` lines whose `deferred_files` never reaches 0. Two fixes, in order: (1) update the installed wrapper -- an installed `~/.gm-tools/plugkit-wasm-wrapper.js` older than the shipped one refreshes `busy_until` only once at boot instead of once per warmup pass, so the embed's later passes lapse the window; reinstall the current gm-plugkit build so the wrapper's warmup loop holds `busy_until` until `deferred_files==0`. (2) If reinstall is unavailable, let the index converge WITHOUT rebooting: after a boot, do NOT immediately re-boot on the first stale reading -- read `.watcher.log`, and as long as `deferred_files` is strictly decreasing across `codeinsight_index_partial` events the index is converging (each accepted verb advances it one wall-budget); give it repeated single verbs until a `code_index: done` / `deferred_files=0` line appears, then normal dispatch resumes. Rebooting mid-convergence resets this progress -- the loop is the reboot, not the embed. The proper durable fix is a host-project one (make `spool` overwrite a stale installed wrapper from the just-resolved bundled build); until that ships, drive real work via native tools and treat the spool as optional bookkeeping.
+**Reboot-loop escape (watcher dies ~30-90s after every boot).** If a fresh `bun x gm-plugkit@latest spool` boots but the watcher dies again shortly after (heartbeat `ts` goes stale >30s with no future `busy_until`, then a new pid appears, repeatedly), the on-disk index has not finished embedding and each boot re-triggers the same synchronous code-index embed that can block the heartbeat past the supervisor's 30s stale limit (`STATUS_STALE_MS`). Confirm by reading `.gm/exec-spool/.watcher.log` for repeated `codeinsight_rebuild` + `partial pass (wall budget) ... deferred_files=N` lines whose `deferred_files` never reaches 0. The durable fix has shipped: every `bun x gm-plugkit@latest spool` boot calls `ensureWrapperFresh()` (`gm-plugkit/bootstrap.js`), which sha256-compares the installed `~/.gm-tools/plugkit-wasm-wrapper.js` against the bundled one and atomically force-replaces it on any mismatch (lock-guarded, tmp-write-then-rename, safe under concurrent per-project watchers) -- a stale installed wrapper self-heals on the very next boot, no manual reinstall needed. If the loop persists even on a freshly-synced wrapper, the embed itself is still genuinely converging: do NOT immediately re-boot on the first stale reading -- read `.watcher.log`, and as long as `deferred_files` is strictly decreasing across `codeinsight_index_partial` events the index is converging (each accepted verb advances it one wall-budget); give it repeated single verbs until a `code_index: done` / `deferred_files=0` line appears, then normal dispatch resumes. Rebooting mid-convergence resets this progress -- the loop is the reboot, not the embed.
 
 **Apparent tooling failure is never grounds to ask the user, never a blind restart.** "Spooler not working" / missing response / stale watcher / `gm_plugkit_stale` flagged in a response = your own mechanical self-recovery: honor a future `busy_until` (wait), else boot + re-dispatch. You have boot authority; asking the user to do what a verb can do is a deviation. Staleness of any kind (stale watcher version, stale served prose vs published source) is itself a deviation to resolve immediately, the same turn it's noticed -- `bun x gm-plugkit@latest spool` first, before any other work.