⚙️ Technical architecture

I built it on the edge so the business does not need a server room.

I use static frontends on Cloudflare Pages, eight ES-module Workers for command routing and state, eight D1 SQL databases for queryable records, SkyeGateFS27 for auth, Resend for approval email, Stripe for billing, KV for fast configuration, and Queues for async work. The stack stays boring where it should be and powerful where it has to be. ⚡

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.

SkyeGateFS27 proof surface screenshot

🔌 What I am proving here

The stack is not a slide. It is wired to live surfaces.

When I say SkyeGateFS27 handles auth and platform events, I link the proof surface. When I say Cloudflare Workers are live, I test them in browser. When I say D1 holds receipts, I keep that boundary in the architecture instead of hiding it in sales language.

Builder note

I chose primitives I can deploy for clients.

I can launch the public site, protected command deck, proof records, approval route, and client workspace layer without making the buyer learn the setup stack first.

⚙️ Stack summary

I keep it static where it should be, Worker-backed where it must be, and private when it controls power.

What this page covers

I built the stack on Cloudflare Pages, 8 named backend surfaces, scoped D1 records, SkyeGateFS27 access, approval email, billing routes, Cloudflare KV and Queues, and 16 local brain files with persona definitions and doctrine. I let buyers evaluate the architecture without receiving the implementation checklist.

What stays private

Access setup, private backend configuration, exact database wiring, secret values, admin-scoped endpoints, and the full 28-lesson admin tutorial content. I handle those during deployment and hand off the live system without turning the public site into a setup manual.