Frontends — Cloudflare Pages
I keep the public spectacle, full system website, customer onboarding, admin command interface, proof vault, fit check, live tour, and founder notes as static HTML/CSS/JS. No server-side rendering. No framework build step.
Each surface connects to its assigned Worker API only where persistence or review is required. Static pages teach and route; Workers carry state and security.
8 Cloudflare Workers — ES module format
Admin automation Worker (brain routing, D1 receipt logging), SaaS provisioning Worker (signup, Stripe billing, workspace isolation), 0meg4kAI security gateway Worker (two-layer scan, quarantine logging), CROWN operating ledger Worker, NEXUS CRM Worker, QUANTUM task ledger Worker, site operator Worker, sentinel audit Worker.
I deploy the Workers under separate routes with scoped D1 bindings. Each Worker only touches the databases assigned to its job.
8 D1 SQL databases
Admin receipts D1, security scan events D1, SaaS customer records D1, CROWN operating ledger D1, NEXUS CRM records D1, QUANTUM task ledger D1, site operator events D1, sentinel audit trail D1.
D1 is Cloudflare's edge-native SQLite. Queries run close to the user. I keep the record stores scoped by function so proof, audit, CRM, task, and customer records do not collapse into one messy bucket.
SkyeGateFS27 auth platform
I use SkyeGateFS27 for all /admin/* authentication: Bearer token introspection, role/scope validation, and allowlist enforcement. Cloudflare Access wraps every admin-scoped Worker endpoint as a second lock.
Customer workspace auth and owner admin auth are separate token systems. A valid customer token cannot reach the admin Worker layer because the scopes are structurally incompatible.
Integrations — Resend and Stripe
Resend handles transactional approval email — fires when a hard gate triggers, routes to the operator's configured admin email with the staged action payload and a confirm/reject link. Stripe handles SaaS billing — plan selection, subscription provisioning, and recurring invoice generation inside the SaaS Worker.
Both are private integrations in the backend layer. Public buyers only need to know that approval notices and billing routes can be deployed; the setup details stay in implementation.
Cloudflare KV and Queues
KV stores fast-read configuration, brain routing tables, and session state that needs sub-millisecond access. Cloudflare Queues handle asynchronous work items — tasks that need to be processed outside the synchronous request cycle without a separate queue infrastructure.
Both primitives are optional layer components. The core system runs on Workers and D1; KV and Queues add throughput and async capability at scale.
16 local brain files — JSON and markdown
Each of the 16 brains has a JSON persona definition and a markdown doctrine file. The persona file carries routing keywords, domain scope boundaries, hard gate flags, and approval escalation paths. The doctrine file carries company context, operating standards, and brain-specific decision logic.
The brain layer runs deterministic keyword classification — not LLM inference on every command. LLM providers can be wired in as optional connectors behind private server-side Workers for enhanced language understanding, but the routing logic is local and does not depend on an active model provider.