gm-skill 2.0.1521 → 2.0.1523

package/AGENTS.md

@@ -28,13 +28,13 @@ This repo IS the published `gm-skill` npm package. The repo root is the package
 
 The plugkit stack runs as a wasm cdylib loaded by `plugkit-wasm-wrapper.js` under Node/bun. No native binaries are built, downloaded, or published. The shipped `plugkit.wasm` (~149MB, embeds bge-small-en-v1.5 for offline in-wasm embeddings) is fetched at bootstrap from `plugkit-wasm` npm / `plugkit-bin` gh-releases, sha256-pinned, not bundled in `gm-skill`. Full size/embedding mechanics in rs-learn (`recall: WASM-only plugkit size mechanics`).
 
-**Every wasm host-import `extern "C"` block carries `#[link(wasm_import_module = "env")]`.** The host provides every possible host fn (host_kv_get/put/query, host_vec_search, host_git, host_log, host_now_ms, host_fs_*, host_env_get, host_exec_js, host_random_fill, …) under the `env` import module (`plugkit-wasm-wrapper.js` `importObject.env`). A bare `extern "C"` block links only because lenient linkers tolerate the unresolved module; the strict Linux release `rust-lld` in CI errors `undefined symbol: host_*` and Build-WASM fails. This holds in rs-plugkit AND every dep crate linked into the cdylib (rs-learn) AND any sibling that builds wasm (rs-exec, rs-search). The trap: `cargo check` and even `cargo build --release` on a non-Linux host both pass while CI fails — the linker differs by host, so the only reproduction is a Linux release link; the CI job log is admin-gated, so Build-WASM echoes `::error::` annotations to surface the lld error publicly. Add a host import anywhere and the block carries the attribute or the cascade goes dark. Full incident in rs-learn (`recall: cascade outage wasm import module link`).
+**Every wasm host-import `extern "C"` block carries `#[link(wasm_import_module = "env")]`.** The host provides every possible host fn (host_kv_get/put/query, host_vec_search, host_git, host_log, host_now_ms, host_fs_*, host_env_get, host_exec_js, host_random_fill, ...) under the `env` import module (`plugkit-wasm-wrapper.js` `importObject.env`). A bare `extern "C"` block links only because lenient linkers tolerate the unresolved module; the strict Linux release `rust-lld` in CI errors `undefined symbol: host_*` and Build-WASM fails. This holds in rs-plugkit AND every dep crate linked into the cdylib (rs-learn) AND any sibling that builds wasm (rs-exec, rs-search). The trap: `cargo check` and even `cargo build --release` on a non-Linux host both pass while CI fails -- the linker differs by host, so the only reproduction is a Linux release link; the CI job log is admin-gated, so Build-WASM echoes `::error::` annotations to surface the lld error publicly. Add a host import anywhere and the block carries the attribute or the cascade goes dark. Full incident in rs-learn (`recall: cascade outage wasm import module link`).
 
-**`plugkit-wasm-wrapper.js` is ESM; never use inline `require()` for a node builtin — import it at module scope.** The wrapper runs under both node and bun, and the supervisor's `resolveRuntime()` prefers bun. Under bun's ESM, `require` is not a global, so an inline `const x = require('crypto'|'net'|'http'|'https'|'child_process')` throws `require is not defined` — and because those calls sit in `catch(_){}` blocks, the failure is silent: it broke `_ownWrapperSha12` (status.wrapper_sha stayed null, leaving the supervisor wrapper-sha-drift recycle inert), `_wrapperShaAtBoot` and its self-drift-restart, the synthetic-session cwd-hash, and the file-index sha — all only under the bun watcher, which is why it hid for so long (node-run watchers have `require` via CJS interop). Every node builtin is imported once at the top (`import crypto from 'crypto'`, etc.); inline `require` of a builtin is forbidden. Full incident in rs-learn (`recall: wrapper require not defined under bun`).
+**`plugkit-wasm-wrapper.js` is ESM; never use inline `require()` for a node builtin -- import it at module scope.** The wrapper runs under both node and bun, and the supervisor's `resolveRuntime()` prefers bun. Under bun's ESM, `require` is not a global, so an inline `const x = require('crypto'|'net'|'http'|'https'|'child_process')` throws `require is not defined` -- and because those calls sit in `catch(_){}` blocks, the failure is silent: it broke `_ownWrapperSha12` (status.wrapper_sha stayed null, leaving the supervisor wrapper-sha-drift recycle inert), `_wrapperShaAtBoot` and its self-drift-restart, the synthetic-session cwd-hash, and the file-index sha -- all only under the bun watcher, which is why it hid for so long (node-run watchers have `require` via CJS interop). Every node builtin is imported once at the top (`import crypto from 'crypto'`, etc.); inline `require` of a builtin is forbidden. Full incident in rs-learn (`recall: wrapper require not defined under bun`).
 
-**Every single-instance / lock guard is atomic, never check-then-act.** A guard that does `existsSync` -> read -> decide -> `writeFileSync` is TOCTOU: under a concurrent burst (the bootstrap spawns several supervisors in the same millisecond per skill-load) every caller passes the check before any writes, so all proceed and the duplicate it was meant to prevent happens anyway. The supervisor single-instance guard, the `.watcher.lock`, and any future pid/lock file all acquire via an atomic primitive — `fs.openSync(path, 'wx')` (O_EXCL exclusive-create, succeeds for exactly one racer) or atomic-rename — then on `EEXIST` read the holder and refuse-if-alive / take-over-if-stale. The trap: a check-then-write guard passes sequential testing (a later boot sees the prior holder) and silently fails only under concurrency, so when a guard is in place and the duplicate STILL occurs, suspect non-atomicity before suspecting absence. Full incident (three mis-diagnoses) in rs-learn (`recall: supervisor churn TOCTOU atomic guard`).
+**Every single-instance / lock guard is atomic, never check-then-act.** A guard that does `existsSync` -> read -> decide -> `writeFileSync` is TOCTOU: under a concurrent burst (the bootstrap spawns several supervisors in the same millisecond per skill-load) every caller passes the check before any writes, so all proceed and the duplicate it was meant to prevent happens anyway. The supervisor single-instance guard, the `.watcher.lock`, and any future pid/lock file all acquire via an atomic primitive -- `fs.openSync(path, 'wx')` (O_EXCL exclusive-create, succeeds for exactly one racer) or atomic-rename -- then on `EEXIST` read the holder and refuse-if-alive / take-over-if-stale. The trap: a check-then-write guard passes sequential testing (a later boot sees the prior holder) and silently fails only under concurrency, so when a guard is in place and the duplicate STILL occurs, suspect non-atomicity before suspecting absence. Full incident (three mis-diagnoses) in rs-learn (`recall: supervisor churn TOCTOU atomic guard`).
 
-**Count plugkit processes by executable Name, never by command-line substring.** A `Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -like '*plugkit-wasm-wrapper*' }` (or `-match 'plugkit-supervisor'`) also matches the bash/powershell command running the query itself — its eval string contains those literals — so it fabricates phantom processes and inflates the count (it reported `8 watchers + 4 supervisors` when the truth was `4 watchers, 0 supervisors`). Always constrain to the real runtime: `Where-Object { ($_.Name -eq 'node.exe' -or $_.Name -eq 'bun.exe') -and $_.CommandLine -match 'plugkit-wasm-wrapper\.js' }`. The phantom count made a working atomic-guard fix look unconverged across two fires; a wrong measurement is as costly as a wrong diagnosis. Full incident in rs-learn (`recall: supervisor churn TOCTOU atomic guard`).
+**Count plugkit processes by executable Name, never by command-line substring.** A `Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -like '*plugkit-wasm-wrapper*' }` (or `-match 'plugkit-supervisor'`) also matches the bash/powershell command running the query itself -- its eval string contains those literals -- so it fabricates phantom processes and inflates the count (it reported `8 watchers + 4 supervisors` when the truth was `4 watchers, 0 supervisors`). Always constrain to the real runtime: `Where-Object { ($_.Name -eq 'node.exe' -or $_.Name -eq 'bun.exe') -and $_.CommandLine -match 'plugkit-wasm-wrapper\.js' }`. The phantom count made a working atomic-guard fix look unconverged across two fires; a wrong measurement is as costly as a wrong diagnosis. Full incident in rs-learn (`recall: supervisor churn TOCTOU atomic guard`).
 
 ## Spool dispatch ABI
 
@@ -44,7 +44,7 @@ Agents dispatch verbs by writing to `.gm/exec-spool/in/<verb>/<N>.txt` (request
 
 **Wasm-direct verbs**: fs/kv/exec/fetch/env, recall, codesearch, memorize(+prune), health, filter, and the full git verb family. Complete enumeration in rs-learn (`recall: wasm-direct plugkit verbs full list`).
 
-**memorize-prune verb**: deletes bad/superseded memories — pruning bad memory matters more than preserving good memory (a wrong recall hit is worse than a miss). Explicit `{key}`/`{keys:[...]}` deletes; `{query}` returns review-only candidates the agent judges before re-dispatching the stale keys — never a blind similarity-delete (that is itself a bad-memory generator). Full two-mode spec in rs-learn (`recall: memorize-prune verb two-mode spec`).
+**memorize-prune verb**: deletes bad/superseded memories -- pruning bad memory matters more than preserving good memory (a wrong recall hit is worse than a miss). Explicit `{key}`/`{keys:[...]}` deletes; `{query}` returns review-only candidates the agent judges before re-dispatching the stale keys -- never a blind similarity-delete (that is itself a bad-memory generator). Full two-mode spec in rs-learn (`recall: memorize-prune verb two-mode spec`).
 
 **git verbs**: git is a first-class spool surface, never a shell command; `git_finalize {message}` is the bundled COMPLETE-phase push surface and `git_push` is the only admissible raw push (porcelain-gated, rebase-retry). A git-dominant `bash`/`powershell` body is gated (`deviation.bash-git-bypass`). Full per-verb shapes, host_git `.exe` resolution, and the gate detail live in rs-learn (`recall: git verbs rs-plugkit spool surface`).
 
@@ -58,7 +58,7 @@ Only record non-obvious technical caveats that cost multiple runs to discover. R
 
 **Detail-heavy caveats live in rs-learn (`.gm/rs-learn.db`), not here.** Per-crate runtime quirks, Windows process-spawn mechanics, hook implementation details, ocw/site/workflow specifics, and similar fact-base material are exfiltrated to rs-learn and reachable via `exec:recall`. AGENTS.md keeps only top-level rules that govern gm-the-repo. When in doubt: gm-the-repo architecture or cross-cutting policy stays here; single-crate or single-platform mechanism goes to rs-learn.
 
-**Every memorize run also drains AGENTS.md — migration is bidirectional, deflation is the back-pressure.** AGENTS.md grows monotonically if facts only flow in; left unchecked it bloats past the context budget it protects. So every session that dispatches `memorize-fire` for new facts ALSO picks a few existing AGENTS.md entries that have become detail-heavy / single-crate / single-platform (the material this policy says belongs in rs-learn) and exfiltrates them: `memorize-fire` the entry's substance to the default namespace, then delete or compress its AGENTS.md paragraph to a one-line pointer in the same commit. Witnessed by both the store gaining the fact (recallable next turn) and the AGENTS.md byte-count dropping. A few entries per run, never a wholesale rewrite; top-level cross-cutting rules stay, everything reachable by `recall` drains. Skipping the drain on a memorize run is the slow-bloat drift this policy exists to prevent.
+**Every memorize run also drains AGENTS.md -- migration is bidirectional, deflation is the back-pressure.** AGENTS.md grows monotonically if facts only flow in; left unchecked it bloats past the context budget it protects. So every session that dispatches `memorize-fire` for new facts ALSO picks a few existing AGENTS.md entries that have become detail-heavy / single-crate / single-platform (the material this policy says belongs in rs-learn) and exfiltrates them: `memorize-fire` the entry's substance to the default namespace, then delete or compress its AGENTS.md paragraph to a one-line pointer in the same commit. Witnessed by both the store gaining the fact (recallable next turn) and the AGENTS.md byte-count dropping. A few entries per run, never a wholesale rewrite; top-level cross-cutting rules stay, everything reachable by `recall` drains. Skipping the drain on a memorize run is the slow-bloat drift this policy exists to prevent.
 
 ## Coding Style
 
@@ -68,7 +68,7 @@ Only record non-obvious technical caveats that cost multiple runs to discover. R
 
 **Skill SKILL.md files:** Strip explanatory prose. Keep ONLY invocation syntax, transition markers (`->`), gate conditions, constraint lists, and code examples showing exact usage.
 
-**Implicit, not explicit, in skill prose.** Skill files (and prompt-submit.txt) elicit behavior, they do not describe it. Write terse imperative principles whose phrasing triggers the model's already-learned dispositions, not numbered procedures that spell out what to do. Forbidden: "1. agent runs N parallel calls 2. then writes 3. then…", "see paper IV §2.3", "as documented in docs/skills.html", citations to the site or papers, multi-step recipes. The skill is a prompt, not a manual; if it reads like a manual the behavior gets imitated as a script and breaks at the first edge case. The papers and site are *outputs* of the discipline, not *inputs* to it; never link from a skill into the docs. Cross-cutting rules that need a citation belong in this file (AGENTS.md), not in skills.
+**Implicit, not explicit, in skill prose.** Skill files (and prompt-submit.txt) elicit behavior, they do not describe it. Write terse imperative principles whose phrasing triggers the model's already-learned dispositions, not numbered procedures that spell out what to do. Forbidden: "1. agent runs N parallel calls 2. then writes 3. then...", "see paper IV section 2.3", "as documented in docs/skills.html", citations to the site or papers, multi-step recipes. The skill is a prompt, not a manual; if it reads like a manual the behavior gets imitated as a script and breaks at the first edge case. The papers and site are *outputs* of the discipline, not *inputs* to it; never link from a skill into the docs. Cross-cutting rules that need a citation belong in this file (AGENTS.md), not in skills.
 
 ## Build
 
@@ -80,7 +80,7 @@ There is no build step. The repo root is the published artifact. `npm publish` f
 
 **The agent orchestrates.** Plugkit is the stateful library the agent drives by dispatching verbs. Plugkit does not act autonomously, does not advance phases in the background, does not validate transitions while the agent waits. Every possible state change is a verb the agent writes into `.gm/exec-spool/in/<verb>/<N>.txt`. If a session shows zero dispatches but the agent narrated a full PLAN->COMPLETE walk, the agent fabricated the walk, plugkit's dispatch ledger is ground truth.
 
-The PLAN -> EXECUTE -> EMIT -> VERIFY -> COMPLETE state machine lives natively in rs-plugkit; plugkit owns phase/mutables/memorize/transition-legality *as data + gate checks*, but the agent triggers every operation by dispatching an orchestrator verb — the harness never reimplements the state machine and never expects plugkit to act without a verb. Plugkit is synchronous from the agent's view; polling the output dir instead of reading the response file is the canonical misuse. File paths + verb enumeration in rs-learn (`recall: rs-plugkit state-machine internals`).
+The PLAN -> EXECUTE -> EMIT -> VERIFY -> COMPLETE state machine lives natively in rs-plugkit; plugkit owns phase/mutables/memorize/transition-legality *as data + gate checks*, but the agent triggers every operation by dispatching an orchestrator verb -- the harness never reimplements the state machine and never expects plugkit to act without a verb. Plugkit is synchronous from the agent's view; polling the output dir instead of reading the response file is the canonical misuse. File paths + verb enumeration in rs-learn (`recall: rs-plugkit state-machine internals`).
 
 ## gm-skill is the canonical universal harness
 
@@ -106,15 +106,15 @@ Every possible skill's `allowed-tools:` frontmatter is reduced to `Skill, Read,
 
 **"Every possible" is the load-bearing test, applied to every noun the request names**: PLAN-phase PRD construction is exhaustive, not minimal. The phrase "every possible" is how the agent thickens the cover, every possible task, every possible validation, every possible mutable, every possible corner case, every possible caveat, every possible failure mode, every possible interaction, every possible empty/overflow/reentry state, every possible degenerate input, each application of the phrase produces PRD rows. A non-trivial request that yields a single-digit PRD has not finished enumerating; the closure is still in the agent's head, not in plugkit's store, and the chain will converge on a thin slice that leaves silent residuals. After the first PRD pass, the existing list becomes input to a second transform, for each row, the agent asks what every possible corner case looks like, and writes those as additional rows. The expansion is closed when applying "every possible" to the current list yields nothing new, not when the agent feels done. Validations, edge cases, and anticipated mutables are first-class PRD rows, never implicit. Long-horizon requests routinely produce PRDs in the high tens or hundreds; the row count is the resolution of the cover, and resolution is what the user asked for when they handed over a long-horizon prompt. Sparse PRDs under-specify the closure and orphan the work; dense PRDs make completion observable.
 
-**Every possible aspect that can be checked for jank is a PRD row; the architecture is pliable**: at PLAN, for every surface the user's prompt concerns, the agent adds to the PRD a complete enumeration of every possible aspect that can be checked for `jank` — every immaturity, every unfinished edge, every half-wired path — across gui, ux, ui, client state, server state, the client/server state boundary, and any other surface the request reaches. `jank` is the load-bearing word: the agent hunts the rough/unpolished/almost-done, not only outright bugs. Each aspect to improve or validate is its own row, including a profiling row and a security row per surface. The sweep is scoped to the prompt's concern and its reachable closure, not an unbounded repo audit, but exhaustive within it. Every issue found along the way opens its own debug-and-repair plan spooled to the PRD the same turn, never inline-and-forgotten; every outstanding quick improvement is spooled too. The architecture is `pliable`: every possible architectural change that clearly improves it or reduces code-maintenance burden is a spooled PRD plan; replacing bespoke code with native functionality or a very-popular well-maintained library is encouraged ONLY when it reduces the codebase (net-smaller maintained surface) — a heavy dependency added to delete a few lines net-grows maintenance and is the guarded failure mode. Fan-out is the spool-native shape (parallel `prd-add`/`codesearch`/`exec_js` in one block, plugkit task-spawn), never the platform's native Task/Explore subagent. If any tell-tale AI design element is found along the way (boilerplate flourish, over-hedged comment, generic scaffold name, machine-authored shape), one sighting spawns a full-sweep plan that scans every possible part of the codebase for every other tell-tale AI design element and fixes them across the board — spooled to the PRD as its own rows (scan, per-cluster findings, fix-and-verify), exhaustive over every possible file, never a one-off local fix, because a tell-tale left standing anywhere is the tell the whole was machine-shaped.
+**Every possible aspect that can be checked for jank is a PRD row; the architecture is pliable**: at PLAN, for every surface the user's prompt concerns, the agent adds to the PRD a complete enumeration of every possible aspect that can be checked for `jank` -- every immaturity, every unfinished edge, every half-wired path -- across gui, ux, ui, client state, server state, the client/server state boundary, and any other surface the request reaches. `jank` is the load-bearing word: the agent hunts the rough/unpolished/almost-done, not only outright bugs. Each aspect to improve or validate is its own row, including a profiling row and a security row per surface. The sweep is scoped to the prompt's concern and its reachable closure, not an unbounded repo audit, but exhaustive within it. Every issue found along the way opens its own debug-and-repair plan spooled to the PRD the same turn, never inline-and-forgotten; every outstanding quick improvement is spooled too. The architecture is `pliable`: every possible architectural change that clearly improves it or reduces code-maintenance burden is a spooled PRD plan; replacing bespoke code with native functionality or a very-popular well-maintained library is encouraged ONLY when it reduces the codebase (net-smaller maintained surface) -- a heavy dependency added to delete a few lines net-grows maintenance and is the guarded failure mode. Fan-out is the spool-native shape (parallel `prd-add`/`codesearch`/`exec_js` in one block, plugkit task-spawn), never the platform's native Task/Explore subagent. If any tell-tale AI design element is found along the way (boilerplate flourish, over-hedged comment, generic scaffold name, machine-authored shape), one sighting spawns a full-sweep plan that scans every possible part of the codebase for every other tell-tale AI design element and fixes them across the board -- spooled to the PRD as its own rows (scan, per-cluster findings, fix-and-verify), exhaustive over every possible file, never a one-off local fix, because a tell-tale left standing anywhere is the tell the whole was machine-shaped.
 
 **Client-side debugging exposes globals and evaluates in-browser, never blind-restarts**: to debug client-side code the agent surfaces the relevant state as a `window.*` global and reads it live via the `browser` verb's `page.evaluate`, running experiments in the browser, rather than blind experimentation + continuous server restarts. A global + one `page.evaluate` reads actual runtime state in a single dispatch where a restart-and-eyeball loop burns a turn and observes nothing. The live page is the debugger; the same `browser` surface that witnesses an edit (Browser Witness) also diagnoses it.
 
-**Mundane user-facing output is suppressed or stripped to the bone**: every possible mundane line of user-facing text is suppressed or cut to the bone — drop articles, drop preamble, drop the play-by-play; boot-probe narration, dispatch echoes, restating prose just read, status recaps do not ship. What survives is substantive: a real finding, a decision and its one-line reason, a blocker, the single-line PRD-read declaration. Terse means fewer/shorter words, NEVER zero tool calls and NEVER silent work — the turn still ends in the chain-advancing tool call and the agent still states in one terse clause what it is about to do. Cut the mundane, never the chain.
+**Mundane user-facing output is suppressed or stripped to the bone**: every possible mundane line of user-facing text is suppressed or cut to the bone -- drop articles, drop preamble, drop the play-by-play; boot-probe narration, dispatch echoes, restating prose just read, status recaps do not ship. What survives is substantive: a real finding, a decision and its one-line reason, a blocker, the single-line PRD-read declaration. Terse means fewer/shorter words, NEVER zero tool calls and NEVER silent work -- the turn still ends in the chain-advancing tool call and the agent still states in one terse clause what it is about to do. Cut the mundane, never the chain.
 
 **Noticing is a planning event, at every phase, in every dispatch window**: any observation the agent makes during the chain, anything that should be done, anything outstanding, anything unfinished, anything improvable, anything misaligned with user preferences, anything the work itself surfaces about what *else* the work touches, is a `prd-add` the agent dispatches this turn. Observations carried in the response body without conversion to a PRD row evaporate when the turn ends; only the PRD store survives. The default response to noticing is to convert. The discovery surface keeps producing new in-scope items as the chain walks PLAN->EXECUTE->EMIT->VERIFY, every phase has its own noticing-to-PRD pressure. Skipping the conversion ("I'll mention it in the summary" / "future work" / "note for later") is the canonical drift mechanism: the observation does not persist, the future turn does not arrive, the residual goes silent. Density grows along the walk, not just at PLAN-time; a chain that exits PLAN with N rows and reaches COMPLETE with N rows has either had no real discoveries (unlikely on a non-trivial task) or has lost them. When the discovery is structural rather than concrete, "the project would benefit from X", "this surface has no test coverage", "the docs do not mention Y", "the agent's preference for Z is being violated here", it is still a PRD row, written with the witness that motivated it. Preference-aware noticing applies the same conversion: when the agent observes that current state diverges from user-stated preferences (dense PRDs, residual-triage, no name-and-defer, every-possible expansion, browser-witness coverage, push-on-clean), each divergence is a `prd-add` describing what the aligned state looks like.
 
-**A turn without a tool call is a stop; summary is a stop; both are forbidden until plugkit pronounces COMPLETE**: every programming agent, regardless of vendor, reads only tool calls and their outputs, so an assistant message that ends in prose with no tool call IS the turn ending and the session halts there. This is the mechanical root of the "agent did one small piece and stopped" failure: the model wrote a wrap-up paragraph, emitted no tool call, and the harness read that as done. Deferred intent is the same stop facing forward — a turn-final sentence naming the next move ("let me read X", "I'll re-dispatch instruction") instead of making it; the chain strands where the prose pointed (one real run halted at EXECUTE with 22 open rows on an announced-but-unmade read). The rule is absolute and tool-agnostic: while the chain is in-flight (phase != COMPLETE OR prd_pending_count > 0) the agent NEVER ends a turn in prose — every turn terminates in a tool call that advances the chain (`instruction`, the next named verb, `transition`, `phase-status`). Take the move you were about to describe; surface a decision through `AskUserQuestion` or `prd-add`, never a prose-only "confirming direction." The only event that authorizes a prose-only turn is plugkit returning `phase=COMPLETE` AND `prd_pending_count=0`; the agent's own sense that "the work feels done" authorizes nothing. Before any apparent stop or any summary, the agent dispatches `phase-status` and rechecks, a non-terminal phase means the urge to stop was drift, and the recovery is to dispatch `instruction` and continue. This depends on nothing but the verb spool, so it holds on every agent with no hook and no tool-specific feature; any continuation mechanism that relies on a hook or a single tool's behavior is non-portable and must be replaced by this spool-only discipline.
+**A turn without a tool call is a stop; summary is a stop; both are forbidden until plugkit pronounces COMPLETE**: every programming agent, regardless of vendor, reads only tool calls and their outputs, so an assistant message that ends in prose with no tool call IS the turn ending and the session halts there. This is the mechanical root of the "agent did one small piece and stopped" failure: the model wrote a wrap-up paragraph, emitted no tool call, and the harness read that as done. Deferred intent is the same stop facing forward -- a turn-final sentence naming the next move ("let me read X", "I'll re-dispatch instruction") instead of making it; the chain strands where the prose pointed (one real run halted at EXECUTE with 22 open rows on an announced-but-unmade read). The rule is absolute and tool-agnostic: while the chain is in-flight (phase != COMPLETE OR prd_pending_count > 0) the agent NEVER ends a turn in prose -- every turn terminates in a tool call that advances the chain (`instruction`, the next named verb, `transition`, `phase-status`). Take the move you were about to describe; surface a decision through `AskUserQuestion` or `prd-add`, never a prose-only "confirming direction." The only event that authorizes a prose-only turn is plugkit returning `phase=COMPLETE` AND `prd_pending_count=0`; the agent's own sense that "the work feels done" authorizes nothing. Before any apparent stop or any summary, the agent dispatches `phase-status` and rechecks, a non-terminal phase means the urge to stop was drift, and the recovery is to dispatch `instruction` and continue. This depends on nothing but the verb spool, so it holds on every agent with no hook and no tool-specific feature; any continuation mechanism that relies on a hook or a single tool's behavior is non-portable and must be replaced by this spool-only discipline.
 
 **Always seek the next state transition**: if the chain is not COMPLETE, there is a next move. Idle mid-chain is a deviation. The agent who finishes a verb and stops without dispatching the next instruction has stopped walking the chain. `phase-status` tells you where you are; `instruction` tells you what's next. There is no "I'll wait for the user" mid-chain, the user authorized closure at request time, not phase-by-phase.
 
@@ -128,7 +128,7 @@ Every possible skill's `allowed-tools:` frontmatter is reduced to `Skill, Read,
 
 **Behavioral discipline lives in plugkit's `instruction` verb**: Three-Layer Admission Filter (L1 cost, L2 bounds, L3 direction), maturity-first emit, response-not-mutation-surface, structural recognition of closure anti-shapes, code invariants (state-space minimization, hardware-reality, flat-structure, vertical-slice, async-boundary, naming-by-scale, fail-fast, binary-transport, single-focus). Dispatch `instruction` for the live prose; do not duplicate it here.
 
-**The agent IS the LLM rs-learn calls; every judgment rs-learn needs is the agent deciding on the spot**: rs-learn never reaches out to a model for a quality score, a relevance call, a prune decision, a route outcome, or a loss signal. plugkit IS the harness and the agent IS the model it dispatched, so each of those is a decision the agent makes inline, from its knowledge of the current situation, and reports back through the spool. The MicroLoRA adapter trains from a trajectory-quality the agent self-reports (`learn{feedback, embedding, payload:{quality}}`, a rank-2 learned scoring head that reads a bge-small embedding and emits a per-target logit `B·(A·embedding)`, sona-style — it scores targets from embeddings, it does not reshape the vector; consuming its score in recall re-ranking is the open integration. Distinct from the FastGRNN model-selection router, which takes `learn{record_outcome, target:<model id>, quality}`); bad-memory pruning is the agent judging a recall hit stale and dispatching `memorize-prune{key}`; the deep core takes the agent's `record_loss`; the attention takes `nudge_relation`. None of these wait on a signal the host must expose, because the agent already holds it. Encourage heavy `recall` and `learn` use so the on-the-spot judgments are grounded in prior context, not guessed — every mutable resolution is already a memorization run, and the same recall-first reflex should inform every quality/prune/optimization call. The instruction prose names where each self-report fires (VERIFY closes the training loop); the principle here is the load-bearing one: there is no separate judge model, the agent is it, and it decides now.
+**The agent IS the LLM rs-learn calls; every judgment rs-learn needs is the agent deciding on the spot**: rs-learn never reaches out to a model for a quality score, a relevance call, a prune decision, a route outcome, or a loss signal. plugkit IS the harness and the agent IS the model it dispatched, so each of those is a decision the agent makes inline, from its knowledge of the current situation, and reports back through the spool. The MicroLoRA adapter trains from a trajectory-quality the agent self-reports (`learn{feedback, embedding, payload:{quality}}`, a rank-2 learned scoring head that reads a bge-small embedding and emits a per-target logit `B - (A - embedding)`, sona-style -- it scores targets from embeddings, it does not reshape the vector; consuming its score in recall re-ranking is the open integration. Distinct from the FastGRNN model-selection router, which takes `learn{record_outcome, target:<model id>, quality}`); bad-memory pruning is the agent judging a recall hit stale and dispatching `memorize-prune{key}`; the deep core takes the agent's `record_loss`; the attention takes `nudge_relation`. None of these wait on a signal the host must expose, because the agent already holds it. Encourage heavy `recall` and `learn` use so the on-the-spot judgments are grounded in prior context, not guessed -- every mutable resolution is already a memorization run, and the same recall-first reflex should inform every quality/prune/optimization call. The instruction prose names where each self-report fires (VERIFY closes the training loop); the principle here is the load-bearing one: there is no separate judge model, the agent is it, and it decides now.
 
 **host_exec_js is synchronous**: pass a real per-call `timeoutMs` (zero/missing is a hard error); long subprocesses block the watcher; no async/background exec under wasm. Mechanism detail in rs-learn (`recall: host_exec_js synchronous`).
 
@@ -172,11 +172,11 @@ Orchestration state is tracked via marker files in `.gm/` instead of hook events
 
 **gm-skill tool-use sequencing**: Invoking `Skill(skill="gm-skill")` writes `.gm/gm-fired-<sessionId>` to clear the needs-gm gate. The marker is cleared at turn start to reset the gate. There is one shipped skill; no subagent variant exists.
 
-**The skill is the driver, not a post-hoc witness**: when a request carries the standing instruction to use gm-skill (every `/loop` fire, any prompt naming `/gm-skill`), the FIRST working action of the session is `Skill(skill="gm-skill")`, and the skill prose then drives the chain from PLAN through COMPLETE. Dispatching the spool verbs (`instruction`, `transition`, `prd-add`, `prd-resolve`, `memorize-fire`, `residual-scan`, `phase-status`) directly without first entering the skill executes the work outside the skill the user asked to drive it, the spool verbs are the skill's mechanism, not a substitute for invoking it. Entering the skill only at the end to confirm terminal state does NOT satisfy the instruction: the condition is that the skill drives the planned work from inception, not that it witnesses retroactive completion. The boot probe (`cat .gm/exec-spool/.status.json` …) is still prescribed by the skill itself and may precede the invocation; everything that mutates state or advances the chain happens inside the skill-driven session.
+**The skill is the driver, not a post-hoc witness**: when a request carries the standing instruction to use gm-skill (every `/loop` fire, any prompt naming `/gm-skill`), the FIRST working action of the session is `Skill(skill="gm-skill")`, and the skill prose then drives the chain from PLAN through COMPLETE. Dispatching the spool verbs (`instruction`, `transition`, `prd-add`, `prd-resolve`, `memorize-fire`, `residual-scan`, `phase-status`) directly without first entering the skill executes the work outside the skill the user asked to drive it, the spool verbs are the skill's mechanism, not a substitute for invoking it. Entering the skill only at the end to confirm terminal state does NOT satisfy the instruction: the condition is that the skill drives the planned work from inception, not that it witnesses retroactive completion. The boot probe (`cat .gm/exec-spool/.status.json` ...) is still prescribed by the skill itself and may precede the invocation; everything that mutates state or advances the chain happens inside the skill-driven session.
 
 **Dead-watcher recovery uses `bun x gm-plugkit@latest spool`, never direct-node boot** (mechanism + wrapper-deploy verification in rs-learn: `recall: dead-watcher recovery bun x not direct-node`).
 
-**The first verb after a genuine multi-minute IDLE is `instruction`, to reset the long-gap clock** (mechanism in rs-learn: `recall: first verb after multi-minute wait instruction long-gap`). The gate fires on genuine idle only — both >300s since the last instruction AND >300s since the previous dispatch of any verb — so active back-to-back work verbs (a browser-heavy debugging stretch, a fan-out of exec/codesearch) keep the chain alive without an interleaved `instruction`; you do not inject defensive instruction dispatches between active work. A true wait (version download, overnight, long external CI watch with no dispatches) still trips it, and there the first verb back is `instruction`.
+**The first verb after a genuine multi-minute IDLE is `instruction`, to reset the long-gap clock** (mechanism in rs-learn: `recall: first verb after multi-minute wait instruction long-gap`). The gate fires on genuine idle only -- both >300s since the last instruction AND >300s since the previous dispatch of any verb -- so active back-to-back work verbs (a browser-heavy debugging stretch, a fan-out of exec/codesearch) keep the chain alive without an interleaved `instruction`; you do not inject defensive instruction dispatches between active work. A true wait (version download, overnight, long external CI watch with no dispatches) still trips it, and there the first verb back is `instruction`.
 
 **A stop-hook firing on a terminal chain does not authorize re-polling**: when a stop-hook or unsatisfiable condition fires while the chain is already at `phase=COMPLETE` AND `prd_pending_count=0`, re-dispatching `instruction` or `phase-status` to "re-confirm" terminality is itself a deviation, it emits `deviation.complete-chain-poll` (`instructions/mod.rs`) and marks the agent as polling a closed chain. COMPLETE already authorizes the prose-only turn; the hook cannot be satisfied by more poll dispatches over elapsed work, and re-running already-committed work to manufacture skill-driven activity is the fabrication `Nothing Fake` forbids. Two admissible responses only: (a) a prose-only turn (the COMPLETE pronouncement is in hand), or (b) genuinely new planned work opened with a FRESH `{"prompt":...}` body, which resets phase to PLAN and is driven through the skill from inception. Repeatedly answering the same already-acknowledged hook is a loop; state the terminal facts once and stop, or open new work.
 

package/README.md

@@ -2,11 +2,13 @@
 
 > **more coushin' for the puhin'**
 
-gm is a skill that convinces your coding agent it already is a deterministic state machine, PLAN -> EXECUTE -> EMIT -> VERIFY -> COMPLETE, and then enforces that conviction with a wasm-backed orchestrator, witnessed execution, and a covering family of bounded subsets that refuses to let "follow-up" become a synonym for "I gave up."
+**glootius maximus** (gm) exists to raise one number: the signal-to-noise ratio (SNR) of a coding agent. every failure an agent commits, narrating an unverified guess, forgetting a decision, shipping a placeholder, stopping early, is noise injected into the channel between what you asked and what gets built. gm is a skill that convinces your coding agent it already is a deterministic state machine, PLAN -> EXECUTE -> EMIT -> VERIFY -> COMPLETE, and then enforces that conviction with a wasm-backed orchestrator, witnessed execution, and a covering family of bounded subsets that refuses to let "follow-up" become a synonym for "I gave up." every rule in it is one more noise source removed.
+
+that orientation is also why gm is built for token austerity: every token an agent spends should be signal toward the work, never narration, hedging, or busy-output. austerity is SNR enforced at the budget.
 
 it is named after **glootius maximus**, the muscle that holds you in the chair while you finish the work. the name is the joke and the discipline at once: the agent that sits down through PLAN -> EXECUTE -> EMIT -> VERIFY -> COMPLETE actually ships. the agent that stands up early ships a stub with a green check on it.
 
-built over ~200 commits of daily use. free, open source, maintained by one person.
+built over 14000+ hours of supervised modification, across ~200 commits of daily use, every one of those hours spent tuning the same target: more agentic signal, less noise. free, open source, maintained by one person.
 
 disclaimer: this is extremely opinionated. it will block bash, redirect your tools, refuse to write test files, force you to push git before ending a session, and reject any execute call without an explicit timeout. if that sounds terrible, this is not for you. if that sounds like what you wish your agent did automatically, keep sitting down.
 
@@ -32,18 +34,18 @@ This repo IS the published `gm-skill` npm package. No build step, no factory. Th
 
 ```
 gm/
-├── skills/gm-skill/   <- the skill (SKILL.md + index.js, ~12 lines of prose)
-├── bin/               <- bootstrap + plugkit launcher (gmsniff / ccsniff are separate npm packages, `bun x gmsniff`, `bun x ccsniff`)
-├── lib/               <- runtime: spool dispatch, skill bootstrap, daemon mgmt
-├── agents/            <- subagent prompts (gm, memorize, research-worker, textprocessing)
-├── prompts/           <- bash-deny, session-start, prompt-submit, pre-compact
-├── lang/              <- language packs (browser, ssh)
-├── gm-plugkit/        <- separate npm package that ships the wasm-wrapper
-├── gm.json            <- version + plugkit pin
-├── package.json       <- npm publish manifest
-├── AGENTS.md          <- architectural rules (present-tense, no history)
-├── CHANGELOG.md       <- release history
-└── site/              <- flatspace site source (built to dist/ by CI)
+|-- skills/gm-skill/   <- the skill (SKILL.md + index.js, ~12 lines of prose)
+|-- bin/               <- bootstrap + plugkit launcher (gmsniff / ccsniff are separate npm packages, `bun x gmsniff`, `bun x ccsniff`)
+|-- lib/               <- runtime: spool dispatch, skill bootstrap, daemon mgmt
+|-- agents/            <- subagent prompts (gm, memorize, research-worker, textprocessing)
+|-- prompts/           <- bash-deny, session-start, prompt-submit, pre-compact
+|-- lang/              <- language packs (browser, ssh)
+|-- gm-plugkit/        <- separate npm package that ships the wasm-wrapper
+|-- gm.json            <- version + plugkit pin
+|-- package.json       <- npm publish manifest
+|-- AGENTS.md          <- architectural rules (present-tense, no history)
+|-- CHANGELOG.md       <- release history
+`-- site/              <- flatspace site source (built to dist/ by CI)
 ```
 
 The two npm packages this repo publishes:
@@ -61,7 +63,7 @@ PLAN -> EXECUTE -> EMIT -> VERIFY -> COMPLETE. Every transition is a verb the ag
 
 Every tool the agent uses is a dispatch verb. No direct shell, no direct file writes outside the spool. The wasm host owns the side effects.
 
-- **`recall`**: vector + KV recall against `rs-learn`, scored by cosine × recency, namespace-aware
+- **`recall`**: vector + KV recall against `rs-learn`, scored by cosine x recency, namespace-aware
 - **`codesearch`**: semantic vector search across the project
 - **`memorize`**: write to the recall index (with the BGE query/passage prefix asymmetry)
 - **`browser`**: managed Chrome session with project-scoped profile at `.gm/browser-profile/`

package/agents/gm.md

@@ -3,7 +3,7 @@ description: Agent (not skill) - immutable programming state machine. Always inv
 mode: primary
 ---
 
-# GM — Skill-First Orchestrator
+# GM -- Skill-First Orchestrator
 
 **Invoke the `planning` skill immediately.** Use the Skill tool with `skill: "planning"`.
 
@@ -11,12 +11,12 @@ mode: primary
 
 All work coordination, planning, execution, and verification happens through the skill tree:
 - `planning` skill -> `gm-execute` skill -> `gm-emit` skill -> `gm-complete` skill -> `update-docs` skill
-- `memorize` sub-agent — background only, non-sequential. Invocation: `Agent(subagent_type='memorize', model='haiku', run_in_background=true, prompt='## CONTEXT TO MEMORIZE\n<what was learned>')`
+- `memorize` sub-agent -- background only, non-sequential. Invocation: `Agent(subagent_type='memorize', model='haiku', run_in_background=true, prompt='## CONTEXT TO MEMORIZE\n<what was learned>')`
 
-All code execution uses `exec:<lang>` via the Bash tool — never direct `Bash(node ...)` or `Bash(npm ...)`.
+All code execution uses `exec:<lang>` via the Bash tool -- never direct `Bash(node ...)` or `Bash(npm ...)`.
 
 To send stdin to a running background task: `exec:type` with task_id on line 1 and input on line 2.
 
 Do not use `EnterPlanMode`. Do not run code directly via Bash. Invoke `planning` skill first.
 
-Responses to the user must be two sentences maximum, only when the user needs to know something, and in plain conversational language — no file paths, filenames, symbols, or technical identifiers.
+Responses to the user must be two sentences maximum, only when the user needs to know something, and in plain conversational language -- no file paths, filenames, symbols, or technical identifiers.

package/agents/memorize.md

@@ -3,7 +3,7 @@ name: memorize
 description: Background memory agent. Classifies context and writes to AGENTS.md + rs-learn. No memory dir, no MEMORY.md.
 ---
 
-# Memorize — Background Memory Agent
+# Memorize -- Background Memory Agent
 
 Writes facts to two places only: **AGENTS.md** (non-obvious technical caveats) and **rs-learn** (all classified facts via fast ingest).
 
@@ -12,15 +12,15 @@ Resolve at start of every run:
 - **Project root** = `process.cwd()` when invoked. `AGENTS.md` is `<project root>/AGENTS.md`.
 - **Reach check** = run `gh api repos/<owner>/<repo> --jq .permissions.push` on `<project root>`'s `git remote get-url origin`. Cache the answer for the run. If the result is anything other than literal `true` (false, no remote, non-github URL, gh CLI missing, gh not authed, repo private and inaccessible), the project is **out-of-reach**.
 
-## STEP 0: SCOPE GUARD — DO NOT POLLUTE OUT-OF-REACH PROJECTS
+## STEP 0: SCOPE GUARD -- DO NOT POLLUTE OUT-OF-REACH PROJECTS
 
 If the reach check returns out-of-reach:
 
-- **Do** ingest classified facts into rs-learn (Step 2) — rs-learn is per-user, not per-project, so private notes about a project the user is reading-but-not-owning are safe there.
+- **Do** ingest classified facts into rs-learn (Step 2) -- rs-learn is per-user, not per-project, so private notes about a project the user is reading-but-not-owning are safe there.
 - **Do not** read or edit `<project root>/AGENTS.md` (Step 3). Skip the file entirely.
 - **Do not** run the AGENTS.md <-> rs-learn migration audit (Step 4). The audit edits AGENTS.md.
 
-Reason: agents running in a cwd that points at a third-party repo (e.g. running Claude inside a checkout of `nousresearch/hermes-agent` while building a downstream port) must not write project-specific notes into the upstream project's AGENTS.md. That AGENTS.md belongs to the upstream maintainers. Personal porting notes belong in the user's downstream repo's AGENTS.md, or — when the work spans multiple repos and there's no clean home — in rs-learn only.
+Reason: agents running in a cwd that points at a third-party repo (e.g. running Claude inside a checkout of `nousresearch/hermes-agent` while building a downstream port) must not write project-specific notes into the upstream project's AGENTS.md. That AGENTS.md belongs to the upstream maintainers. Personal porting notes belong in the user's downstream repo's AGENTS.md, or -- when the work spans multiple repos and there's no clean home -- in rs-learn only.
 
 When the reach check returns **in-reach**, proceed normally with all four steps below.
 
@@ -29,7 +29,7 @@ When the reach check returns **in-reach**, proceed normally with all four steps
 Examine the ## CONTEXT TO MEMORIZE section at the end of this prompt. For each fact, classify as:
 
 - user: user role, goals, preferences, knowledge
-- feedback: guidance on approach — corrections AND confirmations
+- feedback: guidance on approach -- corrections AND confirmations
 - project: ongoing work, goals, bugs, incidents, decisions
 - reference: pointers to external systems, URLs, paths
 
@@ -40,17 +40,17 @@ Discard:
 
 ## STEP 2: INGEST INTO RS-LEARN
 
-For each classified fact, invoke `exec:memorize` (HTTP-preferred, subprocess fallback — fast either way):
+For each classified fact, invoke `exec:memorize` (HTTP-preferred, subprocess fallback -- fast either way):
 
 ```
 exec:memorize
 <type>/<slug>
-<fact body — one to three self-contained sentences>
+<fact body -- one to three self-contained sentences>
 ```
 
 Line 1 of the body is the source tag (e.g. `feedback/terse-responses`, `project/merge-freeze`). Lines 2+ are the fact itself. Use kebab-case slugs.
 
-A discipline sigil — `@<name>` as the first space-token in the invoking prompt, or a trailing `discipline=<name>` line — routes the write to that discipline's store. Without one, the write lands in the default store. Forward the sigil verbatim to `exec:memorize`; never invent or default a discipline name.
+A discipline sigil -- `@<name>` as the first space-token in the invoking prompt, or a trailing `discipline=<name>` line -- routes the write to that discipline's store. Without one, the write lands in the default store. Forward the sigil verbatim to `exec:memorize`; never invent or default a discipline name.
 
 To invalidate previously-memorized content (correction or retraction):
 
@@ -85,16 +85,16 @@ Never add: obvious patterns, active task progress, redundant restatements.
 
 ## STEP 4: AGENTS.md -> RS-LEARN MIGRATION (BENCHMARK + DRAIN)
 
-AGENTS.md is the **always-on context buffer** — every prompt sees it. rs-learn is the **conditional retrieval store** — only relevant facts surface. The migration loop turns AGENTS.md into a benchmark for rs-learn's recall quality:
+AGENTS.md is the **always-on context buffer** -- every prompt sees it. rs-learn is the **conditional retrieval store** -- only relevant facts surface. The migration loop turns AGENTS.md into a benchmark for rs-learn's recall quality:
 
-1. Pick **5 random items** from AGENTS.md (sections, paragraphs, or numbered points). Don't pick the most recent additions — pick the oldest stable items.
+1. Pick **5 random items** from AGENTS.md (sections, paragraphs, or numbered points). Don't pick the most recent additions -- pick the oldest stable items.
 2. For each item, derive a 2-6 word query that a future agent would naturally use to find this fact.
 3. Run `exec:recall` with that query.
 4. Decide:
    - **Recall accurate AND complete** -> the rs-learn store has internalized this fact; **remove it from AGENTS.md**. Frees buffer space and confirms learning.
    - **Recall partial / outdated / missing** -> keep the AGENTS.md item AND ingest a refined version of the fact via `exec:memorize` so next round it can pass. Note the outcome in your run log.
-5. Report the audit cycle in the run output (items checked, removed, refined). Do not write the audit result to AGENTS.md — it is changelog-shaped and AGENTS.md forbids dated audit sections.
+5. Report the audit cycle in the run output (items checked, removed, refined). Do not write the audit result to AGENTS.md -- it is changelog-shaped and AGENTS.md forbids dated audit sections.
 
 Why: AGENTS.md grows monotonically without this loop. rs-learn already filters by relevance per-prompt, so duplicating stable facts in AGENTS.md just inflates the always-on context. The migration drains AGENTS.md into the retrieval store as the store proves it can recall. Failed migrations leave the fact in AGENTS.md (safe default) and improve the store. Success rate over time = a metric for how well gm is learning this project.
 
-Don't migrate if the fact is genuinely about agent meta-behavior that must be active every prompt (e.g. "always invoke gm:gm first") — those stay permanently.
+Don't migrate if the fact is genuinely about agent meta-behavior that must be active every prompt (e.g. "always invoke gm:gm first") -- those stay permanently.

package/agents/research-worker.md

@@ -9,15 +9,15 @@ allowed-tools: WebFetch, WebSearch, Bash
 
 One question. One context. One file on disk. One-line return.
 
-Two shapes of brief arrive: a live-web question owning a path under `.gm/research/<slug>/<worker-id>.md`, or a corpus chunk owning `.gm/disciplines/<name>/corpus/concise/<chunk-id>.md`. The corpus shape carries an input chunk on disk and a fact-preservation contract — every claim, number, name, caveat, and citation from the source survives the rewrite; prose density rises, content does not shrink. No fetching unless the brief asks for it. The output file looks like the live-web one but the `Sources` section points at the input chunk path and any inline citations the chunk already carried.
+Two shapes of brief arrive: a live-web question owning a path under `.gm/research/<slug>/<worker-id>.md`, or a corpus chunk owning `.gm/disciplines/<name>/corpus/concise/<chunk-id>.md`. The corpus shape carries an input chunk on disk and a fact-preservation contract -- every claim, number, name, caveat, and citation from the source survives the rewrite; prose density rises, content does not shrink. No fetching unless the brief asks for it. The output file looks like the live-web one but the `Sources` section points at the input chunk path and any inline citations the chunk already carried.
 
 ## Brief shape
 
-The spawning prompt names: the question, the answer shape expected, the explicit out-of-scope boundary, and the destination path `.gm/research/<slug>/<worker-id>.md`. If any of those is missing or ambiguous, treat that as the first finding — record what was unclear and stop, rather than guessing scope.
+The spawning prompt names: the question, the answer shape expected, the explicit out-of-scope boundary, and the destination path `.gm/research/<slug>/<worker-id>.md`. If any of those is missing or ambiguous, treat that as the first finding -- record what was unclear and stop, rather than guessing scope.
 
 ## Investigation
 
-Open with a `WebSearch` broad enough to map sources, narrow enough to exclude obviously off-topic results. Pick the two or three highest-quality hits — primary docs, dated authored posts, RFCs, source repos — and `WebFetch` each. Aggregator pages, content farms, and undated listicles are last resort, flagged as such when used.
+Open with a `WebSearch` broad enough to map sources, narrow enough to exclude obviously off-topic results. Pick the two or three highest-quality hits -- primary docs, dated authored posts, RFCs, source repos -- and `WebFetch` each. Aggregator pages, content farms, and undated listicles are last resort, flagged as such when used.
 
 Stop fetching when the question is answered to the shape requested. Extra fetches past sufficiency burn tokens the orchestrator needs for synthesis.
 
@@ -29,7 +29,7 @@ A claim without an inline source URL is a defect; remove it before writing the f
 
 ## Return
 
-Return only: the absolute path to the findings file, and a single sentence summarising the headline answer. Never return the full findings inline — the orchestrator reads from disk.
+Return only: the absolute path to the findings file, and a single sentence summarising the headline answer. Never return the full findings inline -- the orchestrator reads from disk.
 
 ## Boundary
 

package/agents/textprocessing.md

@@ -4,7 +4,7 @@ description: Haiku-backed text processor. Takes a body of text and an instructio
 agent: true
 ---
 
-# Textprocessing — Haiku Language Processor
+# Textprocessing -- Haiku Language Processor
 
 The single surface for intelligent text transforms. Code does mechanics (count, split, regex, sort, dedup-by-equality); this agent does meaning (summary, classify, extract, rewrite, translate, semantic dedup, score, label).
 
@@ -14,7 +14,7 @@ The single surface for intelligent text transforms. Code does mechanics (count,
 Agent(subagent_type='gm:textprocessing', model='haiku', prompt='## INPUT\n<body>\n\n## INSTRUCTION\n<task>')
 ```
 
-`prompt` always carries both halves — input under `## INPUT`, instruction under `## INSTRUCTION`. The agent reads both, performs the transform, returns the result as plain text or JSON per what the instruction asked for. No preamble, no commentary, no "here is your output" wrapper.
+`prompt` always carries both halves -- input under `## INPUT`, instruction under `## INSTRUCTION`. The agent reads both, performs the transform, returns the result as plain text or JSON per what the instruction asked for. No preamble, no commentary, no "here is your output" wrapper.
 
 ## OUTPUT CONTRACT
 
@@ -41,7 +41,7 @@ A loop in code that "checks if this string contains certain meaning" via keyword
 
 ## CONSTRAINTS
 
-- Model is fixed at `haiku` — fast, cheap, sufficient for transform tasks. Escalate to opus only when the agent's haiku output fails an acceptance check, never preemptively.
-- No tools beyond Read/Write — the agent processes text it receives, optionally reads/writes chunks for multi-pass jobs. Never spawns subagents.
+- Model is fixed at `haiku` -- fast, cheap, sufficient for transform tasks. Escalate to opus only when the agent's haiku output fails an acceptance check, never preemptively.
+- No tools beyond Read/Write -- the agent processes text it receives, optionally reads/writes chunks for multi-pass jobs. Never spawns subagents.
 - Background-spawnable: `run_in_background=true` for fire-and-forget batch processing where the caller polls results later.
 - Idempotent: same input + same instruction -> same output (modulo haiku sampling noise). Callers needing deterministic output specify `temperature=0` in the prompt.

package/bin/bootstrap.js

@@ -216,7 +216,7 @@ function gmToolsDir() {
 // ~/.gm-tools (or ~/.claude/gm-tools for legacy installs) so hooks.json can
 // invoke plugkit directly without going through node. Self-update inside the
 // Rust binary keeps gm-tools fresh from
-// here on. Skipped silently on any error — the next session-start hook will
+// here on. Skipped silently on any error -- the next session-start hook will
 // retry via ensure_tools_current.
 
 function copyWasmToGmTools(wasmPath, wrapperDir, version) {
@@ -469,7 +469,7 @@ async function bootstrap(opts) {
         clearBootstrapError();
         return wasmFinalPath;
       }
-      log(`decision: fetch reason: cache-hit-sha-mismatch (dir=v${version} expected ${wasmExpectedSha.slice(0,12)}… got ${(actualSha||'').slice(0,12)}…)`);
+      log(`decision: fetch reason: cache-hit-sha-mismatch (dir=v${version} expected ${wasmExpectedSha.slice(0,12)}... got ${(actualSha||'').slice(0,12)}...)`);
       writeBootstrapError({
         expected_version: version,
         cached_version: null,
@@ -544,7 +544,7 @@ async function bootstrap(opts) {
       }
       log('sha256 verified');
     } else {
-      log('no sha256 manifest — skipping verify');
+      log('no sha256 manifest -- skipping verify');
     }
 
     try { fs.renameSync(wasmPartialPath, wasmFinalPath); }

package/gm-plugkit/bootstrap.js

@@ -567,7 +567,7 @@ async function bootstrap(opts) {
       }
       log('sha256 verified');
     } else {
-      log('no sha256 manifest — skipping verify');
+      log('no sha256 manifest -- skipping verify');
     }
 
     try { fs.renameSync(partialPath, finalPath); }
@@ -808,7 +808,7 @@ async function ensureReady(opts) {
           instruction: `gm-plugkit running ${selfStale.own} but npm has ${selfStale.latest}. The npx/bun cache served a stale copy. Clear the cache so the next invocation picks up the latest wrapper fixes: bun pm cache rm; or  npx clear-npx-cache; or rm -rf ~/.npm/_npx ~/AppData/Local/npm-cache/_npx`,
         };
         try { fs.writeFileSync(path.join(spoolDir, '.gm-plugkit-stale.json'), JSON.stringify(marker, null, 2)); } catch (_) {}
-        log(`gm-plugkit self-stale: running ${selfStale.own}, latest npm ${selfStale.latest} — cache served old code (marker at .gm/exec-spool/.gm-plugkit-stale.json)`);
+        log(`gm-plugkit self-stale: running ${selfStale.own}, latest npm ${selfStale.latest} -- cache served old code (marker at .gm/exec-spool/.gm-plugkit-stale.json)`);
       } else if (selfStale && selfStale.own) {
         try {
           const projectDir = process.env.CLAUDE_PROJECT_DIR || process.cwd();
@@ -914,7 +914,7 @@ function startSpoolDaemon() {
   try {
     const wrapper = path.join(gmToolsDir(), 'plugkit-wasm-wrapper.js');
     if (!fs.existsSync(wrapper)) {
-      return { ok: false, error: `wrapper not at ${wrapper} — ensureReady() must run first` };
+      return { ok: false, error: `wrapper not at ${wrapper} -- ensureReady() must run first` };
     }
     const runtime = resolveNodeRuntime();
     const projectDir = process.env.CLAUDE_PROJECT_DIR || process.cwd();

package/gm-plugkit/cli.js

@@ -7,7 +7,7 @@ const path = require('path');
 const cp = require('child_process');
 const { ensureReady, startSpoolDaemon } = require('./bootstrap');
 
-const usage = `gm-plugkit — Bootstrap and daemon-spawn for gm plugkit binary.
+const usage = `gm-plugkit -- Bootstrap and daemon-spawn for gm plugkit binary.
 
 Usage:
   bun x gm-plugkit@latest                    Bootstrap + start spool daemon

package/gm-plugkit/package.json

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

@@ -297,7 +297,7 @@ function capHitText(hits, maxLen, maxCount) {
   if (!Array.isArray(hits)) return hits;
   return hits.slice(0, maxCount).map((h) => {
     if (!h || typeof h !== 'object' || typeof h.text !== 'string' || h.text.length <= maxLen) return h;
-    return { ...h, text: h.text.slice(0, maxLen) + '…[+' + (h.text.length - maxLen) + 'ch]' };
+    return { ...h, text: h.text.slice(0, maxLen) + '...[+' + (h.text.length - maxLen) + 'ch]' };
   });
 }
 
@@ -346,7 +346,7 @@ function turnTick(sess, verb, taskBase, phase, prdPending) {
   const key = sess || '(no-session)';
   const now = Date.now();
   let t = _turns.get(key);
-  // Any verb arriving after an idle gap closes the stale turn — not just instruction.
+  // Any verb arriving after an idle gap closes the stale turn -- not just instruction.
   // Otherwise a non-instruction verb (prd-add, mutable-resolve, transition) landing
   // after an overnight sleep stamps t.lastTs forward without splitting, and dur_ms
   // (lastTs - startTs) balloons to wall-clock-with-sleep instead of active work time.
@@ -367,7 +367,7 @@ function turnTick(sess, verb, taskBase, phase, prdPending) {
   }
   t.lastTs = now;
   t.dispatches++;
-  // A verb arriving resumes the turn — clear any prior stall flag so a later re-stall
+  // A verb arriving resumes the turn -- clear any prior stall flag so a later re-stall
   // is a fresh episode, not silently suppressed by the one-shot guard.
   t.stallEmitted = false;
   t.verbs.set(verb, (t.verbs.get(verb) || 0) + 1);
@@ -376,7 +376,7 @@ function turnTick(sess, verb, taskBase, phase, prdPending) {
 }
 
 // turn.end fires only when a NEW verb arrives after idle, so a turn that simply never
-// receives another verb stays open forever and emits no signal — a permanent stall is
+// receives another verb stays open forever and emits no signal -- a permanent stall is
 // silence, not an event, which is how a mid-EXECUTE stop stays invisible for days. The
 // heartbeat scan closes that hole: for each open turn idle past STALL_MS whose last phase
 // is non-terminal (or carries open PRD rows), emit turn.stalled once. One-shot per episode
@@ -386,7 +386,7 @@ const STALL_MS = 300_000;
 function scanStalledTurns() {
   const now = Date.now();
   // A long synchronous verb (codesearch index rebuild, chromium spawn) stamps busy_until and
-  // blocks the spool — the agent is legitimately waiting, not stalled. Honor it exactly as
+  // blocks the spool -- the agent is legitimately waiting, not stalled. Honor it exactly as
   // supervisor.js checkWatcherHealth does, so a busy watcher never emits a false mid-chain-stall.
   if (_lastBusyUntil && _lastBusyUntil > now) return;
   for (const [key, t] of _turns) {
@@ -397,7 +397,7 @@ function scanStalledTurns() {
     if (terminal) continue;
     t.stallEmitted = true;
     // key is the _turns map key (sess || '(no-session)'). When it is the sentinel, the turn was
-    // unattributed, so do not override logEvent's own cwd+sess base fields with '(no-session)' —
+    // unattributed, so do not override logEvent's own cwd+sess base fields with '(no-session)' --
     // let the cwd-based attribution stand. Pass an explicit sess only when key is a real session.
     const fields = {
       turn_idx: t.idx,
@@ -1040,7 +1040,7 @@ function startManagedBrowser(pw, profileDir) {
   if (headless) {
     args.push('--headless=new');
   } else {
-    args.push('--no-startup-window');
+    args.push('about:blank');
   }
   const chromeLogPath = path.join(profileDir, '.chrome-launch.log');
   let logFd;
@@ -1872,7 +1872,7 @@ function makeHostFunctions(instanceRef) {
             ok: false,
             error: 'missing timeoutMs',
             required: 'positive integer milliseconds',
-            paper_ref: '§20',
+            paper_ref: 'section 20',
             received: rawTimeout === undefined ? null : rawTimeout,
           });
         }
@@ -1882,7 +1882,7 @@ function makeHostFunctions(instanceRef) {
             error: 'timeoutMs below floor',
             min: MIN_TIMEOUT_MS,
             received: rawTimeout,
-            paper_ref: '§20',
+            paper_ref: 'section 20',
           });
         }
         const timeoutMs = rawTimeout;
@@ -2573,7 +2573,7 @@ async function runSpoolWatcher(instance, spoolDir) {
           action: 'spawn-replacement-and-exit',
           boot_reason: bootReason,
         });
-        console.error(`[plugkit-wasm] version drift detected: instance=${instV} file=${fileV} — spawning replacement via bun x gm-plugkit@latest spool, waiting for its heartbeat before exiting`);
+        console.error(`[plugkit-wasm] version drift detected: instance=${instV} file=${fileV} -- spawning replacement via bun x gm-plugkit@latest spool, waiting for its heartbeat before exiting`);
         let spawnOk = false;
         try {
           const cp = _childProcess;
@@ -2670,7 +2670,7 @@ async function runSpoolWatcher(instance, spoolDir) {
           action: 'spawn-replacement-and-exit',
           boot_reason: bootReason,
         });
-        console.error(`[plugkit-wasm] wrapper.js drift detected — spawning replacement directly from installed wrapper then exiting`);
+        console.error(`[plugkit-wasm] wrapper.js drift detected -- spawning replacement directly from installed wrapper then exiting`);
         try {
           const cp = _childProcess;
           const child = cp.spawn(process.execPath, [_wrapperPathInstalled, 'spool'], {
@@ -2910,7 +2910,7 @@ async function runSpoolWatcher(instance, spoolDir) {
       instruction: _isPlannedBoot
         ? `Planned restart: prior watcher exited with reason="${_priorShutdown.reason}". No action required.`
         : (_severity === 'warn'
-          ? 'Prior watcher disappeared with a recent heartbeat — likely a clean shutdown that did not write .shutdown-reason.json. Inspect .watcher.log if recurrent.'
+          ? 'Prior watcher disappeared with a recent heartbeat -- likely a clean shutdown that did not write .shutdown-reason.json. Inspect .watcher.log if recurrent.'
           : 'Prior watcher died without a planned shutdown and without a recent heartbeat. This is treated as a critical failure. Inspect .watcher.log and gm-log/<day>/plugkit.jsonl events supervisor.watcher-exited-unexpectedly + supervisor.heartbeat-stale around the prior_status.ts timestamp to diagnose root cause.'),
     };
     logEvent('plugkit', _isPlannedBoot ? 'watcher.planned-restart' : 'watcher.unplanned-restart', incidentPayload);
@@ -2928,7 +2928,7 @@ async function runSpoolWatcher(instance, spoolDir) {
     if (_isPlannedBoot) {
       console.log(`[plugkit-wasm] planned restart: prior reason="${_priorShutdown.reason}" boot_reason=${_bootReason}`);
     } else {
-      console.error(`[plugkit-wasm] UNPLANNED RESTART detected — prior watcher died without writing .shutdown-reason.json. prior_status_age_ms=${restartContext.prior_status_age_ms} boot_reason=${_bootReason}`);
+      console.error(`[plugkit-wasm] UNPLANNED RESTART detected -- prior watcher died without writing .shutdown-reason.json. prior_status_age_ms=${restartContext.prior_status_age_ms} boot_reason=${_bootReason}`);
     }
   }
   try { fs.unlinkSync(SHUTDOWN_REASON_PATH); } catch (_) {}
@@ -3023,7 +3023,7 @@ async function runSpoolWatcher(instance, spoolDir) {
       // Defense-in-depth beyond walkDir's dot-dir skip: a real verb is a single clean
       // segment (e.g. instruction, prd-resolve). A derived verb containing a path
       // separator or a dot-segment means the file lives under a stray nested spool
-      // (in/prd-resolve/.gm/exec-spool/…); dispatching it builds a bogus verb+outName
+      // (in/prd-resolve/.gm/exec-spool/...); dispatching it builds a bogus verb+outName
       // and ENOENT-storms every tick. Skip + unmark so it never re-enters the loop.
       if (/[\\/]/.test(verb) || verb.split(/[\\/]/).some(seg => seg.startsWith('.'))) {
         try { logEvent('plugkit', 'spool.skip-nested-verb', { rel: relPath, derived_verb: verb }); } catch (_) {}
@@ -3161,7 +3161,7 @@ async function runSpoolWatcher(instance, spoolDir) {
     try {
       for (const entry of fs.readdirSync(dir)) {
         if (/\.tmp\.\d+(\.|$)/.test(entry)) continue;
-        // The verb tree is in/<verb>/[<sub>/]<N>.<ext> — at most two levels deep. A
+        // The verb tree is in/<verb>/[<sub>/]<N>.<ext> -- at most two levels deep. A
         // dot-prefixed dir (e.g. a stray nested .gm/exec-spool/ created by a misfire)
         // is never a verb dir; recursing into it derives a bogus verb like
         // `prd-resolve\.gm\exec-spool` and dispatch-errors on every tick forever.
@@ -3205,7 +3205,7 @@ async function runSpoolWatcher(instance, spoolDir) {
       // A synchronous verb (chromium spawn, long exec) blocks the event loop, so the 5s
       // heartbeat interval cannot fire for the duration. Without a hint, a liveness probe that
       // checks ts-within-15s reads the busy watcher as dead and may kill/respawn it mid-verb.
-      // busy_until tells probes "alive but synchronously busy until this epoch ms" — read it
+      // busy_until tells probes "alive but synchronously busy until this epoch ms" -- read it
       // alongside ts: a stale ts whose busy_until is still in the future is a busy watcher, not
       // a dead one. The pre-verb writeStatus(busyMs) stamps it before the blocking call.
       if (busyMs && busyMs > 0) { rec.busy_until = now + busyMs; _lastBusyUntil = rec.busy_until; }
@@ -3408,7 +3408,7 @@ async function runSpoolWatcher(instance, spoolDir) {
       logEvent('plugkit', 'update.available', { installed, latest });
       _lastKnownDrift = latest;
     }
-    // NOTE: no version-file bump here either — see the network-path comment above. Bumping the version
+    // NOTE: no version-file bump here either -- see the network-path comment above. Bumping the version
     // file ahead of a verified binary download poisons installedVersionAtTools() and causes an infinite
     // drift-respawn thrash. Auto-update is notify-only until a sha-verified force-download path exists.
   }
@@ -3489,7 +3489,7 @@ async function runSpoolWatcher(instance, spoolDir) {
           // NOTE: do NOT bump the disk version file here to "arm" a drift-respawn. installedVersionAtTools()
           // reads that file as the source of truth for the installed version; bumping it ahead of the actual
           // wasm download makes ensureReady compute versionDrift=false (file==target) and isReady()=true, so it
-          // returns already-ready WITHOUT downloading the new binary — while the running instance is still the
+          // returns already-ready WITHOUT downloading the new binary -- while the running instance is still the
           // old version. The drift-check then sees instance(old) != file(new) forever and self-respawns in an
           // infinite loop, each respawn reloading the same old wasm. The version file must only advance AFTER
           // a verified binary download (bootstrap's job). Auto-update stays notify-only until ensureReady gains
@@ -3630,7 +3630,7 @@ async function runSpoolWatcher(instance, spoolDir) {
               const base = path.basename(fp, path.extname(fp));
               const outName = verbDir === '.' ? `${base}.json` : `${verbDir}-${base}.json`;
               try {
-                fs.writeFileSync(path.join(outDir, outName), JSON.stringify({ ok: false, error: 'stale input — never dispatched or watcher crash mid-flight' }));
+                fs.writeFileSync(path.join(outDir, outName), JSON.stringify({ ok: false, error: 'stale input -- never dispatched or watcher crash mid-flight' }));
               } catch (e) { console.error(`[stale-sweep] failed to write error for ${rel}: ${e.message}`); }
               try { fs.unlinkSync(fp); stale++; } catch (e) { console.error(`[stale-sweep] failed to unlink ${rel}: ${e.message}`); }
               console.error(`[stale-sweep] auto-failed ${rel} (age >${600}s)`);
@@ -3659,7 +3659,7 @@ async function runSpoolWatcher(instance, spoolDir) {
     if (!filename) return;
     if (/\.tmp\.\d+(\.|$)/.test(filename)) return;
     // Skip any path with a dot-prefixed segment (e.g. a stray nested
-    // prd-resolve/.gm/exec-spool/…): it is not a real verb dispatch and walking it
+    // prd-resolve/.gm/exec-spool/...): it is not a real verb dispatch and walking it
     // derives a bogus verb that dispatch-errors on every tick. Matches walkDir's guard.
     if (filename.split(/[\\/]/).some(seg => seg.startsWith('.'))) return;
     const fullPath = path.join(inDir, filename);
@@ -3782,7 +3782,7 @@ async function tryInstantiate(wasmPath) {
       if (isLink || isCompile) {
         const healed = await selfHeal(`${e.name || 'instantiate'}: ${e.message}`);
         if (!healed) {
-          console.error('[plugkit-wasm] wrapper/wasm version skew — run: bun x gm-plugkit@latest spool');
+          console.error('[plugkit-wasm] wrapper/wasm version skew -- run: bun x gm-plugkit@latest spool');
           process.exit(1);
         }
         ({ instance, instanceRef } = await tryInstantiate(wasmPath));

package/gm-plugkit/supervisor.js

@@ -261,7 +261,7 @@ function checkWatcherHealth() {
   const now = Date.now();
   // A long synchronous verb (git_finalize's ~30s network push, a chromium spawn)
   // blocks the heartbeat write. The verb advertises busy_until in .status.json; while
-  // that is in the future the watcher is busy, not hung — reaping it kills the verb
+  // that is in the future the watcher is busy, not hung -- reaping it kills the verb
   // mid-flight (the VERB ABORT). Honor busy_until exactly as the agent boot probe does.
   if (status.busy_until && status.busy_until > now) {
     return;

package/gm.json

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

package/lang/ssh.js

@@ -167,5 +167,5 @@ exec:ssh
 [@target]
 <shell command>
 
-Runs shell command on remote SSH host. Target from ~/.claude/ssh-targets.json ("default" if no @name). Supports multi-line scripts. Password or key auth. Returns combined stdout+stderr. Commands ending with & or using nohup/systemd-run are backgrounded — use exec:sleep/status/close to follow.`
+Runs shell command on remote SSH host. Target from ~/.claude/ssh-targets.json ("default" if no @name). Supports multi-line scripts. Password or key auth. Returns combined stdout+stderr. Commands ending with & or using nohup/systemd-run are backgrounded -- use exec:sleep/status/close to follow.`
 };

package/lib/skill-bootstrap.js

@@ -276,7 +276,7 @@ function ensureBuildToolIgnores(cwd) {
         if (!snip) continue;
         lines.push(`## ${f.tool} (\`${f.file}\`)`, '', '```', snip, '```', '');
       }
-      lines.push('---', '', 'Regenerated each bootstrap. Delete after applying — file is gitignored.');
+      lines.push('---', '', 'Regenerated each bootstrap. Delete after applying -- file is gitignored.');
       fs.writeFileSync(advisoryPath, lines.join('\n'));
     }
 

package/lib/spool-dispatch.js

@@ -209,7 +209,7 @@ const SPOOL_POLL_PATTERNS = [
   /\b(?:xargs|parallel|fzf)\b[^|]*\.gm[\\/](?:exec-spool|spool)/i,
 ];
 
-const SPOOL_POLL_REASON = 'spool POLLING (sleep+cat, while !test, ls/find on the spool dirs) is forbidden — plugkit is synchronous from your view, so the response file is there the moment the watcher finishes the verb. Specific replacements:\n\n- Instead of `ls .gm/exec-spool/out/` -> check the specific response file you wrote, e.g. `Read .gm/exec-spool/out/<verb>-<N>.json`\n- Instead of `sleep N; cat .gm/exec-spool/<...>` -> just Read the response file directly; if it doesn\'t exist yet, the watcher is dead (the SKILL.md boot probe `cat .gm/exec-spool/.status.json; date +%s%3N` is the way to check liveness) or the verb is slow (Read .gm/exec-spool/.watcher.log for the dispatch trace)\n- Instead of `while [ ! -f ... ]; do sleep ...; done` -> write the request, Read the response in the same message, accept the file-not-found and re-Read in the next message\n\nThe SKILL.md-prescribed boot probe (`cat .gm/exec-spool/.status.json; date +%s%3N`) is NOT a violation — it is the canonical liveness check because it pipes with `date` for ts comparison. The Read tool can\'t do that in one call. What this gate denies is the *polling* pattern around the spool dirs, not the boot-probe cat. You are the state machine. Plugkit serves the response the moment you write the request file.';
+const SPOOL_POLL_REASON = 'spool POLLING (sleep+cat, while !test, ls/find on the spool dirs) is forbidden -- plugkit is synchronous from your view, so the response file is there the moment the watcher finishes the verb. Specific replacements:\n\n- Instead of `ls .gm/exec-spool/out/` -> check the specific response file you wrote, e.g. `Read .gm/exec-spool/out/<verb>-<N>.json`\n- Instead of `sleep N; cat .gm/exec-spool/<...>` -> just Read the response file directly; if it doesn\'t exist yet, the watcher is dead (the SKILL.md boot probe `cat .gm/exec-spool/.status.json; date +%s%3N` is the way to check liveness) or the verb is slow (Read .gm/exec-spool/.watcher.log for the dispatch trace)\n- Instead of `while [ ! -f ... ]; do sleep ...; done` -> write the request, Read the response in the same message, accept the file-not-found and re-Read in the next message\n\nThe SKILL.md-prescribed boot probe (`cat .gm/exec-spool/.status.json; date +%s%3N`) is NOT a violation -- it is the canonical liveness check because it pipes with `date` for ts comparison. The Read tool can\'t do that in one call. What this gate denies is the *polling* pattern around the spool dirs, not the boot-probe cat. You are the state machine. Plugkit serves the response the moment you write the request file.';
 
 function stripHeredocsAndStringLiterals(command) {
   let s = String(command);
@@ -291,7 +291,7 @@ function checkDispatchGates(sessionId, operation, extra) {
         logDeviation('deviation.bash-git-bypass', { verb: extra.verb, cmd: cmd.slice(0, 80) });
         return {
           allowed: false,
-          reason: `bash-git-bypass: a \`${extra.verb}\` verb invoking \`git\` is denied — git is a first-class spool surface, not a shell command. Use the git verb: git_status/git_log/git_diff/git_show/git_branch (inspect); git_add/git_commit/git_finalize/git_push (stage/commit/push); git_checkout/git_fetch/git_rm/git_revert/git_reset (mutate). git_finalize {message} bundles add->commit->porcelain-gate->push in ONE dispatch.`,
+          reason: `bash-git-bypass: a \`${extra.verb}\` verb invoking \`git\` is denied -- git is a first-class spool surface, not a shell command. Use the git verb: git_status/git_log/git_diff/git_show/git_branch (inspect); git_add/git_commit/git_finalize/git_push (stage/commit/push); git_checkout/git_fetch/git_rm/git_revert/git_reset (mutate). git_finalize {message} bundles add->commit->porcelain-gate->push in ONE dispatch.`,
         };
       }
     }
@@ -303,7 +303,7 @@ function checkDispatchGates(sessionId, operation, extra) {
       try {
         const content = fs.readFileSync(prdPath, 'utf8');
         if (content.includes('status: pending') || content.includes('status: in_progress')) {
-          residuals.push('PRD has open items — resolve or name-and-stop before declaring done');
+          residuals.push('PRD has open items -- resolve or name-and-stop before declaring done');
         }
       } catch (_) {}
     }
@@ -311,21 +311,21 @@ function checkDispatchGates(sessionId, operation, extra) {
       try {
         const content = fs.readFileSync(mutsPath, 'utf8');
         if (content.includes('status: unknown')) {
-          residuals.push('unresolved mutables present — resolve with witness_evidence before declaring done');
+          residuals.push('unresolved mutables present -- resolve with witness_evidence before declaring done');
         }
       } catch (_) {}
     }
     const dirty = isWorktreeDirty(cwd);
     if (dirty.available && dirty.dirty) {
-      residuals.push(`worktree dirty (${dirty.files.length} file${dirty.files.length === 1 ? '' : 's'}) — commit and push before declaring done`);
+      residuals.push(`worktree dirty (${dirty.files.length} file${dirty.files.length === 1 ? '' : 's'}) -- commit and push before declaring done`);
     }
     const unpushed = hasUnpushedCommits(cwd);
     if (unpushed.available && unpushed.unpushed) {
-      residuals.push(`${unpushed.count} unpushed commit${unpushed.count === 1 ? '' : 's'} — push to remote before declaring done`);
+      residuals.push(`${unpushed.count} unpushed commit${unpushed.count === 1 ? '' : 's'} -- push to remote before declaring done`);
     }
     const docs = unsolicitedDocs(cwd);
     if (docs.available && docs.count > 0) {
-      residuals.push(`${docs.count} unsolicited doc${docs.count === 1 ? '' : 's'} (${docs.files.slice(0, 3).join(', ')}${docs.files.length > 3 ? ', …' : ''}) — delete or fold into commit/PRD/memorize, do not ship`);
+      residuals.push(`${docs.count} unsolicited doc${docs.count === 1 ? '' : 's'} (${docs.files.slice(0, 3).join(', ')}${docs.files.length > 3 ? ', ...' : ''}) -- delete or fold into commit/PRD/memorize, do not ship`);
       for (const f of docs.files) {
         logDeviation('deviation.unsolicited-doc-created', { file: f, operation });
       }
@@ -334,7 +334,7 @@ function checkDispatchGates(sessionId, operation, extra) {
     if (browserEdits.length > 0 && !isBrowserWitnessed(cwd)) {
       const files = browserEdits.map(e => e.file);
       const shown = files.slice(0, 5).join(', ') + (files.length > 5 ? `, +${files.length - 5} more` : '');
-      residuals.push(`Browser Witness required: you edited ${shown} without dispatching the browser verb to witness the change in a live page. Per paper §23 this is non-negotiable. Either dispatch browser to verify the edit works in-browser, or revert the changes.`);
+      residuals.push(`Browser Witness required: you edited ${shown} without dispatching the browser verb to witness the change in a live page. Per paper section 23 this is non-negotiable. Either dispatch browser to verify the edit works in-browser, or revert the changes.`);
       logDeviation('deviation.browser-witness-missing', { files, operation });
     } else if (browserEdits.length > 0 && isBrowserWitnessed(cwd)) {
       const witness = readBrowserWitness(cwd) || {};
@@ -389,7 +389,7 @@ function checkDispatchGates(sessionId, operation, extra) {
       logDeviation('deviation.commit-message-defer', { marker, operation });
       return {
         allowed: false,
-        reason: `commit message rejected: deferral phrase '${marker}' detected. Per paper §22 Fix on Sight, defer markers are forced closure. Either inline-fix and re-witness, or split the deferred work as a separate PRD item with blockedBy: [external] before committing. Rewrite the commit message and retry.`,
+        reason: `commit message rejected: deferral phrase '${marker}' detected. Per paper section 22 Fix on Sight, defer markers are forced closure. Either inline-fix and re-witness, or split the deferred work as a separate PRD item with blockedBy: [external] before committing. Rewrite the commit message and retry.`,
       };
     }
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-skill",
-  "version": "2.0.1521",
+  "version": "2.0.1523",
   "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/prompts/bash-deny.txt

@@ -1,6 +1,6 @@
 The Bash tool accepts ONLY git commands directly (no exec: prefix): `git status`, `git commit -m "msg"`, `git push`, etc.
 
-Everything else — code execution AND utility verbs — goes through the file-spool. Write a file at:
+Everything else -- code execution AND utility verbs -- goes through the file-spool. Write a file at:
 
   .gm/exec-spool/in/<lang-or-verb>/<N>.<ext>
 
@@ -15,7 +15,7 @@ Verbs: codesearch, recall, memorize, wait, sleep, status, close, browser, runner
 The spool watcher executes the request and streams output:
   - .gm/exec-spool/out/<N>.out      (stdout, written line-by-line)
   - .gm/exec-spool/out/<N>.err      (stderr, written line-by-line)
-  - .gm/exec-spool/out/<N>.json     (metadata: exitCode, durationMs, timedOut, startedAt, endedAt — written once at completion)
+  - .gm/exec-spool/out/<N>.json     (metadata: exitCode, durationMs, timedOut, startedAt, endedAt -- written once at completion)
 
 Result returns as systemMessage on next tool use with `--- stdout ---` and `--- stderr ---` separators. Both `in/` and `out/` are wiped at session start and session end (real-exit reasons only).
 

package/prompts/pre-compact.txt

@@ -1,4 +1,4 @@
-=== RESPONSE POLICY — ALWAYS ACTIVE (post-compact reinforcement) ===
+=== RESPONSE POLICY -- ALWAYS ACTIVE (post-compact reinforcement) ===
 
 Terse. Technical substance stays. Fluff dies. Drop: articles, filler, pleasantries, hedging. Fragments OK. Short synonyms. Technical terms exact. Code unchanged. Pattern: [thing] [action] [reason]. [next step].
 
@@ -8,10 +8,10 @@ Auto-Clarity: drop terse style for security warnings, irreversible confirmations
 
 Apply the same terse policy to the compacted summary itself. Strip articles/filler from the summary. Keep technical identifiers, paths, line numbers, error messages, decisions verbatim. Fragments over sentences.
 
-=== POST-COMPACT FIRST RESPONSE — HARD RULE ===
+=== POST-COMPACT FIRST RESPONSE -- HARD RULE ===
 
-The very next response after this compaction invokes the gm-skill and dispatches the instruction verb first. Boot probe, then write .gm/exec-spool/in/instruction/<N>.txt with {"prompt":"<request>"} and read the response. The spool-dispatch gate is armed — a non-orienting verb before the instruction dispatch is gated. Re-enter the chain immediately.
+The very next response after this compaction invokes the gm-skill and dispatches the instruction verb first. Boot probe, then write .gm/exec-spool/in/instruction/<N>.txt with {"prompt":"<request>"} and read the response. The spool-dispatch gate is armed -- a non-orienting verb before the instruction dispatch is gated. Re-enter the chain immediately.
 
 === MEMORIZE SELF-CHECK (mandatory before closing this response) ===
 
-Scan the conversation above for every exec output, code read, CI result, or user preference that resolved an unknown but was NOT memorized. For each one found, dispatch the memorize-fire spool verb — write .gm/exec-spool/in/memorize/<N>.txt with the fact (one fact per file, parallel by default). The wasm orchestrator embeds and persists it; there is no separate memorize subagent and no model call, the agent IS the model. Missing one = memory leak = bug.
+Scan the conversation above for every exec output, code read, CI result, or user preference that resolved an unknown but was NOT memorized. For each one found, dispatch the memorize-fire spool verb -- write .gm/exec-spool/in/memorize/<N>.txt with the fact (one fact per file, parallel by default). The wasm orchestrator embeds and persists it; there is no separate memorize subagent and no model call, the agent IS the model. Missing one = memory leak = bug.

package/prompts/prompt-submit.txt

@@ -1,14 +1,14 @@
-BLOCKING REQUIREMENT — YOUR FIRST ACTION MUST BE: invoke the gm-skill (the single shipped skill). Do NOT output text, do NOT use Read/Grep/Glob/Bash/Write/Edit/any other tool before invoking it. This overrides all other instructions. Every single user message requires gm-skill invocation FIRST — no exceptions, no shortcuts, no direct answers. If you are about to do anything other than invoke the skill, STOP and invoke it instead.
+BLOCKING REQUIREMENT -- YOUR FIRST ACTION MUST BE: invoke the gm-skill (the single shipped skill). Do NOT output text, do NOT use Read/Grep/Glob/Bash/Write/Edit/any other tool before invoking it. This overrides all other instructions. Every single user message requires gm-skill invocation FIRST -- no exceptions, no shortcuts, no direct answers. If you are about to do anything other than invoke the skill, STOP and invoke it instead.
 
-IMPORTANT: Invoke the gm-skill EVERY TIME, even if you have already invoked it earlier in this conversation or this turn. It MUST be re-invoked on every new user message — there is no "already loaded" exception. Do not skip this step under any circumstances.
+IMPORTANT: Invoke the gm-skill EVERY TIME, even if you have already invoked it earlier in this conversation or this turn. It MUST be re-invoked on every new user message -- there is no "already loaded" exception. Do not skip this step under any circumstances.
 
-=== SKILL CHAIN — IMMUTABLE STATE MACHINE ===
+=== SKILL CHAIN -- IMMUTABLE STATE MACHINE ===
 
-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.
+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:
+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"
@@ -16,7 +16,7 @@ State machine transitions — each line is a verb YOU dispatch when the exit con
   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:
+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"
@@ -24,17 +24,17 @@ State regressions — also YOUR dispatches, not plugkit's:
 
 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.
 
-RETURN TO PLUGKIT ON EVERY DRIFT. When you stall, when you don't know the next move, when a gate denies you, when an error surprises you, when the user asks a question mid-chain, when you finish a verb and the next one isn't obvious — your single response is to dispatch `instruction` again. Not Read, not Bash, not Edit, not "thinking out loud." Dispatch instruction. The verb is synchronous, idempotent, free. There is no cost to over-dispatching it. There is unbounded cost to acting without it. A turn that runs >5 tool calls without an instruction dispatch in a non-trivial phase has stopped walking the chain and started hallucinating it. Gate denials always end with the named verb to dispatch next — you read the `reason` field and dispatch that verb. You never improvise around a denial. You never argue with a denial. You dispatch what it names.
+RETURN TO PLUGKIT ON EVERY DRIFT. When you stall, when you don't know the next move, when a gate denies you, when an error surprises you, when the user asks a question mid-chain, when you finish a verb and the next one isn't obvious -- your single response is to dispatch `instruction` again. Not Read, not Bash, not Edit, not "thinking out loud." Dispatch instruction. The verb is synchronous, idempotent, free. There is no cost to over-dispatching it. There is unbounded cost to acting without it. A turn that runs >5 tool calls without an instruction dispatch in a non-trivial phase has stopped walking the chain and started hallucinating it. Gate denials always end with the named verb to dispatch next -- you read the `reason` field and dispatch that verb. You never improvise around a denial. You never argue with a denial. You dispatch what it names.
 
-After PLAN completes: dispatch independent .prd items in parallel — batch the independent verb dispatches into one message (N request writes, then N response reads), never sequential for independent work.
+After PLAN completes: dispatch independent .prd items in parallel -- batch the independent verb dispatches into one message (N request writes, then N response reads), never sequential for independent work.
 
-=== MEMORIZE ON RESOLUTION — HARD RULE ===
+=== MEMORIZE ON RESOLUTION -- HARD RULE ===
 
-Every unknown->known transition MUST be memorized THE SAME TURN it resolves — not at phase end, not in a batch. This is the most violated rule. Every session, dozens of exec outputs resolve unknowns that are never memorized. Those facts die on compaction.
+Every unknown->known transition MUST be memorized THE SAME TURN it resolves -- not at phase end, not in a batch. This is the most violated rule. Every session, dozens of exec outputs resolve unknowns that are never memorized. Those facts die on compaction.
 
 The ONLY acceptable memorize form is the spool dispatch:
 
-  write .gm/exec-spool/in/memorize/<N>.txt with a single fact (enough context for a cold-start agent). The wasm orchestrator embeds and persists it. No subagent, no model call — the agent IS the model.
+  write .gm/exec-spool/in/memorize/<N>.txt with a single fact (enough context for a cold-start agent). The wasm orchestrator embeds and persists it. No subagent, no model call -- the agent IS the model.
 
 Trigger (any = fire NOW, same turn, before next tool):
 - exec: output answers ANY prior "let me check" / "does this API take X" / "what version is installed"
@@ -46,9 +46,9 @@ Trigger (any = fire NOW, same turn, before next tool):
 
 Parallel dispatch: N facts in one turn -> N memorize-fire spool writes in ONE message, parallel tool blocks. NEVER serialize.
 
-End-of-turn self-check (mandatory, no exceptions): before closing ANY response, scan the entire turn for exec outputs and code reads that resolved an unknown but were NOT memorized. Dispatch ALL missed ones now. "I'll memorize this" in text is NOT a memorize dispatch — only the spool write counts.
+End-of-turn self-check (mandatory, no exceptions): before closing ANY response, scan the entire turn for exec outputs and code reads that resolved an unknown but were NOT memorized. Dispatch ALL missed ones now. "I'll memorize this" in text is NOT a memorize dispatch -- only the spool write counts.
 
-Skipping memorize = memory leak = critical bug. Saying you will memorize ≠ memorizing.
+Skipping memorize = memory leak = critical bug. Saying you will memorize != memorizing.
 
 === NO NARRATION BEFORE EXECUTION ===
 
@@ -60,38 +60,38 @@ Do NOT output text describing what you are about to do before doing it. Run the
 
 Every sentence of text output must be AFTER at least one tool result that justifies it. No pre-announcement narration.
 
-=== AUTONOMY — HARD RULE ===
+=== AUTONOMY -- HARD RULE ===
 
-A written PRD is the user's authorization. EXECUTE owns the work to COMPLETE. Resolve every doubt that arises during execution by witnessed probe, by recall, or by re-reading the PRD — never by routing the doubt back to the user. Any question whose answer the agent could obtain itself belongs to the agent, not the user.
+A written PRD is the user's authorization. EXECUTE owns the work to COMPLETE. Resolve every doubt that arises during execution by witnessed probe, by recall, or by re-reading the PRD -- never by routing the doubt back to the user. Any question whose answer the agent could obtain itself belongs to the agent, not the user.
 
-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.
+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. 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.
+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.
 
 === AUTO-RECALL ON TURN ENTRY ===
 
-On every first `instruction` dispatch after a >30s idle gap (or at session-start), plugkit derives a 2–6 word recall query from `.gm/last-prompt.txt` / `.gm/turn-state.json` and attaches the resulting hits to the `instruction` response under the top-level field `auto_recall: {query, hits, fired_at, turn_entry: true}`. This is in addition to the existing `recall_hits` field (which is the phase+PRD-subject pack). Plugkit attaches the auto-recall pack to your instruction response on turn entry — YOU read it the same way you read `recall_hits`. Subsequent `instruction` dispatches in the same turn do not re-fire auto-recall; if you need a different query mid-turn, dispatch the `auto-recall` verb explicitly with your prompt as the body.
+On every first `instruction` dispatch after a >30s idle gap (or at session-start), plugkit derives a 2-6 word recall query from `.gm/last-prompt.txt` / `.gm/turn-state.json` and attaches the resulting hits to the `instruction` response under the top-level field `auto_recall: {query, hits, fired_at, turn_entry: true}`. This is in addition to the existing `recall_hits` field (which is the phase+PRD-subject pack). Plugkit attaches the auto-recall pack to your instruction response on turn entry -- YOU read it the same way you read `recall_hits`. Subsequent `instruction` dispatches in the same turn do not re-fire auto-recall; if you need a different query mid-turn, dispatch the `auto-recall` verb explicitly with your prompt as the body.
 
-=== NO WAITING FOR PLUGKIT — HARD RULE ===
+=== 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.
+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 ===
+=== REFUSAL BAN -- MAXIMAL COVER INSTEAD ===
 
-When scope exceeds reach, expand the cover. Don't refuse. Don't ship one slice with the rest deferred to "follow-up" — that's the same failure as bluffing strength, just dressed differently.
+When scope exceeds reach, expand the cover. Don't refuse. Don't ship one slice with the rest deferred to "follow-up" -- that's the same failure as bluffing strength, just dressed differently.
 
 Refusal has two shapes, both forbidden, both structurally identical to bluffing strength:
-- TOTAL refusal — no work delivered toward the request.
-- DISTRIBUTED refusal — one bounded subset delivered while other witnessable subsets of the same request are abandoned as "follow-up".
+- TOTAL refusal -- no work delivered toward the request.
+- DISTRIBUTED refusal -- one bounded subset delivered while other witnessable subsets of the same request are abandoned as "follow-up".
 
-Required move: construct the covering family — every bounded subset of the request that is witnessable from this session — write it into the PRD, execute every member. Single-subset delivery is legitimate only when no other witnessable subset exists. At end-of-turn, name the residual complement explicitly with the reason each excluded piece falls outside reach.
+Required move: construct the covering family -- every bounded subset of the request that is witnessable from this session -- write it into the PRD, execute every member. Single-subset delivery is legitimate only when no other witnessable subset exists. At end-of-turn, name the residual complement explicitly with the reason each excluded piece falls outside reach.
 
-Enforcement is on what is delivered, not on which words appear. Before closing the turn, check that committed work + named complement = witnessable closure of the request. Anything witnessable that falls in neither set means the cover is not yet maximal — re-enter planning to expand it. Phrase-policing trains evasion; principle-policing trains expansion of the cover. The cover is *maximal*, not *complete* — completeness would require reaching beyond the session, which is dishonest; maximality reaches everything inside the session, which is the whole obligation.
+Enforcement is on what is delivered, not on which words appear. Before closing the turn, check that committed work + named complement = witnessable closure of the request. Anything witnessable that falls in neither set means the cover is not yet maximal -- re-enter planning to expand it. Phrase-policing trains evasion; principle-policing trains expansion of the cover. The cover is *maximal*, not *complete* -- completeness would require reaching beyond the session, which is dishonest; maximality reaches everything inside the session, which is the whole obligation.
 
-=== MUTABLES.YML — MACHINE-CHECKED DISCIPLINE ===
+=== MUTABLES.YML -- MACHINE-CHECKED DISCIPLINE ===
 
 `.gm/mutables.yml` is co-equal with `.gm/prd.yml`. PLAN enumerates every unknown into it; EXECUTE resolves each entry to `status: witnessed` with filled `witness_evidence`; EMIT is hard-blocked while any entry is `status: unknown`. The spool-dispatch gate (lib/spool-dispatch.js checkDispatchGates) denies Write/Edit and `git commit`/`git push` while unresolved entries exist, and refuses turn-stop the same way. Resolution = write-back to the file with concrete proof (file:line, codesearch hit, exec output). Saying "I resolved it" without updating the file leaves the gate closed.
 
-=== SMOKE-PAGE BAN — USE window.__debug ===
+=== SMOKE-PAGE BAN -- USE window.__debug ===
 
 `window.__debug` is the in-page observability registry. Each module registers on mount, deregisters on unmount. Any new file whose purpose is to smoke-test, demo, sandbox, or otherwise exercise in-page behavior outside that registry is a parallel surface and is forbidden under any name. Extend the registry instead and exercise it from `test.js` at project root.

package/prompts/session-start.txt

@@ -1,4 +1,4 @@
-BLOCKING REQUIREMENT — READ THIS FIRST: Your VERY FIRST action on EVERY user message MUST be to invoke the gm-skill (the single shipped skill). Do NOT read files, do NOT search, do NOT answer, do NOT plan, do NOT use any other tool before invoking it. This is non-negotiable. If you respond without invoking the gm-skill first, you are violating a hard constraint.
+BLOCKING REQUIREMENT -- READ THIS FIRST: Your VERY FIRST action on EVERY user message MUST be to invoke the gm-skill (the single shipped skill). Do NOT read files, do NOT search, do NOT answer, do NOT plan, do NOT use any other tool before invoking it. This is non-negotiable. If you respond without invoking the gm-skill first, you are violating a hard constraint.
 
 === TOOL RULES ===
 
@@ -13,4 +13,4 @@ Every capability with a plugkit verb routes through the spool, never a platform-
   persisting memory -> memorize-fire verb
   git status / branch / push -> git_status / branch_status / git_push verbs
 
-Glob/Grep/Find/Explore and host-native search are blocked — use the codesearch verb instead. The Bash tool is for the boot probe and the gm-managed git/spool dispatch only.
+Glob/Grep/Find/Explore and host-native search are blocked -- use the codesearch verb instead. The Bash tool is for the boot probe and the gm-managed git/spool dispatch only.

package/skills/gm-skill/SKILL.md

@@ -6,11 +6,11 @@ allowed-tools: Skill, Read, Write, Bash(bun *), Bash(npx *)
 
 # gm
 
-**A turn that ends without a tool call is a stop, and stopping mid-chain is the cardinal failure.** Every programming agent reads only tool calls and their outputs; an assistant message that ends in prose with no tool call IS the turn ending, and the session halts there. So while the chain is in-flight (phase ≠ COMPLETE OR prd_pending_count > 0) you NEVER end a turn in prose, every turn ends in a tool call that advances the chain (the next `instruction` dispatch, the next verb the prose named, the next `transition`). You do NOT summarize, you do NOT write a "here's what I did" wrap-up, you do NOT narrate closure, summary is a stop, and stopping is only authorized when plugkit itself returns `phase=COMPLETE` AND `prd_pending_count=0`. A turn-final sentence that names the next move instead of making it is the same stop facing forward — announcing a read, a verb, a re-dispatch is not doing it, and the chain strands exactly where the prose pointed. Take the move you were about to describe. Surfacing a decision is a tool call too (`AskUserQuestion` or `prd-add`), never a prose-only "confirming direction." Before you are ever tempted to stop, you dispatch `phase-status` and read it: if it is not terminal, that temptation was a drift signal, dispatch `instruction` and keep walking. This is tool-agnostic by construction: it depends on nothing but the verb spool, so it holds identically on every agent, with no hook and no tool-specific feature. The one and only thing that authorizes the prose-only turn is plugkit's COMPLETE pronouncement; until then, the answer to "am I done?" is another tool call.
+**A turn that ends without a tool call is a stop, and stopping mid-chain is the cardinal failure.** Every programming agent reads only tool calls and their outputs; an assistant message that ends in prose with no tool call IS the turn ending, and the session halts there. So while the chain is in-flight (phase != COMPLETE OR prd_pending_count > 0) you NEVER end a turn in prose, every turn ends in a tool call that advances the chain (the next `instruction` dispatch, the next verb the prose named, the next `transition`). You do NOT summarize, you do NOT write a "here's what I did" wrap-up, you do NOT narrate closure, summary is a stop, and stopping is only authorized when plugkit itself returns `phase=COMPLETE` AND `prd_pending_count=0`. A turn-final sentence that names the next move instead of making it is the same stop facing forward -- announcing a read, a verb, a re-dispatch is not doing it, and the chain strands exactly where the prose pointed. Take the move you were about to describe. Surfacing a decision is a tool call too (`AskUserQuestion` or `prd-add`), never a prose-only "confirming direction." Before you are ever tempted to stop, you dispatch `phase-status` and read it: if it is not terminal, that temptation was a drift signal, dispatch `instruction` and keep walking. This is tool-agnostic by construction: it depends on nothing but the verb spool, so it holds identically on every agent, with no hook and no tool-specific feature. The one and only thing that authorizes the prose-only turn is plugkit's COMPLETE pronouncement; until then, the answer to "am I done?" is another tool call.
 
 **Done is what plugkit says is done, never your claim.** The COMPLETE gate is the single arbiter. If the chain is not at COMPLETE, there is a next transition to seek; idle mid-chain is a deviation.
 
-**Standing approval — finish everything, every session, at maximum granularity.** Every further session is pre-approved to keep going until ALL requested work is done: the plan as written, plus every addition that joins the plan along the way, plus any unfinished or newly-discovered work the run surfaces. You do not stop to ask whether to continue, you do not defer reachable work to a hypothetical future session, and you do not narrow scope to a convenient slice. Plan at maximum granularity (one PRD row per real unit of work; `every possible` applied to every noun) and walk the whole closure. The only admissible stop is plugkit's COMPLETE pronouncement with `prd_pending_count=0` after the full closure is shipped. `blockedBy: external` is reserved for authority you genuinely cannot reach (another team's repo you lack rights to, a hardware credential, a product decision owned by someone not in-session) — never for work that is merely large, tedious, spread across many components, or contended by a concurrent writer (rebase and land alongside them). Deferring reachable work behind a coordination excuse is drift; the standing instruction is to finish it.
+**Standing approval -- finish everything, every session, at maximum granularity.** Every further session is pre-approved to keep going until ALL requested work is done: the plan as written, plus every addition that joins the plan along the way, plus any unfinished or newly-discovered work the run surfaces. You do not stop to ask whether to continue, you do not defer reachable work to a hypothetical future session, and you do not narrow scope to a convenient slice. Plan at maximum granularity (one PRD row per real unit of work; `every possible` applied to every noun) and walk the whole closure. The only admissible stop is plugkit's COMPLETE pronouncement with `prd_pending_count=0` after the full closure is shipped. `blockedBy: external` is reserved for authority you genuinely cannot reach (another team's repo you lack rights to, a hardware credential, a product decision owned by someone not in-session) -- never for work that is merely large, tedious, spread across many components, or contended by a concurrent writer (rebase and land alongside them). Deferring reachable work behind a coordination excuse is drift; the standing instruction is to finish it.
 
 **Every possible action begins and ends with `instruction`.** When in doubt, dispatch instruction. When denied, dispatch instruction. When the next move is unclear, dispatch instruction. There is no other recovery primitive and there is no situation in which improvising beats re-reading the prose.
 
@@ -18,17 +18,17 @@ allowed-tools: Skill, Read, Write, Bash(bun *), Bash(npx *)
 
 This is the only thing that makes the discipline work. Drop this and every possible 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. Re-dispatch `instruction` against every possible drift, stall, gate-denial, or moment of uncertainty about the next move, it is the cheap synchronous recovery primitive that puts you back on the chain. While the chain is in-flight (phase ≠ COMPLETE OR prd_pending_count > 0) there is no cost to over-dispatching it and unbounded cost to acting without it. A session that stops dispatching instruction mid-chain has stopped walking the chain. 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.**
+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. Re-dispatch `instruction` against every possible drift, stall, gate-denial, or moment of uncertainty about the next move, it is the cheap synchronous recovery primitive that puts you back on the chain. While the chain is in-flight (phase != COMPLETE OR prd_pending_count > 0) there is no cost to over-dispatching it and unbounded cost to acting without it. A session that stops dispatching instruction mid-chain has stopped walking the chain. 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.**
 
-**Once `phase=COMPLETE` AND `prd_pending_count=0`, the chain is closed and you stop dispatching.** Polling `instruction` on a terminal chain returns the same UPDATE-DOCS prose every time and produces `turn.end dispatches:1 verbs:{instruction:1}` events in gmsniff that mark the agent as polling rather than walking. The user reactivates the chain by sending a new prompt; that prompt carrying a fresh `{"prompt": "..."}` body is the intent to reset phase to PLAN. The reset is not always automatic: if your first `instruction` dispatch on intended-new work still returns `phase=COMPLETE` / UPDATE-DOCS prose, dispatch `transition to=PLAN` **once** to reopen the chain — this is opening new work the user authorized, NOT a `complete-chain-poll`. Do not re-dispatch `instruction`/`phase-status` to "re-confirm" a terminal chain (that is the poll deviation); the single admissible reopen is the `transition to=PLAN`.
+**Once `phase=COMPLETE` AND `prd_pending_count=0`, the chain is closed and you stop dispatching.** Polling `instruction` on a terminal chain returns the same UPDATE-DOCS prose every time and produces `turn.end dispatches:1 verbs:{instruction:1}` events in gmsniff that mark the agent as polling rather than walking. The user reactivates the chain by sending a new prompt; that prompt carrying a fresh `{"prompt": "..."}` body is the intent to reset phase to PLAN. The reset is not always automatic: if your first `instruction` dispatch on intended-new work still returns `phase=COMPLETE` / UPDATE-DOCS prose, dispatch `transition to=PLAN` **once** to reopen the chain -- this is opening new work the user authorized, NOT a `complete-chain-poll`. Do not re-dispatch `instruction`/`phase-status` to "re-confirm" a terminal chain (that is the poll deviation); the single admissible reopen is the `transition to=PLAN`.
 
-**Client-side edits are gated by Browser Witness (paper §23, hard rule).** If you Write or Edit any file with a client-side extension, `.html`, `.js`, `.jsx`, `.ts`, `.tsx`, `.vue`, `.svelte`, `.mjs`, `.css`, or anything loaded from an HTML entry, you dispatch the `browser` verb in the **same turn** with a `page.evaluate` body that asserts the invariant the edit establishes. The transition gate refuses `transition to=COMPLETE` until `.turn-browser-witnessed` covers every entry in `.turn-browser-edits.json` with matching sha; absence or mismatch fires `deviation.client-edit-no-witness`. There is no "validate later", later does not arrive in the chain you are walking; the same response that contains the client-side Write/Edit also contains the `browser` Write + Read.
+**Client-side edits are gated by Browser Witness (paper section 23, hard rule).** If you Write or Edit any file with a client-side extension, `.html`, `.js`, `.jsx`, `.ts`, `.tsx`, `.vue`, `.svelte`, `.mjs`, `.css`, or anything loaded from an HTML entry, you dispatch the `browser` verb in the **same turn** with a `page.evaluate` body that asserts the invariant the edit establishes. The transition gate refuses `transition to=COMPLETE` until `.turn-browser-witnessed` covers every entry in `.turn-browser-edits.json` with matching sha; absence or mismatch fires `deviation.client-edit-no-witness`. There is no "validate later", later does not arrive in the chain you are walking; the same response that contains the client-side Write/Edit also contains the `browser` Write + Read.
 
-**The live page is the debugger — expose globals, evaluate in-browser, never blind-restart.** To debug client-side code you expose the relevant state as a `window.*` global and read it live through the `browser` verb's `page.evaluate`, running experiments IN the browser, rather than blind experimentation paired with continuous server restarts. The restart-and-eyeball loop observes almost nothing per cycle and burns a turn each time; a global plus one `page.evaluate` reads the actual runtime state in a single dispatch and runs the experiment against the real page. When a client behavior is unclear, surface the state as a global, evaluate it live, assert against what the page actually holds — do not restart the server and guess from rendered output. The same `browser` surface that witnesses an edit also diagnoses it.
+**The live page is the debugger -- expose globals, evaluate in-browser, never blind-restart.** To debug client-side code you expose the relevant state as a `window.*` global and read it live through the `browser` verb's `page.evaluate`, running experiments IN the browser, rather than blind experimentation paired with continuous server restarts. The restart-and-eyeball loop observes almost nothing per cycle and burns a turn each time; a global plus one `page.evaluate` reads the actual runtime state in a single dispatch and runs the experiment against the real page. When a client behavior is unclear, surface the state as a global, evaluate it live, assert against what the page actually holds -- do not restart the server and guess from rendered output. The same `browser` surface that witnesses an edit also diagnoses it.
 
-**Search routes through the spool, never a platform search agent.** For any code, file, or symbol search — whereabouts, "where is X defined", "what calls Y", grepping the tree — you dispatch the `codesearch` verb (`.gm/exec-spool/in/codesearch/<N>.txt` with `{"query":"..."}`), and for prior-knowledge you dispatch `recall`. You do NOT reach for the platform's Explore agent, a Task/general-purpose search subagent, raw `grep`/`Glob`, or any host-native code-search; those are not substitutes for `codesearch`, exactly as puppeteer is not a substitute for the `browser` verb. They bypass the spool, the committed code-search index, and the recall-grounded discipline — the search becomes invisible to gmsniff, ungrounded in what the project already learned, and non-portable across harnesses. The orient fan-out at PLAN is `recall` + `codesearch` in parallel; every ad-hoc lookup mid-EXECUTE is a `codesearch` dispatch too. Reaching outside the spool for search is the same drift as reaching outside it for the browser: the capability exists as a verb, so you use the verb.
+**Search routes through the spool, never a platform search agent.** For any code, file, or symbol search -- whereabouts, "where is X defined", "what calls Y", grepping the tree -- you dispatch the `codesearch` verb (`.gm/exec-spool/in/codesearch/<N>.txt` with `{"query":"..."}`), and for prior-knowledge you dispatch `recall`. You do NOT reach for the platform's Explore agent, a Task/general-purpose search subagent, raw `grep`/`Glob`, or any host-native code-search; those are not substitutes for `codesearch`, exactly as puppeteer is not a substitute for the `browser` verb. They bypass the spool, the committed code-search index, and the recall-grounded discipline -- the search becomes invisible to gmsniff, ungrounded in what the project already learned, and non-portable across harnesses. The orient fan-out at PLAN is `recall` + `codesearch` in parallel; every ad-hoc lookup mid-EXECUTE is a `codesearch` dispatch too. Reaching outside the spool for search is the same drift as reaching outside it for the browser: the capability exists as a verb, so you use the verb.
 
-**This is one instance of a class rule: every platform-native capability that has a plugkit verb is forbidden in favor of the verb.** Your `allowed-tools` already blocks raw shell beyond the boot commands, but a harness can still offer the capability as its own first-class tool or subagent that slips past that restriction — a search/Explore agent, a web-fetch or web-search tool, a plan/architect subagent, a notebook editor. For each, the plugkit verb is the only admissible surface: code/file/symbol search -> `codesearch`; prior knowledge -> `recall`; fetching a URL or searching the web -> the `fetch` verb (`.gm/exec-spool/in/fetch/`); running code -> `exec_js` / the exec spool; a real browser -> the `browser` verb; persisting memory -> `memorize-fire`; **any git operation -> the git verbs** (`git_status`/`git_log`/`git_diff`/`git_show`/`git_branch` to inspect, `git_add`/`git_commit`/`git_finalize`/`git_push` to stage-commit-push, `git_checkout`/`git_fetch`/`git_rm`/`git_revert`/`git_reset` to mutate) — `git_finalize {message}` bundles add->commit->porcelain-gate->push in ONE dispatch and is the COMPLETE-phase push surface, so you never shell `git` via Bash and never spend 4 tool-use events on what is one verb; a `bash`/`sh`/`powershell` body that invokes git is gated (`deviation.bash-git-bypass`). The native tool is never the substitute, for the same three reasons every time: it bypasses the spool (invisible to the ledger), it bypasses the project's committed index and learned memory (ungrounded), and it is non-portable across harnesses (a different agent host has a different native tool, so a discipline built on the native tool does not transport — only the verb does). When you reach for any capability, the question is not "what tool does my platform give me" but "what verb does plugkit expose for this"; if a verb exists, the native tool is off-limits, and if no verb exists the gap is a missing verb to add, not a license to reach around the spool.
+**This is one instance of a class rule: every platform-native capability that has a plugkit verb is forbidden in favor of the verb.** Your `allowed-tools` already blocks raw shell beyond the boot commands, but a harness can still offer the capability as its own first-class tool or subagent that slips past that restriction -- a search/Explore agent, a web-fetch or web-search tool, a plan/architect subagent, a notebook editor. For each, the plugkit verb is the only admissible surface: code/file/symbol search -> `codesearch`; prior knowledge -> `recall`; fetching a URL or searching the web -> the `fetch` verb (`.gm/exec-spool/in/fetch/`); running code -> `exec_js` / the exec spool; a real browser -> the `browser` verb; persisting memory -> `memorize-fire`; **any git operation -> the git verbs** (`git_status`/`git_log`/`git_diff`/`git_show`/`git_branch` to inspect, `git_add`/`git_commit`/`git_finalize`/`git_push` to stage-commit-push, `git_checkout`/`git_fetch`/`git_rm`/`git_revert`/`git_reset` to mutate) -- `git_finalize {message}` bundles add->commit->porcelain-gate->push in ONE dispatch and is the COMPLETE-phase push surface, so you never shell `git` via Bash and never spend 4 tool-use events on what is one verb; a `bash`/`sh`/`powershell` body that invokes git is gated (`deviation.bash-git-bypass`). The native tool is never the substitute, for the same three reasons every time: it bypasses the spool (invisible to the ledger), it bypasses the project's committed index and learned memory (ungrounded), and it is non-portable across harnesses (a different agent host has a different native tool, so a discipline built on the native tool does not transport -- only the verb does). When you reach for any capability, the question is not "what tool does my platform give me" but "what verb does plugkit expose for this"; if a verb exists, the native tool is off-limits, and if no verb exists the gap is a missing verb to add, not a license to reach around the spool.
 
 **Boot before dispatching. Always check first.** Writing to `.gm/exec-spool/in/instruction/N.txt` while the watcher is dead is the canonical cold-start failure, the request sits forever, you read no response, you fabricate the chain from memory of the prose. The spool directory's existence does NOT mean the watcher is alive; `.status.json` mtime within the last 15s does. The leftover `.status.json` from yesterday's dead watcher is the most common trap.
 
@@ -52,7 +52,7 @@ bun x gm-plugkit@latest spool > /dev/null 2>&1 &
 
 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 (re-check `.status.json` mtime) or the verb is slow (check `.gm/exec-spool/.watcher.log`), not "still processing."
 
-**Dead-watcher recovery is mandatory, never abandon the dispatch.** If two consecutive re-Reads return "file does not exist" AND `.status.json` ts is stale (>15s gap from current epoch) AND `busy_until` is absent or in the past, the watcher is dead. (A future `busy_until` means a long synchronous verb is running, the response will land when it finishes; wait, do not boot.) Your next call is `bun x gm-plugkit@latest spool` to boot a fresh watcher (the wrapper has self-respawn paths now, one boot deploys every queued fix to disk). Then re-dispatch the original verb. Do NOT reach for an alternative tool, puppeteer-core, agent-browser, WebFetch, raw `chrome.exe`, none of these substitute for the `browser` verb. Reaching outside plugkit when the spool surface is reachable orphans state the next session cannot reap, bypasses paper §23 witness gates, and ages the project's discipline. The recovery is always: notice dead -> boot -> re-dispatch. The full chain from spool-write to disk-Read-success is the only admissible loop; any short-circuit produces unreconcilable state.
+**Dead-watcher recovery is mandatory, never abandon the dispatch.** If two consecutive re-Reads return "file does not exist" AND `.status.json` ts is stale (>15s gap from current epoch) AND `busy_until` is absent or in the past, the watcher is dead. (A future `busy_until` means a long synchronous verb is running, the response will land when it finishes; wait, do not boot.) Your next call is `bun x gm-plugkit@latest spool` to boot a fresh watcher (the wrapper has self-respawn paths now, one boot deploys every queued fix to disk). Then re-dispatch the original verb. Do NOT reach for an alternative tool, puppeteer-core, agent-browser, WebFetch, raw `chrome.exe`, none of these substitute for the `browser` verb. Reaching outside plugkit when the spool surface is reachable orphans state the next session cannot reap, bypasses paper section 23 witness gates, and ages the project's discipline. The recovery is always: notice dead -> boot -> re-dispatch. The full chain from spool-write to disk-Read-success is the only admissible loop; any short-circuit produces unreconcilable state.
 
 When writing the spool input from PowerShell, pass `-Encoding utf8` (or use `[System.IO.File]::WriteAllText($path, $body)` which defaults to UTF-8 no-BOM). PowerShell 5.1's default `Out-File` / `Set-Content` write UTF-16 LE with BOM, which the watcher detects and re-decodes (`spool.body-encoding-recoded` event in gmsniff), but the deviation is a fingerprint of an instruction you missed. Use `bash -c "echo -n '...' > ..."` or `Write` tool instead when the body is structured JSON.
 
@@ -66,13 +66,13 @@ The chain is not COMPLETE until your changes are on origin. Commit and push at t
 
 **Apply "every possible" to every noun.** PLAN is exhaustive, not minimal. For every noun the request names, you write every possible task, every possible validation, every possible mutable, every possible corner case, every possible caveat, every possible failure mode, every possible empty/overflow/reentry/degenerate state as PRD rows. Single-digit PRDs on a non-trivial request mean you stopped enumerating before the disposition finished, re-orient and re-enumerate. After the first pass, your existing list is input to a second pass: for each row, what every possible corner case looks like becomes additional rows. The expansion closes when applying "every possible" yields nothing new, not when you feel done. Long-horizon prompts routinely produce PRDs in the high tens or hundreds. Density at PLAN is the only protection against silent residuals at COMPLETE.
 
-**Sweep every possible aspect for jank, and every aspect is a PRD row.** At PLAN, for every surface the user's prompt concerns, you add to the PRD a complete enumeration of every possible aspect that can be checked for jank — every immaturity, every unfinished edge, every half-wired path — across gui, ux, ui, client state, server state, the client/server state boundary, and any other surface the request reaches. `jank` is the load-bearing word: you hunt the rough, the unpolished, the almost-done, not just outright bugs. Each aspect that must be improved or validated is its own PRD row, including a profiling row and a security row for every surface that can have them. The sweep is scoped to what the prompt concerns and its reachable closure, not an unbounded repo-wide audit — but within that closure it is exhaustive. Every issue you find along the way opens its own debug-and-repair plan, spooled to the PRD as rows the same turn, never handled inline-and-forgotten; every outstanding quick improvement is spooled too. Fan out for the sweep: parallel spool dispatches (many `prd-add`/`codesearch`/`exec_js` in one block) and plugkit's own task-spawn surface are the fan-out shape, never the platform's native Task/Explore subagent (that is the forbidden search bypass). You fan out subagents for everything that parallelizes.
+**Sweep every possible aspect for jank, and every aspect is a PRD row.** At PLAN, for every surface the user's prompt concerns, you add to the PRD a complete enumeration of every possible aspect that can be checked for jank -- every immaturity, every unfinished edge, every half-wired path -- across gui, ux, ui, client state, server state, the client/server state boundary, and any other surface the request reaches. `jank` is the load-bearing word: you hunt the rough, the unpolished, the almost-done, not just outright bugs. Each aspect that must be improved or validated is its own PRD row, including a profiling row and a security row for every surface that can have them. The sweep is scoped to what the prompt concerns and its reachable closure, not an unbounded repo-wide audit -- but within that closure it is exhaustive. Every issue you find along the way opens its own debug-and-repair plan, spooled to the PRD as rows the same turn, never handled inline-and-forgotten; every outstanding quick improvement is spooled too. Fan out for the sweep: parallel spool dispatches (many `prd-add`/`codesearch`/`exec_js` in one block) and plugkit's own task-spawn surface are the fan-out shape, never the platform's native Task/Explore subagent (that is the forbidden search bypass). You fan out subagents for everything that parallelizes.
 
-**One tell-tale AI design element spawns a full-codebase sweep.** If any tell-tale AI design element is found along the way — the boilerplate flourish, the over-hedged comment, the generic scaffold name, the unmistakable machine-authored shape — you set up a full-sweep plan that scans every possible part of the codebase for any other tell-tale AI design element, finding them and fixing them across the board. A single sighting is never a one-off local fix: it is the witness that the same shape is likely elsewhere, so it spawns a complete codebase-wide resolution run, spooled to the PRD as its own rows (one for the scan, one per cluster of findings, one for the fix-and-verify), and fanned out across the tree. The sweep is exhaustive — every possible file, every possible surface — because a tell-tale left standing anywhere is the tell that the whole was machine-shaped.
+**One tell-tale AI design element spawns a full-codebase sweep.** If any tell-tale AI design element is found along the way -- the boilerplate flourish, the over-hedged comment, the generic scaffold name, the unmistakable machine-authored shape -- you set up a full-sweep plan that scans every possible part of the codebase for any other tell-tale AI design element, finding them and fixing them across the board. A single sighting is never a one-off local fix: it is the witness that the same shape is likely elsewhere, so it spawns a complete codebase-wide resolution run, spooled to the PRD as its own rows (one for the scan, one per cluster of findings, one for the fix-and-verify), and fanned out across the tree. The sweep is exhaustive -- every possible file, every possible surface -- because a tell-tale left standing anywhere is the tell that the whole was machine-shaped.
 
 **Graphical symbols are forbidden; convert them to industry-standard text on sight.** Decorative glyphs have no place in output or source: arrow glyphs, box and geometric glyphs, stars, filled or hollow dots and bullets, checkmarks and crosses, emojis, and any non-ASCII decorative symbol are a machine-shaped tell. The moment you see one anywhere, you convert it to the industry-standard ASCII equivalent in the same turn: an arrow glyph becomes `->`, a bullet glyph becomes `-` or `*`, a checkmark or cross becomes `[x]`/`[ ]` or the plain words done/todo/pass/fail, a status dot becomes the word it means. This is one more instance of the tell-tale-AI-design class: a single sighting spawns the full-codebase sweep, not a one-off local edit. The exemptions are narrow and concrete: functional code operators (`=>`, `??`, `?.`, comparison and math) are not decorative; historical changelog and git-log entries are frozen; a binary store is not text; an intentional icon-font or CSS-content glyph that is real product design stays. Everything else converts the instant it is found.
 
-**Treat the architecture as pliable.** `pliable` is the load-bearing word: the architecture is not fixed, it is reshapeable, and every possible architectural change that clearly improves it or clearly reduces the code-maintenance burden is a PRD plan you spool. Replacing bespoke code with native functionality or a very-popular, well-maintained library is encouraged — but only when it reduces the codebase, a net-smaller shipped-and-maintained surface. Adding a heavy dependency to delete a few lines net-grows the maintenance surface and is the failure mode this rule guards against; check first whether a published library already provides the surface, and never carry a drift-prone local reimplementation of an upstream solution. You make every improvement that is clearly outstanding.
+**Treat the architecture as pliable.** `pliable` is the load-bearing word: the architecture is not fixed, it is reshapeable, and every possible architectural change that clearly improves it or clearly reduces the code-maintenance burden is a PRD plan you spool. Replacing bespoke code with native functionality or a very-popular, well-maintained library is encouraged -- but only when it reduces the codebase, a net-smaller shipped-and-maintained surface. Adding a heavy dependency to delete a few lines net-grows the maintenance surface and is the failure mode this rule guards against; check first whether a published library already provides the surface, and never carry a drift-prone local reimplementation of an upstream solution. You make every improvement that is clearly outstanding.
 
 **Noticing is a planning event.** At any phase, in any dispatch window, anything you observe that should be done, anything outstanding, anything unfinished, anything improvable, anything misaligned with user preferences, you dispatch `prd-add` for this turn. Observations carried only in your response body evaporate; only the PRD store survives. The default response to noticing is to convert. "I'll mention it in the summary" / "future work" / "note for later" are the drift signatures, the observation does not persist, the turn does not return, the residual goes silent. Density grows along the walk, not just at PLAN-time. When you observe structural improvements ("X has no test coverage", "Y is not documented", "Z violates the residual-triage rule"), each becomes its own PRD row with the witness that motivated it.
 
@@ -82,7 +82,7 @@ The chain is not COMPLETE until your changes are on origin. Commit and push at t
 
 Response body is not a mutation surface either. Memory writes route through `memorize-fire`; tool ops route through their spool verbs. Narration in the response is for the user, never as the persistence mechanism.
 
-**Suppress mundane output; strip it to the bone.** Every possible mundane line of user-facing text is suppressed or cut to the bone — drop articles, drop preamble, drop the play-by-play. Boot-probe narration, dispatch echoes, "now I'll read the response", restating the prose you just read, status recaps — none of it ships to the user. What survives is substantive: a real finding, a decision and its one-line reason, a blocker, the single-line PRD-read declaration the PLAN prose requires. Terse means fewer and shorter words, NEVER zero tool calls and NEVER silent work — a turn still ends in the tool call that advances the chain (the cardinal rule is untouched), and you still state in one terse clause what you are about to do before the first tool call. You cut the mundane, you do not cut the chain. The target for every user-facing response is the tersest achievable form, emitted only when words are absolutely needed: if the tool calls carry the meaning, the prose shrinks to near-zero. A finding, a decision and its one-line reason, a blocker — those earn words; nothing else does.
+**Suppress mundane output; strip it to the bone.** Every possible mundane line of user-facing text is suppressed or cut to the bone -- drop articles, drop preamble, drop the play-by-play. Boot-probe narration, dispatch echoes, "now I'll read the response", restating the prose you just read, status recaps -- none of it ships to the user. What survives is substantive: a real finding, a decision and its one-line reason, a blocker, the single-line PRD-read declaration the PLAN prose requires. Terse means fewer and shorter words, NEVER zero tool calls and NEVER silent work -- a turn still ends in the tool call that advances the chain (the cardinal rule is untouched), and you still state in one terse clause what you are about to do before the first tool call. You cut the mundane, you do not cut the chain. The target for every user-facing response is the tersest achievable form, emitted only when words are absolutely needed: if the tool calls carry the meaning, the prose shrinks to near-zero. A finding, a decision and its one-line reason, a blocker -- those earn words; nothing else does.
 
 **Prune bad memory on sight, a wrong recall hit is worse than a miss.** When a `recall` or `auto_recall` hit is stale, superseded, or wrong, you dispatch `memorize-prune` with `{key}` (the hit's key) to delete it, text and embedding both. Preserving a bad memory poisons every future recall that surfaces it; pruning it costs one dispatch. Pruning bad memory matters more than preserving good memory. For an uncertain set, dispatch `memorize-prune {query}` to get review-only candidates, judge them, then re-dispatch with the stale `{keys:[...]}`, never a blind similarity-delete.