gm-skill 2.0.2043 → 2.0.2045

package/AGENTS.md

@@ -97,6 +97,8 @@ Every skill's `allowed-tools:` reduced to `Skill, Read, Write` (plus SKILL.md bo
 
 A task that reduces to read/investigate/report, or a change confined to files the subagent owns for the turn, dispatches straight through -- stating the read-only boundary explicitly ("report only, no writes") is task-scope, not gm-protocol restatement, so it's not a violation of the rule above. A task whose plain description asks for an irreversible or shared-state-affecting action (delete data, force-push, merge/close a PR, deploy, rename a shared branch) is not silently handed off -- name the risk in the prompt and require the subagent to surface it back rather than execute it, the same blast-radius judgment the top-level agent applies to its own actions; the action still routes through the gm-driven skill invocation, never a prompt-authored imperative sequence that bypasses it. Contrast: "find every caller of X and summarize" dispatches as-is; "drop the staging table and reseed it" gets confirmed before any subagent is scoped to carry it out.
 
+**A subagent dispatched to build/commit/push in a submodule (`agentplug`, `rs-plugkit`, `rs-codeinsight`, `agentplug-bert`, `agentplug-libsql`, `agentplug-treesitter`, `rs-search`) closes the loop back to gm's own pin as its last step, every time, no exceptions.** These repos are checked out INSIDE this repo's own tree as git submodules -- a commit landed and pushed only to the submodule's standalone remote leaves gm's own tracked pointer silently pointing at the prior commit, invisible until the next explicit `git rev-parse HEAD` (submodule) vs `git rev-parse origin/main` comparison surfaces the drift. Live-hit twice in one session (two distinct commit pairs) before this rule existed -- each time required a manual `git checkout <sha> --detach` in the submodule dir + a `git_finalize` in gm to close. Every subagent prompt dispatching work into one of these submodules must include, as an explicit final step: after pushing the submodule's own commit, `cd` back to gm's root, `git add <submodule-path>`, and commit+push gm's own updated pointer in the SAME turn -- never leave that as an implicit "someone will notice." A top-level `gm` session that itself lands a submodule-touching commit (directly or via a subagent) checks `git status --porcelain` for the submodule path specifically before calling the turn done.
+
 ## Core Rules
 
 **Memory is human-readable md, tracked; derived stores are transient, never tracked.** Detail: the recall store (`recall: gm memory storage mechanics`, `recall: gm managed-gitignore mechanics`).

package/gm-plugkit/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-plugkit",
-  "version": "2.0.2043",
+  "version": "2.0.2045",
   "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.json

@@ -1,6 +1,6 @@
 {
   "name": "gm",
-  "version": "2.0.2043",
+  "version": "2.0.2045",
   "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.2043",
+  "version": "2.0.2045",
   "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

@@ -94,7 +94,9 @@ The `Resolving dependencies` / `Saved lockfile` chatter before the JSON payload
 
 If similar symptoms recur (stub-like responses, silent truncation, debug fields always empty), do NOT re-add a stale-bug workaround section here -- instead root-cause in the real browser-host source, which is now native in agentplug (clone `AnEntrypoint/agentplug`, edit `crates/agentplug-host/src/browser.rs` and its embedded `cdp_eval.js`, rebuild agentplug-runner, verify live against the locally-built `~/.gm-tools/agentplug-runner`, then commit+push to `AnEntrypoint/agentplug` main so the fix ships through the agentplug-bin release path) and update this section with the real fix, the same discipline used for the bugs above.
 
-**Windows-specific transient flakiness that is NOT a plugkit/wrapper bug, just retry it:** `bun x <pkg>@<version>` occasionally hangs indefinitely at "Resolving dependencies" with zero further output even with a pinned exact cached version (a known intermittent Bun/Windows dependency-resolution stall, reproducible with plain `bun x playwriter@<version> session list` outside any wrapper). A bare re-dispatch of the exact same body, or a fresh direct CLI retry, has resolved it every time observed. Do not chase this as a code bug -- 2-3 retries is the correct response, same bound as the raw-CLI fragility note below.
+**Windows-specific transient flakiness that is NOT a plugkit/wrapper bug, just retry it:** `bun x <pkg>@<version>` (any package, e.g. the gm-plugkit boot line itself) occasionally hangs indefinitely at "Resolving dependencies" with zero further output even with a pinned exact cached version -- a known intermittent Bun/Windows dependency-resolution stall, unrelated to browser automation. A bare re-dispatch of the exact same command has resolved it every time observed. Do not chase this as a code bug -- 2-3 retries is the correct response.
+
+**Never drive Chrome/browser automation directly (no raw headless Chrome launch, no playwright/playwriter CLI) -- the `browser` verb is the only sanctioned interface, for debugging or any other purpose.** This binds the calling agent, not just the browser-host implementation: reaching for `puppeteer`/`playwright`/a raw `chrome.exe --headless` invocation via `exec_js`/Bash instead of dispatching the `browser` verb is the same class of deviation as bypassing `codesearch` with raw `Grep`, or bypassing git verbs with raw `git` via Bash. The verb's own native implementation (`crates/agentplug-host/src/browser.rs`, see below) already drives Chrome directly over CDP with no playwriter dependency -- that is an implementation detail of the sanctioned path, not license to reach around it and drive Chrome/playwright by hand.
 
 **The browser verb drives Chrome directly over CDP, native in agentplug-host -- the playwriter relay is not on the eval path.** agentplug-runner launches Chrome with `--remote-debugging-port`, obtains a live DevTools `webSocketDebuggerUrl`, and runs the script in-page via `Runtime.evaluate` over that websocket directly (`crates/agentplug-host/src/browser.rs` + its embedded `cdp_eval.js`), so no relay attach+eval is ever spawned. This is the standing browser eval path. A flaky browser witness is therefore a real bug to root-cause in the CDP path or the Chrome launch, never a `blockedBy: external` tooling gap -- everything is fixable: if a browser dispatch fails, read the CDP endpoint (`http://127.0.0.1:<port>/json/version`), check the Chrome launch args, and fix the actual failure rather than parking it. There is no accepted "external tooling gap" resolution for the browser verb.