Roadmap of roadmaps

A backlog rolls up into a chapter roadmap; a set of chapter roadmaps rolls up into a program roadmap — three levels, each with its own unit.

The program roadmap sequences whole chapters into program milestones, then hands each chapter off to its own roadmap for rung-level detail. Zoom the level on the right to name each level's unit and its artifact — program (the chapter), chapter (the rung), rung (the spec).

Three levels Grouping chapters On the Portal References

Zoom the planning level · pick one

Program · unit: the chapter · artifact: portal.roadmap.md · example: sequence F4 store → F5 engine → F6 web · F10 bot → F7–F9 multi-runtime.

Three levels of planning

The same act — ordering work and pointing each item at the thing below it — happens at three altitudes. Each level has its own planning unit and its own artifact:

program: The planning unit is the chapter. The artifact is portal.roadmap.md — it sequences whole chapters (F4 store, F5 engine, F6 web, F10 bot, F7–F9 multi-runtime) into program milestones M1–M4.
chapter: The planning unit is the rung. The artifact is phoenix.roadmap.md — it sequences nine rungs f6.1…f6.9 into three milestones, each rung a line that points at a spec.
rung: The planning unit is the spec. The artifact is f6.N.md — it defines and proves one rung's behaviour. This is where behaviour finally lives.

A program milestone groups chapters the way a chapter milestone groups rungs. The roadmap of roadmaps does not restate a chapter's rungs — it sequences chapters and hands each off to its own roadmap.

Grouping chapters into program milestones

At the program level, chapters group into program milestones the same way rungs group into chapter milestones. From portal.roadmap.md, verbatim: M1 · the engine (F5), M2 · the web platform (F6), M3 · the bot (F10), M4 · the multi-runtime platform (F7–F9). Each milestone is a usable capability boundary — the engine answers commands; the web app is browsable; the bot runs the learner loop.

Re-grouping chapters edits the program roadmap, never a chapter spec. Pick a chapter below to see its program milestone and its capability — the spec-edits counter holds at zero, because grouping is a roadmap move, not a definition move.

Assign a chapter to its program milestone · pick one

F5 · the engine → M1 · The engine · capability: a correct, recoverable learning engine behind the facade · spec edits: 0.

The program roadmap sequences chapters into milestones — re-grouping them edits the program roadmap, never a chapter spec.

The roadmap of roadmaps, on the Portal

On the Portal — the learning platform this course builds — the program artifact is portal.roadmap.md. In its own words it “sequences the chapters that build it… into program milestones… and hands off to each chapter's own roadmap for rung-level detail.” The chapters stack: the store grounds the engine, the engine exposes the facade, and every surface sits on the facade. The web (F6) and bot (F10) are parallel surfaces over that one facade.

The program roadmap holds the order of chapters; each chapter's roadmap holds the order of its rungs; each spec holds behaviour. Three artifacts, three altitudes, one direction — each level points downward and defines nothing below it.

# portal.roadmap.md — the program at a glance (a line per chapter; verbatim cells).
#   | Chapter | Surface       | Program milestone           |
#   | F5      | engine core   | M1 · The engine             |
#   | F6      | web           | M2 · The web platform       |
#   | F10     | chat (bot)    | M3 · The bot                |
#   | F7–F9   | multi-runtime | M4 · The multi-runtime …    |

# Three artifacts, three altitudes — each points downward, defines nothing below.
program = "portal.roadmap.md"   # sequences chapters into M1…M4
chapter = "phoenix.roadmap.md"  # sequences rungs f6.1…f6.9
spec    = "f6.1.md"            # defines one rung's behaviour

# Re-grouping chapters edits the program roadmap; no chapter spec changes.

the principle

Plan in levels — a program roadmap sequences chapters into milestones; it does not restate a chapter's rungs, and grouping chapters edits no chapter spec.

on the Portal

portal.roadmap.md sequences F4 → F5 → F6 · F10 → F7–F9 into M1–M4; each chapter is handed off to its own roadmap. “Call only the facade” keeps the hand-off clean.

The program roadmap is the roadmap of roadmaps — it orders chapters; each chapter's roadmap orders its own rungs.

Recap — three altitudes, one direction

Planning happens at three levels: the program sequences chapters into milestones (portal.roadmap.md), a chapter sequences rungs into milestones (phoenix.roadmap.md), and a rung points at a spec that defines behaviour (f6.N.md). Each level points downward and defines nothing below it; re-grouping chapters edits the program roadmap, never a chapter spec. The next dive looks at why the chapters at the program level can be parallel surfaces over one core.

Next in A3.6: A3.6.2 · One core, many surfaces — one domain core behind one facade, surfaced through several adapters.

References

The program-planning sources behind the roadmap of roadmaps, and where it connects in the course.

Sources

Humble & Farley — Continuous Delivery — the deployment pipeline as a sequence of independently releasable stages.
Hunt & Thomas — The Pragmatic Programmer — orthogonality: levels that change independently of one another.
Beck, K. — Extreme Programming Explained — the planning game across releases, ordered by value.

Related in this course

A3.6 · The program roadmap — the module hub.
A3.6.2 · One core, many surfaces — the next dive.
A3.3 · Anatomy of a roadmap.md — one chapter roadmap, part by part.
A1.04 · Two layers — the roadmap over the spec.
F6 · The Portal on the web (Phoenix) — one of the chapters this program sequences.