Client Docker Template
The one thing every paying client gets a copy of. Each client lives on their own self-contained Docker stack: WordPress, MariaDB, a Python AI agent, and a Traefik router. We run the infrastructure. They run their business.
Executive summary
The Client Docker Template is the pristine recipe every paying coach is cloned from. One Docker Compose stack per client, isolated by database, volume and network. Inside the stack sit four core services — WordPress, MariaDB, the Python AI agent, and Traefik — plus the white-labelled Fluent suite and roughly two dozen must-use plugins that handle branding, audit, agent routing and security.
The template lives on the shared Hetzner host gg-client-template (178.105.123.133). Demo.guidancegate.com runs there today as the canonical reference. The reference is built, sanitised, monitored, and a clone tool exists and has been tested.
What is locked
- One Docker Compose stack per client on a shared host (ratified R2, Paul 2026-05-17).
- Stack composition: WordPress + MySQL/MariaDB + Python FastAPI agent + Traefik.
- Each coach gets their own AI assistant on their own stack — not one shared engine with personas (supersedes earlier proposal).
- Provisioning is an N8N-orchestrated clone of the pristine template, not a from-scratch build. Booking hashes and automation IDs survive (ratified D9, Paul 2026-05-17).
- Client owns their data. All client business data lives in the client’s own MariaDB — never in GG central Postgres (ratified D7, Paul 2026-05-17).
- MariaDB is the database target. Live demo is still MySQL 8.0.46 pending staging-proven migration (ratified D2, Paul 2026-05-17).
- Every trial is a full per-client stack for 30 days (ratified D12, Paul 2026-05-17).
What is open
14 questions and 9 drifts between Canon and RMM-reality. The biggest is the multi-tenant Compose blocker: container_name and host-port collisions mean no second stack can stand up alongside Sarah Johnson’s on gg-client-template until the shared Traefik refactor is executed. That is the only thing blocking clone 1 going live and the same thing blocking Seth.
The template is the production line. Every future client is a Xerox of it. Get it wrong here and the mistake replicates 30 times. Get it right and provisioning becomes an N8N button. This brief is the joint reference point so Sam and Paul are looking at the same picture before the next sign-off.
North star principles that govern the template
Seven principles — lifted verbatim from brief #42 and the canon principles file — constrain every choice on the template. They are not negotiable for this build.
Client operates, we run the infrastructure
The client posts, edits, and sends. GG handles servers, DNS, SSL, backups, and security. The client never sees a terminal.
Client owns their data
All client business data lives on the client’s own Docker stack — their WordPress install, their MySQL database, their gg_client_fields table. Export is available any time, no questions asked. Retention comes from genuine value, not from lock-in.
White-label everything
The client sees their own brand and “GuidanceGate Business Platform.” They never see WordPress, Fluent, or any vendor name. All Fluent plugins are rebranded.
Boring bedrock, smart application layer
WordPress, Linux, Apache, and MySQL are the stable foundation. The AI agent layer is deliberately replaceable. If Anthropic disappears, the client’s site still works.
Open and scriptable beats closed and visual
Every tool and interface must be drivable end-to-end by AI. This rules out Divi, Elementor, and any proprietary binary format.
Single source of truth, queryable by AI
Each client’s gg_client_fields table is the single source of truth for that client’s business data. GG’s central Postgres holds fleet and ops only.
Every system debuggable by Claude unattended
Structured logs, health endpoints, and AI-readable error messages are mandatory. The bar is: Claude should be able to diagnose any issue at 3am with nobody online.
We dogfood
GG runs the same stack it sells. Sam’s Rhythm Mastery Method drum business is the first real client on the new stack. The demo.gg deployment (running as Sarah Johnson Coaching) is the active dogfood deployment.
The deployed demo.gg Docker stack is ground truth for what currently exists. On a factual question about current state, the built and deployed evidence wins (ratified R5, Paul 2026-05-17). Brain decisions are the source of truth for what GG intends. Recency rule: on conflict, the later decision or build supersedes the earlier one.
Architecture — per-client server model
Each client gets one Docker Compose stack on the shared gg-client-template Hetzner host (cx23, 2 vCPU / 4 GB / 40 GB). All client stacks share the host; inter-client isolation is provided by Docker — separate databases, volumes and networks per client. They cannot see each other’s data.
The four core services in every stack
| Service | What it is | Today’s reality |
|---|---|---|
| wordpress | Apache + PHP 8.3. The client’s website, admin interface and every coach-facing UI surface. | Live on demo.gg. |
| db | MariaDB 11 LTS is the ratified target. MySQL 8.0.46 is the deployed reality. The client’s own database; business data never leaves this container. | Deployed as MySQL 8.0.46. Migration to MariaDB tracked — must be proven on staging first (D2). |
| agent | Python / FastAPI on port 8000 internal. The client’s persistent AI partner. Not Claude Code CLI. Not a WordPress plugin. Skills are markdown files in the container. | Live on demo.gg as the docker-agent image. 11 skills loaded. |
| traefik | TLS termination and subdomain routing. Currently co-located in the per-client compose; the target is a shared platform Traefik in front of all stacks. | Co-located today — this is the multi-tenant blocker (see Section 9). |
The data architecture
Three tables matter on the client’s own MariaDB:
- gg_client_fields — the key-value store managed by the gg-client-fields mu-plugin. All 251 business fields for a coaching practice live here. The bot reads and writes through gg_field() / gg_field_set() helpers. This is the single source of truth for that client’s business data.
- gg_activity_log — logs logins, post edits, bot interactions, field writes by actor, action_type, timestamp and context. Queryable by Sage Shepherd when composing emails, and by the coach if they want to see what the bot did.
- agent_threads / agent_messages / agent_audit / agent_pending — four tables created by the Python agent for chat history, tool use, and the staged-confirm pattern. Audit logs redact sensitive fields.
The central GG Postgres on gg-staff holds fleet and ops data only: heartbeats, status pings, brain_sync messages. It never holds client business data. NocoDB on gg-staff is an internal ops read-only UI for Paul and Sam — it is not in the client data path and not installed on any client stack.
The heartbeat
Each client’s stack pushes a daily status row to the central Postgres: client_id, current_stage, tasks_done_this_week, last_login, last_activity_timestamp, stuck_flag, active_batch, pipeline_count. That is the entire payload — status only, no business data. Sage Shepherd reads these heartbeats to triage which clients need a check-in email. If a heartbeat is older than 25 hours, Shepherd flags it and skips that client’s email for the day rather than silently using stale data.
The host topology
- gg-staff (178.105.115.0, cx33) — the operations server. Brain app, Postgres, N8N, NocoDB, Traefik, Uptime Kuma, Playwright, Sam’s Claude Code. Not client-facing.
- gg-client-template (178.105.123.133, cx23) — the client hosting host. Runs the canonical demo.gg stack today. Will hold every future client stack as additional Docker Compose projects on the same host.
- Paul VPS (76.13.253.221) — Paul’s Claude Code, Caddy, off-site restic backup destination, MainWP. Not a client host.
No sandbox host exists. Decision #100 (three-Hetzner-server architecture) is an unratified proposal only.
The three bots
Three distinct bot roles. Two of them live on the client’s own stack. The third (Sage Shepherd) runs centrally on gg-staff and is therefore out of scope for this template — flagged here so nobody assumes it ships in the clone.
Merlin — the intake interviewer
Merlin is the runtime AI assistant that lives on every client stack. On the per-client Docker stack, the WordPress plugin gg-merlin is the thin front-end widget: it enqueues merlin-chat.js and routes to /agent/* where the Python FastAPI agent handles all bot logic. The PHP engine files inside gg-merlin (Engine.php, PromptBuilder.php, Anthropic.php, ToolHandler.php) are physically present but bypassed at runtime — inert, not formally deactivated, not deleted.
Merlin runs the Stage 1–2 offer-clarity interviews and writes every answer into gg_client_fields. He always offers two paths — “do it for you” or “show you how” — and teaches with breadcrumb-style navigation (ratified D8, Paul+Sam 2026-05-17). Model: Sonnet default, Haiku only for validated simple lookups, Opus reserved for premium. Max 5 agentic iterations per message. Rate limit: 50 messages/hour per client.
Client Bot / Maestro — the coach’s admin partner
Same Python agent, different surface. The persistent chat widget on every WP admin page. Reads and writes the Fluent plugins through tools registered in app/tools/registry.py. Builds pages by assembling from a library of around fifteen pre-built section types with 2–3 variants each, never from a blank canvas. All writes are human-gated: the staged-confirm pattern issues a confirmation card and the coach taps Confirm before any field is saved.
The hard-no list (cannot be unlocked, ever)
- Charge or refund a payment method.
- Delete a contact, tag, or list permanently (soft-delete only).
- Send email to more than 5 recipients without explicit per-message confirmation.
- Modify payment configuration, pricing, or checkout settings.
- Edit legal pages (Terms, Privacy, Refund).
- Modify WordPress core files, plugin files or theme structure files.
- Modify database schema (no CREATE TABLE, ALTER TABLE, DROP TABLE).
- Add or remove WordPress users, or change user roles.
- Change any server-level configuration (nginx, PHP-FPM, cron, firewall).
Sage Shepherd — not in this template
Shepherd is the accountability layer for the 60-day programme. It runs centrally on Sam’s server. It reads the heartbeat table, classifies clients (STUCK / BEHIND / ON_TRACK / JUST_JOINED / POST_60), and drafts emails as Sam for review. Three-beat weekly rhythm: Monday batch, conditional Wednesday nudge, Friday summary.
Sage Shepherd has no chat interface, no widget, no client-facing API. Clients never interact with Shepherd directly. They receive emails that appear to come from Sam. Shepherd does not ship on the client template — nothing about Shepherd needs to land in the Docker stack. Build state checked live 21 May: nothing of the Sage Shepherd model is built — no Shepherd service, cron or workflow on the ops server.
Skills architecture
Skills are interviews and playbooks, not code. They live as markdown files at /app/skills/*.md in the Python agent container’s git repository. The loader (~20 lines, app/skills/loader.py) globs every .md file at startup — no code changes are needed to add a skill. This replaces the role that the old gg-skills-config WordPress plugin previously held.
How a skill runs
- Coach asks the bot to do something (“build me a testimonials page”).
- Bot picks a skill from the library, loads it, and follows the script.
- Skill reads fields from gg_client_fields, assembles HTML from a tested pattern, and proposes the result.
- Staged-confirm: bot shows a confirmation card; coach taps Confirm before anything is saved.
- Activity logged to gg_activity_log.
Model routing
| Model | When it’s used |
|---|---|
| Haiku | Validated simple lookups, standard Monday batch emails, mechanical data substitution. Cheap; default for vetted skill runs. |
| Sonnet | Default for creative or complex work — page builds, copy generation, anything that requires judgement. |
| Opus | Reserved for premium tier or escalation only. Not the default. |
Clients never see model names, token counts, or per-request costs. They see “your AI assistant.” Routing happens behind the scenes. Skills are not paywalled: the revenue model is the flat monthly subscription. Token cost is driven down by skills; there is no per-skill charge or model picker for clients.
Budget & metering
Budget is tracked in cents, not tokens. One pool covers Sonnet + Whisper. Internal cap is $4/month per client ($5 of the $97 subscription allocated; $1 margin). Typical usage runs $2–3/month. The client sees a daily message count and a simple counter — not raw token numbers. The gg-token-budget WP plugin (v2.0.0, must-use, present on the stack) is currently unwired to the Python agent; this is an open reconciliation item between decision #48 (WP plugin tracks tokens) and decision #71 (agent tracks cents).
Agent capabilities are additive-only, explicitly granted, never implicit. The Python agent starts with zero tools. Each capability is a deliberate addition. Clients interact through a locked room with specific doors — nothing is available by default (ratified Paul, 2026-05-17).
Provisioning pipeline
Provisioning is fully automated and zero-touch. The target chain from payment to live stack: 2–5 minutes, no human in the loop, no client action required.
The N8N chain
- Payment (or trial signup) fires an N8N workflow on gg-staff.
- N8N clones the pristine template stack on gg-client-template via
docker compose up. - Four containers come up: WordPress, MariaDB, Python agent, Traefik.
- N8N sets site identity — subdomain, admin user, GG default brand. No client-specific brand data at this step.
- Traefik auto-routes a GG subdomain (firstnamelastname.guidancegate.com) with auto-SSL.
- Coming Soon page set as homepage.
- Stack registered in Uptime Kuma (monitoring) and MainWP (fleet plugin updates).
- Playwright screenshot verifies the site is visually alive.
- Welcome email sent to the client with login details.
The client’s real domain is not connected at provisioning time. It is connected in Stage 3, after pages are built and ready to show publicly. At that point Shepherd emails the client with personalised registrar instructions. Cloudflare DNS automation (N8N sub-workflow) adds the A, SPF, DKIM and DMARC records; a polling script monitors propagation; Traefik issues the SSL certificate once DNS resolves.
Critical path items currently unbuilt
- FluentCart payment webhook to N8N — not wired. The shopping and billing plugin on demo.gg is still in test mode; no real subscription product, no live Stripe connection. Until this lands, no real client can pay us (card #3).
- N8N
docker compose upon gg-client-template — not built. The multi-tenant container_name blocker (Section 9) must be resolved first.
The 37-day cancellation window
Policy: when a client cancels, they get 37 days to export their data before their site is taken down. The policy exists as a line in a planning document. There is no runbook today for what happens at day 37 — who checks, who sends the warning, what gets deleted, what gets archived (card #10). This needs writing up as a real process before the first paying client.
Backups & security
Three backup tiers (ratified Paul+Sam 2026-05-15)
- On-box logical. Both Hetzner hosts run local backup scripts. gg-client-template uses
/root/scripts/gg-backup.sh— mysqldump, wp-content, agent app/skills, traefik acme.json, compose. Hourly + daily. - Off-box restic. Paul VPS pulls from both Hetzner hosts at 04:30 UTC. Rsync lands to
/root/hetzner-staging/, restic encrypts into/root/hetzner-backups. Password in BWS. - Hetzner Cloud snapshots. Available via Hetzner API. Not yet scheduled — pending Paul decision on cost vs benefit.
Retention: hourly 48h / daily 7 days / weekly 5 weeks / monthly 6 months. Brain restore verified passing as of 2026-05-15.
Perimeter
Hetzner Cloud Firewall is the primary perimeter for both Hetzner hosts — applied off-host, no on-box state, instant rollback by API. UFW is inactive on both. Inbound: TCP 22, 80, 443 + ICMP. WireGuard UDP 51820 on gg-staff only (interface present, has never completed a handshake).
Secrets
BWS is the canonical secrets store for Paul VPS and gg-staff. Per-client Docker stacks currently use a plaintext .env file at runtime. BWS is not wired into the client template. Every client clone provisioned from the template propagates plaintext secrets by default. The client-side secret-management model (BWS client integration, Docker secrets, sealed-secrets, or accept-and-document) is an open decision — tracked in the hardening backlog as item #150.
The hardening shopping list
| Item | Source | State |
|---|---|---|
| SSH key management — fleet-wide key rotation and access control | card #208 | decision |
| Cloudflare WAF rules — protect client sites from web attacks | card #209 | decision |
| Per-client API keys (separate Anthropic Workspace per client) | card #84 | raised 22 May |
| Per-client BWS or sealed-secrets at provisioning time | infra-sec-ops canon, item #150 | backlog |
| Intrusion detection — file integrity, process monitoring | card #214 | decision |
| Fluent Support — deactivate and delete from template | ratified D1 | live on demo, not removed |
| Security plugin review (Fluent Security 2.1.2 + Wordfence 8.2.2 both active) | infra-sec-ops canon | two security plugins running |
| WPS Hide Login | parent brief Section 5 | no card defines this on template |
| fail2ban | parent brief Section 5 | not in mu-plugin manifest |
This brief shows a real keyboard and padlock for the security section — not an abstract security badge. The same rule applies to every other image: actual digital work, not metaphors.
Monitoring
Live ops dashboard at dashboard.guidancegate.com/ops. Cron runs every 2 minutes across all three hosts. Nine data sources: disk usage, uptime on 12 GG domains, MainWP fleet status, backup log health, TLS certificate expiry, brain API health, MEMORY.md hygiene, Docker container status, and a security section spanning the full width (reboot_required, fail2ban status, recent failed SSH attempts, Hetzner Cloud Firewall state per host).
Each client’s stack registers with Uptime Kuma at provisioning time (card #150). MainWP child registration (card #151) hooks the stack into fleet plugin updates from Paul VPS.
White-labelling & branding
The coach never sees “WordPress” or any Fluent plugin name. Every surface is white-labelled under GG branding. In the client’s platform the only visible GG reference is “Powered by GuidanceGate” in the admin footer. The bot carries the name the client chose, not “AI Business Assistant” or “Merlin.” Branding is set on first login.
The mu-plugin stack
Mu-plugins load before everything else and cannot be deactivated. Every new client clone includes them. This is the manifest from the canon provisioning file:
| Plugin | What it does |
|---|---|
| gg-client-fields (v1.1.0) | Registers the gg_client_fields table; gg_field() / gg_field_set() helpers; REST endpoint; WP-CLI access. |
| gg-client-dashboard | White-label skin: replaces login logo, injects dark theme and GG logo, renames Fluent menus, suppresses WP update nags. |
| gg-activity-log (v2.0.0) | Logs logins, post edits, bot interactions, field writes by actor / action / timestamp / context. |
| gg-asset-cpt | Registers the gg_asset custom post type for DFY deliverables. |
| gg-bot-escalation | Routes escalation requests from the agent. |
| gg-bot-profile | Serves the client-chosen bot name through the Python agent. |
| gg-bot-arbiter | Must-use arbiter enforcing mutual exclusion between gg-merlin and gg-ai-assistant (D3, Paul 2026-05-17). |
| gg-disable-xmlrpc | Disables the XML-RPC endpoint — standard security tightening. |
| gg-fluent-rebrand | White-labels all Fluent plugin labels, footers and update nags. |
| gg-fluent-rebrand-icons | md5-syncs canonical GG icon assets to Fluent plugin paths on admin_init and plugin update. |
| gg-my-offer | Coach-facing offer summary display. |
| gg-token-budget (v2.0.0) | Present and active. Currently unwired to the Python agent — reconciliation open (Section 9). |
| gg-chat-history, gg-favicon, gg-mega-menu, gg-pages-page, gg-social-post-cpt, gg-users-page, gg-dashboard | Various supporting surfaces in the white-labelled admin. |
Planned but not yet built: gg-seo-meta (lightweight SEO meta boxes — no third-party SEO plugin) and gg-brand-theme (reads the gg_brand WP option JSON, injects CSS variables site-wide).
The brand system
The gg_brand WordPress option (JSON) holds primary, secondary and tertiary colours, heading and body colours, heading and body fonts, border-radius and corner style. One value change in the option updates the entire site through CSS variables. Coach customisation is constrained to short lists, never freeform: inline text and image editing on the front end, structural changes through the Merlin chat widget, approximately 15 pre-built section types with 2–3 variants each, constrained colour and font pickers.
Theme
Base theme: stock Twenty Twenty-Five, completely unmodified. It exists only to keep WordPress happy. All client-facing pages use custom page templates: page-gg-funnel.php, page-gg-free-guide.php, page-gg-stub.php. There is no page builder — no Divi, no Elementor, no Gutenberg blocks. Page content is plain HTML stored in post_content (12–46 KB per funnel page on demo.gg).
The canon mu-plugin manifest lists roughly 19 must-use plugins. RMM (the active dogfood) currently has 28+ in its mu-plugins folder — including gg-briefs, gg-build, gg-business-accelerator-audit, gg-fe-edit, gg-pilot, gg-page-chrome, gg-portal-topbar, gg-site-nav and more. These are RMM-specific tooling that has not yet been triaged into “ships to every client” vs “stays as Sam’s own kit.” No card defines the curated subset. This needs a decision before clone 1 of the template goes live.
Open items, drifts & next steps
Three buckets of unresolved work. The first is the small list of things blocking the very next clone going live. The second is everything else that needs a decision before the template is “done.” The third is the drifts between what canon says and what RMM-reality shows.
What blocks clone 1 going live
| Blocker | What it is | Owner |
|---|---|---|
| Multi-tenant Compose | container_name and host-port collisions mean only one stack can stand up per host today. The fix choices (drop container_name entirely, shared Traefik platform stack, per-client MySQL sidecar) are documented but no decision has been made. This is THE blocker before any second client provisions on gg-client-template. | Paul + Sam joint |
| FluentCart live Stripe product | Demo.gg shopping plugin still in test mode. No real subscription product, no live Stripe gateway, no webhook to provisioning. Until this is built, no real client can pay (card #3, checked live 2026-05-20). | joint |
| 9 architecture questions in brief #46 | Backups, resource limits, per-client MySQL vs shared, SSH access removal, failure domain, MariaDB switch. The compose rewrite is on hold until these are agreed (card #76). | Paul + Sam joint |
| The mu-plugin manifest | Canon lists ~19, RMM has 28+. No card defines the curated “ships to every client” subset. The provisioning cookbook (brief #22) should version-pin the manifest with a review step. | joint |
What blocks Seth
Seth is the first client off the new template. Everything in “blocks clone 1” above blocks Seth. Plus card #84: Seth is named as the place to start adopting per-client API keys (separate Anthropic Workspace per client) as the new provisioning standard. No client has been moved to individual keys yet; today the model is one shared Claude key and one shared voice-service key for all clients.
The 14 open decision-phase questions
Lifted from the project 3 decision cards — these are the discussion-phase items waiting on a sign-off:
| # | Topic | Owner |
|---|---|---|
| 3 | FluentCart needs a live Stripe product before we can take our first payment | joint |
| 8 | Should each client get their own Telegram bot, and if so, on by default? | joint |
| 9 | Lock down which WordPress plugins are required in every new client site — deactivated-on-template plugins keep or remove? | joint |
| 10 | The 37-day data-window after cancellation needs a real runbook | joint |
| 57 | 9 architecture questions for one-isolated-setup-per-client (backups, resource limits, per-client DB, SSH access, failure domain, MariaDB switch…) | Paul |
| 60 | Sign off the shared store (gg_client_fields) — second sign-off pending | joint |
| 61 | Six small background mu-plugins (logging, security, branding) — second sign-off pending | joint |
| 62 | How a coach builds new pages after launch — second sign-off pending | joint |
| 63 | How much control coaches get when customising pages — second sign-off pending | joint |
| 65 | Voice input via Whisper — switch internal Telegram bots over? What do we call the assistant? | joint |
| 66 | One shared AI account for all clients vs per-client — if pooled, do we still get per-client metering and an off switch? | joint |
| 67 | Documentation library the bot can read — second sign-off pending; check if something similar already exists first | joint |
| 84 | Per-client AI keys — separate Anthropic Workspace per client, starting with Seth | Paul |
| 112 | Token-budget and metering-model reconciliation (gg-token-budget WP plugin vs Python agent cents tracking) | Paul + Sam |
The 9 drifts between canon and RMM-reality
| Drift | Canon says | RMM-reality is |
|---|---|---|
| db engine | MariaDB 11 LTS (ratified D2) | MySQL 8.0.46 on demo.gg; RMM is already on MariaDB 11 — the migration path is proven on the RMM stack but not yet rolled to demo.gg |
| mu-plugin set | ~19 must-use plugins in the canon manifest | RMM has 28+ in mu-plugins; subset for the template not defined |
| Fluent Support | Definitively ruled out (D1) — deactivate and delete | Still active on demo.gg as exploration leftover |
| security plugins | Single security plugin (review needed) | Fluent Security 2.1.2 AND Wordfence 8.2.2 both active |
| WPS Hide Login | Listed in parent brief Section 5 | Not installed on demo.gg or RMM; no card defines it |
| fail2ban | Listed in parent brief Section 5 | Not in the mu-plugin manifest; host-level only, not standardised in the clone |
| staging lifecycle | Required by D2 (validate before live) | wordpress-staging container exists on gg-client-template — lifecycle, teardown, key isolation not defined |
| secrets at runtime | BWS canonical on Paul VPS + gg-staff | Per-client Docker stacks ship with plaintext .env containing all 16 secrets — every clone inherits this |
| canon paperwork | Old template doc still describes demo-as-template | Real template is a separate, sanitised, neutral-named stack (since 19 May 2026). Canon update outstanding (card #81) |
Deferred (not part of this template)
- Sage Shepherd — central, not on the client stack. Out of scope for this brief.
- Per-client Telegram bot — parked. The code can talk on Telegram; the per-client setup, cost, and onboarding experience are deliberately deferred (card #8).
- Meta Pixel injection — parked 2026-05-11. Meta app does not exist yet (card #115).
- gg-skills-config / gg-skills-dashboard — present and deactivated on disk. Keep-vs-delete decision deferred.
What sequencing looks like
- Decide the multi-tenant compose model (shared Traefik vs container_name strip) — this unblocks everything else.
- Migrate MySQL → MariaDB on staging, prove, then on demo.gg.
- Curate the mu-plugin manifest and version-pin it.
- Wire FluentCart live Stripe + provisioning webhook.
- Adopt per-client API keys, starting with Seth.
- Write the 37-day cancellation runbook.
- Update the two canon docs to describe the real three-part template (working copy / pristine template / shared router).
All 82 source cards by ID
Every decision-phase card in project_id=3 (“Client Docker template”) at the time of writing. Nothing dropped. Cards marked » are folded into a section above; cards marked + are absorbed contextually; cards marked — are noted but not directly load-bearing for the template (e.g. funnel-page skill specs that belong in their own skill files).
| # | Topic | Where it lands |
|---|---|---|
| 3 | FluentCart live Stripe product | » Section 6, 9 |
| 8 | Per-client Telegram bot | » Section 9 (deferred) |
| 9 | Required-plugin lock-down | » Section 8, 9 |
| 10 | 37-day cancellation runbook | » Section 6, 9 |
| 12 | New email/conversation tool for clients | + flagged, build paused |
| 27 | Submit-My-Offer central webhook | » Section 6 |
| 34 | One central AI engine with personas (superseded) | » Section 4 (superseded) |
| 40 | Submit-My-Offer notification path | + open Q for Paul |
| 57 | One isolated setup per client + MariaDB | » Section 3, 9 |
| 58 | Sage Shepherd | » Section 4 (out of scope) |
| 60 | Sign off gg_client_fields shared store | » Section 3, 9 |
| 61 | Six small background mu-plugins | » Section 8, 9 |
| 62 | How a coach builds new pages | » Section 4, 9 |
| 63 | Coach customisation freedom | » Section 8, 9 |
| 64 | Shepherd as accountability layer | » Section 4 |
| 65 | Whisper for voice input | » Section 4, 9 |
| 66 | Shared vs per-client AI accounts | » Section 5, 9 |
| 67 | Documentation library for the bot | » Section 9 |
| 76 | Multi-tenant Compose rewrite + brief #46 | » Section 9 |
| 81 | Canon still describes the old template | » Section 9 |
| 83 | NextQ as per-client plugin | + noted (idea) |
| 84 | Per-client AI keys / Seth | » Section 7, 9 |
| 97–103 | Hero Section Options, page-build skills | — skill specs |
| 104 | Client Bot authority limits & guardrails | » Section 4 |
| 105 | Skills pull system | » Section 5 |
| 107–111 | Sage Shepherd monitoring, composition, rhythm, escalation, canned replies | » Section 4 (out of scope, summarised) |
| 112 | Token tracking & usage dashboard | » Section 5, 9 |
| 113 | API key provisioning & billing | » Section 5, 7 |
| 114 | Navigation menu setup | — provisioning skill |
| 115 | Meta Pixel injection (PARKED) | » Section 9 (deferred) |
| 118–122 | Asset library, Skills Index, opt-in landing, Activity Log, Plug Drumming | — skill / page specs |
| 123–131 | Offer pages, FAQs, payment pages, calendars, contact, privacy | — page specs |
| 132 | Cron-driven coaching message scheduler | + Shepherd-adjacent |
| 133 | Full site visual review | » Section 6 (verification step) |
| 134 | Form submission test suite | » Section 6 |
| 135 | Email automation test | » Section 6 |
| 136–145 | Booking, Stripe, SMTP, deliverability, search/sitemap, copy variants, video script, free guide | — skill specs |
| 146–161 | Coming-soon, social planner, FluentCRM lists, segmentation, broadcasts, automations, A/B tests, course modules | — skill specs |
| 162–180 | Community setup, member dashboard, app icons, white-label sweep, MainWP child config, monitoring registration, Cloudflare DNS, Hetzner snapshots, restic verify | » Section 6, 7 (touched) |
| 181–200 | Programme stage tasks, Shepherd templates, bot tools, page templates, error pages, 404, 500, robots.txt | — skill / config specs |
| 201–218 | WP plugin rollback, log aggregation, Postgres maintenance, MySQL maintenance, client decommission, rate limiting, push-to-fleet, health endpoint, sync drift, intrusion detection, security review | » Section 7 |
Note on ranges: project 3 contains 82 decision cards, 50 build prompts, and 8 history items. Cards in the 118–200 range are mostly per-page or per-skill build prompts — they are inputs to the template (each page or automation that lands inside it) rather than template-defining decisions. They are referenced here for completeness and absorbed contextually.
Client Docker Template — workstream brief. Synthesised from 82 decision-phase cards in project 3, the canon principles / architecture-stack / infra-sec-ops / provisioning-lifecycle / ai-partner domains, and live inspection of the deployed demo.gg and RMM stacks. Updated 26 May 2026.