Always runnable

A ladder is always runnable when, for every k, the prefix r₁ … rₖ is a runnable, demoable system. This is not an extra property to arrange — it falls out of dependency order. If every rung depends only on rungs below it, then for any prefix, every dependency of every included rung is also included; nothing points outside the prefix. Build the bottom rungs and the result runs.

“Runnable” here is the demoability the A2.01 vertical slice gave each rung, extended to the whole prefix: after rung k there is something a role can exercise end to end. That is the payoff of building bottom-up — the loop has a working system to demo and accept after every single rung, never a half-built one that only runs once the last piece lands.

The contrapositive is the failure. If a rung is built but a rung it depends on is not, that rung is orphaned — it points at something not built, so the build cannot run through it. Remove or skip a rung and every rung above it that depended on it is orphaned at once. Runnability is not the order of the rungs in a list; it is whether the set you have built is closed under dependency.

Toggle each rung built or skipped below. The checker reports whether the built set runs, and on a skip it names the first orphaned rung — a built rung whose dependency is missing — and paints it burgundy. The hero confirmed a clean prefix runs; this checker shows what breaks runnability when a rung is dropped out of order. Reading a clean prefix and finding the orphan in a broken set are two different moves.

On the Portal — the learning platform this course builds — the ladder runs at every prefix. After browse, a learner can browse the catalogue. After browse and enrol, browse then enrol. After browse, enrol, and open a lesson, enrol and open a lesson. The full four track progress over opened lessons. Each prefix is a working system the loop can demo and accept.

Skip enrol but keep open a lesson, and open a lesson is orphaned: it depends on enrolment that was never built, so that set cannot run. Runnability is a predicate over the built set — every built rung's dependency must also be built.

# The Portal dependency graph — the chain from dive 2.
deps = %{browse: [], enrol: [:browse], open: [:enrol], track: [:open]}

runnable? = fn built ->
  Enum.all?(built, fn rung ->
    Enum.all?(deps[rung], &(&1 in built))   # every dependency is also built
  end)
end

runnable?.(MapSet.new([:browse, :enrol]))          # => true  — a clean prefix
runnable?.(MapSet.new([:browse, :open]))           # => false — open is orphaned (enrol missing)

A clean prefix always passes; a built set that skips a rung leaves an orphan and fails. That is why the ladder is built bottom-up — the order guarantees the prefix.

A value ladder is the structure this chapter set out to build: capabilities, in dependency order, runnable at every rung. Every prefix is a working, demonstrable system, because dependency order keeps each prefix closed under dependency — and skipping a rung out of order orphans the rungs above it. The roadmap layer plans delivery over exactly this ladder — which rung ships in which iteration — and the spec layer defines each rung before the Author builds it. Those layers are named here, taught later.

Primary sources for keeping a system releasable at every increment, and where this connects in the course.