Vibe Coding

General execution rules:
- If a step requires manual work in a third-party dashboard, explain it step by step: where to go, which menu to open, what value to create or copy, which permission or type to choose, which file or config field to write it to, and which verification command to run next. Do not only say "manual setup required".
- Clearly separate public config from secrets: public values go into `wrangler.jsonc`, `eas.json`, or frontend env; secrets only go into `.dev.vars`, `.env.production`, or the corresponding CLI secret command.
- Temporarily unused features should be commented out or kept disabled, not deleted; only remove copy, page sections, or sample data when this prompt explicitly asks for that cleanup.

Please help me go live as fast as possible with a minimal setup: Google login only, Stripe payments only, R2 storage only. Skip everything non-essential.

Goals:
- Authentication: Google OAuth only. Disable email/password and GitHub.
- Payments: Stripe only. No Creem or other providers.
- Storage: Cloudflare R2 only.
- Run everything locally first, then deploy Server and Web in one pass.

Please follow these steps:

### Step 1: Cloudflare Configuration (using Codex @Chrome plugin + Wrangler CLI)
Reference: https://developers.cloudflare.com/workers/wrangler/

Prefer Codex's @Chrome plugin to open the Cloudflare Dashboard and use my currently signed-in Chrome session to get or create Cloudflare configuration. Unless Chrome is not signed in, MFA is required, account permissions are insufficient, or the Cloudflare page cannot show the required information, do not ask me to manually copy `CLOUDFLARE_ACCOUNT_ID` or `CLOUDFLARE_API_TOKEN`.

`wrangler.jsonc` required replacement rules:
- Do not keep template project names, domains, D1 values, R2 values, Google Client IDs, or Analytics IDs. The fields below must be replaced with real values for the current project. If the Chrome plugin, Dashboard, or CLI creation fails, write clear placeholders first and mark them as blocking production deployment in the deliverables.
- Confirm and update these fields in `apps/server/wrangler.jsonc`:
  - `name`
  - `d1_databases[0].database_name`
  - `d1_databases[0].database_id`
  - `vars.WEBSITE_URL`
  - `vars.SERVER_URL`
  - `vars.GOOGLE_CLIENT_ID`
  - `r2_buckets[0].bucket_name`
- Confirm and update these fields in `apps/web/wrangler.jsonc`:
  - `name`
  - `services[0].service`
  - `vars.VITE_SERVER_URL`
  - `vars.VITE_APP_URL`
  - `vars.VITE_GA_MEASUREMENT_ID`
  - `vars.VITE_OPENPANEL_CLIENT_ID`
- Recommended placeholder format: `<YOUR_SERVER_WORKER_NAME>`, `<YOUR_WEB_WORKER_NAME>`, `<YOUR_D1_DATABASE_NAME>`, `<YOUR_D1_DATABASE_ID>`, `<YOUR_R2_BUCKET_NAME>`, `https://api.<ROOT_DOMAIN>`, `https://<ROOT_DOMAIN>`, `<YOUR_GOOGLE_CLIENT_ID>`, `<YOUR_GA_MEASUREMENT_ID>`, `<YOUR_OPENPANEL_CLIENT_ID>`. Do not deploy to production while any placeholder remains.

1. Check if Wrangler CLI is available: `pnpm wrangler --version`.
2. Check login status: `pnpm wrangler whoami`. If not logged in, run `pnpm wrangler login` to authenticate via browser.
3. Create D1 database: run `pnpm wrangler d1 create <database-name>`. Copy the `database_id` from the output and write it to:
   - `d1_databases[0].database_id` and `d1_databases[0].database_name` in `apps/server/wrangler.jsonc`
   - `CLOUDFLARE_D1_DATABASE_ID` in `apps/server/.dev.vars`
   - `CLOUDFLARE_D1_DATABASE_ID` in `apps/server/.env.production`
   - If D1 creation or verification fails, set `d1_databases[0].database_name` to `<YOUR_D1_DATABASE_NAME>` and `d1_databases[0].database_id` to `<YOUR_D1_DATABASE_ID>` in `apps/server/wrangler.jsonc`. Do not keep old template values, and explain the failure and follow-up creation command in the deliverables.
4. Create R2 storage bucket: run `pnpm wrangler r2 bucket create <bucket-name>`. Write the bucket name to `r2_buckets[0].bucket_name` in `apps/server/wrangler.jsonc`; keep the `binding` as `STORAGE`.
   - If R2 creation or verification fails, set `r2_buckets[0].bucket_name` to `<YOUR_R2_BUCKET_NAME>` in `apps/server/wrangler.jsonc`. Do not keep old template values, and explain the failure and follow-up creation command in the deliverables.
5. Configure the R2 public access URL:
   - **Local development**: Enable Public Access (r2.dev) in Cloudflare R2 bucket Settings to get `https://pub-xxxx.r2.dev`. Write it to `R2_PUBLIC_URL` in `apps/server/.dev.vars`. Note: r2.dev is rate-limited and intended for development only.
   - **Production**: In R2 bucket Settings → Custom Domains, connect a custom domain (e.g., `storage.yourdomain.com` — the domain must already be in your Cloudflare account). Write it to `R2_PUBLIC_URL` in `apps/server/.env.production`. Custom domains have no rate limits and support WAF and caching.
6. If env files are missing, create them from examples:
   - `apps/server/.dev.vars`
   - `apps/server/.env.production`
   - `apps/web/.env.development`
   - `apps/web/.env.production`

   Web env files may only contain public config. Do not write secrets there.

   Write to `apps/web/.env.development`:
   - `VITE_SERVER_URL=http://localhost:3001`
   - `VITE_APP_URL=http://localhost:3000`

   Write to `apps/web/.env.production`:
   - `VITE_SERVER_URL=https://api.<ROOT_DOMAIN>`
   - `VITE_APP_URL=https://<ROOT_DOMAIN>`

   If the production domain is not confirmed yet, still create `apps/web/.env.production`, keep the `<ROOT_DOMAIN>` placeholder, and tell me in the deliverables that `<ROOT_DOMAIN>` must be replaced with the final domain before production deployment.
7. Set Server Worker name: set `name` in `apps/server/wrangler.jsonc` (e.g., `my-app-server`).
8. Set Web Worker name: set `name` in `apps/web/wrangler.jsonc` (e.g., `my-app-web`).
   - If the project name or target Worker names cannot be confirmed, do not keep old template values. Write `<YOUR_SERVER_WORKER_NAME>` and `<YOUR_WEB_WORKER_NAME>` instead.
9. Configure Service Binding: ensure `services[0].service` in `apps/web/wrangler.jsonc` exactly matches the Server Worker name set in step 7.
   - If the Server Worker name is still unknown, write `<YOUR_SERVER_WORKER_NAME>` to `services[0].service` instead of keeping an old template value.
10. Configure `apps/server/.dev.vars`:
   - `CLOUDFLARE_ACCOUNT_ID` → prefer Codex's @Chrome plugin to get it from the Cloudflare Dashboard overview page
   - `CLOUDFLARE_API_TOKEN` → prefer Codex's @Chrome plugin to create it at https://dash.cloudflare.com/profile/api-tokens with permissions: D1 Edit, Workers R2 Storage Edit, Workers Scripts Edit
   - `CLOUDFLARE_D1_DATABASE_ID` → from step 3
   - `BETTER_AUTH_SECRET` → generate with `openssl rand -base64 32`
11. Configure `apps/server/.env.production`: fill the same Cloudflare variables; generate a separate production value for `BETTER_AUTH_SECRET`.
12. Configure `vars` in `apps/server/wrangler.jsonc`: set `SERVER_URL`, `WEBSITE_URL`, and `GOOGLE_CLIENT_ID` to production values.
13. Configure `vars` in `apps/web/wrangler.jsonc`: set `VITE_SERVER_URL`, `VITE_APP_URL`, `VITE_GA_MEASUREMENT_ID`, and `VITE_OPENPANEL_CLIENT_ID` to production values.
   - If GA or OpenPanel has not been created yet, write `<YOUR_GA_MEASUREMENT_ID>` and `<YOUR_OPENPANEL_CLIENT_ID>` in `apps/web/wrangler.jsonc` instead of keeping old template values. Do not deploy to production while placeholders remain.
14. Configure Web env URLs:
   - In `apps/web/.env.production`, set the same public production URLs:
     - `VITE_SERVER_URL`
     - `VITE_APP_URL`
   - In `apps/web/.env.development`, set local public URLs:
     - `VITE_SERVER_URL=http://localhost:3001`
     - `VITE_APP_URL=http://localhost:3000`
   - If the production domain is not confirmed yet, keep production URLs as `<ROOT_DOMAIN>` placeholders and tell me in the deliverables that `<ROOT_DOMAIN>` must be replaced with the final domain before production deployment.

### Step 2: Google login only
1. Open `apps/server/src/lib/auth.ts`. In `socialProviders`, keep only `google` and comment out `github`; do not delete the related code.
2. If `emailAndPassword` exists, leave it commented out. Do not enable it.
3. Variables needed:
   - `GOOGLE_CLIENT_ID` → write to `vars` in `apps/server/wrangler.jsonc` (public)
   - `GOOGLE_CLIENT_SECRET` → write to `apps/server/.dev.vars` (local) and `apps/server/.env.production` (production)
4. If I do not have Google OAuth credentials yet, prefer Codex's @Chrome plugin to open Google Cloud Console and create them with my currently signed-in Google account:
   - Open `https://console.cloud.google.com/apis/credentials`.
   - If I have multiple Google Cloud projects, choose based on the project name, production domain, or ask me to confirm the target project. Do not guess.
   - Go to Google Cloud Console → APIs & Services → Credentials → Create OAuth 2.0 Client ID (Web application).
   - Authorized JavaScript origins: my Web URL.
   - Authorized redirect URIs: `{SERVER_URL}/api/auth/callback/google`.
   - For local dev, also add `http://localhost:3001/api/auth/callback/google`.
   - If Chrome is not signed in, MFA is required, permissions are insufficient, the Google Cloud page cannot show the required information, or the Chrome plugin cannot complete creation, set `vars.GOOGLE_CLIENT_ID` in `apps/server/wrangler.jsonc` to `<YOUR_GOOGLE_CLIENT_ID>` instead of keeping an old template value. Pause and let me complete the required operation in Chrome. Do not ask for or record passwords or verification codes.
5. `BETTER_AUTH_SECRET` was already generated in Step 1. Confirm it is filled in `apps/server/.dev.vars`.

### Step 3: Stripe payments only (using Stripe CLI)
Please help me go live as fast as possible with a minimal setup: Google login only, Stripe payments only, Cloudflare R2 storage only. Skip everything non-essential.

Core goals:
- Authentication: Google OAuth only. Disable email/password and GitHub.
- Payments: Stripe only. No Creem, RevenueCat, or other providers for Web payments.
- Storage: Cloudflare R2 only.
- Run everything locally first.
- Deploy Server and Web only after all required production values are confirmed.

Important security rules:
- Never print secrets in the final response.
- Do not commit `.env`, `.dev.vars`, API keys, webhook secrets, OAuth secrets, or production secrets.
- If a required dashboard-only secret or non-public value is missing, do not invent a placeholder. In the deliverables, tell me exactly where to configure or copy it, and which file or config field to write it to later. Public `wrangler.jsonc` config should use placeholders according to the rules below.

`wrangler.jsonc` required replacement rules:
- Do not keep template project names, domains, D1 values, R2 values, Google Client IDs, or Analytics IDs. The fields below must be replaced with real values for the current project. If the Chrome plugin, Dashboard, or CLI creation fails, write clear placeholders first and mark them as blocking production deployment in the deliverables.
- Confirm and update these fields in `apps/server/wrangler.jsonc`:
  - `name`
  - `d1_databases[0].database_name`
  - `d1_databases[0].database_id`
  - `vars.WEBSITE_URL`
  - `vars.SERVER_URL`
  - `vars.GOOGLE_CLIENT_ID`
  - `r2_buckets[0].bucket_name`
- Confirm and update these fields in `apps/web/wrangler.jsonc`:
  - `name`
  - `services[0].service`
  - `vars.VITE_SERVER_URL`
  - `vars.VITE_APP_URL`
  - `vars.VITE_GA_MEASUREMENT_ID`
  - `vars.VITE_OPENPANEL_CLIENT_ID`
- Recommended placeholder format: `<YOUR_SERVER_WORKER_NAME>`, `<YOUR_WEB_WORKER_NAME>`, `<YOUR_D1_DATABASE_NAME>`, `<YOUR_D1_DATABASE_ID>`, `<YOUR_R2_BUCKET_NAME>`, `https://api.<ROOT_DOMAIN>`, `https://<ROOT_DOMAIN>`, `<YOUR_GOOGLE_CLIENT_ID>`, `<YOUR_GA_MEASUREMENT_ID>`, `<YOUR_OPENPANEL_CLIENT_ID>`. Do not deploy to production while any placeholder remains.

Important Stripe rule:
- Never rely on the Stripe CLI default account.
- Stripe CLI does not create new Sandboxes automatically.
- Always confirm the target Stripe Sandbox/account id before creating Products or Prices.
- Always pass `--api-key` explicitly for Stripe CLI commands that create or verify resources.

## Step 1: Cloudflare configuration

Reference: https://developers.cloudflare.com/workers/wrangler/

1. Check Wrangler:
   - Run `pnpm wrangler --version`.

2. Check login:
   - Run `pnpm wrangler whoami`.
   - If not logged in, run `pnpm wrangler login` and let me complete browser authentication.

3. Create D1 database:
   - Run `pnpm wrangler d1 create <database-name>`.
   - Write the returned `database_id` and database name to:
     - `d1_databases[0].database_id` in `apps/server/wrangler.jsonc`
     - `d1_databases[0].database_name` in `apps/server/wrangler.jsonc`
     - `CLOUDFLARE_D1_DATABASE_ID` in `apps/server/.dev.vars`
     - `CLOUDFLARE_D1_DATABASE_ID` in `apps/server/.env.production`
   - If D1 creation or verification fails, set `d1_databases[0].database_name` to `<YOUR_D1_DATABASE_NAME>` and `d1_databases[0].database_id` to `<YOUR_D1_DATABASE_ID>` in `apps/server/wrangler.jsonc`. Do not keep old template values, and explain the failure and follow-up creation command in the deliverables.

4. Create R2 bucket:
   - Run `pnpm wrangler r2 bucket create <bucket-name>`.
   - Write the bucket name to `r2_buckets[0].bucket_name` in `apps/server/wrangler.jsonc`.
   - Keep the R2 binding as `STORAGE`.
   - If R2 creation or verification fails, set `r2_buckets[0].bucket_name` to `<YOUR_R2_BUCKET_NAME>` in `apps/server/wrangler.jsonc`. Do not keep old template values, and explain the failure and follow-up creation command in the deliverables.

5. Configure R2 public URL:
   - Local development:
     - Enable Public Access (`r2.dev`) in Cloudflare R2 bucket Settings.
     - Write the `https://pub-xxxx.r2.dev` URL to `R2_PUBLIC_URL` in `apps/server/.dev.vars`.
   - Production:
     - In R2 bucket Settings → Custom Domains, connect a custom domain such as `storage.yourdomain.com`.
     - The domain must already be in the Cloudflare account.
     - Write the production storage URL to `R2_PUBLIC_URL` in `apps/server/.env.production`.
   - If the domain is not in Cloudflare yet, keep using the `r2.dev` public URL for now. In the deliverables, list the follow-up steps: add the domain to Cloudflare, bind the R2 Custom Domain, update `R2_PUBLIC_URL`, and push production Secrets again.

6. If env files are missing, create them from examples:
   - `apps/server/.dev.vars`
   - `apps/server/.env.production`
   - `apps/web/.env.development`
   - `apps/web/.env.production`

   Web env files may only contain public config. Do not write secrets there.

   Write to `apps/web/.env.development`:
   - `VITE_SERVER_URL=http://localhost:3001`
   - `VITE_APP_URL=http://localhost:3000`

   Write to `apps/web/.env.production`:
   - `VITE_SERVER_URL=https://api.<ROOT_DOMAIN>`
   - `VITE_APP_URL=https://<ROOT_DOMAIN>`

   If the production domain is not confirmed yet, still create `apps/web/.env.production`, keep the `<ROOT_DOMAIN>` placeholder, and tell me in the deliverables that `<ROOT_DOMAIN>` must be replaced with the final domain before production deployment.

7. Set Cloudflare Worker names:
   - Set Server Worker `name` in `apps/server/wrangler.jsonc`, for example `<project-name>-server`.
   - Set Web Worker `name` in `apps/web/wrangler.jsonc`, for example `<project-name>-web`.
   - If the project name or target Worker names cannot be confirmed, do not keep old template values. Write `<YOUR_SERVER_WORKER_NAME>` and `<YOUR_WEB_WORKER_NAME>` instead.

8. Configure Web → Server service binding:
   - Ensure `services[0].service` in `apps/web/wrangler.jsonc` exactly matches the Server Worker name.
   - Keep the service binding name expected by the app.
   - If the Server Worker name is still unknown, write `<YOUR_SERVER_WORKER_NAME>` to `services[0].service` instead of keeping an old template value.

9. Configure Cloudflare env files:
   - `apps/server/.dev.vars`:
     - `CLOUDFLARE_ACCOUNT_ID`
     - `CLOUDFLARE_API_TOKEN`
     - `CLOUDFLARE_D1_DATABASE_ID`
     - `BETTER_AUTH_SECRET`
   - `apps/server/.env.production`:
     - same Cloudflare values
     - a separate production `BETTER_AUTH_SECRET`
   - Generate Better Auth secrets with:
     `openssl rand -base64 32`
   - If an API token is needed, create it in Cloudflare Dashboard with permissions:
     - D1 Edit
     - Workers R2 Storage Edit
     - Workers Scripts Edit
     - Queues Edit if this project uses Queues
   - Do not print the token.

10. Configure production URLs:
   - In `apps/server/wrangler.jsonc` vars:
     - `SERVER_URL`
     - `WEBSITE_URL`
   - In `apps/web/wrangler.jsonc` vars:
     - `VITE_SERVER_URL`
     - `VITE_APP_URL`
     - `VITE_GA_MEASUREMENT_ID`
     - `VITE_OPENPANEL_CLIENT_ID`
   - In `apps/web/.env.production`, set the same public production URLs:
     - `VITE_SERVER_URL`
     - `VITE_APP_URL`
   - In `apps/web/.env.development`, set local public URLs:
     - `VITE_SERVER_URL=http://localhost:3001`
     - `VITE_APP_URL=http://localhost:3000`
   - If the production domain is not confirmed yet, keep production URLs as `<ROOT_DOMAIN>` placeholders and tell me in the deliverables that `<ROOT_DOMAIN>` must be replaced with the final domain before production deployment.
   - If GA or OpenPanel has not been created yet, write `<YOUR_GA_MEASUREMENT_ID>` and `<YOUR_OPENPANEL_CLIENT_ID>` in `apps/web/wrangler.jsonc` instead of keeping old template values. Do not deploy to production while placeholders remain.

## Step 2: Google login only

Reference: project auth docs and Better Auth configuration.

1. Open `apps/server/src/lib/auth.ts`.
2. In `socialProviders`, keep only `google`.
3. Comment out GitHub and keep it disabled; do not delete the related code.
4. Ensure `emailAndPassword` is disabled:
   - If `emailAndPassword` exists, leave it disabled.
   - Do not enable email/password login.
5. Configure Google OAuth variables:
   - `GOOGLE_CLIENT_ID`:
     - write to `vars` in `apps/server/wrangler.jsonc`
   - `GOOGLE_CLIENT_SECRET`:
     - write to `apps/server/.dev.vars`
     - write to `apps/server/.env.production`
6. If Google OAuth credentials do not exist yet, tell me to create them:
   - Google Cloud Console → APIs & Services → Credentials → Create OAuth 2.0 Client ID.
   - Application type: Web application.
   - Authorized JavaScript origins:
     - local Web URL, usually `http://localhost:3000`, `http://localhost:3001`
     - production Web URL
   - Authorized redirect URIs:
     - local: `http://localhost:3001/api/auth/callback/google`
     - production: `{SERVER_URL}/api/auth/callback/google`
   - If Chrome is not signed in, MFA is required, permissions are insufficient, the Google Cloud page cannot show the required information, or the Chrome plugin cannot complete creation, set `vars.GOOGLE_CLIENT_ID` in `apps/server/wrangler.jsonc` to `<YOUR_GOOGLE_CLIENT_ID>` instead of keeping an old template value. Pause and let me complete the required operation in Chrome. Do not ask for or record passwords or verification codes.
7. Verify `BETTER_AUTH_SECRET` is filled in `apps/server/.dev.vars`.
8. Locally verify that clicking Google login redirects to Google and returns to the app.
   - If local shell/Workers runtime cannot reach Google but Chrome can, check proxy settings and run local dev with explicit proxy env vars.

## Step 3: Stripe payments only

References:
- https://docs.stripe.com/stripe-cli
- https://docs.stripe.com/sandboxes
- https://docs.stripe.com/sandboxes/dashboard/manage

Prefer Codex's @Chrome plugin to open the Stripe Dashboard and use my currently signed-in Chrome session for account confirmation, Sandbox selection or creation, API key retrieval, and production webhook configuration. Product / Price creation, local webhook forwarding, and CLI verification should still prefer Stripe CLI, and every Stripe CLI command must pass `--api-key` explicitly.

1. Confirm Web payment provider:
   - Confirm `web.payments.provider` is `stripe` in `packages/app-config/src/app-config.ts`.
   - Disable or comment out Creem, RevenueCat, or other Web payment providers; do not delete the related code.

2. Check Stripe CLI:
   - Run `stripe --version`.
   - If not installed on macOS:
     `brew install stripe/stripe-cli/stripe`

3. Select or create the target Stripe Sandbox:
   - Prefer Codex's @Chrome plugin to open the Stripe Dashboard.
   - In Stripe Dashboard, open the account picker.
   - Click `Switch to sandbox`.
   - Select the existing sandbox for this project, or create a new sandbox named `<project-name>`.
   - Confirm the selected sandbox/account name and account id (`acct_...`) before creating Products or Prices.
   - If manual creation is required, do not invent a workaround. In the deliverables, tell me exactly where to click and what to create.

4. Get the target Sandbox test secret key:
   - Prefer Codex's @Chrome plugin to enter the selected sandbox, then go to Developers → API keys.
   - Copy the test secret key (`sk_test_...`).
   - Write it to `STRIPE_SECRET_KEY` in `apps/server/.dev.vars`.
   - Do not use a key from another sandbox/account.

5. Verify the API key belongs to the intended sandbox:
   - Run:
     `stripe accounts retrieve --api-key "$STRIPE_SECRET_KEY"`
   - Confirm returned account id and display name match the selected sandbox.
   - If they do not match, do not create Stripe resources with that key. In the deliverables, tell me to get the correct key from the target sandbox's Developers → API keys page and write it to `STRIPE_SECRET_KEY` in `apps/server/.dev.vars`.

6. Create Products and Prices with explicit `--api-key`:
   - Create Pro product:
     `stripe products create --name="Pro" --api-key "$STRIPE_SECRET_KEY"`
   - Create Pro monthly price:
     `stripe prices create --product=<prod_id> --currency=usd --unit-amount=1000 --recurring[interval]=month --api-key "$STRIPE_SECRET_KEY"`
   - Create Pro yearly price:
     `stripe prices create --product=<prod_id> --currency=usd --unit-amount=10000 --recurring[interval]=year --api-key "$STRIPE_SECRET_KEY"`
   - Create Lifetime product:
     `stripe products create --name="Lifetime" --api-key "$STRIPE_SECRET_KEY"`
   - Create Lifetime price:
     `stripe prices create --product=<prod_id> --currency=usd --unit-amount=200000 --api-key "$STRIPE_SECRET_KEY"`
   - If the app has credit packs, create their prices in the same target sandbox using explicit `--api-key`.
   - Write each returned `price_...` ID to the corresponding `providerPriceIds.test` in `packages/app-config/src/app-config.ts`.

7. Local webhook:
   - Start webhook forwarding with the same explicit sandbox key:
     `stripe listen --api-key "$STRIPE_SECRET_KEY" --forward-to http://localhost:3001/api/webhooks/stripe`
   - Write the printed `whsec_...` to `STRIPE_WEBHOOK_SECRET` in `apps/server/.dev.vars`.
   - Restart the local server after updating `STRIPE_WEBHOOK_SECRET`.

8. Local Stripe verification:
   - Trigger a test event:
     `stripe trigger checkout.session.completed --api-key "$STRIPE_SECRET_KEY"`
   - Confirm local server receives `POST /api/webhooks/stripe` with HTTP 200.
   - A generic CLI trigger may not contain app-specific user metadata, so a business-level skip log is acceptable if signature verification and delivery succeed.
   - Also verify a real Checkout flow with test card:
     `4242 4242 4242 4242`.

9. Production Stripe setup:
   - Do not create or overwrite production prices unless I explicitly confirm the live account.
   - Prefer Codex's @Chrome plugin to open the Stripe Dashboard and confirm the target live account name and account id.
   - Get the live secret key (`sk_live_...`) from the intended live Stripe account.
   - Write it to `STRIPE_SECRET_KEY` in `apps/server/.env.production`.
   - Create or confirm live Products / Prices in the live account.
   - Write each live `price_...` ID to `providerPriceIds.production`.
   - Prefer Codex's @Chrome plugin to configure a production webhook in Stripe Dashboard:
     `{SERVER_URL}/api/webhooks/stripe`
   - Write the production Signing secret to `STRIPE_WEBHOOK_SECRET` in `apps/server/.env.production`.

## Step 4: Storage only R2

1. Confirm app config storage provider is `r2`.
2. Disable or comment out any non-R2 storage providers; do not delete the related code.
3. Confirm server storage binding is `STORAGE`.
4. Verify locally:
   - Upload through the app if logged in.
   - Or do a minimal Wrangler R2 smoke test:
     - put a temporary object
     - read it back
     - delete it
5. Do not leave smoke-test objects in the bucket.

## Step 5: Database migration

1. Confirm `d1_databases[0].database_id` in `apps/server/wrangler.jsonc` is filled.
2. Run:
   - `pnpm db:generate`
   - `pnpm db:migrate:local`
3. If production deployment is ready, later run:
   - `pnpm db:migrate`

## Step 6: Local verification

Start:

`pnpm dev:web+server`

Verify:
- Web renders locally.
- Server health/root endpoint responds.
- Google OAuth login redirects to Google and returns to the app.
- Stripe test checkout works with test card `4242 4242 4242 4242`.
- Stripe webhook receives events with HTTP 200.
- R2 upload or R2 smoke test works.
- No GitHub login.
- No email/password login.
- No Creem/RevenueCat Web payment routes.

Run verification commands as appropriate:
- `pnpm check-types` for meaningful TS/config changes.
- `pnpm --filter server exec wrangler deploy --dry-run`
- `pnpm --filter web exec wrangler deploy --dry-run`

## Step 7: Deploy in one pass only when production values are complete

Before deploying, confirm:
- `apps/server/.env.production` has:
  - `CLOUDFLARE_ACCOUNT_ID`
  - `CLOUDFLARE_API_TOKEN`
  - `CLOUDFLARE_D1_DATABASE_ID`
  - `BETTER_AUTH_SECRET`
  - `GOOGLE_CLIENT_SECRET`
  - `R2_PUBLIC_URL`
  - `STRIPE_SECRET_KEY`
  - `STRIPE_WEBHOOK_SECRET`
  - any app-specific required production secrets
- `packages/app-config/src/app-config.ts` has real `providerPriceIds.production`, not placeholders.
- `apps/server/wrangler.jsonc` has current project values and no placeholders:
  - `name`
  - `d1_databases[0].database_name`
  - `d1_databases[0].database_id`
  - `r2_buckets[0].bucket_name`
- `apps/server/wrangler.jsonc` production vars are correct:
  - `SERVER_URL`
  - `WEBSITE_URL`
  - `GOOGLE_CLIENT_ID`
- `apps/web/wrangler.jsonc` has current project values and no placeholders:
  - `name`
  - `services[0].service`
- `apps/web/wrangler.jsonc` production vars are correct:
  - `VITE_SERVER_URL`
  - `VITE_APP_URL`
  - `VITE_GA_MEASUREMENT_ID`
  - `VITE_OPENPANEL_CLIENT_ID`
- `apps/web/wrangler.jsonc` service binding points to the Server Worker.
- `services[0].service` in `apps/web/wrangler.jsonc` exactly matches `name` in `apps/server/wrangler.jsonc`.
- Google OAuth production redirect URI is configured:
  `{SERVER_URL}/api/auth/callback/google`
- Stripe production webhook is configured:
  `{SERVER_URL}/api/webhooks/stripe`
- R2 production custom domain is configured and written to `R2_PUBLIC_URL`.

Then deploy:
1. `pnpm -F server secrets:bulk:production`
2. `pnpm db:migrate`
3. `pnpm deploy:server`
4. `pnpm deploy:web`

After deploy:
- Verify Web production URL.
- Verify Server production URL.
- Verify Google login in production.
- Verify Stripe live/test as appropriate.
- Verify R2 public file URL.

## Deliverables

Return a concise deployment report with:

- Cloudflare Worker names:
  - Server
  - Web
- D1 database:
  - name
  - database_id
- R2:
  - bucket name
  - local `R2_PUBLIC_URL`
  - production `R2_PUBLIC_URL`
- Service Binding:
  - Web binding name
  - target Server Worker name
- Login methods enabled:
  - Google only
- Stripe:
  - target sandbox account id/name
  - test Price ID to plan mapping
  - production Price ID to plan mapping
- Env/vars files written:
  - list only file names and variable names, not secret values
- Production URL table:
  - Web URL
  - Server URL
  - Storage URL
- If there are placeholders or Chrome plugin / Dashboard / CLI creation failed:
  - list the exact fields
  - explain the failure reason
  - provide the Dashboard path or command needed to fill them later
- Verification commands run and results
- Manual dashboard steps still required from me

General execution rules:
- If a step requires manual work in a third-party dashboard, explain it step by step: where to go, which menu to open, what value to create or copy, which permission or type to choose, which file or config field to write it to, and which verification command to run next. Do not only say "manual setup required".
- Clearly separate public config from secrets: public values go into `wrangler.jsonc`, `eas.json`, or frontend env; secrets only go into `.dev.vars`, `.env.production`, or the corresponding CLI secret command.
- Temporarily unused features should be commented out or kept disabled, not deleted; only remove copy, page sections, or sample data when this prompt explicitly asks for that cleanup.

Please help me start the Web and Server local development environment in the current project.

Goals:
- Start the Web client and Server using the existing project scripts.
- The Web client depends on the Server API URL and Web environment variables.
- Both the Web and Server may require mandatory environment variables. Please check them first and configure as much as possible.

Please follow these steps:
1. Read the root `package.json`, `apps/web/package.json`, `apps/server/package.json`, `apps/web/.env*.example`, `apps/server/.env*.example`, `apps/web/wrangler.jsonc`, and `apps/server/wrangler.jsonc` to confirm the actual commands and required configuration.
2. If local env files are missing, create development env files from the examples. Only fill values that can be safely inferred from examples or local defaults. Do not invent real secrets.
3. Check the local Web URL and Server URL. Prefer the ports defined by project scripts or docs.
4. Confirm that `VITE_SERVER_URL`, `VITE_APP_URL`, Server-side `SERVER_URL`, and `WEBSITE_URL` match each other for local development.
5. Start the Server. Prefer the local default port defined by project scripts.
6. After the Server is healthy, start the Web client and explain what I should see in the terminal or browser.

Reference docs:
https://www.easystarter.dev/en/docs/web/getting-started

Deliverables:
- The actual startup commands used.
- Env files created or modified.
- Variables I still need to fill manually.
- Web URL, Server URL, and how to verify that Web is connected to the Server.

General execution rules:
- If a step requires manual work in a third-party dashboard, explain it step by step: where to go, which menu to open, what value to create or copy, which permission or type to choose, which file or config field to write it to, and which verification command to run next. Do not only say "manual setup required".
- Clearly separate public config from secrets: public values go into `wrangler.jsonc`, `eas.json`, or frontend env; secrets only go into `.dev.vars`, `.env.production`, or the corresponding CLI secret command.
- Temporarily unused features should be commented out or kept disabled, not deleted; only remove copy, page sections, or sample data when this prompt explicitly asks for that cleanup.

Please help me configure the Cloudflare integration.

Goals:
- Prepare the base credentials needed later for Cloudflare Workers, D1, and R2.
- Write safely configurable values into project files.
- For sensitive information that cannot be retrieved automatically, clearly tell me where to get it and where to write it.

Please follow these steps:
1. Read `apps/server/wrangler.jsonc`, `apps/web/wrangler.jsonc`, `apps/server/.dev.vars.example`, `apps/server/.env.production.example`, and `apps/server/drizzle.config.ts` to confirm Cloudflare-related variables and configuration locations.
2. Check whether Wrangler is installed and logged in, for example with `pnpm wrangler whoami` or an existing project script.
3. Check and prepare these variables:
   - `CLOUDFLARE_ACCOUNT_ID`
   - `CLOUDFLARE_API_TOKEN`
4. If local env files are missing, create them from examples:
   - `apps/server/.dev.vars`
   - `apps/server/.env.production`
5. Do not invent a Cloudflare token. Tell me:
   - Where to copy `CLOUDFLARE_ACCOUNT_ID` in Cloudflare Dashboard.
   - Which permissions `CLOUDFLARE_API_TOKEN` should have: D1 Edit, Workers R2 Storage Edit, Workers Scripts Edit.
   - Which files these values should be written to.
6. If I already provided values, write them to the correct files and avoid putting secrets into files that will be committed to Git.

Reference docs:
https://www.easystarter.dev/en/docs/web/integrations/cloudflare

Deliverables:
- Cloudflare login status.
- Files created or modified.
- Variables still missing.
- Whether the next step should be database, storage, or deployment.

General execution rules:
- If a step requires manual work in a third-party dashboard, explain it step by step: where to go, which menu to open, what value to create or copy, which permission or type to choose, which file or config field to write it to, and which verification command to run next. Do not only say "manual setup required".
- Clearly separate public config from secrets: public values go into `wrangler.jsonc`, `eas.json`, or frontend env; secrets only go into `.dev.vars`, `.env.production`, or the corresponding CLI secret command.
- Temporarily unused features should be commented out or kept disabled, not deleted; only remove copy, page sections, or sample data when this prompt explicitly asks for that cleanup.

Please help me configure the Cloudflare D1 database and run the local database development flow.

Prefer Codex's @Chrome plugin to open the Cloudflare Dashboard and use my currently signed-in Chrome session to get or create Cloudflare configuration. Unless Chrome is not signed in, MFA is required, account permissions are insufficient, or the Cloudflare page cannot show the required information, do not ask me to manually copy `CLOUDFLARE_ACCOUNT_ID` or `CLOUDFLARE_API_TOKEN`.

Goals:
- Create or connect a D1 database.
- Sync `apps/server/wrangler.jsonc`, `apps/server/.dev.vars`, and `apps/server/.env.production`.
- Generate and run local database migrations.

Please follow these steps:
1. Read `apps/server/wrangler.jsonc`, `apps/server/src/db/schema`, `apps/server/drizzle.config.ts`, and the root `package.json` to confirm database configuration and scripts.
2. Check whether these Cloudflare variables are configured:
   - `CLOUDFLARE_ACCOUNT_ID`
   - `CLOUDFLARE_API_TOKEN`
   - `CLOUDFLARE_D1_DATABASE_ID`
3. If there is no D1 database yet, prefer the project command, for example `pnpm wrangler d1 create <database-name>`; if it cannot be executed, prefer Codex's @Chrome plugin to open the Cloudflare Dashboard and create it there.
4. After getting `database_id`, write it to:
   - `apps/server/.dev.vars`
   - `apps/server/.env.production`
   - `d1_databases[0].database_id` in `apps/server/wrangler.jsonc`
5. Confirm whether `d1_databases[0].binding` matches the binding used by the code, usually `DB`.
6. Run local development commands:
   - `pnpm db:generate`
   - `pnpm db:migrate:local`
7. If I need to inspect data, start the local Studio, for example `pnpm db:studio:local`.

Reference docs:
https://www.easystarter.dev/en/docs/web/integrations/database

Deliverables:
- D1 database name and database_id.
- Configuration files modified.
- Database commands executed and their results.
- If anything fails, explain the reason and the next step.

General execution rules:
- If a step requires manual work in a third-party dashboard, explain it step by step: where to go, which menu to open, what value to create or copy, which permission or type to choose, which file or config field to write it to, and which verification command to run next. Do not only say "manual setup required".
- Clearly separate public config from secrets: public values go into `wrangler.jsonc`, `eas.json`, or frontend env; secrets only go into `.dev.vars`, `.env.production`, or the corresponding CLI secret command.
- Temporarily unused features should be commented out or kept disabled, not deleted; only remove copy, page sections, or sample data when this prompt explicitly asks for that cleanup.

Please help me configure the email service.

Goals:
- Use the built-in Resend email service.
- Configure variables required for signup verification and password reset emails.
- Configure sender name and sender domain.

Please follow these steps:
1. Read `packages/app-config/src/app-config.ts`, `apps/server/.dev.vars.example`, `apps/server/.env.production.example`, and `apps/server/src/emails` to confirm the email provider and template locations.
2. Check whether `common.email.provider` is `resend`.
3. Check and configure:
   - `RESEND_API_KEY`
   - `common.app.name`
   - `common.email.from.localPart`
   - `common.email.from.domain`
4. If I have not provided a Resend API Key, tell me:
   - Go to https://resend.com/api-keys to create an API Key.
   - Choose Sending access.
   - Write the key to `apps/server/.dev.vars` and `apps/server/.env.production`.
5. If the sender domain is not verified yet, tell me to add the domain in Resend Domains and add the DNS records provided by Resend to my DNS provider.
6. Do not write `RESEND_API_KEY` to frontend environment variables, and do not commit it to Git.
7. After configuration, tell me how to verify email sending through signup verification or forgot password.

Reference docs:
https://www.easystarter.dev/en/docs/web/integrations/email

Deliverables:
- Email provider.
- Final sender format, for example `App Name <noreply@yourdomain.com>`.
- Files modified.
- Remaining actions I need to complete in Resend or DNS.

General execution rules:
- If a step requires manual work in a third-party dashboard, explain it step by step: where to go, which menu to open, what value to create or copy, which permission or type to choose, which file or config field to write it to, and which verification command to run next. Do not only say "manual setup required".
- Clearly separate public config from secrets: public values go into `wrangler.jsonc`, `eas.json`, or frontend env; secrets only go into `.dev.vars`, `.env.production`, or the corresponding CLI secret command.
- Temporarily unused features should be commented out or kept disabled, not deleted; only remove copy, page sections, or sample data when this prompt explicitly asks for that cleanup.

Please help me configure Web authentication.

Goals:
- Get email/password, GitHub OAuth, and Google OAuth working.
- Ensure Server URL, Web URL, OAuth callback URLs, and CORS trusted origins are consistent.
- For third-party dashboard setup that cannot be created automatically, give me a clear action checklist.

Please follow these steps:
1. Read `apps/server/src/lib/auth.ts`, auth client-related code under `apps/web/src`, `packages/app-config/src/app-config.ts`, `apps/server/wrangler.jsonc`, `apps/web/wrangler.jsonc`, and `apps/server/.dev.vars.example`.
2. Generate or check `BETTER_AUTH_SECRET`. If missing, generate it with `openssl rand -base64 32` and write it to `apps/server/.dev.vars`; write the production value to `apps/server/.env.production`.
3. Check whether local and production `SERVER_URL`, `WEBSITE_URL`, `VITE_SERVER_URL`, and `VITE_APP_URL` match each other.
4. Configure GitHub OAuth:
   - Local callback URL is usually `http://localhost:3001/api/auth/callback/github`.
   - Production callback URL is `{SERVER_URL}/api/auth/callback/github`.
   - Put `GITHUB_CLIENT_ID` in public config or vars, and `GITHUB_CLIENT_SECRET` in secret/env files.
5. Configure Google OAuth:
   - Authorized JavaScript origins should use the Web URL, for example `{WEBSITE_URL}`.
   - Authorized redirect URIs should use `{SERVER_URL}/api/auth/callback/google`.
   - Put `GOOGLE_CLIENT_ID` in public config or vars, and `GOOGLE_CLIENT_SECRET` in secret/env files.
6. If email signup verification or forgot password is enabled, confirm the email service is configured.
7. Do not invent real GitHub or Google credentials. If missing, list dashboard creation steps and where to put each value.
8. Start Web + Server and verify signup, login, logout, OAuth callback, and session persistence.

Reference docs:
https://www.easystarter.dev/en/docs/web/integrations/authentication

Deliverables:
- Login methods currently enabled.
- Env/vars list to write.
- GitHub and Google callback URLs to configure in their dashboards.
- Web URL and Server URL check result.
- How to verify the login flow locally.

General execution rules:
- If a step requires manual work in a third-party dashboard, explain it step by step: where to go, which menu to open, what value to create or copy, which permission or type to choose, which file or config field to write it to, and which verification command to run next. Do not only say "manual setup required".
- Clearly separate public config from secrets: public values go into `wrangler.jsonc`, `eas.json`, or frontend env; secrets only go into `.dev.vars`, `.env.production`, or the corresponding CLI secret command.
- Temporarily unused features should be commented out or kept disabled, not deleted; only remove copy, page sections, or sample data when this prompt explicitly asks for that cleanup.

Please help me configure Alibaba Cloud phone sign-in.

Goals:
- Use the built-in Better Auth phone-number plugin and Alibaba Cloud Dypnsapi.
- Configure verification-code login for mainland China phone numbers.
- If my product only targets users in China, help me decide whether phone sign-in can be the only login method.

Please follow these steps:
1. Read `apps/server/src/sms/providers/aliyun.ts`, `apps/server/src/lib/auth.ts`, login-related frontend pages, `apps/server/.dev.vars.example`, and `apps/server/.env.production.example`.
2. Confirm the current phone login flow uses:
   - `SendSmsVerifyCode`
   - `CheckSmsVerifyCode`
   - Mainland China `+86` E.164 phone number format
3. Check and configure server variables:
   - `ALIBABA_CLOUD_ACCESS_KEY_ID`
   - `ALIBABA_CLOUD_ACCESS_KEY_SECRET`
4. If I have not provided an AccessKey, tell me:
   - Create a RAM user in Alibaba Cloud RAM Console.
   - Enable OpenAPI access.
   - Grant `dypns:SendSmsVerifyCode` and `dypns:CheckSmsVerifyCode`.
   - After creating the AccessKey, write it to both `apps/server/.dev.vars` and `apps/server/.env.production`.
5. Do not change the built-in Alibaba Cloud verification-code parameters unless I explicitly ask:
   - `ALIYUN_SMS_VERSION`
   - `ALIYUN_SMS_SIGN_NAME`
   - `ALIYUN_SMS_TEMPLATE_CODE`
6. If I want phone sign-in only, check whether GitHub / Google login variables and UI can be left unconfigured or hidden, and give a recommendation.
7. Start local Server and Web, then verify the send-code and verify-code endpoints.

Reference docs:
https://www.easystarter.dev/en/docs/web/integrations/authentication/aliyun-phone-auth

Deliverables:
- Alibaba Cloud variables configured.
- RAM permission checklist.
- Local verification steps.
- Conclusion on whether other login methods are still required.

General execution rules:
- If a step requires manual work in a third-party dashboard, explain it step by step: where to go, which menu to open, what value to create or copy, which permission or type to choose, which file or config field to write it to, and which verification command to run next. Do not only say "manual setup required".
- Clearly separate public config from secrets: public values go into `wrangler.jsonc`, `eas.json`, or frontend env; secrets only go into `.dev.vars`, `.env.production`, or the corresponding CLI secret command.
- Temporarily unused features should be commented out or kept disabled, not deleted; only remove copy, page sections, or sample data when this prompt explicitly asks for that cleanup.

Please help me configure Cloudflare R2 storage.

Goals:
- Create or connect an R2 bucket.
- Configure the R2 binding for the Worker.
- Configure the public file access URL.
- Verify avatar or attachment upload.

Please follow these steps:
1. Read `apps/server/wrangler.jsonc`, `apps/server/src/storage`, `packages/app-config/src/app-config.ts`, `apps/server/.dev.vars.example`, and `apps/server/.env.production.example`.
2. Check the R2 binding name used by the project, usually `STORAGE`.
3. If there is no bucket yet, prefer the project command, for example `pnpm wrangler r2 bucket create <bucket-name>`; if it cannot be executed, tell me the Cloudflare Dashboard path to create it.
4. Write the bucket name into `r2_buckets` in `apps/server/wrangler.jsonc`.
5. Guide me to enable Public Access in Cloudflare R2 bucket Settings and get `https://pub-xxxx.r2.dev` or a custom domain.
6. Write the public URL to:
   - `R2_PUBLIC_URL` in `apps/server/.dev.vars`
   - `R2_PUBLIC_URL` in `apps/server/.env.production`
7. Check whether upload types, file size limits, and allowed MIME types in `packages/app-config/src/app-config.ts` fit the current product needs.
8. Start local Server and Web, then verify whether avatar or attachment upload works.

Reference docs:
https://www.easystarter.dev/en/docs/web/integrations/storage

Deliverables:
- R2 bucket name.
- R2_PUBLIC_URL.
- Configuration files modified.
- Upload limit summary.
- Local verification method.

General execution rules:
- If a step requires manual work in a third-party dashboard, explain it step by step: where to go, which menu to open, what value to create or copy, which permission or type to choose, which file or config field to write it to, and which verification command to run next. Do not only say "manual setup required".
- Clearly separate public config from secrets: public values go into `wrangler.jsonc`, `eas.json`, or frontend env; secrets only go into `.dev.vars`, `.env.production`, or the corresponding CLI secret command.
- Temporarily unused features should be commented out or kept disabled, not deleted; only remove copy, page sections, or sample data when this prompt explicitly asks for that cleanup.

Please help me configure Web Stripe payments.

Goals:
- Use the built-in Stripe Provider.
- Configure subscriptions, lifetime purchase, Billing Portal, and Webhook.
- Update server environment variables and `app-config.ts` pricing plans.

Please follow these steps:
1. Read `packages/app-config/src/app-config.ts`, `apps/server/src/payments`, `apps/server/.dev.vars.example`, `apps/server/.env.production.example`, and Web pricing / billing pages.
2. Confirm whether `web.payments.provider` is `stripe`; if not, explain the current provider and the impact of switching.
3. Check and configure server variables:
   - `STRIPE_SECRET_KEY`
   - `STRIPE_WEBHOOK_SECRET`
4. If I have not provided a Stripe Secret Key, tell me to get it from Stripe Dashboard → Developers → API keys:
   - Use `sk_test_` for test environment.
   - Use `sk_live_` for production environment.
5. Guide me to create Stripe Products and Prices:
   - Pro monthly Price
   - Pro annual Price
   - Lifetime one-time Price
6. Write Stripe Price IDs into `web.payments.plans` in `packages/app-config/src/app-config.ts`, ensuring:
   - `providerPriceId` is `price_...`
   - `amountCents` matches the price in Stripe Dashboard
   - `priceType`, `interval`, `trialDays`, and `status` are correct
7. Use Stripe CLI for local Webhook development:
   - If not installed, tell me that macOS can run `brew install stripe/stripe-cli/stripe`.
   - Run `stripe login`.
   - Run `stripe listen --forward-to http://localhost:3001/api/webhooks/stripe`.
   - Write the `whsec_...` printed by the terminal to `apps/server/.dev.vars`.
8. Configure production Webhook in Stripe Dashboard with URL `{SERVER_URL}/api/webhooks/stripe`, and write the Signing secret to `apps/server/.env.production`.
9. Check whether Billing Portal is enabled in Stripe Dashboard.
10. Start Web + Server and verify subscription and lifetime purchase flows with a Stripe test card.

Reference docs:
https://www.easystarter.dev/en/docs/web/integrations/payments/stripe

Deliverables:
- Where Stripe environment variables were written.
- Price ID to local plan mapping.
- Local and production Webhook configuration.
- Billing Portal configuration status.
- Local payment verification steps.

General execution rules:
- If a step requires manual work in a third-party dashboard, explain it step by step: where to go, which menu to open, what value to create or copy, which permission or type to choose, which file or config field to write it to, and which verification command to run next. Do not only say "manual setup required".
- Clearly separate public config from secrets: public values go into `wrangler.jsonc`, `eas.json`, or frontend env; secrets only go into `.dev.vars`, `.env.production`, or the corresponding CLI secret command.
- Temporarily unused features should be commented out or kept disabled, not deleted; only remove copy, page sections, or sample data when this prompt explicitly asks for that cleanup.

Please help me configure Web Creem payments.

Goals:
- Use the built-in Creem Provider.
- Configure subscriptions, lifetime purchase, customer billing portal, and Webhook.
- Update server environment variables and `app-config.ts` pricing plans.

Please follow these steps:
1. Read `packages/app-config/src/app-config.ts`, `apps/server/src/payments`, `apps/server/.dev.vars.example`, `apps/server/.env.production.example`, and Web pricing / billing pages.
2. Confirm whether `web.payments.provider` is `creem`; if not, explain the current provider and the impact of switching.
3. Check and configure server variables:
   - `CREEM_API_KEY`
   - `CREEM_WEBHOOK_SECRET`
4. If I have not provided a Creem API Key, tell me to get it from the Creem dashboard:
   - Use `creem_test_` for test environment.
   - Use `creem_live_` for production environment.
5. Guide me to create Creem Products:
   - Pro monthly product
   - Pro annual product
   - Lifetime one-time product
6. Write Creem Product IDs into `web.payments.plans` in `packages/app-config/src/app-config.ts`, ensuring:
   - `providerPriceId` is `prod_...`
   - `amountCents` matches the price in Creem dashboard
   - `trialDays` matches the trial days configured in the Creem product
   - `priceType`, `interval`, and `status` are correct
7. Use ngrok for local Webhook development:
   - If ngrok is not installed, tell me that macOS can run `brew install ngrok/ngrok/ngrok`, or download it from https://ngrok.com/download.
   - If an authtoken is required, tell me to run `ngrok config add-authtoken <your-token>`.
   - After starting the Server, run `ngrok http 3001`.
   - Set Creem Webhook URL to `{ngrok_https_url}/api/webhooks/creem`.
8. Configure production Webhook in the Creem dashboard with URL `{SERVER_URL}/api/webhooks/creem`, and write the Webhook Secret to `apps/server/.env.production`.
9. Start Web + Server and verify subscription, lifetime purchase, and billing portal flows.

Reference docs:
https://www.easystarter.dev/en/docs/web/integrations/payments/creem

Deliverables:
- Where Creem environment variables were written.
- Product ID to local plan mapping.
- Local and production Webhook configuration.
- Local payment verification steps.

General execution rules:
- If a step requires manual work in a third-party dashboard, explain it step by step: where to go, which menu to open, what value to create or copy, which permission or type to choose, which file or config field to write it to, and which verification command to run next. Do not only say "manual setup required".
- Clearly separate public config from secrets: public values go into `wrangler.jsonc`, `eas.json`, or frontend env; secrets only go into `.dev.vars`, `.env.production`, or the corresponding CLI secret command.
- Temporarily unused features should be commented out or kept disabled, not deleted; only remove copy, page sections, or sample data when this prompt explicitly asks for that cleanup.

Please help me deploy the Server to Cloudflare Workers.

Goals:
- Complete local CLI deployment or check GitHub automatic deployment configuration.
- Configure production vars and secrets.
- Run production D1 database migrations.
- Output the final Server URL and check authentication, storage, and payment Webhook URLs.

Please follow these steps:
1. Read `apps/server/wrangler.jsonc`, `apps/server/.env.production.example`, `apps/server/.dev.vars`, the root `package.json`, and `apps/server/package.json`.
2. Check deployment prerequisites:
   - Cloudflare is logged in.
   - D1 database_id is configured.
   - R2 bucket is configured.
   - `SERVER_URL` and `WEBSITE_URL` are configured as production URLs.
3. Check `apps/server/wrangler.jsonc`:
   - `name`
   - `d1_databases`
   - `r2_buckets`
   - `vars.SERVER_URL`
   - `vars.WEBSITE_URL`
   - Public variables such as OAuth Client IDs
4. Prepare `apps/server/.env.production` with sensitive variables only, for example:
   - `BETTER_AUTH_SECRET`
   - `GITHUB_CLIENT_SECRET`
   - `GOOGLE_CLIENT_SECRET`
   - `RESEND_API_KEY`
   - `R2_PUBLIC_URL`
   - `STRIPE_SECRET_KEY`
   - `STRIPE_WEBHOOK_SECRET`
   - `CREEM_API_KEY`
   - `CREEM_WEBHOOK_SECRET`
5. Run the deployment command, preferring a project script such as `pnpm deploy:server`.
6. After deployment succeeds, record the Worker URL.
7. Push production Secrets, preferring a project script such as `pnpm -F server secrets:bulk:production`.
8. Run production database migrations:
   - If schema changed, run `pnpm db:generate` first.
   - Then run `pnpm db:migrate`.
9. If a custom domain is bound, check and update:
   - `SERVER_URL`
   - `WEBSITE_URL`
   - Web-side `VITE_SERVER_URL`
   - GitHub / Google OAuth callback URLs
   - Stripe / Creem Webhook URLs
10. After deployment, access a health check or key API to confirm the Worker responds correctly.

Reference docs:
https://www.easystarter.dev/en/docs/web/deploy-server

Deliverables:
- Actual deployment command.
- Worker URL or custom Server URL.
- Names of Secrets pushed. Do not output secret values.
- Database migration result.
- URLs that still need to be synchronized in OAuth / payment dashboards / Web config.

General execution rules:
- If a step requires manual work in a third-party dashboard, explain it step by step: where to go, which menu to open, what value to create or copy, which permission or type to choose, which file or config field to write it to, and which verification command to run next. Do not only say "manual setup required".
- Clearly separate public config from secrets: public values go into `wrangler.jsonc`, `eas.json`, or frontend env; secrets only go into `.dev.vars`, `.env.production`, or the corresponding CLI secret command.
- Temporarily unused features should be commented out or kept disabled, not deleted; only remove copy, page sections, or sample data when this prompt explicitly asks for that cleanup.

Please help me deploy Web to Cloudflare Workers.

Goals:
- Deploy the TanStack Start Web app to Cloudflare Workers.
- Confirm the Service Binding between Web Worker and Server Worker is correct.
- Configure production Web URL and Server URL.

Please follow these steps:
1. Read `apps/web/wrangler.jsonc`, `apps/server/wrangler.jsonc`, `apps/web/package.json`, and the root `package.json`.
2. Confirm the Server has already been deployed and that `name` in `apps/server/wrangler.jsonc` is the real Server Worker name.
3. Check `apps/web/wrangler.jsonc`:
   - `name`
   - `services[0].binding`
   - `services[0].service`
   - `vars.VITE_SERVER_URL`
   - `vars.VITE_APP_URL`
4. Ensure `services[0].service` exactly matches the Server Worker's `name`.
5. Ensure `VITE_SERVER_URL` points to the production Server URL and `VITE_APP_URL` points to the production Web URL.
6. Run the deployment command, preferring a project script such as `pnpm deploy:web`.
7. After deployment succeeds, record the Web Worker URL.
8. If a custom domain is bound, sync updates to:
   - `VITE_APP_URL` in `apps/web/wrangler.jsonc`
   - `VITE_SERVER_URL` in `apps/web/wrangler.jsonc`
   - `WEBSITE_URL` in `apps/server/wrangler.jsonc`
   - OAuth dashboard Homepage URL and callback URLs
9. Redeploy Web and any necessary Server so static vars take effect.
10. Visit production Web and verify key flows such as homepage, login, payments, and file upload.

Reference docs:
https://www.easystarter.dev/en/docs/web/deploy-web

Deliverables:
- Actual deployment command.
- Web Worker URL or custom Web URL.
- Service Binding check result.
- Configuration files modified.
- Production verification checklist.

General execution rules:
- If a step requires manual work in a third-party dashboard, explain it step by step: where to go, which menu to open, what value to create or copy, which permission or type to choose, which file or config field to write it to, and which verification command to run next. Do not only say "manual setup required".
- Clearly separate public config from secrets: public values go into `wrangler.jsonc`, `eas.json`, or frontend env; secrets only go into `.dev.vars`, `.env.production`, or the corresponding CLI secret command.
- Temporarily unused features should be commented out or kept disabled, not deleted; only remove copy, page sections, or sample data when this prompt explicitly asks for that cleanup.

Please help me configure the Web theme system.

Goals:
- Adjust the default theme preset.
- Add a new theme Preset if needed.
- Ensure light and dark CSS variables are complete, then verify theme switching and persistence.

Please follow these steps:
1. Read `apps/web/src/configs/theme-presets.ts`, Web theme provider / hook / config files, and `packages/app-config/src/app-config.ts`.
2. First explain the current theme system:
   - Appearance modes: `light`, `dark`, `system`
   - Theme preset list
   - User preference localStorage keys
3. If I only want to change the default theme, adjust the order of `themePresets` in `theme-presets.ts` and put the target preset first.
4. If I want to add a new theme, add a new key to `themePresets` with:
   - `label`
   - `styles.light`
   - `styles.dark`
5. The new theme must contain exactly the same CSS variable names as existing themes to avoid missing runtime styles.
6. Check whether the theme selector UI automatically shows the new preset. If not, add the required configuration.
7. Start Web and check light/dark/system switching, theme preset switching, whether preferences persist after refresh, and whether first paint has no obvious flash.

Reference docs:
https://www.easystarter.dev/en/docs/web/config/theme

Deliverables:
- Default theme configuration.
- New or modified theme preset.
- Files modified.
- Development services that need restart.
- Visual verification checklist.

General execution rules:
- If a step requires manual work in a third-party dashboard, explain it step by step: where to go, which menu to open, what value to create or copy, which permission or type to choose, which file or config field to write it to, and which verification command to run next. Do not only say "manual setup required".
- Clearly separate public config from secrets: public values go into `wrangler.jsonc`, `eas.json`, or frontend env; secrets only go into `.dev.vars`, `.env.production`, or the corresponding CLI secret command.
- Temporarily unused features should be commented out or kept disabled, not deleted; only remove copy, page sections, or sample data when this prompt explicitly asks for that cleanup.

Please help me configure the Web landing page.

Goals:
- Adjust the default landing page section order.
- Remove sections that are not needed and add sections that are needed.
- Add a custom landing page section if needed.

Please follow these steps:
1. Read `apps/web/src/configs/web-config.ts`, `apps/web/src/configs/landing-page-component/landing-page-component-registry.tsx`, `apps/web/src/configs/landing-page-component/landing-page-component-config.ts`, and `apps/web/src/components/landing-page`.
2. List the currently available section keys, labels, and types.
3. Check the current `defaultLandingPageComponents` order.
4. Adjust default sections based on my product needs:
   - Reorder sections.
   - Remove sections that are not needed.
   - Add registered sections.
5. Note that only one section with the same `type` will be shown on the landing page. If multiple sections of the same type are selected, warn me and keep the most suitable one.
6. If I want to add a custom section:
   - Create the component under `apps/web/src/components/landing-page/`.
   - Register it in `landing-page-component-registry.tsx`.
   - Add label, group, and type in `landing-page-component-config.ts`.
   - If it should be shown by default, add it to `defaultLandingPageComponents` in `web-config.ts`.
7. Start Web and check whether each homepage section appears as expected, and whether desktop and mobile layouts are correct.

Reference docs:
https://www.easystarter.dev/en/docs/web/config/landing-page

Deliverables:
- Final landing page section order.
- Sections added, removed, or modified.
- Files modified.
- Copy or image assets I still need to provide.
- Visual verification checklist.

General execution rules:
- If a step requires manual work in a third-party dashboard, explain it step by step: where to go, which menu to open, what value to create or copy, which permission or type to choose, which file or config field to write it to, and which verification command to run next. Do not only say "manual setup required".
- Clearly separate public config from secrets: public values go into `wrangler.jsonc`, `eas.json`, or frontend env; secrets only go into `.dev.vars`, `.env.production`, or the corresponding CLI secret command.
- Temporarily unused features should be commented out or kept disabled, not deleted; only remove copy, page sections, or sample data when this prompt explicitly asks for that cleanup.

Please help me configure Web analytics.

Goals:
- Wire up Google Analytics 4 (traffic) and OpenPanel (product analytics).
- Both providers are optional and skip themselves when their env vars are empty — they don't interfere with each other.
- OpenPanel should not listen to every route change by default; expose `trackOpenPanelEvent` / `trackOpenPanelScreenView` and call them only from key funnel steps.
- Put each variable in the right place for local dev, local CLI deploy, and CI / remote deploy.

Please follow these steps:
1. Read `apps/web/src/lib/analytics/google-analytics.tsx`, `apps/web/src/lib/analytics/openpanel.ts`, `apps/web/src/lib/analytics/page-view-tracker.tsx`, `apps/web/src/routes/__root.tsx`, `apps/web/.env.development.example`, `apps/web/.env.production.example`, and `apps/web/wrangler.jsonc` to confirm the variable names and loading flow.
2. If I haven't provided a GA4 Measurement ID:
   - Sign in at https://analytics.google.com.
   - Admin → Create → Property, fill in product name, time zone, currency.
   - Data Streams → Add stream → Web, enter the site URL.
   - On the stream detail page copy the **Measurement ID** (format `G-XXXXXXXXXX`).
3. If I haven't provided an OpenPanel Client ID:
   - Sign up at https://openpanel.dev.
   - Click Create Project and fill in Project name.
   - Keep **Website** enabled, and turn off **App** and **Backend / API** unless needed now.
   - Enter the production site URL in **Domain**, e.g. `https://yourdomain.com`.
   - In **Allowed domains**, list origins allowed to write events — e.g. the production domain and `http://localhost:3000`.
   - Click **Create project**.
   - After creation, copy the Website **Client ID** from the project's client details (UUID).
4. Write `VITE_GA_MEASUREMENT_ID` and `VITE_OPENPANEL_CLIENT_ID` to:
   - `apps/web/.env.development` for local dev.
   - The `vars` block in `apps/web/wrangler.jsonc` for local CLI deploys (plain text, not a Secret).
   - `apps/web/.env.production` as the canonical CI variable list, and mirror those into Cloudflare's **build variables** (GitHub auto-deploy).
5. Both values are `VITE_`-prefixed public config that ships in the client bundle. Do **not** put them in `.dev.vars` and do **not** push them via `pnpm run secrets:bulk:production`.
6. To enable only one provider, leave the other variable empty — its SDK will skip automatically.
7. After configuration, start Web and verify:
   - The current session shows up in GA4 Realtime.
   - GA `page_view` updates when routes change.
   - After manually calling an OpenPanel helper from key funnel steps such as signup completed, login succeeded, subscription started, or core generation finished, those events show up in the OpenPanel Live view.

Reference docs:
https://www.easystarter.dev/en/docs/web/integrations/analytics

Deliverables:
- Whether GA4 and OpenPanel are enabled and the IDs used.
- Files modified (`.env.development` / `wrangler.jsonc` / `.env.production`).
- The CI build-variable list.
- The 3-5 key funnel steps you recommend tracking first.
- Local verification steps.