@decocms/start 2.30.1 → 4.0.0

package/.agents/skills/deco-to-tanstack-migration/SKILL.md

@@ -315,7 +315,7 @@ See: `references/search.md`
 5. **`tsconfig.json` mirrors `vite.config.ts`** -- only `"~/*": ["./src/*"]` in paths
 6. **Signals don't auto-subscribe in React** -- reading `signal.value` in render creates NO subscription; use `useStore(signal.store)` from `@tanstack/react-store`
 7. **Commerce loaders need request context** -- `resolve.ts` must pass URL/path to PLP/PDP loaders
-8. **`wrangler.jsonc` main must be a custom worker-entry** -- TanStack Start ignores `export default` in `server.ts`. The `main` field lives in the **central** `decocms/deco-start/deploy/wrangler-template.jsonc` (D6); site repos do not commit `wrangler.jsonc`.
+8. **`wrangler.jsonc` main must be a custom worker-entry** -- TanStack Start ignores `export default` in `server.ts`. The `main` field lives in the site's per-site `wrangler.jsonc`.
 9. **Copy components faithfully, never rewrite** -- `cp` the original, then only change mechanical things (class→className, imports). NEVER regenerate or "improve" — AI-rewritten components are the #1 source of visual regressions
 10. **Tailwind v4 logical property hazard** -- mixed `px-*` + `pl-*/pr-*` on the same element breaks the cascade
 11. **oklch CSS variables need triplets, not hex** -- `oklch(var(--x))` must store variables as oklch triplets

package/.agents/skills/deco-to-tanstack-migration/references/worker-cloudflare.md

@@ -37,7 +37,7 @@ TanStack Start's Cloudflare adapter **completely ignores** the `export default`
 
 **Diagnosis**: Search the built `dist/server/worker-entry-*.js` bundle for your custom code (e.g., `X-Cache`, `caches.open`, `_cache/purge`). If absent, TanStack stripped it.
 
-**Fix**: Create a **separate** `src/worker-entry.ts` file that wraps TanStack Start's built handler. Wrangler is told to use this file via `main: "./src/worker-entry.ts"` in the **canonical wrangler template** at `decocms/deco-start/deploy/wrangler-template.jsonc` (D6) — sites do not configure this themselves.
+**Fix**: Create a **separate** `src/worker-entry.ts` file that wraps TanStack Start's built handler. Wrangler is told to use this file via `main: "./src/worker-entry.ts"` in the site's `wrangler.jsonc`.
 
 ```typescript
 // src/worker-entry.ts
@@ -58,9 +58,10 @@ export default createDecoWorkerEntry(serverEntry, {
 ```
 
 The `main` field is set centrally so a future migration of the entry path
-applies to every site at once (single PR to the template). If you ever need to
-override `main` for a single site, add it under `deploy/sites/<repo>.jsonc` —
-never to a per-site `wrangler.jsonc` (sites don't commit one; see D6).
+applies to every site at once (single PR to the template). There is no
+per-site override file; if a single site truly needs a different
+entry path, change the template (and accept that all sites get it) or add a
+substitution token like `$WORKER_ENTRY_PATH` and feed it from a per-site env.
 
 This ensures admin route interception AND edge caching survive the build because they're in the Worker's own fetch handler, outside of TanStack's build pipeline.
 
@@ -140,7 +141,7 @@ After deploying a new build to Cloudflare Workers, the edge cache may still serv
    `npx wrangler secret put` manually per-site — the central workflow keeps
    GitHub and Cloudflare in sync.
 2. Call the purge endpoint: `POST /_cache/purge` with `Authorization: Bearer <token>` and body `{"paths":["/"]}`
-3. The right place to automate this is the **central** `deco-start/.github/workflows/deploy.yml` (D6) so every site picks it up at once. Do not add site-local deploy.yml steps; site repos hold only ~5-line caller workflows.
+3. Currently this lives in each storefront's per-site `deploy.yml` (D6 centralization was reverted; D6.3 Workers Builds replacement is in flight).
 
 
 ## 44. Runtime Module Import Kills Lazy-Loaded Sections
@@ -211,111 +212,34 @@ Or in project `.npmrc` with an env var (for CI):
 **Tradeoff with `github:` syntax**: No semver resolution — `npm update` is meaningless. Pin to a tag for stability: `github:decocms/deco-start#v0.14.2`. Without a tag, you get HEAD of the default branch.
 
 
-## 46. Central Deploy / Wrangler Config (D6)
+## 46. Deploy / Wrangler Config (interim, D6.3 in flight)
 
-**Severity**: HIGH — site repos must NOT commit `wrangler.jsonc` or per-site deploy logic. Doing so reintroduces drift.
+**Status (2026-05-07)**: D6.2's centralized App-mediated dispatch was
+**reverted** in favour of Cloudflare Workers Builds owning the deploy
+pipeline per-worker. The Workers Builds onboarding plan is being
+designed in a follow-up PR. Until it lands, this section describes the
+**interim state**: each storefront retains its own per-site inline
+`deploy.yml` workflow (the original pre-D6 setup), with its own
+`CLOUDFLARE_API_TOKEN` and `CLOUDFLARE_ACCOUNT_ID` repo secrets.
 
-Per [D6](../../../../.cursor/rules/migration-tooling-policy.mdc), all
-storefronts deploy via reusable workflows shipped from
-`decocms/deco-start/.github/workflows/{deploy,preview,sync-secrets,regen-blocks}.yml@v2`.
-The canonical `wrangler.jsonc` lives at
-`decocms/deco-start/deploy/wrangler-template.jsonc`; per-site overrides live at
-`decocms/deco-start/deploy/sites/<repo-name>.jsonc`. The two are deep-merged at
-deploy time and written to a generated `wrangler.jsonc` in the runner; site
-repos gitignore the file.
+Site repos **do** commit a per-site `wrangler.jsonc` during the interim
+period. The `deco-wrangler` CLI no longer ships from `@decocms/start`.
 
-### What goes in the site repo
+### What changes when Workers Builds onboarding ships
 
-Four ~5-line caller workflow stubs and nothing else:
+When the D6.3 replacement lands, expect:
 
-```yaml
-# .github/workflows/deploy.yml
-name: Deploy
-on:
-  push:
-    branches: [main]
-permissions:
-  contents: write
-jobs:
-  deploy:
-    uses: decocms/deco-start/.github/workflows/deploy.yml@v2
-    secrets: inherit
-```
-
-(Plus equivalent `preview.yml`, `regen-blocks.yml`, `sync-secrets.yml` —
-see `scripts/migrate/templates/github-workflows.ts` for the canonical text.)
-The migration script generates these for new sites; the same stubs are
-hand-applied to existing sites.
-
-### What goes in `decocms/deco-start/deploy/sites/<repo>.jsonc`
-
-The minimum:
-
-```jsonc
-{
-  "worker_name": "<repo-name>"
-}
-```
-
-Plus optional `routes`, `kv_namespaces`, `analytics_engine_datasets`,
-`version_metadata` for the few sites that need them. Adding a new site is a
-PR to deco-start, not a change to the site repo.
-
-### Local dev
-
-Site repos add three package.json hooks so vite picks up the generated
-`wrangler.jsonc`:
-
-```jsonc
-"scripts": {
-  "gen:wrangler": "deco-wrangler gen",
-  "predev": "deco-wrangler gen",
-  "prebuild": "deco-wrangler gen",
-  "types": "deco-wrangler types",
-  "deploy": "echo 'Production deploys are managed by .github/workflows/deploy.yml on push to main. For an emergency manual deploy run: npx deco-wrangler deploy'; exit 1"
-}
-```
+- Per-storefront CF Builds connection (one dashboard click per worker).
+- Per-site `.github/workflows/deploy.yml` removed; CF Builds takes over
+  on push.
+- `wrangler.jsonc` continues to live in the site repo, but a `deco-build`
+  CLI in `@decocms/start` regenerates the bindings (KV, R2, etc.) from a
+  central template at build time so customers can't add bindings to
+  other tenants' resources.
+- `name` field in `wrangler.jsonc` is enforced by CF (verified against
+  `baggagio-tanstack` 2026-05-07 — a malicious `name` value is ignored
+  and CF auto-opens a PR to fix it).
 
-`deco-wrangler` is a `bin` shipped from `@decocms/start` that materializes the
-canonical config from the central registry, then either exits (`gen` mode) or
-execs the real `wrangler` with that config in cwd.
-
-### Trust model
-
-- The central workflow ignores all caller `inputs:` for site identity.
-- Site name is derived from `${{ github.repository }}` (set by GitHub,
-  untamperable by user code) and looked up in `deploy/sites/<repo>.jsonc`.
-- A customer cannot misroute their deploy onto another site's worker
-  because they can't write to `decocms/deco-start` (CODEOWNERS-protected).
-- `CLOUDFLARE_API_TOKEN` and `CLOUDFLARE_ACCOUNT_ID` live ONLY in
-  `decocms/deco-start`'s `production` GitHub Environment. The reusable
-  workflow declares `environment: production`, which makes
-  `${{ secrets.CLOUDFLARE_* }}` resolve from the called repo's environment
-  instead of the caller's repo secrets. Storefront repos never hold the
-  Cloudflare credential.
-- Per-site runtime secrets in storefront repos are prefixed `SECRET_*` and
-  flow into the worker via the central `sync-secrets.yml`, which inherits
-  them via `secrets: inherit`, validates names, and `wrangler secret put`s
-  them under their unprefixed name.
-
-### Common mistakes (do not do these)
-
-- **Committing `wrangler.jsonc` to a site repo.** Generated only;
-  always gitignored. If you see it tracked, the site missed migration.
-- **Adding a site-local `deploy.yml` step** (e.g. cache purge after deploy).
-  Add it to `deco-start/.github/workflows/deploy.yml` instead so every site
-  picks it up at once.
-- **Hard-coding `account_id` in a site's wrangler config.** It comes from
-  `CLOUDFLARE_ACCOUNT_ID` (in `decocms/deco-start`'s `production`
-  Environment in CI; `wrangler login` locally). Removing it from JSON is
-  the one-way protection against accidentally deploying to the wrong
-  account.
-- **Adding `CLOUDFLARE_*` to a storefront repo's secrets.** They belong
-  in `decocms/deco-start` only, in the `production` environment. The
-  central workflow's `environment:` binding overrides anything passed
-  from the caller, so an accidental copy on a site is dead code.
-- **Setting `worker_name` to anything other than the repo name** without
-  a strong reason. The 1:1 binding makes audit (and incident response)
-  trivial. Exceptions today: `casaevideo-storefront` -> `casaevideo-tanstack`
-  and `miess-01-tanstack` -> `miess-tanstack` (both for historical
-  Cloudflare worker names that predate the repo).
+Until then, do NOT scaffold caller stubs that reference
+`decocms/deco-start/.github/workflows/*.yml@vN` — those workflows are
+gone.

package/.agents/skills/deco-to-tanstack-migration/templates/package-json.md

@@ -12,11 +12,8 @@
     "generate:blocks": "tsx node_modules/@decocms/start/scripts/generate-blocks.ts",
     "generate:invoke": "tsx node_modules/@decocms/start/scripts/generate-invoke.ts",
     "generate:schema": "tsx node_modules/@decocms/start/scripts/generate-schema.ts --site storefront",
-    "gen:wrangler": "deco-wrangler gen",
-    "predev": "deco-wrangler gen",
-    "prebuild": "deco-wrangler gen",
-    "types": "deco-wrangler types",
-    "deploy": "echo 'Production deploys are managed by .github/workflows/deploy.yml on push to main. See D6.'; exit 1"
+    "deploy": "wrangler deploy",
+    "types": "wrangler types"
   },
   "dependencies": {
     "@decocms/apps": "^0.20.1",

package/.cursor/rules/migration-tooling-policy.mdc

@@ -1,5 +1,5 @@
 ---
-description: Constitutional decisions for the deco-start migration-tooling effort (D1–D6, priorities, process). Always loaded.
+description: Constitutional decisions for the deco-start migration-tooling effort (D1–D5 + D6.3 revert, priorities, process). Always loaded.
 alwaysApply: true
 ---
 
@@ -14,7 +14,7 @@ summary; always defer to the plan when they conflict.
 1. **Design for 100 sites, not 3.** When the surface of an abstraction is
    well-understood, ship it. Don't defer waiting for "more signal" — design
    for the projection. When the surface is *not* understood, *decide*
-   explicitly (write a D-record like D1–D6), don't ship fast.
+   explicitly (write a D-record like D1–D5), don't ship fast.
 2. **Strict over flexible.** No support layers, no soft drift, no
    fork-runtime adapters. Every fork divergence becomes either a PR back to
    canonical or visible local debt.
@@ -76,38 +76,36 @@ Failure modes get documented in skills, not encoded as escape hatches.
 **Agent behavior**: when a migration goes sideways, propose deletion +
 re-run, not in-place repair. Add the failure mode to the skill.
 
-### D6 — Deploy / preview / secrets pipelines: centralize in `deco-start` (signed off 2026-05-07)
-All storefronts deploy via reusable workflows under
-`decocms/deco-start/.github/workflows/{deploy,preview,sync-secrets,regen-blocks}.yml@v2`.
-Per-site overrides live in [`deploy/sites/<repo>.jsonc`](../../deploy/) and
-are deep-merged on top of [`deploy/wrangler-template.jsonc`](../../deploy/wrangler-template.jsonc)
-at deploy time. **Customer repos do not commit `wrangler.jsonc`** — it is
-generated locally by `deco-wrangler gen` (a `bin` shipped from
-`@decocms/start`) and gitignored. The repo→worker binding is the trust
-boundary: the central workflow ignores caller `inputs:` for identity and
-derives the site name from `${{ github.repository }}`. `deploy/**` is
-CODEOWNERS-protected.
-
-**Cloudflare credentials live in `decocms/deco-start` only**, in the
-`production` GitHub Environment. The reusable workflows declare
-`environment: production`, which makes `${{ secrets.CLOUDFLARE_* }}`
-resolve from the called repo (deco-start) instead of the caller. A
-storefront repo only ever holds its own `SECRET_*` runtime secrets
-(pushed to its worker by the central `sync-secrets.yml` via
-`secrets: inherit`). Two-tier secret model is the second half of the
-trust boundary — even a fully compromised storefront repo has no path
-to the Cloudflare token.
-
-**Agent behavior**: when adding or migrating a site, do **not** generate a
-per-site `wrangler.jsonc` or per-site `deploy.yml` / `preview.yml` /
-`sync-secrets.yml` / `regen-blocks.yml`. The site repo gets the four
-~5-line caller stubs only. Per-site config goes in a PR to
-`decocms/deco-start` adding `deploy/sites/<repo>.jsonc`. Do not commit
-`wrangler.jsonc` or any wrangler config to a site repo. Do **not** add
-`CLOUDFLARE_*` to a storefront repo's secrets — the central workflow's
-`environment:` binding overrides anything passed from the caller, so an
-accidental copy on a site is dead code at best and a credential leak
-risk at worst.
+### D6.3 — Revert D6/D6.1/D6.2; Cloudflare Workers Builds owns deploy (signed off 2026-05-07)
+The whole D6 family — centralized GitHub Actions reusable workflows under
+`decocms/deco-start/.github/workflows/{deploy,preview,sync-secrets}.yml`,
+the `decocms-deployer` GitHub App, the per-storefront `<site_name>-secrets`
+GitHub Environments, the central `deploy/wrangler-template.jsonc`, the
+`deco-wrangler` CLI, the `deploy/sites/<repo>.jsonc` registry, and the
+per-site caller stubs — has been **reverted**.
+
+Why: GitHub Free orgs do not propagate org-level secrets to private repos,
+which forced the App private key to be distributed to every storefront repo
+individually. That key gives the holder the ability to mint installation
+tokens for any installed repo, concentrating blast radius on a credential
+that had to be rotated across N storefronts. The trust model couldn't pay
+for itself at our scale.
+
+**Replacement direction (to be elaborated in a follow-up D-record once
+shipped):** Cloudflare Workers Builds owns deploy/preview pipelines per-worker.
+The dashboard repo<->worker connection is the source of truth — verified
+empirically against `baggagio-tanstack` 2026-05-07 that a malicious
+`wrangler.jsonc` `name` field is ignored, the deploy lands on the connected
+worker, and CF auto-opens a PR to fix the config. Per-storefront wiring is
+one CF dashboard click per worker.
+
+**Agent behavior — current interim period**: while D6.3's replacement is
+being designed, do **not** scaffold `decocms/deco-start@vN`-calling caller
+stubs in storefronts and do **not** depend on a `deco-wrangler` CLI from
+`@decocms/start` (it no longer exists). Storefronts retain their existing
+per-site inline `deploy.yml` (with their own `CLOUDFLARE_*` secrets) until
+Workers Builds onboarding lands. Site repos do still commit `wrangler.jsonc`
+during this interim — `deco-wrangler gen` is gone.
 
 ## Priority order
 
@@ -142,4 +140,3 @@ order — but only if explicitly identified as urgent.
 - When reading a section of the plan or a skill, prefer the plan or skill
   over your memory of past conversations.
 - Do not run `deco-deploy` or any deploy command from agent flows.
-- Do not commit `wrangler.jsonc` to a site repo. See **D6** above.

package/CODEOWNERS

@@ -1,16 +1,6 @@
 # CODEOWNERS for decocms/deco-start
 #
-# `deploy/` is the trust boundary for the central deploy pipeline. The files
-# under `deploy/sites/` immutably bind a customer repo to a Cloudflare worker;
-# `deploy/wrangler-template.jsonc` is the canonical wrangler config every site
-# inherits. A bad PR here can misroute a deploy or change every site's runtime
-# configuration in one shot. Only the platform team approves changes.
-#
-# The central reusable workflows are in the same trust boundary: they decide
-# how every site is built and deployed.
-deploy/                       @vibe-dex
-.github/workflows/deploy.yml         @vibe-dex
-.github/workflows/preview.yml        @vibe-dex
-.github/workflows/sync-secrets.yml   @vibe-dex
-.github/workflows/regen-blocks.yml   @vibe-dex
-scripts/deploy/                      @vibe-dex
+# Workflows under `.github/workflows/` decide how this package is built,
+# released, and what blocks regeneration sites can trigger. Only the
+# platform team approves changes.
+.github/workflows/                   @vibe-dex

package/MIGRATION_TOOLING_PLAN.md

@@ -118,7 +118,9 @@ this plan.
 | 2026-05-01 | **D4 — Site-local apps: local by default, promote at 3** | Site-specific apps live in `src/apps/local/` until ≥3 sites use them, then promote to `@decocms/apps`. |
 | 2026-05-01 | **D5 — Failed migrations: rm -rf and re-run** | No `--restart` mode. Half-migrated sites are throwaways. Failure modes get documented in skills, not encoded as escape hatches. |
 | 2026-05-07 | **D6 — Deploy / preview / secrets pipelines: centralize in `deco-start`** | At 6 sites the "1-minute copy" of `deploy.yml` / `preview.yml` / `wrangler.jsonc` had already produced unintended drift (lebiscuit missing 2 workflows, miess missing `account_id`, casaevideo's `loadtest:tail` worker name out of sync with its wrangler config). All sites now consume reusable workflows from `decocms/deco-start@v2` and a per-site registry under [`deploy/sites/<repo>.jsonc`](./deploy/) deep-merged on top of [`deploy/wrangler-template.jsonc`](./deploy/wrangler-template.jsonc) at deploy time. Customer repos hold only ~5-line caller workflows; `wrangler.jsonc` is generated and gitignored. The repo→worker binding is the trust boundary that prevents one site's commits from misrouting onto another site's worker (the central workflow ignores caller `inputs:` for identity and derives the site name from `${{ github.repository }}`). See [`deploy/README.md`](./deploy/README.md) for the contract. |
-| 2026-05-07 | **D6.1 — Cloudflare credentials never leave `deco-start`** | Same-day refinement of D6 after the first central deploy on `baggagio-tanstack` failed with `Secret CLOUDFLARE_API_TOKEN is required, but not provided while calling`. The original D6 design used `secrets: inherit` from the storefront stub and required `CLOUDFLARE_*` to live in the `deco-sites` org, which broke the principle that *the only secrets a storefront repo holds are the secrets that go into wrangler secrets, not the ones used to deploy*. Refinement: the central `deploy.yml` / `preview.yml` / `sync-secrets.yml` jobs declare `environment: production`, which makes `${{ secrets.CLOUDFLARE_* }}` resolve from the called repo (`decocms/deco-start`'s `production` GitHub Environment) instead of the caller's repo secrets. Storefronts now hold only their own `SECRET_*` runtime secrets; `sync-secrets` inherits those via `secrets: inherit` and pushes them as worker secrets. The trust boundary becomes two-tier: even a fully compromised storefront repo has no path to the Cloudflare credential, and even a compromised storefront cannot misroute *its own* deploy onto another site's worker because `worker_name` comes from the CODEOWNERS-protected registry, not caller input. See [`deploy/README.md`](./deploy/README.md) "Where Cloudflare credentials live" section. |
+| 2026-05-07 | **D6.1 — Cloudflare credentials never leave `deco-start`** | Same-day refinement of D6 after the first central deploy on `baggagio-tanstack` failed with `Secret CLOUDFLARE_API_TOKEN is required, but not provided while calling`. The original D6 design used `secrets: inherit` from the storefront stub and required `CLOUDFLARE_*` to live in the `deco-sites` org, which broke the principle that *the only secrets a storefront repo holds are the secrets that go into wrangler secrets, not the ones used to deploy*. First-pass refinement: the central `deploy.yml` / `preview.yml` / `sync-secrets.yml` jobs declared `environment: production` to try to make `${{ secrets.CLOUDFLARE_* }}` resolve from `decocms/deco-start`'s `production` Environment. **Found broken empirically on 2026-05-07** — the deployment registers in the *caller* repo, not the called workflow's repo, so the environment lookup uses the caller's `production` env (auto-created with no secrets). Superseded by D6.2 the same evening. |
+| 2026-05-07 | **D6.2 — App-mediated dispatch + no per-site registry (supersedes D6 + D6.1)** | After D6.1's `environment:` mechanism was empirically shown not to work cross-repo, the architecture pivoted: a `decocms-deployer` GitHub App is installed on `decocms/deco-start` (`actions:write`) and on each storefront repo (`contents:read`, optionally `pull-requests:write`). The storefront caller stub mints a short-lived App-installation token and calls `gh workflow run deploy.yml --repo decocms/deco-start --ref v3 -f site_owner=… -f site_name=…`. The central workflow runs in `decocms/deco-start`'s context, so `CLOUDFLARE_API_TOKEN` / `CLOUDFLARE_ACCOUNT_ID` are ordinary repo secrets. For runtime `SECRET_*` values, each storefront has a `<site_name>-secrets` GitHub Environment in `decocms/deco-start` (S1 design); `sync-secrets.yml` binds to that environment and pushes to `wrangler secret put`. The per-site registry under `deploy/sites/<repo>.jsonc` was dropped entirely (Pure C): worker name = repo basename by convention; the App being installed on the storefront repo is the deploy authorization gate; rare per-worker derived fields (like AE dataset name) use `$WORKER_*` substitution tokens in the template. Force-rollback is impossible for production deploys because the central workflow ignores caller-supplied `site_sha` and resolves the storefront's current default-branch HEAD itself. See [`deploy/README.md`](./deploy/README.md) for the full trust model. **Operational migrations required by Pure C:** `miess-01-tanstack` repo's worker shifts from `miess-tanstack` to `miess-01-tanstack` (CF-side cutover); `lebiscuit-tanstack` AE dataset shifts from `deco_metrics_lebiscuit` to `deco_metrics_lebiscuit_tanstack` (orphans old data). |
+| 2026-05-07 | **D6.3 — Revert D6/D6.1/D6.2; deploys move to Cloudflare Workers Builds** | The whole D6 family (centralized GitHub Actions reusable workflows + `decocms-deployer` GitHub App + per-storefront GitHub Environments + central `deploy/wrangler-template.jsonc` + `deco-wrangler` CLI + per-site caller stubs) is being **reverted**. Trigger: GitHub Free orgs do not propagate org-level secrets to private repos, which forced the App private key to live as a per-storefront repo secret in every storefront — that key gives the holder the ability to mint installation tokens that can trigger workflows on `decocms/deco-start`, which in turn have the only Cloudflare credentials in the system. Per-repo distribution + rotation of that key across N customer storefronts didn't scale and concentrated blast radius on one credential. **Replacement (chosen, to be detailed in a follow-up D-record once shipped):** [Cloudflare Workers Builds](https://developers.cloudflare.com/workers/ci-cd/builds/) owns the deploy/preview pipelines per-worker. Verified empirically on `baggagio-tanstack` 2026-05-07: a malicious `wrangler.jsonc` `name` field pointing at a different worker (`americanas-tanstack`) is **ignored** by CF Builds — the deploy lands on the connected worker (`baggagio-tanstack`), CF surfaces a warning banner in the dashboard, and CF auto-opens a PR to fix the config (deco-sites/baggagio-tanstack#34). The dashboard repo<->worker connection is the source of truth; the in-repo config is treated as a secondary input. Per-storefront wiring (one CF dashboard click per worker) is acceptable at our scale; revisit when CF's [git-integration enable API](https://github.com/cloudflare/workers-sdk/issues/12058) lands. The `deco-build` CLI (regenerates `wrangler.jsonc` bindings from a central template) and runtime-secrets management remain to be designed in a separate PR. |
 
 The full text of the constitutional rule (loaded into every agent
 session for this repo) lives at
@@ -1677,15 +1679,14 @@ props. One broken section never takes the page down.
   `regen-blocks.yml` and its `wrangler.jsonc` lacked `account_id`,
   lebiscuit's preview workflow swallowed `wrangler` exit codes, and
   casaevideo's `loadtest:tail` referenced a worker name that didn't
-  match its `wrangler.jsonc`. **Resolved 2026-05-07 via D6:** all
-  workflows + wrangler config are centralized in
-  [`deco-start/.github/workflows/`](./.github/workflows/) and
-  [`deco-start/deploy/`](./deploy/). New-site onboarding is now: open a
-  PR adding `deploy/sites/<repo>.jsonc` to deco-start, then drop the
-  ~5-line caller workflows into the new site's repo. No `wrangler.jsonc`
-  is committed to the site repo — `deco-wrangler gen`
-  (a `bin` shipped from `@decocms/start`) materializes it from the
-  central registry on demand for local dev and CI alike.
+  match its `wrangler.jsonc`. **Status 2026-05-07: D6 → D6.1 → D6.2
+  reverted via D6.3** in favour of Cloudflare Workers Builds owning
+  the deploy/preview pipelines per-worker. The replacement is being
+  designed in a follow-up; until it ships, the existing per-site
+  inline `deploy.yml` workflows in each storefront remain the
+  operational deploy path (i.e. the original drift problem comes back
+  on the surface for now, but with full single-credential trust
+  isolation per storefront — no shared credentials).
 
 #### Counter-evidence the user-rule asks for
 

package/package.json

@@ -1,14 +1,13 @@
 {
   "name": "@decocms/start",
-  "version": "2.30.1",
+  "version": "4.0.0",
   "type": "module",
   "description": "Deco framework for TanStack Start - CMS bridge, admin protocol, hooks, schema generation",
   "main": "./src/index.ts",
   "bin": {
     "deco-migrate": "./scripts/migrate.ts",
     "deco-post-cleanup": "./scripts/migrate-post-cleanup.ts",
-    "deco-htmx-analyze": "./scripts/htmx-analyze.ts",
-    "deco-wrangler": "./scripts/deploy/wrangler-wrapper.mjs"
+    "deco-htmx-analyze": "./scripts/htmx-analyze.ts"
   },
   "exports": {
     ".": "./src/index.ts",

package/scripts/migrate/phase-scaffold.ts

@@ -5,7 +5,6 @@ import { log, logPhase } from "./types";
 import { generatePackageJson } from "./templates/package-json";
 import { generateTsconfig } from "./templates/tsconfig";
 import { generateViteConfig } from "./templates/vite-config";
-import { generateGithubWorkflows } from "./templates/github-workflows";
 import { generateKnipConfig } from "./templates/knip-config";
 import { generateRoutes } from "./templates/routes";
 import { generateSetup } from "./templates/setup";
@@ -50,20 +49,21 @@ function writeMultiFile(ctx: MigrationContext, files: Record<string, string>) {
 export function scaffold(ctx: MigrationContext): void {
   logPhase("Scaffold");
 
-  // Root config files. wrangler.jsonc is INTENTIONALLY not generated --
-  // per D6, the canonical wrangler config lives in decocms/deco-start under
-  // deploy/wrangler-template.jsonc and per-site overrides under
-  // deploy/sites/<repo>.jsonc; the file is materialized locally by
-  // `deco-wrangler gen` and gitignored.
+  // Root config files. wrangler.jsonc is intentionally NOT generated by
+  // the migration script -- it's per-site, lives in the site repo, and
+  // is wired by hand on first deploy (D6.3 interim state until the
+  // Cloudflare Workers Builds onboarding lands).
   writeFile(ctx, "package.json", generatePackageJson(ctx));
   writeFile(ctx, "tsconfig.json", generateTsconfig());
   writeFile(ctx, "vite.config.ts", generateViteConfig(ctx));
   writeFile(ctx, "knip.config.ts", generateKnipConfig());
   writeFile(ctx, ".gitignore", generateGitignore());
 
-  // Caller workflow stubs that delegate to decocms/deco-start's reusable
-  // workflows. The customer repo holds no deploy logic of its own.
-  writeMultiFile(ctx, generateGithubWorkflows());
+  // Deploy / preview pipelines are owned by Cloudflare Workers Builds
+  // configured per-worker in the CF dashboard (D6.3). The migration
+  // does NOT scaffold deploy/preview/sync-secrets workflows in the site
+  // repo; the operator wires the repo<->worker connection in the CF
+  // dashboard once after the first push.
   writeFile(ctx, ".prettierrc", JSON.stringify({
     semi: true,
     singleQuote: false,
@@ -216,9 +216,6 @@ dist/
 # Cloudflare Workers
 .wrangler/
 .dev.vars
-# Generated by \`deco-wrangler\` from @decocms/start's central registry.
-# Source of truth lives in decocms/deco-start under deploy/sites/<repo>.jsonc.
-wrangler.jsonc
 
 # TanStack Router (auto-generated)
 src/routeTree.gen.ts

package/scripts/migrate/phase-verify.ts

@@ -13,12 +13,10 @@ const REQUIRED_FILES = [
   "package.json",
   "tsconfig.json",
   "vite.config.ts",
-  // wrangler.jsonc is INTENTIONALLY absent -- D6: it lives in decocms/deco-start
-  // under deploy/sites/<repo>.jsonc and is generated locally by `deco-wrangler gen`.
-  ".github/workflows/deploy.yml",
-  ".github/workflows/preview.yml",
+  // Deploy / preview / sync-secrets pipelines are owned by Cloudflare
+  // Workers Builds (D6.3) -- configured in the CF dashboard, not via
+  // GitHub workflow files in the site repo.
   ".github/workflows/regen-blocks.yml",
-  ".github/workflows/sync-secrets.yml",
   "knip.config.ts",
   ".prettierrc",
   "src/server.ts",

package/scripts/migrate/templates/package-json.ts

@@ -109,15 +109,12 @@ export function generatePackageJson(ctx: MigrationContext): string {
       build:
         "npm run generate:blocks && npm run generate:sections && npm run generate:loaders && npm run generate:schema && npm run generate:invoke && tsr generate && vite build",
       preview: "vite preview",
-      // wrangler.jsonc is generated by `deco-wrangler gen` from the central
-      // registry in @decocms/start (D6). Predev/prebuild ensure it is up to
-      // date before vite runs the @cloudflare/vite-plugin which reads it.
-      "gen:wrangler": "deco-wrangler gen",
-      predev: "deco-wrangler gen",
-      prebuild: "deco-wrangler gen",
-      deploy:
-        "echo 'Production deploys are managed by .github/workflows/deploy.yml on push to main. For an emergency manual deploy run: npx deco-wrangler deploy'; exit 1",
-      types: "deco-wrangler types",
+      // Deploy is owned by Cloudflare Workers Builds (D6.3); the
+      // repo<->worker connection is configured per-worker in the CF
+      // dashboard. Local devs use plain `wrangler` against the
+      // committed wrangler.jsonc.
+      deploy: "wrangler deploy",
+      types: "wrangler types",
       typecheck: "tsc --noEmit",
       format: 'prettier --write "src/**/*.{ts,tsx}"',
       "format:check": 'prettier --check "src/**/*.{ts,tsx}"',

package/.github/workflows/deploy.yml

@@ -1,122 +0,0 @@
-name: deploy (central)
-
-# Reusable workflow that drives `wrangler deploy` for any storefront repo
-# registered under `deploy/sites/<repo-name>.jsonc`.
-#
-# Site identity (worker name, KV bindings, routes, ...) is derived ONLY from
-# `${{ github.repository }}` and the registry checked in to deco-start. The
-# caller cannot pass an `inputs:` block to override the worker name -- this is
-# the trust boundary that prevents one site's commits from deploying on top of
-# another site's worker.
-#
-# Caller usage (in customer repo, `.github/workflows/deploy.yml`):
-#
-#   on:
-#     push:
-#       branches: [main]
-#   permissions:
-#     contents: write
-#   jobs:
-#     deploy:
-#       uses: decocms/deco-start/.github/workflows/deploy.yml@v2
-#       secrets: inherit
-#
-# `secrets: inherit` is intentionally tolerated but UNUSED by the deploy job:
-# `CLOUDFLARE_API_TOKEN` / `CLOUDFLARE_ACCOUNT_ID` resolve from the
-# `production` environment in this repo (via `environment:` below), NOT from
-# the caller. That keeps the Cloudflare credential off every storefront repo
-# entirely. The same env binding is repeated in `preview.yml` and
-# `sync-secrets.yml`.
-
-on:
-  workflow_call: {}
-
-permissions:
-  contents: write
-
-concurrency:
-  group: deploy-${{ github.repository }}
-  cancel-in-progress: false
-
-jobs:
-  deploy:
-    runs-on: ubuntu-latest
-    # Resolves `secrets.CLOUDFLARE_*` against the `production` environment in
-    # decocms/deco-start (NOT against the caller's repo secrets). Setup:
-    # decocms/deco-start > Settings > Environments > production >
-    # CLOUDFLARE_API_TOKEN + CLOUDFLARE_ACCOUNT_ID.
-    environment: production
-    steps:
-      - name: Checkout caller repo
-        uses: actions/checkout@v4
-
-      - name: Resolve deco-start ref + site identity
-        id: meta
-        run: |
-          # github.workflow_ref looks like
-          #   decocms/deco-start/.github/workflows/deploy.yml@refs/tags/v1
-          # or
-          #   decocms/deco-start/.github/workflows/deploy.yml@refs/heads/main
-          WF_REF="${{ github.workflow_ref }}"
-          REF="${WF_REF##*@}"
-          REF="${REF#refs/tags/}"
-          REF="${REF#refs/heads/}"
-          echo "deco_start_ref=$REF" >> "$GITHUB_OUTPUT"
-          echo "site_name=${GITHUB_REPOSITORY#*/}" >> "$GITHUB_OUTPUT"
-
-      - name: Checkout deco-start registry at the same ref
-        uses: actions/checkout@v4
-        with:
-          repository: decocms/deco-start
-          ref: ${{ steps.meta.outputs.deco_start_ref }}
-          path: .deco-start
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 22
-
-      - name: Generate lockfile if missing
-        if: hashFiles('package-lock.json') == ''
-        run: npm install --package-lock-only
-
-      - name: Restore npm cache
-        uses: actions/cache@v4
-        with:
-          path: ~/.npm
-          key: npm-${{ runner.os }}-${{ hashFiles('package-lock.json') }}
-          restore-keys: npm-${{ runner.os }}-
-
-      - name: Sync lockfile and install
-        run: |
-          npm install --package-lock-only
-          if ! git diff --quiet package-lock.json 2>/dev/null; then
-            git config user.name "github-actions[bot]"
-            git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
-            git add package-lock.json
-            git commit -m "chore: sync package-lock.json"
-            git push || echo "Lockfile push failed (remote ahead); proceeding with deploy"
-          fi
-          npm ci
-
-      - name: Build
-        run: npm run build
-
-      - name: Resolve site manifest
-        id: site
-        run: node .deco-start/scripts/deploy/resolve-site.mjs
-        env:
-          DECO_START_PATH: .deco-start
-          SITE_NAME: ${{ steps.meta.outputs.site_name }}
-
-      - name: Generate wrangler.jsonc
-        run: node .deco-start/scripts/deploy/build-wrangler-config.mjs
-        env:
-          DECO_START_PATH: .deco-start
-          SITE_NAME: ${{ steps.meta.outputs.site_name }}
-          OUTPUT_PATH: ./wrangler.jsonc
-
-      - name: Deploy to Cloudflare Workers
-        run: npx wrangler deploy --var BUILD_HASH:$(git rev-parse --short HEAD)
-        env:
-          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
-          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}