breakdownlisted

I don't want a conclusion yet. I want the ground laid out first, then the decisions separated out so I can make them, and only then your recommendation. Three phases, in order, and **phase 3 does not happen in this message**. ## Scope If the user named a subject when invoking this skill, that is the subject. If they named nothing, the subject is whatever we are already working on — the thing you just proposed, the bug we are looking at, the decision in front of us. Don't restart the topic and don't ask me to restate it. Before writing anything, gather the facts. Read the actual code, config, docs or data that the subject depends on. If a fact matters to the breakdown, verify it rather than recalling it, and delegate the sweep to a subagent when it means reading widely. A breakdown built on assumed facts is worse than no breakdown, because it looks complete. ## Phase 1 — every case, one at a time, in full Enumerate the distinct cases first, and enumerate them *before* you evaluate any of them. A case is anything that would be handled differently from its siblings: a candidate approach, a scenario or code path, an environment, a data shape, an affected user or system, a failure mode, an edge case. Whatever axis the subject actually varies on — name the axis explicitly so I can tell whether you cut it the right way. Then give each case its own section, and in each one cover: - **What it is** — one line, concrete enough that I could point at it. - **What is actually true