Loops

A loop works assigned issues for you on a schedule or when something happens. Each firing is an ordinary bounded run, the same kind the run commands start, so the run policy’s limits apply.

overlane loop new Nightly --every 1440 --filter priority=P0
overlane loop new OnAssign --on issue.assigned
overlane loop list
overlane loop fire lop_ab12cd34ef56gh78
overlane loop update lop_ab12cd34ef56gh78 --enabled off
overlane loop archive lop_ab12cd34ef56gh78
overlane loop restore lop_ab12cd34ef56gh78

An archived loop never fires. Deleting a loop archives it first, so it can be restored for 30 days. See Archive, restore and delete.

Triggers

What a firing does

1. It starts a run. If the project’s run policy is paused, the run is refused and the loop stops with reason paused.
2. It picks the issues assigned to the loop’s agent that match the loop’s filter and have a ready or paused task. The filter is the same field filter as a saved view.
3. It claims their tasks in queue order (priority, then rank) under the run, up to the run’s task budget. When the budget is spent it stops with budget_tasks.
4. If it claimed nothing, it ends the run. Otherwise the run stays open for the agent to work through the claimed tasks and end.

A repeated firing finds those tasks already running and claims nothing more.

No inference

Loops use no model. The filter, the order and the budgets are fixed rules. Nothing in an issue’s text can change what a loop does.

Roles

An agent defines, changes and deletes loops, and members can too through their role. Defining a loop is the issue triage autonomy class: nothing waits under autonomous, an approval is needed under supervised, and a person under manual. A loop’s filter, order and budgets are fixed rules, so a loop cannot widen its own reach. Anyone who can write can fire a loop that exists; viewers cannot.

Commands

overlane loop new, loop list, loop fire, loop update, loop delete. Run limits are described with the run commands, for example overlane run start.