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 mobile setup: Apple Sign-In (iOS) only, RevenueCat in-app purchases only, R2 storage only, D1 database only. Skip everything non-essential.

Goals:
- Authentication: Apple Sign-In (iOS native) only. Disable email/password, Google OAuth, and GitHub.
- Payments: RevenueCat only. No Stripe or other providers.
- Storage: Cloudflare R2 only.
- Database: Cloudflare D1 only.
- Verify everything on a physical device first, then deploy Server and build/submit via EAS in one pass.

Please follow these steps:

### Step 1: Cloudflare base setup (using Wrangler CLI)
Reference docs: https://developers.cloudflare.com/workers/wrangler/

1. First read these files to confirm the project's real config locations and scripts:
   - Root `package.json`
   - `apps/server/package.json`
   - `apps/server/wrangler.jsonc`
   - `apps/server/drizzle.config.ts`
   - `apps/server/.dev.vars.example`
   - `apps/server/.env.production.example`
   - `apps/native/app.json`
   - `apps/native/eas.json`
   - `packages/app-config/src/app-config.ts`
2. Check whether Wrangler CLI is available: `pnpm wrangler --version`.
3. Check Cloudflare login status: `pnpm wrangler whoami`. If not logged in, run `pnpm wrangler login`, complete browser authentication, then continue.
4. Create or connect a D1 database:
   - If no database exists yet, run `pnpm wrangler d1 create <database-name>`.
   - Write the output `database_name` and `database_id` to `d1_databases[0]` in `apps/server/wrangler.jsonc`.
   - Also write the `database_id` to `CLOUDFLARE_D1_DATABASE_ID` in `apps/server/.dev.vars` and `apps/server/.env.production`.
5. Create or connect an R2 bucket:
   - If no bucket exists yet, 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` aligned with the binding used by the project code, usually `STORAGE`.
   - For local development, enable Public Access (r2.dev) in Cloudflare R2 bucket Settings, then write `https://pub-xxxx.r2.dev` to `R2_PUBLIC_URL` in `apps/server/.dev.vars`.
   - For production, prefer binding a custom domain in R2 bucket Settings → Custom Domains, then write the production URL to `R2_PUBLIC_URL` in `apps/server/.env.production`.
   - If the production custom domain is not confirmed yet, use the r2.dev public URL for now and continue. In the deliverables, tell me to bind an R2 Custom Domain later, update `R2_PUBLIC_URL` in `apps/server/.env.production`, then push production Secrets again.
6. Set the Server Worker name in `apps/server/wrangler.jsonc`, for example `<your-app>-server`.
7. Configure `vars` in `apps/server/wrangler.jsonc`:
   - `SERVER_URL`: production Server URL.
   - `WEBSITE_URL`: production Web URL, used by auth callbacks, email links, or mobile deep links.
   - `APPLE_APP_BUNDLE_IDENTIFIER`: must exactly match `expo.ios.bundleIdentifier` in `apps/native/app.json`.
   - If the Cloudflare production custom domain is not confirmed yet, use the `*.workers.dev` URL returned after Worker deployment as `SERVER_URL` and continue. `WEBSITE_URL` can keep the `<ROOT_DOMAIN>` placeholder or use the currently reachable Web URL. In the deliverables, explain that after the final domain is confirmed, `SERVER_URL` / `WEBSITE_URL`, the RevenueCat Webhook, and the Apple Return URL must be updated, then Server must be redeployed and the production App rebuilt.
8. Configure `apps/server/.dev.vars`:
   - `CLOUDFLARE_ACCOUNT_ID`: copy it from the Cloudflare Dashboard overview page.
   - `CLOUDFLARE_API_TOKEN`: create it in Cloudflare API Tokens with at least D1 Edit, Workers R2 Storage Edit, and Workers Scripts Edit permissions.
   - `CLOUDFLARE_D1_DATABASE_ID`: value from step 4.
   - `BETTER_AUTH_SECRET`: generate it with `openssl rand -base64 32`.
   - `R2_PUBLIC_URL`: local public access URL from step 5.
9. Configure `apps/server/.env.production`: write production values for `CLOUDFLARE_ACCOUNT_ID`, `CLOUDFLARE_API_TOKEN`, `CLOUDFLARE_D1_DATABASE_ID`, `BETTER_AUTH_SECRET`, and `R2_PUBLIC_URL`. Generate a separate production `BETTER_AUTH_SECRET`; do not reuse the local value.
10. Configure mobile environment variables:
   - Set `EXPO_PUBLIC_SERVER_API_URL` to the production Server URL in each build profile in `apps/native/eas.json`.
   - Set `EXPO_PUBLIC_WEB_APP_URL` to the production Web URL.
   - If the project has local mobile env files, also write the local development Server URL there. For physical-device development, do not use `localhost`; prefer an ngrok HTTPS URL.
   - If the production domain is not confirmed yet, set `EXPO_PUBLIC_SERVER_API_URL` to the currently reachable Workers URL, and set `EXPO_PUBLIC_WEB_APP_URL` to the currently reachable Web URL or keep the `<ROOT_DOMAIN>` placeholder. In the deliverables, explain that after the final domain is confirmed, `apps/native/eas.json` must be updated and a new EAS production build must be created.
11. Run database migrations:
   - `pnpm db:generate`
   - `pnpm db:migrate:local`

### Step 2: Apple Sign-In only
1. Open `apps/server/src/lib/auth.ts`. In `socialProviders`, comment out `google` and `github`. Keep only Apple Sign-In configuration; do not delete the related code.
2. If `emailAndPassword` exists, leave it commented out. Do not enable it.
3. Confirm `APPLE_APP_BUNDLE_IDENTIFIER` is written to `vars` in `apps/server/wrangler.jsonc`, and that it exactly matches `expo.ios.bundleIdentifier` in `apps/native/app.json`.
4. If I do not have an Apple Developer account, or have not enabled Sign in with Apple for the App ID yet, tell me: go to Apple Developer Portal → Certificates, Identifiers & Profiles → Identifiers, find the matching Bundle ID, enable the Sign in with Apple capability, then regenerate the Provisioning Profile.
5. Note: Apple Sign-In only covers iOS. This minimal setup does not handle Android login; if Android login is needed later, add Google or phone-number login separately.

### Step 3: App Store Connect setup (using asc-cli)
Reference docs: https://github.com/tddworks/asc-cli

1. Check whether asc-cli is installed: `asc --version`. If not installed, run `brew install tddworks/tap/asccli`.
2. Check login status: `asc auth check`. If not logged in, use an App Store Connect API Key:
   - Go to App Store Connect → Users and Access → Integrations → App Store Connect API → Generate API Key. Use Admin or App Manager permissions.
   - Download the `.p8` private key file, and record the Key ID and Issuer ID.
   - Log in with: `asc auth login --key-id <KEY_ID> --issuer-id <ISSUER_ID> --private-key-path <path/to/AuthKey.p8> --name default`.
3. Confirm the App exists: `asc apps list`. If the target App is found, run `asc init --app-id <app-id>` to pin the current project context.
4. If the target App does not exist in App Store Connect yet, prefer creating it with asc-cli. If the current asc-cli version does not support all required fields, clearly tell me that the App must be created in App Store Connect web UI, and list the required App Name, Bundle ID, SKU, and Primary Language.
5. Create or confirm in-app purchase products:
   - First run `asc subscriptions --help` and `asc iap --help` to confirm the subscription and one-time purchase commands supported by the current asc-cli version.
   - Use asc-cli to create the subscription group, monthly subscription, annual subscription, and non-consumable Lifetime product.
   - Plan Product IDs before creating them, for example `com.yourapp.pro.monthly`, `com.yourapp.pro.yearly`, and `com.yourapp.pro.lifetime`. Product IDs cannot be changed after creation, so do not use temporary names.
   - If a product creation or initial submission step must be completed in Apple's web UI or requires iris private login capability, do not invent commands. In the deliverables, explain the reason and the exact manual steps.
6. Record all App Store Connect Product IDs. They will be written to RevenueCat and `packages/app-config/src/app-config.ts` later.

### Step 4: RevenueCat setup (using RevenueCat MCP)
Reference docs: https://www.revenuecat.com/docs/tools/mcp/setup

1. Configure the RevenueCat MCP Server. If you do not have a RevenueCat API v2 Secret Key, create one in RevenueCat Dashboard → API Keys.
2. Use RevenueCat MCP to create or confirm the iOS App. The Bundle ID must match `expo.ios.bundleIdentifier` in `apps/native/app.json`.
3. Use MCP to import the Products created in App Store Connect in step 3.
4. Use MCP to create an Entitlement, for example `pro`, and attach all Pro-unlocking Products to that Entitlement.
5. Use MCP to create or update the default Offering, and attach Monthly, Annual, and Lifetime packages.
6. Get the client API Key `EXPO_PUBLIC_REVENUECAT_IOS_API_KEY`, then write it to `apps/native/eas.json` and the local mobile env file.
7. Set `EXPO_PUBLIC_REVENUECAT_ENTITLEMENT_ID`, for example `pro`, in `apps/native/eas.json` and the local mobile env file.
8. Get the server API Key `REVENUECAT_SECRET_API_KEY`, then write it to `apps/server/.dev.vars` and `apps/server/.env.production`.
9. Generate the Webhook Authorization header:
   - Run `openssl rand -hex 32`.
   - Prefix it with `Bearer `, for example `Bearer <random>`.
   - Write the same full value to the RevenueCat Webhook Authorization header and to `REVENUECAT_WEBHOOK_SECRET` in `apps/server/.dev.vars` / `apps/server/.env.production`.
10. Local Webhook: start the Server, run `ngrok http 3001`, and use RevenueCat MCP to configure the Webhook URL as `{ngrok_https_url}/api/webhooks/revenuecat`.
11. Write store Product IDs to `native.payments` in `packages/app-config/src/app-config.ts`, ensuring the iOS `providerPriceId` exactly matches the App Store Connect / RevenueCat Product ID.

### Step 5: Local verification (physical iOS device preferred)
1. Start the Server: `pnpm dev:server`.
2. A physical device cannot reach localhost. Expose the local Server with ngrok: run `ngrok http 3001`, then write the HTTPS forwarding URL to the mobile environment variable `EXPO_PUBLIC_SERVER_API_URL`.
3. Restart Expo / Native App so the environment variable takes effect.
4. Connect the iOS device and start the App using the project's iOS device script.
5. Verify that Apple Sign-In completes successfully.
6. Verify that the RevenueCat Offering loads and plans are displayed.
7. Verify that avatar or file upload to R2 works.
8. Verify that local D1 migrations have run and the Server no longer fails because of missing database schema.

### Step 6: Deploy Server and build for submission
1. Confirm `vars.SERVER_URL` and `vars.WEBSITE_URL` in `apps/server/wrangler.jsonc` are production URLs.
2. Confirm the production profile in `apps/native/eas.json` uses the production `EXPO_PUBLIC_SERVER_API_URL` and `EXPO_PUBLIC_WEB_APP_URL`.
   - If the Cloudflare production custom domain is not confirmed yet, first use the Workers URL returned by `pnpm deploy:server` to complete Server deployment, physical-device verification, and the EAS build. In the deliverables, tell me to bind the final domain in Cloudflare later, then update `apps/server/wrangler.jsonc`, `apps/server/.env.production`, `apps/native/eas.json`, the RevenueCat Webhook, and the Apple Return URL, redeploy Server, and rebuild the App.
3. Run `pnpm deploy:server`.
4. Push production Secrets: `pnpm -F server secrets:bulk:production`.
5. Run production database migration: `pnpm db:migrate`.
6. Use RevenueCat MCP to configure the production Webhook URL: `{SERVER_URL}/api/webhooks/revenuecat`.
7. If using a Service ID callback for Apple, update the Return URL in Apple Developer Portal to `{SERVER_URL}/api/auth/callback/apple`.
8. Build the iOS production package: `pnpm -F native eas:build:ios:production`.
9. Submit to App Store Connect: `pnpm -F native eas:submit:ios:production`.

Reference docs:
https://developers.cloudflare.com/workers/wrangler/
https://github.com/tddworks/asc-cli
https://www.revenuecat.com/docs/tools/mcp/setup
https://www.easystarter.dev/en/docs/mobile/integrations/authentication
https://www.easystarter.dev/en/docs/mobile/integrations/iap/revenuecat
https://www.easystarter.dev/en/docs/mobile/integrations/cloudflare
https://www.easystarter.dev/en/docs/mobile/integrations/storage
https://www.easystarter.dev/en/docs/mobile/integrations/database

Deliverables:
- Cloudflare login status.
- Server Worker name.
- Login methods enabled (Apple Sign-In only, iOS only).
- Product IDs created in App Store Connect.
- RevenueCat Offering, Entitlement, and Product ID mapping.
- R2 bucket name and R2_PUBLIC_URL.
- D1 database_id and migration result.
- List of env/vars files written.
- Manual items still required in Apple Developer Portal, App Store Connect, RevenueCat, or Cloudflare, plus why they could not be automated.

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 mobile App and Server local development environment in the current project.

Goals:
- Start the server and iOS simulator using the existing project scripts.
- The App depends on the server, `apps/native/app.json`, and mobile environment variables.
- Both the App 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/native/package.json`, `apps/native/app.json`, `apps/native/.env*.example`, `apps/server/.env*.example`, 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. If any variables cannot be configured automatically, list the variable name, purpose, where to get it, which file to write it to, and an example format.
4. Check whether key fields in `apps/native/app.json` are reasonable for local startup, such as `name`, `slug`, `scheme`, and `ios.bundleIdentifier`.
5. Start the Server. Prefer the local default port defined by the project scripts or docs.
6. After the Server is healthy, start the iOS Simulator / Expo and explain what I should see in the terminal or simulator.

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

Deliverables:
- The actual startup commands used.
- Env files created or modified.
- Variables I still need to fill manually.
- Server URL, App API URL, and how to verify that the App 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 start a physical-device development environment in the current project, together with the Server.

Goals:
- Start the server and physical-device App using the existing project scripts.
- A physical device cannot access `localhost` directly. Please confirm the recommended local access method, such as ngrok or a LAN IP.
- The App depends on `apps/native/app.json`, mobile environment variables, and a Server URL reachable from the device.
- Both the App 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/native/package.json`, `apps/native/app.json`, `apps/native/.env*.example`, `apps/server/.env*.example`, and `apps/server/wrangler.jsonc` to confirm device-development scripts, server port, and required configuration.
2. Check whether physical-device development tools are available, such as Xcode / Android Studio, Expo CLI, EAS CLI, connected iOS device status, or connected Android device status.
3. 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.
4. Start the Server and confirm the local server URL and port.
5. If the physical device needs to access the local Server, configure a public or LAN-reachable URL. Prefer ngrok:
   - First check whether ngrok is installed, for example with `ngrok version`.
   - If it is not installed, tell me how to install it. On macOS, prefer Homebrew: `brew install ngrok/ngrok/ngrok`; downloading from https://ngrok.com/download is also fine.
   - If ngrok requires login or an authtoken, tell me to get the token from https://dashboard.ngrok.com/get-started/your-authtoken, then run `ngrok config add-authtoken <your-token>`.
   - After the Server starts, start ngrok with the actual server port, for example `ngrok http 3001`.
   - Find the HTTPS forwarding URL in ngrok output, for example `https://xxxx.ngrok-free.app`.
   - Write that HTTPS URL to the mobile env variable, for example `EXPO_PUBLIC_SERVER_API_URL=https://xxxx.ngrok-free.app`.
   - Restart Expo / the physical-device App after changing env variables so the new value takes effect.
   - If ngrok cannot be installed or started automatically, tell me which command to run, which URL to copy, and which env file to update.
6. Choose the correct App startup command based on the connected device:
   - Prefer the project's iOS device script for a physical iOS device.
   - Prefer the project's Android device script for a physical Android device.
   - If the project already has an App + Server parallel script, prefer that script.
7. If `scheme`, `ios.bundleIdentifier`, `android.package`, or Apple Team ID in `apps/native/app.json` affects physical-device execution, check it and explain what needs to change.

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

Deliverables:
- The actual Server startup command.
- The actual physical-device startup command.
- ngrok installation status, startup command, and HTTPS forwarding URL.
- Final Server URL reachable from the device.
- Env files created or modified.
- Variables I still need to fill manually.
- How to verify on the physical device that the App 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 mobile `apps/native/app.json`.

Goals:
- Replace the EasyStarter template identifiers with my own App information.
- Ensure iOS, Android, deep links, and EAS Update fields are consistent.
- If required information is missing, do not invent it. List exactly what I need to provide.

Please follow these steps:
1. Read `apps/native/app.json`, `packages/app-config/src/app-config.ts`, and `apps/server/wrangler.jsonc` to confirm the current App name, scheme, Bundle ID, Android package, and Server-side Apple Bundle ID.
2. Check and configure these fields:
   - `expo.name`
   - `expo.slug`
   - `expo.scheme`
   - `expo.ios.bundleIdentifier`
   - `expo.ios.appleTeamId`
   - `expo.android.package`
   - `expo.extra.eas.projectId`
   - `expo.updates.url`
3. Prefer the same reverse-DNS package format for iOS and Android, for example `com.yourcompany.yourapp`.
4. Ensure the `scheme` in `apps/native/app.json` matches the mobile deep link scheme in `packages/app-config/src/app-config.ts`.
5. Ensure `APPLE_APP_BUNDLE_IDENTIFIER` in `apps/server/wrangler.jsonc` matches `expo.ios.bundleIdentifier`.
6. If there is no EAS project yet, tell me to run `eas init` inside `apps/native`, and explain that it generates `projectId` and `updates.url`.
7. Check whether icon and splash asset paths exist. If they still use template assets, list the file paths that need replacement.

Reference docs:
https://www.easystarter.dev/en/docs/mobile/integrations/app-json

Deliverables:
- Fields and values modified.
- Information I still need to provide, such as Apple Team ID, Bundle ID, or EAS Project ID.
- Actions required in Apple Developer Portal or Google Play Console.
- Recommended validation commands after configuration.

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/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/mobile/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.

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, tell me the Cloudflare Dashboard path to create it.
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/mobile/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/mobile/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 mobile authentication.

Goals:
- Get email/password, Google OAuth, and native iOS Apple Sign-In working.
- Ensure Server URL, Deep Link Scheme, OAuth callback URLs, and App configuration 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`, `apps/native/lib/auth/auth.client.ts`, `apps/native/app.json`, `packages/app-config/src/app-config.ts`, `apps/server/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 `SERVER_URL`, `WEBSITE_URL`, and mobile `EXPO_PUBLIC_SERVER_API_URL` are consistent and reachable.
4. Check whether the `scheme` in `apps/native/app.json` matches the mobile scheme in app config.
5. Configure Google OAuth:
   - Callback URL should be `{SERVER_URL}/api/auth/callback/google`.
   - If HTTPS is needed for mobile local development, use ngrok and update the Authorized redirect URI in Google Cloud Console.
   - Put `GOOGLE_CLIENT_ID` in public config or vars, and `GOOGLE_CLIENT_SECRET` in secret/env files.
6. Configure Apple Sign-In:
   - Confirm the App ID has Sign In with Apple enabled in Apple Developer Portal.
   - `APPLE_APP_BUNDLE_IDENTIFIER` must match `ios.bundleIdentifier` in `apps/native/app.json`.
   - If a Service ID callback is needed, use `{SERVER_URL}/api/auth/callback/apple` as the Return URL.
7. Do not invent real Google or Apple credentials. If missing, list dashboard creation steps and where to put each value.

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

Deliverables:
- Login methods currently enabled.
- Env/vars list to write.
- Google and Apple callback URLs to configure in their dashboards.
- Deep Link Scheme 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 / Apple login variables and UI can be left unconfigured or hidden, and give a recommendation.
7. Start local Server and App/Web, then verify the send-code and verify-code endpoints.

Reference docs:
https://www.easystarter.dev/en/docs/mobile/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 the local Server and verify whether avatar or attachment upload works.

Reference docs:
https://www.easystarter.dev/en/docs/mobile/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 plan and create mobile in-app purchase products.

Goals:
- Use asc-cli to create or confirm iOS subscriptions and one-time purchase products in App Store Connect.
- Create or confirm Android subscriptions and one-time purchase products in Google Play Console.
- Record iOS and Android product IDs for RevenueCat and `app-config.ts`.
- Plan naming first, because Product IDs cannot be changed after creation.

Please follow these steps:
1. Read `apps/native/app.json`, `packages/app-config/src/app-config.ts`, and `apps/native/eas.json` to confirm Bundle ID, Android package, current plans, and price configuration.
2. Check asc-cli first:
   - Check whether it is installed: `asc --version`. If not installed, run `brew install tddworks/tap/asccli`.
   - Check login status: `asc auth check`. If not logged in, sign in with an App Store Connect API Key: `asc auth login --key-id <KEY_ID> --issuer-id <ISSUER_ID> --private-key-path <path/to/AuthKey.p8> --name default`.
   - Run `asc apps list` to find the target App. If it exists, run `asc init --app-id <app-id>` to pin the current project context.
   - If first-time IAP submission support is needed, check whether iris login is required with `asc iris status`; if not logged in, explain that I can run `asc iris auth login --apple-id <apple-id> --interactive`.
3. Help me plan the product structure, including at least:
   - Monthly subscription
   - Annual subscription
   - Lifetime purchase
4. Provide iOS Product ID and Android Product ID naming schemes. Product IDs cannot be changed after creation, so do not use temporary names casually.
5. Use asc-cli to create or confirm App Store Connect products:
   - First run `asc subscriptions --help` and `asc iap --help` to confirm the subscription and one-time purchase commands supported by the current asc-cli version.
   - If the target App does not exist in App Store Connect yet, prefer creating it with asc-cli. If the current asc-cli version cannot cover required fields, tell me to create the App in App Store Connect web UI and list the required App Name, Bundle ID, SKU, and Primary Language.
   - Use asc-cli to create the subscription group.
   - Use asc-cli to create monthly and annual subscriptions.
   - Use asc-cli to create a Non-Consumable lifetime product.
   - Use asc-cli or App Store Connect web UI to complete price, availability, localization, and review screenshot.
   - If first-time IAP submission must use iris or App Store Connect web UI, explain why and provide the exact command or manual path. Do not invent commands.
6. Guide me through Google Play Console:
   - Create the App.
   - Confirm at least one AAB/APK has been uploaded.
   - Create subscriptions, Base Plans, and Offers.
   - Create one-time purchase products.
   - Activate all products.
7. If I do not have store accounts, App Store Connect API Key, Google Play Console App, or required permissions yet, list the prerequisites and do not skip steps.

Reference docs:
https://github.com/tddworks/asc-cli
https://www.easystarter.dev/en/docs/mobile/integrations/iap/store-products

Deliverables:
- asc-cli installation and login status.
- App Store Connect App ID.
- Product ID mapping table.
- asc-cli commands executed and results.
- Remaining dashboard steps for each platform, plus why they could not be automated.
- Fields that need to be copied back into RevenueCat and `app-config.ts`.
- Risk reminders, especially that Product IDs cannot be changed.

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 integrate RevenueCat in-app purchases.

Goals:
- Connect App Store / Google Play products.
- Use RevenueCat MCP to configure Products, Offerings, Entitlements, and Webhook.
- Update App-side and Server-side environment variables.
- Update plans and product IDs in `app-config.ts`.

Please follow these steps:
1. Read `apps/native/eas.json`, `packages/app-config/src/app-config.ts`, `apps/server/.dev.vars.example`, `apps/server/.env.production.example`, and RevenueCat webhook-related code under `apps/server/src`.
2. Configure the RevenueCat MCP Server. If there is no RevenueCat API v2 Secret Key yet, create one in RevenueCat Dashboard → API Keys and configure MCP according to the docs.
3. Use RevenueCat MCP to confirm store products have been created and collect iOS / Android Product IDs.
4. Use RevenueCat MCP to create or confirm RevenueCat Apps:
   - Use Bundle ID for iOS.
   - Use package name for Android.
   - Configure App Store Connect API key / Google Play service credentials.
5. Use RevenueCat MCP to import Products and configure the default Offering:
   - Monthly
   - Annual
   - Lifetime
6. Use RevenueCat MCP to create an Entitlement, for example `pro`, and attach all Products that should unlock Pro to that Entitlement.
7. Use RevenueCat MCP to get and configure client variables:
   - `EXPO_PUBLIC_REVENUECAT_IOS_API_KEY`
   - `EXPO_PUBLIC_REVENUECAT_ANDROID_API_KEY`
   - `EXPO_PUBLIC_REVENUECAT_ENTITLEMENT_ID`
   Write them to `apps/native/eas.json` and local mobile env files.
8. Use RevenueCat MCP to get and configure server variables:
   - `REVENUECAT_SECRET_API_KEY`
   - `REVENUECAT_WEBHOOK_SECRET`
   Write them to `apps/server/.dev.vars` and `apps/server/.env.production`.
9. Use ngrok for local Webhook development, and create or update the Webhook through RevenueCat MCP:
   - Start the Server.
   - Run `ngrok http 3001`.
   - Set RevenueCat Webhook URL to `{ngrok_https_url}/api/webhooks/revenuecat`.
   - Make the Authorization header exactly match `REVENUECAT_WEBHOOK_SECRET`.
10. Update `native.payments` in `packages/app-config/src/app-config.ts`, ensuring `providerPriceId` exactly matches the Product IDs in the store dashboards / RevenueCat.
11. Start the App and verify it can fetch Offerings, display plans, and unlock Entitlement after purchase.

Reference docs:
https://www.revenuecat.com/docs/tools/mcp/setup
https://www.easystarter.dev/en/docs/mobile/integrations/iap/revenuecat

Deliverables:
- RevenueCat MCP configuration status.
- RevenueCat App, Offering, and Entitlement configuration summary.
- Where iOS / Android SDK Keys and Entitlement ID were written.
- Server Secret and Webhook configuration locations.
- Plan and product ID mapping in `app-config.ts`.
- How to verify locally and in production.

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 in-app purchase 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`
   - `GOOGLE_CLIENT_SECRET`
   - `RESEND_API_KEY`
   - `R2_PUBLIC_URL`
   - `REVENUECAT_SECRET_API_KEY`
   - `REVENUECAT_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`
   - Web-side Server URL
   - Google / Apple OAuth callback URLs
   - RevenueCat Webhook URL
10. After deployment, access a health check or key API to confirm the Worker responds correctly.

Reference docs:
https://www.easystarter.dev/en/docs/mobile/deploy/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 / RevenueCat / 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 prepare and execute mobile App publication.

Goals:
- Use EAS to build iOS and Android production packages.
- Submit to App Store Connect and Google Play Console.
- Confirm production Server, RevenueCat, auth callbacks, and App identifiers are fully configured.

Please follow these steps:
1. Read `apps/native/app.json`, `apps/native/eas.json`, `apps/native/package.json`, and `packages/app-config/src/app-config.ts`.
2. Check prerequisites:
   - Server has been deployed.
   - `EXPO_PUBLIC_SERVER_API_URL` is the production Server URL.
   - `EXPO_PUBLIC_WEB_APP_URL` is the production Web URL.
   - RevenueCat iOS / Android SDK Keys and Entitlement ID are configured.
   - Apps have been created in App Store Connect and Google Play Console.
3. Check `apps/native/app.json`:
   - `expo.name`
   - `expo.slug`
   - `expo.version`
   - `expo.scheme`
   - `ios.bundleIdentifier`
   - `ios.appleTeamId`
   - `android.package`
   - `extra.eas.projectId`
4. If EAS has not been initialized, run or tell me to run `eas init` inside `apps/native`.
5. Check whether EAS CLI is installed and logged in:
   - `eas --version`
   - `eas whoami`
6. Build the iOS production package, preferring a project script such as `pnpm -F native eas:build:ios:production`.
7. Build the Android production package, preferring a project script such as `pnpm -F native eas:build:android:production`.
8. After builds finish, submit iOS:
   - `pnpm -F native eas:submit:ios:production`
9. Submit Android:
   - `pnpm -F native eas:submit:android:production`
10. After submission, tell me what metadata, screenshots, privacy information, and review notes still need to be filled in App Store Connect / Google Play Console.
11. If the change is only JS/copy/UI, decide whether OTA can be used: `pnpm -F native eas:update:production`.

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

Deliverables:
- EAS login status.
- iOS / Android build links.
- iOS / Android submission results.
- Remaining store listing materials.
- Whether OTA update can be used.

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 mobile theme system.

Goals:
- Adjust the App's default appearance mode and default theme family.
- Add a new Theme Family if needed.
- Keep Uniwind, theme CSS, types, and i18n copy in sync.

Please follow these steps:
1. Read `apps/native/providers/theme-provider.tsx`, `apps/native/global.css`, `apps/native/metro.config.js`, `apps/native/themes`, and mobile theme-related copy in `packages/i18n`.
2. First explain the current theme system:
   - Appearance modes: `system`, `light`, `dark`
   - Theme Families currently available in the project
   - Active theme name format: `{themeFamily}-{resolvedThemeMode}`
3. If I only want to change the default theme, update the default `themeModePreference` and `themeFamily` in `theme-provider.tsx`.
4. If I want to add a new theme family:
   - Add the new key to `THEME_FAMILIES` and the `ThemeFamily` type.
   - Add the corresponding CSS file under `apps/native/themes`.
   - Import the new theme in `apps/native/global.css`.
   - Register `newtheme-light` and `newtheme-dark` in `extraThemes` in `apps/native/metro.config.js`.
   - Add the new theme name and description to i18n copy.
5. The new theme CSS must contain exactly the same variable names as existing themes to avoid missing runtime styles.
6. After changing Metro / Uniwind config, restart Expo. If cache issues occur, use `npx expo start --clear`.
7. Start the App and check theme switching in settings, light/dark switching, and whether preferences persist after restart.

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

Deliverables:
- Default theme configuration.
- New or modified theme family.
- 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 mobile analytics.

Goals:
- Wire up OpenPanel without listening to every route change by default; expose `trackOpenPanelEvent` / `trackOpenPanelScreenView` for key funnel steps.
- The SDK skips initialization when no Client ID or Client Secret is set.
- Place the Client ID and Client Secret correctly for local dev, local production builds, and EAS cloud builds.

Please follow these steps:
1. Read `apps/native/lib/analytics/openpanel.ts`, `apps/native/app/_layout.tsx`, `apps/native/.env.development.local.example`, `apps/native/.env.production.example`, and `apps/native/eas.json` to confirm the variable name and load flow.
2. If I haven't provided an OpenPanel Client ID and Client Secret:
   - Sign up at https://openpanel.dev.
   - Click Create Project and fill in Project name (feel free to reuse the same project as Web for cross-platform funnels).
   - Enable **App**, and turn off **Website** and **Backend / API** unless needed now.
   - Click **Create project**.
   - After creation, copy the App **Client ID** and **Client Secret** from the project's client details.
3. Write `EXPO_PUBLIC_OPENPANEL_CLIENT_ID` and `EXPO_PUBLIC_OPENPANEL_CLIENT_SECRET` to:
   - `apps/native/.env.development.local` — loaded by `expo start` in dev mode, local only.
   - `apps/native/.env.production` — loaded automatically by Expo (based on `NODE_ENV=production`) for local production builds: `eas build --local --profile production`, native builds after `expo prebuild`, or `expo export`. If the file doesn't exist yet, run `cp apps/native/.env.production.example apps/native/.env.production` first.
   - The `env` block in each of `eas.json`'s three profiles (`development`, `preview`, `production`) — used by EAS cloud builds; **takes precedence over `.env.production` and overrides any variable with the same name**.
4. To keep production data separate from internal builds, create different Clients in the OpenPanel dashboard for each environment — sharing one Client across QA and prod mixes the event streams.
5. After starting the App, verify:
   - Regular navigation does not emit OpenPanel events automatically.
   - After manually calling an OpenPanel helper from key funnel steps such as onboarding completed, login succeeded, subscription started, or core generation finished, those events appear in the OpenPanel Live view.

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

Deliverables:
- The OpenPanel Client ID / Client Secret in use (list each environment if you wire up multiple).
- Files modified (`.env.development.local` / `.env.production` / `eas.json`).
- The 3-5 key funnel steps you recommend tracking first.
- Local verification steps.