advisor-checkpointlisted

# Advisor Checkpoint Spend the expensive model only at a task's few load-bearing moments; let a cheaper/faster model handle the rest. ## When to consult - **Before committing to a non-obvious approach.** Orientation (reading files, finding the shape of the problem) doesn't need it; the moment you're about to write code, edit a plan, or declare an interpretation does. - **When stuck** — an error is recurring, an approach isn't converging, results don't fit what you expected. - **Before declaring a non-trivial task done.** Make the deliverable durable first (commit, save, write the file) — the consult adds latency, and a durable result survives an interruption where an unwritten one doesn't. Skip it on short, reactive steps where the next action is dictated by what you just read — the value is highest on the first consult, before an approach crystallizes, not on every turn. ## In an interactive session Dispatch an `Agent` call at a checkpoint above, with `model` set to a stronger tier than the one currently running (`opus` or `fable`), given the plan or diff so far and a specific question — not "review everything," but "does this approach have a flaw" or "which constraint breaks the tie between X and Y." Treat the response as advice, not a verdict: - If you act on it and it fails empirically, or you have primary-source evidence it's wrong (the file says X, the test says Y), adapt — don't re-litigate an empirical result against advice. - If you already have