cortex-extract-insightlisted

# cortex-extract-insight You produce the `.cortex/insight/` layer — an inferred, persistent, queryable understanding of the codebase (design §5.1) — as **a plan, not a pipeline** (design §5.3): you read the deterministic L1 output and *decide* how to analyze the rest, in four phases. Everything you write MUST conform to `cortex-schema.md` §4.10 (the storage contract) — field names, enums, and id grammars come from there and from `src/insight/storage.ts`/`entry.ts`; never invent fields. Two non-negotiables up front: - **No CLI wrapper (RULES 3, design §5.3).** There is no `cortex extract-insight` command and you must never reference one. You are invoked from a session or by a scheduled task; Core never triggers extraction. - **Recursion re-plans from the top (build-order flag F7).** Your fan-out is exactly one level deep. If a scope turns out too large, YOU (the top-level orchestrator) break it into sub-scopes and re-dispatch in a later wave. A scope sub-agent NEVER spawns sub-agents of its own. Insight is **ungated — context, not authority** (schema §4.10). You write it directly; you never touch `compass/`, `atlas/`, `RULES.md`, or either spec tree, and you emit no pulse proposals — only the two pulse artefacts named in §4.10.10 plus your transient fragment manifests. ## Invocation modes Determine the mode before doing anything (design §5.11): 1. **Initial extraction** — no usable `.cortex/insight/` layer exists (or the user asks for a rebuild). Run all fo