@decocms/start 3.0.0 → 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
@@ -59,7 +59,7 @@ 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). There is no
-per-site override file (D6.2 Pure C); if a single site truly needs a different
+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.
 
@@ -141,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
@@ -212,137 +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.2)
-
-**Severity**: HIGH — site repos must NOT commit `wrangler.jsonc`, must NOT hold
-Cloudflare credentials, and must NOT have per-site deploy logic. Doing so
-reintroduces drift and breaks the trust model.
-
-Per [D6.2](../../../../.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@v3`.
-There is no per-site registry: worker name == storefront repo basename by
-convention. The canonical `wrangler.jsonc` lives at
-`decocms/deco-start/deploy/wrangler-template.jsonc`; the build script
-substitutes `$WORKER_NAME` / `$WORKER_UNDERSCORE` tokens at deploy time and
-writes a generated `wrangler.jsonc` in the runner. Site repos gitignore the
-file.
-
-### What goes in the site repo
-
-Four caller workflow stubs that mint a `decocms-deployer` GitHub App
-installation token and call `gh workflow run` on `decocms/deco-start@v3`:
-
-```yaml
-# .github/workflows/deploy.yml
-name: Deploy
-on:
-  push:
-    branches: [main]
-permissions:
-  contents: read
-jobs:
-  trigger:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/create-github-app-token@v1
-        id: app-token
-        with:
-          app-id: ${{ secrets.DECOCMS_DEPLOYER_APP_ID }}
-          private-key: ${{ secrets.DECOCMS_DEPLOYER_APP_PRIVATE_KEY }}
-          owner: decocms
-          repositories: deco-start
-      - env:
-          GH_TOKEN: ${{ steps.app-token.outputs.token }}
-        run: |
-          gh workflow run deploy.yml \
-            --repo decocms/deco-start \
-            --ref v3 \
-            -f site_owner=${GITHUB_REPOSITORY%%/*} \
-            -f site_name=${GITHUB_REPOSITORY##*/}
-```
+## 46. Deploy / Wrangler Config (interim, D6.3 in flight)
 
-(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.
-
-### App + secrets setup (one-time, per org)
-
-1. Create a `decocms-deployer` GitHub App with permissions
-   `Actions: Write`, `Contents: Read`, `Pull requests: Write` (the last
-   only needed if you want preview URLs commented on PRs),
-   `Metadata: Read`. Install it on `decocms/deco-start` and on each
-   storefront repo (or whole-org install on `deco-sites`).
-2. Store the App ID and private key as `deco-sites` org-level secrets
-   `DECOCMS_DEPLOYER_APP_ID` and `DECOCMS_DEPLOYER_APP_PRIVATE_KEY` so every
-   storefront workflow can mint installation tokens without per-repo setup.
-3. Store `CLOUDFLARE_API_TOKEN` and `CLOUDFLARE_ACCOUNT_ID` as plain repo
-   secrets in `decocms/deco-start` (NOT in any storefront).
-4. For each storefront that has runtime secrets: create a GitHub Environment
-   in `decocms/deco-start` named `<storefront-repo-basename>-secrets`, add
-   the `SECRET_*` values there, and configure protection rules to grant the
-   site team self-service access to that environment only.
-
-### 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"
-}
-```
+**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.
+
+Site repos **do** commit a per-site `wrangler.jsonc` during the interim
+period. The `deco-wrangler` CLI no longer ships from `@decocms/start`.
+
+### What changes when Workers Builds onboarding ships
+
+When the D6.3 replacement lands, expect:
+
+- 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 template (worker name inferred from git
-remote / package.json), then either exits (`gen` mode) or execs the real
-`wrangler` with that config in cwd.
-
-### Trust model
-
-- **Authorization gate**: the deploy can only start if the
-  `decocms-deployer` App is installed on the target storefront repo. The
-  central workflow's App-token mint step fails with a clear error otherwise.
-- **Worker naming is convention-based and not customer-controlled.** A
-  customer with push access to their own storefront cannot rename the worker
-  their deploy lands on (the central workflow uses `inputs.site_name` as the
-  worker name; modifying their stub to pass a different `site_name` would
-  also require the App to be installed on that other repo).
-- **Cloudflare credentials never leave `decocms/deco-start`.** The central
-  workflow runs in deco-start's context, so the env-var resolves natively
-  from repo secrets.
-- **Force-rollback is impossible for production.** The central deploy
-  workflow ignores any caller-supplied sha and always resolves the
-  storefront's current default-branch HEAD itself.
-- **Per-site runtime secrets** (`SECRET_*`) live in deco-start environments,
-  not storefront repos. The storefront caller stub for `sync-secrets.yml`
-  triggers a workflow that binds to the matching env and runs
-  `wrangler secret put`. The storefront repo holds zero secrets beyond the
-  `decocms-deployer` App credentials.
-
-### 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.
-- **Adding `CLOUDFLARE_*` to a storefront repo's secrets.** They never
-  belong there. The central workflow runs in deco-start's context.
-- **Adding `SECRET_*` to a storefront repo's secrets.** They live in the
-  matching `<site_name>-secrets` environment in deco-start.
-- **Hard-coding `account_id` in a site's wrangler config.** It comes from
-  `CLOUDFLARE_ACCOUNT_ID` (in CI; `wrangler login` locally) — keeping
-  it out of JSON is the one-way protection against accidentally deploying
-  to the wrong account.
-- **Trying to override the worker name** for one site. There is no
-  per-site override mechanism in D6.2. If the worker MUST be named
-  differently from the repo, the right answer is either to rename the
-  repo to match (cleanest) or to do a CF-side migration (deploy a new
-  worker with the repo-name and re-attach routes). This trade-off was
-  taken intentionally in exchange for the registry-free architecture.
+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,51 +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.2 — App-mediated dispatch + no per-site registry (signed off 2026-05-07; supersedes D6 + D6.1)
-All storefronts deploy via reusable workflows under
-`decocms/deco-start/.github/workflows/{deploy,preview,sync-secrets,regen-blocks}.yml@v3`.
-Storefront caller stubs mint a short-lived **`decocms-deployer` GitHub App**
-installation token (App ID + private key live as `deco-sites` org-level
-secrets) and call `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` and
-`CLOUDFLARE_ACCOUNT_ID` are ordinary repo secrets in `decocms/deco-start`
-and never leave it.
-
-There is **no per-site registry under `deploy/sites/`**. Worker name == storefront
-repo basename by convention. Per-worker derived fields use `$WORKER_NAME` /
-`$WORKER_UNDERSCORE` substitution tokens in
-[`deploy/wrangler-template.jsonc`](../../deploy/wrangler-template.jsonc).
-The deploy authorization gate is the App being installed on the storefront
-repo — if it isn't, the App-token mint inside the central workflow fails and
-the deploy never starts. **Customer repos do not commit `wrangler.jsonc`** —
-it is generated locally by `deco-wrangler gen` (a `bin` shipped from
-`@decocms/start`) and gitignored.
-
-Production deploys are **force-rollback proof**: the central workflow ignores
-any caller-supplied `site_sha` and resolves the storefront's current default
-branch HEAD itself. The worst a compromised storefront can do across tenants
-is trigger a no-op redeploy of another storefront's current main.
-
-`SECRET_*` runtime secrets live in **`decocms/deco-start`** as well, in
-per-storefront GitHub Environments named `<site_name>-secrets`. `sync-secrets.yml`
-binds to the matching environment and runs `wrangler secret put`. Site teams
-get edit/approve permission on their own environment via Environment
-protection rules. **The storefront repo holds zero secrets** beyond the
-App credentials (which only grant the ability to trigger workflows on
-`decocms/deco-start`).
-
-`deploy/`, `scripts/deploy/`, and the central workflow files are
-CODEOWNERS-protected.
-
-**Agent behavior**: when adding or migrating a site, do **not** generate a
-per-site `wrangler.jsonc`, do **not** generate a `deploy/sites/<repo>.jsonc`
-file (that whole directory was removed in D6.2), and do **not** add
-`CLOUDFLARE_*` or `SECRET_*` to a storefront repo's secrets. The site repo
-gets four ~15-line caller stubs that mint a `decocms-deployer` App token and
-fire `workflow_dispatch` at `decocms/deco-start@v3`; the App ID + private key
-live as `deco-sites` org-level secrets `DECOCMS_DEPLOYER_APP_ID` and
-`DECOCMS_DEPLOYER_APP_PRIVATE_KEY`.
+### 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
 
@@ -155,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,14 +1,6 @@
 # CODEOWNERS for decocms/deco-start
 #
-# `deploy/wrangler-template.jsonc` is the canonical wrangler config every
-# storefront inherits. A bad PR here can change every site's runtime config in
-# one shot. Only the platform team approves changes.
-#
-# The central reusable workflows under `.github/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

@@ -120,6 +120,7 @@ this plan.
 | 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*. 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
@@ -1678,19 +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 → D6.1 →
-  D6.2:** all workflows + wrangler config are centralized in
-  [`deco-start/.github/workflows/`](./.github/workflows/) and
-  [`deco-start/deploy/`](./deploy/), and storefront caller stubs use
-  a `decocms-deployer` GitHub App to trigger them via `workflow_dispatch`
-  with no Cloudflare credentials in the storefront repo. New-site
-  onboarding is now: install the `decocms-deployer` App on the new
-  storefront repo, drop the ~15-line caller workflows in, push to main.
-  No `deploy/sites/<repo>.jsonc` PR is needed — worker name is the
-  repo basename by convention. No `wrangler.jsonc` is committed to the
-  site repo — `deco-wrangler gen` (a `bin` shipped from `@decocms/start`)
-  materializes it from the central template 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": "3.0.0",
+  "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.2, the canonical wrangler config lives in decocms/deco-start under
-  // deploy/wrangler-template.jsonc; the file is materialized locally by
-  // `deco-wrangler gen` and gitignored. Worker name = storefront repo basename
-  // by convention; there is no per-site registry.
+  // 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 wrangler template.
-# Worker name is derived from the git remote / package.json by convention.
-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.2: it's generated from
-  // decocms/deco-start's deploy/wrangler-template.jsonc 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}"',