@elitedcs/ghl-mcp 3.83.0 → 3.83.1

package/CHANGELOG.md

@@ -2,6 +2,21 @@
 
 ## Unreleased
 
+## 3.83.1 — the Blueprint skill stops asking for the funnel 3.83.0 removed
+
+3.83.0 took funnels out of Blueprint installation, but the installed skill was not
+updated with it. `skills/blueprint/SKILL.md` still listed `funnels` among the arrays
+its plan must carry, and still asked "Build this funnel inside GoHighLevel, or as a
+custom site you host?" with GoHighLevel as the stated default. The skill ships inside
+the package, so anyone running Blueprint produced a plan carrying a key their own
+plan format forbids and their own build step refuses.
+
+The skill and its README now say plainly that Blueprint builds no funnel, page or
+website, and that pages are a separate job after the account exists, on hosting the
+member owns. A test pins the skill and the plan format together so they cannot
+disagree again.
+
+
 ## 3.83.0 — a build you can check, and no funnel at the end of it
 
 **Blueprint no longer builds a funnel, a page, or a website of any kind.** GoHighLevel's own page

package/README.md

@@ -897,7 +897,7 @@ Built by **[Elite DCs, LLC](https://elitedcs.com)** — a digital marketing and
 
 **Tech stack:** TypeScript, Node.js, esbuild, MCP SDK, Zod, GHL API v2, Firebase Auth
 
-**Version:** 3.83.0
+**Version:** 3.83.1
 
 ---
 

package/dist/index.js

@@ -28540,7 +28540,7 @@ var require_package = __commonJS({
   "package.json"(exports2, module2) {
     module2.exports = {
       name: "@elitedcs/ghl-mcp",
-      version: "3.83.0",
+      version: "3.83.1",
       mcpName: "io.github.drjerryrelth/ghl-command",
       description: "GoHighLevel MCP Server for Claude. 250 tools \u2014 full CRM, automation, marketing control, account-wide workflow audit, live funnel-capture verification, and the only programmatic GHL workflow builder, now multi-tenant across client accounts.",
       main: "dist/index.js",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@elitedcs/ghl-mcp",
-  "version": "3.83.0",
+  "version": "3.83.1",
   "mcpName": "io.github.drjerryrelth/ghl-command",
   "description": "GoHighLevel MCP Server for Claude. 250 tools — full CRM, automation, marketing control, account-wide workflow audit, live funnel-capture verification, and the only programmatic GHL workflow builder, now multi-tenant across client accounts.",
   "main": "dist/index.js",

package/skills/blueprint/README.md

@@ -17,11 +17,13 @@ The skill produces the reviewable build plan and the two-part checklist, and sto
 
 ## What you get back
 
-- A build plan for the account: pipeline and stages, custom fields, tags, the intake form, a funnel outline, email and SMS sequences, and the workflows that wire them together.
+- A build plan for the account: pipeline and stages, custom fields, tags, the intake form, email and SMS sequences, and the workflows that wire them together. Blueprint does not build a funnel, a page or a website.
 - Two checklists: what Blueprint will build automatically once you approve, and what only you can do in the GHL UI or with an outside service (A2P, Stripe, calendar, phone number, sending domain), in the order you need to do it.
 
 Every reference in the plan is a name, not a raw GoHighLevel ID. That is what stops the silent-failure bug where one dead ID skips every action under it and the workflow still shows green.
 
-## Funnels: GHL-native or your own site
+## Pages and funnels are a separate job
 
-Each funnel can be built **inside GoHighLevel** (the default — zero setup on your part) or as a **custom site you host** on Cloudflare/Vercel and wire back to your GHL sub-account. The external path is for technically-capable users: you need your own host account + CLI, a GHL Private Integration token you store as a host secret, and comfort with a one-time command-line deploy. Blueprint generates the site, hands you the exact verified wiring values, and runs a live verification gate, but it never deploys for you or holds your keys. If that's not you, pick GHL-native and everything still works.
+Blueprint sets up the account. It does not build a funnel, a page or a website of any kind, and a plan that asks for one is refused rather than half-built. GoHighLevel's own page builder was not good enough to hand a client, so it was taken out.
+
+When you do want pages, that is its own job after the account exists: a **custom site you host** on Cloudflare or Vercel and wire back to your sub-account. It is for technically-capable users. You need your own host account and CLI, a GHL Private Integration token you store as a host secret, and comfort with a one-time command-line deploy. The product generates the site, hands you the exact verified wiring values, and runs a live verification gate, but it never deploys for you and never holds your keys.

package/skills/blueprint/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: blueprint
-description: Turn a GHL Command client intake into a complete, reviewable GoHighLevel account build plan — the GHL Command Blueprint. Detects Agency OS for a deeper brief (else uses the built-in intake form), selects an industry preset, generates a structured build plan (pipeline, fields, tags, calendar, form, funnel, email/SMS, workflows) with symbolic refs not real IDs, and renders a two-part approval checklist (what GHL Command builds automatically vs. what you must do manually, in order). The plan stops at the human approve gate; GHL-native staging then runs via apply_build_plan. Each funnel can be GHL-native (default) or an external site the user hosts (Cloudflare/Vercel) and wires back to GHL — a power-user, capability-gated lane that generates the site, injects verified field IDs, walks the user through their own deploy, and finishes only when verify_funnel passes on the real URL. Triggers on build my Blueprint, run Blueprint, GHL Command Blueprint, build a client account, watch it build a client, new client account, client onboarding build, build plan, account build spec, external funnel, host my own funnel.
+description: Turn a GHL Command client intake into a complete, reviewable GoHighLevel account build plan — the GHL Command Blueprint. Detects Agency OS for a deeper brief (else uses the built-in intake form), selects an industry preset, generates a structured build plan (pipeline, fields, tags, calendar, form, email/SMS, workflows) with symbolic refs not real IDs. Blueprint does not build funnels, pages or websites of any kind, and renders a two-part approval checklist (what GHL Command builds automatically vs. what you must do manually, in order). The plan stops at the human approve gate; GHL-native staging then runs via apply_build_plan. Pages and funnels are a separate job after the account exists, on hosting the member owns. Triggers on build my Blueprint, run Blueprint, GHL Command Blueprint, build a client account, watch it build a client, new client account, client onboarding build, build plan, account build spec, external funnel, host my own funnel.
 compatibility: Claude Code, Claude Cowork, Claude.ai
 ---
 
@@ -17,7 +17,7 @@ This skill produces a **build plan** (the contract in `references/brief-schema.m
 ```
 Detect brief source ─► Source the brief (§2A) ─► Select preset ─► Fill skeleton ─► Derive handoffs ─► Generate copy ─► Assemble plan (per-funnel target) ─► Quality gate ─► Render approval view
                                                                                                                               │
-   external funnel only, AFTER approval ──────────────────────────────────────────────────────────────────────────────────►│ stage GHL side (apply_build_plan) ─► generate + inject site ─► deploy preview→confirm→promote ─► verify_funnel gate ─► done
+   pages/funnels: SEPARATE, after the account    ──────────────────────────────────────────────────────────────────────────────────►│ stage GHL side (apply_build_plan) ─► generate + inject site ─► deploy preview→confirm→promote ─► verify_funnel gate ─► done
 ```
 
 Read `references/preset-format.md` once; it defines the tokens (`{{...}}`), `conditionalOn`, `fillFrom`, and `copyDirection` you will resolve. Read `references/agency-os-detection.md` for the brief-source decision. Read `references/approval-view.md` for the final render. Read `references/external-funnel.md` only when a funnel is `target: "external"` (the capability gate + site gen/deploy + verify lane).
@@ -80,7 +80,7 @@ Default for REVIEW: **outlines** (`subject` + `bodyOutline` + `mergeTags` for em
 
 ## STEP 7 — Assemble the plan (§5)
 
-Emit a §5-conforming object: `schemaVersion`, `planId`, `briefId`, `preset`, `summary`, then the object arrays (`pipelines`, `customFields`, `tags`, `customValues`, `calendars`, `forms`, `funnels`, `emails`, `sms`, `workflows`, `handoffs`), `buildOrder`, and an empty `idMap`. Keep strictly to contract fields (the MCP validators may be strict). Record provenance (preset id + version, brief source) in the `summary` text, not as an extra field. Use GHL-correct enums: `dataType` ∈ {TEXT, LARGE_TEXT, NUMERICAL, PHONE, **MONETORY**, CHECKBOX, SINGLE_OPTIONS, MULTIPLE_OPTIONS, FLOAT, DATE, TEXTBOX_LIST, FILE_UPLOAD, SIGNATURE}; `calendarType` ∈ {round_robin, event, class_booking, collective, service_booking}.
+Emit a §5-conforming object: `schemaVersion`, `planId`, `briefId`, `preset`, `summary`, then the object arrays (`pipelines`, `customFields`, `tags`, `customValues`, `calendars`, `forms`, `emails`, `sms`, `workflows`, `handoffs`) — **never a `funnels` key, not even an empty one: the plan schema forbids it and `apply_build_plan` halts on it**, `buildOrder`, and an empty `idMap`. Keep strictly to contract fields (the MCP validators may be strict). Record provenance (preset id + version, brief source) in the `summary` text, not as an extra field. Use GHL-correct enums: `dataType` ∈ {TEXT, LARGE_TEXT, NUMERICAL, PHONE, **MONETORY**, CHECKBOX, SINGLE_OPTIONS, MULTIPLE_OPTIONS, FLOAT, DATE, TEXTBOX_LIST, FILE_UPLOAD, SIGNATURE}; `calendarType` ∈ {round_robin, event, class_booking, collective, service_booking}.
 
 Workflow actions stay **logical** (type + key params + refs). Do not emit GHL-native action JSON — the executor expands logical actions via `action-schemas.json` and owns the failure-prone shapes (`internal_update_opportunity` node-level discriminator, `internal_notification`/task-notification nesting, `remove_from_workflow` dual id, `wait` `startAfter`, `attachments:[]`, `html` vs `body`, node `next`/`parentKey` chaining). All object pointers are refs. Max 40 actions per workflow; split longer flows into linked + exit workflows.
 
@@ -90,7 +90,7 @@ Workflow actions stay **logical** (type + key params + refs). Do not emit GHL-na
 
 **Branching + appointment-relative actions.** `find_opportunity` is the only branching action and MUST be the last action in its workflow (its found/notFound branches do not rejoin). `wait_appointment` ("N before the appointment") only works in a workflow with an `appointment` trigger. The MCP validator enforces both, plus unique object names within each type and a 40-node cap (a workflow containing a `find_opportunity` branch cannot be auto-split).
 
-**Per-funnel target (GHL-native vs external).** For each funnel, set `target` ∈ `ghl` (default) / `external` (+ `host`/`domain` when external). Ask once per funnel: "Build this funnel inside GHL, or as a custom site you host on Cloudflare/Vercel and wire back to GHL?" The brief may pre-answer. **The instant a funnel is set to `external`, run the capability gate in `references/external-funnel.md` §1** — plainly state the required access (own host account + CLI, a GHL Private Integration token they store as a host secret, comfort with a one-time CLI deploy, optional domain/DNS) and say outright it is for technically-capable users; if that is not them, steer to `target: "ghl"`. Default GHL; never assume dev skills. The chosen target renders per funnel in the approval view (external = the power-user path, with ownership facts).
+**Blueprint builds no funnel, page or website.** GoHighLevel's own page builder was not good enough to hand a client, so it was removed from installation: the plan schema forbids a `funnels` key and `apply_build_plan` halts on one. Never ask which way to build a funnel and never put one in the plan. If the brief asks for pages or a funnel, say plainly that Blueprint sets up the account and that pages are a separate job afterwards, on hosting they own, wired back to the account. That lane is STEP 10 and it runs only after the account exists and the plan is approved.
 
 ## STEP 8 — Quality gate (run on yourself before showing anything)
 
@@ -115,9 +115,9 @@ Invite edits (rename / drop / reorder / adjust). Re-render after edits. End by s
 
 **Workflows default to DRAFT — prompt before publishing.** `apply_build_plan` builds workflows DRAFT unless `publishWorkflows:true`. Before any workflow goes live, ASK the operator: "Publish these now, or leave them DRAFT for review?" Pass `publishWorkflows:true` only on an explicit yes. Workflows gated by an unmet handoff (e.g. SMS workflows behind `handoff.a2p`) never auto-publish even when opted in; pass satisfied handoffs in `metHandoffs` to lift their gate. If any funnel is `target: "external"`, also run STEP 10 after approval.
 
-## STEP 10 — External funnel lane (only if a funnel is `target: "external"`)
+## STEP 10 — Pages and funnels: a separate job, after the account
 
-For each external funnel, run the lane in `references/external-funnel.md` after approval. Summary:
+Only when the member asks for pages after the account is built. Never part of the plan. Run the lane in `references/external-funnel.md`. Summary:
 1. **Stage the GHL side.** Confirm the active sub-account, then `apply_build_plan` `mode:"dry_run"` → show the report → on the operator's go, `mode:"execute"`. Capture the returned `externalWiring` bundle (verified custom-field IDs, `bookingUrl`, trigger tag) and the speed-to-lead workflow id. If `externalWiring.unresolved` is non-empty, stop and re-run execute — never wire a form to an unresolved field.
 2. **Generate + inject the site.** Generate the site with `frontend-design` from the page outlines + brand. Inject the lead form keyed by the bundle's **verified `fieldId`s** (custom fields under `custom: {<fieldId>: value}`, never name-guessed; option values must match GHL option values), the `bookingUrl` into the booking CTA, a honeypot, and Turnstile for production. Fail closed (never a silent success).
 3. **Deploy — the user runs every command; the product deploys nothing and never handles the token.** Scaffold `wrangler.toml` (vars only); the user sets `GHL_PIT` as a host secret themselves. Deploy to a preview URL → confirm → promote to production. Never silently clobber a live deployment.