feat(pipeline): multi-model plan → code → review pipeline task type

[bborn]

Workflow task type: one goal → a small DAG of steps

Adds a workflow: a single goal is broken into a small DAG of step tasks that run on one shared git branch, each routed to its own executor and model, advancing automatically. Steps are sequential where they depend on each other and parallel where they don't.

The default plan-code-review workflow:

Plan ──▶ Code ──▶ Review A ─┐
                  Review B ─┴─▶ Collect ──▶ PR

Step	Default	Job
Plan	Claude / Opus	Explore, write PLAN.md, push. No code.
Code	Claude / Sonnet	Implement the plan, push.
Review A, Review B	Claude / Opus, Claude / Sonnet	Two independent reviewers, in parallel, each on its own branch. Different models + independent context catch different classes of issue and avoid single-context self-review.
Collect	Claude / Sonnet	Read both reviews, apply the fixes worth applying, open the PR.

How it works

Built on primitives TaskYou already has — no bespoke execution engine; the normal daemon runs each step task:

• The DAG is the task dependency graph. Each step is a task; a step's Deps become auto_queue dependencies. Fan-out (two reviewers depending on Code) and join (Collect depending on both reviewers) fall out for free — ProcessCompletedBlocker queues a step once all its blockers complete.
• One shared branch. The root step pins the branch; every other step checks it out via SourceBranch, handing work forward through git. The two reviewers push to their own branches (single push, no rebase) so they can't clobber each other, and Collect reads each explicitly.
• Autonomous, with a human gate only when needed. Steps advance on their own; the workflow lands in blocked when Collect opens the PR (awaiting a human merge) or when a step calls taskyou_needs_input.
• One board card, not N. A workflow's step tasks collapse into a single lead card showing the goal and current step + progress (⇄ goal / Review ∥ · 3/5) instead of cluttering the board with a card per step.

Configurable per project

Each step's executor and model is configurable per project and persisted, so you set it once and every workflow in that project uses your choices:

ty pipeline config -p myapp                          # show current config
ty pipeline config -p myapp --set "Review B=codex"   # cross-executor review
ty pipeline config -p myapp --set "Code=claude/haiku"
ty pipeline config -p myapp --reset                  # back to defaults

Steps are data, so a workflow can be extended (add a QA step, a third reviewer, a different flow) without touching the executor.

Entry points

• CLI: ty pipeline "<goal>" (--definition, --list, --no-execute, --permission-mode, --json) and ty pipeline config.
• TUI: a Workflow selector in the new-task form; selecting one turns submit into a workflow, with a start-now / save-for-later confirm and a board toast.
• MCP: taskyou_create_pipeline so an agent can spawn a workflow mid-task.

Each step commits and pushes the shared branch, so a workflow needs a git-worktree project with a remote to push to.

Changes

• internal/pipeline/ (new/reworked): DAG model (Step + Deps, validated for single-root / acyclic / unique names), the built-in plan-code-review definition, Create() that builds the linked-task DAG, per-project step config, and GroupWorkflows for the collapsed board card.
• internal/ui/: workflow board collapse (kanban.go, app.go), the Workflow form selector, the confirm/toast.
• cmd/task/main.go: ty pipeline + ty pipeline config.
• internal/mcp/server.go: taskyou_create_pipeline.
• internal/executor/executor.go: setupWorktree honors a caller-pinned BranchName so the root step can own the shared branch.

Tests & QA

• Unit tests: DAG build + validation, parallel fan-out + join auto-advance, the per-branch review handoff, per-project config round-trip, and workflow grouping / lead / progress.
• Exercised end-to-end with live agents (Plan → Code → two parallel reviewers → Collect) on a real git repo with a remote — which is how a reviewer-clobber bug in the review handoff was found and fixed (reviewers now push to their own branches). Collect read both reviews, applied one and deferred the other with reasoning, and pushed.
• All package tests + golangci-lint v2.8.0 green.

Follow-ups

• Opening a collapsed workflow card shows the lead step's detail; a dedicated workflow overview (all steps / the parallel branches at a glance) is a natural next step.
• A TUI surface to edit pipeline config (today it's the CLI; the TUI already honors the saved config).

🤖 Generated with Claude Code

[bborn]

Follow-up round 2: configurable phases, no Codex default, TUI + QA

Addressing the review feedback (d8243544, and TUI/QA in 96163f64):

No more Codex default / fallback

The default pipeline is now all Claude — Plan=opus, Code=sonnet, Review=opus — so it works on any host and never silently swaps executors. The old "default to Codex, fall back to Claude" behavior and the AvailableExecutors fallback machinery are gone.

Configurable per project, persisted (set once → always your choices)

Each phase's executor+model is configurable per project and saved (settings key pipeline_config:<project>:<definition>). Set it once and every pipeline in that project defaults to your choices — the CLI, TUI, and MCP paths all read the saved config via pipeline.EffectivePhases.

New ty pipeline config:

$ ty pipeline config -p myapp
plan-code-review pipeline for myapp (defaults)
  Plan     claude/opus
  Code     claude/sonnet
  Review   claude/opus

$ ty pipeline config -p myapp --set "Review=codex" --set "Code=claude/haiku"
plan-code-review pipeline for myapp (configured)
  Plan     claude/opus
  Code     claude/haiku
  Review   codex/default

# subsequent `ty pipeline "<goal>" -p myapp` and TUI pipelines use exactly this
$ ty pipeline config -p myapp --reset   # back to defaults

Partial edits merge onto current config; unknown phase names / executors error clearly.

TUI affordance (from the prior round)

New-task form gained a Pipeline selector (advanced fields); selecting a definition turns submit into a pipeline build, with a pipeline-aware confirm and a board toast. QA'd via the ty-qa VHS harness on an isolated instance:

Form selector
Selected + hint
Confirm
Created end-to-end (toast + chain on board)

(The board card labels show [Plan]/[Code]/[Review]; executor/model live on each phase task and are what pipeline config controls.)

All package tests + golangci-lint v2.8.0 green.

Follow-up: a TUI screen to edit pipeline config (today it's the CLI; the TUI already honors the saved config).

[bborn]

Round 3: rebuilt as a workflow DAG — parallel review, one board card, real-agent QA

Went back to how herdr actually works (Plan → Code → two parallel reviewers → collect) and reworked the linear pipeline into a real workflow DAG. Commit f01c8acf.

What changed

• It's a DAG, not a chain. Each step has Deps; the default plan-code-review is Plan → Code → [Review A ∥ Review B] → Collect. Sequential where steps depend on each other, parallel where they don't — the two independent reviewers (different models, independent context) are the whole point, catching different issues and avoiding self-review bias. Built on the existing task dependency graph (fan-out + join via auto_queue).
• One board card, not N. A workflow's step tasks collapse into a single lead card — ⇄ <goal> with the current step + progress (Review ∥ · 3/5) — instead of cluttering the board with 5 cards. ("stage all phases" wording is gone too.)
• Configurable / extensible. Steps are data — add a QA step, point a reviewer at codex, etc. — per project via ty pipeline config.
• Autonomous, human gate only at the end. Steps advance on their own; the workflow drops to blocked only when Collect opens the PR (or a step genuinely needs input).

Board: one collapsed card (was 5)

QA — actually ran it end-to-end with live agents

Ran the real rendered step prompts through live Claude agents on a git repo with a remote — Plan (sonnet) → Code (sonnet) → Review A (haiku) ∥ Review B (sonnet), concurrently → Collect (sonnet), goal: "add fizzbuzz.py + a pytest test".

This caught a real bug. With the reviewers pushing to a shared branch, the weaker model botched the rebase-push and clobbered the other reviewer's file. Fixed: each reviewer now pushes to its own branch (single push, no rebase, no race), and Collect reads each explicitly. Re-ran — both reviews survive:

code branch:   plan → code → collect
  4d5eca5 plan: Add fizzbuzz.py ...
  daa6f69 Add fizzbuzz.py and pytest suite per PLAN.md
  25e81e9 Add .gitignore for Python artifacts        ← Collect applied a review nit

parallel review branches (independent, no clobber):
  …-review-a  (haiku)  → review-review-a.md
  …-review-b  (sonnet) → review-review-b.md   ← both intact

Collect read both reviews, applied Review B's .gitignore nit, deferred its requirements.txt suggestion with reasoning (matched scope to PLAN.md), noted no reviewer disagreement, and pushed. (The final gh pr create no-op'd only because the QA sandbox uses a local bare remote, not GitHub — PR creation itself is standard.)

All package tests + golangci-lint v2.8.0 green.

Follow-ups

• Codex was installed but its binary is broken in my env (bad mise install), so both QA reviewers ran on Claude (different models) — cross-executor is config-driven and unit-tested; a working codex slots in via pipeline config --set "Review B=codex".
• Board: opening a collapsed card shows the lead step's detail; a dedicated workflow overview (see all steps / the parallel branches) is a nice next step.

[bborn]

Full TUI flow for workflows — including in-TUI config (3da6f4a2)

Configuring a workflow's per-step models was CLI-only; added a proper in-TUI editor so the whole flow is doable on the board. QA'd by driving the real TUI (isolated instance, VHS).

1. Create a workflow — the new-task form's Workflow selector:

2. Configure it — press W on the board. One row per step with an executor/model selector; the DAG deps (← Code, ← Review A+Review B) render inline. ↑/↓ step · ←/→ change · enter save:

3. Cross-executor review — set Review B to codex (←/→):

4. Save — persists to the per-project config and toasts on the board:

It edits the same persisted config as ty pipeline config — verified round-trip: after saving Review B → codex in the TUI, ty pipeline config -p qa reads back Review B codex/default, and vice versa. So the CLI and TUI are two views of one setting, and every workflow in the project defaults to it.

All package tests + golangci-lint v2.8.0 green.

[bborn]

User-defined workflows — text-file first, LLM optional (ace3f0d3)

Answering "how are steps defined / who sets them / how do I configure them": custom workflows are now first-class. You can define a whole new flow (add a QA step, a spike→build→test shape, more reviewers) without touching Go.

YAML files (the source of truth)

One workflow per file in ~/.config/task/workflows/*.yaml (override $TY_WORKFLOWS_DIR), plus per-project .taskyou/workflows/. Discovered at runtime, merged with the built-in. Hand-editable:

name: build-and-qa
steps:
  - {name: Plan, model: opus, prompt: "Plan {{goal}}."}
  - {name: Build, deps: [Plan], prompt: "Build it."}
  - {name: Security, deps: [Build], prompt: "Security review; write security.md."}
  - {name: QA, executor: codex, deps: [Build], prompt: "QA it; write qa.md."}
  - {name: Finalize, deps: [Security, QA], prompt: "Address findings, finalize."}

Authoring is just prompts — the git plumbing is derived from the DAG

You write what each step does + its deps; the handoff is composed from the step's DAG position. QA'd — the generated body for a parallel step vs the join/sink:

• Security (parallel with QA) → "push your output to YOUR OWN branch {{branch}}-security … Do NOT open a pull request."
• Finalize (joins Security+QA, sink) → "read origin/{{branch}}-security and origin/{{branch}}-qa … open a pull request with gh pr create."

So authors can't get the parallel-branch handling wrong — the exact bug the earlier real-agent QA caught.

Free text → workflow

ty pipeline new "<describe it>" runs it through Claude → a validated, editable YAML (with a self-repair retry). Live QA — one sentence produced a 9-step DAG:

$ ty pipeline new "spike three approaches in parallel, pick the best, build it,
                   then review and test in parallel, then finalize"
Created workflow 'spike-build-verify'
  Plan               claude/opus
  Spike Approach A   claude/sonnet  ← Plan
  Spike Approach B   claude/sonnet  ← Plan
  Spike Approach C   claude/sonnet  ← Plan
  Evaluate and Select claude/opus   ← Spike A+Spike B+Spike C
  Build              claude/opus    ← Evaluate and Select
  Code Review        claude/opus    ← Build
  Test               claude/sonnet  ← Build
  Finalize           claude/opus    ← Code Review+Test

In the TUI

Custom workflows appear in the new-task Workflow selector automatically:

Tests cover parse/validate/marshal round-trip, registry merge + shadowing, DAG-derived handoff, and Create honoring a custom workflow. All green + golangci-lint v2.8.0.

Honest limitations (follow-ups)

• Multi-root workflows (true parallel entry points, e.g. 3 spikes with no shared root) aren't supported yet — the root pins the shared branch, so the generator adds a single root the parallel steps depend on. Real multi-root needs shared-branch bootstrapping.
• The TUI W model-config modal still targets the default workflow; custom workflows set their models in YAML (or ty pipeline config -d <name>).

[bborn]

Both follow-ups done (cd9cee95)

Multi-root workflows (true parallel entry points)

Workflows can now have several root steps that run at once (e.g. 3 spikes with no shared root). When a workflow has >1 root, Create pre-creates the shared branch on the remote so every root checks it out and runs in parallel; each parallel root pushes to its own branch and the join reads them — all derived from the DAG. Single-root is unchanged. QA'd:

$ ty pipeline "Rewrite the tokenizer" -p demo --definition three-spikes
  Spike A  claude/sonnet  status=queued   deps=None
  Spike B  claude/sonnet  status=queued   deps=None
  Spike C  claude/sonnet  status=queued   deps=None
  Pick     claude/opus    status=blocked  deps=[Spike A, Spike B, Spike C]
→ shared branch pre-created on origin ✅   (all 3 roots parallel, Pick joins)

Without a remote it fails clearly: "multi-root workflows need a git-worktree project with a remote."

Config is the files — dropped the settings config + TUI form

You were right; there didn't need to be a per-project config layer or a TUI form. Removed:

• internal/pipeline/config.go (the pipeline_config settings, StepConfig, EffectiveSteps, …)
• the ty pipeline config command
• the W TUI model-config modal (and all its wiring)

Configuration now lives in the YAML files. To customize the built-in, eject it:

$ ty pipeline edit
Wrote plan-code-review to ~/.config/task/workflows/plan-code-review.yaml

It writes the built-in steps with verbatim: true (so the ejected file behaves identically), and a custom file shadows the built-in by name — edit models/prompts/steps by hand. ty pipeline new "<describe it>" still generates one from English.

Tests updated (multi-root parse/validate + parallel-root handoff; config tests removed). All package tests + golangci-lint v2.8.0 green.
EOF