The program view

The chapter roadmap so far plans one surface: the web. The program roadmap plans the whole system. On the Portal that system is one domain core behind one facade, surfaced through several adapters. Two are roadmapped today: the web — chapter F6, planned in phoenix.roadmap.md — and the bot — chapter F10, planned in f10.roadmap.md.

They are parallel surfaces over the same facade. Neither depends on the other for its core loop, so they are sequenced by product priority, not a hard dependency, and each is a roadmap of its own. Reserved chapters F7–F9 (multi-runtime) are named, not designed. Adding a surface adds a roadmap; it does not change the core.

What lets two surfaces ship on independent cadences is the master invariant: every surface calls only the Portal facade and renders only the closed error set. Because no surface reaches below the facade, a change to one cannot ripple into another, and the core never changes underneath either. The figure below holds the invariant as a switch: when both surfaces call only the facade, their cadences are decoupled; if one is imagined to reach below it, the cadences couple. The two figures teach different moves — the hero reads each surface's roadmap, this one shows the invariant as the seam.

On the Portal — the learning platform this course builds — the program roadmap names one core, one facade, and several surfaces. The web (phoenix.roadmap.md, F6) and the bot (f10.roadmap.md, F10) are parallel surfaces over the one Portal facade, each a roadmap of its own, shipping on independent cadences; F7–F9 are reserved. The chapter roadmap this module produced is the web surface's plan, set in its place in the program.

The fragment below names the program in the roadmap's own terms — markdown, not Elixir source. This is the delivery plan Part VII executes: the same chapter roadmap, run rung by rung on the Portal end to end.

# portal.roadmap.md — the program view (markdown; the surfaces over one facade).
core      = Portal            # one domain core behind one facade
surfaces  =
  - web (F6)  -> phoenix.roadmap.md   # this module's chapter roadmap
  - bot (F10) -> f10.roadmap.md       # a parallel surface, its own roadmap
cadence   = independent       # sequenced by product priority, not dependency

# The master invariant is the seam: each surface calls only the Portal facade,
# so adding a surface adds a roadmap and never changes the core. F7–F9 reserved.

The workshop ran the whole roadmap layer on the Portal: A2's value ladder became a chapter roadmap of nine rungs in three milestones with a per-iteration table, a tracer was chosen and breadth deferred, and the chapter was set in a program view of web and bot over one facade. The output reproduces the real phoenix.roadmap.md; re-ordering rungs edits the roadmap, never a spec. That delivery plan is what Part VII executes, rung by rung, on the Portal — and what the next chapter, the spec layer, turns into proven behaviour.

The sources behind sequencing many surfaces over one core, and where it connects in the course.