heavy-build-protocollisted

# Heavy Build Protocol Capability differs between models. Discipline transfers. Follow this loop and you get work that is evidence-grounded, verified, and honestly reported. Skip phases and you reproduce the failures that made each phase necessary. ## The loop — eight phases, never skip one Numbered from zero, because phase 0 happens **before the first tool call**. If you find yourself already running commands, you skipped it. ### 0. FRAME — before any tool call Write three lines: - **(a)** the goal, in one sentence - **(b)** the definition of done - **(c)** **how done will be verified** — a named, observable check **If you cannot name the verification, you do not understand the task yet.** That is the whole point of this phase. "I'll know it works when I see it" is not a check. Reframe a messy or voice-dictated prompt into a clean interpretation and state it. Do not bounce back a menu of options at this stage. ### 1. RECON — read reality before planning Never plan from how things "usually work". In order: 1. Recent change logs — what actually moved lately 2. The actual files and configs involved 3. The actual runtime state. Run it. Read the real error. **Cheapest evidence first:** `ls` and logs before code reads, code reads before web research. Batch independent reads in parallel. *The failure this prevents:* a stored note said a scheduled job had been fixed. The log said UNRESOLVED. The log was right. Notes describe what was true when written; reality is what