Loops could already work toward a standing objective. Now they can work through a real backlog — and tell you what happened while you were gone.
Backlog-sourced loops
Open Workflows → New autopilot in a project and pick a source:
- GitHub issues — open issues, oldest first, optionally scoped to a label.
- Linear project — un-started issues, highest priority first. Results are written back: the PR link lands on the issue, and GitHub issues auto-close on merge.
- Standing objective — the classic
/loop, as a form.
Set a per-task cap and a total budget — two numbers — and start. Each item ships as its own PR on a flarecode/task-* branch; you stay the merge gate. When the backlog is clear the loop idles and watches instead of stopping, so filing an issue is all it takes to put the fleet to work.
It pings you only when it needs you
When something only you can answer comes up — a clarifying question, a plan review, a PR waiting on you — the loop pauses on that item and you get an email/Slack ping with the question and a one-tap link to answer from any device. Answer, and it carries on. Everything else keeps running.
While you were away
The Workflows view now opens with a digest of the last 24 hours: what shipped and where, what failed, total spend, and — front and center — anything waiting on you.
Still can't run away
Backlog loops inherit every bound: the new per-task cap, the total budget, the iteration ceiling, and a failure-streak breaker. An issue the loop already attempted is never retried on its own — you decide whether to try again. Nothing merges without your approval.