Pipeline and stages

A pipeline is a list you own

A pipeline is an ordered list of stages. Nothing about that list is fixed: you rename stages, reorder them, add and delete them, assign a different persona to each, and rewrite each one's instructions. The default pipeline is a starting point, not a schema.

Context → Build → Review → Loop (human gate) → PR Open

Each stage carries five things: a display name (the board column header), a built-in kind (what TDE does mechanically when a task enters), an assigned agent persona, free-text instructions, and an optional deliverable spec.

Stage kinds

The kind is the only part TDE interprets. There are five:

An agent runs automatically on Agent, Build, Review and PrOpen. A HumanGate runs nothing — that is its whole job. See Human gates.

The prompt is the source of truth

Every stage agent run gets two blocks of text. The first is a short, non-editable control protocol — it tells the agent what support it has (its worktree, the repository, MCP tools, persona skills, TDE Brain, prior stage deliverables) and how to hand the task on. The second is your stage's authored instructions, which carry all of the behavior.

The routing directive is what moves the task. An agent ends its output with exactly one line:

NEXT: advance    — objective met; move forward to the next stage
NEXT: back       — return to the previous stage (with required-changes feedback above)
NEXT: stay       — keep the task here and run again
NEXT: done       — automation is complete; stop at the human gate when one remains
NEXT: <stage-id> — jump to a specific stage by its id

There is no hardcoded forward/backward rule in TDE. The directive is parsed from the bottom of the agent's output, so any pipeline — with any stage names, in any order — decides its own path purely through prompts.

The legacy review tokens APPROVED and CHANGES_REQUESTED are still accepted and mean advance and back. That is what makes the built-in Review stage work: its prompt asks for exactly one verdict, APPROVED or CHANGES_REQUESTED, plus concise actionable feedback added to the task. CHANGES_REQUESTED sends the task back to Build; APPROVED advances it to the human Loop.

An agent that genuinely needs a human decision emits an ASK: block instead of a directive and stops — the task is parked until someone answers, then the same stage re-runs with the answer in context.

Built-in stage prompts

New standard stages start with editable default instructions:

Editing these only adds guidance — the control protocol is always present, and the authored prompt remains the source of truth for behavior.

Triage: not everything is code

Before any stage runs, a triage agent reads the task's title and description only — it does not read the repository or run commands — and classifies the intent:

The classifier is deliberately free of keyword lists, so it works in any language and any domain vocabulary. Mixed or unclear tasks answer CODE, and an unparseable answer falls back to CODE too — the safe direction is the full pipeline.

QA and RESEARCH short-circuit: TDE runs only the pipeline's first agent stage under a read-only prompt, then moves the task straight to the human Loop gate. No Build, no Review, no verify, no PR. The task log reads fast-path: Q&A — running 'context' only, then human gate, and Activities gets a … ready for human review event whose body states that automation stopped and no build artifacts were produced.

Artifacts between stages

A stage can leave structured output for the stages that follow. Deliverables are validated against the stage's spec and stored on the task. A successful generic Build also captures a Change Map from the worktree: files, relationships and the delivery state become a durable artifact rather than a temporary preview.

Capture happens only when Build completes successfully. A stay, back, budget block or failed run cannot publish a successful delivery map. Review receives the worktree context and must return a verdict with concrete evidence — a file and line, a test or a command and outcome — before automation accepts approval.

In the task detail, Git Changes shows the raw diff, Change Map shows the persisted artifact and Mermaid renders that map. This keeps Build, Review and the human-facing diagram on the same evidence.

Multiple pipelines

Pipelines are stored one JSON file per pipeline in ~/.tde/pipelines/<id>.json. A default pipeline always exists and can never be removed; saving prunes files for pipelines you deleted.

Two optional presets ship as Store items rather than being seeded automatically:

Creating your own pipeline copies the default's structure — stage ids, names, kinds — but clears every prompt, so you author the new flow from scratch. A built-in pipeline can be reset to its factory definition; a custom one cannot, because there is nothing to reset to.

Each project picks a pipeline, and each task records the pipeline it runs, so changing a project's pipeline does not retroactively re-route work already in flight.

Where a run can stop

A stage run is not guaranteed to reach the next stage. In order:

1. Open dependencies — the task waits for its blockers to close.
2. Quota — an agent CLI too close to its rate limit parks the task with a Paused: … quota at N% event.
3. Budget — a task over its budget_cents is not handed to an agent at all; the log reads paused: task over budget. At 80% of budget the pinned model is dropped in favor of the CLI default.
4. Guards — a Review-stage guard violation fails the verdict and sends the task back to Build.
5. Human gate — automation halts by design.
6. A parked question — the ASK: flow.
7. Step budget — a pipeline that runs stages × (review cycles + 1) steps without finishing is parked at the first human gate with a … needs a human event.