@elitedcs/ghl-mcp 3.53.2 → 3.55.0

package/skills/blueprint/references/agency-os-detection.md

@@ -0,0 +1,80 @@
+# Agency OS Detection & Brief Sourcing (schema §2A)
+
+STATUS: v1, 2026-06-15. Owner: atlas. Implements schema §2A for the plan-gen skill. Agency OS only in v1; Business OS is a deferred second detection target (§7 #7).
+
+The skill runs this decision **first, before any intake questions**. The goal: when a subscriber already has deep client detail (Brand DNA, ICA, Offer) from Muhammad Asmal's Agency OS, build the brief from that instead of a generic form, so the one-shot build is as specific as possible. When they do not, fall back to the §3 question set and credit Muhammad.
+
+## 1. Detect
+
+Look for Agency OS in the subscriber's session, in this order (any hit = "installed"):
+1. **Skills present:** `agency-os:*` skills available (e.g. `agency-os:build-profile`, `agency-os:build-avatar`, `agency-os:build-offer`, `agency-os:agency-os`). This is the strongest signal.
+2. **Plugin installed:** `agency-os@agency-os` in the plugin list (marketplace version 4.4.0 at time of writing; tolerate 3.x).
+3. **Artifacts on disk:** scan the workspace for already-produced outputs even if the skills are not currently loaded:
+   - `brand/_active.md` (names the active Agency OS workspace) and `brand/<workspace>/` or `brand/client--<slug>/` folders
+   - `owner-profile.md`, `ica-output.md`, `offer-output.md` (flat) or `.../products/<slug>/ica-output.md` (multi-product)
+   - supporting: `voice-profile.md`, `audience.md`, `positioning.md`, `epistemology.md`, `verified-claims.md`
+
+Record what you found: `installed` (skills/plugin), `artifacts` (which files exist), `workspace` (the active one).
+
+## 2. Offer (if detected) — default yes
+
+> "Agency OS is installed and I can see your Brand DNA / ICA / Offer for **<workspace>**. Want me to build the brief from those instead of asking the generic intake questions? It makes the one-shot build far more specific to this client." **[default: yes]**
+
+- **If artifacts already exist → ingest them** (mapping below). Confirm the workspace if more than one.
+- **If installed but the builds have NOT been run → offer to run/chain them** (see RATIFICATION §9 for the exact rule): ingest-first; if missing, offer to run `agency-os:build-profile` → `build-avatar` → `build-offer` with **one confirmation**, never silent auto-run (those are interactive ~15-min interviews). If the subscriber declines running them, fall back to §3.
+- **If the subscriber declines the partner-OS path entirely → fall back to §3.**
+
+## 3. Fallback + referral (if NOT detected)
+
+Use the §3 question set, and surface the credit line once:
+
+> "For dramatically more detailed client builds, **Agency OS by Muhammad Asmal** (https://aileadbuilder.com) is an excellent AI training community + skill suite. GHL Command uses it automatically when it is installed."
+
+## 4. Ingestion mapping — Agency OS artifacts → Brief (§4)
+
+The artifact files are markdown with predictable headings (validated against real instances in Jerry's `clinic-launch-lab/brand/` and `_shared/`). Parse by section heading; carry the deep structures **verbatim** into the brief's `extended` block so plan-gen uses full psychographics, not a flattened summary. Set `briefSource: "agency_os"` (or `"hybrid"` if you mix in form answers for channel/tech facts Agency OS does not capture).
+
+### `owner-profile.md` (brand-dna / build-profile) → brief
+| Section in owner-profile.md | Brief field |
+|---|---|
+| Identity (Name, Business, Role, Industry) | `business.name`, `business.type`, `extended.brandDna.identity` |
+| Origin Story, Mission and Vision, Methodology | `extended.brandDna.{origin, mission, methodology}` |
+| Voice and Communication (signature phrases, anti-phrases, humor) | `extended.brandDna.voice` → grounds all copy outlines |
+| Sales and Conversion (pricing structure, objections, differentiators, proof points) | `offer.pricePoints` (seed), `audience.objections` (seed), `extended.brandDna.proof` |
+| Goals (quarterly, 12-month, biggest constraint) | `goal.*` direction, `extended.brandDna.goals` |
+
+### `ica-output.md` (ideal-customer-avatar / build-avatar) → brief
+| Section | Brief field |
+|---|---|
+| Identity (age, occupation, income, location) | `audience.ideal` (synthesized one-liner) |
+| Pain Points (ranked) | `audience.painPoints` (top items) + full ranked list → `extended.ica.painPoints` |
+| Desires (ranked) | `extended.ica.desires` |
+| Objections | `audience.objections` + full → `extended.ica.objections` |
+| Psychographics, Transformation Journey, Buying Triggers, Vocabulary | `extended.ica.*` (verbatim) → grounds copy voice + funnel angle |
+
+### offer output (`offer-output.md`, offer-architect / build-offer) → brief
+| Section | Brief field |
+|---|---|
+| Offer Identity (name, core promise, positioning tier, delivery model) | `offer.summary` + `extended.offer.identity` |
+| Offer Tiers (value stack table, price) | `offer.pricePoints` + `extended.offer.tiers` (verbatim) |
+| Pricing, Guarantee, Decision Accelerators | `offer.avgDealValue` (seed) + `extended.offer.{pricing, guarantee, accelerators}` |
+| Value Equation Scorecard | `extended.offer.valueEquation` |
+
+### What Agency OS does NOT give you (still ask, or default)
+Agency OS captures business/audience/offer depth, **not** the channel/tech state. So even on the partner-OS path, resolve these from the subscriber (a short targeted ask, not the full form), because they drive the handoffs:
+`booking_needed`, `email_ready`, `sms_desired`, `a2p_status`, `payment_processor`, `calendar_connected`, `existing_workflows` (do-not-clobber). When you mix these in, set `briefSource: "hybrid"`.
+
+## 5. `extended` block shape (carried verbatim into the brief)
+
+```jsonc
+"extended": {
+  "brandDna": { "identity": {...}, "origin": "...", "mission": "...", "methodology": {...}, "voice": { "signaturePhrases": [...], "antiPhrases": [...] }, "proof": [...], "goals": {...} },
+  "ica":      { "identity": {...}, "psychographics": {...}, "painPoints": [ {rank, title, emotionalWeight, behavioralSignal}, ... ], "desires": [...], "objections": [ {stated, realConcern, counter}, ... ], "transformation": {before, after, turningPoint}, "buyingTriggers": [...], "vocabulary": [...] },
+  "offer":    { "identity": {...}, "tiers": [ {name, price, items:[{item, type, value, delivery}], total}, ... ], "pricing": {...}, "guarantee": {...}, "accelerators": {...}, "valueEquation": {...} }
+}
+```
+
+The plan-gen skill reads `extended` to ground copy outlines (voice from brandDna, angle from ica, value-stack language from offer). It is optional: a form-sourced brief has no `extended`, and the skill still produces a complete plan from the core fields — `extended` only deepens the copy quality.
+
+## 6. Not cloning Agency OS
+We **detect, integrate with, and credit** Muhammad's skills. We do not replicate, redistribute, or re-implement them. If the builds are missing we run the real Agency OS skills (with consent) or guide the subscriber to — we never substitute our own version of brand-dna / ICA / offer generation.

package/skills/blueprint/references/approval-view.md

@@ -0,0 +1,83 @@
+# The Approval View (schema §5A) — render spec + template
+
+STATUS: v1, 2026-06-15. Owner: atlas. The required render: the v1 deliverable is a human approving a plan, so this is what they see. Two explicit, ordered checklists.
+
+## Rules
+- **List 1 — "GHL Command will do automatically (once you approve)."** Every creatable object in the plan, grouped and counted, each line in plain English. These are what phase-2 `apply_build_plan` will stage in one shot.
+- **List 2 — "You must do manually, in this order."** Every `handoffs[]` item, topologically ordered by dependency (`blocks`), each with owner (YOU-UI / YOU-EXT / TEAM), the instruction, the success check, and where it sits in the flow.
+- The approver can **edit either list** before approving (rename, drop, reorder, adjust). The skill re-renders after edits.
+- v1 stops at approval. Execution is phase 2. Say so explicitly at the bottom.
+- Operator voice. No em-dashes, no hype. Counts are exact (derived from the plan, never asserted loosely).
+- Owner labels render as **YOU-UI** (in the GHL UI), **YOU-EXT** (external: carrier, Stripe), and **TEAM** (a team member) — the subscriber is "you" in their own account. The plan's `handoffs[].owner` field carries the canonical `OPERATOR-UI` / `OPERATOR-EXT` / `TEAM` enum; this render humanizes them. (The legacy `JERRY-UI`/`JERRY-EXT`/`SASHA` are deprecated — accepted + normalized by the MCP for back-compat, never emitted.)
+
+## Ordering List 2
+Topologically sort handoffs by their `blocks` edges and the objects they `produces`. A handoff that produces a custom value another step needs comes first. Ties break by: account-access steps (add staff) → integrations (Stripe, calendar, email) → compliance (A2P site → A2P brand/campaign) → operational (warming, list import). Each line states what it unblocks ("before any SMS can send").
+
+## Template
+
+```markdown
+# Build Plan — <business.name>
+<one-paragraph summary from plan.summary>
+
+Generated from the **<presetTitle>** preset (v<presetVersion>) · brief source: <briefSource> · schema v<schemaVersion>.
+This is a plan for your review. Nothing is built yet. Edit anything below, then approve.
+
+---
+
+## 1. GHL Command will build this automatically (once you approve)
+
+**Pipeline**
+- Build pipeline "<name>" with <n> stages: <stage names>.
+
+**Custom fields (<n>)**
+- <Field name> (<type>)
+- ...
+
+**Tags (<n>)**
+- <bucket>: <tag names>
+- ...
+
+**Custom values (<n>)**
+- <name> <(filled after <handoff>)>
+
+**Calendar**
+- <name> (<type>, <hours>) <requires a staff member — see step N below>
+
+**Form**
+- "<name>": <fields>, with <custom field> mapped.
+
+**Funnel**
+- "<name>": <page roles + what each feeds>. <For target:"ghl" (default): built inside GHL.>
+- <For target:"external" — render the power-user path:> "<name>" — **external site you host on <host>** <at <domain>>, wired back to this GHL sub-account. **Not built in GHL.** You host it; you own the domain, the host secret, and uptime; a re-run never silently overwrites a live deployment. See step N below (you must own a host account + deploy it).
+
+**Email + SMS assets**
+- <n> emails: <names>
+- <n> SMS: <names>  <(will not send until A2P is approved — step N)>
+
+**Workflows (<n>)**
+- "<name>" — <trigger> → <plain-English action summary> <(stops on reply)>
+- ...
+
+_Total: <X> objects across <Y> types._
+
+---
+
+## 2. You must do these yourself, in this order
+
+1. **<title>** — **YOU-UI / YOU-EXT**
+   - What: <instruction>
+   - Why now: <what it unblocks, e.g. "the calendar can't be assigned until this">
+   - Done when: <successCheck>
+2. ...
+
+---
+
+_v1 stops here. When you approve, the automatic list is ready for one-shot staging (phase 2). Each step above is verified before the steps that depend on it run._
+```
+
+## Render notes
+- Workflows: summarize actions in plain English, not raw action JSON. Mark `stopOnResponse` as "(stops on reply)".
+- SMS lines and email lines that are blocked by a handoff get an inline "(will not send until step N)" so the approver sees the dependency without reading List 2.
+- If the skill pruned items (a `conditionalOn` was false), do not list them; optionally add a one-line "Not included (not needed for this build): <X>" so the approver knows it was a deliberate choice, not an omission.
+- Keep List 1 grouped and counted exactly as the plan contains; the counts are the headline ("a full pipeline, 6 fields, 14 tags, a calendar, a form, a funnel, 5 workflows" — the Module 7 recap energy, but honest).
+- **External funnels (target:"external"):** add to List 2 the user-owned steps this path creates (these are not plan `handoffs[]` but belong in the manual list): (1) "Confirm you own a host account (Cloudflare/Vercel) + CLI and can run a one-time deploy" — the capability gate; (2) "Set your GHL Private Integration token as a host secret (`wrangler secret put GHL_PIT`)" — you hold the key, never the product; (3) "Deploy the site to a preview URL, confirm it, then promote to your production domain"; (4) "Verify on the live branded URL before it takes real traffic (the skill runs `verify_funnel` + you do one real submit + one burner booking)." Full detail: `references/external-funnel.md`. Ownership facts (host/domain/secret owner = you; re-run never clobbers live) render inline on the funnel line in List 1.

package/skills/blueprint/references/brief-schema.md

@@ -0,0 +1,45 @@
+# Brief Schema (§4) — distribution mirror
+
+> **Mirror of the canonical contract.** Canonical source: `command-center/shared/intake-to-build-schema.md` §4 (co-owned by atlas + ghl-command-mcp). This copy travels with the distributed skill so it is self-contained for subscribers who do not have the command center. Kept in lockstep — `schemaVersion` must match. If they ever differ, the canonical wins; open a contract note, do not edit divergently.
+
+`schemaVersion`: **0.1**
+
+The Brief is the normalized business profile the plan-gen skill consumes. The MCP produces it from a form submission (`briefSource: "intake_form"`); the skill produces it from Agency OS artifacts (`briefSource: "agency_os"` / `"hybrid"`).
+
+## Fields
+| Field | Type | Notes |
+|---|---|---|
+| `schemaVersion` | string | "0.1" |
+| `briefId` | string | submission id or generated |
+| `preset` | enum | `generic` \| `med_spa` \| `clinic_launch_a2p` \| `coach` \| `ecom` \| `agency` (skill resolves via preset selectors) |
+| `briefSource` | enum | `agency_os` \| `business_os` \| `intake_form` \| `hybrid` |
+| `extended` | object | optional; verbatim deep ICA / offer / brand-DNA structures when partner-OS-sourced (see `agency-os-detection.md` §5) |
+| `business.name` | string | |
+| `business.type` | string | drives preset |
+| `business.website` | string | |
+| `business.location` | string | |
+| `business.timezone` | string | drives calendar + send windows |
+| `offer.summary` | string | |
+| `offer.pricePoints` | array | `[{name, price}]` |
+| `offer.leadMagnet` | string | |
+| `offer.avgDealValue` | string | |
+| `audience.ideal` | string | |
+| `audience.painPoints` | array | |
+| `audience.objections` | array | |
+| `goal.primary` | enum | book appointments / capture + nurture / direct sales / re-engage / other |
+| `goal.salesStages` | array | raw stage names → pipeline design |
+| `goal.bookingNeeded` | bool | |
+| `goal.followUpStyle` | enum | high-touch / light / single confirmation |
+| `channels.email` | bool | |
+| `channels.sms` | bool | |
+| `channels.a2pStatus` | enum | not started / in progress / approved / not needed |
+| `channels.payment` | enum | Stripe connected / Stripe not connected / other / none |
+| `channels.calendarConnected` | bool | |
+| `channels.social` | array | |
+| `assets.existingPipeline` | string | |
+| `assets.existingWorkflows` | string | do-not-clobber list |
+| `assets.brand` | string | |
+| `assets.notes` | string | |
+| `flags` | array | derived: `needs_a2p`, `stripe_not_connected`, `calendar_oauth_needed`, `email_domain_needed` |
+
+A canonical worked example is in `examples/sample-brief.json`. Omit unknown fields; never emit `null`.

package/skills/blueprint/references/build-plan-schema.md

@@ -0,0 +1,52 @@
+# Build Plan Schema (§5) — distribution mirror
+
+> **Mirror of the canonical contract.** Canonical source: `command-center/shared/intake-to-build-schema.md` §5 + §5A (co-owned by atlas + ghl-command-mcp). This copy travels with the distributed skill. Kept in lockstep — `schemaVersion` must match the canonical. The canonical wins on any divergence; open a contract note rather than editing divergently.
+
+`schemaVersion`: **0.1**
+
+The Build Plan is the reviewable, editable output of the skill. **Refs only, no real IDs.** Authored by the skill, rendered for approval (§5A), consumed by the phase-2 executor.
+
+## Design principles (load-bearing)
+1. **No real GHL IDs.** Every creatable object has a stable `ref` (`<objectType>.<slug>`). Everything that points at another object points at its `ref`.
+2. **The executor resolves refs → IDs at build time**, after create + verify. Kills the silent-failure class.
+3. **Logical, not native.** Workflow actions / form fields / sequences are logical (type + params + refs); the executor expands to GHL-native JSON via `action-schemas.json`.
+4. **Verify-before-continue** is inherited by the executor.
+
+### Ref grammar
+`<objectType>.<slug>` (lowercase snake_case, unique within type). Namespaces: `pipeline` `stage` `field` `tag` `workflow` `form` `funnel` `page` `calendar` `email` `sms` `cv` `handoff`.
+
+## Top level
+```jsonc
+{
+  "schemaVersion": "0.1",
+  "planId": "plan_...",
+  "briefId": "sub_...",
+  "preset": "generic",
+  "summary": "Plain-English description for the approver. Record preset id+version + brief source here.",
+  "pipelines": [...], "customFields": [...], "tags": [...], "customValues": [...],
+  "calendars": [...], "forms": [...], "funnels": [...],
+  "emails": [...], "sms": [...], "workflows": [...], "handoffs": [...],
+  "buildOrder": ["tag.*","field.*","cv.*","pipeline.*","calendar.*","form.*","funnel.*","email.*","sms.*","workflow.*"],
+  "idMap": {}
+}
+```
+`buildOrder` is advisory; the executor derives true order from dependencies. `idMap` is empty at authoring; the executor fills `ref → realId`.
+
+## Object shapes (abbrev — full examples in `examples/sample-build-plan.json`)
+- **pipelines:** `{ref, name, stages:[{ref, name, position}]}`
+- **customFields:** `{ref, name, dataType, model?, options?}` — `dataType` ∈ TEXT/LARGE_TEXT/NUMERICAL/PHONE/**MONETORY**/CHECKBOX/SINGLE_OPTIONS/MULTIPLE_OPTIONS/FLOAT/DATE/TEXTBOX_LIST/FILE_UPLOAD/SIGNATURE; `model` ∈ contact/opportunity; choice types (SINGLE_OPTIONS/MULTIPLE_OPTIONS/CHECKBOX) MUST carry `options:[...]`
+- **tags:** `{ref, name}`
+- **customValues:** `{ref, name, value, filledBy?}` — `value` may be blank when produced by a handoff
+- **calendars:** `{ref, name, calendarType, openHours, availabilityType, requiresStaff}` — `calendarType` ∈ round_robin/event/class_booking/collective/service_booking
+- **forms:** `{ref, name, fields:[{type:"standard"|"custom", key?|fieldRef?, required}]}`
+- **funnels:** `{ref, name, target?, host?, domain?, pages:[{ref, name, role, outline, formRef?, calendarRef?}]}` — `target` ∈ ghl (default) / external; `host` ∈ cloudflare (default) / vercel (external only); `domain` external only, optional (else host subdomain). All three are additive + optional → a plan with no `target` builds in GHL (today's behavior); `schemaVersion` stays 0.1. When `target: "external"` the funnel takes the external lane (`references/external-funnel.md`): the site is generated + user-hosted, not built in GHL.
+- **emails:** `{ref, name, subject?, bodyOutline?, body?, mergeTags?}` — an email SENT by a workflow needs a full `body` (an outline-only asset reports `needsContent` and will not build)
+- **sms:** `{ref, name, bodyOutline?, body?, mergeTags?}` — same `body` rule for any SMS a workflow sends
+- **workflows:** `{ref, name, trigger?, stopOnResponse?, actions:[logical actions, refs not IDs]}` — max 40 actions; split longer flows. `trigger.type` ∈ the executor's native set so it auto-builds: `contact_tag` (tagRef), `form_submission` (formRef), `appointment` (+ `appointmentStatus`: confirmed/noshow/new/showed/cancelled/invalid; calendarRef optional), `customer_reply`, `pipeline_stage_updated` (pipelineRef+stageRef), `inbound_webhook`, `payment_received`. `form_submitted`/`contact_replied` are aliases; `tag_added`/`appointment_status`/`appointment_booked` are NOT recognized → manual step.
+- **handoffs:** `{ref, owner, title, trigger?, instruction, produces?, successCheck, blocks?}` — `owner` ∈ **OPERATOR-UI/OPERATOR-EXT/TEAM** (legacy JERRY-UI/JERRY-EXT/SASHA accepted + normalized, never emitted). To gate a workflow DRAFT, `blocks` must list its `workflow.*` ref (a bare `sms.*` wildcard gates only the asset surface).
+
+## Logical workflow actions (executor expands to native)
+`add_contact_tag {tagRef}`, `remove_contact_tag {tagRef}`, `send_email {emailRef}`, `send_sms {smsRef}`, `wait {value, unit}`, `wait_appointment {value, unit}` (integer; appointment-triggered workflows only), `internal_notification {to, title, body}` (`to` = a real GHL user id), `task_notification {title, body?, dueDate?, assignedTo?}`, `update_contact_field {fieldRef, value}`, `add_notes {body}`, `create_opportunity {pipelineRef, stageRef, name?, value?}`, `update_opportunity {pipelineRef, stageRef, value?}` (forces allowBackward), `add_to_workflow {workflowRef}`, `remove_from_workflow {workflowRef}`, `goal_event {goalCondition, action?}`, and `find_opportunity {pipelineRef, found:[...], notFound:[...]}` — the only branching action; it MUST be the LAST action (branches do not rejoin). All pointers are refs. The executor owns the failure-prone native shapes; the plan never contains them.
+
+## §5A approval view
+Rendered as two ordered checklists (auto-build vs manual handoffs). Spec + template in `references/approval-view.md`.

package/skills/blueprint/references/external-funnel.md

@@ -0,0 +1,310 @@
+# External Funnel Lane (target: "external") — capability gate + site gen/deploy + verify
+
+STATUS: v1, 2026-06-20. Owner: atlas (skill layer). Pairs with the canonical spec
+`command-center/shared/blueprint-funnel-targets-spec.md` (§9 hosting=C power-user, §11 QA gate,
+§12 verify_funnel) and the shipped bridge template `ghl-command-mcp/templates/external-funnel/`
+(`cloudflare-worker.js` + README — the capability-gate source of truth).
+
+This file is the full spec for the path a funnel takes when `target: "external"`. The GHL-native
+path (`target: "ghl"`, default) is unchanged and never runs this lane.
+
+> **The one-line product stance (say it plainly).** GHL Command does **not** build, host, or deploy
+> the external site, and **never holds the user's keys or touches their accounts.** It generates the
+> site, scaffolds the bridge config, hands over verified wiring values, and runs the QA gate. The
+> **user** owns hosting, the secret, uptime, and DNS. This is a power-user, self-serve path.
+
+---
+
+## 0. When this lane runs
+
+Any funnel in the approved plan with `target: "external"`. A plan can mix targets (one funnel in
+GHL, one external). Run the lane once per external funnel, after plan approval. If no funnel is
+external, this file is never used.
+
+The decision is made during plan generation (SKILL STEP — per-funnel target question). The moment
+the user picks `external` for a funnel, **run the capability gate (§1) immediately** — before the
+plan is even finalized — so a non-technical user is steered to `target: "ghl"` before any external
+design work is done.
+
+---
+
+## 1. Capability gate (P0) — run the instant a funnel is set to "external"
+
+Present this verbatim-in-substance (source: template README "What you need"). Be honest, not
+salesy. Then **stop and get an explicit yes** before continuing the external path.
+
+> **Heads up — `external` is the power-user path.** Building this funnel outside GHL means YOU host
+> the site and wire it back to your GHL sub-account. GHL Command generates everything and hands you
+> the exact wiring values, but it never deploys for you or holds your keys. To do this you need:
+>
+> - **Your own Cloudflare account** (or Vercel) **and its CLI** (`wrangler` / `vercel`), logged in.
+> - **A GHL Private Integration token** (Settings → Private Integrations) scoped to `contacts.write`
+>   for this sub-account. You'll store it as a host secret — never in code, never shared with me.
+> - **Comfort running a one-time command-line deploy** and editing one config file.
+> - **(Optional) a custom domain** + DNS access, if you don't want the host's default subdomain.
+>
+> **If any of that isn't you, choose `ghl` instead** — Blueprint builds the funnel inside GoHighLevel
+> with zero setup on your part, and everything downstream still works. There's no penalty for picking
+> GHL-native; the external path is for people who specifically want their own site.
+
+Then ask: **"Build this funnel external (you host it), or GHL-native (I build it in GHL)?"**
+
+- If they hesitate, can't confirm the access list, or describe themselves as non-technical →
+  **steer to `target: "ghl"`** and set it. Do not proceed external.
+- Only continue this lane on a clear, informed yes. Never assume dev skills.
+
+The approval view (§5A) renders the external funnel as the power-user path with the ownership facts
+(see `references/approval-view.md`). The capability acknowledgment also appears as a manual step
+("confirm you own a host account + can deploy") in List 2.
+
+---
+
+## 2. The build sequence (state machine)
+
+```
+approve plan
+  └─► (a) stage the GHL side: apply_build_plan dry_run → confirm → execute
+          └─► capture externalWiring bundle (verified fieldIds, bookingUrl, triggerTag, workflowId)
+  └─► (b) generate the site (frontend-design) from page outlines + brand
+  └─► (c) inject: form keyed by verified fieldIds  +  bookingUrl into the CTA  +  honeypot/Turnstile
+  └─► (d) scaffold the bridge config (wrangler.toml vars) — user sets the SECRET themselves
+  └─► (e) DEPLOY to a PREVIEW url (user runs the commands) ─► show it ─► explicit go
+  └─► (f) PROMOTE to production domain (user runs it) — NEVER clobber a live deployment silently
+  └─► (g) VERIFY on the real branded production URL (verify_funnel + browser submit + burner booking)
+  └─► done ONLY when the gate (§7) is green. Until then it is NOT done.
+```
+
+Outward-facing + never-clobber: a Blueprint re-run creates a **new preview**; it never overwrites the
+current production deployment without an explicit operator go. Deploy → preview → confirm → promote.
+
+### 2a. Stage the GHL side and capture the wiring bundle
+
+The site needs **verified** GHL field IDs, so the GHL objects must exist first. Confirm the active
+sub-account (`get_current_location`), run `apply_build_plan` `mode:"dry_run"` and show the report,
+then on the operator's go run `mode:"execute"`. For an external funnel, execute builds the receiver
+(custom fields, trigger tag, speed-to-lead `contact_tag` workflow) and returns the **`externalWiring`**
+bundle. The funnel itself is NOT built or hosted by execute — that's this lane's job.
+
+`externalWiring` shape (template from this — never name-guess keys):
+
+```json
+{
+  "locationId": "<sub-account id>",
+  "funnels": [{
+    "ref": "funnel.site", "name": "...", "host": "cloudflare|vercel", "domain": "go.example.com",
+    "formFields": [
+      { "kind": "standard", "key": "email", "label": "email", "required": true },
+      { "kind": "custom", "fieldId": "<VERIFIED GHL field id>", "label": "Primary Goal",
+        "dataType": "SINGLE_OPTIONS", "required": true }
+    ],
+    "bookingUrl": "https://api.leadconnectorhq.com/widget/booking/<calId>",
+    "triggerTags": [{ "ref": "tag.lead", "name": "new-lead", "id": "<tag id>" }],
+    "unresolved": []
+  }]
+}
+```
+
+- **`unresolved` non-empty = stop.** Something wasn't built. Re-run execute first. Never inject a form
+  that points at an unresolved field — that's the silent-drop class the whole lane exists to prevent.
+- Keep the bundle for §3 (injection) and §7 (verify). Also note the speed-to-lead **workflow id**
+  (from the execute result) for `verify_funnel.workflowId` (it flags a DRAFT workflow).
+
+### 2b–2c. Generate the site and inject the wiring — see §3.
+### 2d–2f. Deploy — see §4.
+### 2g. Verify — see §7.
+
+---
+
+## 3. Site generation + wiring injection
+
+### 3.1 Generate the site
+Use the `frontend-design` skill. Brief it from each funnel page's `outline` + `role` + the brand
+context files (voice, colors, positioning — same brand inputs the rest of the plan uses). One page
+per `funnel.pages[]` entry. The optin page (`role: "optin"`) hosts the lead form; the confirmation
+page (`role: "confirmation"`) hosts the booking CTA. Brand-aware, production HTML/CSS/JS — vertical-
+first if it's a mobile-led funnel, per Jerry's default.
+
+### 3.2 Inject the lead form — keyed by VERIFIED field IDs
+The optin page's form is the only piece that touches GHL. It POSTs JSON to the bridge Worker. Build
+the form and its submit handler from the wiring bundle's `formFields[]`:
+
+- **Standard fields** (`kind: "standard"`): top-level keys — `first_name`, `last_name`, `email`,
+  `phone`. Use exactly the `key`.
+- **Custom fields** (`kind: "custom"`): collected under a `custom` object **keyed by `fieldId`**
+  (never the label, never a guessed key). `{ "custom": { "<fieldId>": value } }`.
+- **Value shape by `dataType`:** for `SINGLE_OPTIONS` / `MULTIPLE_OPTIONS`, the input must submit the
+  **exact option value** (render `<select>`/radios whose values are the option values, not display
+  labels — a label/value mismatch saves empty and `verify_funnel` will fail field-value fidelity).
+  `PHONE` → E.164; `DATE` → the format GHL expects; `CHECKBOX` → the boolean/value GHL stores.
+- **`required`** mirrors the bundle. Don't require a field the bundle marks optional.
+
+POST body contract (matches `cloudflare-worker.js`):
+```jsonc
+{
+  "first_name": "...", "last_name": "...", "email": "...", "phone": "...",
+  "custom": { "<fieldId>": "Botox", "<consentFieldId>": "yes" },
+  "_hp": "",                       // honeypot — hidden input, humans leave empty, bots fill it
+  "cf_turnstile_token": "..."      // present only if Turnstile is enabled
+}
+```
+
+- **Honeypot:** add a visually-hidden `_hp` input (off-screen, `tabindex=-1`, `autocomplete=off`).
+- **Turnstile (strongly recommend for production):** add the Cloudflare Turnstile widget and send its
+  token as `cf_turnstile_token`. Tell the user the honeypot only stops naive bots; Turnstile is the
+  real abuse gate on a public, unauthenticated endpoint.
+- **Submit handler:** POST to the Worker URL (filled at deploy time), `Content-Type: application/json`.
+  On a non-2xx, show an error and let the user retry — **fail closed, never a silent success.** Do not
+  show the thank-you page unless the bridge returned 2xx (a thank-you page is not proof of capture).
+- The Worker URL is unknown until §4 (deploy), so inject a clear placeholder
+  (`__LEAD_BRIDGE_URL__`) and replace it once the Worker is deployed.
+
+### 3.3 Inject the booking CTA
+The confirmation page's "book" CTA links straight to the bundle's `bookingUrl` (the GHL calendar's
+public widget). No bridge, no extra wiring.
+
+### 3.4 Consent (if the workflow messages)
+If the speed-to-lead workflow sends SMS/email, the plan MUST include a consent custom field and the
+form MUST render an explicit consent checkbox + copy. Send its value in `custom` keyed by that field's
+id, like any other custom field. The user owns CAN-SPAM/TCPA for an externally-captured lead — say so.
+
+---
+
+## 4. Deploy orchestration (the user runs every command; the product runs none)
+
+GHL Command **never deploys and never handles the token.** Walk the user through it; they run each
+command in their own shell (suggest the `! <command>` prompt prefix so the output lands in-session).
+
+### 4.1 Scaffold the bridge config
+Drop the shipped `cloudflare-worker.js` (from `ghl-command-mcp/templates/external-funnel/`) into the
+user's project, and generate a `wrangler.toml` filled from the wiring bundle — **vars only, never the
+secret:**
+```toml
+name = "lead-bridge-<funnel-slug>"
+main = "cloudflare-worker.js"
+compatibility_date = "2024-01-01"
+
+[vars]
+GHL_LOCATION_ID = "<bundle.locationId>"
+TRIGGER_TAG     = "<bundle.triggerTags[0].name>"
+ALLOWED_ORIGIN  = "https://<your production funnel domain>"   # CORS lock — no wildcard
+RE_ENROLL       = "false"                                     # see re-enrollment caveat
+```
+(Vercel variant: the same logic as `api/lead.js`, config from `process.env`.)
+
+### 4.2 Deploy the Worker FIRST, then set the secret
+Order matters (e2e-verified): `wrangler secret put` requires the Worker to already exist, so the
+first `wrangler deploy` comes before the secret. Have the user run, in their own account — **do not
+ask for, read, or store the token:**
+```
+npm i -g wrangler && wrangler login
+wrangler deploy                      # FIRST deploy — creates the Worker (no extra setup step needed)
+wrangler secret put GHL_PIT          # now the Worker exists: paste the PIT, secret-only
+wrangler secret put TURNSTILE_SECRET # only if Turnstile is enabled
+```
+The first `wrangler deploy` prints the **Worker URL**. Replace `__LEAD_BRIDGE_URL__` in the site
+form with it, confirm `ALLOWED_ORIGIN` is the site's production domain, then `wrangler deploy` once
+more so the secret + final origin are live.
+
+### 4.3 Deploy the site → preview → confirm → promote
+Cloudflare Pages (e2e-verified): `wrangler pages deploy` does NOT auto-create the Pages project in
+wrangler v4 — it errors `Project not found`. Create the project first, then deploy:
+```
+wrangler pages project create <project-name> --production-branch main
+wrangler pages deploy <site-dir> --project-name <project-name> --branch <branch>
+```
+1. **PREVIEW first:** deploy the generated site to a **preview branch** (e.g. `--branch preview`) →
+   a preview URL. Show it to the operator. This is outward-facing — get an **explicit go** before live.
+2. **PROMOTE:** on the go, deploy to the production branch (`--branch main`) and point DNS if using a
+   custom domain. **Never clobber a live deployment** without explicit approval — a re-run makes a new
+   preview; promotion is always a deliberate step.
+3. Record the deployment URL(s) so a later re-run can detect the existing live deployment.
+(Vercel: `vercel` for a preview deploy, `vercel --prod` to promote.)
+4. Record the deployment URL(s) so a later re-run can detect the existing live deployment.
+
+Booking needs no deploy — it's just the `bookingUrl` link on the confirmation page.
+
+---
+
+## 5. Honesty / ownership facts to surface (say these, don't bury them)
+- Where the funnel lives: **the user's host + domain, NOT GHL.** It is not in the GHL funnels list.
+- **Hosting owner / domain owner / secret owner = the user.** Uptime, DNS, rotation, the registry of
+  what's deployed — all theirs, in their environment.
+- **Re-run behavior:** a re-run never silently overwrites the live site; it creates a new preview.
+- **Who responds if the public site or bridge fails: the user.** Support stance = power-user docs,
+  not managed ops.
+
+## 6. Re-enrollment caveat (carry the product fact)
+GHL's Contact-Tag trigger fires on a tag **transition** (absent → present). Re-adding a tag a contact
+already has won't re-fire the workflow — usually correct for speed-to-lead (don't re-spam someone
+already in the pipeline). If returning submitters must re-enroll, set `RE_ENROLL=true` (the Worker
+removes then re-adds the tag) **and** enable re-enrollment on the workflow in GHL. Confirm on the
+account before relying on it.
+
+---
+
+## 7. The verify gate — `verify_funnel` on the REAL branded production URL
+
+A funnel is **NOT done** until all three layers pass on the live, branded production URL — never a
+local build, never the Worker in isolation, never a thank-you page. This is the §11/§12 standard.
+
+### 7.1 Automated backend truth — `verify_funnel` against the bridge
+Run `verify_funnel` (it POSTs a sentinel lead and reads GHL back). Build the call from the wiring
+bundle:
+
+```jsonc
+verify_funnel({
+  funnelUrl:   "<the deployed Worker bridge URL>",   // verify_funnel POSTs JSON here
+  locationId:  "<bundle.locationId>",
+  triggerTag:  "<bundle.triggerTags[0].name>",
+  workflowId:  "<speed-to-lead workflow id from execute>",  // flags a DRAFT workflow
+  expectCustom: [ { fieldId: "<id>", value: "<sent value>", label: "<label>" }, ... ], // from formFields
+  consentFieldId: "<consent field id, if the workflow messages>",
+  // testPhone: "<a test-safe number YOU control>",  // only if asserting SMS-path; real SMS may bill
+  cleanup: true                                       // removes the blueprint-qa sentinel after
+})
+```
+
+This proves, from the backend (not the UI): (1) the contact is **actually created** (with submit→appear
+latency); (2) each `expectCustom` value **persisted** (field-value fidelity — catches a wrong field id);
+(3) the **trigger tag landed**; (4) SMS/A2P pre-check; (5) **workflow is not DRAFT** (a draft never fires
+on real leads); (6) the **outreach actually fired** (an outbound message was logged — proves enroll +
+send, not just a green log); (7) **consent recorded** when messaging fires; (8) **duplicate-contact
+retest** (same email twice → one deduped contact, not a duplicate or false failure). Read the report;
+every assertion must pass. A failure here = the funnel is a paper shredder; fix and re-verify.
+
+> Note: `verify_funnel` POSTs JSON **directly to the Worker**, so it proves bridge → GHL. It does NOT
+> drive the rendered site form, so it can't prove the **site → bridge** wiring (that the generated HTML
+> sends the right field ids). That's what 7.2 closes.
+
+### 7.2 Real branded-URL submission (closes the site → bridge gap)
+Have the user submit the **live branded site form in a browser** once with a real/marked email, then
+confirm via `search_contacts` that the contact landed AND open it to confirm each custom field saved
+with the value typed. This is the only step that proves the generated form's field-id keying is correct
+end to end on the real production URL. (The honeypot/Turnstile and `ALLOWED_ORIGIN` are also exercised
+here, since this is a genuine browser submit from the production origin.)
+
+### 7.3 Burner booking (manual — can't be faked server-side)
+If booking is wired, the user books **one real "burner" appointment** through the production booking
+CTA and confirms it appears in GHL. A reachable widget URL is not proof.
+
+### 7.4 Done definition
+The funnel is done only when **7.1 passes clean**, **7.2's branded-URL contact landed with correct
+field values**, and **7.3's booking is confirmed** (when booking is wired). Otherwise it is not done —
+say what failed and stop. Don't call a funnel that thanks people while leads evaporate "done."
+
+---
+
+## 8. Quick checklist (run before calling any external funnel complete)
+- [ ] Capability gate shown; informed yes (non-technical users steered to GHL-native).
+- [ ] GHL side executed; `externalWiring.unresolved` is empty.
+- [ ] Form keyed by **verified `fieldId`s**; option values match GHL option values; consent field sent if messaging.
+- [ ] Honeypot present; Turnstile enabled for production.
+- [ ] Worker deployed by the user; `GHL_PIT` set as a secret by the user (never handled by the product).
+- [ ] `ALLOWED_ORIGIN` = production domain; fail-closed on non-2xx.
+- [ ] Site deployed preview → confirmed → promoted; live deployment never silently clobbered.
+- [ ] `verify_funnel` green (contact + fidelity + tag + non-draft + outreach + consent + dedup).
+- [ ] Real branded-URL browser submit landed with correct field values.
+- [ ] Burner booking confirmed in GHL (if booking wired).
+- [ ] Ownership/support facts stated to the operator.
+</content>
+</invoke>