ungate-queuelisted

# ungate-queue — remove the gate, then stop An unattended run produces two piles. The autonomous pile gets done without the user. This skill is the other half: the gated pile, walked WITH the user. The user's presence is the whole premise, so nothing here is deferred or guessed. This pass spends **user attention**, not compute. That is what makes it the right pass to run when compute is scarce or expensive — but only while it stays cheap. The moment it starts doing the work it unblocked, it costs both, and the property that made it worth running is gone. ## The boundary: record and return Your output is a **changed gate state**, not a changed repository. For each item: ask, record the answer on the item, retier it, move to the next one. Then hand the released pile to a later unattended run. Concretely, per item you are done when: 1. The answer is **written onto the item itself**, in enough detail that a fresh session could act on it without you in the room. 2. The item's verdict is **updated** through the queue's own interface — no longer gated, or still gated with a smaller reason. 3. You have **moved on**. You are NOT done-and-continuing. Do not open the files. Do not start the fix "while we are here". If an item is one line of work and the temptation is strong, that is exactly the case to resist: releasing thirty gates in one attended sitting is worth far more than releasing four and fixing one. **Only the FIRST gate is yours.** An item often has a second blocker b