preflightlisted

Before starting work on issue $ARGUMENTS, execute these phases in order. Do NOT write code until all gates are cleared. ## Phase 1 — Mechanical context gathering 1. Run `pnpm exec totem spec $ARGUMENTS` to generate the implementation spec from the issue body. Output lands in `.totem/specs/<issue>.md`. 2. Call `mcp__totem-dev__search_knowledge` with a query describing the changes you're about to make. If the issue touches a specific system (hooks, orchestrator, compiler, extract pipeline, store layer, MCP server), ALSO query `mcp__totem-strategy__search_knowledge` for relevant ADRs and proposals. 3. Summarize in 3-5 bullets: what the spec says, which lessons are relevant, and any constraints or traps surfaced by the knowledge queries. If `totem spec` fails, report the error and stop — do not proceed to Phase 2. ## Phase 2 — Scope triage (decide if Phase 3 is needed) **Skip Phase 3 if this is a tactical change.** Tactical means ALL of: - Pure bug fix, wording change, or existing-test tightening - No new types or required fields on existing types - No new state containers (maps, sets, module-level variables, singletons) - No new failure modes or classes of error - No new cross-cutting concerns (logging, telemetry, caching, auth) - Touches ≤3 files in a single architectural layer **Draft the design doc (Phase 3) if ANY of:** - Adds a new type, interface, or required field - Adds a new state container or changes state ownership/lifecycle - Introduces a ne