Publishing

Promote a verified build to a stable public URL

Overview

Publishing is live. A workspace whose latest retained source bundle has a QA-passed, render-verified static output can be promoted to one stable snapshot in Cloudflare R2 and served unauthenticated at /sites/<site-name>/ on the Taskcenter origin. Custom domains are not live: a published site is only reachable at its Taskcenter address, because DNS and certificate mapping still need a durable deploy target.

Readiness

Publish is only offered once the build is attested: the retained source bundle, the completed builder run, and the verified static output must all still match their D1 records and their R2 bytes, and the recorded QA and render-verification gates must have passed with no blockers. When any of those fails, the control is disabled and names the exact reason instead of publishing something unverified.

Publish, re-publish, rename, unpublish

Publishing writes one stable R2 object keyed by the site's durable name and records it in the D1 publish ledger. Re-publishing overwrites that same object and URL. Renaming copies the snapshot to the new name and retains a permanent redirect from the old one. Unpublishing deletes the object, so the public URL stops serving immediately and returns 404; the name is retained so a later publish restores the same URL. The same lifecycle is available to the agent and to the scheduled re-publish routine, authorized on thread write plus ownership of the workspace thread.

Custom domains

Mapping a customer-owned domain is not available. No DNS record, certificate, or deploy-target binding is created, and a domain request must say so rather than implying the site moved. Publishing itself is unaffected — the site stays reachable at its Taskcenter address.