jonnifyagile agents
jonnify / Agile Agent Workflow / A2 · Decomposition / A2.07 · Workshop: decomposing Portal

A2.07 · Decomposition · capstone

Workshop: decomposing Portal

Six techniques, one real target. The capstone runs the whole chapter on the Portal’s web surface — and shows the decomposition is not hypothetical: it already happened, rung by rung, in a repository you can read.

A2.01 through A2.06 each taught one move. Here they land where they were actually used: the Portal’s web surface, built in the companion course as chapter F6 (Phoenix). A one-line vision — serve the Portal to people — was decomposed into nine vertical rungs (f6.1–f6.9), each a real capability carried by four artifacts — a roadmap line, a spec, Given/When/Then stories, an agent brief — built over the unchanged engine and proven before the next began. The slider walks that real roadmap; the three dives carry the what/why, the how, and the when by hand.

The Portal’s web surface, decomposed for real

The earlier modules taught the moves on toy stories. The capstone applies them where they were actually used: the Portal’s web surface — chapter F6 in the companion course. Its one-line vision, serve the Portal to people, was decomposed into nine vertical rungs, f6.1 through f6.9. Every rung ships one capability a real role can use, calls only the unchanged Portal facade, and carries its own four artifacts: a line in phoenix.roadmap.md, a spec f6.N.md, Given/When/Then acceptance in f6.N.stories.md, and an agent brief f6.N.llms.md.

Drag the slider to walk the roadmap. The readout answers the four questions a decomposition has to settle for every rung — what it delivers, when it was specified and shipped (from the repository’s git history), why (which milestone it serves), and how it is proven — read straight off the real f6.N files. Each rung is taught and built as its own chapter in the companion course, under /elixir/phoenix — the bootstrap at /elixir/phoenix/lifecycle, persistence at /elixir/phoenix/ecto, and so on through the dashboard.

The F6 web chapter · nine rungs, three milestones · drag to walk the roadmap

F6.1
M1 · ship the catalog M2 · make it live M3 · ship to users F6.1boot F6.2route F6.3Ecto F6.4ctx F6.5HEEx F6.6Live F6.7PubSub F6.8auth F6.9dash shipped ◂ ▸ specified
F6.1 · Bootstrap the Phoenix Portal — what: the headless F5 engine stands up as a Phoenix app — the endpoint joins the supervision tree, a thin controller calls only the facade, a GET /health route proves it is up. when: specced 02 Jun, shipped 03 Jun. why: milestone 1, ship the catalog. how: 5 stories in f6.1.stories.md; proven by — Given the running app, when I request GET /health, then I receive 200 with body ok.

A decomposition answers why, what, when, and how for every rung — and a good one leaves that trail in the repository, not only in a plan.

The three dives

Each dive carries part of the decomposition by hand on the real F6 chapter, in the arc what & why → how → when: read the vision into its rung ladder of real stories, show one rung as its four artifacts and its proof, then order the rungs into milestones and watch the specs evolve in git. Read them in order — A2.07.1 starts.

A2.07 closes the chapter on the real thing. The F6 decomposition walked above — nine rungs, four artifacts each, ordered into three milestones — is the kind of backlog Part III, the roadmap layer, plans into delivery. Each rung is then specified, built, and proven in the companion /elixir Phoenix chapter — F6.4 contexts at /elixir/phoenix/contexts, F6.6 LiveView at /elixir/phoenix/liveview; this workshop shows their decomposition. Return to the A2 module navigation to review the techniques it applies.

References

The end-to-end story-and-backlog tradition this capstone draws on, and the chapter modules it runs in sequence.

Sources

Related in this course