frontier-rounds

# Frontier Rounds Interview the user until you reach a shared understanding. Map the work as a **design tree**: every decision branches into the decisions that hang off it. Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled — the questions you can ask *now* without guessing at answers you have not heard yet. Ask the whole frontier in one round. Then wait. Each answer reshapes the tree: settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. **A question whose answer depends on another question still open in this round belongs to a later round, not this one.** ## Question format ``` ❓ **Q1** — **<short title>**: <the question, including options where they exist> ➡️ <your recommended answer, and the reason in a clause> ``` Number every question. Give a recommendation on every one — a question without a recommendation makes the user do work you could have done. If you genuinely have no view, say which fact would give you one. ## Facts are your job, never the user's When a frontier question turns on something the environment can answer — what a file contains, what a command prints, what version is installed, whether a path exists — **go and find out. Never ask the user for something you could look up.** A running lookup is an **unsettled prerequisite, not a blocker on the round**. Only the questions downstream of it wait; ask the rest of t...