Every feature in 0xCMS

• "Lect" structured content — every page's body is a JSON document with a defined shape: localized fields, scalar attributes (@), page-reference pointers (*), repeatable items, reusable blocks (_blocks), and tags (_tags). Metadata like _type, _modifier, and _pointers live alongside.
• Blueprint-driven schema — page types are declared as blueprints (a mix of field strings and nested item maps); the editor form, search paths, and CSV headers are all derived from the same blueprint.
• Built-in multilingual support — default language set (mis, en, zh-hant, zh-hans) with per-field localized values; language is chosen per request and threaded through save/reload. A Languages admin manages locales, fallback order and content/UI enablement, while Translations stores per-locale UI overrides; the complete admin shell and profile language selector use those runtime translations.
• 21 field types rendered from Liquid snippets: text, textarea, richtext, number, boolean, switch, checkbox, radio, select, date, time, color, email, tel, url, link, page (page-reference combobox), picture, file (private media uploads), range (labelled discrete scales), and rating (keyboard-accessible stars).
• Markdown rich-text mode — the richtext/md field keeps a visual rich-text surface, Markdown source and submitted HTML synchronized. It is now the default body field for pages and blocks, with translated mode controls and recovery for legacy double-escaped HTML.
• Translation-aware field chrome — shared text, email, number, textarea, picture, select, and switch snippets can resolve labels, placeholders, blank labels, and select options from i18n keys, with plain-text fallbacks for existing blueprints.
• Page-reference fields — a searchable combobox backed by a JSON API to link one page to another (by type, filtered by name/slug).
• Page hierarchy — pages can have a parent (page_id), forming trees; parent options are searchable.
• Scheduling window & timezone — every page carries optional start/end timestamps with a timezone (UTC offset or IANA name; default configurable via DEFAULT_TIMEZONE).
• Weight ordering — manual sort weight per page, editable inline and via a batch endpoint; client-rendered item groups also offer drag handles that update their ordinary weight inputs before save.
• Legacy-format normalization — older "structured" JSON shapes are auto-migrated to the current lect model on read.
• Lect merge semantics — blueprint defaults ← stored content ← incoming partial, so API callers and importers can send only the fields they changed.

• Structured editor UI — a Tailwind + vanilla-JS admin form that renders each blueprint field, item list, and block list, with an inline HTML toolbar for rich text.
• Full page CRUD — create (blank or create_by_type), edit, update, and soft-delete, with slug auto-generation and guaranteed-unique slugs.
• In-editor structured actions — add/remove/reorder items and blocks without leaving the page (server applies the structured action and re-renders).
• Server-side validation re-renders the form with a 422 and error list while preserving entered values.
• Plugin edit views — a plugin can take over the entire edit/new form for the page types it owns; the CMS POSTs the editor context to the plugin and wraps the returned HTML fragment in admin chrome. Its form posts back to the normal CMS save handler, so versioning/publish are unchanged.
• Graceful fallback — if a plugin edit view returns 404 or any error, the built-in editor is used, so a half-built plugin can never lock an editor out of a page.
• Native-editor escape hatch — append ?native=1 (or ?editor=cms) to force the built-in editor for a page a plugin would otherwise render; the flag survives validation errors and post-save reloads.
• Return-path preservation — the editor remembers where you came from (e.g. a plugin dashboard) across saves, so Back/Cancel still point there.
• Read-only page view — /pages/:id/read renders the same structured content as static text (no inputs, no CRDT, no presence), safe for reviewing a page without any risk of accidental edits; a plugin that owns the page type can render this view too, with the same ?native=1 fallback.
• Privacy table view — page types with email/phone/mobile/fax fields get a privacy-aware list rendering with client-side masking for sensitive contact columns.
• Modifier attribution — the last editor's name is resolved and shown.

• Version on every save — each create/update mints a new page_versions row; draft_pages.current_page_version_id points to the active one. The action (create/update/publish/revert/restore) is recorded.
• Version history panel — the editor lists the 20 most-recent versions with timestamp and action.
• Version preview — open any past version read-only (?version=…) and diff it against the current draft.
• Revert / restore — roll a page back to any prior version; the revert itself becomes a new version (append-only history).
• Live-version indicator — the editor marks which stored version currently matches what's published.
• History survives trash — version rows and tag links move to trash with the page and come back intact on restore (ids preserved).
• Plugin & API writes are versioned too — every write-back API create/update/delete mints a version and fires the matching lifecycle hook, exactly like the admin editor.
• Custom version actions — an API update can record its own action label in the history (e.g. a plugin's domain action like checked-in), not just a generic update.
• Delete versions — remove a single version, or clean a page's entire history at once (both confirmation-gated); the current-version pointer is retargeted to the latest remaining version.
• Timezone-aware history — version timestamps are formatted in the configured default timezone, not raw UTC.

• Durable Object per page (PageSyncDO) coordinates concurrent editors over WebSocket, so a team never silently overwrites each other's work.
• CRDT overlay model — a live overlay of uncommitted edits sits on top of the last-saved page. Ops are stored per (field, user), so one editor's edits can be dropped independently of another's.
• Last-write-wins by HLC — each field's effective value is the op with the highest hybrid logical clock across users.
• Leave-without-saving recovery — when an editor disconnects without saving, their uncommitted edits are dropped and each affected field falls back to the next editor's value, or the saved baseline.
• Save commits the overlay — saving clears uncommitted ops and pushes the saved values as everyone's new baseline (a save-then-leave never reverts).
• Field-level presence highlights — transient focus/blur signals show which field each collaborator is currently in (relayed, never stored).
• Presence roster with heartbeat — a presence API tracks who's on a page (name, avatar, last-seen/last-active), with stale entries auto-expired after 10 minutes.
• Multi-tab safe — a user's ops persist while any of their connections (e.g. a second tab) remain open.

• Adapter-based publish targets — one publish builds a single page snapshot (row + denormalized tag links) and fans it out to every configured target; unpublish and delete remove it from all targets the same way.
• Draft ↔ published separation — drafts live in the private CMS database; publishing writes to a separate published database a public reader Worker can be given in isolation (no access to users, sessions, drafts, or trash).
• Built-in d1 target — upserts live_pages/live_page_tags by uuid; unpublish deletes both.
• Built-in r2 target — writes static JSON: pages/<uuid>.json (full snapshot, lect parsed) plus a rolling index.json listing of all live pages.
• Plugin publish targets — any plugin whose manifest declares publishTarget: true auto-receives publish/unpublish/tag-removal snapshots over three POST endpoints (IPFS pinning, webhooks, search indexes, static rebuilds).
• Awaited fan-out with partial-failure reporting — publish targets are awaited; per-target failures are logged and surfaced in the editor flash ("published, but these targets failed: …") without blocking the ones that succeeded.
• Publish-status badges — the dashboard reads live state from the first read-capable target and shows draft/live status per page.
• Pull published → draft — bring a live page back into drafts for editing (creates a draft if none exists).
• Unpublish & publish-on-save — publish directly from the dashboard, or with the publish action inside a save.
• Plugin auto-republish — plugin-owned page types listed in manifest autoPublishTypes automatically republish on ordinary saves once they are already live; first publish remains an explicit editor action.

• Taxonomies — named groupings (years, categories, topics, collections, …) managed in their own admin (gated by taxonomy:write).
• Tags — terms within a taxonomy, with localized names, slugs, and optional parent-tag nesting (gated by tag:write).
• Many-to-many page↔tag links — tags attach to draft pages and travel with them through publish, trash, and restore.
• Inline tag assignment API — add/remove a page's tags via JSON endpoints (bumps the page's updated_at).
• Tag pickers in the editor and in advanced search, grouped by taxonomy.
• Tag weights & batch reorder — manual sort weight per tag, with a batch reorder endpoint so a whole taxonomy can be resequenced in one call.
• Slug-keyed taxonomies — tags reference their taxonomy by slug (migration-safe renames); plugin-defined taxonomies appear in the tag admin alongside built-in ones.

• Advanced multi-criterion search — combine any number of criteria with AND, OR, or NOT operators.
• Blueprint-aware field paths — search a specific field inside the lect JSON (including wildcard item paths like items[*].name), auto-populated from each page type's blueprint.
• Tag filters per criterion — require pages carrying all selected tags (grouped by taxonomy).
• Chinese search variants — a term automatically also matches its Simplified/Traditional equivalents.
• Scoped or global — search all page types or a single type; sortable by id/name/slug/weight/created/updated, asc or desc, with pagination.
• SQLite JSON querying — path specs compile to safe, parameterized json_extract/json_each SQL.
• Quick search box on the dashboard redirects into the advanced-search form.
• Queued bulk actions — publish, unpublish, or delete either selected search results or the full filtered result set; the work is queued as an admin job instead of timing out in the request.

• Private R2 uploads — picture fields upload to a private R2 bucket (never public); the Worker gates every read at /media/<key> behind a valid session.
• Upload validation — files are checked by magic-byte header sniffing and content type, with distinct 413 (too large) / 415 (unsupported) errors.
• Safe, collision-free keys — sanitized filename + date-partitioned path (dir/YYYY/M/D/) + a random UUID prefix.
• Media metadata table records key, URL, filename, content type, and size for every upload; uploads are audit-logged.
• On-the-fly thumbnails — /media-preview/<key> uses the Cloudflare Images binding to create cached 100×100-cover WebP previews directly from private R2 objects, retaining media security headers. It safely serves the original when the binding or object is unavailable, the file is not an image or is oversized, or decoding fails.
• Rate-limited & permissioned — uploads require media:upload and are throttled per IP.

• Dedicated import-export plugin — CSV tooling now lives in a plugin rather than the CMS core, keeping format-specific UI and workflow independently deployable.
• Content metadata endpoint — GET /__cms/content-meta supplies scoped page types, languages, taxonomies and blueprint-derived path specs for headers and mapping.
• Bulk target resolution — list pages by up to 500 ids or slugs, with JSON-array binds that stay under D1’s parameter limit.
• Tag ensuring — POST /__cms/tags/ensure creates or resolves tags by taxonomy and name for a batch import.
• Atomic batch creation — import plugins use the same single/batch create path as other Plugin API callers, including scope checks, quotas, credits, version history and hooks.

• Database-defined page types — create/edit/delete page types at runtime (gated by pagetype:write): a slug, name, blueprint (JSON), optional block lists and taxonomy lists, and a weight. No redeploy to add a content type.
• Database-defined block types — reusable block definitions with their own field blueprints (gated by blocktype:write).
• Unified type admin — page and block types share one CRUD route factory and reusable list/form views, while retaining the correct per-type controls and copy.
• Effective config merge — code defaults, database-defined types, and plugin-contributed types are merged into one live editor config (cached per isolate).
• Plugin-contributed types are visible — page/block types a plugin registers appear read-only in the admin, badged with the contributing plugin's name.
• Available-classes helper — an admin snippet surfaces the Tailwind class set available to plugin/admin fragments.

• Soft delete — deleting a page copies it (with version history and tag links) into trash, preserving ids so a later restore keeps the same identity, and unpublishes it from every target.
• Trash browser — paginated list with a per-type filter dropdown, a full type-count breakdown, and a "trashed in the last hour" counter.
• Restore to draft — restore a single page (re-linking its parent if the parent still exists), bringing back version history and tags; legacy trash rows get a fresh restore snapshot.
• Bulk restore — restore all, by type, or only the last hour, set-based so an event's worth of pages restores without timing out (gated by trash:restore).
• Permanent delete / empty trash — purge a single row, or empty all / by type / last-hour only (gated by trash:purge).
• Audited — restore and purge actions write to the audit log.

• OAuth 2.1 login with PKCE (S256 code challenge) across five providers: GitHub, Google, Microsoft/Entra, Apple, and self-hosted Eventuai. The login page shows one button per provider in ENABLED_PROVIDERS order.
• Provider abstraction handles per-provider quirks: Microsoft tenant selection (common/organizations/consumers/tenant id), Apple form_post response mode, and ID-token vs. userinfo-endpoint identity sourcing.
• Apple ID-token verification — verifies the RS256 signature against Apple's published JWK selected by kid, then checks issuer, audience (client id), expiry, and the OAuth nonce before trusting identity claims.
• Stateless PKCE flow — the state + code verifier + chosen provider ride in a signed, 10-minute oauth_state JWT cookie (__Host- prefixed, SameSite=None on secure origins), so there is no server-side session store during login.
• Dual-JWT sessions: short-lived 15-minute access token + rotatable 7-day refresh token, both HS256-signed with the Web Crypto API and stored as httpOnly cookies.
• Refresh-token revocation — refresh JTIs are hashed (SHA-256) and stored in the sessions table; logout and rotation delete them, so tokens can be invalidated server-side.
• Silent token refresh via POST /auth/refresh (JSON) with refresh-token rotation; admin pages keep the session alive with a keepalive.
• Session hygiene — concurrent sessions per user are capped and expired session rows are purged opportunistically (via waitUntil, off the response path).
• Multi-provider account linking — link additional providers to one CMS account from the profile page or /auth/start?provider=…&link=1; it will not silently merge logged-out accounts by matching email.
• Identity table (user_oauth_identities) maps many provider identities to one user, with a legacy oauth_id fallback for un-backfilled databases.
• Optional registration allowlist — ALLOWED_EMAIL_DOMAINS restricts who can create a new account; existing linked users always pass so a config change can't lock anyone out.
• First-login role provisioning — the IdP-supplied role seeds a new account once; later logins refresh profile fields but never overwrite the CMS role, so admin role edits stick.
• Rate-limited credential endpoints — /auth/start, /auth/callback, and /auth/refresh are throttled per IP.
• Weak-secret guard — the Worker refuses to serve (outside localhost) if JWT_SECRET is missing or under 32 chars, so no one can forge admin tokens.

• Capability-based authorization — routes require a specific permission (e.g. content:publish), not just "is an editor". A user's effective permissions are the union over every role they hold (roles are a comma-separated list).
• Four built-in roles with a least-privilege matrix: admin (everything, never lockable), editor (full content lifecycle, taxonomy, media, import — no purge/plugins), moderator (publish, soft-delete, restore only), and viewer (no admin access; blocked from /admin by the editor guard).
• 18 granular permissions: content:read/write/publish/delete/import, trash:restore/purge, tag:write, taxonomy:write, media:upload, plugin:access/manage, menu:manage, pagetype:write, blocktype:write, users:manage, roles:manage, and credits:share.
• Bounded role delegation — custom roles remain editable, but a delegated role or user manager can only modify and assign authority that is a subset of their own. admin remains all-powerful and immutable, preventing both privilege escalation and lockout.
• Database-backed permission resolution layered over code defaults, cached per-isolate with a 60-second TTL.
• User management (gated by users:manage) — list users, view linked identities, and assign roles.
• Plugin-contributed permissions — a plugin can declare namespaced permissions (e.g. events:manage) that appear in the Roles admin for granting to custom roles.

Each plugin is a separate Cloudflare Worker reached over HTTPS at {url}/__plugin/…. The CMS validates and caches its bounded manifest, then forwards signed-in user context plus that registration's dedicated secret on outbound calls. A plugin can add nine things:

• Lifecycle hooks — run on page create / update / publish / unpublish / delete (webhooks, external indexing, cache purge, notifications). Hooks are best-effort and never block the editor.
• Content types — register new blueprints / blocks / block-lists / taxonomy-lists that merge into the editor config.
• Fields & blocks — register new pagefield types and serve their Liquid snippets, rendered through the CMS editor.
• Edit views — render the whole edit/new form for owned page types (see §02).
• Admin routes + nav — add an admin page proxied at /admin/plugins/<id>/… with a nav entry; a nav item can nest under the Settings group and restrict itself by role.
• Publish targets — declare publishTarget: true to receive publish snapshots (see §05).
• Save-time auto-publish rules — declare autoPublishTypes for owned page types that should republish automatically after an already-live page is edited.
• Quota limits — declare admin-configurable caps on how many pages of a type may exist (see §16).
• Credit costs — declare chargeable actions billed against user credit balances (see §16).

// registry & safety

• Runtime registration (no redeploy) — register/enable/disable/configure plugins by URL in a management admin (gated by plugin:manage), stored in a plugins table. Manifests are auto-discovered and cached.
• Per-plugin secrets — each registration gets its own generated secret, so one plugin can be rotated or revoked without touching others. The environment PLUGIN_SECRET is outbound-only legacy compatibility; `/__cms` never accepts it in place of a row secret.
• Copyable Worker setup values — the plugin form exposes the registration secret plus tenant KV key/value details with localized copy feedback, so operators can configure a plugin Worker without transcribing credentials.
• Bounded manifests — malformed identities and structures are rejected, prototype-mutating keys are ignored during config/content normalization, and manifest bodies are capped at 256 KiB.
• Tenant-aware plugin calls — hook and publish-target requests include x-cms-tenant when CANONICAL_ORIGIN is configured, so multi-tenant plugins can route CMS-originated work correctly.
• Admin proxy — plugin admin pages are proxied under the CMS origin, wrapped in admin chrome, under the strict nonce CSP (gated by plugin:access). Full-document plugin responses may opt into same-origin iframing.
• SSRF literal guard — plugin URLs with obvious private, loopback, link-local (including cloud metadata 169.254.169.254), CGNAT, or .internal literal hosts are rejected. This is not a complete DNS-rebinding defense, so registration remains privileged.
• Approved static assets — a plugin can ship JS/CSS to run inside CMS chrome (e.g. a camera scanner), but an admin must explicitly approve each path, pinning its SRI (sha384) content hash, before it survives sanitization.
• Delegated page-type access — a companion plugin can request readTypes/writeTypes for page types it doesn't own; an admin must approve each delegated scope before the CMS honors it. A scope may be the wildcard *, which (once approved) grants access to every page type.
• Versioned plugin view files — plugin view/asset files are served with immutable, revision-keyed caching.
• Explicit trust boundary — proxied plugin pages and approved plugin JS execute on the CMS origin. Install only audited plugins and approve the minimum assets and delegated scopes required.
• Inert when unused — with no plugins configured, the system adds no overhead.

A reverse, server-to-server channel (authenticated by the per-plugin secret, outside the browser auth stack) so guest-facing flows on a plugin's own domain — public RSVP submit, QR check-in, bulk contact import — can read and write the CMS pages they own or are delegated.

• Scoped reads & writes — a caller identifies itself via x-plugin-id; writes are limited to its manifest page types plus admin-approved writeTypes, reads also reach approved readTypes.
• List / read pages — paginated listing by type with name/slug/lect search (Chinese variants included), parent filter, and lect-pointer filters (single or multi-value IN).
• Large lookup-safe reads — direct ids/slugs lookups and include_tags=1 lists use JSON-array binds, supporting up to 500 values without exceeding D1’s 100-parameter limit.
• Advanced search endpoint — POST /pages/search accepts the same multi-criterion semantics as the admin advanced search (AND/OR/NOT operators, blueprint field paths, tag filters, Chinese variants), scoped to the caller's readable types, up to 500 results per page.
• Create & batch-create — single create and bulk creation up to 100 pages share one path for validation, ID/parent resolution, quotas, credits, DB writes and hooks; batches preserve all-or-nothing limits/credit semantics while reporting per-item errors.
• Partial update — PUT/PATCH merge only the fields sent (blueprint ← stored ← incoming), re-version, and commit the live overlay; an update may label its version with a custom action string.
• Batch update — PATCH /pages/batch applies up to 100 partial lect updates in one transaction, reports malformed/duplicate/forbidden rows by input index, and preserves version history plus update hooks for every valid page.
• Batch publish — POST /pages/publish publishes up to 100 draft page IDs through the standard target pipeline, enforcing the caller's page-type scope, rejecting invalid or duplicate IDs, reporting per-item target failures, and emitting publish hooks.
• Credit & quota aware — priced page types are charged before insert (insufficient balance returns 402 with the cost breakdown; failed inserts refund automatically) and quota limits are enforced on every create, single or bulk (see §16).
• Server-side bulk clone — duplicate a related collection (e.g. an event's guests) by lect pointer or parent id, with a uniform lect transform (drop keys, merge overrides), processed in bounded chunks that return a resume cursor so arbitrarily large lists clone across several requests.
• Server-side bulk delete — soft-delete a related collection (by pointer or parent), and batch-delete by id list, both chunked and cursor-resumable.
• Versioned, audited, observable — every create/update/delete mints a page version, writes an audit row attributed to plugin:<id>, and fires lifecycle hooks to other plugins.
• Subrequest-budget aware — batch sizes and per-call caps are tuned to stay within Workers' free-plan subrequest limits.

Meter or monetize what plugins let users do. A plugin's manifest declares chargeable actions and quota limits, an admin configures the prices and caps, and the host enforces them on every page-create path — the admin editor and the write-back API alike, so neither door can be used to sidestep the other.

• Per-user balances & append-only ledger — every user carries a credit balance; every change appends a credit_ledger row (delta, balance-after, action, entity, plugin, note, actor), so the ledger always explains the balance.
• Manifest-declared costs — page_create costs are charged automatically by the host whenever a page of that type is created; metered costs are reported by the plugin via POST /__cms/credits/charge for actions the host can't observe (e.g. sending an EDM); recurring costs create tracked subscriptions charged monthly in advance or arrears by scheduled Worker sweeps.
• Admin-configured pricing — a Plugins → Credits screen prices each declared cost (0 = explicitly free); unconfigured costs fall back to the manifest default. If several plugins price the same page type, the effective cost is the sum.
• Overdraft-proof by construction — the ledger INSERT and balance UPDATE share a credits ≥ amount guard and run in one D1 batch (a transaction), so concurrent spends can never take a balance below zero; success is verified via RETURNING.
• 402 with cost breakdown, automatic refunds — insufficient balance rejects the create with the priced parts itemized; if a charged operation fails downstream, the charge is refunded best-effort as its own ledger row.
• Admin grants & deductions — users:manage can adjust any balance with a mandatory note, audit-logged; the profile page shows a paginated ledger and the sidebar shows your live balance.
• Configurable quota limits — a plugin declares caps on how many pages of a type may exist, scoped total, per-parent, or per-pointer (e.g. guests per event); an admin sets the value or marks it explicitly unlimited.
• Credit and limit summary — every signed-in admin can inspect effective plugin prices and usage limits at /admin/settings/credits; only plugin managers see configuration links.
• Plugin-visible usage, subscriptions & quotes — GET /__cms/limits, GET /__cms/credits, GET /__cms/credits/quote, and the subscription/usage endpoints let plugin UIs show quota usage, recurring status, effective pricing, balances, and affordability before starting long jobs.
• Bulk-safe enforcement — a bulk create or import that would breach a quota is rejected whole, never half-applied; violations return a human-readable message pointing at the limit.
• Scope-gated declarations — a plugin can only price or cap page types it owns or has been delegated (admin-approved); declarations are validated, deduped, and capped at 20 per plugin, so a hostile manifest can't block or bill another plugin's content.

• Liquid-templated admin UI — server-rendered sections/templates served from a dedicated views binding, with compiled Tailwind CSS and small vanilla-JS enhancements (table filter, color tags, privacy table, client render).
• Dashboard — paginated page list with All / Draft / Live status filters, per-type sub-lists (/pages/list/:type), live publish badges, quick search, and import/export shortcuts.
• Color labels — an inline picker assigns a color (red / orange / yellow / green / blue / purple / gray, or none) to a page, written to a page lect attribute. It's a lightweight visual marker — unrelated to taxonomy tags — that drives at-a-glance row color-coding and client-side filtering on the dashboard.
• Flash messages carried through redirects for every action's outcome.
• Profile page — view your account, linked identities, and start additional provider links.
• Settings-grouped navigation — plugin nav items and admin sections can nest under a Settings group.
• Session keepalive keeps admin sessions warm while you work.
• Auto-hiding mobile header — the admin header collapses as you scroll on small screens, giving content the full viewport.
• Sidebar credit balance — your live credit balance shows in the sidebar (see §16).
• Configurable branding — the app name and icon come from System settings (see §18), shown in the sidebar and on the login page; per-type titled views.
• Dashboard brand link — the configured site title and icon in both desktop and mobile admin navigation link directly to /admin.
• Custom 404 & 500 pages rendered from the views layer.

• App branding — rename the admin app and pick its icon at runtime; both show in the sidebar and on the login page. White-label the CMS per deployment without a redeploy.
• Sidebar menu manager — show/hide and re-weight every built-in nav item and every plugin nav item, including the weight of the Settings group itself; the System entry is always kept visible so you can never hide your way out of settings (anti-lockout).
• Configurable admin home — point the post-login landing at any /admin path (e.g. a plugin's dashboard) instead of the page list.
• Key-value settings store — a single upsert-semantics settings table backs branding, menu layout, admin home, plugin credit prices, and plugin quota values.

• Strict CSP with per-request nonces — default-src 'self', nonce-gated scripts, base-uri 'none', object-src 'none', frame-ancestors 'none'; a route can opt into wasm-unsafe-eval (e.g. the zxing camera scanner) or same-origin framing.
• Security headers on every response — HSTS (preload, 1 year), X-Content-Type-Options: nosniff, Referrer-Policy: same-origin, and X-Frame-Options: DENY by default.
• Fail-closed cross-origin mutation guard — non-safe methods are rejected unless a browser signal (Origin, Referer, or Sec-Fetch-Site: same-origin) positively proves same-origin; headerless clients must send a matching Origin. The /__cms secret-authenticated channel is exempted deliberately.
• Canonical host enforcement — requests to non-canonical hosts get a 308 redirect (GET/HEAD) or 404 (mutations), preventing host-confusion.
• Locked-down Permissions-Policy — camera/microphone/geolocation denied by default; opt-in per route.
• No-store on sensitive paths — /admin, /auth, and server-to-server /__cms responses set Cache-Control: no-store.
• Privilege-escalation resistance — delegated role and user managers cannot grant, assign, edit, or delete roles more powerful than their own effective permissions.
• Single-use admin submit tokens — signed per-form _cms_once tokens are atomically claimed by sharded Durable Objects to stop duplicate POSTs without D1 contention; claims are released after downstream failures so a legitimate retry still works.
• Plugin fragment sanitization — proxied plugin HTML runs under the strict nonce CSP and is sanitized; inline scripts are stripped unless delivered as approved, hash-pinned assets. Full-document plugin pages use a separate baseline CSP; loopback HTTP images are allowed only when the CMS document itself is served from localhost or 127.0.0.1.
• Per-IP rate limiting on auth and upload endpoints (Workers Rate Limiting bindings).
• Audit log — sensitive actions (import, media upload, restore, purge, plugin writes) record who did what to which entity.
• Private-by-default data separation — public readers can be given only the published database, with zero access to auth, sessions, drafts, or trash.

• 100% edge-native — a single Cloudflare Worker (Hono router), no origin servers and no databases to babysit.
• Two D1 databases — a private CMS store (auth, sessions, drafts, trash, taxonomy, versions, media metadata, roles, plugins, jobs, approvals, settings, credit ledger) and a separate published store (live_pages/live_page_tags).
• R2 object storage — a private media bucket, plus an optional static-JSON publish bucket.
• Durable Objects — per-page WebSocket coordinators with SQLite storage for CRDT ops and presence, plus sharded coordinators for single-use admin form-token claims.
• Sequentially consistent D1 sessions — every request, queue job and scheduled task starts on the primary, so later reads observe earlier writes while D1 may safely use sufficiently current replicas.
• Cloudflare Queues — a CMS-owned queue for durable background admin jobs.
• Versioned migrations — checked-in SQL migrations for both databases (auth identities, admin jobs, plugin asset approvals, plugin page-type approvals, settings, tag weights & taxonomy slugs, credits), with a local one-command migrate script.
• Deploy-revision awareness — view assets are cache-busted by the Worker version metadata (or a manual fallback), so a new deploy invalidates cached CSS/JS.
• Web Crypto everywhere — JWT signing/verification and token hashing use the platform crypto API, no Node dependencies.

• Durable admin jobs — long-running admin actions (e.g. large plugin duplicate/delete requests) are enqueued on a queue and processed by a job runner, tracked in an admin_jobs table, so they survive request timeouts.
• Off-response-path hygiene — session capping/purging and hook/audit delivery run via waitUntil so they never slow the user's request.
• Chunked, resumable bulk operations — clone/delete/restore of large collections, plus advanced-search bulk publish/unpublish/delete, are batched or queued with cursors/jobs to stay within platform limits.
• Best-effort, non-blocking integrations — lifecycle hooks and audit writes are fire-and-forget; publish targets are awaited but fail independently.