seal-planlisted

# seal-plan A plan is the hardest artifact in the flow. Its whole job is to be **portable and deterministic**: hand it to another conversation, or a smaller model, and you should get the same result. That only holds if the plan is sealed. Three properties seal it. ## The three properties - **Closed — zero open decisions.** Every choice was made upstream (`expert-panel`, `shape-spec`). The plan is pure convergence. A plan that still contains a decision delegates that divergence to execution time, where each executor will resolve it differently — non-deterministic by construction. If you find an open choice while writing the plan, stop and settle it upstream. - **Pinned to a machine-checkable acceptance oracle.** "Same result" needs a definition of "same". It is *behavioral equivalence*: the same acceptance criteria pass, the same invariants hold — not character-identical output. So the plan must name an acceptance oracle that a machine can check (tests, criteria), and **snapshot the volatile part into the plan itself**. A plan whose acceptance target can drift between writing and execution is not deterministic. (This is where a plan differs from a spec: the spec points at a live oracle for freshness; the plan snapshots for determinism.) - **Written for the weakest executor (plan-to-the-floor).** Portability is relative to a capability floor. Write the plan for the *least* capable model you intend to run it on: exact file paths, complete code in every step, exact commands