# Optional business admin

Only prepare an admin when requested or when the operator opts in with site creation `--admin`. Continue the website's prepare → CURRENT → work → complete workflow and verified local-preview stop. Admin rollout does not bypass website consent or release gates.

Read the installed harness's `docs/ADMIN.md` and the published admin's packaged `agent/WORKFLOW.md`, `agent/refs/harness.md`, and `agent/refs/cloudflare.md`. Use the pinned **1.0.0** release. Run `vitris admin setup --site WEBSITE --dir SIBLING_ADMIN --domain admin.customer-domain.com --website HTTPS_SITE_ORIGIN --tenant EXISTING_TENANT_ID --backend-origin HTTPS_BACKEND --plan`. Review `artifacts/admin/setup-plan.json`, then repeat with `--apply` and a dedicated environment `VITRIS_ADMIN_API_TOKEN`. Reuse the published installer; never reproduce it or silently overwrite an installation.

Setup is local scaffolding and public connection metadata only. Preserve forms, origins, tenants, existing accounts/records, authored source and workflow progress. Never infer compatibility from scaffolding: an older deployed backend needs its own reviewed API upgrade. `vitris admin status` is local metadata; `vitris admin verify --site WEBSITE --dir ADMIN` checks deployed identity and authoritative reads with the dedicated credential, without printing records. Failures must remain visible, with no demo fallback.

Default scopes: leads:read and analytics:read. Add --lead-write to both setup commands only for explicit lead status/follow-up write authorization. Prepare a complete hashed grant map with `vitris admin grant`; preserve unrelated grants. Store only SHA-256 in backend ADMIN_CONNECTIONS, and upload the raw token to the admin as HARNESS_API_TOKEN through secret stdin. Never commit configuration or credentials.

Prepare explicit, separate customer-account provisioning, D1 migrations, owner bootstrap, Cloudflare Email Service onboarding, authentication, DNS/TLS and deployment steps. Never deploy/migrate a shared backend as a side effect. Sites without collection need an explicitly provisioned backend and separately reviewed form/analytics activation; they have no historical data to import. Production demo login is forbidden. Test submissions and notification captures remain isolated and read-only; preview traffic is excluded from analytics. Clearly label synthetic fixtures and stub services. Pages, Media, page builders and arbitrary HTML editing remain outside scope.

Admin 1.0.0 includes shared interface typography, website color handoff, lead follow-up, account lifecycle and optional operational modules. Existing installations require a reviewed package/UI/schema diff; installing the package does not deploy either application. Read the packaged leads.md and accounts.md. Follow-up needs the compatible website backend API and its separate 0006_admin_lead_followups.sql migration, while standalone admins use 0010_lead_followups.sql. Never infer live booking, mail delivery or payment activation from a stable package version.