Automations

Every project has one Automation section that controls how SupaCloud reacts to events on that project without a human starting a task by hand. It consolidates “what is this project allowed to do automatically, and how supervised is it” into a single place: an autodev mode, an orthogonal PR-review lane, and a shared set of supervision controls.

The autodev mode

The autodev mode is one selector with three values. It decides what the project does with its issues.

Mode	What it does
Off	The project imports its issues but dispatches nothing.
Simple	Each new issue is worked directly to a pull request, in arrival order (first in, first out).
Backlog	Issues are collected, classified and prioritised, then dispatched in priority order — bounded by the autonomy level, the concurrency caps and the budget.

Simple and Backlog run the same scan → classify → dispatch pipeline; they differ only in the order they pick work off the queue — Simple takes the oldest queued item first, Backlog takes the highest-priority one. Both produce changes according to the project’s merge policy. Off leaves the pipeline disarmed.

The orthogonal PR-review lane

One further automation runs on events, independently of the autodev mode — a project can turn it on in any combination with the mode.

Lane	What fires it	What it does
PR-review	A pull-request webhook	Runs the auto-developer over an incoming pull request.

PR-review is orthogonal to the autodev mode: turning it on does not change the mode, and a Backlog project can also review pull requests. It carries its own supervision controls (below).

The shared controls

The same control row governs how supervised and how constrained each automation is, across the autodev mode and the PR-review lane. These are the levers worth understanding.

Severity

A severity gate filters which events the automation acts on. An event below the configured minimum severity is ignored. Severity is derived from the event’s labels (and, for backlog and PR-review, its priority): a label like critical, blocker or outage is critical; high, urgent or security is high; low, minor or docs is low; everything else defaults to medium. Leaving the severity at Any applies no gate.

Approval mode

Approval mode decides how much of a human is in the loop before work is merged. The exact options depend on the automation, but they map onto the same idea:

Direct / none — no extra human gate; the automation proceeds to its merge policy on its own.
Draft first / PR only — the automation opens a pull request and stops there; a human reviews and merges.
Require review / human gate — a human approval is required before the change can complete. For backlog this is the human_gate mode, which makes the workflow’s gate node hold the run until a person approves.
Concept first — before writing any code, the automation produces a code-grounded implementation concept and pauses for a human to review it. Once a person approves, the same run continues and implements the approved concept.

Concept first puts a human approval node in the middle of a single run, not between two runs: the concept and the implementation are one continuous task, so the approver sees the agent’s grounded plan in context before it touches the code. It composes orthogonally with the merge policy and the audit / review gate — concept approval governs what gets built, the merge policy and review gate still govern how the result is merged. It is available for the backlog / autodev lane.

For a backlog dispatch, approval mode is expressed as the merge policy: PR only (open a PR and stop), Auto-merge on green (merge once every gate passes), or Full auto.

Completion action

The completion action decides what happens to the linked issue when an issue-linked task finishes. It is a per-automation setting with three values:

Close (the default) — comment on the linked issue with the closing summary and then close or transition it.
Comment — post the closing summary but leave the issue open.
Nothing — neither comment nor transition the issue (a full opt-out).

The completion action governs issue-linked tasks: the PR-review lane and any task you launch by hand from an issue (run --issue). An autonomously dispatched backlog item is not issue-linked at the task level — it carries a backlog reference, not an issue reference — so its source issue is closed by the merged pull request’s Fixes #N, and Comment / Nothing therefore do not apply to backlog dispatch. The completion action is read from the highest-precedence enabled automation arm.

Agent profile

The Agent picker sets which agent (and, through an agent profile, which model, effort and capability set) the automation launches its runs with. A backlog automation can pin an agent profile that the workflow’s implement node prefers over the project’s default probe agent. Left unset, the automation falls back to the project’s configured agent.

Classifier

When a project is in Backlog mode, a classifier reads each imported issue and tags it before it is dispatched. The classifier is configured right in the backlog settings and has two variants:

Rules — a fast, deterministic classifier driven by the issue’s labels, title and body. It needs no model and no credential.
LLM — a model classifies the issue. You choose the model, the system prompt it runs with, and the categories (the kind taxonomy) it may assign.

The classifier sorts each issue along three axes:

Axis	What it captures
Kind	What the issue is — bug, feature, chore, question (or your own categories under the LLM variant).
Priority → severity	How urgent it is. Priority orders the backlog queue; it also maps to a severity the severity gate reads.
Scope (Umfang)	How big the change is — small, medium or large. Scope nudges the routing effort up for a large change and down for a small one.

The severity always sets a floor on the effort the router spends; scope nudges within that floor, so a large-scope issue gets a little more effort and a small-scope one a little less. Both Simple and Backlog classify; Simple just ignores the priority ordering and works items first-in-first-out.

Review

Turning on Review runs an independent forensic audit after the implement stage of a backlog item. If that audit fails, SupaCloud escalates the item’s routed effort one tier and re-queues it for another attempt — a no-op once the item is already at the highest effort, where the failure simply stands.

Review can also run as an explicitly bounded multi-round loop: a convergence level gates whether an item is eligible at all (based on its classified severity), and the loop is then bounded by a maximum number of rounds and a maximum cost. This lets a hard item iterate toward a clean audit without ever running unbounded.

Autonomy level

Each project carries an autonomy level that inherits from the workspace and is clamped by the plan ceiling and the onboarding cap. The level maps to a policy vector — whether the auto-dispatcher may run at all, how readily a tool call asks a human for clarification, an effort bias, and the merge ceiling — across five named bands:

Band	Dispatch	Merge ceiling
Manuell (0–24)	Off — manual trigger only	PR only
Assistiert (25–49)	On (manual trigger)	PR only
Überwacht (50–74)	On	Auto-merge on green
Autonom (75–99)	On	Auto-merge on green
Entfesselt (100)	On	Full auto

The level is monotonic: as the slider rises, dispatch turns on and stays on, the ask-threshold only relaxes, and the merge ceiling only loosens. An automation may additionally pin an autonomy override that is lower than the workspace entitlement (it can never raise it past the plan ceiling). An override that resolves to 0 is a hard pause.

Blast radius

The blast radius is the hard, fail-closed boundary on what an autonomous run can touch — independent of the autonomy level or any confirmation token. It has two parts, both set in the Automation section.

Denied tools

A denied-tools denylist names MCP tools (for example app.deploy) that the run may never call. The effective denylist for a run is the union of the project-level denylist and every enabled automation’s denylist — a tool denied by any applicable source is denied for the run. A deny here is absolute: it survives a valid deploy confirmation and even the level-100 Entfesselt slider, because the check runs before the tool handler ever sees a token.

Environment scope

The environment scope restricts which environment class the run may act on: all (no restriction), or one of production, staging, development. The deploy and migration tools are production-class — an automation scoped to staging or development cannot run them. When several enabled automations apply, the narrowest concrete scope wins, so a run can never act outside the tightest configured environment. An unknown stored scope fails closed to the most restrictive (development).

How it all composes

For a single dispatched backlog run the gates compose, fail-closed, in this order: the global dispatch kill-switch, onboarding mode, quiet hours, the workspace concurrency ceiling, the project’s autonomy level / override and its dispatch_enabled band, provider quota headroom, the budget hard-stops, and finally — per tool call inside the run — the blast radius. Each gate can only narrow what the previous one allowed; none can widen it.