The open decisions

The closing section of phoenix.roadmap.md is “Seams & open decisions”. It does not pretend the chapter has no uncertainty; it lists each unresolved choice, says where it is the right time to decide, and names the seam the decision will plug into. An honest roadmap states its open questions rather than hiding them.

The open decisions are real, but they are not unbounded. The master invariant constrains every one of them, verbatim: “The web layer calls only the Portal facade and renders only the closed %Portal.Error{} set.” Whatever authentication, deployment target, or dashboard the project chooses, the resolution sits over the facade — so the F5 engine below it does not move.

The control below picks a resolution for one open decision. The invariant readout stays “holds” across every allowed choice, because the boundary is fixed regardless of which option wins. This is the move the hero figure could not show: the hero read each decision and its rung; this proves the consequence — that the invariant holds no matter how a decision resolves.

On the Portal, phoenix.roadmap.md names five seams it does not resolve up front: authentication and the deploy target (both “decided then” at F6.8), the dashboard's metrics (decided at F6.9), the catalog browsing read (Catalog.list_courses/0, distinct from the facade's courses_of/1), and the Postgres EventStore adapter behind the F5.8 port. Each is deferred to the rung where the information to decide it exists.

None of them threatens the engine, because all of them sit over the facade. In the file's words, the only structural change to the F5 supervision tree across all of F6 is adding PortalWeb.Endpoint; later rungs add PubSub and Presence “only as the real-time features require them”. The open decision is named; the master invariant fixes the boundary it resolves within.

# phoenix.roadmap.md — "Seams & open decisions" (named, not resolved).
#   Authentication (F6.8)       — "the choice of social/SSO … is decided then"
#   Deployment & clustering (F6.8) — "the deploy target … is decided then"
#   Dashboard data (F6.9)        — "which metrics it shows … is decided then"

# Every resolution stays over the master invariant — the boundary is fixed.
defmodule PortalWeb.SomeController do
  # calls only the Portal facade; renders only %Portal.Error{}
  Portal.enroll(user_id, course_id)   # whatever auth resolves to, this does not change
end

The “Seams & open decisions” section names what a roadmap has not decided — auth, deployment, the dashboard, the catalog read, the event-store adapter — says where each is decided, and names the seam. Deferring a decision to its rung is sequencing, not avoidance; and the master invariant bounds every resolution, so the engine below the facade never moves. That closes A3.3: a roadmap carries six parts, the per-iteration table at its heart, and the open decisions named but not resolved — all read on the real phoenix.roadmap.md.

The sources behind naming open decisions and bounding them with an invariant, and where this connects in the course.