Independent cadence

Because the web (F6) and the bot (F10) are parallel surfaces over the same facade, neither depends on the other for its core loop. From portal.roadmap.md, verbatim: “F6 (web) and F10 (bot) are parallel surfaces over the same F5 facade — neither depends on the other for its core loop, so they are sequenced by product priority, not by a hard dependency.” And: “M2 and M3 are both surfaces over M1's facade; either can lead, and they can advance in parallel once the engine's near-term slice is shipping.”

So each surface ships on its own cadence. The web ships catalog → live → users; the bot ships answer → identity → browse/enroll/learn. The one soft link is F10.8's webhook delivery, fronted by F6.1's endpoint — named, not a hard ordering of the core loops.

Re-ordering one surface's roadmap edits that surface's roadmap only. The figure below advances or defers the next rung on one surface; the other surface's row stays fixed, and two counters — “other-surface edits” and “core edits” — hold at zero. No spec is edited either: a reorder is a roadmap move.

The two figures teach different moves: the hero reads each surface's cadence over the shared facade; this one proves that re-ordering one cadence leaves the other surface and the core untouched.

On the Portal, the web (F6) and the bot (F10) advance as parallel tracks over the same Portal facade. From portal.roadmap.md's near-term path: “Continue the web (make it live, then auth and deploy) and the bot (browse, enroll, learn, progress) as parallel tracks over the same facade.” The Operator chooses which surface's next rung ships first, by product priority; the Author builds it; the shared core stays one delivery beneath both.

What lets the two cadences run independently is the master invariant. Because each surface calls only the facade and renders only the closed error set, re-ordering F6's rungs edits no F10 rung and no core code. The master invariant is the seam.

# portal.roadmap.md — two surfaces, two cadences, one facade (verbatim relations).
#   web (F6):  f6.1 catalog → f6.6 live → f6.8 users     (its own schedule)
#   bot (F10): f10.1 answer → f10.2 identity → f10.5 learn (its own schedule)
#   both over the one Portal facade · sequenced by product priority

# Re-ordering one surface edits that surface's roadmap only.
edited        = "web roadmap"  # the surface you reordered
other_surface = 0             # the bot is untouched
core_edits    = 0             # the core is untouched
spec_edits    = 0             # a reorder is a roadmap move, not a spec edit

# The master invariant — call only the facade — is the decoupling seam.

The web (F6) and the bot (F10) are parallel surfaces over the same facade, so each ships on its own cadence, sequenced by product priority rather than a hard dependency. Re-ordering one surface's roadmap edits that surface's roadmap only — the other surface, the core, and every spec stay untouched, because each surface calls only the facade. That closes A3.6: the program roadmap orders chapters; one core is surfaced through several adapters; and each surface ships on its own cadence over the one facade.

The independent-delivery sources behind separate cadences, and where this connects in the course.