The first two stories

A5.4.1 made one agent story closeable: a Directive the agent runs and an Acceptance gate that closes it. The next question is whether the whole path — from a user story, through its agent story, to a verified change — is short enough that the agent has nothing left to decide. The brief answers it on paper, with a worked trace, before any agent runs.

The Portal's web bootstrap brief, f6.1.llms.md, ends its agent stories with a section titled ## Execution plan — first two stories. Its own words: “a worked trace of how the framework turns a user story into a verified change, to confirm the path is short and leaves no decision to the agent that the spec has not already fixed. Each plan is story → agent story → tasks → files → command → gate; an agent runs the steps top to bottom and stops at the gate.” Two plans are walked — one per story.

# f6.1.llms.md — ## Execution plan — first two stories
#
# Plan A — F6.1-US1 (serve the Portal as a Phoenix app) · via F6.1-AS1
  tasks    → T1 → T2 → T3   (foundation → endpoint → supervision)
  files    → the new apps/portal_web foundation/endpoint/supervision files (+ two core touches)
  command  → mix deps.get && mix compile && mix phx.server, then curl -i localhost:4000/health
  gate     → 200 ok from /health; the :portal tree boots store → engine before :portal_web (telemetry → endpoint)
#
# Plan B — F6.1-US2 (see a user's courses) · via F6.1-AS2
  tasks    → T4 → T5 → T6   (browser pipeline + route → controller → view)
  files    → router, controller, view, index.html.heex, error.html.heex
  command  → mix test …course_controller_test.exs, then curl localhost:4000/courses/USR_known
  gate     → a known user renders; empty state for none/unknown (200); injected %Portal.Error{} → 422

The plan's payoff is in its closing line. The brief ends the section with an efficiency check: “each story is two-to-six files behind one command and one gate, and every branch (empty state, injected-error render) is already specified — so the agent implements rather than decides.” That is the whole point of walking the plan: not the steps, but their shortness. A story whose path is a handful of files behind a single command and a single gate is a story the agent can implement; a story whose path sprawls is one it must navigate, and navigating means deciding.

Toggle the meter below between Plan A and Plan B. Each shows the files it touches and confirms one command and one gate stand behind them. Both plans land inside the two-to-six band.

Plan A and Plan B are not summaries; they are the literal steps an agent runs. Plan A builds the application as a Phoenix app: tasks T1→T3, the new apps/portal_web foundation and endpoint plus the two core edits that drop Bandit, one command (mix compile && mix phx.server, then a curl of /health), and one gate — 200 ok from /health with the :portal tree booting store → engine before the endpoint. Plan B renders a user's courses: tasks T4→T6, the router, controller, view, and two .heex templates, one command (the controller test plus a curl of /courses/USR_known), and one gate — a known user renders, an unknown or empty id renders the empty state at 200, and an injected %Portal.Error{} renders 422.

The path each plan walks is short because every branch it would otherwise have to invent — the empty state, the injected-error render — is already specified upstream. That is why the brief closes on its efficiency check, and why this dive sits before the prompt that runs the plans. The companion course walks the same path the running system takes for a request: the Phoenix request path the ordered build assembles.

A first-two-stories execution plan walks the opening stories from a user story through its agent story, the tasks, the exact files, one command, and one gate — before any agent runs. Plan A serves the Portal as a Phoenix app over T1→T3; Plan B renders a user's courses over T4→T6. Each is two-to-six files behind a single command and a single gate, and every branch is already specified, so the agent implements rather than decides. The next dive turns to the gate itself: the runnable check that closes a story, and what it means when one is missing.

Primary sources for turning a user story into a short, gated path, and where the stories this plan walks and the request path it assembles are defined in the companion course.