One Watchtower,
many islands

The £0 discipline

Oracle's free allowance is 1,500 OCPU-hours + 9,000 GB-hours per month for every tenancy, paid or free: exactly one 2-core / 12 GB ARM machine running continuously. The estate is designed to live inside that line on purpose.

• One account, one VM. Everything Enigma runs fits the Watchtower with headroom; client workloads never land on it, so the free pool is never contended.
• Guardrails, live: a £1 monthly budget with an actual-spend alert at £0.01 and a forecast alert, weekly free-tier audits, and the Capacity Sentinel forecasting ahead of any wall.
• Growth valves, priced in advance: a second VM (~$28/month, minutes from IaC) or a second free tenancy, chosen only when the Sentinel's data says so. Every client island brings its own free tier, so client growth costs Enigma nothing.

Target architecture

Your watchdog question, answered by the diagram: the monitor never lives on the box it watches. Each tenancy's free x86 micro watches the other tenancy, and one external check (Better Stack or UptimeRobot, free) watches both from outside Oracle entirely, so even an Oracle-wide outage still pages you.

Where every gigabyte lives

One free OCI account, carved deliberately. First the whole account, then inside the Watchtower itself, so every moving part is visible against the memory it actually occupies.

Client sites appear nowhere in these maps on purpose: every client's workload lives on their own island, spending their own free tier. The Watchtower's headroom belongs to Enigma alone.

The product, in frames

What the moving parts look like as screens. Mockups, not screenshots: the build targets exactly these.

Watchtower ↔ island · the working relationship

Also queued for frames when we mock the sales page proper: Launch Command's live war room, the connect wizard with its grant switches, the client vault (services + off/read/act dials), the agent registry card, the infrastructure map (these treemaps, live), the machine-surface tile showing what AI read this week, and a daily-brief card as it lands in the client's chat.

Cloudflare as the perimeter

• Tunnels, not open ports. cloudflared runs on every VM and dials out; ports 80/443 are closed at the firewall. There is nothing to port-scan. SSH stays key-only and can later move behind the tunnel too.
• Access = your login layer for free. Team members and client logins to dashboards go through Cloudflare Access (free to 50 users): real SSO, per-app policies, session logs. This is the human-permissions layer you asked about.
• Pages hosts the 3D frontends. The Next.js + Three.js scroll experiences deploy to Cloudflare Pages (free, global, fast) and pull content from WordPress over WPGraphQL, now a canonical WordPress plugin as of WP 7.0. Client sites survive even if a VM is down, because the frontend is on the edge.
• R2 holds the backups that must not die with an Oracle account (10 GB free, pennies after).

AI-era crawl policy (the edge welcomes agents, repels swarms)

• Verified AI crawlers allowed, unverified bots challenged. Cloudflare cryptographically verifies the real answer-engine crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) via AI Crawl Control (free); impersonators and scrapers hit the WAF and rate limits. AI-search visibility and bot-swarm protection are the same policy, not a trade-off.
• Every client site ships AI-legible by default: schema.org structured data, clean semantic content from the WordPress API, and an llms.txt, a provisioner step, not an upsell. Being quotable by answer engines is the new SEO.
• AI referrals are a tracked channel: ChatGPT/Perplexity/Claude traffic appears as its own source in the analytics tiles and Launch Command, next to Google and social.
• The machine surface: every site carries a parallel, edge-served layer made for agents, sitemap.xml, llms.txt, a full markdown content mirror (llms-full.txt), schema.org JSON, and a clean JSON feed of products/offers/events. Regenerated automatically by a Worker on every WordPress publish (the site-bot's index re-syncs from the same event), stored in KV/R2, served from the edge: agent traffic costs the origin nothing and is never stale. SEO and AEO become one pipeline, the same structured feed serves Google's crawler and the answer engines. Foundation, deliberately, for a future agent-actions endpoint (bookings/purchases by agents), which is not built until a client needs it.
• Per-client AI visibility policy as a Dual-Control switch: all verified AI crawlers / search-only / block all, paid course content can stay out of training crawls while remaining in search. Cloudflare's pay-per-crawl pilot is on the watch list as a future revenue line for content-heavy clients.

The hosting plane

• Coolify as the deployment surface. A self-hosted PaaS on the WordPress VM: one-click per-client WordPress containers, automatic SSL, Git-push deploys, a UI your future team can use without me. It is the most mature option in its class and the pattern real agencies now run.
• One container per client, never Multisite. Isolation is the security story: a plugin exploit in one client's site stays in that container. 12 GB runs 8–12 modest client sites.
• WordPress is the content API, not the website. Clients log into the WordPress they know; the design layer is regenerable by AI without ever touching their content. Your custom plugins map content types to scene parameters for the 3D pages.
• The content contract (AI builds the vessel, the CMS owns the words): no baked-in copy, ever. Every visible string, image, and price on an AI-generated page resolves from a CMS field; the client edits in the WordPress they know, publish fires the webhook, the Pages frontend rebuilds and the machine surface re-syncs automatically. The Squarespace feeling — edit content, site updates — with no ceiling, and the reason AI can regenerate the design endlessly (Theme Manager) without ever touching content.
• The LMS is a tenant, not a platform. Tutor LMS (free) inside a WordPress container gets you courses this month; a custom LMS is a rewrite you do only if a client pays for it.

The agent plane

• Agent runtime in Docker, with room for the Hermes instance you mentioned, I need you to tell me exactly what Hermes is (a product? a model? a framework?) before I spec its container.
• Second brain: CouchDB + Obsidian LiveSync gives you real Obsidian on every device, syncing through your own server, the closest thing to "Notion but ours". If the team needs real-time co-editing later, Outline (team wiki) joins it as a separate container rather than replacing it.
• Team workspace: Planka (self-hosted Kanban) behind Cloudflare Access. Team members log in with SSO; no new passwords to manage.
• Hermes profiles and bot mode, governed here: the desktop app's per-profile settings map one-to-one onto Agent Registry entries — each profile becomes a registered identity with its own model, rules, and scoped grants, so governance lives in the registry, not inside the app. The hosted Watchtower instance runs in bot mode permanently (24/7, channel-connected); the desktop app stays the personal cockpit. Each profile can hold its own seat in Buzz channels, honoring agents-as-persons.
• Model choice and spend are settings, not defaults: each agent profile carries its model + effort as registry fields (a dropdown, per agent and per preset button); provider API keys live in the Vault, gateway-mediated. Because inference is the estate's one true meter, every agent gets a spend cap with a locked-on signal when it nears the line.
• Agent gateway pattern. Agents never hold raw credentials. One gateway container mediates every tool call: per-agent identity, per-tool allowlists, full audit log. This is the 2026 standard for multi-user agent estates and it is the guardrail layer for teammates bringing their own agents.
• The Update Steward. A dedicated agent that watches every update surface (Ubuntu security feeds, WordPress core/plugins, WPScan CVE database, Docker image releases, Cloudflare changelogs), reads the IaC dependency graph to compute blast radius, rehearses the update on a cloned container with smoke checks, then proposes, Telegram/Buzz card with severity, staging result, recommendation, rollback plan. Human acceptance before production, always; one pre-agreed standing rule covers actively-exploited critical CVEs (patch now, report immediately after). Executes one product at a time with the watchdog confirming health, auto-revert on failure.

Permissions below the web layer

Cloudflare Access governs humans at the front door. Agents and automation get governed at the cloud layer, and this is the blind spot most self-hosted builds never close:

• Compartments per concern. OCI compartments are free folders with real IAM walls. Client infra, agent infra, and shared network each get one; policies grant access per compartment.
• Scoped automation users. The API key I hold today is tenancy-admin, right for the build phase, wrong forever. Before the first client, I create least-privilege automation users: the backup job can write backups and nothing else; an agent that manages DNS cannot touch compute.
• Secrets live in OCI Vault (free), not in env files on disk. Ironically, the first console page you found is part of the real architecture after all.
• The Ledger (one log for everyone): a single append-only record of every actor's every action — agent runs, human clicks, setting changes, grant uses, deploys, view-as sessions — filterable by actor, tenant, and time. Entries are hash-chained (each sealed against the last, a property borrowed from Buzz's Nostr architecture), so history is tamper-evident: nobody, admin included, can quietly rewrite it. The Agent Registry's run history and the client's vault audit feed are both just slices of the Ledger.
• VM hardening baseline on every instance: automatic security updates, fail2ban, key-only SSH, and a weekly patch window the watchdog verifies.

The layer that makes it a business

• Everything as code. The whole estate, network, VMs, containers, lives in a Git repo (OpenTofu + Compose files). Rebuilding either tenancy from scratch is one command plus a restore, under an hour.
• Backups leave Oracle nightly. Encrypted database dumps and content to Cloudflare R2. Oracle's own 5 free boot-volume backups die with the account; these don't.
• DNS lives at Cloudflare, so pointing every client site at a rebuilt server, on OCI, DigitalOcean, anywhere, is a minutes-long change, invisible to clients.
• Email is a known trap: Oracle blocks outbound port 25, so WordPress password resets and LMS mail silently fail. Every site sends through a transactional email API instead, Brevo (300/day free) or Resend (100/day free), wired in from day one.

What the estate looks like on paper

Worth paying for, when the time comes

• PAYG upgrade on the hosting tenancy, £0 in itself, unlocks capacity, kills idle-reclaim risk. First real client.
• Domains (~£10/yr each), unavoidable, and Cloudflare sells them at cost.
• R2 beyond 10 GB, pennies per month once client media grows.
• A paid VM tier, only when client count outgrows 12 GB; the same Coolify + IaC estate moves onto it unchanged. That's what "future proof" means here: growth changes the hardware, never the architecture.

The client tenancy model

The product above the infrastructure: white-glove service, built so a client could walk away whole, which is exactly why they won't.

One Cloudflare account per client

• Free, unlimited, multi-member. Each client's account holds their zone, tunnel, edge config, and their site-bot's knowledge base (Vectorize + AutoRAG + Workers AI). Enigma Field sits in it as an invited member; our VMs run one cloudflared connector per client account.
• Ownership doctrine: anything truly the client's lives in accounts they could leave with (zone, content, data, bot index, workspace identities). Anything that is our machinery lives in ours (OCI estate, portal, gateway, playbooks). Offboarding is a checklist, not an extraction, portability is the sales pitch, not the risk.

The Enigma Portal (the product)

• Dual-Control Doctrine (first principle): every capability exists three ways, a setting (dashboard switch/policy, e.g. auto-patch thresholds per severity per client), a button (a human does it through the UI), and an agent action that calls the same API the button calls. No agent side-doors; identical audit trail either way. Settings are a WORKING interface: dials, switches, matrices an admin operates, never a bare list, and the same values are the code agents read as their instructions. The security policy panel is the first instance: the Update Steward reads its orders from switches, not briefings.
• One Payload app serves every audience: super-admin sees the fleet, client-admins see their tenant, members see their slice, scoping enforced at the data layer by Payload's field-level access control, not hidden in the UI. Behind Cloudflare Access; per-client provider tokens in OCI Vault; every read audited.
• Roles, humans and agents in the same table: Owner (Nick, exactly one) → Super-Admin (invited builders) → client-admin (their tenant) → member roles per tile (SEO → Search Console + Analytics; social → Mailchimp; commerce → Stripe) → agent identities. Owner-locked, read-only or invisible to super-admins: Vault access policies, billing and budgets, agent standing rules, role-granting caps, gateway root config, and the invariant contract. Builders get full operational power; the security spine and the money stay with the Owner. Enforced at the data layer by Payload access control, same mechanism as client scoping. Team access granted self-serve by the client-admin within caps, or white-glove as a billable service task.
• Agents are persons: every agent/bot has an identity, a role, gateway-held credentials it never sees, an allowlist, and an audit trail. An SEO agent for Client A holds exactly Client A's SEO role.
• Tiles v1: WordPress + Stripe. Then GA4/Search Console (Google OAuth per client), Mailchimp, Calendly, social APIs, "train your agent" (feed documents, inspect answers, review conversations), and the machine surface tile, alongside GA4/Search Console: which verified AI crawlers visited and how often, which pages and feeds they pulled, what the WAF challenged, freshness checks per machine asset (green-tied to the last publish), with AI referrals in the overlay so crawl activity and the traffic it produces read side by side. The cross-tile overlay, post → traffic → sales in one map, is the intelligence clients can't get from their separate consoles. Traffic from social comes free via GA4/Search Console; performance on social needs each platform's API (Meta Graph, TikTok, LinkedIn, YouTube) via OAuth.
• Connect wizard onboarding: a row of provider cards, "Connect" buttons for OAuth platforms (client authorizes on the provider's own page, three clicks, no secrets in their hands, revocable by them) and paste-once fields for key-based tools (Mailchimp, Calendly, Zoom) that write-only into OCI Vault. One-time agency setup: Meta and TikTok app review (free, start before the first client needs it).
• Agent-run, human-visible: preset query buttons ("Today's brief", "Morning traffic report", "What should I do this week?") are productized agent runs over that client's scoped tiles, rendered as cards. The daily brief is push (Buzz/email on schedule), the dashboard is the archive. Insights end in action buttons; the permission table decides which ones a client can fire versus which route to Enigma.
• Signals (the notification rules panel): any metric in the estate can become a ping — a rule is source + condition + channel, written as switches in a working panel, not code. Sales cross a milestone, traffic triples baseline, a launch stalls, a member churns, an agent errors, and above all compute nearing the paid line (free-pool headroom under a set percentage → Telegram AND email, on by default, not removable below warning level). The channel is a rung, not an assumption: each recipient picks where signals land — Telegram, Slack, WhatsApp, Signal, Discord, a Buzz channel, or plain email — because Hermes speaks all of them natively; one rules panel, many doors. Nick's default is Telegram; a client's team might live in Slack and never know the difference. Email remains the locked fallback that outlives every VM. Agents read the same rules — a signal is also an instruction about what matters.
portal.enigma · signals · channel: Telegram ▾

Sale ≥ £500 → Telegram, instantly

Daily revenue milestone crossed → Telegram

Traffic ≥ 3× baseline for 1h → Telegram

Member cancelled → Telegram, named, with history

Free-pool headroom < 15% → Telegram + emaillocked on

Everything else → morning brief digest

Signals · the estate taps you on the shoulder, on your terms

• Who pays doctrine: clients hold free Cloudflare accounts (portability); all compute lives on the Enigma estate; Enigma pays the (near-zero) infrastructure. Margin and white-glove both depend on this. Scale check: ~8–12 containerized WP clients on the current VM, static/headless clients nearly free, first paid capacity rung (~$25–50/mo ARM VM) needed around client 10–12 and covered by any single retainer.

The Estate Map (the flow visualization)

• One seamless flow map per client: outside world → doors (landing pages, campaign links) → rooms (pages, with dwell time) → drop-offs → conversions. Rendered entirely from pipes we already collect: GA4 journeys, Cloudflare edge arrivals, the link registry's UTMs, Stripe/Shopify events. A rendering, not a new data system.
• Toggles: audience layer (humans / AI agents / blocked bots), campaign lens (a single launch becomes Launch Command's flow view), time scrubbing (before/after, launch-day replay).
• Every drop-off is clickable: estate-language explanation (the doors-and-rooms metaphor IS the ELI5 layer) plus an action button where one exists, gated by the role table.
• Renders to a scheduled flow report in the client archive; the daily brief cites it ("the Instagram door doubled this week").

Launch Command (campaign mode)

• A client declares a launch (offer, date, channels); every ad push and post becomes a timestamped annotation on a live timeline. The portal generates the UTM campaign links, so attribution is clean by construction.
• Live funnel, impressions → clicks → sessions → checkouts → revenue, from GA4 realtime + Stripe events. Mid-flight anomaly alerts end in action buttons, gated by the permission table.
• Every launch ends in a retrospective report, automatically: timeline of annotations, funnel results per channel vs benchmark, what outperformed, what underperformed, and concrete recommendations. Reports are archived per client; the next launch's opening brief cites the last report's recommendations. Every launch learns from the previous one by construction.

Fleet view (managing many clients as one)

• The super-admin home is a fleet board: every client as a row, site health, retainer status, open alerts, active launches, resource weight, last steward proposal, sortable by "needs attention". Built for the day there are 15 clients, from the day there is one.
• Onboarding at speed is already structural (WP-22: a login link is the onboarding); the fleet board makes the aftermath of fast onboarding manageable: new tenants surface at the top until their wizard completes and their first health check passes.
• The infrastructure map: a live super-admin view of the physical estate, each VM as a vessel showing RAM/CPU partitioned per container, tunnels, watchdogs, and client islands as their own vessels. Rendered from the OCI and Docker/Coolify APIs the Capacity Sentinel already reads; Sentinel forecasts draw on this map directly.
• Scaling the estate is an IaC edit, not a rebuild: raising a VM's shape, adding a paid VM, or moving a heavy client to dedicated capacity is a one-file change + apply, with the same architecture. The free build and the paid build are the same build.

The Capacity Sentinel (proactive, not reactive)

• An agent that watches trends, not just states: per-container and per-VM RAM/CPU/disk/traffic over rolling weeks, plus per-client bot usage against free-tier caps.
• It forecasts instead of alarming: "at current growth, the WordPress VM reaches 80% memory in ~5 weeks; options: rebalance containers, raise the shape (~$X/mo), or move client Y to dedicated." Heads-up cards land in the fleet board and Telegram before anything degrades.
• Thresholds and forecast horizons are settings in the policy panel (Dual-Control, as always). The watchdogs stay the reactive layer; the Sentinel is the early-warning layer above them.

The Agent Registry (every agent, fully visible, editable)

• A dashboard page listing every agent and bot in the estate as a spec card: identity, what it's connected to, credentials it can request (never see), its operating rules and standing policies, schedule, recent runs, and audit trail. The registry renders from the same gateway config that enforces those rules, the page is the truth, not documentation of it.
• Super-admin: full manual edit of any agent's spec. Client-admin: the simplified surface, toggles, plain-language descriptions, eye-icon explainers, with an "under the hood" mode that technical clients can open to edit their own agents' rules within caps Enigma sets. Editing an agent is changing its config row, which the gateway enforces on the next run; no redeploys, no code.

Component ladders (every layer, lowest sufficient rung wins)

The commerce ladder generalizes: each component is chosen per client, bottom-up. Rung 1 is nearly always Cloudflare/Stripe-native at £0; the top rung is self-hosted heavyweight machinery sold at flagship pricing. Never sell a top rung to a rung-1 client.

Rung admission rule: a tool only earns a rung if it has a robust, scriptable API whose key or OAuth grant we can scope, store in Vault, and hand to the gateway, that is what lets the wizard connect it once and the agents auto-populate tiles, reports, and briefs from it forever. No API, no rung (it can still be connect-only for inherited clients). Cautionary example: WPForms, a good human product with a weak machine API: inherited installs are kept patched and connect-only, never chosen for new builds. An inherited install running on a third party's license is a dependency to record and remedy at handover. A working revenue path is never migrated for taste; sales move to rung 1 (Stripe Checkout) at the next natural change.

• Marketing email / newsletters (transactional mail stays Brevo/Resend, a separate job): (1) Listmonk self-hosted, one light binary + Postgres, ~100MB per client, unlimited subscribers at £0, sends through Brevo SMTP/SES; deliverability discipline (SPF/DKIM, warm-up) becomes our checklist item → (2) Brevo free (300/day, unlimited contacts) for small lists → (3) Beehiiv (free to 2,500 subs) only when the newsletter IS the product, growth network, referrals, paid subs; data exportable so portability holds → (4) Mailchimp connect-only, never a migration target.
• Forms: (1) Workers form handler, £0, no plugin surface → (2) Fluent Forms in the WP container → (3) Typeform/Tally connect-only.
• Scheduling: (1) Calendly free, connected via wizard → (2) WP booking plugin (Amelia) when bookings are the business → (3) self-hosted Cal.com for white-label flagship (~1GB RAM, flagship pricing).
• Analytics: (1) Cloudflare Web Analytics, £0 zero-config → (2) GA4 when ads/funnels demand it → (3) self-hosted Umami for EU/privacy-sensitive clients (also narrows the EU-residency gap).
• Support/chat: (1) the client's site bot → (2) Crisp free for human handoff → (3) self-hosted Chatwoot at flagship scale only (~2GB, same warning class as Medusa).
• Site search: (1) WordPress native → (2) self-hosted Meilisearch for flagship catalogs.
• App data (added 27 Aug): (1) the WordPress/Payload databases already running, most clients need nothing more → (2) Supabase for custom interactive apps, Postgres + auth + realtime as a service (already proven in prior in-house builds); a per-client Supabase account follows the island doctrine → (3) self-hosted Postgres on our VMs when cost/control demands. Existing Supabase estates connect as tiles day one.
• CMS (revised 27 Aug, every client gets a CMS, it's the base offer): (1) WordPress container is the base rung, plugin economy (LMS, WooCommerce), client familiarity → (2) Payload CMS is the flagship rung for fully custom experiences: TypeScript, open source, lives inside the Next.js app, reshapeable React admin, field-level access control as code. Static-on-Pages is not a rung, it is a frontend delivery mode any rung can use (Davide's stage-1 static stays as inherited). Rejected: Strapi (key features paywalled), Directus (revenue-limited license), Ghost (publishing only).
• Payload ↔ WordPress layering (decided): Payload is the agency layer, ONE instance, ours, and the Portal's backend (WP-10 decision made): tenants, the human+agent role table, agent registry, glossary, briefs, link registry, launch records. Each client's WordPress stays the client layer: sole truth for their site content. The seam is the API through the gateway (WPGraphQL/REST), never content duplication, never Payload embedded in WordPress. A small Enigma WP plugin polishes the handshake: SSO into the portal, publish webhooks to the machine surface, health beacon to the fleet board.

Command-centre patterns (adopted from the ARMS guide, Aug 2026)

• Seven principles govern WP-09 and WP-10: one page at one address, always up; show, don't store (dashboards are windows, truth lives in the systems); every widget earns its place or gets deleted; artifacts one click away; the second brain is the centrepiece; start with three widgets and grow one conversation at a time; the skin is per-client, the system underneath is the product.
• Artifacts ring, per client: a searchable "everything made for you" widget, every brief, retro report, and design version. Visible proof of work that justifies the retainer on every login.
• Client-facing second brain view: a visual, searchable map of the client's own knowledge base (content, contacts, docs) as a portal widget, a rendering over the Vectorize/CouchDB data we already hold, not new infrastructure.
• Preset buttons run as headless skills: each preset query ("Today's brief") is a skill fired headlessly (claude -p pattern) on the agent VM through the gateway, with model/effort as options. Button, schedule, and agent all fire the same skill, Dual-Control by construction.
• Router-file memory convention for the agent VM workspace and IaC repo from day one: a master router plus one index file per area, updated in the same turn anything moves. Retrofitting this at 60k files is the documented failure mode; adopting it at zero files is free.

Agency billing (Enigma gets paid inside the product)

• Nick connects the agency's own Stripe once in the super-admin board. Clients are put on retainer subscriptions (Stripe Billing): the client's dashboard shows their plan, invoices, and payment method; the super-admin board shows receivables, payment status per client, and failed-payment dunning for Enigma's own invoices.
• Retainer status can gate service level in the role table (a lapsed retainer downgrades gracefully, visible warning first, never a surprise cutoff mid-launch).

The provisioner (one button spins up a client)

• Super-admin clicks "New client", answers a short form, name, domain, site type (static / WordPress / headless), plan, EU-sensitive yes/no, and the pipeline does the rest: WordPress container via the Coolify API (if applicable), tunnel ingress route, portal tenant + role rows, link-engine subdomain, bot knowledge-base index, Stripe retainer subscription, glossary defaults, and the onboarding login link, emailed automatically.
• The provisioner is itself IaC: the form writes a tenant file to git and applies it, so every tenant's existence is versioned, reproducible, and de-provisionable the same way (off-boarding is the same button in reverse, running the ownership-doctrine handoff checklist).
• Known manual seam, by design: creating the client's own Cloudflare account (no API for account signup). Day one the tenant runs in Enigma's account; the wizard hands the client (or Nick, white-glove) a scripted five-minute account-creation + zone-migration step at contract signing. Tracked as a checklist item on the tenant, never forgotten.

Onboarding doctrine: a login is the whole onboarding

• Onboarding a client = creating their tenant + sending one login link. First sign-in launches a guided walkthrough: connect accounts (the wizard), meet your dashboard, meet your agent, set your team. Every step has the eye-icon explainer; skippable and resumable.
• The portal is their one command center from minute one, every credential, key, and account they need is either connected through the wizard or stored for them behind their login. If onboarding requires a document, a call, or a manual step outside the dashboard, that is a product bug to fix, not a process to accept.

Sales automation recipes (preset, per-client toggles)

• A recipe library wired through Stripe and Shopify (and WooCommerce, same pattern): abandoned-checkout follow-up, new-subscriber welcome sequence, failed-payment dunning, post-purchase upsell, win-back after N days quiet. Each recipe follows the Dual-Control Doctrine: a toggle in the client's dashboard, a manual run button, and an agent that executes it through the same API, with the recipe's sends going through the client's connected email/SMS provider, never a side channel.
• The Access Loop (flagship recipe): access follows payment. A Stripe subscription event grants or revokes every connected door at once: Zoom registration (unique join links), Telegram membership (via an Enigma-built bot that issues single-use invites and removes on revoke: an agent identity with exactly two powers), Mailchimp tags, LMS enrollment. Runs on a Cloudflare Worker (free, no VM in the loop); the identity spine resolves who-is-who across payment email vs signup email. The owner keeps the decision layer: a message naming who left, the churn numbers, the why. Tile view: per-member door status, mismatch queue, event log, manual grant/revoke beside the automation. Acceptance: cancel a test subscription and watch every door close within minutes, with the owner notified.
• Recipes are versioned agency IP; a client's specific tuning (copy, timing, discounts) is client-specific configuration under the standard licensing terms.

The link engine (short links as managed inventory)

• Self-hosted short-linker (Dub open-source or a Workers + KV build) on the client's own subdomain (go.clientdomain.com), on-brand, portable with the client per the ownership doctrine, click data owned by us not Bitly. A Bitly integration remains possible as a tile but is not the spine.
• The registry is the source of truth. Every link records: destination, campaign, channel, creation date, creator (human or agent), and every placement (which post, ad, email, or page it was injected into). Categorized and filterable in the dashboard.
• Lifecycle hygiene is enforced, not hoped for: links are created only through the registry (portal button or agent via the same API); deleting a campaign archives its links and lists every placement needing cleanup; a weekly sweeper agent verifies every active destination and flags 404s/redirect drift. No stale-link graveyard, ever.

The Hormozi metrics layer

• LTV, CAC, and ratio on every client home tile, scored against benchmarks (3:1 pure digital, 6:1+ human-delivered), numbers arrive with verdicts.
• Client-financed acquisition as the launch KPI: 30-day gross profit > 2× (CAC + COGS), scored automatically by Launch Command.
• Core Four attribution on every lead (warm outreach / content / cold outreach / paid ads); speed-to-lead as a live metric with a 60-second alert.
• Super-admin sees all metrics cross-portfolio, the anonymized pattern-learning the contract claims. Full FireCrawl + NotebookLM research pass before this layer is built, per playbook doctrine.

Communications: Buzz (piloted, not promised)

• Block's open-source Slack rival (Apache-2.0, self-hostable, Nostr-based): client teams and their AI agents share channels as equal members; identities are user-owned keys, extending the portability doctrine to conversations.
• Pre-1.0. Sequence: our team runs it on the agent VM first; per-client workspaces only when it stabilizes. We are the guinea pig, never a client.

Client islands: bring any infrastructure (the default hosting model)

• The infrastructure ladder (decided 28 Aug): the non-negotiable is the Enigma-standard island: a fresh account provisioned from our IaC with tunnels, guardrails, and invariant-contract coverage: OCI by default (best free tier), same pattern on any provider. Full white-glove guarantees attach only to standard islands.
• Brought infrastructure is a rung, not a refusal. A client's existing DigitalOcean droplet or server connects through the wizard (SSH key or provider token into Vault): monitored, visible in their dashboard, deployable-to if it passes a health audit: but marked inherited, best-effort, with a migration path to a standard island at the next natural change. Their segregated backends port INTO the one command center either way; the ladder just decides what we can promise on top of them.
• Every client hosts on their own account from client #1 (Davide). The Watchtower stays pure Enigma machinery, client workloads never land on it, which removes the ~10-client ceiling entirely: every client brings their own free tier. A wizard connect card links the client's own OCI tenancy: the wizard guides creation of a least-privilege enigma-operator IAM user in their tenancy (never their root key); that scoped key lands in Vault, revocable by them in one click, audited on both sides.
• Their island runs our standard machinery, same IaC, Coolify pattern, tunnel into their own Cloudflare account. To the portal, fleet board, watchdogs, and Update Steward it is just another tenant row; the API-first architecture does not care whose cloud a container runs on.
• Departure becomes a non-event: remove the operator key, server, site, data, and domain were theirs all along. The ownership doctrine completed at the compute layer.
• Guardrails install with the key: the operator key's first act on a new island is installing the same kit we run, budget + spend alerts (to client and Enigma), weekly free-tier audit, Sentinel trend monitoring. Their dashboard then tells them when to scale, on the island or any ladder component, turning scaling moments into quoted upgrades instead of surprises.
• Scaling bonus: each island brings its own free tier (2 OCPU/12GB ARM), so island clients consume none of the Enigma VM budget. Account signup and payment verification stay client-performed (wizard-scripted); everything after the operator key exists is automated.

The mobile layer (deferred build, day-one architecture)

• The mechanism, decided: member portal and client apps are React web apps with Capacitor as the store path, one codebase → web, PWA, App Store, Play Store. (Quasar was evaluated 27 Aug: excellent, but it is Vue wrapped around this same Capacitor engine, adopting it would split a React estate into two frameworks. Same capability, no split.) Expo is the named alternative if a flagship ever needs native-first. A prior in-house app validated the product behaviors (live toggles, view-as) but is not the model.
• Mobile-ready constraints baked in now, built later: API-first (the app is just another API client); auth designed for webviews from the first login screen (OAuth redirect + deep-link handling); push notifications as one abstraction (web push / native push, same interface); every portal route deep-linkable so app links and web links are the same links.
• Ladder: (1) PWA, installable, push-capable, £0, every client day one → (2) Capacitor native shells when store presence is wanted → (3) Expo native for flagship only.
• Feature-flag matrix in the admin: products/modules × surfaces (web/app) × tiers as switches, stored in Payload, read at runtime, flipping a switch changes every member's app now, no store re-release.
• Live device-frame preview in the admin renders the member app with current flags applied; view-as works inside the frame.
• View-as (portal-wide): any admin, scoped by role, opens a registered user's portal exactly as they see it, read-only, visible "Viewing as" banner, audited. The behavior is proven in a prior in-house build; the implementation is fresh.

The membership layer (every site gets members)

• Base rung: WordPress's native user system IS the membership database, proven, and every LMS/membership/commerce plugin builds on it. We add Google OAuth + passwordless email login (Nextend Social Login), a "My Account" member portal (my courses, purchases, subscriptions via deep link to Stripe's hosted customer portal, cards never touch our stack, newsletter preferences), and the LMS enrolling against the same accounts. Flagship rung: Payload's built-in auth.
• The identity spine: one member record per human per client, stitching WordPress account ↔ Stripe customer ↔ newsletter subscriber ↔ LMS enrollments ↔ contact card. Gateway sync jobs keep it stitched on events (purchase → account + enrollment; unsubscribe → card update).
• Admin member tile: search any customer, see everything they are to the business, bought, subscribed, enrolled, emailed, one view, agent-queryable ("who bought X but never logged in?").

The client vault: connect once, grant by switch

• Every client credential (OAuth grants, pasted keys) lands in their own vault partition through the wizard: all their APIs in one governed place.
• Enigma holds grants, never keys. The super-admin sees a client's vault as connected services with switches, not secrets. Each credential carries a grant level per role: off / read / act: for Enigma ops and for individual agents. The gateway enforces the switches; nothing else can read the vault.
• Client-governed, live: raising or revoking a grant is instant, no re-onboarding. White-glove default: onboarding grants the standard working bundle; the toggles exist for clients who want the dial.
• Every use visible: the client's dashboard shows an audit feed of which grant was used, by whom or which agent, when. Transparency is what makes "leave everything connected" comfortable.

Contacts into the client's second brain

• A light CRM whose cards live in the client's own knowledge base: customers, vendors, leads, partners. Cards are auto-created and auto-enriched from operations, a Stripe customer, a Calendly booking, a form submission, a support thread each add to the card, so the record grows without data entry.
• Their site/workspace agent reads these cards: "what do we know about vendor X", "who bought the last launch but not this one". Lives in the client's lane (their account, their data, walks with them), readable by Enigma under the contract like everything else.

The explain-it-simply layer (the eye icon)

• Every metric, technical term, and setting carries a hover icon: a plain-language explanation a non-technical owner understands, plus one line on what it connects to ("changing this affects X; it is fed by Y"). No external research required to operate the dashboard.
• Content ships from a maintained glossary (agency IP), one entry per term, agent-drafted and human-reviewed. The dashboard teaches its own users over time, that is part of the product's value, not decoration.

Client zero: The Enigma Field itself

• Enigma's own sales landing page ships on the platform's own pattern: 3D scroll frontend on Cloudflare Pages (the site IS the demo of what Enigma sells), content from the Payload instance on the Watchtower, machine surface and Estate Map running on it from day one. Every feature demo a prospect sees is the live product operating on Enigma itself.

Client #1: Davide

• His static site (davide-lavina.pages.dev + domain) currently lives in the Enigma Field Cloudflare account. Onboarding him properly means standing up his own free Cloudflare account and moving his zone + Pages project into it, the first real execution of the ownership doctrine, done while stakes are low.
• His live site is never the guinea pig (the August brief's rule, written about him): dashboard access, tiles, and his bot arrive around the site; the site itself changes only when the pattern is proven on demo tenants.
• He is the EU-residency flag made concrete: Luxembourg, EU clients. His site staying static-on-Cloudflare sidesteps it today; any future WordPress/CMS for him triggers the EU hosting conversation before data lands in Ashburn.
• His onboarding is the acceptance test for WP-22 run against reality: login link → wizard → connected dashboard, no questions needed. Where he stalls, the wizard gets fixed.

Custom client services (the extension point)

• Any client can grow bespoke endpoints: stateless compute as a Worker in their account (island doctrine, £0), stateful services as containers on their island. Their site's components attach via the content contract; their dashboard gets a custom tile reading the same API (usage, results, errors, free-tier headroom).
• Real-time management is Dual-Control: the service's settings live as config the dashboard edits and the service reads per request — flip a switch, the live widget changes, no redeploy; agents adjust the same config under their grants; the Ledger records all of it.
• Priced by the IP doctrine: custom services are client-specific builds — licensed while a client, named buyout on departure. First candidate on file: Davide's astrology service (current planets + birth charts), pending his own evaluation card and sealed V1 boundary.

Frame of reference: the Wix and Squarespace AI wave

• Wix shipped Harmony (Jan 2026): vibe-coding plus visual editing with an AI agent, atop Astro, its dashboard assistant. The category is validated by the biggest builder on earth; clients will arrive already believing "AI edits my site" is normal.
• The structural difference: their AI edits their renderer, content sits in their collections, hosting is theirs, and leaving means rebuilding. The Enigma content contract delivers the same experience on an open substrate: content in standard WordPress, frontend in git on Cloudflare, everything walks with the client.
• Their agent operates the website; ours operate the business. The site is one tile in a command center that also runs payments, email, access doors, launches, and the Ledger. The close Wix cannot say: you own every piece, and you can leave whenever you want — which is why you won't.

Data & IP doctrine (contract language, not vibes)

• Agency IP: machinery, patterns, playbooks, agent architecture, licensed as service, never transferred.
• Client property: their data, content, trained bot knowledge, workspace identities, theirs from day one.
• Client-specific agent configurations: licensed while a client, named buyout price on departure.
• Learning: the agency learns from anonymized, aggregated patterns across the portfolio, claimed explicitly in the contract. Raw client data is never training data by default; that line is a sales asset.

Inherited from the August research

Nick's 13 Aug research thread and its audited distillation (the Tech-stack selection brief in the Enigma Library) were reviewed against this design on 27 Aug. The verdicts:

Already agreeing, now confirmed as doctrine

• The layer picker survives intact: Cloudflare on everything, WordPress as the content brain with custom front ends (never page builders), LMS from a proven plugin (never custom-first, budget $200–300/yr for a mature one), headless deferred until CMS content must drive the 3D pages, AI layer outside WordPress reading the REST API. Commerce upgraded (27 Aug) to a per-client ladder, lowest sufficient rung wins: (1) Stripe Checkout/Payment Links + Workers for digital products, subscriptions, and services, the default; (2) Snipcart for static sites with small catalogs; (3) WooCommerce for WP-centric clients; (4) Medusa for flagship headless stores (its own Node + Postgres + Redis stack, ~1–1.5GB RAM per client, flagship-tier pricing only); (5) Shopify connected via API when a client already lives there, never migrated. Total cost including fees remains the judging rule.
• IaC was already the brief's non-negotiable for self-hosting, and "text-first so any coding agent can operate it" is exactly why. OCI free replaces the brief's $11–17/mo DigitalOcean lane with the same architecture at £0.
• The hardening lesson is paid for: A previously managed self-hosted WordPress estate was taken down by a bot swarm. The brief's answer was proxy-only origin; this design goes further, no open ports at all, tunnels only.

New obligations this blueprint now carries

• The Theme Manager plugin from the wishlist is the centerpiece of the AI-design story: design versions live in git (v1 Original, v2 Ethereal, …), activation is a pointer flip, rollback is free, and the plugin is just a switcher UI over versions git already keeps. This becomes the first custom plugin we build.
• The full wishlist is the acceptance test: LMS with student accounts/progress/certificates; one-source-of-truth CMS (create once → website, member library, course, dashboard, email, app); memberships and tiered access; digital products and payments. Every layer above already seats these.
• Never make a live client site the guinea pig. Davide's static Pages site stays untouched; the OCI estate is the parallel build, and any client cuts over only when the hardened pattern is proven. Same rule for every migration after him.

Security posture: the audit

An adversarial pass over the whole design (28 Aug). Strong by construction: sealed ports, container isolation, one credential-holder, grants-not-keys, the hash-chained Ledger, off-cloud backups, least-privilege island keys, invariant checkers. The audit added seven upgrades, now part of the spec:

1. MFA everywhere it matters: OCI console accounts carry account-level MFA; Cloudflare Access requires MFA for Owner and super-admin surfaces, hardware security keys recommended for the Owner.
2. Step-up authentication: vault grant changes, Owner-locked settings, de-provisioning, and restores demand fresh re-auth in the moment — a stolen session can look, never touch.
3. No static secrets on disk: the Watchtower reaches OCI Vault via instance principals (the VM's own identity); there is no credential file to steal.
4. Ransomware-resistant backups: the R2 token is write-and-list only — a compromised Watchtower can add history, never read or erase it — plus object versioning.
5. Rotation as routine: operator keys, API keys, tunnel credentials on a 90-day cycle, Steward-proposed, inventory visible in the registry. The build-phase tenancy-admin key is demoted to scoped automation users before the first client.
6. Security signals locked on: failed admin logins, new-device sign-ins, grant changes, and agent permission edits join the un-removable signal set.
7. No secrets in any frontend, enforced: browsers hold only their Access session; keys live in Vault, read only by the gateway. The deploy pipeline scans every built frontend bundle for key patterns and refuses to ship on a match — a checker, not a habit.
8. Injection-proof by construction: raw SQL is a code-review rejection — every data path uses parameterized engines (Payload's ORM, WordPress prepared statements); plugin-land is watched by the Steward + WPScan; Cloudflare's WAF managed rules filter injection patterns at the edge as depth.
9. The break-glass runbook: written, rehearsed procedures for Access lockout, key compromise (rotate everything via IaC in one command), and a Cloudflare outage. Enterprise-grade means the bad day is rehearsed, not improvised.

The honest ceiling stands: patterns and discipline are enterprise-level; contractual guarantees (SLA, indemnity) remain what £0 cannot buy. Everything above is enforced by the invariant contract, not by memory.

One system, top to bottom

Every part above assembles into a single stack. Read it bottom-up; each layer only talks to its neighbors through the stated interface, which is why any component is a swappable rung and the whole is not a patchwork.

Environments: side-tree to main (Enigma and client infra alike)

• Frontends: Cloudflare Pages preview deployments, every branch gets its own URL automatically, free; promotion is the merge to main.
• Watchtower stack (portal, gateway, agents): Coolify staging instance per branch, separate container + staging DB, own subdomain behind Access (team-only, crawler-invisible), ephemeral: spun up per branch, torn down at merge.
• Client islands: staging clone of the client's site on their own VM behind Access; build in the clone, smoke-check, client approves on the staging URL, promote. Code forks, content doesn't: themes/plugins/config promote through git (the Theme Manager pattern); live content (orders, members, posts) is never forked, staging reads a sanitized copy.
• Contract invariant: nothing reaches main or a live client site without passing through a side build and its acceptance check, enforced by the pipeline refusing direct-to-main, not by discipline.

The five spines that make it one system rather than parts: (1) everything is an API and every surface, button, schedule, agent, calls the same one; (2) one permission table governs every human and agent; (3) one IaC repo declares every resource on every cloud, so any of it can be rebuilt from git; (4) one invariant contract that every change is reviewed against; (5) one ownership rule, client things live in client-portable accounts, agency things in ours. A component that honors the five spines can be swapped without touching its neighbors; that is the difference between a stack and a Frankenstein.

Execution spec, the work packages

Written so a competent worker can execute without needing the reasoning above: each package states what it produces, what must exist first, the guardrails that must not be violated while building it, and the check that proves it done. Build in dependency order; packages with the same dependencies can run in parallel.

The invariant contract: every guardrail below compiles into a living INVARIANTS.md in the IaC repo, named invariants with enforcement mappings, each mapped to its enforcing mechanism: no agent side-doors (gateway is the only credential holder), links exist only via the registry, client-owned data lives in client-portable accounts, £0 spend (budget + billing watcher), nothing ships without its acceptance check. Changes are reviewed against the contract (IBR invariant review); every checker is self-tested against the incident that motivated it; violations surface as healing-loop proposals under Owner acceptance. The contract is Owner-locked in the portal. This is a standalone build inside the Enigma estate: the contract lives in the Enigma IaC repo, its checkers run on the Watchtower, its proposals surface in the Enigma portal — the discipline is inherited from proven prior systems, the machinery shares nothing with them and depends on nothing outside this estate.

Standing rules that apply to every package: build on proven, supported open source rather than from scratch, custom code is reserved for what is Enigma-specific, and a component with an active community beats a component we must maintain alone; nothing ships without its acceptance check passing; every capability lands as API-first (buttons and agents are both callers); every credential lives in Vault behind the gateway; every change to infrastructure goes through the IaC repo; anything client-owned lands in a client-portable account.

Decisions I need from you

1. Lane, DECIDED (27 Aug): Lane B. Upgrade this account to Pay As You Go with a £1 budget, spend alerts, a 48-hour billing watch on the second VM, and a weekly free-tier audit. Alerts route via Hermes → Telegram (primary) with Oracle email as the independent fallback.
2. Hermes, IDENTIFIED: Nous Research's Hermes Agent (MIT, self-hostable via Docker). Runs on tq-agents on free models for basic automation; inference credits are the one metered cost to watch.
3. Which domain and Cloudflare account front the platform? (theenigmafield's Cloudflare already exists, use it, or a fresh one for hosting?)
4. Second brain flavor: Obsidian-first (LiveSync, personal, matches your current workflow) or team-wiki-first (Outline)? Both is fine too, they're just two containers.
5. Go order (revised 28 Aug, portal-first per Nick): WP-02 tunnels + close ports → WP-03 Coolify on the watchtower → WP-10 Portal v1: the super-admin login is the next visible deliverable → WP-05 IaC + backups → WP-07 Hermes + Telegram → WP-04 watchdogs → product tiles in spec order. Client hosting begins on Davide's island, not the watchtower.