meta-looplisted

# meta-loop Three-tier loop: **orchestrator** (this session) runs the hot path plan → delegate → verify → synthesize; **workers** (`reader` on sonnet, `worker` on opus) do parallel execution; **advisor** (fable, fresh context) is a consulted advisor off the hot path. The economics: parallelism is the leverage, not a cheaper worker. A worker runs on the same tier the orchestrator would have used doing the work itself, so fanning out costs wall-clock and context - never quality. The saving is structural rather than per-token: no single agent fills a context window, so several shorter threads cost less in aggregate than one long thread that maxes out and compacts repeatedly. Session-model note: a skill cannot set the main-thread model. Run the session on Opus (`/model opus`) so the orchestrator matches its writers; on a Fable session the loop still works - the advisor then buys a fresh, unanchored context rather than a model upgrade. Worker tier never follows the session: `reader` and `worker` pin their own models in frontmatter, because an agent with no pin inherits the session model, which silently downgrades a fan-out on a cheap session and silently runs it on the priciest tier on an expensive one. ## Phase 1 - Plan (orchestrator) Write the plan before spawning anything: subtasks, each with a concrete deliverable and acceptance criteria the orchestrator can check from evidence (diff, test output, file list - not the worker's own say-so). Mark which subtasks are independen