One Common Process, Three Peer Surfaces

Rule

DPF delivers software through three interchangeable delivery surfaces: Claude Code, Codex CLI, and the embedded Build Studio. They are peers, not a hierarchy. None is privileged; work never depends on any one being healthy. All three advance the one common governed lifecycle — the Build Studio state machine ideate → plan → build → review → ship, advanced by evidence at each gate, right-sized by a (type × size) policy matrix. The phase graph never changes; a skipped phase gets an auto-pass gate. Each transition runs the gate check — nothing is rubber-stamped, regardless of surface.

Why

The enabling principle already exists and is operator-ratified: governance-approves-evidence-not-provenance. A gate reads only its required evidence fields and never branches on who produced them — which is exactly what makes three surfaces interchangeable. When the surfaces are not declared peers under one process, they diverge: one gets treated as primary, the others route around it, and the lifecycle fragments into three incompatible flows. The process is provenance-agnostic by design so it survives any surface being down, slow, or mid-upgrade.

The interactive surfaces (Claude/Codex) produce evidence and call the gate directly through MCP. The embedded surface (Build Studio) keeps its auto-advance engine but must converge on the same gate/evidence contract. Stabilizing that engine is the engine-first priority (spec §7 Q4) so Build Studio is a true peer surface, not a workaround the other two route around indefinitely.

How To Apply

Decision Dimensions

Origin

Unified Delivery Surfaces spec, 2026-06-05 (WWMD-ratified). Operator framing: “Build Studio is a 3rd delivery process like Claude and Codex, but more embedded.”