A5.3 · module hub
Execution topology
References named the sources; requirements numbered the checks. Those requirements imply a runtime shape and a build order — and the topology writes both down, with the exact files the agent touches.
The brief's third part answers the three things a spec leaves open about how the code is
assembled: what runs (the supervision tree and the request flow), in what order
it is built (the task DAG, each step compiling), and in which files (the touched-file
list and the boundary the agent does not cross). With them fixed, a Claude Author assembles a system bottom-up
without guessing. Select a part on the right; the three dives go deep on each. All grounded on the Portal's
real f6.1.llms.md.
The three parts of topology · pick one
From requirements to a shape
A5.2 left a set of numbered, traced requirements — F6.1-R1–R8 on the
Portal's f6.1.llms.md. Each names a source and a check, but on its own a requirement
does not say where its code lives, in what order it is wired, or what process owns it at runtime. Those are the
decisions the spec leaves open, and the execution topology closes them.
The topology has three pinned artifacts. The runtime shape names the supervision tree and how a request flows through it. The task DAG fixes the build order, with each step leaving the app compiling. The file list bounds the change to the exact files created, edited, and deleted. Together they let an Author assemble the increment bottom-up — the same request lifecycle the companion Phoenix request lifecycle chapter builds.
The principle
The topology fixes the runtime shape, the build order, and the files — the three things a spec leaves open about how the code is assembled.
On the Portal
f6.1.llms.md pins the two-supervisor tree
(:portal + :portal_web), the
T1→T7 order, and the touched-file list, so the agent assembles bottom-up.
Topology is the difference between “build this” and “build this, in this shape, in this order, here.”
Trace a request
The runtime shape is most concrete as a path. A request to f6.1.llms.md's Portal
enters the endpoint and walks the plug stack to the router, which dispatches to the controller, which calls the
domain through exactly one door: the Portal.courses_of/1 facade. Step through the hops
below. Switch the route to /health and the path stops at the router — the one
path that never reaches the facade.
Follow a request through the plug stack
Every domain path reaches the engine through one door, the facade; the health route is the single path that never opens it.
The three dives
Each dive takes one part of the topology, in the order an Author needs them: the runtime shape it must reproduce, the task DAG it builds in, and the file list that bounds the change. Read them in order — A5.3.1 starts.
The runtime shape
The two-supervisor tree — :portal and
:portal_web — and how a request flows through the plug stack to the facade,
with /health the one path that skips it.
The task DAG
T1→T7 with its [R…] traces; each
step leaves the app compiling. Build out of order and a dependency breaks — the controller before its
route has nothing to dispatch to.
The file list
The exact files created, edited, and deleted — the change's blast radius — with the engine, store, contexts, and facade pinned as unchanged below the boundary.
After A5.3, the next module — A5.4 · Agent stories — turns this ordered plan of work into units with an executable Directive and a closing Acceptance gate. Return to the A5 chapter navigation to continue.
References
The sources behind writing a runtime shape, a build order, and a file list an agent can assemble from, and where the request lifecycle and the facade boundary are built in the companion course.
Sources
- llmstxt.org — The /llms.txt convention — the links-first, machine-readable brief whose topology section pins what runs, in what order, in which files.
- Hunt, A. & Thomas, D. — The Pragmatic Programmer — tracer bullets and the discipline of building a system end to end in a fixed order.
- Anthropic — Building effective agents — giving a coding agent the structure and order it needs to assemble a system without guessing.
Related in this course
- A5.3.1 · The runtime shape
- A5.3.2 · The task DAG
- A5.3.3 · The file list
- A5.2 · References and requirements — the requirements this topology orders.
- Companion · The Phoenix request lifecycle — the request flow this topology describes, built in Elixir.
- Companion · Contexts and the facade — the boundary the file list respects.