HoneyBun is a multi-vertical, multi-city SEO website platform. Operators get fully deployed WordPress sites with AI-generated content, schema markup, and a DCC engine that personalizes every page from a single JSON config.
An operator signs up, their site is provisioned, AI generates content, and the render worker delivers optimized HTML to every visitor — all from a single JSON config.
1
Operator Signs Up
Diagnostic call → Simplex checkout → webhook fires provisioning. Operator picks their vertical (plumber, gym, med spa, etc.) and market.
2
Site Provisioned
hb-provision worker clones the golden WordPress instance on Cloudways, assigns a subdomain, and stores client data in KV.
3
AI Content Generated
hb-content worker runs two passes: Sonnet researches the market, Opus writes high-converting local SEO copy for every page and city.
4
Pages Go Live
The WordPress theme fetches from hb-render on every request. HTML fragments, CSS vars, and JSON-LD schema are injected into the page — no plugin required.
5
SEO Engine Runs
Schema.org markup is injected per page type — LocalBusiness, Service, FAQPage, AggregateRating, BreadcrumbList — all wired to DCC data.
6
Operator Ranks & Retains
Monthly retainer covers ongoing content updates, SEO monitoring via hb-agent, and dashboard access at app.gethoneybun.com.
System Architecture
Request Flow End-to-End
Every page view travels through three systems: WordPress theme → Cloudflare Worker → KV Store. The mu-plugin bridges them invisibly.
Four core workers carry the request path. Fifty-five specialist workers handle orchestration, monitoring, audit, SEO, funnel, OG/image rendering, and platform plumbing. All deployed via Wrangler from workers/configs/*.toml.
wrangler-provisioning.toml
🏗️ Provision
Receives Simplex webhook on checkout → clones the golden WordPress instance on Cloudways → assigns a subdomain → stores new client record in KV. The entry point for every new operator.
HB_CLIENTS (KV)HB_ASSETS (R2)
wrangler-content.toml
✍️ Content
Two-pass AI content generation pipeline. Pass 1: Sonnet researches the market, competitors, and local signals. Pass 2: Opus writes converting local SEO copy for every page template and city combination.
HB_CLIENTS (KV)
wrangler-render.toml
⚡ Render
Pre-computes HTML fragments, CSS custom properties, and JSON-LD schema from the DCC config. Returns a { html, css, schema } payload to the WordPress mu-plugin on every page load. Fastest path to dynamic, personalized pages.
HB_CLIENTS (KV)
wrangler-agent.toml
🤖 Agent
AI agent skills available on-demand: SEO audit of any operator page, content intake from operator questionnaire, and supplemental content generation. Extends platform capability without touching the main workers.
Three layers of vertical readiness: 13 golden template apps deployed and ready to clone (from deploy-manifest.json) · 15 verticals with full implementation under workers/verticals/ (DCC schema, slug patterns, schema.org type, voice preset, nav items, trust signals) · 24 verticals with marketing landing pages on gethoneybun.com. The extra 9 are sales-ready but await full build-out. 5 are running in production right now as live operator sites.
Production (live operator on platform)
Implemented (workers/verticals/ exists)
Marketing only (landing page, no vertical build)
📸 Photo Booth
🔧 Plumbers
💆 Med Spas
🏋️ Gyms / Fitness
💈 Barbershops
❄️ HVAC
💅 Nail Salons
🏠 Roofers
🏡 Realtors
🪵 Flooring & Epoxy
⚡ Electricians
💉 IV Hydration (Clinic)
🦷 Dentists
🔨 Home Remodelers
🚐 IV Hydration (Mobile)
👁️ Optometrists
😁 Orthodontists
💍 Wedding Coordinators
🏝️ Luxury Real Estate
📷 Photographers
🎬 Videographers
🎵 DJs
🎉 Event Planners
🏛️ Venues
💼 CPA / Tax Accountants
Per-Vertical Full Implementation = 24 PHP Templates
Two Vite-built PWAs → Cloudflare Pages: hb-operator-app (operator-facing) and hb-internal-app (internal ops).
🎨
themes/
WordPress themes: photo-booth (base / golden), realtor, plus verticals/ per-industry themes. Synced to Cloudways.
🔌
mu-plugins/
Must-use plugins for every operator's WP install: hb-heartbeat.php (render bridge), hb-hero-preview.php. Mirrored to Cloudways wp-content/mu-plugins/.
🌐
wp-app-root/
PHP HTTP endpoints called by workers: hb-deployer.php, hb-theme-sync.php. Bridge between Cloudflare Workers and Cloudways WordPress.
📚
pages-catalog/
Local dev tool. Regenerates URL catalog for go.gethoneybun.com via node generate-catalog.js.
🧪
pilots/ · scripts/
Pilot experiments and one-off ops scripts. Not deployed — local execution only.
Operator Dashboard
app.gethoneybun.com
The operator-facing control center. Analytics, integrations, site management — all in one place.
📊
GA4 Integration
Connect Google Analytics 4. Traffic, conversions, and ranking trends displayed in the operator dashboard with HoneyBun attribution.
🔍
GSC Integration
Google Search Console data surfaced in-dashboard. Impressions, clicks, average position — per page and per query.
📍
GBP Integration
Google Business Profile. Local visibility metrics, reviews, and citation health tracked from a single dashboard view.
🔑
Client Portal
Per-operator login. View their site, SEO metrics, and content status. SOP-008 governs the client portal onboarding flow.
⚙️
Workflows Engine
Cloudflare Worker-backed automation (hb-workflows endpoints). SOPs trigger workflows for onboarding, content delivery, review requests, and lead follow-up.
🤖
Agent Orchestration
SOP-010 defines agent orchestration. hb-agent skills fire on demand: SEO audits, content gap analysis, intake processing.
Autonomous Runner
Tiered Execution Pipeline
The runner is the execution layer between the task board and the git repos. It runs on the Mac Mini, receives tasks from the dispatcher, and routes each one through the appropriate pipeline based on risk tier. All eight phases of the autopilot migration are live.
Tier Model
Tier 0 · Verify-Only
Read-only DONE_WHEN, zero files_touched, no write verbs in description. Single verifier pass in source repo. No worktree. Closes in ~30s. Examples: [AUDIT] confirm commit X landed on main.
Tier 1 · Reversible Edit
Single-file or small change (<5 files, no structural keywords). Two-pass Researcher → Builder in isolated worktree. Diff guard + sensitive-path check before push. Auto-merged to main on pass.
Tier 2 · Multi-File / Structural
≥5 files or structural keywords (across all, all cities, template, theme-wide). Four-station pipeline. Builder commits in worktree, Verifier independently checks DONE_WHEN, result surfaces as approve/reject card.
Tier 3 · Blocked
Tags: critical, infra, recovery, handoff, deploy. Or files_touched contains sensitive paths (wrangler*.toml, .env*, migrations/, auth/, billing/, CI workflows). Requires a human Claude Code session.
Topology A — Tier 0 / Tier 1
Tier 0: Single Verifier Pass
Read-only Claude session runs DONE_WHEN. Parses RESULT: PASS/FAIL. Runner PATCHes task directly: status=completed + verified_at + verification_output + files_touched=['(verified-no-files-changed)']. No Researcher, no Fixer, no worktree.
Tier 1: Researcher → Builder
Pass 1 (Researcher): read-only, produces FILES_TO_CHANGE + FIX_SPEC + DONE_WHEN. Pass 2 (Builder): implements in isolated worktree on branch autopilot/<taskId>. Commits only — runner handles push after diff inspection.
Diff Guard + Push
After Builder exits: inspectDiff checks committed-but-not-pushed diff. >200 lines or >5 files or sensitive path hit → escalateDiff (stash diff, reset, PATCH blocked, fire alert). Pass → git merge --ff-only from sourceRepo + push. Worktree torn down.
Topology B — Tier 2 (Four-Station Mini-Line)
Station 1+2: Researcher → Builder
Same as Tier 1 but Builder does NOT push after committing. Worktree branch preserved at /tmp/hb-build/<jobId>.
Station 3: Verifier (Independent)
A separate read-only Claude session (pass3-verifier) runs DONE_WHEN against the worktree. PASS → PATCH status=testing + verified_at + verification_output + files_touched + proposed_diff (≤20KB). FAIL → PATCH failed, teardown. The agent that built never verifies its own work.
Station 4: Human Gate + Merge Bot
Task surfaces in the /task-board review lane with full diff + verifier output. Approve: dashboard → POST /tasks/:id/approve-merge → hb-tasks → hb-task-dispatcher → runner POST /merge → git merge --ff-only + push + PATCH completed + teardown. Reject: same chain → runner POST /reject → PATCH pending + teardown.
Post-Merge Health Check (Phase 8)
Probe Trigger
Every dispatcher cron cycle (*/15 min): scans tier=2 tasks completed in the last 10 min with a DONE_WHEN present. Extracts HTTP URL from curl-style checks. Probes via fetch(). Complex shell pipelines are skipped — safer than a false-positive revert.
Failure Streak Tracking
KV keys postmerge:fail:<taskId> + postmerge:fail-at:<taskId> with 30-min TTL. 2 consecutive failures within a 5-min window → triggers auto-revert. Window resets on success or TTL expiry.
Auto-Revert
Runner POST /revert: captures HEAD SHA, runs git revert <SHA> --no-edit, pushes to origin main, PATCHes task to blocked with revert details, fires alert. Alert body distinguishes "revert requested" vs "runner unreachable — manual rollback required."
Event-Driven Dispatch (Phase 1)
Trigger Points
Three hooks in hb-tasks.js: POST /tasks (create), PATCH status→pending, PATCH unclaim→pending. Each fires ctx.waitUntil(maybeFireDispatch) — response never blocked. Kill switch checked at event source (defense in depth; dispatcher checks again).
Dispatch Path
POST /dispatch-task on hb-task-dispatcher. dispatchSingleTask() runs full eligibility: kill switch, autopilot-ok tag, DONE_WHEN present, capacity gate, KV dedup. Delegates to dispatchOne(). Cron (*/15 min) stays as safety net for misses.
Measured Impact
In-flight KV lock appears within 5s of task creation vs prior cron lag of up to 900s. Tier 0 AUDIT tasks close in ~30s vs ~3min two-pass. Concurrent tasks run in isolated worktrees — zero source-repo collisions.
Task Quality Gate
Every task must carry a machine-verifiable success criterion before it can enter the dispatch queue. Enforced at the API layer — POST /tasks returns 422 if either gate fails. No exceptions.
Required: description
Non-empty description field required on every task. Blank description → 422 description required. Gives the runner enough context to do the work without reading the board session history.
Required: DONE_WHEN
Description must include a DONE_WHEN: clause — a shell command that exits 0 on success, or the literal string human-review-required. Missing clause → 422 DONE_WHEN clause required. The runner and the auto-review pipeline both depend on this field to verify completion objectively.
System vs. Human origin
System-generated notifications ([ALERT], [AUTO-ESCALATE], [AUTO-REMEDIATE], [REVIEW:*], [FOLLOW-UP]) are exempt — they're fired programmatically by cron workers with controlled shapes. Tasks created by a human action (e.g. pressing → Claude on an alert card) are never exempt: a button press is a work decision, not a notification.
Auto-Review Pipeline
When any task transitions to status=completed, the pipeline fires two hooks inside ctx.waitUntil() — response is never blocked. Kill switch: KV key auto-review:enabled must equal "1".
Phase 1 — Queue Review
maybeQueueReview: if the completed task touched code files (non-empty files_touched), classify the review level — review, review+security, or audit (6-pass P0–P5) based on file count and path patterns. Queue a [REVIEW:level] task tagged autopilot-ok with a structured DONE_WHEN. Daily cap: 20 auto-generated tasks. Depth cap: 3 review cycles.
Phase 3 — Queue Follow-Up
maybeQueueFollowUp: when a [REVIEW] task closes, parse its board_review_summary for structured findings JSON. If CRITICAL or HIGH findings exist, queue a [FOLLOW-UP] coding task listing each finding and the files to fix. Includes repeat-finding detection: if the same finding hash recurs after a fix attempt, the chain escalates to [HUMAN-REVIEW-REQUIRED] instead of looping.
Escalation Path
When depth cap (3 cycles) or repeat-finding detection fires, queueHumanEscalation creates a [HUMAN-REVIEW-REQUIRED] board task and simultaneously calls HB_PROVISION /internal/send-alert (SMS + email + push) as a fallback — escalation failure is never silent even if Supabase is down.
Security
Security Posture
Documented for technical due diligence. Every layer below is verified from source — not inferred from configuration intent.
frame-ancestors 'self' · base-uri 'self' · script-src locked to self + GTM + Turnstile · connect-src explicit allowlist of all HoneyBun endpoints + GA4. unsafe-inline required for Breeze full-page cache compatibility; nonce-based CSP evaluated and documented as blocked until Breeze is replaced with edge-level caching.
HSTS + Transport
Strict-Transport-Security: max-age=31536000; includeSubDomains — HTTPS enforced at browser level across the entire domain tree. Referrer-Policy: strict-origin-when-cross-origin — limits referrer leakage on cross-origin navigation.
lib/permissions.js — can(), isPrivilegedAdmin(), ROLE_AGENCY_ADMIN and role constants. Not ad-hoc if-checks. Privileged operations (cross-tenant reads, admin routes, force-release) require isPrivilegedAdmin() explicitly.
Scoped Operator Keys
Each operator's X-HB-Key is scoped to their own clientId. One operator's key cannot reach another operator's data. Master key and operator keys are separate credential classes; operator keys cannot self-elevate.
CSRF + Bot Protection
CSRF token injection explicitly prevented on per-client key operations. Cloudflare Turnstile (invisible managed CAPTCHA) on all lead capture forms — lazy-loaded on first modal open, zero pageload impact for non-converting visitors.
Rate Limiting & Resilience
Rate Limiting — Two Layers
KV-backed throttle gates at the application layer — 429 enforcement on all high-sensitivity endpoints before DB touch. CF WAF as the upstream volumetric layer — bot score, threat scoring, and request-rate limiting handled before the request reaches the worker.
Timeout Discipline
AbortSignal.timeout() on every external call — 3s for fast paths, 5–8s for Supabase operations. No hanging requests that cascade into worker CPU exhaustion. Timeout errors are classified and logged the same as network errors.
Read-vs-Write Retry Discrimination
Supabase reads retry on 429/502/503/504 (safe to retry). Writes only retry on 503/504 — not on 502, which may indicate a partial write. Prevents double-writes under ambiguous network failures. Exponential backoff with configurable attempt cap.
Deploy Integrity
SHA-256 Ledger — Every File Deploy
Every file deploy records operator, target path, holder, before-hash, after-hash, bytes, and timestamp to an append-only Supabase table. No deploy exits without provenance. Ledger insert retries 3× before alerting — provenance is never silently lost.
Pre-Write Conflict Detection
Before any file write, the caller submits sha256_live (freshly read) and sha256_assumed_base (what it thinks is live). If they don't match, the write returns 409 — no silent overwrites from concurrent sessions. Removes the race condition from parallel deploys.
Known Gaps (on record)
No structured audit log for admin actions inside app.gethoneybun.com (who changed what, when). No secret rotation automation — rotation is manual. unsafe-inline on CSP script-src (Breeze cache constraint — documented above). These are tracked, not unknown.