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 answers four questions and stops: is it on (a switch with a sentence that says what the current value actually means), how hands-on do you want to be (one choice — Check every step, Just the plan, or Autopilot — that sets all five gates at once), which repos, and where is everything else. Every other control still exists: All settings, one link down, is the full list — 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 — as collapsible cards grouped into Pipeline behavior, Automation, and Safety & setup, closed until you open the one you need, with a filter box over the whole list so a name you already know never needs a card opened. The split is deliberate: you watch the lander on its own tab and change it in Setup's All settings.

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.

A run also carries what each phase caught or changed. Time and money say what a stage COST; they cannot say whether it earned them. So each phase reports its own counts through a typed call (POST /dev-pipeline/stage-findings — a route, not a line in the run's scratch state file, because a machine-to-machine hop travels in a typed channel): a verdict (clean / changed / held), how many findings it raised, how many of those it acted on, and how many lines its own actions produced. The per-run read returns them as phaseFindings, one entry per phase that reported. Three states are kept apart on purpose — a reported 0 means the phase looked and found nothing to act on; a missing count means it could not derive that number; and no entry at all means the phase never reported, which is different from reporting zero. A missing entry is never read as a clean phase: recording is best-effort and never gates the run, so its absence means "no record", not "nothing found". The fields arrive on the same read the Timing tab already uses (GET /dev-pipeline/runs?history=N); the tab does not draw them yet.

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). 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).

Related

Dev Pipeline is the workflow this panel oversees, Dev Pipeline Maintenance covers the housekeeping jobs it reports on, and Git guardrails and Developer guardrails are the two guardrail systems it shares controls with.