Order the backlog

Dives 1 and 2 produced nine ready, proven rungs — but nine rungs in a row are still a list. A backlog has an order, and the order is not a preference: it is the dependency graph. The value ladder groups the rungs into three milestones, each one a deliverable a real role can use, each resting only on the milestones below it, the system runnable at every boundary. This is the delivery arc the companion course’s phoenix.roadmap.md records, read straight off the source.

The arc is the first deployable product first, then layer interactivity, real-time, and operations on top. M1 ships the catalog (F6.1–F6.5): a persistent, server-rendered catalog you can browse and add to. M2 makes it live (F6.6–F6.7): the same catalog, interactive and pushed across clients. M3 ships to users (F6.8–F6.9): auth, a deployed clustered release, and an operations dashboard, once the live catalog has earned feedback. Pick a milestone in the hero to read what it ships; the rows below are verbatim from the roadmap.

The order is only half a backlog. A real one also has a history — it changed under feedback, and the repository keeps the receipts. The F6 decomposition was not written once and obeyed; it was written up front, built one rung at a time, and reconciled as each shipped rung taught the next. The cadence is spec → build → reconcile: every time the as-built surface diverged from the plan, the plan was edited — never the engine below the facade. This is the move A2.07’s parent loop names in A1.03.3 · Adapt: feedback edits the spec, not the code.

Step the slider through the nine dated F6 commits. The readout prints the date, the commit hash, and what changed — a rung flipping shipped, or a spec reconciled — with the running count of the ladder’s state. The clearest spec-edit is 5a440fd, the F6.5 route reconcile: a naming collision on /courses, surfaced during the build, sent feedback back into the spec.

Put the order and the history together and the F6 backlog reads as below: nine rungs over the unchanged F5 facade, grouped into three milestones, each milestone a runnable product, the shipped/specified frontier marked. This is the artifact the whole workshop was for — not a static list, but a dependency-ordered, version-controlled plan whose specs move under feedback while the engine holds still. The store and engine it rests on are built in the companion course; this ordering is the human work that decides what ships, in what order, and how the plan adapts. Each rung is specified, built, and proven at /elixir/phoenix, with the M3 frontier — auth and the deployed release — at /elixir/phoenix/deployment.

# The F6 backlog — nine rungs over the unchanged F5 Portal facade,
# ordered into three milestones. Each milestone is a runnable product.

# ── M1 · ship the catalog ─────────── browse + add, server-rendered ──
F6.1 boot     # shipped 03 Jun · the engine served as a Phoenix app
F6.2 route    # shipped 04 Jun · routes + pipelines + a protected scope
F6.3 Ecto     # shipped 04 Jun · persistence behind the EventStore port
F6.4 ctx      # shipped 04 Jun · Catalog/Enrollment/Accounts behind the facade
F6.5 HEEx     # shipped 04 Jun · the catalog rendered; route reconcile 5a440fd

# ── M2 · make it live ───────────── interactive + pushed to clients ──
F6.6 Live     # shipped 05 Jun · live search + live create over the facade
F6.7 PubSub   # specified  · per-socket state pushed across clients   ◄ frontier

# ── M3 · ship to users ───── auth, a deployed release, a dashboard ──
F6.8 auth     # specified  · phx.gen.auth, runtime secrets, a release task
F6.9 dash     # specified  · the whole chapter composed read-only, under auth

# Specs written 02 Jun (d2f959d); F6.1–F6.6 shipped by 05 Jun;
# F6.7–F6.9 specs reconciled forward as each rung shipped.

The workshop ran the whole chapter on one real target — the Portal’s web surface, the F6 Phoenix chapter. Dive 1 read the one-line vision into its nine-rung value ladder of real stories; dive 2 showed one rung (F6.6) as its four artifacts and proved it by its Given/When/Then; this dive supplied the two things that make a list a backlog — an order and a history. The order: nine rungs grouped into three dependency-ordered milestones — M1 ship the catalog (F6.1–F6.5), M2 make it live (F6.6–F6.7), M3 ship to users (F6.8–F6.9) — runnable at each, the shipped/specified frontier after F6.6. The history: the git trail of specs written 02 Jun, six rungs shipped by 05 Jun, and the rest reconciled forward — the spec the moving source of truth, edited by feedback. Six rungs are shipped; three are specified. That ordered, version-controlled backlog is the input to Part III.

Primary sources for ordering a backlog into milestones and treating the spec as the living plan, plus the real F6 chapter this dive reads from and the chapter moves it completes.