run-reworklisted

# Run rework A `fail` verdict is not the end of a task; it is the next instruction. Feed the worker exactly what is wrong, in the least disruptive way, and repeat until the work passes or the budget runs out. Bounding this loop is what stops a review disagreement from quietly consuming the developer's time. ## When to use - A review returns `fail` with at least one open `blocker` or `major` finding. - A rework round came back still failing, or the fix introduced a regression. - The developer asked for changes (request changes) on an otherwise complete task. ## When not to use - Only `minor`/`nit` findings remain: document them in the report and proceed; they do not block a pass. - The task is still running: `monitor-agents`. - No review has run yet: `review-work` first — you cannot send findings you do not have. ## Inputs - The open `blocker`/`major` findings recorded on the task (`python3 scripts/tm.py task show <id>`), each with severity, category, file, line, and suggestion. - The same worker that wrote the change, and its task for the current iteration and `max_iterations`. ## Procedure 1. **Check the budget.** Compare the task's iteration with `max_iterations` (`python3 scripts/tm.py task show <id>`). At the limit, do not send another round — escalate with the full report and one question via `escalate-decision`. 2. **Write a feedback brief of findings only.** Pull the open findings from the ledger (`task show <id>`); group them by sever