fog-planlisted

# Fog Plan A plan's job is not to prove completeness; it's to put the expensive-to-change decisions in front of the user while changing them is still free. Before writing: only low-risk residue converts to a labeled `[A]`. An open decision or taste item blocks the plan — run its listed resolver, record the answer, then plan. Update the ledger first; the plan cites only `Resolved` and `Assumed` items. Order by volatility, sourced from the ledger: 1. **Decisions you may want to tweak** — data model, interfaces, user-facing behavior. Each: the choice, one alternative considered (or "no real alternative" for territory findings), what changing it later costs. (From `Resolved`.) 2. **Assumptions standing** — the `[A]` batch: one line each, veto window, and the pivot signal — what observation during implementation forces revisiting it. 3. **Mechanical work** — compressed. The user trusts you here; reviewing it wastes their attention. Write the plan to `PLAN.md` beside the ledger (`PLAN-<task-slug>.md` if the ledger is slugged) — the two files together are the launch packet for a fresh session. End with the 2–4 items you need a yes or no on before starting. Target under ~400 words — a plan too long to read gets skimmed.