A5.3.2 · dive 2/3
The task DAG
The runtime shape says what the running system looks like. The task DAG says how to assemble it — a fixed build order in which every step leaves the app compiling.
A spec lists what a rung must do; it does not say in what order to build it. The
task DAG turns the rung into an ordered chain of tasks, each depending on the steps before it, so a Claude
Author builds bottom-up and never holds a half-compiling tree. Step the figure on the right through the
Portal's real order, T1 to T7, and read which
requirements each step satisfies.
The build order · step through T1 to T7
The build order
A task DAG is a build order written as a directed chain — a directed acyclic graph. Each task names the requirements it satisfies and runs only after the tasks it depends on. Two properties make it a build order an agent can follow without thinking: each step leaves the app compiling (a task adds the smallest unit that still builds, so the tree is never broken between steps), and the order is a dependency order (a later task assumes the earlier ones exist).
For the Portal's web bootstrap, f6.1.llms.md pins the order exactly: deps and the
entrypoint, then the endpoint, then the supervision wiring, then the router, then the controller, then the
view, then verify. The hero figure steps through it; each step reports the task, the requirements it
satisfies, and that the app still compiles. Nothing in that order is the agent's to decide — the brief
decided it, derived from the runtime shape.
The build order
A directed chain of tasks, each naming the requirements it satisfies and the steps it depends on, written so the app compiles after every one.
On the Portal
f6.1.llms.md orders T1 deps →
T2 endpoint → T3 supervision →
T4 router → T5 controller →
T6 view → T7 verify, each with its
[R…] trace.
The order is read bottom-up: the endpoint exists before a router can be mounted on it, the router exists before a controller's action can be dispatched, and verify runs last because it checks all of it. The next section makes one of those edges visible by breaking it.
A dependency order
The order is not arbitrary — it is a dependency order, and that is what makes “each step still
compiles” true. The controller (T5) depends on the router
(T4): the controller's index/2 action is dispatched by a
route the router must already define. The router depends on the endpoint (T2):
a router is mounted only because the endpoint plugs it in last. Build a task before its prerequisite and the
later code references something not yet built — the tree breaks.
Toggle the figure below between the brief's order and a swap that builds the controller
(T5) before the router (T4). In order, no dependency is
unmet. Swapped, the controller is dispatched by a route that does not exist yet — one broken
dependency. The task DAG exists so that swap never happens.
Build out of order · break a dependency
A task DAG is a build order an agent can follow without ever holding a half-compiling tree.
On the Portal
The Portal's web bootstrap ships from a real brief, f6.1.llms.md, whose execution
topology carries the task DAG verbatim. The order is the one the figures use; the
[R…] traces tie each step back to a numbered requirement, so the build order
and the requirements list stay one document. The route the ordered build assembles is the request path of
the companion course's Phoenix request lifecycle —
the endpoint, the router, and the controller, built bottom-up in this exact order.
# f6.1.llms.md — Execution topology — the task DAG (each step leaves the app compiling) # T1 deps + entrypoint → T2 endpoint [R1] → T3 supervision [R2] → T4 router [R3, R6] → T5 controller [R4, R8] # dispatched by T4's route → T6 view [R5] → T7 verify [R7, R8]
The principle
The task DAG fixes the build order so the system compiles at every step; out of order, a dependency breaks — the later code references something not yet built.
On the Portal
f6.1.llms.md orders T1 → T7
with [R…] traces; the endpoint (T2) precedes the
supervision wiring (T3), which precedes the router (T4),
which precedes the controller (T5).
A task DAG turns “build this” into “build this, in this order, each step still compiling” — a plan an agent follows, not a sequence it guesses.
Recap — the build order is fixed, the file list comes next
The runtime shape drew the running system; the task DAG draws the order it is assembled in, as a directed chain where each step leaves the app compiling and a later task assumes the earlier ones exist. Build out of order and a dependency breaks — the controller dispatched by a route that does not exist yet. With the order fixed, what remains is the exact set of files the agent touches in it — the third piece of the execution topology.
Next in A5.3: The file list — the exact touched files, so the agent creates and edits the right ones and no others.
References
Primary sources for the machine-brief form a task DAG lives in and for building incrementally so the system works at every step, with the runtime shape this order assembles and the request lifecycle it produces.
Sources
- llmstxt.org — The /llms.txt convention — the links-first, machine-readable brief that carries the task DAG an agent builds in order.
- Hunt, A. & Thomas, D. — The Pragmatic Programmer — tracer bullets: build incrementally and keep the system working at every step.
- Anthropic — Building effective agents — why a coding agent needs the build order fixed rather than an open-ended goal.
Related in this course
- A5.3 · Execution topology — the module hub.
- A5.3.1 · The runtime shape — the running system this order assembles.
- A5 · The agent brief — the chapter landing.
- Companion · The request lifecycle — the request path the ordered build produces.