The runtime shape

Execution topology is the brief's third part, and the runtime shape is its first piece: a picture of the system while it runs. It names two things and fixes both — the supervision tree (the OTP processes and the supervisor over each, with a restart strategy) and the request path (the ordered hops a request takes to the one domain entry point). The companion course teaches how the tree and the lifecycle work; the brief's job is to draw the exact shape this rung must run in.

For the Portal's web bootstrap, F6.1-R2 pins it: the tree splits across two app supervisors, each strategy: :one_for_one. The :portal app keeps the three F5 domain children (Portal.Store, Portal.EventStore.adapter(), {Portal.Engine, []}); the new :portal_web app supervises PortalWeb.Telemetry and PortalWeb.Endpoint. The boundary is an app-level dependency arrow, :portal_web → :portal, and that ordering boots the domain children before the endpoint — the shape the agent reproduces, not one it chooses.

The second half of the runtime shape is the request path: the ordered hops a request takes from the endpoint, through the plug stack, to the one domain entry point. In f6.1.llms.md that path runs Plug.Static → Plug.RequestId → Plug.Telemetry → Plug.Parsers → Plug.Session → PortalWeb.Router, and from the router the courses route reaches CourseController.index/2, which calls only the facade, Portal.courses_of/1. Every domain path goes through the facade and returns either data or a %Portal.Error{}.

One path is the exception. The health route — GET /health in the F6.1 brief — returns 200 "ok" and performs no domain call. The brief names it as the one path that does not reach the facade, so the agent does not wire a domain call where none belongs. Toggle the figure below between the two routes to trace where each one ends. (The companion course walks the same hops as the live request lifecycle through the endpoint.)

The Portal's web bootstrap ships from f6.1.llms.md, and its runtime topology block draws the whole shape at once: the two supervisors with their children, the :portal_web → :portal app dependency that orders the boots, and the request flow ending at the facade. None of that is in the spec; all of it is in the brief.

# f6.1.llms.md — the runtime shape (F6.1-R2): two app supervisors, both :one_for_one
#
:portal      Portal.Application     # apps/portal — domain
  ├─ Portal.Store                  # F5 — the read model courses_of/1 reads
  ├─ Portal.EventStore.adapter()   # F5 — unchanged
  └─ {Portal.Engine, []}           # F5 — unchanged   (Bandit dropped → three)

:portal_web  PortalWeb.Application  # apps/portal_web — NEW, dep {:portal, in_umbrella: true}
  ├─ PortalWeb.Telemetry
  └─ PortalWeb.Endpoint            # boots AFTER :portal via the app dependency
#
# request flow:
#   Plug.Static → … → Plug.Session → PortalWeb.Router
#     └─ /courses/:user_id → CourseController.index/2 ──► Portal.courses_of/1
#     └─ /health → 200 "ok"   (no domain call — the one path that skips the facade)

The runtime shape is the first piece of a brief's execution topology: the supervision tree and the request path, both fixed. On the Portal, F6.1-R2 splits the tree across two :one_for_one app supervisors and orders the boot with the :portal_web → :portal dependency; the request flows the plug stack to the one facade, and only /health skips it. The next dive reads the same topology as a build plan — the task DAG that fixes the order this shape is assembled in.

Primary sources for the machine-brief form that carries a runtime topology, for pinning the running shape as a contract, and where the request lifecycle this shape describes is taught in the companion course.