The iteration table

The per-iteration table is where a roadmap turns operational. Its header row, verbatim from phoenix.roadmap.md, is | Rung | Ships (the slice) | Demo | Harness | Feedback asked |. Each row is one rung, and each cell answers a concrete question.

The table holds order, not behaviour. Re-ordering the rungs re-plans delivery — it changes which slice ships first — and edits no spec, because the behaviour lives in the f6.N.md the row points at, never in the row. The control below re-orders a real slice of the F6 table; the spec-edits counter is wired to the order and stays at 0 no matter how the rungs are shuffled.

This is the move the hero figure could not show: the hero read a fixed row; this proves a consequence — that order is decoupled from definition. Re-plan freely above the facade; the specs below it do not move.

On the Portal, the real per-rung table in phoenix.roadmap.md lists nine rows, F6.1 through F6.9. F6.5 ships “the rendered catalog (index, course_card, form, inline errors)”, demos “browse the catalog; create with inline errors”, is harnessed by “HTML render tests; valid/invalid create”, and asks “layout, UX, error wording?”. F6.6 ships “interactivity (live search, live create, streams)” and asks “does the interaction feel right?”.

Each row is a vertical slice built to production quality, harnessed with ConnTest or LiveViewTest, and demoed for feedback. The order of the rows is the delivery plan; it re-plans without touching the specs, because every row points at a spec and defines no behaviour of its own.

# phoenix.roadmap.md — the per-rung table (verbatim cells).
| Rung | Ships (the slice)                            | Demo                          | Harness          |
| f6.1 | the engine served as a web app               | hit the root, see a page      | ConnTest GET smoke |
| f6.5 | the rendered catalog (index, course_card, …) | browse the catalog; create   | HTML render tests |
| f6.6 | interactivity (live search, live create)     | search as you type; no reload | LiveViewTest      |

# Re-ordering the rows re-plans delivery; the f6.N.md specs they point at do not change.
order      = ["f6.5", "f6.1", "f6.6"]  # a re-planned sequence
spec_edits = 0                          # order is decoupled from definition

The per-iteration table is where a roadmap turns operational: one rung per row, five columns — rung, ships, demo, harness, feedback asked — each row a PR-sized increment. The order is the delivery plan, and re-ordering the rungs edits no spec, because each row points at a spec and defines no behaviour. With the table read, the closing dive turns to what the roadmap names but does not resolve: the open decisions.

The small-batch delivery tradition the per-iteration table draws on, and where it connects in the course.