feat: P4 Phase C — Build a flow (decomposition over the untouched pipeline)

[ryandmonk]

Flow decomposition per the ratified P4 architecture: one workflow goal → an editable plan of 2–8 steps (composer-core flow-plan.ts on the plan.ts idioms — existing intents only, enum-clamped, honest labeled deterministic fallback that never blocks) → the flow created immediately with every step PENDING (first-class state: warn-level lint, disabled navigator chips, outline preview) → each step driven as an ordinary runBuild turn, strictly sequential with provider-aware spacing (the P3a burst finding), Accept pre-targeted to its step through the Phase B binding, per-step resume buttons.

The generation pipeline, contracts, emit, A2UI, renderers, intents, and governance are untouched; no test makes a live gateway call; with the flow-mode toggle untouched the single-surface Build path renders byte-identically (pinned by e2e). runBuild now resolves the turn's outcome (computed from the turn's own events) so the driver can sequence — void callers unaffected.

Fail-first: pre-change failures pasted in 396ed22. composer-core 77→89, composer 65→68, smoke e2e 12→13, composer-agent 44/44 re-run, typecheck clean.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	dspack-studio-composer	f06b296	Aug 12 2026, 01:17 PM

[Copilot]

Pull request overview

Adds P4 Phase C “Build a flow” support by introducing flow decomposition planning (2–8 step editable plans) and a sequential per-step build driver, while keeping the underlying single-surface generation pipeline unchanged until the flow-mode toggle is enabled.

Changes:

• Introduces flow-plan planning primitives in composer-core (schema, provider-agnostic request builder, deterministic fallback, reconciliation).
• Adds an opt-in “Build a flow…” mode in Build UI with plan editing, immediate creation of PENDING flows, and sequential step builds with provider-aware spacing.
• Updates flow parsing/linting/preview to treat surfaceId: "" as a first-class “PENDING” step state, plus adds/extends unit + e2e coverage.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
packages/composer-core/src/index.ts	Re-exports new flow-plan APIs/types.
packages/composer-core/src/flows.test.ts	Adds a contract-level shape anchor test for empty surfaceId (pending step).
packages/composer-core/src/flow-plan.ts	New flow decomposition planner: schema, request builder, deterministic fallback, reconciler.
packages/composer-core/src/flow-plan.test.ts	New unit tests for flow-plan request shape, reconciliation, and deterministic behavior.
apps/composer/app/views/preview-view.tsx	Disables pending-step chips and renders an outline/pending empty-state instead of treating it as an error.
apps/composer/app/views/build-view.tsx	Adds flow-mode UI, plan editor, flow creation with pending steps, and sequential step build driver + accept targeting.
apps/composer/app/state.tsx	Extends runBuild to return a turn outcome and tags turns with flowStepHint for accept pre-targeting.
apps/composer/app/planning.ts	Adds planFlow() with hosted inference + deterministic fallback.
apps/composer/app/flows.ts	Adds pending-step helpers and updates flow lint to warn (not error) on pending steps.
apps/composer/app/flows.test.ts	Adds tests for pending-step lint behavior and parse acceptance.
e2e/composer-prod-smoke.spec.ts	Adds a full “build a flow” smoke test covering planning/editing/pending preview/sequential builds.

Suppressed comments (3)

apps/composer/app/views/build-view.tsx:620

• After a flow has been created (flowBuild !== null), the step title/goal/intent inputs remain editable. This can desync the persisted flow (already saved via saveFlows with step titles) from what the Build UI shows/uses for subsequent step builds, and it undermines the intended "edit → approve → build" lifecycle. Consider locking the step fields once the flow is created, not just while it's running.

                  <input
                    style={{ ...field, minWidth: 140 }}
                    value={step.title}
                    onChange={(e) => patchPlanStep(i, { title: e.target.value })}
                    disabled={flowBuild?.running === true}

apps/composer/app/views/build-view.tsx:699

• The "Create flow & build steps" button is enabled for 1-step (or >8-step) plans, which contradicts the 2–8 step contract and can lead to out-of-contract flows. Disable this action unless the plan is within bounds.

                  <button
                    className="st-btn st-btn--primary"
                    disabled={flowPlan.steps.length === 0 || planBusy || buildBusy}
                    onClick={() => void acceptPlan()}
                    data-testid="flow-plan-accept"
                  >
                    Create flow &amp; build steps

apps/composer/app/views/build-view.tsx:485

• acceptPlan() only guards against an empty plan, but it should enforce the same 2–8 step bounds as the flow-plan schema; otherwise a manually edited plan can create an out-of-contract flow and the driver will attempt to build an arbitrary number of steps.

  const acceptPlan = async () => {
    if (!flowPlan || flowPlan.steps.length === 0 || planBusy || buildBusy || flowBuild?.running) return;
    const plan = flowPlan; // frozen for this drive; the editor locks while running

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.