Agent pipelines, an opt-in memory graph, and scheduled runs

[DanilaZanin]

One agent in a chat handles a targeted edit well. A larger task usually wants a
shape: plan it, write it, review it, send the review back to whoever wrote the
code. Today that means driving every hand-off by hand, and @ delegation only
gets you part of the way, because nothing brings the result back.

This adds a pipeline engine that runs those chains, an editor for them in the
composer, and an opt-in memory graph. Everything is off by default: Codeg still
opens in single-agent mode with memory disabled, and the existing chat is
untouched.

docs/agent-pipelines.md is the user-facing guide.

The engine

A linear chain with bounded back-edges. Two chains ship: Duet
(coder, reviewer) and Team (planner, coder, reviewer, tests), both looping
back to the coder for up to three fix rounds.

• Every step carries its role, agent, model, timeout, prompt template and a
  read-only flag. Prompts substitute $task, $plan, $summary, $review
  and $memory.
• A read-only step that edits the tree is caught: the engine hashes the
  worktree around it and downgrades the verdict to inconclusive, naming the
  paths that moved. Such a step is also told the rule in its prompt, which it
  previously was not.
• Status transitions are compare-and-swap, each attempt carries its own id, and
  runs still open after a restart are closed as interrupted.
• Graphs are validated up front: no cycles, no unknown targets, at most eight
  steps, one to ten iterations.
• Steps launched by the engine answer their own permission prompts. Without
  this they simply sat until the step timed out, because there is no user
  attached to a pipeline step.

Verdicts

A reviewer or test step reports through the pipeline_verdict MCP tool; notes
are required when it asks for changes. When the tool is unavailable, a
VERDICT: marker in the agent's own output is parsed instead.

Isolation

Each run works in its own git worktree on a temporary branch, and lands through
a squash or a merge commit when the user applies it. Apply refuses when the
project has staged changes of its own rather than folding them into a commit
the user did not write.

Editing a chain

The role chips in the composer are the editor. A chip opens two lists, agent
and model; the models come from a live probe of that agent rather than a
hardcoded table, and a saved id the agent no longer lists stays visible instead
of being silently swapped for the first option. Agent and model move together,
since the old agent's model id almost never exists on the new one.

Editing Duet or Team stores an override of the built-in chain, with a Reset
beside the chips once one exists. The schema already carried preset_key, its
partial unique index and a save_preset function that nothing called; this
connects that seam.

Custom mode gains a + that asks for the role first, which also decides where
the step lands: a planner goes to the head, since it exists to brief the steps
after it.

While a pipeline mode is active the composer hides its own model and reasoning
pickers. The model belongs to each step now, and a second control for it would
point at a session the run does not use. The edit-permission mode stays: it
matters more once several agents write, not less.

The canvas keeps the full step editor (prompt, timeout, read-only, loop target)
on a pipeline card.

Automations

A run_pipeline action, so a chain can run on a schedule or on demand.

Memory (opt-in, off by default)

Three backends: off, a local SQLite graph with FTS5 search and two-hop edge
traversal, or an external MCP server.

What gets remembered is the user's choice: built-in kinds (decision, fixed bug,
task summary, preference) plus their own, each set to automatic, on request or
off, scoped to the project or global. memory_write, memory_search and
memory_link are exposed only while memory is on, everything written passes a
secret redactor first, and injected context is wrapped in
<memory untrusted="true">.

Bugs found along the way and fixed here

Most of these surfaced while running the feature against a real repository
rather than in tests.

• A draft was lost when creating a conversation from the canvas failed, and
  when a tab was switched before the debounce flushed.
• Sending while a conversation was still being created dropped the message.
• A delegated task could be completed by a stale child connection.
• working_dir from tool arguments was not checked for being an absolute,
  existing directory.
• Permissive CORS applied to every route rather than the public ones, and
  backup uploads had no size cap.
• Adding a pipeline card on the canvas always failed: the service requires
  pipeline_id for that kind and the create command hardcoded None.
• The canvas step inspector wrote to React state only, so reassigning a step to
  another agent looked applied, was gone on reopen, and the run used the old
  chain.
• Apply with the squash strategy only staged the merge, then deleted the
  run's branch and worktree, leaving the work as an uncommitted diff with its
  only record gone.
• The read-only guard always reported "reviewer modified files" whichever step
  it was and whatever it touched. In practice the culprit is often a
  session-start hook or a build cache the repo does not ignore, which the old
  message gave no way to discover.
• The composer looked its presets up by display name while the API returns them
  keyed by preset key, so the role chips never rendered at all.
• fitView on the canvas card only ran for the first render, so a newly added
  step landed outside the card with nothing to show it existed.

Testing

The full gate passes: lint, the frontend suite, the static export, and
cargo check / test / clippy for codeg, codeg-server and codeg-mcp.

New coverage includes an end-to-end duet run driven through the real engine
(loop-back then pass, the fix-round limit, and an inconclusive review), the
preset overlay and reset, the composer chip editor, the graph edit helpers, and
the read-only instruction staying in step with the flag.

Beyond the automated gate, the duet was run against a live repository end to
end: planner, coder on a different vendor's model, reviewer reporting through
the MCP tool, then Apply landing a real commit whose asserts fail on the old
implementation.