[Bug]: Cloudflare Pages deploys are always production — target: 'preview' is ignored, no way to publish a gated preview

[jxstanford]

Before you submit

• I searched existing issues and confirmed this is not a duplicate.
• I replaced the example text with the real behavior, reproduction steps, expected result, and version from the app's About menu or od --version.

What happened?

The Cloudflare Pages deploy provider always creates a production deployment served at the public root <project>.pages.dev, even though both DeployConfigResponse.target and DeploymentInfo.target are typed as 'preview'. There is no config or API option to request a non-production (preview) deployment, so a generated artifact is publicly live the instant it's deployed — you can't stage a gated preview URL for review before it goes public.

Steps to reproduce

1. Configure the Cloudflare Pages deploy provider (token + account ID).
2. Deploy any project artifact (POST /api/projects/<id>/deploy with providerId: "cloudflare-pages").
3. Note the returned url is the production root <project>.pages.dev and is publicly reachable immediately.
4. In the Cloudflare dashboard, open the deployment → Environment = Production (never Preview).
5. There is no setting or request field to make this a preview deployment.

Expected behavior

Because the deploy config and every DeploymentInfo are declared target: 'preview', a deploy should be able to produce a Cloudflare Pages preview deployment — a <hash>.<project>.pages.dev URL (deploy branch ≠ production_branch) that can be Access-gated, leaving the production hostname untouched. At minimum, OD should expose an explicit choice between production and preview rather than silently forcing production.

Open Design version

0.10.2 (od --version; reproduced on main @ 2ff2d79)

Platform

macOS (Apple Silicon) — but the defect is in the daemon deploy code and is platform-independent.

Additional context

Root cause (traced to source):

• apps/daemon/src/deploy.ts:498 hardcodes form.append('branch', 'main') on the deployment FormData.
• apps/daemon/src/deploy.ts:1000 sets production_branch: 'main'. Cloudflare Pages treats branch === production_branch as Production, so every deploy is Production.
• target: 'preview' (deploy.ts:168/182/432/543, routes/deploy.ts:125) and the contract literals (packages/contracts/src/api/projects.ts:506,527) are never translated into the Cloudflare deploy branch — the label only feeds internal metadata and DNS (pagesTarget, deploy.ts:628, is derived from the pages.dev hostname, not the branch).
• routes/deploy.ts accepts no branch/target override, so no caller can request a non-production deploy.

Suggested minimal direction: derive the deploy branch from an explicit deploy mode (preview → a non-main branch such as preview; publish/approve → main) and thread an optional target through routes/deploy.ts. This also unblocks #2357 (versioned handoff publishing), which presumes a working preview path.

[open-design-bot]

🎉 ✨ Welcome to Open Design, @jxstanford!

✨ 🔥 Lit the spark.

🌱 Your first contribution adds energy to the project. Thanks for showing up and helping Open Design grow.

💛 Thanks for helping Open Design grow. Keep building in the open. 🚀

🔗 Share on X (English) · 分享到 X（中文）

[lefarcen]

Hey @jxstanford! 👋 Thanks for the detailed source-level analysis — this is a clear bug.

I verified your findings:

• apps/daemon/src/deploy.ts:498 does hardcode form.append('branch', 'main')
• apps/daemon/src/deploy.ts:1000 sets production_branch: 'main' during project creation
• packages/contracts/src/api/projects.ts declares target: 'preview' in both DeployConfigResponse and DeploymentInfo, but this type annotation never controls the actual Cloudflare API branch parameter — so every deploy lands as Production

Root cause: The deploy code doesn't translate the target field into the Cloudflare Pages branch selection. Cloudflare Pages treats branch === production_branch as Production environment, so the hardcoded 'main' forces all deploys into production.

Why this matters: You can't stage a gated preview URL for review before it goes public. The generated artifact is live at <project>.pages.dev the instant deployment succeeds.

Your suggested direction (derive deploy branch from an explicit mode: preview → non-main branch like preview; publish → main) is the right architecture fix and unblocks #2357 (versioned handoff publishing).

This is a clean, well-scoped bug with a clear implementation path. I'll label it help wanted — if you or another contributor wants to take this on, a PR that threads an optional target through routes/deploy.ts and uses it to set the Cloudflare branch parameter would be very welcome. ✨