Defer breadth

After the tracer ships, the platform is live but shallow: one thin path works end to end, and the rest is breadth not yet built. There are two ways to proceed. Breadth-first would add every feature a little at a time across the whole surface, with nothing complete end to end until the columns are joined. Depth-first grows the one thread that already works: each later rung deepens the proven slice, and breadth is added deliberately, one feature at a time.

Depth-first ships end-to-end value at rung one and keeps shipping it. The seams it has not reached are not ignored — they are written down as later rungs and named open decisions, so the roadmap stays honest about what it has not yet built. The figure shows what each order delivers first.

Deferring breadth is only honest if what is deferred is written down. A roadmap that quietly skips the seams it has not reached pretends to a certainty it does not have; a roadmap that names every deferred seam — as a later rung or an open decision — is honest about its uncertainty. The meter below scores that honesty over a fixed set of seams: it rises as more deferred seams are named, and reaches full only when none is hidden.

The two interactives teach different moves: the hero contrasts the two delivery orders, this one measures whether the deferral is honest. Slide the count of named seams and read the verdict.

On the Portal, rung f6.1 threads the system end to end. The roadmap does not then build every feature at once. It grows the thread — persistence (f6.3), the rendered catalog (f6.5), real-time (f6.7) — and the breadth it has not reached is deferred to the third milestone and written down as named open decisions: sign-in and deployment at f6.8, the operations dashboard at f6.9.

That is the honest move. A roadmap that claimed all of it was done at rung one would hide its uncertainty; naming the deferred seams as later rungs makes the uncertainty visible and bounded. Every rung — built or deferred — holds the master invariant: “The web layer calls only the Portal facade and renders only the closed %Portal.Error{} set.” F6.1 is the tracer, kept and grown; a prototype of it would be discarded.

# phoenix.roadmap.md — depth grows the thread; breadth is deferred and named.
#   f6.1 → f6.3 → f6.5 → f6.7   depth: grow the one live thread
#   open decisions (named, deferred): auth, deployment → f6.8 ; dashboard → f6.9

thread      = "f6.1"                  # the tracer, shipped first
deepened_by = ["f6.3", "f6.5", "f6.7"]  # depth follows the thread
deferred    = ["auth", "deployment", "dashboard"]  # named open decisions
honest      = true                    # every deferred seam is written down

# All of it under the master invariant: the web layer calls only the Portal facade.

Once the tracer is live, depth follows it: each later rung deepens the proven slice, and breadth is added deliberately. Deferring breadth is honest only when the deferred seams are named as later rungs and open decisions. On the Portal, F6.1 threads the system; F6.3, F6.5, F6.7 deepen it; auth and the dashboard are deferred to F6.8–F6.9 and written down. That closes the technique: thread first, tell a tracer from a prototype, then defer breadth honestly. Return to the hub to read the whole module, or carry on through the chapter.

The delivery-planning sources behind deferring breadth honestly, and where it connects in the course.