[HalfSweet]

Every deployment of the store was made by hand with wrangler, and main ran ahead of what was live (nine days, once, with a removed route still being served). This makes a merge the release.

What the workflow does

.github/workflows/store.yml, on a change to store/, lib/ (the Worker reads lib/mock.ts), the lockfile or the workflow itself:

• On a pull request: type-checks the website and runs the store's tests. No deploy, and no secrets are used.
• On main: the same checks, then wrangler d1 migrations apply --remote, then wrangler deploy, which builds the website first. One deploy at a time, in the order the merges came.
• By hand (workflow_dispatch): deploys main again.

It does not need the pocketjs submodule or Rust, so it does not run the whole bun run check; that stays a local step. The two actions are pinned to the commits their release tags name (actions/checkout v7.0.1, oven-sh/setup-bun v2.2.0).

What was decided

• Migrations run automatically, before the Worker, with no one asked. Nothing sorts the ones that only add from the ones that take away. docs/applets.md says how to write one for that order.
• A deploy that goes wrong is put right by hand. The same section has the commands: wrangler rollback, and D1's time travel for the database.

Already done, outside this pull request

• main is protected: changes come through pull requests only, admins included; no approval is required, force pushes and deletion are off, and no status check is required (a check that only runs for some paths would block every pull request that does not touch them).
• The secret CLOUDFLARE_ACCOUNT_ID is set.

Needed before this is merged

The secret CLOUDFLARE_API_TOKEN does not exist yet. It has to be made in the Cloudflare dashboard (Workers Scripts, Workers Routes and D1, edit, on the account that holds omarchy-pocket-store) and stored with gh secret set CLOUDFLARE_API_TOKEN. Without it the checks pass and the deploy step fails; nothing is deployed and nothing is harmed.

What merging does

Merging this touches the workflow's own path, so it starts a deploy of main: with the token in place that puts #18 (the Chinese site) live. The live database has no migration waiting.

Verified

• In a clean copy of main with no submodule and no node_modules: bun install --frozen-lockfile, bun run typecheck:site and bun test ./store/test pass; wrangler d1 migrations list --remote finds nothing to apply; wrangler deploy --dry-run builds and bundles with the workflow's own command line.
• The check job runs on this pull request.
• Not verified: the deploy job. It cannot run before the merge, and the token it needs does not exist yet. The protection was read back from GitHub, not tested by trying to push to main.