Built-in Workflows

Four pipelines embedded in the binary. Run by name; customize with tracker init.

All four embedded workflows are coding-flavored — they shipped with the binary because they were the original use case. The pipeline framework itself is general: any sequence of LLM calls plus parallel branches plus human gates fits the same .dip shape. RAG, eval, content moderation, agent triage are all doable; we just haven’t shipped opinionated templates for them yet. Pull requests welcome.

Milestone Builder

`build_product`

Read a SPEC.md, decompose into milestones, implement each with verification loops, cross-review the complete result with three models, verify spec compliance.

graph TB Start([Start]) --> Setup["Setup Workspace"] Setup --> Lint["Lint Spec
sonnet"] Lint -->|ready| ReadSpec["Read & Analyze Spec
sonnet, reasoning: medium"] Lint -->|needs work| Forge["Forge Spec
opus, budget-capped"] Forge --> Fidelity{{"Fidelity
check"}} Fidelity -->|ok| Lint Fidelity -->|budget out| Done([Done]) ReadSpec -->|success| Decompose["Decompose into
Milestones
opus, reasoning: high"] ReadSpec -->|fail| ER{{"EscalateReview"}} Decompose -->|success| Approve{{"Human:
Approve Plan"}} Decompose -->|fail| ER Approve -->|approve| Pick["Pick Next
Milestone"] Approve -->|adjust| Decompose Approve -->|reject| Done subgraph loop ["Build Loop · per milestone"] Pick -->|milestone N| Impl["Implement
opus, 50 turns"] Impl --> Test["Test Milestone
tests + verify cmd"] Impl -.->|turns exhausted| Op{{"Human:
Operator Decision"}} Op -->|continue| Impl Op -->|commit + advance| Mark Test -->|pass| Verify["Verify Completion
sonnet"] Verify -->|pass| Mark["Mark Done"] Mark --> Pick Test -->|fail| Fix["Fix Issues
opus, 50 turns"] Fix --> Test Test -->|escalate| EM{{"EscalateMilestone"}} EM -->|mark done| Mark EM -->|retry| Impl end Pick -->|all done| Review subgraph xreview ["Cross-Review · 3 models"] Review["Parallel Fan-Out"] --> Claude["Claude Review
sonnet"] Review --> Codex["Codex Review
gpt-5.2"] Review --> Gemini["Gemini Review
gemini-2.5-pro"] Claude --> Join["Fan-In Join"] Codex --> Join Gemini --> Join Join --> Synth["Synthesize Reviews
opus"] end Synth -->|pass| FinalBuild["Final Build
& Test"] Synth -->|fail| ApplyFix["Apply Review
Fixes"] --> FinalBuild FinalBuild --> FinalSpec["Final Spec
Compliance
opus"] FinalSpec -->|pass| Cleanup --> FinalCommit --> Done FinalBuild -->|fail| ER FinalSpec -->|fail| ER ER -->|accept| Cleanup ER -->|retry| Decompose EM -->|accept| Cleanup

Why it’s shaped this way

Split escalation gates. EscalateMilestone handles mid-build stuck-ness (mark done / retry / accept / abandon, defaults to mark-done). EscalateReview handles post-build failure (accept / retry / abandon, defaults to accept). One gate would conflate two different decisions.
Per-milestone circuit breaker. A fix_attempts file on disk caps retries per milestone to 3 and persists across pipeline restarts. Reset only by MarkMilestoneDone. The engine’s global restart counter would otherwise let a stuck milestone 1 burn through milestone 10’s budget.
Three-model cross-review. Claude, Codex, and Gemini review independently. Reviews are synthesized to surface consensus vs. disputed findings — cheaper than asking a single model to argue with itself.
Defensive shell scripts. Tool nodes never eval LLM output. Milestone headers are matched flexibly. Empty-file guards fail loudly so an empty patch file doesn’t silently no-op the build.

# Run it
tracker build_product

# Copy and customize
tracker init build_product
# edit build_product.dip, then:
tracker build_product.dip

Competitive Fan-Out

`ask_and_execute`

Ask the user what to build, explore and spec it, fan out to three implementations in isolated git worktrees, cross-critique, pick the winner, apply it, clean up the rest.

graph TB Ask{{"What would you like done?"}} --> Explore["Explore Codebase"] Explore --> Spec["Write Spec"] Spec --> Approve{{"Approve Spec?"}} Approve -->|approve| WT["Create Git Worktrees"] subgraph compete ["Competitive Implementation"] WT --> P["Parallel Fan-Out"] P --> C["Claude"] P --> O["OpenAI"] P --> G["Gemini"] C --> J["Fan-In Join"] O --> J G --> J end J --> Crit["Cross-Critique"] Crit --> Pick["Pick Best"] Pick --> Apply["Apply & Commit"] Apply --> Clean["Clean Worktrees"] Clean --> Done([Done])

Each model implements the same spec in its own git worktree — full filesystem isolation, no interference. Each implementation is reviewed by all three models; a judge selects the winner from aggregate scores; the winning branch is merged and the others are deleted.

tracker ask_and_execute

Parallel Streams

`build_product_with_superspec`

For large structured specs with parallel work streams and dependency graphs. Independent streams run concurrently; mechanical quality gates between phases; cross-review at the end; full traceability audit.

graph TB Analyze["Analyze Spec
Structure"] --> Plan["Build Execution
Plan"] Plan --> Approve{{"Approve?"}} Approve -->|approve| P1["Phase 1:
Parallel Streams"] P1 --> G1["Quality
Gate 1"] G1 -->|pass| P2["Phase 2:
Dependent Streams"] G1 -->|fail| Fix1["Fix Phase 1"] Fix1 --> G1 P2 --> G2["Quality
Gate 2"] G2 -->|pass| Review["Cross-Review
(3 models)"] Review --> Final["Final Gates
& Traceability"] Final --> Done([Done])

Quality gates are mechanical, not LLM-judged — build, test, lint, coverage, complexity. The final gate verifies every spec requirement maps to implementation and test coverage. Designed for specs big enough that a single milestone-builder run would lose the plot.

Interview-Driven

`deep_review`

Structured codebase review powered by interview mode. Three rounds of targeted questions (scope, findings, priorities) drive parallel analysis and produce an actionable remediation plan.

graph TB Ask{{"What to review?"}} --> Explore["Explore
Codebase"] Explore --> GenScope["Generate Scope
Questions"] GenScope --> Scope{{"Interview:
Scope"}} subgraph analysis ["Parallel Analysis"] Scope --> P["Fan-Out"] P --> Correct["Correctness
opus"] P --> Sec["Security
opus"] P --> Design["Design
opus"] Correct --> J["Fan-In"] Sec --> J Design --> J end J --> Synth["Synthesize
Findings"] Synth --> Findings{{"Interview:
Findings"}} Findings --> GenPri["Generate Priority
Questions"] GenPri --> Priority{{"Interview:
Priorities"}} Priority --> Plan["Write Remediation
Plan"] Plan --> Review{{"Approve Plan?"}} Review -->|approve| Final["Finalize"] --> Done([Done]) Review -->|revise| Plan

Three interview gates narrow down the work: scope (primary concern, target area, deployment context), findings (each finding presented as intentional / known bug / needs investigation — your context kills false positives), priorities (timeline, fix approach, dependencies). The output is a remediation plan, not a wall of nitpicks.

# Review any codebase
tracker deep_review

# Fully autonomous (LLM answers the interviews)
tracker --autopilot mid deep_review

Run them unattended

Every workflow is designed for hands-on AND fully unattended operation. Pick the gate-handling strategy that matches your deployment.

Autopilot personas

An LLM judge answers every gate. Four personas: lax (forward progress), mid (balanced, default), hard (high bar), mentor (approve with feedback).

tracker --autopilot mid build_product

Auto-approve

Deterministic — no LLM call, always picks the default or first option. Best for CI and pipeline-flow tests.

tracker --auto-approve build_product

Webhook gates

POST every gate to your URL; pipeline blocks on the callback. Slack bots, email approval, mobile push, factory workers. Per-gate tokens, configurable timeout.

tracker --webhook-url https://... build_product

Workflow customization

After tracker init <name>, the local .dip file takes precedence on subsequent runs. Tweak per-node models, backends, or prompts without forking the whole pipeline.

Workflow params

Top-level vars become ${params.*} graph attrs referenceable in prompts, commands, and conditions. Override at runtime with --param key=value; unknown keys hard-fail at startup.

Budget ceilings

Put max_total_tokens / max_cost_cents / max_wall_time in a workflow’s defaults: block; CLI flags override per-run. Halts emit EventBudgetExceeded.

Human-gate timeouts

Set timeout and timeout_action per human gate so unattended runs keep moving if no one responds. Works with freeform, choice, and interview modes.

Stall & per-node guards

A stall_timeout in defaults: is enforced by the budget guard to halt runs that stop making progress. Per-node max_cost_usd and no_progress_turns cap individual nodes, emitting EventNodeCostLimitExceeded / EventNodeNoProgressDetected.

Manager loops in `.dip`

Declare stack.manager_loop supervisors directly via ir.NodeManagerLoop. Six flat attrs — no DOT escape hatch. Snippet below.

Commit-only fs-jail

Bound a node’s file writes with writable_paths (native Landlock fs-jail) plus params: commit_only: true to keep it from authoring source. build_product’s FinalCommit declares writable_paths: .git/**, .ai/** so git add/git commit work but the node cannot write product code.

manager_loop Supervise
  label: "Watch build attempts"
  subgraph_ref: "subgraphs/build.dip"
  poll_interval: 30s
  max_cycles: 10
  stop_condition: "stack.child.status = success"
  steer_condition: "stack.child.cycles > 3"
  steer_context: "hint=try-alternate-plan,priority=high"

Backend selection is per-pipeline or per-node: tracker --backend claude-code build_product flips globally; per-node backend: claude-code attrs win over the global flag. All four built-in workflows work with every backend.

Pipeline testing

Every edge from every gate is tested with dippin simulation tests — scenario overrides inject conditions, assertions verify the routing path. No LLM calls.

{
  "name": "milestone escalation default — mark done continues build",
  "scenario": {
    "TestMilestone.tool_stdout": "escalate",
    "TestMilestone.outcome": "fail"
  },
  "expect": {
    "immediately_after": {"EscalateMilestone": "MarkMilestoneDone"}
  }
}

dippin test examples/build_product.dip
# 23 tests: 23 passed, 0 failed