# Launch (optional)

For a separately requested business admin at `admin.customer-domain.com`, read `admin.md` and the installed harness's `docs/ADMIN.md`. Use `vitris admin setup --plan` and reviewed `--apply`; verify the actual deployed backend with `vitris admin verify`. Local scaffolding does not enable collection/authentication or deploy infrastructure. Keep the sibling admin's Cloudflare provisioning and release separate from website publication.

Only when the operator asks after `preview_ready`. Rebuild and validate assets locally, then upload the exact staged bundle directly to Cloudflare Pages. GitHub stores source and history; hosted deployment automation is opt-in.

1. Commit authored source and the lockfile to the customer's private repository when requested. Keep `dist/`, `agent/release-bundles/`, `agent/release-candidate.json`, `agent/releases/`, captures and credentials out of Git.
2. Authenticate with the operator's own `npx wrangler login` and confirm the account. For a new site create a Pages Direct Upload project with `npx wrangler pages project create PROJECT`. Set `launch.json.pagesProject` and the real production `launch.json.publicOrigin`. Run `npm run deploy:preview` and accept the hosted preview; run `npm run deploy` only for explicit production publication. Ordinary deployment uses quick publish: rebuild, stage the exact files, upload, record their identity and check the hosted URL. Initial website creation retains its full local-preview gates. Do not restart that workflow or run verify/preflight solely for a routine publish request. Preservation sites support temporary previews only.
3. For existing Git-connected Pages projects, disable automatic production and preview branch deployments before local uploads. Review and disable existing automatic GitHub deployment workflows as well. Preserve project names, domains, launch configuration, authored files and workflow progress. Installing or upgrading the harness does not migrate package scripts or remote settings. See the installed harness's `docs/CLOUDFLARE.md`.
4. Backend tenant registration, contact forms, administration sign-in, custom domains and DNS are separate configured features. If publishing through the authenticated backend Worker, retain the exact verified bundle signing and attestation contract and review that path before migration. Direct Pages uploads do not provision tenants or forms.
5. Hosted automation is opt-in. `deployment/github-actions.yml.example` is inactive until an operator chooses and installs it under `.github/workflows/` with protected secrets. Cloudflare Git builds are another optional alternative. Enable one publication path per site; the legacy hosted and signed-Worker examples retain their explicitly configured full preflight contract. Do not migrate existing hosted automation as a side effect of a routine publication.

Do not merge secrets into git. Use `.env` for Cloudflare tokens.

Quick publish is the default: `vitris deploy --environment production` (`npm run deploy` in newly scaffolded sites). It rebuilds and deploys without browser, graph or launch review gates. Compilation, asset validation, Cloudflare credentials, staged-file integrity and an HTTP smoke check still run. Receipts record build-only verification. Preservation sites use `--environment preview` and also skip screenshot comparisons. For a requested comprehensive publication review, use `vitris deploy --full-review --environment production` or `npm run deploy:full`; Chromium is required for browser checks. `--quick` and `deploy:quick` remain compatibility aliases for the default. Never mark skipped reviews passed.