Lanes

A Lane ties everything together: one ticketing source, one or more repos, and the modules to use. Think of it as a pipeline definition — "watch these tickets, work in these repos, behave this way." You'll typically have one Lane per project or repo-group, and every run (record) belongs to exactly one Lane.

Each Lane polls its ticketing source on its own interval. How a ticket is picked up depends on the tracker: on a label tracker (GitHub Issues) a ticket is eligible when it carries all of the Lane's discovery labels; on a status tracker (Jira / Shortcut) when it sits in the Lane's Ready status. Either way it's your per-ticket on/off switch, and it can route tickets to different Lanes (e.g. ai-eligible → a small-fixes Lane on a cheap model, ai-complex → a heavy Lane on a strong one).

Creating a Lane

Prerequisites: a Ticketing module and a Version Control module (Modules), each backed by a working credential. Then Lanes → New Lane. The required parts:

1. Basics — name, optional description, poll interval (default 30 s; 5 s–24 h), and the Enabled toggle. A disabled Lane keeps its config but stops polling.
2. Ticketing — pick your Ticketing module. The form then adapts to the tracker: a label tracker (GitHub) asks for discovery labels (multiple AND together; most Lanes need one); a status tracker (Jira / Shortcut) asks for a Ready status plus optional per-stage status moves (see Lifecycle below).
3. Version Control — pick your Version Control module.
4. Workspace Repos — at least one repo. Press Verify on each row to confirm the credential can reach it before you rely on it.

Save, and the Lane starts polling immediately if enabled. Everything below is optional tuning.

Workspace repos

Each repo row has a name (owner/repo; on Azure Repos, project/repo) and a role — a short label like primary, api, or frontend that becomes the repo's folder name in the agent's workspace. Roles must be unique within a Lane — they become folder names, so two repos with the same role collide.

• Multi-repo Lanes: add several repos and a single ticket gets a workspace containing all of them — the agents make coordinated changes across repos, and every repo that ends up modified gets its own PR in one run. Use roles the agents can understand (frontend / backend beats repo1 / repo2).
• Advanced (per repo): an explicit clone URL (auto-derived from the name if blank) and a per-repo base branch override.
• Base branch precedence: per-repo → Lane default → Version Control module default → main.

Lifecycle

As a run progresses, the Lane updates the ticket so anyone looking at the board sees the state without opening LoomAI. The Ticketing section is adapter-aware — it speaks whichever vocabulary your tracker uses:

• Label trackers (GitHub) — per stage, labels to add and remove.
• Status trackers (Jira / Shortcut) — per stage, a single status to move the ticket to, chosen from the tracker's own workflow statuses.

The stages are the same either way. Only Ready is required; the rest are optional — leave a stage blank to skip it.

Stage	Fires when
Ready (required)	The trigger — a ticket here is picked up
In Progress	The ticket is picked up
Done	The run finishes (the PR is opened)
Failed	The run fails
Cancelled	The run is cancelled

Updates are best-effort — a tracker API hiccup is logged but never fails the run. (Dedup is independent of this: a finished ticket is tracked by its run record, so it's never re-picked-up by accident even if a label or status update didn't land.)

Re-running a finished ticket

A finished ticket already has a run record, so it won't be picked up again on its own — re-running takes a deliberate, distinct signal:

• Label trackers — add the Lane's re-run label (default ai-redo) to the finished ticket. It's removed once the re-run starts. (Re-applying the discovery label does nothing — the ticket already has a record.)
• Status trackers — move the ticket back to the Ready status. Loom sees it's back in Ready after a finished run and re-runs it.

Status trackers: map In Progress. The move-back-to-Ready re-run only works if In Progress is mapped to a status — that's what moves the ticket out of Ready on pickup, so its later return to Ready is an unambiguous "do it again." Leave In Progress blank and a finished ticket just sits in Ready; re-runs then need the Re-run button on the record instead. (Mapping it also keeps the board honest — otherwise a ticket being actively worked still shows as Ready.)

Model

Per-Lane override of the global default model from Settings. Leave blank to inherit. This is the main cost/quality routing lever: cheaper models for low-risk Lanes, stronger models for complex ones.

AGENTS.md

On by default. Before each ticket runs, any repo in the Lane missing an AGENTS.md gets one generated into its workspace — so the agents have the repo's conventions during planning and coding. The generated file is committed as part of the ticket's PR. Turn it off to skip this Lane-wide.

Coding Standards

Attach a Coding Standards module and its markdown is written to each repo's workspace as CODING-STANDARD.md at the start of every run. See Modules.

Blueprints

The agents' per-repo memory layer — .agent/ docs they read before exploring the code. Attaching a Blueprint module is the master switch; without one, docs are neither read nor written. With one attached:

• Writeback mode — enabled (default: runs update the docs as they learn), read-only (consult but never modify — good while evaluating), or journal-only (queue learnings for inspection before they're folded in).
• Auto-generate (off by default) — when a ticket runs against a repo with no .agent/ yet, generate one first as a pre-step; it's swept into that ticket's PR. Off by default because a full repo index is a sizable one-time run.
• Generate blueprints (on saved Lanes) — runs the indexer across every repo on the Lane right now. Repos that already have .agent/ are skipped; missing ones get an indexer run that commits the docs and opens a dedicated PR. Save the Lane first if you changed repos or branches.

Agent Tuning (beta)

Attach an Agent Tuning module to layer your custom per-agent instructions onto the run. See Modules.

Silent mode (beta)

For working a ticket without the orchestrator visibly touching it. With silent mode on, the ticket is picked up, worked, and the branch is pushed — but no ticket comments are posted, no labels change, no PR opens, and no notifications fire. Everything that would have been posted (comments, labels, the PR title and body) is saved on the record so you can read or copy it later and open the PR yourself.

Commit identity controls who the commits appear authored by. Leave it blank and silent mode auto-detects the identity from your Version Control token; set name + email to force a specific author.

Messaging

Attach one or more channels (Discord / Slack modules) and pick each one's hooks — PR opened, Run failed, or both. The same channel module can serve many Lanes with different hooks on each.

Workflow

The phase list at the bottom — which agents run, in what order — is read-only and shows the engine default (PM → Architect → Test Author → Developer → QA → DevOps). A per-Lane workflow editor is planned.

Day-to-day

• Pause a Lane — uncheck Enabled; config and history stay put.
• Edit safely — each run snapshots the Lane's config when the ticket is picked up, so edits never affect runs already in flight, only future pickups.
• Run the indexer for one repo — each repo row on a saved Lane has a Run indexer button for a targeted blueprint refresh.