The iteration loop

Inside a milestone, each rung is one iteration — a PR-sized increment sized over four columns: Ships, Demo, Harness, Feedback.

The per-iteration table on the Portal's real phoenix.roadmap.md sizes every rung that way. Pick a rung on the right to fill its row — the slice it ships, the demo, the harness, and the feedback it asks for — each accepted before the next begins.

The four columns The per-rung loop On the Portal References

Fill the iteration row for a rung · pick one

f6.1 · Ships: the engine served as a web app · Demo: hit the root, see a page · Harness: ConnTest GET smoke · Feedback: shell and layout right? A PR-sized increment, accepted before the next begins.

One iteration, four columns

The milestones group the rungs; the iteration sizes each one. The per-iteration table on phoenix.roadmap.md gives every rung one row over four columns, verbatim: Rung, Ships (the slice), Demo, Harness, Feedback asked. The file calls each row “a PR-sized increment — a spec triad, the slice, a green harness, a demo, a feedback note”.

The columns hold the rung accountable. Ships names the vertical slice. Demo is the observable proof a real role can watch. Harness is the test that keeps it green. Feedback asked is the one question the demo puts to the reviewer. A rung is accepted — demo green, harness green, feedback taken — before the next begins.

Ships: the vertical slice the rung delivers — e.g. f6.1: “the engine served as a web app (endpoint, request → facade → render)”.
Demo: the observable proof — e.g. f6.1: “hit the root, see a page”.
Harness: the test that keeps it green — e.g. f6.1: a ConnTest GET smoke.
Feedback: the question the demo asks — e.g. f6.1: “shell and layout right?”.

The per-rung loop

Each row is run by a loop, stated verbatim in the file: sharpen → build → ship → demo → review → feedback → adapt. The Author sharpens the spec triad, builds the slice, ships it, demos it, the Operator reviews, feedback is gathered, and the plan adapts. The file's rule is the load-bearing part: feedback edits the spec, the single source of truth, never the shipped code.

Step the loop below to walk the seven phases. It teaches a different move from the hero: the hero fills one rung's table row; this walks the loop that produces and accepts it, and marks the two phases that edit the spec.

Step the per-rung loop

1 / 7

phase 1 / 7 · sharpen — the Author sharpens the rung's spec triad before any code is written. Edits the spec: yes (sharpening the contract, before the build).

Run each rung through one iteration; feedback edits the spec, not the shipped code, and the next rung starts from the corrected spec.

The iteration loop, on the Portal

On the Portal, the per-iteration table is the operational heart of phoenix.roadmap.md. Take f6.1: it ships the engine served as a web app; its demo is “hit the root, see a page”; its harness is a ConnTest GET smoke; its feedback asks “shell and layout right?”. A PR-sized increment with a demo and a harness, accepted before f6.2 begins.

When the demo prompts a change — “the shell needs the nav” — that feedback edits f6.1's spec. The next rung is built from the corrected spec, not by patching shipped code. The roadmap holds order; the spec holds behaviour; feedback flows into the spec.

# phoenix.roadmap.md — the per-iteration table (one row per rung; verbatim cells).
#   | Rung | Ships (the slice)              | Demo                  | Harness         | Feedback asked       |
#   | f6.1 | the engine served as a web app | hit the root, see a page | ConnTest GET smoke | shell and layout right? |
#   | f6.5 | the rendered catalog           | browse the catalog    | HTML render tests | layout, UX, error wording? |

# The per-rung loop runs each row:
loop = sharpen -> build -> ship -> demo -> review -> feedback -> adapt
edits_on_feedback = "the spec — the single source of truth"  # never the shipped code

the principle

Run each rung through one iteration over Ships, Demo, Harness, Feedback — a PR-sized increment with a demo and a harness, accepted before the next begins.

on the Portal

F6's per-iteration table sizes every rung that way over the one Portal facade. Feedback edits the spec; re-grouping rungs edits the roadmap, never a spec.

Size a rung so it ships, demos, and is accepted in one pass — then the next rung starts from a clean, corrected spec.

Recap — one iteration per rung

Each rung is one iteration over four columns — Ships, Demo, Harness, Feedback — a PR-sized increment run by the loop sharpen → build → ship → demo → review → feedback → adapt. Feedback edits the spec, never the shipped code, and a rung is accepted before the next begins. With the rungs grouped into milestones and each sized as an iteration, the last dive decides their order.

Next in A3.5: A3.5.3 · Sequencing the ladder — order by dependency and product priority while the spec-edits counter stays at zero.

References

The iteration sources behind the per-rung loop, and where it connects in the course.

Sources

Beck, K. — Extreme Programming Explained — the short cycle: plan, build, demo, take feedback, adapt.
Humble & Farley — Continuous Delivery — the PR-sized increment with an automated harness and a demo.
Hunt & Thomas — The Pragmatic Programmer — testing as the harness that keeps each increment green.

Related in this course

A3.5 · Milestones and iterations — the module hub.
A3.5.1 · Shippable milestones — the previous dive.
A3.5.3 · Sequencing the ladder — the next dive.
A3.3.2 · The iteration table — the same table read row by row.
A3.2 · XP for small batches — why a batch of one is the cheap default.
F6 · The Portal on the web (Phoenix) — the real chapter this roadmap plans.