---
title: Dev Pipeline panel
---

# Dev Pipeline panel

## What it is

A built-in sidebar panel that oversees the **dev-pipeline workflow** in one place:
the pipeline runs happening right now, the git worktrees that have piled up per repo
(with one-click safe cleanup), the gate auto-approval switch, and the auto-lander (its
on/off, which repos it watches, live status, and a history of every branch it has
landed).

It is **mostly oversight, plus real controls** — it doesn't _run_ a pipeline (a run
lives in a Claude session), but it does two consequential things directly: the Live
view's **Needs-you strip approves a gate in one tap** (`approveGate` — the approval
lands in the session's chat as your own message), and **Adopt spawns a real, paid
Claude session** to resume a stranded run. Everything else is reads and settings
toggles. It is a built-in _virtual project_ (it docks in the main panel beside the
projects sidebar and hosts no Claude sessions of its own).

**The auto-lander comes on with the Dev Pipeline — once the Dev Pipeline is on.** You do
not switch the lander on separately, and you do not have to add repositories by hand:
turning the Dev Pipeline on arms the lander for the repositories the Dev Pipeline is
already set up for. This used to need four separate opt-ins — the master toggle, adding a
repo, that repo's enable, and clearing its observe-only mode — and gave no hint when it
was only half-configured, so it would sit doing nothing while finished branches
piled up waiting to land.

**Is the Dev Pipeline on?** It is its own setting (`devPipelinePanelEnabled`), and it
defaults to **off**. There is no in-app control for it, so on a standard install it is off
and nothing behind the panel is armed: the auto-lander does not run, the worktree-mutation
lockdown is not armed, and daily maintenance and git-store maintenance do not run. The
panel itself is still visible and fully usable either way — a shipped surface, never
hidden — but do not read "the auto-lander is on by default" into the paragraph above
unless the Dev Pipeline is genuinely on. (Agents and contributors: **How it works** below
names the code path and every reader of that setting.)

Your own choice always wins. Turn the lander off and it stays off even with the Dev
Pipeline on; turn it on and it stays on regardless. Add repositories yourself and
that list is used verbatim instead of the derived one. Nothing is written to your
settings on your behalf — the default is simply _computed_ until you express a
preference, so there is nothing to undo.

**Works on mobile too.** The panel is available over Web Access on your phone, not
just the desktop — it's all data read-outs and toggles, so you can watch live runs,
flip auto-approve, and control the auto-lander remotely. (The auto-lander itself
runs on your desktop machine; the phone just drives it, like any other setting.)

> **Shipped — visible to everyone.** The `dev-pipeline-panel` registry entry carries
> `status: 'shipped'`, which the gate reads BEFORE it ever looks at a setting, so
> `visible()` returns true for every user and `devPipelinePanelEnabled` is IGNORED
> **for the sidebar reveal only**. There is nothing to reveal: no Lab toggle to flip, and the
> `AMC_SHOW_DEV_PIPELINE_PANEL` env var is inert. That is the _visibility_ gate and nothing
> else — the same setting is the Dev Pipeline's own opt-in, read directly by the background
> behaviours (the auto-lander, the worktree-mutation lockdown, daily maintenance, git-store
> maintenance), and it defaults to **off**. See "Is the Dev Pipeline on?" above.

## Where to find it

The panel is organized as a **left rail — Live, Timing, Agent Board, Auto-lander, QA Fleet, and
Setup** — and clicking one fills the panel, full height. (**Agent Board** shows only when you've
turned the Agent Status Board on — see below; the other five are always there.) On a phone the rail
becomes a row of tabs across the top (it works over Web Access).

## How it behaves

**QA Fleet** reads the QA fleet ledger — the record the audit pipeline writes as it exercises your
features — and turns it into a per-feature **E2E pass/fail** list, a **findings** list you can
triage in place (resolve / dismiss / reopen, with undo), and a **coverage** view that ranks features
by how long it has been since one was last exercised. It refreshes every 30 seconds while you are
looking at it, because the fleet runs continuously in the background and a load-once view went stale
the moment its own results landed.

**Live** holds your active runs _and_ worktrees together, grouped under collapsible
**project headers** — everything for one repo in one place, with a per-project count
covering all three things the group holds (e.g. _"3 runs · 2 worktrees · 5 ready branches"_,
so a repo holding only stranded ready-to-merge branches never collapses to a card with no
count at all); a project waiting at a gate sorts to the top, and you can
collapse a repo you don't care about. **"Waiting" means waiting on YOU** — parked at an
approval gate (Plan…Docs). A run sitting at the terminal ready-to-merge gate is waiting on
the auto-lander, not on you, so it neither badges the group nor suppresses the
_"✓ All clear — nothing is waiting on you"_ line. That one predicate feeds the all-clear
line, the amber group pill, and which runs show a Stop, so they can never contradict
each other. On both Live and Timing, each run row shows **which
repo it's working in** (the repo folder name, derived from the project's `folderPath`, with
the full path on hover so two same-name checkouts on different drives read apart). **Timing** is the run-time monitor (below); **Agent Board** shows the full Agent Status Board in-panel (below). **Auto-lander**
is the read-mostly watch tab — the lander's live status, the queue of branches marked
ready-to-merge, and the land history (landed / conflict / set aside). **QA Fleet** is the QA
results view — open findings with in-app triage, E2E pass/fail, and coverage (below). **Setup**
is the single home for every control — gate auto-approval, the workflow companions, which repos
are covered, custom phases, the auto-lander's own switches, automatic master catch-up, worktree
cleanup, daily maintenance,
the testing-gate bypass, git guardrails, developer guardrails and Repo Foundations — organized as collapsible cards grouped into
**Pipeline behavior**, **Automation**, and **Safety & setup**, all closed until you open the one
you need. The split is deliberate: you _watch_ the lander on its own tab and _change_ it in Setup.

**Needs you — the strip that answers "how do I approve a gate?".** Live LEADS with a
**Needs-you strip** (amber, the design system's Needs-You colour): every run currently parked
at a human approval gate, lifted out of its project card so you act on it at a glance instead
of hunting a pill inside a collapsed group. Each row gives you three things:

- **Approve** — one tap clears that gate. You don't have to open the session or type
  anything: Omniscio sends `approved` into that session **as your own message**, carrying a
  small _auto-approved_ tag, so the transcript reads exactly as if you'd typed it. This is
  the non-coder's answer to "the run is waiting on me and I don't want to use the chat".
- **Stop** — end a run parked at a gate (decline a plan, kill a run gone wrong) without
  jumping into the session. It **confirms first** ("Stop this run?"), and it leaves the
  worktree and its work **intact** — you can reopen or restart it later. The same control
  also sits on the run row itself.
- **Open** — jump to that session's chat when you'd rather answer properly.

An in-flight Approve or Stop **disables that whole row** (one busy guard shared by both), so
the two can't race or double-fire; the panel re-hydrates after the send, and a run that
already advanced — auto-approved, or you replied in-session — simply drops out of the strip.
When runs exist but none is waiting, the strip is replaced by a plain **"✓ All clear —
nothing is waiting on you."** line.

**Freshness + manual refresh.** Above the list sits an **"Updated \<ago\>"** cue and a
**Refresh** button (`data-ui-anchor="dev-pipeline-live-refresh"`), shown in BOTH the empty and
populated states so you are never left wondering whether what you're reading is stale. The
list also refreshes itself on a timer while the panel is open.

**Active runs.** Every live session that is running a dev-pipeline, with the step
it's on (Plan → Red Team → Build → Elegance → Docs → Ready) and whether it's
**waiting at a gate** for you — the gate label is always a short, clean tag and the chip
is width-capped, so a long underlying status line can never spill off the row. A run parked
at a gate also shows a live **`waiting <time>`** counter (amber), so a run stuck on _your_
approval is obvious at a glance. Each row also shows the run's **approximate spend so far**
(`≈$…`) — run-scoped, not the session total, so chatting in the same session before starting
the pipeline never inflates it. Click a run to jump straight to that session's chat. The
list refreshes itself while the panel is open and costs nothing when it's closed. (A
pipeline run that isn't inside a git repo may not appear — that's a known v1 limit.)

**Timing (run monitor).** Where each recent run's time — and **money** — actually went, so
you can spot bottlenecks. A **summary strip** leads with the totals — time spent **working**,
time **waiting on you** at a gate, time **stuck** (rate-limited / errored / blocked), the
average wait per run, a **Spend** tile totaling the listed runs' approximate cost, and the
single **biggest stall**. Below it, a list of **recent runs**, each with its `≈$` run cost,
a **"Landed ✓"** mark once the auto-lander has merged that run's branch (or a **"Couldn't
land"** mark, with the reason, when the lander set the branch aside instead of landing it — so
a finished run reads as done or explains itself rather than just vanishing), and a working /
waiting-on-you / stuck
bar (green / amber / red) you can expand for the
per-phase breakdown — including **per-phase spend**, so you can see whether the money went to
the build, the docs, or the red team. The time split — waiting-on-you vs. stuck vs. total —
is **exact**; per-phase labels and all `≈$` figures are best-effort (costs are deltas between
snapshots taken at each run transition; a run recorded before cost snapshots shipped shows
"—", never a made-up $0). Unlike Live, Timing **keeps finished runs** — it reads a durable
record that outlives a run's scratch files — and costs nothing when the tab is closed. Runs
that finished before this shipped have no history.

**Narrowing the window.** A **7 days / 30 days / All time** picker sits at the top of the tab
and filters the whole view — the list, the tiles and the trend together — newest first within
the window you chose. It is rendered above the loading and empty states on purpose, so a window
that happens to hold no runs still offers you the way back to a wider one rather than an empty
screen. Choosing **All time** shows everything on record.

**What Timing's numbers cover.** The read returns the newest 100 runs, and the heading counts
honestly rather than printing the page size as a total — **"Recent runs (showing 100 of 4,000)"**
when there are more than fit, **"(4,000)"** when that is all of them. The same cap applies to the
summary strip above it, so one scope line sits directly under the tiles — _"These totals cover the
100 most recent runs below, not all 4,000."_, or _"These totals cover the N runs below."_ once
nothing is being left out. Only the **Spend** tile repeats the caveat inline (_"Spend (≈, these
runs)"_); the four duration tiles stay plain and are covered by that one line rather than
repeating the same qualifier four times over.

**Agent Board.** The full **Agent Status Board** — every agent Omniscio has launched, each a
card with its status, workspace, dev-pipeline phase/gate, and live to-do list — right
inside the panel, so you don't have to leave to check on your agents. Click a card to jump
to that session. It's the **same board** as the top-right **Agent Board** toolbar icon (both
open it), and it's **view-only**. The tab appears only when the Agent Status Board feature is
on (**Settings → Workflow → "Agent Status Board"**); turn that off while you're on the tab and
the panel quietly falls back to Live.

**Worktrees.** Per repository, every git worktree that exists — the isolated copies
dev-pipeline runs and sessions create — so the pile-up is visible in one place. They
normally live in a `<repo>-worktrees` folder beside the repo; if Omniscio ever has to
put one somewhere else it says so with an inbox card rather than moving it quietly
(see [dev-pipeline.md](dev-pipeline.md)). Each
row shows its branch, whether a live session still **owns** it or it's **orphaned**,
its pipeline step, a **ready-to-merge** badge, and how long since it was touched. You
can **open** its folder, **jump** to the owning session, or **remove** it — and Remove
is heavily guarded: it refuses anything **marked do-not-delete**, anything a live session is
using, anything with unsaved changes, and anything whose commits haven't landed yet; it can
never touch your main checkout, and it refuses anything that is no longer a recognized
worktree. A per-repo **"Remove all safe-to-remove"** clears the safe ones in one click.

**"Marked do-not-delete" outranks everything.** If you (or an agent) put a keep marker on a
worktree — a note in its branch description saying not to delete it — that veto is **absolute**:
it holds even when the worktree looks perfectly safe to remove, and it is read **fail-closed**,
so if the marker can't be read the worktree is kept rather than deleted. It exists because a
pinned worktree was once reaped mid-run and work was lost. When Remove refuses for this reason
the toast says _"Couldn't remove X: it is marked do-not-delete"_ — clear the marker on that
branch if you genuinely want it gone.
It also lists branches marked ready-to-merge that have no worktree (the stranded ones).

**Long lists say how long they are.** Every list on this panel — worktrees, ready branches,
cleanup run history, the worktree verdict grid, the restore list, the auto-lander's queue and
its activity log — paints the first 50 rows, states the true total in its heading
(_"Worktrees (showing 50 of 312)"_ when capped, _"(312)"_ when whole), and offers a
**"Show N more"**. Same 50-row first-paint limit, and the same reason, as the archived-session
sidebar. Expanding a list is **your** state: it survives the panel's background refresh
rather than snapping back to page one every tick.

**Stale runs + Adopt.** A worktree holding a pipeline run **left mid-flight by a dead
session** (the session was deleted or ended — not merely idle) gets a grey **"Stale run"**
pill and an **Adopt** button. One click spawns a fresh session _inside that worktree_ that
picks the run up exactly where it stopped — the run's saved state names its phase, plan,
and history, so nothing is redone. Adopt is deliberately cautious: it re-checks every fact
at click time (a run whose original session is still alive anywhere is never adoptable),
two simultaneous clicks can't start two sessions, and a failed adopt leaves everything
retryable. Adopting spawns a real (paid) agent session, so it **asks you to confirm first** —
naming the worktree, saying a real AI session starts, that it costs money, and that it may end
by marking the branch ready to merge. (Every other consequential control in this panel — Stop
run, Remove worktree, Run cleanup now, Restore worktree, Repo-Foundations setup — already
confirmed; Adopt was the one paid action that did not.) While a session is spawning the
**Adopt** button shows a spinner and disables (one
adoption in flight at a time), so a double-click can't start two; on success you get a
confirming toast (_"Adopted … — a new session is resuming the run"_), a click that turns out
not to be adoptable tells you why, and a transport failure surfaces an error — nothing is lost
either way.

**Auto-approve gates.** A per-gate switch list with a select-all master. When a gate
is on, Omniscio approves it automatically the moment an agent reports it done — so a
pipeline flows without you clicking approve at each step. On by default: **Red Team,
Build, Elegance, Docs**, plus the two always-on standards gates — **🚦 Standards Check**
(after Red Team) and **🔬 Standards Audit** (after Docs). Flip either standards gate
**off** and that review still runs, but the pipeline stops there for your approval
instead of clearing itself — the way to force a manual standards review. The **Plan**
gate and the final **Ready-to-Merge** stop always wait for you, and a gate that asks a
question or reports a blocker is never auto-approved. Each auto-approval shows up **in
the chat as your own message**, carrying a small **auto-approved** tag — so the
transcript reads just as if you'd clicked approve.

## For agents

The rest of this panel — the **Auto-lander** tab, the **QA Fleet** tab and the **Setup** tab, plus the internals an agent or contributor needs (the virtual-project id, the IPC and push wiring, every reader of the enabling setting, and the contracts that lock it) — is in [Dev Pipeline panel (part 2)](dev-pipeline-panel-part-2.md).

## Related

[Dev Pipeline](dev-pipeline.md) is the workflow this panel oversees, [Dev Pipeline Maintenance](dev-pipeline-maintenance.md) covers the housekeeping jobs it reports on, and [Git guardrails](git-guardrails.md) and [Developer guardrails](developer-guardrails.md) are the two guardrail systems it shares controls with.