execute-unattended

execute-unattended — keep moving, stop only for gates

This is the execution engine. Your goal is momentum: do not stop between items, and do not half-do anything. Momentum means not pausing to report or to ask about routine next steps — it does not mean skipping the confirmations described under "What autonomy does not relax" below. Those are the one class of stop that stays.

Wrap-and-switch

The moment an item turns out to need user input, stop that item immediately. Move to the next Tier 1 item. Do not wait and do not idle: an unattended run has nobody to answer, so a question asked mid-run buys nothing and costs the rest of the queue. Carry the question to the closing wrap instead, where it becomes a gated-list entry the user can answer in one pass.

When you stop, do three things, not one:

1. Retier the item in the store, not just in your notes. A gate you only mention in the wrap is gone as soon as the wrap scrolls past; the store is what the next run reads. If the tracker has a blocked state, set it.
2. Record the gate reason — the specific question, not "needs input".
3. Name the partial progress in that reason. State what is already done and what the next run should therefore not redo. Without this the next run cannot tell a fresh item from a half-finished one, so it starts over — and the first half is paid for twice.

Work up to a known gate on purpose

Wrap-and-switch above is reactive: it fires when an item turns out to need a human. Make it anticipatory too. When you can already see that an item ends at a gate, do not skip the item — deliberately do the part that sits before the gate, then stop there and record it.

This is the standard move, not an exception squeezed under granularity. Most gated items are not gated end to end; they are a stretch of ordinary work followed by one question. Skipping the whole item because it finishes at a question leaves real, autonomous progress on the table, and it is progress nobody else is going to make while the user is away.