Site management UI

Morning Bell’s authenticated /admin page is the alpha management surface beside the visual editor. It exposes the CMS work that does not naturally belong on a component outline: page lifecycle and SEO, global settings, navigation, form definitions, redirects, submissions, members and roles, domains, audit events, and immutable page versions.

The Pages panel is the guided path. It creates pages from approved Basic, Services, Gallery, and Contact layouts; edits title, slug, navigation label, and SEO description; reorders or duplicates pages; links directly to visual editing; and deletes a page only after the editor chooses a surviving redirect target. The home route is locked. A single confirmed action publishes pages, navigation, and redirects together.

Settings, navigation, forms, and redirects remain structured draft/published resources. The alpha UI intentionally edits their JSON representation so the framework contract can settle before bespoke controls hide it; every save still passes through the relevant Zod parser, optimistic version, guarded command, tenant Durable Object, and audit record. Publishing a resource and restoring a version require explicit confirmation. A polished self-serve builder can layer guided controls over exactly these endpoints.

The public layout reads published settings and navigation. Provisioning initializes all resource families. Public form submissions are validated against the published form definition, restricted to same-origin requests, size-bounded, HMAC-pseudonymized for abuse control, limited per form/subject/time bucket, and stored tenant-locally. Only forms.view can list submission values.

Local development exposes this same Pages panel after the localhost extension handoff. Its in-memory content resets with the Astro server. Other administration panels remain production-only because their membership, audit, domain, and operational data depend on Cloudflare bindings.

Member invitation maps a pre-proven external (issuer, subject) to one explicit site role. It never creates a WiseWig password. Domain requests begin unverified and cannot route public traffic until hosting orchestration proves control and sets verified_at.