Run the backlog

The autonomous backlog lets SupaCloud scan a project’s open issues, classify and prioritise them, and dispatch agent runs to work through them — bounded by budgets, a concurrency ceiling, quiet hours, and the workspace autonomy level. This page covers the operator tasks: turning backlog mode on, reading the workspace board, setting the safety limits, and launching a controlled dispatch.

Note

Backlog is one of the project’s three autodev modes (Off · Simple · Backlog). Simple and Backlog both run the dispatch pipeline; PR-review is a separate, orthogonal lane. For the mode model and how approval mode, the classifier, agent profile and blast radius interact, see Automations and Choose the autodev mode.

Put a project in Backlog mode

1. Open the project, then open its Edit modal.
2. In the Automation section, set the autodev mode to Backlog. (Set it to Simple to work each issue directly to a pull request in arrival order instead; Off imports issues but dispatches nothing.)
3. Pick the Approval mode (the backlog merge policy): PR only (open a PR and stop), Auto-merge on green (merge when all gates pass), or Full auto.
4. Optionally set the Classifier, the Agent, the Severity gate and the Blast radius (environment scope + denied-tools denylist).
5. Save. The project’s backlog workflow is materialised so dispatched items have something to run on.

Whatever the mode, SupaCloud imports the project’s open issues — from the Git forge, Linear and Notion — and the scan/classify sweep records new ones as queued items. Backlog mode then dispatches them in priority order.

View the workspace backlog board

Open Backlog in the sidebar.

The page has a Project ⇄ Workspace scope toggle:

• Workspace scope (the default) is a cross-project, read-only roll-up of every backlog-enabled project in the workspace, plus the manual dispatch panel. This option only appears once the workspace has two or more backlog-enabled projects — below that there is no cross-project picture worth showing.
• Project scope lists the workspace’s projects; opening one shows its interactive board, where you can drag cards between lanes, reorder priority, and drag a finished card to Done.

Each board has seven fixed-order columns: classified → queued → in_progress → in_review → done, plus the needs_info and blocked lanes. The active pipeline runs left to right; done, needs_info and blocked are the terminal-ish lanes.

Read the dispatch panel

The dispatch panel above the workspace board is the live view of how the dispatcher is working. It shows:

• the dispatch rate — how many backlog runs were dispatched in the recent window;
• the last tick — how long ago the background scheduler last ran (a growing value means the ticker has stalled);
• the in-flight count — backlog runs running across the workspace right now;
• the tick interval — the scheduler’s cadence;
• a per-project row for each backlog project, showing its effective cap, its queued items and any blocked reason (why that project is not dispatching).

The panel collapses to a single status line when you do not need the detail — click it to expand the full breakdown again.

Note

Dispatch can be paused two ways. As an owner you can pause your whole workspace from its settings; an instance operator can also throw the instance-wide global dispatch red button. Dispatch runs only when both allow it — a paused workspace or a disabled global switch shows as the blocked reason in the panel.

Set the concurrency ceiling

The workspace concurrency ceiling (max_backlog_concurrent) caps the sum of in-flight backlog runs across all the workspace’s projects. It is checked first on every dispatch tick, in addition to each project’s own concurrency cap — the effective cap is the per-project cap and the workspace ceiling and the autonomy level’s concurrency factor, whichever is lowest.

An unset ceiling means uncapped: only the per-project caps bound each project. The resolved ceiling and the remaining free slots are surfaced on the workspace backlog status above the board, so you can see why dispatch is (or is not) launching.

Set quiet hours

Quiet hours pause dispatch during a daily window — scan and classify keep running, so items still accumulate as queued; only the launch is suppressed.

1. Open Settings → Workspace and find the Quiet hours card.
2. Set a Start and End time. Times are stored and evaluated in UTC.
3. Save.

The window is a half-open interval [start, end). A window that crosses midnight (for example 22:00 → 06:00) is supported. Leaving both fields empty clears the window (dispatch is never suppressed); a half-filled pair is rejected — set both or neither.

Note

Quiet hours are one of several dispatch gates. Dispatch is also suppressed while the workspace is in onboarding mode, when the global dispatch kill-switch is off, when the workspace concurrency ceiling is full, when the autonomy level resolves to 0, or when provider quota is near exhaustion.

Run a dispatch dry-run, then dispatch

The manual dispatch panel on the workspace board runs a dry-run preview before you launch anything. A bodiless dispatch request is always a safe preview — it writes nothing and launches nothing.

1. On the workspace board, the Dispatch panel loads a dry-run preview on mount. Click Refresh to re-run it.
2. Read the preview:
   • Queued items — an upper bound on how many runs could launch (per-project caps and budgets are not simulated here, so the real count may be lower).
   • Autonomy level — the resolved autonomy ceiling for the workspace.
   • A suppressed banner with a human reason when a gate blocks dispatch (onboarding, ceiling reached, autonomy 0, global kill-switch off, quiet hours, or provider quota near exhaustion).
3. If nothing blocks and the queue is non-empty, Dispatch now is enabled. Clicking it commits the launch, reports how many runs started, and re-previews so the panel reflects the post-launch board.

A real dispatch requires the CreateRun capability and writes an audit event. The same gates the preview reports are enforced on the live launch, so the preview never disagrees with what actually happens.

Note

Dispatch also runs automatically on the background scheduler tick when the autonomy level is at Assistiert or above. At the Manuell band the auto-dispatcher is off entirely and only a manual Dispatch now can launch. See Automations for the bands.

Tune the dev pipeline

Each backlog automation runs a dev pipeline with draft, implement and review stages. The pipeline carries two layers of tuning:

• Per-stage expert overrides — a per-stage harness, model and effort for the draft, implement and review stages, stamped onto the materialised workflow nodes. These are configured through the API / the raw pipeline_config this release — there is no dedicated form editor in the web UI for the per-stage map yet.
• Return-to-sender loop — the Review toggle and the loop knobs (convergence level, max rounds, max cost) are surfaced in the project’s Automation section. With Review on, an independent forensic audit runs after implement; a failed audit escalates the item’s effort one tier and re-queues it, or — when the return-to-sender loop is enabled — runs a bounded multi-round loop.

See Automations for how the review gate and the convergence loop behave.

See also

• Automations
• Runs and tasks
• Entitlements and MCP tiers