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.

On WiseWig-managed hosting, page reads and lifecycle commands go through the trusted hostname dispatcher and execute in that tenant’s user Worker. The Worker reloads all three draft resources, checks their optimistic versions, applies the schema-driven mutation, and commits pages, navigation, and redirects in one tenant-local SQLite transaction. Deletion requires the exact delete confirmation; bundle publication requires content.publish plus the exact publish confirmation. The browser-facing Astro Worker has no direct tenant Durable Object binding in the managed deployment profile.

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. In managed hosting, Astro computes the pseudonymous subject and sends only the fixed form ID, values, and hash through the hostname dispatcher; the tenant Worker supplies the platform-selected site ID. The form request cannot select a tenant, site, or workspace. 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.

The legacy hosted-deployment/provider panel is hidden in the managed customer-site profile. Provider deployment and support-grant effects belong in a separately authenticated operator/platform application; the customer Astro Worker deliberately has no HOSTING_DEPLOYER or shared D1 binding. Self-hosted adapters may continue to expose their own implementation.

The visual overlay offers developer-approved themes to users with theme.switch. Selecting one requests a server migration preview. Appearance-only releases preserve every slot; layout releases list the content-bearing slots that need discard decisions and the optional or required slots that can be initialized. A confirmed switch changes only the draft and reloads the server-rendered page; publication remains separate.

Managed dispatch coverage includes visual section/structure editing, structured site resources, page lifecycle/publication, theme preview/switch, public form submission, tenant-isolated media upload/list/delivery/deletion, the complete sandboxed-plugin lifecycle, immutable version browsing/restore, audit browsing, form-submission reads, members, domains, and tenant operations. Sensitive reads use separate fixed operations with exact permissions; submission values are never returned by a generic content search or viewer grant. For plugin installation, the trusted dispatcher—not Astro or the tenant Worker—verifies the agency-trusted signature and digest, installs the immutable artifact through its sandbox service binding, and grants one exact tenant commit.

Managed operational usage, backups, checksum verification, retention maintenance, and point-in-time recovery run tenant-locally. The same screen merges those results with D1-owned tenant status, operational events, and platform-command audit. Confirmed status and erasure requests use the dispatcher’s separate D1 ledger; Astro holds neither a tenant Durable Object namespace nor authority to mutate shared platform tables directly.

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.