[Muawiya-contact]

Step 3: one PR for the Supabase production cutover

This is the single large, reviewable Step 3 branch requested by the owner. It starts at merged develop (caaf0be) and targets main so the release diff contains Steps 1–3 together. It is ready for code review; merging requires the owner's specific confirmation. This head branch differs from issue #418's original exact develop → main rule; that exception needs owner review before merge. Issue #418 remains open until the operational gates below are complete.

Review scope

This PR includes the already reviewed Step 1/2 commits from develop, so GitHub reports 279 files against main and its full downloadable diff exceeds the API line limit. Review the Step 3 delta at develop...codex/step3-release-cutover and the focused Step 3 commits. Confirm the prior merged PRs separately in the release diff.

Changes

• Separates the phone's API endpoint from browser confirmation, recovery, privacy, and profile links. An optional legacy web origin lets old shared QR links still be read.
• Hosts those public pages on the static reviewer site because Supabase Edge Functions do not serve browser HTML. The reviewer build accepts the exact Supabase API function URL, with publishable-only page config and security headers.
• Rejects mobile and reviewer builds that mix one Supabase project's Auth URL with another project's API function URL.
• Adds an exact-commit-tag, owner-reviewed, backup-gated one-time production SQL batch for 0046–0130. It refuses an incorrect project or partially migrated baseline and never edits the production ledger automatically.
• Adds a main-only, protected Supabase API/worker deployment with production project and database-connection guards, read-only schema checks, API /health, and an unsigned worker boot check. It deploys no Cron schedule.
• Makes the separate, one-time inactive Cron installer refuse a rerun when any One Concept job already exists, so it cannot silently deactivate a job after handover.
• Adds a protected current-main workflow to install those eight jobs inactive and read back their exact names and state. It requires the successful production API/worker deploy run ID for the same commit, avoiding manual production SQL pasting or premature Cron installation.
• Makes the Release workflow verify the successful deployment run and exact main SHA, validate that the schema connection belongs to production, reject an existing version tag before OTA, publish preview first, and pause for protected approval before production OTA. The production OTA then requires the exact production Supabase API and Auth URLs; Railway or staging URLs fail before publication.
• Adds the production cutover, rollback, capacity, backup, and job handover runbook in docs/SUPABASE_CUTOVER.md; updates RELEASING.md and the codebase map.

Version and What's New

The final branch-to-main diff includes app version 1.10.15 and its one-time What's New card from merged Step 2. The card highlights daily reminders at the learner's chosen time. Native runtime stays 1.10.8. The mobile release diff must be checked again if main or develop moves.

Verification and current status

• Hosted mobile, reviewer/browser, backend, release-guard and migration checks passed on current head 763e799. Netlify reports its deploy preview canceled by site policy, so the new browser routes still require live verification after merge. Focused public-config, browser, production-batch guard and inactive-Cron runner tests passed locally. This review added two production-URL guard tests; all 11 release-guard tests and eight production target/Cron Python unit tests passed locally. The workflow YAML parsed and git diff --check passed. The one-time Cron installer was not run against production or a live pg_cron test database.
• The private production archive was restored a second time in a network-disabled local database. All 85 migrations 0046–0130 passed in filename order with ON_ERROR_STOP; read-back found the expected API and worker schema objects. The temporary database was removed.
• Staging API/worker, provider, security, and load results are recorded in the Step 1/2 work log. The protected production SQL job applied all 85 migrations and its first live schema check passed. The second verifier initially failed before connecting because its Python import path was wrong; this PR fixed that invocation. Owner-approved read-only run 39598031891 validated the production target, returned schema_ready=true and supabase_cutover_schema=ready, and skipped the SQL apply job. The ledger now lists all 130 production migrations. Production Edge deploy, OTA and Cron remain unchanged. Railway Auto Deploy is disabled on all three live services per owner report; the services and both Cron schedules remain running.
• The owner supplied the production Supabase Free-plan baseline for 25 Sep–25 Oct: database 0.033 GB (31.94 MB), Storage 0 GB, egress 0.099 GB, 5 MAU, and 1 Edge invocation. At 500 daily users and 30 API calls each, a 30-day month would consume 450,000 of the documented 500,000 Free Edge invocations before workers. If enabled, the reviewed per-minute reminder schedule adds 43,200 calls; editorial-generation and legacy-enrichment schedules add 21,600 each. That combined planning scenario exceeds the Free allowance before retries and bursts. Actual usage and capacity remain unproven.
• The owner saved nine nonsecret production Edge configuration values. Their visible SHA-256 prefixes match the intended values without disclosing them. The owner subsequently reported saving the private worker database URL and matching Edge/Vault signing key, plus the worker URL in Vault. Those private values need a protected boot and signed-dispatch check after deployment.
• The owner subsequently reported copying the production Gemini key to Edge Secrets and saving editorial, generation and legacy-enrichment flags as true. Email remains disabled with cap zero; production provider calls are not yet exercised.
• A read-only production query on October 21 found 16 of 60 database connections open (1 active), all five tracked work queues at zero, and no cron.job schema yet. This is a point-in-time headroom check, not a 500-user load guarantee. The owner confirmed Netlify's current VITE_API_URL remains on Railway, VITE_SUPABASE_URL names the production project, and its publishable key is present.

Merge and cutover gates still open

1. Refresh Railway deployed SHAs and measure actual per-user traffic. Current production connection utilization and all five work queues were read back on October 21. The Free-plan usage baseline is recorded, but 500-user capacity remains unproven. Rotate exposed Gmail OAuth credentials before enabling production email.
2. The private production database backup completed at 2026-10-21T11:43:58Z; its checksum, archive format, isolated restore, and 85-file migration rehearsal passed. Its non-secret reference is saved in production-schema. The owner approved the exact-tag production SQL run. It applied 0046–0130 and the first live schema check passed. The final verifier initially hit a Python import error. The corrected, owner-approved read-only run 39598031891 passed both schema checks and skipped SQL application. All 85 verified filenames are now in backend/migrations/applied.txt. Do not rerun SQL. The temporary exact-tag environment allowlist entries were removed after completion, retaining only main.
3. Confirm production Edge/Vault secrets by the protected deployment and a signed canary, install inactive Cron through the new protected current-main workflow, then check EAS preview/production values and a real-phone canary without mixing project credentials. The site cancels PR deploy previews, so live route verification follows the merge while Railway remains the configured API.
4. Railway Auto Deploy is disabled on api, reminders and pool-topup per the owner, with the existing deployments and schedules still running. Obtain the owner's explicit confirmation for this exact PR merge. Publish and test the new Netlify pages on main with its current Railway API setting. Then run the protected main-only Supabase deploy, verify live flows, install inactive Cron using its successful deploy run ID, switch and recheck Netlify, test the phone preview, approve production OTA separately, and hand over Cron without duplicate executors.
5. Observe a complete cadence/morning load and old-client tail before separately approving Railway retirement. Production remains on Railway today.

The existing production-schema GitHub environment was verified and updated to require Muawiya-contact approval while keeping its main branch policy; the backup reference and correctly named production deploy token are recorded there. The database restore drill does not cover external Storage files or Supabase service settings. The current public Netlify bundle contains the production Supabase Auth hostname and the Railway API hostname; the owner confirmed those saved Netlify URL settings and the presence of a publishable key, but its value was not independently checked. The PR Netlify preview is canceled by site policy. A read-only check of the current published site found /privacy serves HTML, while /confirmed, /reset-password, and /p/... still serve the old app shell. The new public pages must be published and tested before Auth or mobile URLs change.

The code is ready for review; production deployment, client routing, Cron activation, and Railway retirement remain separate guarded operations. No production switch or PR merge is requested by marking this PR ready.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[Muawiya-contact]

ok