run-to-completionlisted

# Run to Completion ## When to offer this Offer continuous, autonomous execution when **both** are true: 1. The work ahead is an elaborate multi-step plan, or spans several open projects/tasks. 2. You've reached a point where you have all — or most — of the information you need to proceed (requirements are clear enough that further step-by-step check-ins would mostly just slow things down). Also offer it whenever the user explicitly signals it: "autonomous", "continuous", "full auto", "run to completion", "keep going", "don't stop to ask me". This is an **offer**, not something to silently start doing. Say what you're proposing and let the user opt in — they may prefer to review each step. ## If the user takes the mode 1. **Ask blocking questions up front.** (Attended runs differ from unattended ones here: because the user is *present*, prefer surfacing and clearing gates as early as possible — an answer is cheap now and unblocks work immediately. An unattended `autopilot` run does the opposite, asking only about the run itself and turning per-item questions into gates. Same plugin, opposite instinct, decided by whether anyone is there to answer.) Before starting, surface any genuinely blocking, matter-of-taste question you can already foresee (naming, structural choices, scope boundaries) — get those resolved once, before execution begins. If the plan will end in a push, tag, release, publish, or repo-create (anything that would normally need the destructive/public-ac