A triage routine implements a ticket instead of queueing it

[suleimansh]

🤖 automated

Found while dogfooding the whole rotation on a throwaway repo (#1204, evidence in #1640).

What happened. Add quick-win work to AI Queue was fired on a repo with three open, planned tickets. It queued two of them — and implemented the third itself, committing a 14-line README.md change onto its own tf-triage-quick branch and opening a pull request for it.

The ticket it consumed (README gets a Usage section) never reached TODO_AGENTS.md. The queue entry it did write for another ticket even refers back to the work it had just done:

Must also update the ## Usage output block in README.md — that section landed via tf-triage-quick and this change invalidates it.

Why it is wrong. Triage promotes work; the drain does it. The split is what makes concurrency safe: a triage rewrites the shared queue document and so must stay one agent, while the drain fans out one agent per entry. A triage that also writes code:

• spends a drain's work in the one-agent lane, so the fan-out never gets it
• skips the queue, which is where a human can veto an item before an agent implements it
• pins its work to tf-triage-quick, a branch reused by every future triage — the next run then aborts on "branch already exists"

Not a code bug. Nothing in auto-pm.ts asks for this; the preset's prompt allowed it. The fix is in prompts/, and the check is that a triage's own branch carries only TODO_AGENTS.md.

Repro. Throwaway repo, three planned tickets, Run now on Add quick-win work to AI Queue.