Sequencing the ladder

The milestones group the rungs and the iteration sizes each one; sequencing decides the order they climb in. Two forces set it at once. Dependency: a rung that needs another's output comes after it — the rendered catalog (f6.5) needs persistence (f6.3), which needs the route surface (f6.2), which needs the served app (f6.1). Product priority: among the rungs that are buildable, the most valuable, least risky thread leads.

F6 reads as both at once. It ships the tracer (f6.1: request → facade → render) first to de-risk integration, then persistence and the rendered catalog — the first deployable product — before interactivity (f6.6–f6.7) and auth and deploy (f6.8–f6.9). Auth is high value but high risk, so it follows once the live catalog has earned feedback.

Among the buildable rungs, which leads? Score each by value minus risk. A rung that is high value and low risk leads; a rung that is high value but high risk waits until earlier rungs have lowered the unknowns. The tracer (f6.1) is low value on its own but very low risk and unblocks everything, so it leads the whole ladder.

The sorter below scores four rungs over a fixed model. It teaches a different move from the hero: the hero re-orders the whole ladder while holding spec edits at zero; this scores one rung at a time to show which thread should lead.

On the Portal, F6's order is the two forces resolved. Dependency fixes the spine: f6.1 (served app) → f6.2 (routes) → f6.3 (persistence) → f6.4 (domain) → f6.5 (rendered catalog). Product priority decides what leads where there is slack: the tracer first to de-risk integration, the deployable catalog before interactivity, auth and deploy last because they are high-risk and best informed by real feedback.

Re-sequencing any of this is a roadmap edit. Promote f6.6 ahead of f6.5, or split a milestone — phoenix.roadmap.md changes, and every f6.N.md spec stays exactly as written. That is what the hero figure's spec-edits counter, held at zero, makes visible.

# phoenix.roadmap.md — the ladder order (a roadmap property, not a spec).
order = ["f6.1", "f6.2", "f6.3", "f6.4", "f6.5", "f6.6", "f6.7", "f6.8", "f6.9"]

# Two forces set it:
dependency      = "a rung needing another's output comes after it"
product_priority = "the most valuable, least risky buildable thread leads"

# Re-ordering is a roadmap edit — the specs are untouched.
spec_edits = 0  # holds at zero however the rungs move

The ladder is sequenced by dependency and product priority: each rung must be buildable, and the most valuable, least risky thread leads. F6 ships the tracer first, then the deployable catalog, then live, then auth. Re-sequencing is a roadmap edit; the spec-edits counter holds at zero. That closes A3.5: rungs grouped into milestones, each sized as one iteration, ordered for value over risk — a delivery plan, not a flat to-do list.

The prioritisation sources behind sequencing the ladder, and where it connects in the course.