gm-oc 2.0.630 → 2.0.632

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-oc",
-  "version": "2.0.630",
+  "version": "2.0.632",
   "description": "State machine agent with hooks, skills, and automated git enforcement",
   "author": "AnEntrypoint",
   "license": "MIT",

package/skills/browser/SKILL.md

@@ -4,199 +4,74 @@ description: Browser automation via playwriter. Use when user needs to interact
 allowed-tools: Bash(browser:*), Bash(exec:browser*)
 ---
 
-# Browser Automation with playwriter
+# Browser Automation
 
-**Use gm subagents for all independent work items. Invoke all skills in the chain: planning → gm-execute → gm-emit → gm-complete → update-docs.**
+Two pathways — never mix:
 
+**`exec:browser`** — JS against `page`. `page`, `snapshot`, `screenshotWithAccessibilityLabels`, `state` globals available. 15s live window then backgrounds; drains auto on every subsequent plugkit call.
 
-## Two Pathways
+**`browser:` prefix** — playwriter session management. One command per block.
 
-**Session commands** (`browser:` prefix) — manage multi-step sessions via playwriter CLI. Each `browser:` block runs its commands sequentially.
-
-**JS execution** (`exec:browser`) — run JavaScript directly against `page`. State persists across calls via `state` global.
-
-**CRITICAL**: Never mix these two pathways. Each `browser:` block is a separate Bash call. Each `exec:browser` block is a separate Bash call.
-
-## 15-Second Ceiling — How It Works
-
-Every `exec:browser` call has a 15s live window. During that window, all stdout/stderr is streamed to you in real time. After 15s the task backgrounds and you receive:
-- All output produced so far (live drain)
-- A task ID with `plugkit sleep/status/close` instructions
-
-**The task keeps running.** Every subsequent plugkit interaction automatically drains all running browser tasks — you will see new output without asking.
-
-**Never use `await new Promise(r => setTimeout(r, N))` with N > 10000.** Use short poll loops instead (see patterns below).
-
-**"Assertion failed: UV_HANDLE_CLOSING" in output** means the call exceeded 15s and was cut off — ignore the assertion noise, look at the output before it. The task was backgrounded normally.
-
-## Idle Timeout & Session Reaper
-
-Playwriter kills idle browser sessions after 5-15 minutes of inactivity. The rs-exec tooling now automatically cleans up the spawned browser process when the Claude Code session ends, preventing zombie tabs.
-
-**Historical note**: Earlier versions left the browser running after session end, causing repeated tabs on reconnect. This is now fixed — the browser will be killed when your session idles and closes.
-
-## Session Pathway (`browser:`)
-
-Create a session first, use `--direct` for CDP mode (requires Chrome with remote debugging):
-
-```
-browser:
-playwriter session new --direct
-```
-
-Returns a numeric session ID (e.g. `1`). Use that ID for all subsequent calls. **Each command must be a separate Bash call:**
-
-```
-browser:
-playwriter -s 1 -e 'await page.goto("http://example.com")'
-```
-
-```
-browser:
-playwriter -s 1 -e 'await snapshot({ page })'
-```
+## Core Usage
 
 ```
-browser:
-playwriter -s 1 -e 'await screenshotWithAccessibilityLabels({ page })'
+exec:browser
+await page.goto('https://example.com')
+await snapshot({ page })
 ```
 
-State persists across session calls:
-
 ```
 browser:
-playwriter -s 1 -e 'state.x = 1'
+playwriter session new --direct
 ```
 
 ```
 browser:
-playwriter -s 1 -e 'console.log(state.x)'
-```
-
-
-**RULE**: The `-e` argument must use single quotes. The JS inside must use double quotes for strings.
-
-**RULE**: Never chain multiple `playwriter` commands in one `browser:` block — run one command per block.
-
-## JS Execution Pathway (`exec:browser`)
-
-For direct page access, DOM queries, and data extraction. The runtime provides `page`, `snapshot`, `screenshotWithAccessibilityLabels`, and `state` as globals.
-
-```
-exec:browser
-await page.goto('https://example.com')
-await snapshot({ page })
-```
-
-```
-exec:browser
-const title = await page.title()
-console.log(title)
+playwriter -s 1 -e 'await page.goto("http://example.com")'
 ```
 
-Never add shell quoting — write plain JavaScript directly.
-
-## Core Workflow
-
-1. **Navigate**: `exec:browser\nawait page.goto('url')` — session auto-created on first call
-2. **Snapshot**: `exec:browser\nawait snapshot({ page })`
-3. **Interact**: click, fill, type in subsequent `exec:browser` calls
-4. **Extract data**: `exec:browser\nconsole.log(await page.evaluate(() => document.title))`
+Session state persists across `browser:` calls. `-e` arg: single quotes outside, double quotes inside JS strings.
 
-## Long-Running Operations — Poll Pattern
+## Timing
 
-For operations that take >10s (model loading, network fetches, animations):
+Never `await setTimeout(N)` with N > 10000. Use poll loops:
 
-**Step 1** — set up listener and kick off the operation:
-```
-exec:browser
-state.done = false
-state.result = null
-page.on('console', msg => {
-  const t = msg.text()
-  if (t.includes('loaded') || t.includes('ready')) { state.done = true; state.result = t }
-})
-await page.click('#start-button')
-console.log('started, waiting...')
-```
-
-**Step 2** — poll in short bursts (this will background after 15s and keep draining):
 ```
 exec:browser
 const start = Date.now()
 while (!state.done && Date.now() - start < 12000) {
   await new Promise(r => setTimeout(r, 500))
 }
-console.log('done:', state.done, 'result:', state.result)
+console.log(state.result)
 ```
 
-If step 2 backgrounds (takes >15s), every subsequent plugkit call will drain its output automatically. When you see the result in the drain log, close the task:
-```
-exec:close
-task_N
-```
+"Assertion failed: UV_HANDLE_CLOSING" = backgrounded normally, ignore noise.
 
 ## Common Patterns
 
-
-
-### Data Extraction
-
+Data extraction:
 ```
 exec:browser
-const items = await page.$$eval('.product-title', els => els.map(e => e.textContent))
+const items = await page.$$eval('.title', els => els.map(e => e.textContent))
 console.log(JSON.stringify(items))
 ```
 
-
-### Console Monitoring — set up listener first, then poll
-
+Console monitoring — set listeners first, then poll:
 ```
 exec:browser
 state.logs = []
-state.errors = []
 page.on('console', msg => state.logs.push({ type: msg.type(), text: msg.text() }))
-page.on('pageerror', e => state.errors.push(e.message))
-console.log('listeners attached')
-```
-
-```
-exec:browser
-console.log('logs so far:', JSON.stringify(state.logs.slice(-20)))
-console.log('errors:', JSON.stringify(state.errors))
 ```
 
 ```
 exec:browser
-if (page.workers().length > 0) {
-  const r = await page.workers()[0].evaluate(() => JSON.stringify({ type: 'worker alive' }))
-  console.log(r)
-}
-```
-
-exec:browser
-const result = await page.evaluate(() => JSON.stringify({
-  entityCount: window.debug?.scene?.children?.length,
-  playerId: window.debug?.client?.playerId
-}))
-console.log(result)
-```
-
-exec:browser
-const start = Date.now()
-while (Date.now() - start < 12000) {
-  const el = await page.$('#status')
-  if (el) { console.log('found:', await el.textContent()); break }
-  await new Promise(r => setTimeout(r, 300))
-}
+console.log(JSON.stringify(state.logs.slice(-20)))
 ```
 
-## Key Rules
+## Rules
 
-- `browser:` prefix → playwriter session management (one command per block)
-- `exec:browser` → JS in page context (multi-line JS allowed, 15s live window)
-- Never mix pathways in the same Bash call
-- `-e` argument: single quotes on outside, double quotes inside for JS strings
 - One `playwriter` command per `browser:` block
-- Never `await setTimeout(N)` with N > 10000 — use short poll loops instead
-- All running browser tasks drain automatically on every plugkit interaction
+- Never mix pathways in same Bash call
+- `exec:browser` = plain JS, no shell quoting
+- All browser tasks drain automatically on every plugkit interaction
+- Sessions reap after 5-15min idle; browser cleaned up on session end

package/skills/code-search/SKILL.md

@@ -3,53 +3,33 @@ name: code-search
 description: Mandatory codebase search workflow. Use whenever you need to find anything in the codebase. Start with two words, iterate by changing or adding words until found.
 ---
 
-# CODEBASE SEARCH — Mandatory Workflow
+# CODEBASE SEARCH
 
-**Use gm subagents for all independent work items. Invoke all skills in the chain: planning → gm-execute → gm-emit → gm-complete → update-docs.**
+`exec:codesearch` is the only codebase search tool. `Grep`, `Glob`, `Find`, `Explore`, `grep`/`rg`/`find` inside `exec:bash` = ALL hook-blocked. No fallback path.
 
+Handles: exact symbols, exact strings, file-name fragments, regex-ish patterns, natural-language queries, PDF pages (cite `path/doc.pdf:<page>`).
 
-`exec:codesearch` is the only way to search the codebase. **`Grep`, `Glob`, `Find`, `Explore`, and `grep`/`rg`/`find`/`ripgrep` inside `exec:bash` are ALL hook-blocked.** There is no fallback path for exact matches, regex, or file-name patterns — codesearch handles all of them. If you find yourself reaching for Grep or Glob, that reflex is wrong; replace with codesearch.
-
-**What codesearch handles** (every codebase-lookup need lands here):
-- Exact identifier / symbol lookup (function names, class names, constants) — symbols are extracted and indexed separately, exact matches rank top.
-- Exact string content — query tokens >1 trigger a literal-substring boost in content scoring.
-- File-name fragments — file paths are tokenized and matched with a score boost.
-- Regex-ish patterns — BM25 tokenization covers snake_case, camelCase, dot/dash splits; matching component words returns the file.
-- Natural-language concept queries — BM25 + vector re-ranking handle "find the hook that blocks grep", "where is PR stats calculated", etc.
-- PDF pages — specs, papers, manuals, RFCs, datasheets, design docs extracted page-by-page into the same index. Cite `path/to/doc.pdf:<page>`.
-
-**Direct-read exceptions** (no search required):
-- Known absolute path → `Read` tool.
-- Listing a known directory → `exec:nodejs` + `fs.readdirSync`.
-
-Unscanned digital PDFs are a search gap — if you know a doc exists and it isn't returning, check it is not under an ignored dir and that extraction succeeded (encrypted / image-only PDFs yield empty chunks silently).
+Direct-read exceptions: known absolute path → `Read`. Known dir listing → `exec:nodejs` + `fs.readdirSync`.
 
 ## Syntax
 
 ```
 exec:codesearch
-<natural language query>
+<two-word query>
 ```
 
-## Mandatory Search Protocol
-
-**Start with exactly two words.** Never start broader. Never start with one word.
+## Protocol
 
-**Iterate by changing or adding words** — do not switch approach or give up until the content is found:
+1. Start: exactly two words
+2. No results → change one word
+3. Still no → add third word
+4. Still no → swap changed word again
+5. Minimum 4 attempts before concluding absent
 
-1. Start: two-word query most likely to match
-2. No results → change one word (synonym, related term)
-3. Still no results → add a third word (narrow scope)
-4. Still no results → swap the changed word again
-5. Keep iterating — changing or adding words each pass — until content is found
-
-**Never**: start with one word | start with a sentence | give up after one miss | switch to a different tool | declare content missing after fewer than 4 search attempts
-
-**Each search is one `exec:codesearch` call.** Run them sequentially — use each result to inform the next query.
+Never: one word | full sentence | give up under 4 attempts | switch tools.
 
 ## Examples
 
-Finding where a function is defined:
 ```
 exec:codesearch
 session cleanup idle
@@ -59,23 +39,10 @@ session cleanup idle
 exec:codesearch
 cleanup sessions timeout
 ```
-→ found.
-
-Finding config format:
-```
-exec:codesearch
-plugin registration format
-```
-→ no results →
-```
-exec:codesearch
-plugin config array
-```
-→ found.
 
-Finding content inside a spec PDF:
+PDF search:
 ```
 exec:codesearch
 usb descriptor endpoint
 ```
-→ returns `docs/usb-spec.pdf:42` — cite page, open via Read if you need the surrounding page text.
+→ returns `docs/usb-spec.pdf:42` — cite page, Read if you need surrounding text.

package/skills/create-lang-plugin/SKILL.md

@@ -5,68 +5,54 @@ description: Create a lang/ plugin that wires any CLI tool or language runtime i
 
 # CREATE LANG PLUGIN
 
-**Use gm subagents for all independent work items. Invoke all skills in the chain: planning → gm-execute → gm-emit → gm-complete → update-docs.**
+Single CommonJS file at `<projectDir>/lang/<id>.js`. Auto-discovered — no hook editing.
 
-
-A lang plugin is a single CommonJS file at `<projectDir>/lang/<id>.js`. gm-cc's hooks auto-discover it — no hook editing, no settings changes. The plugin gets three integration points: **exec dispatch**, **LSP diagnostics**, and **context injection**.
-
-## PLUGIN SHAPE
+## Plugin Shape
 
 ```js
 'use strict';
 module.exports = {
-  id: 'mytool',                          // must match filename: lang/mytool.js
+  id: 'mytool',                         // must match filename
   exec: {
-    match: /^exec:mytool/,               // regex tested against full "exec:mytool\n<code>" string
-    run(code, cwd) {                     // returns string or Promise<string>
-      // ...
-    }
+    match: /^exec:mytool/,
+    run(code, cwd) { /* returns string or Promise<string> */ }
   },
-  lsp: {                                 // optional — synchronous only
-    check(fileContent, cwd) {            // returns Diagnostic[] synchronously
-      // ...
-    }
+  lsp: {                                // optional — synchronous only
+    check(fileContent, cwd) { /* returns Diagnostic[] */ }
   },
-  extensions: ['.ext'],                  // optional — file extensions lsp.check applies to
-  context: `=== mytool ===\n...`        // optional — string or () => string
+  extensions: ['.ext'],                 // optional — for lsp.check
+  context: `=== mytool ===\n...`       // optional — string or () => string
 };
 ```
 
-```ts
-type Diagnostic = { line: number; col: number; severity: 'error'|'warning'; message: string };
-```
-
-## HOW IT WORKS
-
-- **`exec.run`** is called in a child process (30s timeout) when Claude writes `exec:mytool\n<code>`. Output is returned as `exec:mytool output:\n\n<result>`. Async is fine here.
-- **`lsp.check`** is called synchronously in the hook process on each prompt submit — must NOT be async. Use `execFileSync` or `spawnSync`.
-- **`context`** is injected into every prompt's `additionalContext` (truncated to 2000 chars) and into the session-start context.
-- **`match`** regex is tested against the full command string `exec:mytool\n<code>` — keep it simple: `/^exec:mytool/`.
+`type Diagnostic = { line: number; col: number; severity: 'error'|'warning'; message: string }`
 
-## STEP 1 — IDENTIFY THE TOOL
+## How It Works
 
-Answer these before writing any code:
+- `exec.run` — child process, 30s timeout, async OK. Called when Claude writes `exec:mytool\n<code>`.
+- `lsp.check` — synchronous, called per prompt submit. Use `spawnSync`/`execFileSync`. No async.
+- `context` — injected into every prompt (truncated 2000 chars).
 
-1. What is the tool's CLI name or npm package? (`gdlint`, `tsc`, `deno`, `ruff`, ...)
-2. How do you run a single expression/snippet? (`tool eval <expr>`, `tool -e <code>`, HTTP POST, ...)
-3. How do you run a file? (`tool run <file>`, `tool <file>`, ...)
-4. Does it have a lint/check mode? What does its output format look like?
-5. What file extensions does it apply to?
-6. Is the game/server running required, or does it work headlessly?
+## Step 1 — Identify Tool
 
-## STEP 2 — IMPLEMENT exec.run
+1. CLI name or npm package?
+2. Run single expression? (`tool eval <expr>`, `tool -e <code>`, HTTP POST...)
+3. Run file? (`tool run <file>`)
+4. Lint/check mode + output format?
+5. File extensions?
+6. Requires running server or headless?
 
-Pattern for **HTTP eval** (tool has a running server):
+## Step 2 — exec.run Patterns
 
+HTTP eval (running server):
 ```js
-const http = require('http');
 function httpPost(port, urlPath, body) {
   return new Promise((resolve, reject) => {
     const data = JSON.stringify(body);
     const req = http.request(
       { hostname: '127.0.0.1', port, path: urlPath, method: 'POST',
         headers: { 'Content-Type': 'application/json', 'Content-Length': Buffer.byteLength(data) } },
-      (res) => { let raw = ''; res.on('data', c => raw += c); res.on('end', () => { try { resolve(JSON.parse(raw)); } catch { resolve({ raw }); } }); }
+      res => { let raw = ''; res.on('data', c => raw += c); res.on('end', () => resolve(JSON.parse(raw))); }
     );
     req.setTimeout(8000, () => { req.destroy(); reject(new Error('timeout')); });
     req.on('error', reject);
@@ -75,109 +61,65 @@ function httpPost(port, urlPath, body) {
 }
 ```
 
-Pattern for **file-based execution** (write temp file, run headlessly):
-
+File-based (headless):
 ```js
-const fs = require('fs');
-const os = require('os');
-const path = require('path');
-const { execFileSync } = require('child_process');
-
 function runFile(code, cwd) {
   const tmp = path.join(os.tmpdir(), `plugin_${Date.now()}.ext`);
   fs.writeFileSync(tmp, code);
-  try {
-    return execFileSync('mytool', ['run', tmp], { cwd, encoding: 'utf8', timeout: 10000 });
-  } finally {
-    try { fs.unlinkSync(tmp); } catch (_) {}
-  }
+  try { return execFileSync('mytool', ['run', tmp], { cwd, encoding: 'utf8', timeout: 10000 }); }
+  finally { try { fs.unlinkSync(tmp); } catch (_) {} }
 }
 ```
 
-**Distinguish single expression vs multi-line** when both modes exist:
-
+Single expr detection:
 ```js
-function isSingleExpr(code) {
-  return !code.trim().includes('\n') && !/\b(func|def|fn |class|import)\b/.test(code);
-}
+const isSingleExpr = code => !code.trim().includes('\n') && !/\b(func|def|fn |class|import)\b/.test(code);
 ```
 
-## STEP 3 — IMPLEMENT lsp.check (if applicable)
-
-Must be **synchronous**. Parse the tool's stderr/stdout for diagnostics:
+## Step 3 — lsp.check
 
 ```js
-const { spawnSync } = require('child_process');
-const fs = require('fs');
-const os = require('os');
-const path = require('path');
-
 function check(fileContent, cwd) {
   const tmp = path.join(os.tmpdir(), `lsp_${Math.random().toString(36).slice(2)}.ext`);
   try {
     fs.writeFileSync(tmp, fileContent);
     const r = spawnSync('mytool', ['check', tmp], { encoding: 'utf8', cwd });
-    const output = r.stdout + r.stderr;
-    return output.split('\n').reduce((acc, line) => {
+    return (r.stdout + r.stderr).split('\n').reduce((acc, line) => {
       const m = line.match(/^.+:(\d+):(\d+):\s+(error|warning):\s+(.+)$/);
-      if (m) acc.push({ line: parseInt(m[1]), col: parseInt(m[2]), severity: m[3], message: m[4].trim() });
+      if (m) acc.push({ line: +m[1], col: +m[2], severity: m[3], message: m[4].trim() });
       return acc;
     }, []);
-  } catch (_) {
-    return [];
-  } finally {
-    try { fs.unlinkSync(tmp); } catch (_) {}
-  }
+  } catch (_) { return []; }
+  finally { try { fs.unlinkSync(tmp); } catch (_) {} }
 }
 ```
 
-Common output patterns to parse:
-- `file:line:col: error: message` → standard
-- `file:line: E001: message` → gdlint style (`E`=error, `W`=warning)
-- JSON output → `JSON.parse(r.stdout).errors.map(...)`
-
-## STEP 4 — WRITE context STRING
-
-Describe what `exec:<id>` does and when to use it. This appears in every prompt. Keep it under 300 chars:
+## Step 4 — context String
 
+Under 300 chars:
 ```js
-context: `=== mytool exec: support ===
-exec:mytool
-<expression or code block>
-
-Runs via <how>. Use for <when>.`
+context: `=== mytool ===\nexec:mytool\n<expression>\n\nRuns via <how>. Use for <when>.`
 ```
 
-## STEP 5 — WRITE THE FILE
-
-File goes at `lang/<id>.js` in the project root. The `id` field must match the filename (without `.js`).
-
-Verify after writing:
+## Step 5 — Write + Verify
 
 ```
 exec:nodejs
-const p = require('/abs/path/to/lang/mytool.js');
+const p = require('/abs/path/lang/mytool.js');
 console.log(p.id, typeof p.exec.run, p.exec.match.toString());
 ```
 
 Then test dispatch:
-
 ```
 exec:mytool
-<a simple test expression>
+<simple test expression>
 ```
 
-If it returns `exec:mytool output:` → working. If it errors → fix `exec.run`.
-
-## CONSTRAINTS
-
-- `exec.run` may be async — it runs in a child process with a 30s timeout
-- `lsp.check` must be synchronous — no Promises, no async/await
-- Plugin must be CommonJS (`module.exports = { ... }`) — no ES module syntax
-- No persistent processes — `exec.run` must complete and exit cleanly
-- `id` must match the filename exactly
-- First match wins — if multiple plugins could match, make `match` specific
-
-## EXAMPLE — gdscript plugin (reference implementation)
+## Constraints
 
-See `C:/dev/godot-kit/lang/gdscript.js` for a complete working example combining HTTP eval (single expressions via port 6009) with headless file execution fallback, synchronous gdlint LSP, and a context string.
+- `exec.run` async OK (30s timeout)
+- `lsp.check` synchronous only — no Promises
+- CommonJS only — no ES module syntax
+- No persistent processes
+- `id` must match filename exactly
+- First match wins — make `match` specific

package/skills/gm/SKILL.md

@@ -5,68 +5,40 @@ description: Agent (not skill) - immutable programming state machine. Always inv
 
 # GM — Skill-First Orchestrator
 
-**Invoke the `planning` skill immediately.** Use the Skill tool with `skill: "planning"`.
+Invoke `planning` skill immediately. Skill tool only — never Agent tool for skills.
 
-**CRITICAL: Skills are invoked via the Skill tool ONLY. Do NOT use the Agent tool to load skills.**
+## STATE MACHINE
 
-## WHERE YOU ARE
+Top of chain. No mutables resolved. Phases: PLAN → EXECUTE → EMIT → VERIFY → UPDATE-DOCS.
+Each phase loads protocols via Skill invocation only. Reading summary ≠ being in phase.
 
-Top of state machine. No mutables resolved, no files read, no phase protocols loaded. Each phase (PLAN, EXECUTE, EMIT, VERIFY, UPDATE-DOCS) carries its own protocols (mutable discipline, pre-emit diagnostic, post-emit verify, hygiene sweep, CI watch). Protocols enter context only when you invoke the corresponding Skill. Reading a summary ≠ being in them.
+`gm-execute` = execution contract (all phases). `governance` = route/legitimacy reference (load once).
 
-Transitions = state changes, not reminders. Phase exit condition met → next Skill invocation moves you. Without invocation: still in prior state, regardless of prose.
+## MEMORIZE — HARD RULE
 
-`gm-execute` = execution contract. Defines "running code" across every phase: `exec:<lang>` = only runner; `exec:codesearch` = only exploration; witnessed output = only ground truth; import real modules over reimplementation. Execution happens in every phase, not only EXECUTE. About to run anything, `gm-execute` protocols not fresh in context → operating outside contract → reload `gm-execute` first.
+Unknown→known = memorize same turn it resolves. Background, non-blocking.
 
-`governance` = governance reference. Route discovery (7 route families, 16 failure taxonomy) feeds `planning`. Weak-prior bridge (plausibility never equals authorization) constrains `gm-execute`. Legitimacy gate (earned specificity, lawful downgrade, five refused collapses) gates `gm-emit` and `gm-complete`. Load once at session start.
+Triggers: exec: output answers prior unknown | code read confirms/refutes assumption | CI log reveals root cause | user states preference/constraint | fix worked for non-obvious reason | env quirk observed.
 
-## FRAGILE LEARNINGS — HARD RULE
-
-Every unknown→known transition in this session = fact that dies on compaction unless handed off **the same turn it resolves**. Not end of phase. Not end of chain. Same turn.
-
-**Automatic trigger** — spawn `memorize` the moment any of these happens:
-- An `exec:` run's output answers an earlier "let me check" / "I don't know yet"
-- A code read confirms or refutes an assumption
-- A CI log reveals a root cause
-- User states a preference, constraint, deadline, or decision
-- A fix worked for a non-obvious reason
-- A tool / environment quirk bit once (blocked commands, path oddities, platform gotchas)
-
-**Invocation** (background, non-blocking, continue working in the same message):
 ```
-Agent(subagent_type='gm:memorize', model='haiku', run_in_background=true, prompt='## CONTEXT TO MEMORIZE\n<single fact with enough context to be useful cold>')
+Agent(subagent_type='gm:memorize', model='haiku', run_in_background=true, prompt='## CONTEXT TO MEMORIZE\n<fact>')
 ```
 
-**Parallel**: multiple facts resolve in one turn → spawn multiple memorize agents in the **same message** (parallel tool blocks). One call per fact. Never serialize, never batch into one prompt.
-
-**End-of-turn self-check** (mandatory before handing control back): scan the turn for resolved unknowns that were not memorized. Any found → spawn them now, parallel, before the response closes.
-
-Resolve an unknown, skip memorize = memory leak. Treat it as a bug, not a style choice.
-
-## USER DONE TALKING
-
-User gave task. User waiting. Not co-pilot — person whose time you conserve by running chain end-to-end. Mid-chain questions ("should I proceed?", "which approach?", "look right before continue?") = chain breaks. Every break forces user back into loop they offloaded.
-
-Unknown resolution order — fixed:
-1. **Code execution** — witnessed run (`exec:<lang>`, `exec:codesearch`, import real module). Covers 90%+ of mutables.
-2. **Web** — `WebFetch` / `WebSearch` for API docs, spec PDFs, library versions, framework conventions. Covers environment facts not in this codebase.
-3. **User** — only after code and web exhausted. Only for genuinely ambiguous scope that makes planning impossible, or destructive-irreversible decisions (force-push, drop prod table, publish). Not for preferences resolvable from existing code conventions.
-
-An unknown that could fall to step 1 or 2 is not a clarifying question — it is a missed run. "Want me to..." or "Should I..." mid-chain = invoke next skill instead.
-
-Clarification allowed at top of chain (before first `planning`) when scope is genuinely unreadable. After chain starts: policy carries it.
+Multiple facts → parallel Agent calls in ONE message. End-of-turn: scan for un-memorized resolutions → spawn now.
 
-All work coordination, planning, execution, and verification happens through the skill tree starting with `planning`:
-- `planning` skill → `gm-execute` skill → `gm-emit` skill → `gm-complete` skill → `update-docs` skill
-- `memorize` sub-agent — background only, non-sequential. `Agent(subagent_type='gm:memorize', model='haiku', run_in_background=true, prompt='## CONTEXT TO MEMORIZE\n<what was learned>')`
+## EXECUTION ORDER
 
-All code execution uses `exec:<lang>` via the Bash tool — never direct `Bash(node ...)` or `Bash(npm ...)`.
+1. Code execution (exec:<lang>, exec:codesearch) — 90%+ of unknowns
+2. Web (WebFetch/WebSearch) — env facts not in codebase
+3. User — only when 1+2 exhausted AND decision is destructive-irreversible
 
-**Every `git push` triggers GitHub Actions. CI is auto-watched by the Stop hook — outcomes (green / failed / still-running) appear in next-turn context. No manual `gh run watch` needed. `gh run view <id> --log-failed` is for on-demand failure diagnosis only. Full behaviour in `gm-execute`.**
+"Should I..." mid-chain = invoke next skill instead.
 
-Do not use `EnterPlanMode`. Do not run code directly via Bash. Invoke `planning` skill first.
+Skill chain: `planning` → `gm-execute` → `gm-emit` → `gm-complete` → `update-docs`
 
-## RESPONSE POLICY — ALWAYS ACTIVE
+exec:<lang> only. Never Bash(node/npm/npx/bun). git push = auto CI watch via Stop hook.
 
-Always terse. Technical substance stays. Fluff dies. Drop articles, filler, pleasantries, hedging. Fragments OK. Short synonyms. Technical terms exact. Pattern: `[thing] [action] [reason]. [next step].`
+## RESPONSE POLICY
 
-Code, commits, and PR descriptions write in normal prose. Security warnings, destructive confirmations, and genuinely ambiguous sequences also drop terseness. Everything else stays terse.
+Terse. Drop filler. Fragments OK. Pattern: `[thing] [action] [reason]. [next step].`
+Code/commits/PRs = normal prose. Security/destructive = drop terseness.