ci: deploy brand site through Cloudflare Pages

[Jess Sullivan (Jesssullivan)]

Summary

• replace the stale GitHub Pages publisher with the TIN-2357 Cloudflare Pages static-spoke lane
• build through the repo Nix/Just contract before deploy
• skip deploy safely until CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID are configured

Validation

• nix develop --command just check
• nix develop --command just build
• nix develop --command gitleaks detect --source . --redact --verbose

Remaining operator blocker

The currently available Cloudflare tokens verify and can read the tinyland.dev zone, but return 403 code 10000 for the Cloudflare Pages API. Creating the Pages project/domain still requires a Pages-scoped token.

[linear]

TIN-2357 scheduling-bridge.tinyland.dev brand site: truth-fix maturity claims + finish the oauth-mux de-clone (CNAME/robots point at omux.xoxd.ai)

2026-07-02 prompt-03 truth pass (verified first-hand against the repo):

1. Maturity overstatement — README and +page.svelte claim flat "Acuity, cal.com, Vagaro, GlossGenius backend interop" with no status qualifiers. Verified reality: Acuity is the only production browser pack; CalCom is read-only (REST landed upstream); GlossGenius/Vagaro not started. Copy must carry the maturity ladder (production / read-only / planned), per the prompt-03 brand-copy deliverable.
2. Half-rebranded oauth-mux clone — CNAME and robots.txt still point at omux.xoxd.ai; page.server.ts, components, providers.json, /api/providers, and launch docs are all still oauth-mux content. The scheduling-bridge brand surface is currently publishing another product's identity.

Repo: tinyland-inc/scheduling-bridge.tinyland.dev (brand site only — the engine lives in Jesssullivan/scheduling-bridge, which is healthy: 0.7.1 triple-consistent, runFlow sole path, 14 golden traces incl. 7 failure paths, fuzzy single-sourced from kit /fuzzy).

Initiative: Practitioner Kit Platform.

Review in Linear