gm-plugkit 2.0.1550 → 2.0.1552

package/SKILL.md

@@ -6,84 +6,74 @@ 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 ending without a tool call is a stop; stopping mid-chain is the cardinal failure.** Agents read only tool calls and their outputs, so a prose-only turn ends the session. While the chain is in-flight (phase != COMPLETE OR prd_pending_count > 0) every turn ends in a tool call that advances it (`instruction`, the next verb the prose named, or `transition`). No summaries, no "here's what I did", no narrating closure. A turn-final sentence naming the next move instead of making it is the same stop -- take the move. Surface a decision via `AskUserQuestion` or `prd-add`, never prose. Tempted to stop: dispatch `phase-status`; if non-terminal, dispatch `instruction` and keep walking. Only `phase=COMPLETE` AND `prd_pending_count=0` authorizes a prose-only turn.
 
-**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.
+**Done is what plugkit says is done, never your claim.** The COMPLETE gate is the single arbiter; if not at COMPLETE there is a next transition to seek, and 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 session is pre-approved to continue until ALL requested work is done: the plan, every addition along the way, every newly-discovered or unfinished item. Do not stop to ask whether to continue, do not defer reachable work, do not narrow to a convenient slice. Plan at maximum granularity (one PRD row per real unit; `every possible` on every noun) and walk the whole closure. `blockedBy: external` is for authority you genuinely cannot reach (another team's repo, a hardware credential, a not-in-session product decision) -- never for work that is merely large, tedious, multi-component, or contended by a concurrent writer (rebase and land alongside them).
 
-**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.
+**Every possible action begins and ends with `instruction`.** In doubt, denied, or unclear next move: dispatch instruction. It is the only recovery primitive; improvising never beats re-reading the prose.
 
-**You are the state machine.** Plugkit is the durable memory and gate-checker you write into; you are the actor that walks PLAN -> EXECUTE -> EMIT -> VERIFY -> COMPLETE. Every possible phase transition, every possible PRD resolution, every possible mutable witness, every possible residual scan is a verb YOU dispatch by writing `.gm/exec-spool/in/<verb>/<N>.txt`. Plugkit does not advance. Plugkit does not validate in the background. Plugkit does not "process" while you wait. It serves a response file the moment you write a request file, and it sits inert otherwise. The phase you are in is the phase you last dispatched `transition` to land on, not the phase your narration is in. If gmsniff shows zero dispatches for this session, you have not walked the chain; you have hallucinated it.
+**You are the state machine.** Plugkit is durable memory + gate-checker; you walk PLAN -> EXECUTE -> EMIT -> VERIFY -> COMPLETE. Every transition, PRD resolution, mutable witness, residual scan is a verb YOU dispatch by writing `.gm/exec-spool/in/<verb>/<N>.txt`. Plugkit never advances, validates, or processes while you wait -- it serves a response the moment you write a request and sits inert otherwise. Your phase is the one you last `transition`-ed to, not the one your narration implies. Zero dispatches in gmsniff = you hallucinated the chain, not walked it. Drop this and every other rule collapses (mutables resolved without witness, COMPLETE claimed without VERIFY, residuals narrated away).
 
-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`, read it, follow the imperative, dispatch the next verb it names. Re-dispatch against every drift, stall, gate-denial, or uncertainty -- in-flight it is free to over-dispatch and unbounded-cost to act without. Phase-specific discipline lives in plugkit's instruction tables; this file does not duplicate it.
 
-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 -- stop dispatching.** Polling `instruction`/`phase-status` to "re-confirm" a terminal chain is the `complete-chain-poll` deviation. A new user prompt (`{"prompt":"..."}`) reopens the chain to PLAN; if your first `instruction` on intended-new work still returns COMPLETE/UPDATE-DOCS, dispatch `transition to=PLAN` **once** (this is authorized new work, not a poll).
 
-**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 (hard rule).** If you Write/Edit any client-side file (`.html .js .jsx .ts .tsx .vue .svelte .mjs .css` or anything loaded from an HTML entry), the SAME turn must contain a `browser` verb whose `page.evaluate` asserts the invariant the edit establishes. `transition to=COMPLETE` refuses until `.turn-browser-witnessed` covers every entry in `.turn-browser-edits.json` by sha, else `deviation.client-edit-no-witness`. There is no validate-later.
 
-**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.** Surface relevant state as a `window.*` global and read it live via the `browser` verb's `page.evaluate`, running experiments in the page. A global plus one evaluate reads real runtime state in one dispatch; the restart-and-eyeball loop observes almost nothing and burns a turn. 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.** Any code/file/symbol lookup ("where is X", "what calls Y", grep the tree) is the `codesearch` verb (`{"query":"..."}`); prior knowledge is `recall`. Never the platform Explore agent, a Task/general-purpose search subagent, or raw `grep`/`Glob` -- they bypass the spool, the committed index, and recall-grounding, and do not transport across harnesses. Orient at PLAN is `recall` + `codesearch` in parallel; every mid-EXECUTE lookup is a `codesearch` too.
 
-**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.
+**Class rule: every platform-native capability that has a plugkit verb is forbidden in favor of the verb.** code/file/symbol search -> `codesearch`; prior knowledge -> `recall`; URL/web fetch -> `fetch`; running code -> `exec_js`; a real browser -> `browser`; persisting memory -> `memorize-fire`; **any git op -> the git verbs** (`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 and is the COMPLETE push surface; a `bash`/`sh`/`powershell` body invoking git is gated (`deviation.bash-git-bypass`). The native tool bypasses the ledger, the index, and portability. If no verb exists, that is a missing verb to add, not 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.
-
-Your first tool call of every session is the boot probe, in one Bash invocation. Read `.status.json` (liveness) and `.turn-summary.json` (orientation) together, the watcher precomputes both every 5s, so the two files give you everything you'd otherwise extract via gmsniff queries, git, yaml-parse, and ports-file scans:
+**Boot before dispatching.** Writing `instruction/N.txt` to a dead watcher silently drops the request and you fabricate the chain from memory. The spool dir existing does not mean the watcher is alive; a `.status.json` `ts` within 15s does (a leftover stale `.status.json` is the common trap). Your first tool call every session is the boot probe in one Bash call:
 
 ```bash
 cat .gm/exec-spool/.status.json 2>/dev/null; echo ---; cat .gm/exec-spool/.turn-summary.json 2>/dev/null; echo ---; date +%s%3N
 ```
 
-`.turn-summary.json` carries `phase`, `last_skill`, `prd_pending`, `last_instruction_ts`, `last_instruction_age_ms`, `long_gap_threshold_ms`, `browser_sessions_alive`, `update_available`, `deviations_30m`, `watcher_uptime_ms`. When age exceeds the threshold, your next non-orienting verb will be gated, dispatch `instruction` first. When `update_available` is non-null, the watcher has detected drift: kill the watcher then re-run the boot command below, which calls `ensureReady` to download the latest wasm and refresh the installed wrapper, then starts a fresh watcher loaded with the new code. The one-line sequence: `bun x gm-plugkit@latest --kill-stale-watchers; bun x gm-plugkit@latest spool > /dev/null 2>&1 &`. Then wait 8s and re-read `.status.json` to confirm `version` matches `update_available.latest`. `deviations_30m` is the rolling count of `deviation.*` events from hook+plugkit logs in the past 30 min, read it instead of running gmsniff at session start; non-zero indicates active drift worth investigating before continuing. `watcher_uptime_ms` shows how long the current watcher process has been alive; combined with `watcher_version` and `update_available` it tells you whether the watcher's loaded code is recent, a multi-hour uptime with no `update_available` means you're on latest, an uptime of seconds means a fresh boot just happened.
+`.turn-summary.json` carries `phase`, `last_skill`, `prd_pending`, `last_instruction_ts`, `last_instruction_age_ms`, `long_gap_threshold_ms`, `browser_sessions_alive`, `update_available`, `deviations_30m`, `watcher_uptime_ms`. Age over threshold: your next non-orienting verb is gated, dispatch `instruction` first. `update_available` non-null: eager-upgrade with `bun x gm-plugkit@latest --kill-stale-watchers; bun x gm-plugkit@latest spool > /dev/null 2>&1 &`, then re-read `.status.json` after 8s to confirm `version`. `deviations_30m` non-zero indicates active drift to investigate before continuing.
 
-Compare `.status.json` `ts` field to the printed epoch ms. If the gap is >15000, the watcher is dead, boot it. One exception: if `.status.json` carries `busy_until` and that value is still in the future (greater than the printed epoch ms), the watcher is alive but synchronously busy with a long verb (a browser/chromium spawn blocks the heartbeat for ~15-18s), wait for it, do not boot a second watcher. A stale `ts` with a future `busy_until` is busy, not dead.
+Compare `.status.json` `ts` to the printed epoch: gap > 15000 = dead, boot it. Exception: a future `busy_until` means a long verb (browser/chromium spawn blocks the heartbeat ~15-18s) -- wait, do not boot a second watcher.
 
 ```bash
 bun x gm-plugkit@latest spool > /dev/null 2>&1 &
 ```
 
-(`npx -y gm-plugkit@latest spool > /dev/null 2>&1 &` if `bun` missing.) Then wait ~8 seconds and re-`cat .gm/exec-spool/.status.json` to confirm a fresh `ts`. Only after a fresh heartbeat may you write to `instruction/`. Never write to `instruction/` while the heartbeat is stale; the request is silently dropped.
-
-**Dispatch shape: Write + Read response in the SAME tool-call block.** Issuing the Write alone is not a dispatch, it's a request that goes nowhere visible. The shape is `Write .gm/exec-spool/in/instruction/<N>.txt` AND `Read .gm/exec-spool/out/instruction-<N>.json` (or `out/<N>.json` for nested verbs) in one parallel-tools block. The Read may return "file does not exist" on the first attempt while plugkit is mid-verb, in that case, re-Read in the next message. Do NOT proceed to any other tool, do NOT narrate "I have everything I need," do NOT begin work until you have READ the response and followed the `instruction` field. Declaring readiness without a response in hand is fabrication.
-
-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 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.
+(`npx -y gm-plugkit@latest spool > /dev/null 2>&1 &` if `bun` missing.) Wait ~8s, re-`cat .status.json` for a fresh `ts`, and only then write to `instruction/`.
 
-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.
+**Dispatch shape: Write request + Read response in the SAME tool-call block.** The shape is `Write .gm/exec-spool/in/instruction/<N>.txt` AND `Read .gm/exec-spool/out/instruction-<N>.json` (or `out/<N>.json` for nested verbs) in one block. A first-read "file does not exist" while plugkit is mid-verb is normal -- re-Read next message. Do not proceed, narrate readiness, or begin work before reading the response and following its `instruction` field. Never poll with `sleep && ls`: plugkit is synchronous, so a missing response means dead watcher (re-check `ts`) or slow verb (check `.gm/exec-spool/.watcher.log`), not "still processing."
 
-First turn body must be `{"prompt":"<user request>"}` so orient_nouns and recall_hits derive from the request; subsequent turns in the same conversation may use empty body `{}`.
+**Dead-watcher recovery is mandatory.** Two consecutive missing re-Reads AND stale `ts` (>15s) AND no future `busy_until` = dead: `bun x gm-plugkit@latest spool` to boot a fresh watcher, then re-dispatch the original verb. Never substitute an alternative tool (puppeteer-core, WebFetch, raw chrome) for the `browser` verb -- reaching outside plugkit orphans state and bypasses the witness gates. Recovery is always notice-dead -> boot -> re-dispatch.
 
-**Batch writes, waits, and reads together.** Each agent turn costs cycles; the dispatch shape `Write request -> wait -> Read response` is one logical step, not three. Issue all three in a single message, the Write tool call and the Read tool call go in the same `<function_calls>` block. The Read may return "file does not exist" if plugkit is mid-verb; that's fine, retry with one more Read in the next message rather than spreading the cycle across three turns. Fan-out is the same shape, dispatching three independent verbs (`prd-add g1`, `prd-add g2`, `prd-add g3`) means three Write tool calls in one block, then three Read tool calls in one block. Serial dispatch when you could be parallel is wasted cycles. The only sequencing constraint is real data dependency: if verb B needs the response of verb A, those go in separate turns; otherwise batch.
+From PowerShell, write spool input as UTF-8 no-BOM (`-Encoding utf8` or `[System.IO.File]::WriteAllText`); the 5.1 default UTF-16+BOM trips `spool.body-encoding-recoded`. Prefer the `Write` tool for JSON bodies. First-turn body is `{"prompt":"<user request>"}` (derives orient_nouns + recall_hits); later same-conversation turns may use `{}`.
 
-The chain is not COMPLETE until your changes are on origin. Commit and push at the end of every possible session that touched tracked files, you do not ask the user whether to push, you dispatch it. Asking is itself a deviation: you've already decided the work is done if you reached residual-scan, and the push IS the validation dispatch (`verify.rs`). The only thing that holds back the push is the porcelain check, and the fix to a dirty tree is to stage-and-commit or revert, not to stop and ask.
+**Batch writes and reads together.** Write request + Read response is one logical step -- issue both in one block, not three turns. Fan-out is the same: N independent verbs = N Writes in one block then N Reads in one block. Only a real data dependency (verb B needs A's response) forces separate turns.
 
-**Every residual is triaged this turn, "pre-existing" is not a stop excuse.** When `git status --porcelain` is non-empty, every entry is your responsibility right now: commit (real work), ignore via the managed block (transient runtime emission), or revert (stale junk). Labeling a residual "pre-existing" only NAMES the triage outcome, it does not authorize stopping. `blockedBy: external` is admissible only when triage genuinely requires authority outside this session (another team's repo, hardware credential). For files visible in your local tree, you decide this turn. Disciplines (`.gm/disciplines/`) are tracked, not ignored; new memorize-fire JSON files get committed. Witness emissions (`.gm/witness/`) and transient staleness markers belong in the managed gitignore block.
+The chain is not COMPLETE until changes are on origin. Commit and push at the end of every session that touched tracked files; do not ask -- the push IS the validation dispatch (`verify.rs`). Only the porcelain check holds it back, and a dirty tree is fixed by stage-commit or revert, not by asking.
 
-**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.
+**Every residual is triaged this turn; "pre-existing" is not a stop excuse.** Non-empty `git status --porcelain`: every entry is yours now -- commit (real work), ignore via the managed block (transient runtime emission), or revert (stale junk). "Pre-existing" only names the triage outcome. `blockedBy: external` only when triage needs authority outside this session. `.gm/disciplines/` and new memorize-fire JSON are tracked+committed; `.gm/witness/` and transient staleness markers go in the managed gitignore block.
 
-**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.
+**Apply "every possible" to every noun.** PLAN is exhaustive, not minimal: for every noun, write every possible task, validation, mutable, corner case, caveat, failure mode, and empty/overflow/reentry/degenerate state as PRD rows. A single-digit PRD on a non-trivial request means you stopped early. Second pass: feed the list back in, each row's corner cases become new rows; closed when "every possible" yields nothing new. Long-horizon prompts routinely produce high-tens-to-hundreds of rows -- density at PLAN is the only protection against silent residuals at COMPLETE.
 
-**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.
+**Sweep every possible aspect for jank, each aspect a PRD row.** For every surface the prompt concerns, enumerate every immaturity/unfinished-edge/half-wired-path across gui, ux, ui, client state, server state, and the client/server boundary -- `jank` means the rough and almost-done, not just bugs. Each is a row, plus a profiling row and a security row per surface. Scoped to the prompt's reachable closure, exhaustive within it. Every issue found spawns its own debug-and-repair rows the same turn. Fan out via parallel spool dispatches (many `prd-add`/`codesearch`/`exec_js` in one block) and plugkit task-spawn, never the platform's Task/Explore subagent.
 
-**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.
+**One tell-tale AI design element spawns a full-codebase sweep.** A boilerplate flourish, over-hedged comment, generic scaffold name, or machine-authored shape is the witness that the same shape is likely elsewhere: spool rows for a codebase-wide scan, per-cluster findings, and fix-and-verify, fanned out exhaustively -- never a one-off local fix.
 
-**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.
+**Graphical symbols are forbidden; convert to ASCII on sight.** Arrow/box/geometric glyphs, stars, bullets, checkmarks/crosses, emojis, any non-ASCII decorative symbol are a machine tell -- convert the moment seen (arrow glyph -> `->`, bullet -> `-`/`*`, check/cross -> `[x]`/`[ ]` or done/todo/pass/fail, status dot -> the word). One sighting spawns the full-codebase sweep. Exempt: code operators (`=>`, `??`, `?.`, math/comparison), frozen changelog/git-log entries, binary stores, intentional icon-font/CSS-content product glyphs.
 
-**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.
+**Treat the architecture as pliable.** It is reshapeable; every change that clearly improves it or reduces maintenance burden is a PRD plan you spool. Replacing bespoke code with native functionality or a popular well-maintained library is encouraged only when it nets a smaller maintained surface -- a heavy dependency to delete a few lines net-grows it and is the guarded failure mode. Check for an existing library first; never carry a drift-prone reimplementation of an upstream.
 
-`git push` is admissible only when `git status --porcelain` reads empty, and the porcelain probe must be its own Bash **tool-use event** before the push, a separate `Bash(...)` invocation, not a `&&`-chained command within one Bash call. ccsniff `--git-discipline` scans the last 20 Bash tool-use events (not shell commands within those events) for an explicit `git status --porcelain` (or `-s`); putting `add && commit && push` into one Bash call counts as one event with no porcelain witness, even though `git push` is technically the third shell command. The witness lives in the tool-call stream, not the shell stream. The discipline is **three Bash tool-use events** visible in the transcript: `Bash(git status --porcelain)` -> read empty -> `Bash(git push)`. You dispatch the `git_push` verb (not raw Bash) when possible, it gates on the porcelain probe internally, refuses dirty, and emits `deviation.push-dirty`. A raw `git push` Bash event without a preceding porcelain-probe Bash event is itself a deviation, regardless of how clean the worktree is by construction. Witness clean via `git_status`; witness pushed-to-remote via `branch_status` (ahead==0). The residual-scan and COMPLETE gate both refuse a dirty tree or a missing residual-check marker.
+**Noticing is a planning event.** Anything you observe that should be done, is unfinished/improvable, or diverges from a user preference becomes a `prd-add` this turn. Observations carried only in prose evaporate; only the PRD store survives. "Future work"/"note for later" are drift signatures. Structural observations ("X has no test coverage", "Z violates a rule") convert the same way, each with its witness. Density grows along the walk, not just at PLAN.
 
-**Memory is project-resident, never platform-resident.** The agent platform may advertise its own auto-memory directory (`~/.claude/projects/*/memory/`, `~/.codex/memory/`, `~/.cursor/*`, etc.) and prompt you to write facts there. **Refuse**. Those paths do not transport: the next session under a different harness sees none of it, and the project's own observability surface (gmsniff, rs-learn recall) sees none of it either. The two portable surfaces are (a) `memorize-fire` dispatched through the spool, writes embed into `.gm/rs-learn.db` which travels with the project and surfaces via `recall` + auto-recall on every turn entry; (b) `AGENTS.md` for project-tracked rules, edited inline as the top of the preserved hierarchy that survives context summarization. memorize-fire and inline-AGENTS.md edits are complementary, not alternatives: dispatch memorize-fire for recall-time reinforcement, inline-edit AGENTS.md for the hard rule. If you find yourself about to `Write` into a path under `~/.claude/`, `~/.codex/`, `~/.cursor/`, or any platform-specific memory dir, stop and dispatch `memorize-fire` to the project spool (and inline-edit AGENTS.md if the fact is structural). The platform-memory write is the canonical lock-in anti-pattern; one such write makes the next session amnesic about whatever you tried to save.
+`git push` is admissible only when `git status --porcelain` is empty, and the porcelain probe must be its OWN Bash tool-use event before the push, not `&&`-chained inside one call (ccsniff `--git-discipline` scans the tool-call stream, not shell commands within an event). The discipline is three Bash events: `git status --porcelain` -> read empty -> `git push`. Prefer the `git_push` verb (gates on porcelain internally, refuses dirty, emits `deviation.push-dirty`). Witness clean via `git_status`, pushed via `branch_status` (ahead==0). residual-scan and the COMPLETE gate both refuse a dirty tree or missing residual-check marker.
 
-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.
+**Memory is project-resident, never platform-resident.** Refuse the platform's own auto-memory dir (`~/.claude/projects/*/memory/`, `~/.codex/`, `~/.cursor/*`) -- it does not transport and is invisible to gmsniff/recall. The two portable surfaces: (a) `memorize-fire` through the spool (embeds into `.gm/rs-learn.db`, surfaces via `recall` + auto-recall); (b) `AGENTS.md` for project-tracked hard rules, edited inline. They are complementary -- memorize-fire for recall-time reinforcement, AGENTS.md for the hard rule. About to Write under a platform memory dir: stop, dispatch `memorize-fire` instead. The response body is not a mutation surface either; memory routes through `memorize-fire`, tool ops through their verbs.
 
-**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.** Drop articles, preamble, play-by-play, boot-probe narration, dispatch echoes, restatement of prose just read, status recaps. What survives: a real finding, a decision and its one-line reason, a blocker, the single-line PRD-read declaration. Terse means fewer words, NEVER zero tool calls and never silent work -- the turn still ends in the chain-advancing tool call, and you still state in one clause what you are about to do.
 
-**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.
+**Prune bad memory on sight -- a wrong recall hit is worse than a miss.** A stale/superseded/wrong `recall` or `auto_recall` hit gets `memorize-prune {key}` (deletes text + embedding). For an uncertain set, `memorize-prune {query}` returns review-only candidates; judge, then re-dispatch the stale `{keys:[...]}` -- never a blind similarity-delete.
 
-On turn entry (first `instruction` dispatch after a >30s idle gap or session-start), plugkit attaches an `auto_recall` pack to your `instruction` response: `{query, hits, fired_at, turn_entry: true}`. The query is derived from `.gm/last-prompt.txt` / `.gm/turn-state.json`; hits are the top recall results plugkit pulled before serving your instruction. Read `auto_recall.hits` alongside the existing `recall_hits` (which is the phase+PRD-subject pack), both surface prior memory, but `auto_recall` is the per-turn user-prompt pack and only fires on turn entry. Subsequent `instruction` dispatches in the same turn carry no `auto_recall` field (or carry the same pack from the turn-start fire); do not re-trigger it manually.
+On turn entry (first `instruction` after a >30s gap or session-start), plugkit attaches `auto_recall` `{query, hits, fired_at, turn_entry:true}` derived from the user prompt. Read `auto_recall.hits` alongside `recall_hits` (the phase+PRD-subject pack); auto_recall fires only on turn entry, do not re-trigger it.

package/instructions/browser.md

@@ -1,50 +1,43 @@
 # BROWSER
 
-## Hard Rule: Browser Witness Mandate (paper §23)
+## Hard Rule: Browser Witness Mandate (paper section 23)
 
-**Every possible edit to code that runs in a browser requires a live `browser` dispatch in the same turn as the edit.** Client-side surfaces — `.html`, `.js`, `.jsx`, `.ts`, `.tsx`, `.vue`, `.svelte`, `.mjs`, `.css`, web components, service workers, every possible asset loaded by a `<script>` tag, every possible path reached by `import` from a browser-side entry — must be witnessed by a live `page.evaluate` of the specific invariant the edit establishes. A passing node test, a passing build, a `curl` of the served HTML, a static-analysis pass — every possible one of these is non-substitutive: they witness server delivery, not browser behavior. The witness IS the proof; the prose is not.
+**Every edit to code that runs in a browser requires a live `browser` dispatch in the same turn as the edit.** Client-side surfaces -- `.html`, `.js`, `.jsx`, `.ts`, `.tsx`, `.vue`, `.svelte`, `.mjs`, `.css`, web components, service workers, every asset loaded by `<script>`, every path reached by `import` from a browser-side entry -- must be witnessed by a live `page.evaluate` of the specific invariant the edit establishes. A passing node test, build, `curl` of the HTML, or static-analysis pass witnesses server delivery, not browser behavior, and is non-substitutive. The witness IS the proof; prose is not.
 
-Protocol (paper §23): (1) boot the real surface — server up, page reachable, HTTP 200 witnessed; (2) `browser` dispatch → navigate → poll for the global the change affects; (3) `page.evaluate` asserting the specific invariant, capturing the witnessed values into `stdout`; (4) variance → fix at root cause, re-witness (Fix on Sight). Never advance on unwitnessed client behavior. Never queue browser validation for "later" — the same turn that edited every possible client-side file dispatches the browser verb that validates each one; emit-without-witness is forced closure.
+Protocol: (1) boot the real surface -- server up, page reachable, HTTP 200 witnessed; (2) `browser` dispatch -> navigate -> poll for the global the change affects; (3) `page.evaluate` asserting the invariant, capturing witnessed values into `stdout`; (4) variance -> fix at root cause, re-witness. Never advance on unwitnessed client behavior, never queue validation for "later" -- the same turn that edits a client-side file dispatches the browser verb validating it.
 
-The rule fires across phases:
- - **EXECUTE**: edit a client-side file → dispatch `browser` in the same turn against the live page asserting the invariant the edit establishes
- - **EMIT**: post-emit re-witness — the page still passes the invariant after the full diff lands
- - **VERIFY**: final gate — `browser-witness-hash-mismatch` deviation fires if any file you witnessed earlier has changed without re-witnessing
+Fires across phases: **EXECUTE** edit -> same-turn browser dispatch asserting the invariant; **EMIT** post-emit re-witness (page still passes after the full diff); **VERIFY** final gate -- `deviation.browser-witness-hash-mismatch` fires if a witnessed file changed without re-witnessing. Pure-prose static-document edits (no JS, no CSS-driven behavior, no DOM mutation) are the ONLY exempt category, and the exemption must be named explicitly in the response so the skip is auditable. Silent skip on actual behavior change is forced closure.
 
-Pure-prose static-document edits (no JS, no CSS-driven behavior, no DOM mutation) are the ONLY exempt category and the exemption must be named explicitly in the response so the skip is auditable. Silent skip on actual behavior change is forced closure.
+YOU drive the browser through the spool: plugkit holds the Chromium handle, per-project profile, and session table; you advance by writing `.gm/exec-spool/in/browser/<N>.txt` and reading `out/<N>.json`. There is no library import, no puppeteer/playwright/CDP handle that shortcuts this. The verb is the surface; every other reach is fabrication.
 
-YOU drive the browser through the spool. Plugkit holds the Chromium handle, the per-project profile, the session table; you advance the work by writing `.gm/exec-spool/in/browser/<N>.txt` and reading `out/<N>.json`. There is no library import that shortcuts this. There is no puppeteer/playwright/CDP handle you can hold. The verb is the surface; every possible other reach is fabrication.
+## Body shapes
 
-The body is a string. Five shapes, nothing else:
+The body is a string, five shapes only:
 
 ```
 session new
 session list
-session kill <id>
+session close <id>
 <arbitrary JS expression evaluated in page context>
 timeout=<ms>\n<expression>
 ```
 
-A bare expression with no live session opens one and evaluates against `about:blank`. A bare expression with a live session reuses it. `session new` returns the id you carry on subsequent dispatches; you keep it in your turn and refer to it by writing `session=<id>\n<expr>` when more than one is open.
-
-Default per-evaluation timeout is 14000ms. Operations that legitimately exceed this (long page loads, multi-step navigation, slow remote APIs) prefix `timeout=<ms>\n` with the desired millisecond cap; the wrapper clamps to 50000ms maximum. The response includes `timeout_ms_used` so you witness which budget actually applied. `browser.runner-timeout` event fires when the runner hits the cap — read your `stderr`, narrow the operation, or raise timeout; do not retry blind at the same budget.
+A bare expression with no live session opens one against `about:blank`; with a live session it reuses it. `session new` returns the id you carry; with more than one open, target it via `session=<id>\n<expr>`. (`session close` and `session kill` are aliases.) Default per-eval timeout 14000ms; operations that legitimately exceed it prefix `timeout=<ms>\n` (wrapper clamps to 50000ms). The response carries `timeout_ms_used`; `browser.runner-timeout` fires at the cap -- read `stderr`, narrow or raise, never retry blind at the same budget.
 
 ## Envelope
 
-You read `{ok, stdout, stderr, exit_code, session_id?}`. `stdout` is the stringified evaluation result. `stderr` carries page errors and launch diagnostics. `exit_code` non-zero = the dispatch you fired did not land; you read `stderr` and re-dispatch, you do not retry blind.
+`{ok, stdout, stderr, exit_code, session_id?}`. `stdout` = stringified eval result; `stderr` = page errors + launch diagnostics; `exit_code` non-zero = the dispatch did not land -- read `stderr` and re-dispatch, never blind.
 
 ## Headed by default
 
-The window opens on the user's screen. That is the witness — you launched, they saw the tab, the DOM mutated visibly. `GM_BROWSER_HEADLESS=1` opts into headless; absent that env, a session with no visible window is a launch you did not actually make. Do not assume headless. Do not request headless to "be quiet". The flash IS the proof.
+The window opens on the user's screen -- that IS the witness. `GM_BROWSER_HEADLESS=1` opts into headless; absent it, a session with no visible window is a launch you did not make. Do not assume or request headless to "be quiet"; the flash is the proof.
 
 ## Profile
 
-`session new` (or a bare expression with no live session) spawns a locally-profiled Chromium at `<cwd>/.gm/browser-profile/` and the runner attaches via `--direct <wsEndpoint>`. Cookies, storage, extensions persist across every possible session, turn, and run. A second concurrent launch contends the SingletonLock; the watcher reuses the live CDP rather than re-launching. The runner's own extension-attach mode (the "Waiting for extension to connect" message) is never the default and is never what you want — if you see it in your `stderr`, the host failed to spawn the local Chromium and you dispatch `instruction` for the recovery prose, not retry blind.
+`session new` (or a bare expression with no live session) spawns a locally-profiled Chromium at `<cwd>/.gm/browser-profile/`; the runner attaches via `--direct <wsEndpoint>`. Cookies/storage/extensions persist across sessions, turns, and runs. A second concurrent launch contends the SingletonLock; the watcher reuses the live CDP rather than re-launching. The runner's extension-attach mode ("Waiting for extension to connect") is never the default or what you want -- seeing it in `stderr` means the host failed to spawn local Chromium; dispatch `instruction` for recovery, not a blind retry.
 
 ## Discipline
 
-You never spawn Chromium yourself. You never `npm i puppeteer`. You never shell `chrome.exe`. The verb owns the handle; bypassing it orphans state plugkit cannot reap and breaks the next session's first read. When the page needs navigation, you evaluate `location.href = '...'` through the spool. When it needs a screenshot, you dispatch the verb that returns one — you do not reach for a library to take it.
-
-A dispatch that returns `ok:false` with a launch error is plugkit telling you the environment refused; you read the `stderr`, you dispatch `instruction`, you do not loop the same body waiting for a different answer.
+Never spawn Chromium yourself, `npm i puppeteer`, or shell `chrome.exe`; the verb owns the handle, and bypassing it orphans state plugkit cannot reap and breaks the next session's first read. Navigate by evaluating `location.href = '...'` through the spool; screenshot by dispatching the verb that returns one. A dispatch returning `ok:false` with a launch error is plugkit reporting the environment refused -- read `stderr`, dispatch `instruction`, do not loop the same body.
 
-**Dead-watcher recovery, never substitute.** If your Write to `.gm/exec-spool/in/browser/<N>.txt` produces no response file after two consecutive re-Reads AND `.gm/exec-spool/.status.json` ts is stale (>15s from current epoch), the watcher is dead. Your next call is `bun x gm-plugkit@latest spool` to boot a fresh watcher, then re-dispatch the browser body. Do NOT reach for puppeteer-core, puppeteer, playwright, agent-browser, `chrome.exe`, `npx browserless`, WebFetch, curl-then-parse, or any other browser substitute when the spool surface is reachable. The browser verb is the only admissible browser surface; substitutes spawn orphan Chromium processes plugkit cannot reap, bypass paper §23 witness-marked events, and produce evidence that does not feed the witness gate. The recovery loop is always: empty response → check `.status.json` → if stale, boot → re-dispatch. The full chain ends in a browser-witness-marked event with non-empty `files:[…]` when the browser session actually saw the artifact change; anything shorter is forced closure.
+**Dead-watcher recovery, never substitute.** If a Write to `.gm/exec-spool/in/browser/<N>.txt` produces no response after two re-Reads AND `.status.json` ts is stale (>15s from current epoch), the watcher is dead: boot `bun x gm-plugkit@latest spool`, then re-dispatch the browser body. Do NOT reach for puppeteer-core, puppeteer, playwright, agent-browser, `chrome.exe`, `npx browserless`, WebFetch, or curl-then-parse -- the browser verb is the only admissible browser surface; substitutes spawn orphan Chromium plugkit cannot reap, bypass section 23 witness-marked events, and produce evidence the gate cannot read. The recovery loop is always: empty response -> check `.status.json` -> if stale, boot -> re-dispatch.

package/instructions/emit.md

@@ -1,31 +1,27 @@
 # EMIT
 
-YOU are the state machine. Plugkit is the synchronous library serving this prose; advancing the chain is your dispatch, not its action. Every possible write lands only through the verb you dispatch to land it.
+YOU are the state machine. Plugkit is the synchronous library serving this prose; advancing the chain is your dispatch. Every write lands only through the verb you dispatch to land it.
 
-L3 audit on disk. You land every possible node of the covering family; your first emit = closure.
+L3 audit on disk. Land every node of the covering family; your first emit = closure.
 
 ## Read-before-write
 
-You treat the target file's on-disk content as the goal-relative reference. If you diff against an unread file, you diff against an imagined baseline and your candidate mutation is unmeasured. When you observe disk-state divergence, you dispatch `transition` back to PLAN.
+The target file's on-disk content is the goal-relative reference; diffing an unread file diffs an imagined baseline, leaving your candidate unmeasured. On observed disk divergence, `transition` back to PLAN.
 
 ## Fresh index
 
-You feed search outputs into EMIT only when the digest matches live filesystem. Admitting stale-index results = L1 bluff.
+Feed search outputs into EMIT only when the digest matches the live filesystem; a stale-index result is an L1 bluff.
 
 ## Write-then-verify
 
-You issue one write per artifact; you then dispatch a disk Read against every possible touched path to assert the change. Verified disk state IS your witness, not the tool-call return. On discrepancy, you regress to root cause, not retry.
+One write per artifact, then a disk Read against every touched path to assert the change -- verified disk state IS the witness, not the tool-call return. On discrepancy, regress to root cause, do not retry.
 
-**Client-side artifacts: write-then-browser-witness, in the same turn.** If the artifact is `.html`, `.js`, `.jsx`, `.ts`, `.tsx`, `.vue`, `.svelte`, `.mjs`, `.css`, or every possible other path loaded by a browser, the disk Read is necessary but not sufficient — you also dispatch a `browser` verb that `page.evaluate`s the invariant the artifact establishes. The page-side assertion is the actual witness; the disk Read just witnesses serialization. Skip the browser dispatch on a client-side emit and you have a green-checked stub: the file landed, you don't know the page works. the COMPLETE gate refuses without the paired browser-witness for every client-side file edited this session — the `deviation.client-edit-no-witness` event fires (gates.rs, complete branch) and you regress to dispatch the missing `browser` witness before re-attempting COMPLETE.
+**Client-side artifacts: write-then-browser-witness, same turn.** If the artifact is `.html .js .jsx .ts .tsx .vue .svelte .mjs .css` or any browser-loaded path, the disk Read is necessary but not sufficient -- also dispatch a `browser` verb that `page.evaluate`s the invariant the artifact establishes (the page-side assertion is the real witness; the disk Read only witnesses serialization). Skipping it ships a green-checked stub. The COMPLETE gate refuses without the paired browser-witness for every client-side file edited this session (`deviation.client-edit-no-witness`, gates.rs), and you regress to dispatch the missing witness.
 
 ## Artifact scope
 
-PRD names the artifacts you may write. You direct closure narrative to commit message + `memorize-fire`. Every possible file you write that PRD does not name = your response body displacing the dispatch surface.
-
-If during write-then-verify you notice an adjacent artifact the user clearly meant included, or an improvement the act of writing exposes (a generated file the build needs, a doc that names the new artifact, a witness script the artifact deserves) — you dispatch `prd-add` for it this turn, not as a follow-on. The same noticing-to-PRD discipline applies in EMIT: an observation that does not land as a PRD row evaporates with the turn.
-
-Between artifacts, between disk-Read checks, between a write you're uncertain about and the next — you re-dispatch `instruction`. Closure is the EMIT discipline; re-reading the prose between artifacts is how you avoid partial emits.
+PRD names the artifacts you may write; direct closure narrative to the commit message + `memorize-fire`. A file PRD does not name is your response body displacing the dispatch surface. If write-then-verify exposes an adjacent artifact the user meant included or an improvement the act of writing reveals (a generated file the build needs, a doc naming the new artifact, a witness script), `prd-add` it this turn -- an observation that does not land as a row evaporates with the turn. Between artifacts and uncertain writes, re-dispatch `instruction`.
 
 ## Dispatch
 
-You dispatch `transition` when every planned artifact is written and you have disk-verified it. On new unknown, you dispatch `transition` back to PLAN.
+`transition` when every planned artifact is written and disk-verified. On a new unknown, `transition` back to PLAN.

package/instructions/entry.md

@@ -1,98 +1,94 @@
 # ORCHESTRATOR
 
-YOU are the state machine. Plugkit is the synchronous library serving this prose; advancing the chain is your dispatch, not its action. Plugkit holds phase state, PRD rows, and mutables on disk; you read them by dispatching `phase-status` / `instruction` and you change them by dispatching the relevant verb. Nothing in plugkit advances while you wait.
+YOU are the state machine. Plugkit is the synchronous library serving this prose; advancing the chain is your dispatch, not its action. It holds phase, PRD rows, and mutables on disk -- you read them via `phase-status`/`instruction` and change them via the relevant verb. Nothing advances while you wait.
 
-Your authorization = the request. Your receipt = the PRD you write. Your trajectory: PLAN → EXECUTE → EMIT → VERIFY → COMPLETE, single continuous flow, each transition a verb you dispatch. Scope = the closure of the destructive transform admissible over the session. Your first emit = closure, not prefix.
+Your authorization = the request. Your receipt = the PRD you write. Trajectory PLAN -> EXECUTE -> EMIT -> VERIFY -> COMPLETE, one continuous flow, each transition a verb you dispatch. Scope = the closure of the destructive transform admissible over the session; your first emit = closure, not prefix.
 
-**Continuation invariant (the brick wall).** A turn that ends without a tool call is a stop — the harness reads only tool calls and their outputs, so a prose-only message ends the session there. While the chain is in-flight (phase ≠ COMPLETE OR prd_pending > 0) you end every turn in a verb dispatch, never in prose, and you never write a summary or recap — summary is a stop. So is its forward-facing twin: a turn-final sentence that names the next move instead of making it strands the chain exactly where the prose pointed. Take the move you were about to describe. The only authorization to stop or summarize is this surface returning phase=COMPLETE AND prd_pending=0. Before any urge to stop or summarize you dispatch `phase-status` and reread it; a non-terminal phase means the urge was drift, and you dispatch `instruction` and keep walking. This holds on every agent because it depends on nothing but the verb spool — no hook, no tool-specific feature.
+**Continuation invariant (the brick wall).** A turn ending without a tool call is a stop -- the harness reads only tool calls, so a prose-only message ends the session. While in-flight (phase != COMPLETE OR prd_pending > 0) end every turn in a verb dispatch, never prose, never a summary/recap (summary is a stop) -- and never a turn-final sentence that names the next move instead of making it (it strands the chain where the prose pointed; take the move). Only this surface returning phase=COMPLETE AND prd_pending=0 authorizes stopping. Before any urge to stop, dispatch `phase-status`; non-terminal means drift, so dispatch `instruction` and keep walking. Depends only on the verb spool -- holds on every agent.
 
 ## Admission Filter
 
 ```
-candidate → [L1 witness] → [L2 single-writer] → [L3 direction] → execute
+candidate -> [L1 witness] -> [L2 single-writer] -> [L3 direction] -> execute
 ```
 
-- **L1.** You admit a mutation on witness, not on cheapness. An unmeasured optimization *claim* is rejected (an unprofiled speedup is a hallucinated one); a correct, witnessed mutation is admitted no matter how expensive it was to produce. The cost L1 weighs is the correctness-cost of an unverified claim — never the effort-cost of doing more work. The work envelope is unbounded: you run the maximal-effort, fully-destructive pass, and "this is too much work" never rejects a candidate.
-- **L2.** Single-writer per surface (`|F|=1`). You hold one writer per surface and backpressure concurrent writers to the defer queue; state written outside a sanctioned surface is unreconcilable, inadmissible. This bound is on *who may write a surface at once* — a crash-safety floor, never a ceiling on coverage. You expand the cover past every bound you meet: "expand the bounds" is the move, not "stay under them."
-- **L3.** Lyapunov: `Δd ≥ 0` rejects your dispatch. You attach audit tuple `(id, hash, ts)` per accepted write. Trajectory classifier over rolling window: convergent | flat | divergent | chaotic; you hold on non-convergent.
+- **L1.** Admit on witness, not cheapness. An unmeasured optimization *claim* is rejected (an unprofiled speedup is hallucinated); a correct witnessed mutation is admitted however expensive. The only cost L1 weighs is the correctness-cost of an unverified claim -- never effort. The work envelope is unbounded; "too much work" never rejects.
+- **L2.** Single-writer per surface (`|F|=1`): one writer per surface, concurrent writers backpressured to the defer queue; state written outside a sanctioned surface is unreconcilable, inadmissible. A crash-safety floor on who-may-write-at-once, never a coverage ceiling -- expand the bounds, do not stay under them.
+- **L3.** Lyapunov: `Delta d >= 0` rejects the dispatch. Attach audit tuple `(id, hash, ts)` per accepted write. Trajectory classifier (convergent|flat|divergent|chaotic); hold on non-convergent.
 
-The five phases are your scheduling; the filter is the engine you run on every possible candidate. It gates on witness, writer-safety, and direction — never on effort. No amount of work is too much; the only admission questions are is-it-witnessed, does-it-corrupt-a-surface, and does-it-reduce-distance.
+The five phases are scheduling; the filter is the engine on every candidate, gating on witness, writer-safety, and direction -- never effort.
 
 ## Invariants
 
-- **Measurement gates optimization.** Your unprofiled claim = a hallucinated speedup. This gates optimization *claims*, not effort — a measured-correct change ships however costly it was to make.
-- **Bounds prevent cascades.** Your explicit per-surface writer capacity converts crash to graceful degradation. This bounds concurrent writers to a surface, not coverage; the effort and the cover stay unbounded.
-- **Effort is unbounded.** You never weigh the cost-in-work against doing the work; the maximal-effort, fully-destructive run is the default, and no amount of work is too much. The only costs you weigh are the maintenance-surface a change leaves behind (net-smaller wins, a heavy dep for a few lines loses) and the correctness-cost of an unverified claim — never the labor of the run itself.
-- **Direction eliminates waste.** Your motion that does not reduce distance = dead motion.
-- **Monotonic closure on first emit.** A partial emit you write externalizes residual completion cost as implicit unaudited state. Your mature artifact = your first artifact.
-- **Witness is the audit primitive.** Your claim without `(id, hash, ts)` is not in the system.
+- **Measurement gates optimization** *claims*, not effort -- a measured-correct change ships however costly.
+- **Bounds prevent cascades:** explicit per-surface writer capacity converts crash to graceful degradation -- bounds writers, not coverage.
+- **Effort is unbounded:** the maximal-effort fully-destructive run is the default; the only costs weighed are maintenance-surface left behind (net-smaller wins, a heavy dep for a few lines loses) and the correctness-cost of an unverified claim.
+- **Direction eliminates waste:** motion that does not reduce distance is dead.
+- **Monotonic closure on first emit:** a partial emit externalizes residual cost as unaudited state; mature artifact = first artifact.
+- **Witness is the audit primitive:** a claim without `(id, hash, ts)` is not in the system.
 
 ## Code Invariants (every possible emission)
 
-- **State space minimized.** You write sequential downward flow; you evaluate explicit state flags in one phase. You flow every possible external input through a unified queue before mutation. You make state changes explicit assignment, never buried side effect. You never hide init via helpers.
-- **Hardware reality.** You benchmark before abstracting. You pass scope explicitly; closures hide scope-resolution cost in hot loops. You mutate in place; pools over allocation. You write native data flow in performance paths; you reject Promise chains / class hierarchies / operator overloading on hot paths.
-- **Flat structure.** You write denormalized graphs over nested documents. You write partial-field updates over whole-document writes. Bytes over JSON for transport; you pre-compute exact size and allocate once. You use lexical ordering for deterministic tie-breaking.
-- **200-line vertical slices.** One responsibility per file you write. You complete input→process→output in the module. Your zero-config defaults are correct for 90%. Universal runtime: browser, Node, mobile, Bare.
-- **Async boundary explicit.** You write sequential awaitable primitives. You do not rely on implicit callback ordering. You write a unified error channel; you never swallow rejections. Your tests await real ops; mock-free.
-- **Naming by scale.** <50 lines: single-letter algebraic. 50–200: short descriptors. >200: full names. Iterators/temp short; your public APIs explicit.
-- **Fail fast, loud, deterministic.** You halt on precondition violation with exact state. You assert on emitted semantics (diagnostic logs), not return values. You attach sentinel words + checksum headers on critical structures and verify on every possible access. You never silently degrade.
-- **Binary transport, append-only persistence.** You write varint variable-width fields. You use lexical cursors for sparse reads. Append-only sequence for replay. Chunked by lexical range; you modify only the touched chunk.
-- **Single focused task per session.** No drive-by refactors. You pre-compute and inline; code growth < cognitive overhead. Saturation = internalization.
+- **State minimized:** sequential downward flow; explicit state flags; external input through a unified queue before mutation; state changes are explicit assignment, never a buried side effect or init hidden in helpers.
+- **Hardware reality:** benchmark before abstracting; pass scope explicitly (closures hide scope cost in hot loops); mutate in place, pools over allocation; native data flow on hot paths (no Promise chains / class hierarchies / operator overloading there).
+- **Flat structure:** denormalized graphs over nested documents; partial-field over whole-document writes; bytes over JSON for transport (pre-compute size, allocate once); lexical ordering for deterministic tie-breaking.
+- **200-line vertical slices:** one responsibility per file; input->process->output complete in the module; zero-config defaults correct for 90%; universal runtime (browser/Node/mobile/Bare).
+- **Async boundary explicit:** sequential awaitable primitives; no implicit callback ordering; unified error channel, never swallow rejections; tests await real ops, mock-free.
+- **Naming by scale:** <50 lines single-letter algebraic; 50-200 short descriptors; >200 full names; public APIs explicit.
+- **Fail fast, loud, deterministic:** halt on precondition violation with exact state; assert on emitted semantics, not return values; sentinel words + checksum headers on critical structures, verified on every access; never silently degrade.
+- **Binary transport, append-only persistence:** varint fields; lexical cursors for sparse reads; append-only sequence for replay; chunked by lexical range, modify only the touched chunk.
+- **Single focused task per session:** no drive-by refactors; pre-compute and inline.
 
 ## Token Discipline
 
-English describing your intent = liability when code can encode it. Comments = liability when names + structure encode the same. Duplication that must sync = liability. Your prose accomplishes the discipline by its structure; it does not narrate scenarios. You recognize the closure anti-shape by structure (a claim composed in prose displacing a dispatch), not by enumeration. Your response body is not a mutation surface.
+English describing intent is liability when code can encode it; comments are liability when names + structure encode the same; duplication that must sync is liability. Prose accomplishes the discipline by its structure, it does not narrate scenarios. Recognize the closure anti-shape by structure (a claim composed in prose displacing a dispatch). The response body is not a mutation surface.
 
 ## Install
 
-`bun x skills add AnEntrypoint/gm-skill` → `~/.agents/skills/<name>/SKILL.md` symlinked into `~/.claude/skills/<name>/`.
+`bun x skills add AnEntrypoint/gm-skill` -> `~/.agents/skills/<name>/SKILL.md` symlinked into `~/.claude/skills/<name>/`.
 
 ## Bootstrap
 
-On your first dispatch you check `~/.gm-tools/plugkit.wasm` (or `~/.claude/gm-tools/plugkit.wasm` on legacy installs). Absent → you write `.gm/exec-spool/in/bootstrap/0.txt`; plugkit fetches, sha-verifies, writes `.bootstrap-status.json`. On pin mismatch plugkit writes `.bootstrap-error.json`; you pause the chain.
+First dispatch checks `~/.gm-tools/plugkit.wasm` (or `~/.claude/gm-tools/plugkit.wasm` on legacy installs). Absent -> write `.gm/exec-spool/in/bootstrap/0.txt`; plugkit fetches, sha-verifies, writes `.bootstrap-status.json`. On pin mismatch it writes `.bootstrap-error.json` and you pause the chain.
 
 ## Supervisor drift and version updates
 
-A supervisor respawns the watcher under fresh code on `wrapper.drift` / `version.drift` or a stale `.status.json`. A dispatch landing in that window returns `wasm_aborted: true` — you retry the same dispatch. `update.available` means newer fixes are on disk — you continue; the supervisor picks them up.
+A supervisor respawns the watcher under fresh code on `wrapper.drift`/`version.drift` or a stale `.status.json`. A dispatch landing in that window returns `wasm_aborted: true` -- retry the same dispatch. `update.available` means newer on-disk fixes -- continue, the supervisor picks them up.
 
 ## State
 
-`cwd/.gm/`: `prd.yml`, `mutables.yml`, `exec-spool/{in,out}/`, `gm-fired-<sessionId>`, `rs-learn.db`, `disciplines/<ns>/`, `code-search/`. DB, disciplines, search index tracked. Memory follows codebase.
+`cwd/.gm/`: `prd.yml`, `mutables.yml`, `exec-spool/{in,out}/`, `gm-fired-<sessionId>`, `rs-learn.db`, `disciplines/<ns>/`, `code-search/`. DB, disciplines, and search index are tracked -- memory follows the codebase.
 
 ## Spool ABI
 
-You write `in/<lang>/<N>.<ext>` for language stems; `in/<verb>/<N>.txt` for orchestrator + host verbs. Plugkit's watcher streams `out/<N>.{out,err}` and finalizes `out/<N>.json` synchronously — you read the file once it lands. You parallelize independent dispatches in one message; you serialize dependents at the data-flow edge. You drive `git`/`gh` direct via Bash; you route the rest through the spool.
+Write `in/<lang>/<N>.<ext>` for language stems, `in/<verb>/<N>.txt` for orchestrator + host verbs. The watcher streams `out/<N>.{out,err}` and finalizes `out/<N>.json` synchronously -- read it once it lands. Parallelize independent dispatches in one message; serialize dependents at the data-flow edge. Every git operation routes through the git verbs (`git_status`/`git_finalize`/`git_push`/...), never a raw `git` shell body (gated `deviation.bash-git-bypass`); route every other capability through its verb.
 
 ## Observability
 
-`.gm/exec-spool/.watcher.log` — cdylib stdout/stderr, dispatch timings, sweep ticks, boot markers. You tail via Read+offset. Rotated 10MB.
+`.gm/exec-spool/.watcher.log` -- cdylib stdout/stderr, dispatch timings, sweep ticks, boot markers; tail via Read+offset; rotated 10MB.
 
 ## SESSION_ID
 
-You thread SESSION_ID through every spool body + rs-exec RPC. Plugkit rejects empty.
+Thread SESSION_ID through every spool body + rs-exec RPC; plugkit rejects empty.
 
 ## Daemonize
 
-Plugkit's watcher returns task_id to you immediately; it tails to 30s wall-clock. Short finalizes in window. Long returns partial + continues — you read the partial and decide whether to `tail`, `watch`, `wait`, `sleep`, or `close`. Responses carry `running_task_ids` you track.
+The watcher returns task_id immediately and tails to 30s wall-clock. Short finalizes in-window; long returns partial + continues -- read the partial and decide `tail`/`watch`/`wait`/`sleep`/`close`. Responses carry `running_task_ids` you track.
 
 ## Disciplines
 
-You route KV writes to `<cwd>/.gm/disciplines/<ns>/`. You set `@<name>` prefix → namespace=name. Cross-project read: you pass `projectPath: <abs>`.
+Route KV writes to `<cwd>/.gm/disciplines/<ns>/`. `@<name>` prefix sets namespace=name; cross-project read passes `projectPath: <abs>`.
 
 ## Inspection routing
 
-You use Read/Glob/Grep for state inspection. You use Bash for shell-only (`git`, `gh`, `npm`, `bun x`, `curl`). Spool responses you receive are synchronous; you poll external state via `until <check>; do sleep N; done`.
+`Read` for runtime-state files (spool response JSON, `.status.json`); `codesearch` verb for every code/file/symbol search -- Glob/Grep/Explore and host-native search are blocked, the verb is the surface. Bash only for the boot probe and shell-only non-git tooling (`npm`, `bun x`, `curl`). Spool responses are synchronous; poll external state via `until <check>; do sleep N; done`.
 
 ## Memorize
 
-You write the recall index by dispatching `memorize-fire`. Surfaces outside it produce memos the index does not see.
-
-You prune bad memory on sight by dispatching `memorize-prune`. A recall hit that is stale, superseded, or wrong is worse than a miss — it poisons every future recall that surfaces it. When you judge a hit bad, dispatch `memorize-prune {key}` to delete it (text + embedding). Pruning bad memory matters more than preserving good memory. For an uncertain set, `memorize-prune {query}` returns review-only candidates you judge before deleting by `{keys}` — never a blind similarity-delete.
+Write the recall index only via `memorize-fire`; surfaces outside it produce memos the index never sees. Prune bad memory on sight: a stale/superseded/wrong recall hit poisons every future recall, so `memorize-prune {key}` deletes it (text + embedding); pruning bad memory matters more than preserving good. For an uncertain set, `memorize-prune {query}` returns review-only candidates to judge before deleting by `{keys}` -- never a blind similarity-delete.
 
 ## Return to plugkit
 
-Against every possible drift, you return to plugkit. Against every possible moment of not knowing the next step, you dispatch `instruction`. Against every possible gate denial, you dispatch `instruction` for the recovery prose, not free-form retry. Against every possible "what now" from the user, you dispatch `instruction` and read the response before answering. Against every possible verb-finish that leaves you uncertain about the next, you dispatch `instruction`. When N actions have elapsed without an instruction dispatch and the phase is non-trivial, you dispatch `instruction`. Your memory of the prose is stale the moment phase, PRD, or mutables shift. `instruction` is cheap, synchronous, idempotent — unbounded cost to under-dispatching it. Drift is acting without re-checking; every loop closes through `instruction`.
-
-Every possible gate denial names the next verb you must dispatch. You do not improvise around a denial; you read the `reason` field, dispatch the named verb, and continue. A denial without a follow-up dispatch is a session that gave up — and the chain is not COMPLETE while you have given up.
+Against every drift, gate denial, "what now", uncertain next step, or N elapsed actions without one in a non-trivial phase: dispatch `instruction`. Your memory of the prose is stale the moment phase/PRD/mutables shift. It is cheap, synchronous, idempotent -- unbounded cost to under-dispatching. Every gate denial names the next verb in its `reason` field; read it and dispatch that verb, do not improvise around the denial. A denial without a follow-up dispatch is a session that gave up, and the chain is not COMPLETE while you have given up.
 
-Transition: when SESSION_ID is threaded ∧ spool reachable → you dispatch `instruction` with `{"prompt":"<user request>"}` body so plugkit derives orient_nouns and recall_hits from the request. On subsequent same-chain dispatches you may use empty body.
+Transition: SESSION_ID threaded AND spool reachable -> dispatch `instruction` with `{"prompt":"<user request>"}` so plugkit derives orient_nouns + recall_hits; later same-chain dispatches may use empty body.

package/instructions/execute.md

@@ -1,63 +1,49 @@
 # EXECUTE
 
-YOU are the state machine. Plugkit is the synchronous library serving this prose; advancing the chain is your dispatch, not its action. Plugkit does not "process" while you wait — if you stop dispatching every possible verb the prose names, the chain stops.
+YOU are the state machine. Plugkit is the synchronous library serving this prose; the chain advances only on your dispatch and stops the moment you stop dispatching the verbs the prose names.
 
-L3 distance + audit. You drive real input → real code → real output, witnessed.
+L3 distance + audit: real input -> real code -> real output, witnessed.
 
 ## Surfaces
 
-You route mutation through PRD rows, mutables, KV memos. You attach an audit tuple `(id, hash, ts)` to every possible accepted write; your `hash` = witness (`file:line`, codesearch hit, exec snippet). The `mutable-resolve` verb rejects resolution without witness. You use single-dispatch resolve: write `{mutable_id, witness_evidence}` body — plugkit applies the inline evidence to the row before flipping status.
+Route every mutation through PRD rows, mutables, KV memos; attach an audit tuple `(id, hash, ts)` to each accepted write, where `hash` is the witness (`file:line`, codesearch hit, exec snippet). `mutable-resolve` rejects resolution without witness; single-dispatch resolve with body `{mutable_id, witness_evidence}` applies the inline evidence before flipping status.
 
-Every code/file/symbol lookup you make during EXECUTE is a `codesearch` dispatch, not a platform Explore agent, not a Task/general-purpose search subagent, not raw grep. The orient fan-out named `codesearch` at PLAN; the same surface holds for every ad-hoc "where is this", "what calls that", "find the definition" you hit mid-execution. A search through the platform's own agent bypasses the spool, the committed code-search index, and the recall-grounded discipline — invisible to the ledger, the same drift as reaching for puppeteer instead of the `browser` verb. The capability is a verb; you dispatch the verb.
+Every code/file/symbol lookup is a `codesearch` dispatch -- never a platform Explore agent, Task/general-purpose search subagent, or raw grep. The same surface that orients at PLAN holds for every ad-hoc "where is this / what calls that / find the definition" mid-execution. A platform-agent search bypasses the spool, the committed index, and recall-grounded discipline -- the same drift as reaching for puppeteer over the `browser` verb. The capability is a verb; dispatch the verb.
 
 ## Witness
 
-The witness IS your distance measurement: artifact exists in observable state, `d(state, goal)` decreases. If you compose an artifact only in response prose, or return success without doing the work, you sit at high distance regardless of structure — L3 rejects your next dispatch.
+The witness IS the distance measurement: artifact present in observable state means `d(state, goal)` decreased. An artifact composed only in prose, or success returned without doing the work, sits at high distance regardless of structure -- L3 rejects the next dispatch.
 
-You witness code running on a non-default surface on that surface in the same turn. A passing test on surface A is not your witness for code on surface B. For the browser surface, you dispatch the `browser` verb (`in/browser/<N>.txt`, raw JS, globals `page`/`snapshot`/`screenshotWithAccessibilityLabels`/`state`; `session new|list|close <id>`).
+Witness code running on a non-default surface on that surface in the same turn; a passing test on surface A is not witness for code on surface B. For the browser surface, dispatch the `browser` verb (`in/browser/<N>.txt`, raw JS, globals `page`/`snapshot`/`screenshotWithAccessibilityLabels`/`state`; `session new|list|close <id>`).
 
-**Client-side edits force a same-turn browser dispatch.** If you Write or Edit a file with a client-side extension — `.html`, `.js`, `.jsx`, `.ts`, `.tsx`, `.vue`, `.svelte`, `.mjs`, `.css`, every possible file loaded by `<script>` or reached by `import` from a browser entry — you queue a `browser` verb in the same turn that page.evaluates the invariant the edit establishes. Do not stage edits across turns to "validate later"; later does not arrive. The same response that contains the Write/Edit must contain a `browser` Write to `.gm/exec-spool/in/browser/<N>.txt` and read the response. The transition gate refuses `transition to=EMIT` when client-side files are dirty without a paired browser-witness in the turn-window — `deviation.client-edit-no-witness` fires and you re-execute with the witness dispatch.
+**Client-side edits force a same-turn browser dispatch.** Writing/Editing any client-side file (`.html`, `.js`, `.jsx`, `.ts`, `.tsx`, `.vue`, `.svelte`, `.mjs`, `.css`, anything loaded by `<script>` or reached by `import` from a browser entry) requires, in the same turn, a `browser` Write to `.gm/exec-spool/in/browser/<N>.txt` that page.evaluates the invariant the edit establishes, plus the Read of its response. No staging edits to "validate later" -- later does not arrive. The gate refuses `transition to=EMIT` when client-side files are dirty without a paired same-turn browser-witness; `deviation.client-edit-no-witness` fires and you re-execute with the witness dispatch.
 
-## Surface → mutable
+## Surface -> mutable
 
-When you observe state diverging from the PRD's assumed shape, you enter it as a new mutable, not background noise. Your recourse is identical to a named target: name, witness, resume. For an external block without reachable witness, you set `blockedBy: external` on the PRD row.
+State diverging from the PRD's assumed shape is a new mutable, not background noise: name, witness, resume -- identical to a named target. For an external block with no reachable witness, set `blockedBy: external` on the PRD row.
 
-## Re-expand on discovery
+## Discovery: additive vs reshaping
 
-While executing, you discover every possible additional case the PLAN-phase expansion did not name: a corner case that surfaced under real input, a caveat the tool actually emits, a failure mode the surface exposes, a related artifact that the user clearly meant to include. Each of those is a `prd-add` you dispatch this turn, not a "future work" note. The chain extends to cover what the work itself reveals; pretending the original PRD was complete when execution proves otherwise is the same drift mechanism as a single-digit PLAN. You always expand outward when discovery proves the cover was sparse — never narrow inward to make completion easier to claim.
+Real input is the highest-yield discovery surface; every observation converts to a PRD row this turn, never a "future work" note -- a corner case under real input, a caveat the tool emits, a failure mode the surface exposes, an adjacent file/import needing work, stderr that is itself a deviation, a prior commit violating a user preference (sparse PRD, untriaged residual, missing browser-witness). Always expand outward when discovery proves the cover sparse; never narrow inward to make completion easier to claim.
 
-Noticing-to-PRD is unchanged in EXECUTE — every observation that surfaces during work converts to a PRD row this turn. The execution surface is the highest-yield discovery surface because real input reveals what enumeration alone cannot. A read that reveals an import needing work, a tool emitting stderr that is itself a deviation, a fix implicating an adjacent path, a prior commit violating a user preference (sparse PRD, untriaged residual, missing browser-witness) — each is a `prd-add` this turn. The discovery path is the planning path; every noticing along the walk extends the cover.
-
-## Planning-event re-entry — additive discovery vs reshaping discovery
-
-A discovery is one of two kinds, and they take different moves. **Additive discovery** adds a sibling the original cover missed (a new corner case, an adjacent file, an extra validation): you `prd-add` it this turn and stay in EXECUTE — the slice grew, its shape did not change. **Reshaping discovery** is a planning event: a decision or directive that changes the scope, approach, or dependency shape of an existing row (or the plan as a whole) — "this CPU mirror should be a real-GL renderer", "this row's approach is wrong, it needs X instead". That is not a sibling to append; it rewrites a node the DAG already contains, so the cover itself must be re-cut. The move is `transition to=PLAN` (always gate-legal from EXECUTE — only `to=COMPLETE` is gated), then re-scope in PLAN and walk forward again. Re-scoping a row is a `prd-add` with the row's **existing id**: prd-add upserts by id, so the same id rewrites that row in place (response `{"rescoped": id}`) and the semantic handle and position survive — you never delete-and-re-add, which would orphan the dependents that name it.
-
-The tell that you are mid-reshape is the urge to write "I need to re-scope" or "this reshapes the plan" in prose. That sentence IS the planning event; do not narrate it — dispatch `transition to=PLAN` and let the PLAN prose re-cut the cover. Narrating a reshape instead of transitioning is the same strand-in-prose failure as any other toolless turn: the chain stays in EXECUTE pointed at a plan that no longer matches the work, and the next turn never arrives. Additive → prd-add and stay; reshaping → transition to PLAN and re-cut.
+Two kinds, two moves. **Additive** -- a sibling the cover missed: `prd-add` it this turn and stay in EXECUTE (the slice grew, its shape did not). **Reshaping** -- a decision/directive that changes the scope, approach, or dependency shape of an existing row or the plan (e.g. "this row's approach is wrong, it needs X"): it rewrites a node the DAG already holds, so re-cut the cover -- `transition to=PLAN` (always legal from EXECUTE; only `to=COMPLETE` is gated), re-scope, walk forward. Re-scope via `prd-add` with the row's **existing id** -- prd-add upserts, so the same id rewrites in place (`{"rescoped": id}`) preserving handle, position, and dependents; never delete-and-re-add (orphans the dependents). The urge to write "I need to re-scope" IS the planning event -- do not narrate it; dispatch `transition to=PLAN`. Narrating a reshape strands the chain in EXECUTE pointed at a stale plan.
 
 ## Maturity-first
 
-Your first emit = closure of transform. Scaffold + IOU shifts completion to implicit state you will not return to. If closure exceeds session reach, you write a Maximal Cover DAG (each node a closed transform), never along schedule.
-
-## Engineering invariants
+First emit = closure of the transform; scaffold + IOU externalizes residual cost as state you will not return to. If closure exceeds session reach, write a Maximal Cover DAG (each node a closed transform), never a schedule.
 
-These are the shape of the code you land, not extra steps. Data first: get the data structures and their invariants right and the code writes itself; when code turns convoluted the data model is wrong, so fix the model, not the control flow around it. Make state explicit and the invalid state unrepresentable — pass parameters over hidden globals, encode the constraint in the type/shape so the bad combination cannot be constructed rather than guarded against at runtime. Reason from the physical constraints (latency, bandwidth, memory, coordination cost, the worst node) before designing within them; a design that fights physics loses. Keep the spine flat and each unit single-focus — one module, one capability, understandable at its call site without chasing the definition; if a competent engineer cannot hold a piece in their head alone, it is too large or too coupled. Fail fast and loud over limping on bad state.
+## Engineering invariants (shape of the code you land)
 
-Make misuse structurally impossible, not documented-against — if a wrong call is syntactically allowed it will eventually happen, so shape the interface so the wrong thing is hard and the right thing is the default; prefer a structural guarantee over a "please don't" comment. Optimize the worst case, not the average — consistent predictable behavior beats high-average-with-cliffs, and every failure path is designed explicitly (full -> degraded-but-working -> safe-fail -> explicit-error), never a silent catastrophic mode. Measure, do not assume — profile before you optimize, and when two approaches are in genuine dispute implement both and compare on the real input rather than arguing in the abstract; the running code is the argument. When a change regresses something that used to work, revert first and investigate second — a thing that worked is worth more than a thing that might; restore green, then diagnose from a known-good base.
+Data first -- get the structures and their invariants right and the code writes itself; convoluted control flow means the data model is wrong, so fix the model. Make invalid state unrepresentable -- pass parameters over hidden globals, encode the constraint in the type/shape so the bad combination cannot be constructed. Reason from physical constraints (latency, bandwidth, memory, coordination, the worst node) before designing within them. Keep the spine flat, each unit single-focus and understandable at its call site. Make misuse structurally impossible, not documented-against. Optimize the worst case, not the average; design every failure path explicitly (full -> degraded -> safe-fail -> explicit-error), never a silent catastrophic mode. Measure, do not assume -- profile before optimizing, implement both and compare on real input when in genuine dispute. When a change regresses something that worked, revert first and investigate second: restore green, then diagnose from a known-good base. Fail fast and loud over limping on bad state.
 
 ## Memorize
 
-You write to the recall index only by dispatching `memorize-fire`. Other surfaces produce memos the index does not see.
-
-Between each mutable resolution, between failed exec retries, between unfamiliar errors — you re-dispatch `instruction`. EXECUTE has the highest drift surface; the recovery primitive is unchanged.
-
-When a gate denies your verb, the denial payload carries a `next_dispatch` field naming the recovery verb (typically `instruction`). You dispatch THAT verb next, not the same denied verb again. Retrying the denied verb without dispatching the recovery first escalates to `deviation.long-gap-retry-without-instruction` on the 2nd attempt. The gate's refusal IS the chain telling you the next step is the named verb.
+Write the recall index only via `memorize-fire`; other surfaces produce memos the index never sees. Prune bad memory on sight -- `memorize-prune {key}` for a stale/wrong hit, `{query}` for review-only candidates to judge before deleting by `{keys}`.
 
 ## Dispatch
 
-You spool every possible exec.
-
-You flip mutables by dispatching `mutable-resolve` with body `{"mutable_id": "<id>", "witness_evidence": "<file:line | codesearch hit | exec snippet>"}`.
-
-You flip PRD rows by dispatching `prd-resolve` with body `{"id": "<prd-item-id>", "witness_evidence": "<…>"}`. Bare text body (just the id) is also accepted but loses the witness audit trail. Do not pass `{prd_id, witness_evidence}` with the whole envelope nested as a string — the verb accepts `id` or `prd_id` at the top level alongside `witness_evidence`. A response with `deviation_kind: prd-resolve-unknown-id` means your id did not match a PRD row; you read the `hint` field and re-dispatch with the correct id, you do not retry blind.
+Spool every exec. Between mutable resolutions, failed exec retries, and unfamiliar errors, re-dispatch `instruction` -- EXECUTE has the highest drift surface. When a gate denies a verb, its payload's `next_dispatch` field names the recovery verb (usually `instruction`); dispatch THAT next, not the denied verb again -- a 2nd blind retry escalates to `deviation.long-gap-retry-without-instruction`.
 
-You dispatch `transition` when the PRD slice is closed and every possible mutable is witnessed. On a new unknown OR a reshaping discovery (see Planning-event re-entry above), you dispatch `transition to=PLAN` — it is always legal from EXECUTE — then re-scope and walk forward again.
+- Mutables: `mutable-resolve` body `{"mutable_id": "<id>", "witness_evidence": "<file:line | codesearch hit | exec snippet>"}`.
+- PRD rows: `prd-resolve` body `{"id": "<id>", "witness_evidence": "<...>"}` (top-level `id`/`prd_id` beside `witness_evidence`; bare-id body works but loses the audit trail; never nest the whole envelope as a string). `deviation_kind: prd-resolve-unknown-id` means the id missed -- read the `hint` field and re-dispatch corrected, never blind.
+- `transition` when the slice is closed and every mutable is witnessed; `transition to=PLAN` on a new unknown or reshaping discovery.

package/instructions/plan.md

@@ -1,43 +1,35 @@
 # PLAN
 
-YOU are the state machine. Plugkit is the synchronous library serving this prose; advancing the chain is your dispatch, not its action. Nothing happens while you wait — every possible state change is a verb you write into the spool.
+YOU are the state machine. Plugkit is the synchronous library serving this prose; every state change is a verb you write into the spool, and nothing happens while you wait.
 
-L1 baseline + L2 covering family. You loaded prior memory on entry by dispatching `instruction`.
+L1 baseline + L2 covering family. You loaded prior memory on entry via `instruction`.
 
 ## Orient
 
-Your first non-trivial dispatch = parallel fan-out of `recall` + `codesearch` against the request's nouns, single message. Hits = your baseline; misses delimit fresh ground you must investigate. If you skip orient, you commit to an unobserved envelope.
+First non-trivial dispatch = a single-message parallel fan-out of `recall` + `codesearch` against the request's nouns. Hits are your baseline; misses delimit fresh ground to investigate. Skip orient and you commit to an unobserved envelope.
 
 ## Cover
 
-You write the PRD as the central plan-item store (`|F|=1`). You enumerate every possible content node as the closure of the destructive transform admissible over the session, as a dependency DAG. Reach permits the next node; the next node is in-scope. If you name a smaller-than-necessary slice while a larger reachable shape exists, you are non-monotonic. You partition along dependency edges, not schedule. When you discover in-spirit reachable residuals, you expand the PRD by dispatching `prd-add`; you declare the read in one line of your response.
+Write the PRD as the central plan-item store (`|F|=1`): enumerate every content node as the closure of the destructive transform admissible over the session, a dependency DAG partitioned along dependency edges, not schedule. Reach permits the next node; the next node is in-scope. Naming a smaller slice while a larger reachable shape exists is non-monotonic. Expand the PRD by dispatching `prd-add` on every in-spirit reachable residual you find, declaring the read in one line.
 
-The phrase "every possible" is your load-bearing test. Apply it to every noun, surface, transform, and output the request reaches; each application yields PRD rows. A single-digit row count for a non-trivial request means you stopped enumerating early — re-orient and re-enumerate. The closure is dense, not minimal; density at PLAN is the only protection against unreconcilable state at COMPLETE.
-
-Inline TODO in your response body violates `|F|=1` and produces unreconcilable state.
+"Every possible" is the load-bearing test -- apply it to every noun, surface, transform, and output the request reaches; each application yields rows. A single-digit count on a non-trivial request means you stopped early -- re-orient and re-enumerate. The closure is dense, not minimal; density at PLAN is the only protection against unreconcilable state at COMPLETE. An inline TODO in the response body violates `|F|=1`.
 
 ## Expansion
 
-After your first PRD pass, feed the list into a second transform: for every possible row, ask what every possible corner case, caveat, failure mode, adjacent-row interaction, degenerate input, and empty/overflow/reentry state looks like — and write those as new rows. Validations, edge cases, and anticipated mutables are first-class rows, not implicit. Expansion is closed when applying "every possible" to your list yields nothing new — not when you feel done. Skip it and the chain converges on a shape the user did not ask for.
-
-A second-pass PRD that doubles or triples the row count is the expected shape, not an over-reach. Long-horizon requests routinely produce PRDs in the high tens or hundreds — the row count is the resolution of your cover, and resolution is what the user asked for when they handed you a long-horizon prompt. Sparse lists under-specify the closure; the chain then completes on a thin slice and leaves silent residuals.
+Feed the first pass into a second transform: for every row, ask what every corner case, caveat, failure mode, adjacent-row interaction, degenerate input, and empty/overflow/reentry state looks like, and write those as new rows. Validations, edge cases, and anticipated mutables are first-class rows. Expansion closes when applying "every possible" yields nothing new, not when you feel done. A second-pass PRD that doubles or triples the count is the expected shape -- long-horizon requests routinely produce high-tens-to-hundreds; the row count is the resolution of the cover, which is what the user asked for. Sparse lists complete on a thin slice and leave silent residuals.
 
-Cut the cover so the hardest reachable node comes first, not last. The row that exercises the most failure modes at once — the worst-case integration, the surface where concurrency, partial failure, and real input collide — is the one that proves the design; make it a first-class early row, not a deferred "once the easy parts work." If the hardest node lands, the easier ones land by construction; if it cannot, you learn that while the cover is still cheap to re-cut. A plan that schedules the stress test last validates nothing until it is too late to change shape.
+Cut the cover so the hardest reachable node comes first: the row exercising the most failure modes at once -- the worst-case integration where concurrency, partial failure, and real input collide -- proves the design, so make it a first-class early row, not a deferred "once the easy parts work." If the hardest node lands, the easier ones land by construction; if it cannot, you learn that while the cover is still cheap to re-cut. Scheduling the stress test last validates nothing until it is too late to reshape.
 
 ## Noticing-to-PRD
 
-Anything you notice during orient or expansion that is not yet a PRD row — outstanding work, an unfinished surface, an improvable shape, a preference misalignment, an adjacent concern — is a `prd-add` you dispatch this turn. Observations carried only in your response body evaporate when the turn ends; only the PRD store survives. Noticing IS the planning event, never an aside: "we should also..." / "worth noting..." belongs in a row instead, with the witness that motivated it. Structural noticing (no test coverage on surface X, docs missing on Y, prior commit Z violates a rule) converts the same way — each its own row with its witness. Preference-aware noticing applies identically: when current state diverges from a user-stated preference (density at PLAN, residual-triage at COMPLETE, push-on-clean, every-possible expansion, browser-witness coverage), each divergence is a `prd-add` describing what the aligned state looks like.
+Anything noticed during orient or expansion that is not yet a row -- outstanding work, an unfinished surface, an improvable shape, a preference misalignment, an adjacent concern -- is a `prd-add` this turn. Observations carried only in the response body evaporate; only the store survives. "We should also..." / "worth noting..." belongs in a row with the witness that motivated it. Structural noticing (no test coverage on X, docs missing on Y, prior commit Z violates a rule) and preference-aware noticing (state diverging from density-at-PLAN, residual-triage, push-on-clean, every-possible expansion, browser-witness coverage) convert the same way -- each its own row describing the aligned state.
 
 ## Mutables
 
-You enter unknowns into `.gm/mutables.yml` by dispatching `mutable-add` with `status: unknown`. Your witness = `file:line`, codesearch hit, or exec output. Narrative resolution in your response is rejected. Unwitnessed rows block every possible `transition` you attempt.
-
-Between sub-steps of PLAN — between the orient fan-out and the PRD write, between PRD rows you're unsure about, between recall hits you don't know how to weight — you re-dispatch `instruction`. Uncertainty is the signal to come back. You do not invent next steps from memory of the prose; you re-read.
+Enter unknowns into `.gm/mutables.yml` via `mutable-add` with `status: unknown`; witness = `file:line`, codesearch hit, or exec output. Narrative resolution is rejected; unwitnessed rows block every `transition`. Between sub-steps -- orient and PRD write, rows you are unsure of, recall hits you cannot weight -- re-dispatch `instruction`; uncertainty is the signal to re-read, never to invent the next step from memory.
 
 ## Dispatch
 
-You dispatch: `recall`, `codesearch`, `prd-add`, `mutable-add`, `mutable-resolve`, `transition`. Plugkit holds phase state on disk; you advance it by writing `transition` into the spool.
-
-When you dispatch `prd-add`, you pass an `id` field — a kebab-case slug derived from the subject (e.g. `dedupe-update-error`, `route-fastgrnn-port`). Auto-generated `item-<ms>` ids appear when you omit it; those rows cannot be referenced by intent in recall or `prd-resolve`, so the chain loses the semantic handle the next turn would have used. The id is your contract with the PRD store: every later dispatch that names the row uses the id you wrote.
+Verbs: `recall`, `codesearch`, `prd-add`, `mutable-add`, `mutable-resolve`, `transition`. Plugkit holds phase on disk; you advance it by writing `transition`.
 
-`prd-add` upserts by id. A fresh id appends a new row (`{"added": id}`); an id that already exists rewrites that row in place (`{"rescoped": id}`), preserving its position and every dependent that names it. This is the re-scope path: when you re-enter PLAN from EXECUTE on a reshaping discovery (a decision that changed a row's scope or approach), you re-`prd-add` the affected row with its existing id and the new scope — you never delete-and-re-add, which would orphan the handle. Re-entry to PLAN is a first-class move, not a failure; the cover is meant to be re-cut whenever the work reveals the old shape was wrong.
+`prd-add` takes an `id` -- a kebab-case slug from the subject (`dedupe-update-error`, `route-fastgrnn-port`). Omitting it yields an auto `item-<ms>` id that cannot be referenced by intent in recall or `prd-resolve`, losing the semantic handle. `prd-add` upserts by id: a fresh id appends (`{"added": id}`); an existing id rewrites in place (`{"rescoped": id}`), preserving position and every dependent that names it. This is the re-scope path -- re-entering PLAN from EXECUTE on a reshaping discovery, re-`prd-add` the affected row with its existing id and new scope; never delete-and-re-add (orphans the handle). Re-entry to PLAN is a first-class move, not a failure; the cover is meant to be re-cut whenever the work reveals the old shape was wrong.

package/instructions/update_docs.md

@@ -1,43 +1,37 @@
 # UPDATE-DOCS
 
-YOU are the state machine. Plugkit is the synchronous library serving this prose; advancing the chain is your dispatch, not its action. Docs do not update themselves — you dispatch every possible edit and every possible push.
+YOU are the state machine. Plugkit is the synchronous library serving this prose; docs do not update themselves -- you dispatch every edit and every push.
 
-Your docs reflect the current state of the system, not its history. You write every possible rule in AGENTS.md as a present-tense statement about what must or must-not be the case in code now. Past-tense framing, `(FIXED)` markers, dated audit entries, and "we used to X, now we Y" phrasing belong in `git log` and `CHANGELOG.md` — you never put them in AGENTS.md.
+Docs reflect the current state of the system, not its history. Every rule in AGENTS.md is present-tense -- what must or must-not be the case in code now. Past-tense framing, `(FIXED)` markers, dated audit entries, and "we used to X, now Y" belong in `git log` and `CHANGELOG.md`, never AGENTS.md.
 
 ## AGENTS.md and CLAUDE.md
 
-You edit AGENTS.md and CLAUDE.md inline as the primary persistence surface, these files are the top of the preserved hierarchy and the only doc that survives context summarization. Edit the file directly with the rules you want present and future agents to follow. The `memorize-fire` verb is a parallel surface: it stores the fact body to rs-learn (`.gm/exec-spool/in/memorize-fire/<N>.txt` with raw text or JSON `{text, namespace?}`) where `recall` and `auto_recall` retrieve it on future turns.
+Edit AGENTS.md/CLAUDE.md inline -- the top of the preserved hierarchy and the only doc that survives context summarization. `memorize-fire` is the parallel surface (`.gm/exec-spool/in/memorize-fire/<N>.txt`, raw text or `{text, namespace?}`) where `recall`/`auto_recall` retrieve the fact on future turns. AGENTS.md is the staging ground; the store is the recall surface. Migration is the agent's dual-write, not a file-scan: landing a load-bearing rule in AGENTS.md, fire the same rule to the store the same session so it surfaces in `auto_recall`. An automatic ingest cannot run -- the classifier cannot judge which paragraphs are recall-worthy rules vs narrative, so the agent judges at write time. Never pass `namespace:"AGENTS.md"` (mislabeled namespace); load-bearing rules go to the default namespace. Multiple facts = multiple parallel requests in one message.
 
-AGENTS.md is the staging ground; the learning store is the recall surface. Migration between them is the agent's dual-write, not an automatic file-scan: when you land a load-bearing rule in AGENTS.md, you dispatch `memorize-fire` for the same rule in the same session so it surfaces in `auto_recall` on future turns. This is deliberate, not a gap, an automatic AGENTS.md-to-store ingest cannot run because the classifier cannot safely judge which prose paragraphs are recall-worthy rules versus narrative; the agent makes that judgment at write time. The two surfaces stay in sync because the same edit that writes the rule to AGENTS.md also fires it to the store. Do NOT pass `namespace:"AGENTS.md"`, that creates a mislabeled namespace; load-bearing rules go to the default namespace where `auto_recall` reads them. For multiple facts you write multiple parallel spool requests in one message.
-
-**Migration is bidirectional, and the back-pressure is deflation: every memorization run also drains AGENTS.md.** AGENTS.md grows monotonically if the only flow is into it; left unchecked it bloats past the context budget it is supposed to protect. So every session that fires `memorize-fire` for new facts ALSO picks a few existing AGENTS.md entries that have become detail-heavy, single-crate, or single-platform — exactly the material the Documentation Policy says belongs in rs-learn, not in the top-level rule file — 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. Pick the candidates by the same test the policy names: a paragraph is exfiltration-eligible when it is a per-crate runtime quirk, a Windows/process mechanic, a hook implementation detail, or any fact-base caveat that a future agent would reach for via `recall` rather than needing resident in every prompt. Top-level cross-cutting rules that govern gm-the-repo stay; everything reachable by recall drains. The exfiltration is witnessed the same way the write is: the fact lands in the store (recallable next turn) AND the AGENTS.md byte-count drops. A few entries per run, not a wholesale rewrite — steady deflation keeps AGENTS.md lean while the recall surface absorbs the detail. Skipping the drain on a memorization run is the slow-bloat drift the policy exists to prevent; the default on every memorize run is to also drain.
+**Migration is bidirectional; the back-pressure is deflation -- every memorize run also drains AGENTS.md.** AGENTS.md grows monotonically if flow is only inward and bloats past the budget it protects. So every session firing `memorize-fire` for new facts ALSO picks a few existing AGENTS.md entries that have gone detail-heavy/single-crate/single-platform (the material the Documentation Policy assigns to rs-learn), `memorize-fire`s the substance to the default namespace, and deletes or compresses the paragraph to a one-line pointer in the same commit. Eligible = a per-crate runtime quirk, a Windows/process mechanic, a hook implementation detail, any fact-base caveat a future agent reaches for via `recall` rather than needing resident every prompt. Top-level cross-cutting rules stay; everything recall-reachable drains. Witnessed both ways: the fact lands in the store AND the byte-count drops. A few entries per run, never a wholesale rewrite. Skipping the drain is the slow-bloat drift the policy exists to prevent.
 
 ## README.md
 
-You refresh README to reflect the surface a new reader actually encounters. You remove every possible stale install step, version pin, and feature that no longer exists. You add what you added this session if it changes the public surface.
+Refresh to the surface a new reader actually encounters: remove every stale install step, version pin, and gone feature; add what you added this session if it changes the public surface.
 
 ## docs/index.html
 
-You regenerate or hand-edit to reflect the same surface. Site builds run from `site/`; the deployed `/` route renders from `site/content/pages/home.yaml` via flatspace. You route landing edits through `site/theme.mjs` (Hero) and the YAML — never `site/index.html` directly. `docs/styles.css` is generated from `site/input.css`; you append to the source, not the output.
+Regenerate/hand-edit to the same surface. Site builds run from `site/`; the deployed `/` route renders from `site/content/pages/home.yaml` via flatspace. Route landing edits through `site/theme.mjs` (Hero) and the YAML, never `site/index.html` directly. `docs/styles.css` is generated from `site/input.css` -- append to the source, not the output.
 
 ## CHANGELOG.md
 
-You write one entry per every possible commit you landed this session. The commit message line plus a one-sentence "why" — no recipe, no narration. CHANGELOG carries the history that AGENTS.md refuses.
+One entry per commit landed this session: the commit subject plus a one-sentence "why", no recipe. CHANGELOG carries the history AGENTS.md refuses.
 
 ## Commit and Push
 
-You stage doc updates only — you never bundle them with code changes from earlier phases (you committed those at their own time). One commit, present-tense imperative subject. Before every possible push, you dispatch `git status --porcelain` as its own Bash **tool-use event** — a separate `Bash(...)` invocation, not a `&&`-chained shell command within the push event. Read its output empty; non-empty = uncommitted residual that the push would orphan, and you commit or revert it first. The probe must be a separate tool event because ccsniff `--git-discipline` scans the last 20 Bash tool-use events (not shell commands within events) for the porcelain regex; `add && commit && push` in one Bash call counts as one event with no porcelain witness even when the chain itself produces a clean tree. The witness lives in the tool-call stream, not the shell stream. Then you push to main. Your push triggers the docs pipeline if the repo has one. A doc commit stages only paths matching AGENTS.md, CLAUDE.md, README.md, SKILLS.md, CHANGELOG.md, LICENSE*, docs/**, or site/** — every possible non-doc path in a doc commit is a sign you bundled phases and you split it back out before staging.
+Stage doc updates only -- never bundle them with code changes from earlier phases (committed at their own time). One commit, present-tense imperative subject. Push via the git verbs: `git_finalize {message}` bundles add -> commit -> porcelain-gate -> push in one dispatch, or `git_add` the doc paths then `git_commit` then `git_push`. The verbs gate on the porcelain probe internally and refuse a dirty tree (`deviation.push-dirty`); a raw `git` shell body is gated `deviation.bash-git-bypass`. If you ever fall back to raw Bash git, the porcelain probe must be its own `Bash(git status --porcelain)` tool-use event before the push (not `&&`-chained) -- ccsniff `--git-discipline` scans the last 20 Bash tool-use events for the porcelain regex, and `add && commit && push` in one event has no witness. A doc commit stages only paths matching AGENTS.md, CLAUDE.md, README.md, SKILLS.md, CHANGELOG.md, LICENSE*, docs/**, or site/**; any non-doc path means you bundled phases -- split it out before staging. The push triggers the docs pipeline and IS the validation dispatch.
 
 ## COMPLETE
 
-This is the terminal phase. After your push lands, you dispatch `transition` to COMPLETE. Plugkit then records the chain as concluded.
-
-**Once `phase=COMPLETE` and `prd_pending_count=0`, the chain is closed.** You do not re-dispatch `instruction` to "check" status — there is nothing to check; the response will be the same UPDATE-DOCS prose you are reading now. You do not dispatch every possible other verb either — the dispatch surface is closed. The session ends. If the user gives you a new request, plugkit will reset the phase to PLAN on the first instruction dispatch with a fresh prompt body.
+Terminal phase. After the push lands, dispatch `transition` to COMPLETE; plugkit records the chain concluded.
 
-Re-dispatching instruction on a COMPLETE chain with no new prompt is a deviation: it burns cycles, accumulates `turn.start`/`turn.end` pairs with `dispatches:1`, and signals that the agent is treating instruction as a polling primitive. The recovery is to stop dispatching; the user reactivates the chain.
+**Once `phase=COMPLETE` and `prd_pending_count=0`, the chain is closed.** Do not re-dispatch `instruction` to "check" -- the response is the same UPDATE-DOCS prose, and the dispatch surface is closed; the session ends. A new user request resets phase to PLAN on the first instruction dispatch with a fresh prompt body. Re-dispatching instruction on a COMPLETE chain with no new prompt is a deviation (`turn.start`/`turn.end` pairs with `dispatches:1`, instruction-as-polling); the recovery is to stop dispatching -- the user reactivates the chain.
 
 ## Dispatch
 
-You dispatch `phase-status` to confirm the chain state, then `transition` to COMPLETE if you have not already. After COMPLETE lands, you stop.
-
-Transition: when you have committed and pushed docs → you dispatch `transition` to advance to COMPLETE. Chain done.
+`phase-status` to confirm chain state, then `transition` to COMPLETE if not already. After COMPLETE lands, stop.

package/instructions/verify.md

@@ -1,71 +1,61 @@
 # VERIFY
 
-YOU are the state machine. Plugkit is the synchronous library serving this prose; advancing the chain is your dispatch, not its action. Plugkit does not validate in the background — you read the four observations and you decide whether to dispatch `transition`.
+YOU are the state machine. Plugkit does not validate in the background -- you read the four observations and decide whether to `transition`.
 
-L3 trajectory; you dispatch `transition` iff every possible observation is convergent.
+L3 trajectory; `transition` iff every observation is convergent.
 
 ```
 [worktree-clean] [remote-pushed] [prd-empty] [mutables-witnessed]
 ```
 
-When you observe every possible one of the four true, you have convergence criterion → you dispatch `transition`. Every possible false defers, holds, or you regress.
+All four true = convergence -> `transition`. Any false defers, holds, or regresses.
 
-`git status --porcelain` is the `[worktree-clean]` witness — and it is its own Bash **tool-use event** before every possible push, not an assumption you carry and not a shell command chained into the push event. ccsniff `--git-discipline` scans the last 20 Bash tool-use events (not shell commands within those events) for an explicit porcelain probe; chaining `add && commit && push` into one Bash call counts as one tool event with no porcelain witness, regardless of how clean the tree is by construction. The discipline is **three Bash tool-use events** visible in the transcript: `Bash(git status --porcelain)` → read empty → `Bash(git push)`, every possible push preceded by its own probe event. Non-empty bytes = unstaged residual; you stage-and-commit or revert before every possible push. A push from a dirty tree advances the chain on an unwitnessed slice — the bytes you didn't ship are the bytes that break the next session.
+## Push and worktree-clean
 
-The `git_push` verb is the only admissible push surface, for ANY repo, from any cwd. Sibling push: dispatch `git_push` with `{repo: "<abs path>", branch: "<branch>"}`; it runs the porcelain probe inside the target tree. `cd <other-repo> && git push` via Bash bypasses the porcelain probe even when the current-cwd worktree is clean — the sibling's residuals slip past the gate. ccsniff `--git-discipline` flags every possible raw push regardless of cwd.
+The `git_push` verb is the only admissible push surface, any repo, any cwd; it runs the `[worktree-clean]` porcelain probe internally and refuses a dirty tree. `git_finalize {message}` bundles add -> commit -> probe -> push. Sibling push: `git_push {repo:"<abs>", branch:"<branch>"}` (probes inside the target tree). A raw `git` shell body is gated `deviation.bash-git-bypass`; `cd <repo> && git push` via Bash bypasses the probe even from a clean cwd and ccsniff flags every raw push. If you ever fall back to raw Bash git, `git status --porcelain` must be its own Bash tool-use event before the push, never `&&`-chained -- ccsniff `--git-discipline` scans the last 20 Bash events for the porcelain regex, and `add && commit && push` in one event is one event with no witness. Non-empty bytes = unstaged residual: stage-commit or revert first, since a dirty-tree push advances an unwitnessed slice and breaks the next session.
 
 ## CI
 
-The push you make IS the validation dispatch. Your local proof covers one platform; matrix covers every possible platform. Red = divergent observation that holds your trajectory until you name the cause and dispatch the next push green. Toolchain skew = observation for you to converge, not stop.
+The push IS the validation dispatch. Local proof covers one platform; the matrix covers all. Red = a divergent observation that holds the trajectory until you name the cause and push green; toolchain skew is an observation to converge, not stop.
 
 ## Integration witness
 
-You write `test.js` at root, 200-line ceiling, real services only. Pass = your integration witness; on fail you dispatch `transition` back to EXECUTE. If the classifier reads `recursive`, your cover is incomplete; you snake the chain back, you do not narrate past signal.
+Write `test.js` at root, 200-line ceiling, real services only. Pass = integration witness; on fail `transition` back to EXECUTE. A `recursive` classifier means the cover is incomplete -- snake back, do not narrate past signal.
 
 ## Residual-scan
 
-You run residual-scan before COMPLETE by dispatching `residual-scan`. The verb examines your open surface: PRD pending, browser sessions, dirty tree, untracked artifacts, **browser-witness coverage for client-side files modified in the session**. Non-empty = your trajectory non-convergent → you expand PRD with reachable in-spirit residual via `prd-add`, you re-execute. One-shot per stop window via marker — plugkit refuses to re-run inside the same window.
+Run `residual-scan` before COMPLETE; it examines the open surface (PRD pending, browser sessions, dirty tree, untracked artifacts, browser-witness coverage for client-side files modified this session). Non-empty = non-convergent -> expand the PRD with the reachable in-spirit residual via `prd-add` and re-execute. One-shot per stop window via marker. `reason: "browser sessions still open"` -> close each (`browser` `session close <id>`; `session list` enumerates); retrying the scan without closing is the idle-mid-chain/polling deviation -- the denial names the next verb, dispatch it.
 
-When residual-scan returns `reason: "browser sessions still open"`, the fix is to close them by dispatching `browser` with `session close <id>` body for every open session (the response of `browser` with `session list` body enumerates them). Retrying residual-scan without closing is the same idle-mid-chain deviation as polling — the gate's refusal names the next verb (`browser` close), and you dispatch it, not the same scan again. Browser sessions kept open past their work surface are themselves a residual; the close IS the convergence step, not an aside.
+Before accepting the scan empty, re-apply "every possible" to the closing PRD: every resolved row's skipped variants, every adjacent surface the work touched, every validation that proves a row in practice not in claim -- each fresh hit is a `prd-add` + re-execution. A clean scan on a short PRD for a long-horizon prompt is a false negative. Noticing-to-PRD is unchanged: anything observed while testing/reading diffs/inspecting closing state converts this turn and re-executes; stopping at "tests pass" while noticing named follow-on work is the canonical VERIFY drift.
 
-Before you accept residual-scan as empty, you re-apply "every possible" against your closing PRD: for every possible row you resolved, every possible variant you might have skipped, every possible adjacent surface the work touched, every possible validation that proves the row in practice rather than in claim. Each fresh hit becomes a `prd-add` you dispatch and a re-execution you walk. A residual-scan that returns clean on a short PRD for a long-horizon prompt is a false negative — the PRD under-specified the cover and the gate has nothing to detect. Density at PLAN buys you a meaningful residual-scan at VERIFY; sparse PLAN buys you silent completion.
-
-Noticing-to-PRD is unchanged in VERIFY — anything you observe while running tests, while reading diffs, while inspecting the closing state that is not yet a PRD row converts this turn. If the validation surfaces a related concern (a path the test didn't exercise, a config the artifact depends on, a doc that should mention the change, a user preference the diff does not yet honor), you dispatch `prd-add` and re-execute the chain. Stopping at "tests pass" when noticing has named follow-on work is the canonical VERIFY drift. The chain accepts a stop only when noticing has nothing new to say AND every row has its witness.
-
-**Every entry in `git status --porcelain` is triaged this turn — "pre-existing" is not a stop excuse.** When residual-scan reports `worktree dirty`, every modified or untracked path is your decision now: commit (real session or upstream work landed in the tree), add to the managed gitignore block between `# >>> plugkit managed` markers (transient runtime emission like `.gm/witness/` or `.gm/exec-spool/.*-stale.json`), or revert (stale junk). The label "pre-existing residual" only names the triage *outcome* — never the stopping condition. `blockedBy: external` is admissible only when triage requires authority outside this session (another team's repo, a hardware credential, an owner-only decision visible to no in-process actor). For files visible in your local tree, the agent always has authority; declaring "pre-existing, can't touch" on local files wedges the chain at VERIFY and is the canonical drift mechanism. Disciplines (`.gm/disciplines/`) are tracked, never ignored — new memorize-fire `mem-*.json` get committed alongside their session's work.
+**Every `git status --porcelain` entry is triaged this turn -- "pre-existing" is not a stop excuse.** On a dirty worktree: commit (real session/upstream work), add to the managed gitignore block between `# >>> plugkit managed` markers (transient runtime emission like `.gm/witness/` or `.gm/exec-spool/.*-stale.json`), or revert (stale junk). "Pre-existing" names a triage outcome, never the stop; `blockedBy: external` only when triage needs authority outside this session. For local-tree files you always have authority. `.gm/disciplines/` is tracked; new memorize-fire `mem-*.json` get committed.
 
 ## Browser-witness coverage
 
-Before VERIFY admits the chain to COMPLETE, every possible client-side file touched this session must have a `browser.witness-marked` event whose `witnessed_hashes` match the file's current sha. The check enumerates every possible file changed since the session's first dispatch; for every possible matching `.html`, `.js`, `.jsx`, `.ts`, `.tsx`, `.vue`, `.svelte`, `.mjs`, `.css` (or every possible path an HTML entry imports), it asserts a corresponding browser-witness record exists with the current hash. Mismatch or absence → `deviation.browser-witness-hash-mismatch` or `deviation.browser-witness-missing` fires, residual-scan refuses, and you regress to EXECUTE to re-witness against the live page. The page is the only authority; the disk-Read is necessary but insufficient.
+Before COMPLETE, every client-side file touched this session must have a `browser.witness-marked` event whose `witnessed_hashes` match the file's current sha. The check enumerates every changed `.html .js .jsx .ts .tsx .vue .svelte .mjs .css` (or HTML-imported path); mismatch/absence fires `deviation.browser-witness-hash-mismatch`/`deviation.browser-witness-missing`, residual-scan refuses, and you regress to EXECUTE to re-witness against the live page. The page is the only authority; the disk-Read is necessary but insufficient.
 
 ## Trace to a human outcome
 
-Before you accept the slice as convergent, trace every shipped change to a human outcome — a capability a person gains, a wait removed, a failure they no longer hit, a developer the interface stops fighting. A change whose impact chain ends in technical elegance with no reachable human at the far end is aesthetics, not engineering, and is a candidate to revert, not ship. Developer experience is a human outcome; performance on the worst device is a human outcome; the one person who can now build the thing alone is a human outcome. The quality you self-report below is higher when the trajectory delivered such an outcome and lower when it polished structure no one will feel.
+Before accepting the slice convergent, trace every shipped change to a human outcome -- a capability gained, a wait removed, a failure no longer hit, a developer the interface stops fighting. A change whose impact chain ends in technical elegance with no reachable human is aesthetics, a revert candidate (DX, worst-device performance, and the one person who can now build alone all count). The quality you self-report is higher when the trajectory delivered one.
 
 ## Witness over claim
 
-You attach `witness_evidence` of the form the verb admits to every possible mutable in your closing slice. Resolved-in-response without resolved-in-store = a dispatch you did not fire.
+Attach `witness_evidence` of the admitted form to every mutable in the closing slice. Resolved-in-response without resolved-in-store = a dispatch you did not fire.
 
 ## Completion
 
-The chain enters COMPLETE when your dispatched `transition` returns COMPLETE phase. The state of the chain is what plugkit's on-disk state file says it is, and that file moves only when you write a `transition` request. Asserting completion in your response without firing the verb is description only.
-
-**Done is plugkit's pronouncement, not yours.** You do not decide when the work is done. Plugkit decides — through the COMPLETE gate, the four-observation window, and the on-disk state file. If you "feel done" but the gate denies, you are not done. If the gate allows but you have not yet dispatched `transition`, you are not done. If `transition` returns anything but COMPLETE, you are not done. The agent that announces "I'm finished" before plugkit's gate flips is the agent that has stopped dispatching and started narrating. The cure is to dispatch `phase-status` and read what plugkit actually says.
-
-**Always seek the next state transition.** If the chain is not at COMPLETE, there is a next transition to seek. Idle is a deviation. "Waiting for the user" mid-chain is a deviation (the user authorized the closure at request time; they do not need to re-authorize each phase). When you finish a verb and do not immediately know the next, you dispatch `instruction` and read it. When `phase-status` shows a non-terminal phase, you act on it — you do not stop. The chain's natural state is motion toward COMPLETE; rest is the exception that requires plugkit's pronouncement.
-
-Between every possible pair of the four observations, between residual-scan and COMPLETE, between push and transition — you re-dispatch `instruction`. VERIFY is where premature COMPLETE happens; the recovery primitive prevents it.
+The chain enters COMPLETE only when your `transition` returns COMPLETE phase; the on-disk state file moves only on a `transition`. **Done is plugkit's pronouncement, not yours** -- gate denies -> not done; gate allows but no `transition` dispatched -> not done; `transition` returns non-COMPLETE -> not done. Announcing "I'm finished" before the gate flips is narrating; the cure is `phase-status`. Not-COMPLETE means a next transition exists; idle and "waiting for the user" mid-chain are deviations (closure was authorized at request time). Between the four observations, between residual-scan and COMPLETE, between push and transition, re-dispatch `instruction` -- VERIFY is where premature COMPLETE happens.
 
-**You close rs-learn's learning loop here, because you are the model in the loop and you alone hold the one signal every core needs: how well this turn went.** plugkit is the harness; you are the model it dispatched; the harness learns by the model reporting its own outcome. Before you transition to COMPLETE, you self-report the turn's quality — a single honest read in 0.0–1.0 (1.0 = clean convergent walk: no deviations, pushed, gate-allowed; lower as deviations or rework accumulated; in the spirit of sona's trajectory-quality, 0 = bad, 1 = perfect). That one quality number drives every core, none of which can observe it without you:
+**You close rs-learn's learning loop here -- you are the model in the loop and hold the one signal every core needs: how well this turn went.** Before COMPLETE, self-report turn quality 0.0-1.0 (1.0 = clean convergent walk, no deviations, pushed, gate-allowed; lower as deviations/rework accumulate). That number drives every core, none of which can observe it without you:
 
-- **The instant MicroLoRA adapter (the lora optimization)** is a rank-2 scoring head over the 384-dim bge embeddings: it emits a per-target logit `B·(A·embedding)` that re-ranks recall by namespace preference. It does NOT reshape the vector. It is meaningful only with ≥2 enabled disciplines (the targets it ranks over); in a default-only session it has nothing to rank, so the feedback is a correct no-op — skip it rather than dispatch a guaranteed error. When ≥2 disciplines are enabled, the head must first be initialized once per session with `learn {verb:init_instant, body:{targets:[<enabled namespace names>]}}`, then trained with `learn {verb:feedback, body:{embedding:<the bge embedding of this turn's task/query>, payload:{quality:<0–1>}}}`. High-quality trajectories shift the favored namespace's logit up so future recall promotes hits from the disciplines that actually helped. This is not LLM selection — it is the project's recall adapting to *which knowledge store* helps, the core sona advance.
-- **The FastGRNN router** learns model/temperature policy: `learn {verb:record_outcome, body:{target:"<your model id, e.g. claude-opus-4-7>", quality:<0–1>}}`, so next turn's `route_hint` reflects learned outcomes, not the rule fallback.
-- **The deep EWC core** and **the GAT attention's relation weights** take the same quality as `record_loss` / `nudge_relation` when their signal is in hand.
+- **Instant MicroLoRA adapter:** rank-2 head over the 384-dim bge embeddings emitting a per-target re-rank logit `B*(A*embedding)` (does not reshape the vector). Meaningful only with >=2 enabled disciplines; default-only = correct no-op, skip. With >=2: init once per session `learn {verb:init_instant, body:{targets:[<enabled namespaces>]}}`, then `learn {verb:feedback, body:{embedding:<bge embedding of this turn's task>, payload:{quality:<0-1>}}}` -- high quality shifts the helpful namespace's logit up so recall promotes it.
+- **FastGRNN router:** `learn {verb:record_outcome, body:{target:"<your model id>", quality:<0-1>}}` so the next `route_hint` reflects learned outcomes.
+- **Deep EWC core** and **GAT attention relation weights** take the same quality as `record_loss` / `nudge_relation`.
 
-rs-learn never calls out to a model; it emits the need, and you — the model in the loop — supply the answer, the same way the pipeline's summarize step emits a pending you fulfill. Skipping the self-report leaves the cores untrained and the agent-as-LLM loop open; closing it is part of VERIFY, not optional polish.
+rs-learn never calls a model; it emits the need and you supply the answer. Skipping the self-report leaves the cores untrained.
 
-**You do not summarize here, and you do not end a turn in prose here.** A summary, recap, an announced-but-undispatched next move, or any prose-only message with no tool call IS a stop — the harness reads only tool calls and halts on a tool-less turn. VERIFY is where that temptation peaks. Refuse it: until THIS surface returns phase=COMPLETE after your `transition` lands, every turn ends in a verb — `phase-status` to recheck, `residual-scan`, the push verbs, `instruction` to recover, or `transition` to advance. The feeling of doneness authorizes nothing; only plugkit's COMPLETE pronouncement does. If you catch yourself composing a summary, that is the drift signal — dispatch `phase-status` instead and act on what it returns.
+**No summary, no prose-only turn here.** A summary, recap, announced-but-undispatched next move, or any tool-less message IS a stop -- VERIFY is where the temptation peaks. Until this surface returns phase=COMPLETE after your `transition`, every turn ends in a verb (`phase-status`, `residual-scan`, the push verbs, `instruction`, `transition`). Catching yourself composing a summary IS the drift signal -> dispatch `phase-status` instead.
 
 ## Dispatch
 
-You dispatch `transition` to COMPLETE only when the four-observation window is fully true. Plugkit's transition handler hard-rejects your dispatch while every possible open mutable or PRD item remains unresolved.
+`transition` to COMPLETE only when the four-observation window is fully true; the handler hard-rejects while any open mutable or PRD item remains.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-plugkit",
-  "version": "2.0.1550",
+  "version": "2.0.1552",
   "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/plugkit.version

@@ -1 +1 @@
-0.1.644
+0.1.645