# Cloudflare development and production promotion The development Site is a separate Cloudflare Worker deployment managed by Sites, with project-scoped D1 provisioning and its own runtime configuration. It is not a resource created inside a verified company-owned Cloudflare account. The original review Site is preserved. No domain or Cloudflare subscription was purchased by this work. ## Build here 1. Open the development project using its native source workflow and current repository credential. Do not open the original review Site for new development edits. 2. Keep `deployment/environments.m2m.json` and `lib/deployment-policy.ts` aligned. The founder's local Zora must remain offline. The canonical adapter throws before any network call; supplying gateway secrets cannot enable it. 3. Install the checked-in lockfile. Run `node --experimental-strip-types scripts/check-development-policy.mjs`, `node --experimental-strip-types scripts/check-space-privacy.mjs`, and `node node_modules/typescript/bin/tsc --noEmit`. 4. Use synthetic data. The new Site gets its own database from its `DB` declaration; do not export development records from another environment into it. Append Drizzle migrations and review SQL; previously applied migrations are immutable. 5. Configure a cloud-only AI service separately if desired and authorized. No AI credential is configured by this release. The existing direct cloud provider adapter is independent of local Zora, but must pass public-scope, data handling, cost and response tests before use. Never hide the unavailable state or call an authored tour live intelligence. 6. Publish private development revisions through the Sites source/build/deploy workflow. Preserve owner-only audience. Record source commit and successful deployment receipt. A cloud publish does not deploy the bundled Python reference runtime; its state machine must be integrated into a separately provisioned company service or ported and retested for Workers. ## Prepare and promote a release 1. Freeze a tested development source commit. Record exact lockfile and migration hashes, test evidence, capability claims and remaining gates. 2. Provision a separate production project/database and production identity. Keep names, secrets, callback origins, provider budgets, webhook destinations and allowed audiences separate. The proposed production project ID is intentionally unset until it actually exists. 3. Review the complete Meet Zora flow in the development environment: first visit, truthful AI availability, optional account, memory consent, export, clear history, deletion, reviewed feedback, company action approval and ZoraTrade paper workflow. Cloud integration tests must cover the deployed implementation, not just the Python reference. 4. Create a production release candidate from the exact reviewed source. Change only explicit environment configuration. Do not copy the development `.openai/hosting.json` project identity into production; preserve the target project's identity. Never copy `.env`, runtime state, founder archives or development users. 5. Obtain the release authority decision for this candidate and applicable business gates. Paid services and live trading require their own verified authority and provider configuration. Family/game expansion is not required for the first product launch. 6. Inspect migrations against a production-like database snapshot with synthetic or lawfully controlled data. Use expand/contract changes; do not rely on an application rollback to reverse a destructive database change. Record independently retained recovery evidence and deletion tombstones. 7. Deploy the candidate privately first where feasible; verify actual production identities, boundaries, cost limits and provider receipts. Record a last-known-good application version and database recovery procedure. Broaden access or attach the public company domain only through the reviewed release decision. 8. Observe the release. Halt consequential automation on integrity/scope failure. Revert the application to its verified predecessor when safe. Database recovery must preserve deletion records and reconcile external effects. For a company-owned Cloudflare account, obtain authorized account access first and review the Sites-specific authentication dispatch integration. A raw Wrangler upload alone does not replace that identity boundary. Map the same application code to separate named environments with distinct D1 IDs and secrets; maintain the same acceptance gates. Current official Cloudflare documentation supports separate environment bindings and D1 databases; this design uses project separation under the managed hosting route. Sources checked 26 September 2026: - https://developers.cloudflare.com/d1/configuration/environments/ - https://developers.cloudflare.com/workers/wrangler/environments/ ## Consented visitor request intake When a signed-in visitor checks the separate consent box, the site writes the visitor-owned request and a company queue projection in one D1 batch. The projection contains a random row ID, an opaque digest for idempotency, the approved category and summary, `awaiting_review` state, and timestamp. It contains no account ID, name, profile or conversation. The request is not automatically assessed and no outbound follow-up is configured. Deleting the visitor's saved space removes that visitor's active request records and the matching company projection in the same batch. The site exposes no company reviewer API or staff dashboard. Queue rows await a separately authenticated company workflow. This deployment therefore demonstrates consented intake into the company's queue, not completed support, an assessment decision, or an action by Zora Prime. ## Published environment addresses - Development (private): https://zora-one-dev.bjorn-campbe-6257.chatgpt.site - Staging (private): https://zora-one-staging.bjorn-campbe-6257.chatgpt.site - Current reviewed company site: https://zora-one-vision.bjorn-campbe-6257.chatgpt.site Development and staging are separate managed Sites projects. Each has its own D1 binding and currently provisioned application tables. No visitor records were copied between them. Staging is configured to accept future release candidates; no production promotion has occurred. The accessible managed Sites provider is not evidence that the Founder’s separately owned Cloudflare dashboard/account is connected.