@elitedcs/ghl-mcp 3.77.0 → 3.77.1

package/CHANGELOG.md

@@ -1,5 +1,41 @@
 # Changelog
 
+## 3.77.1 — the Blueprint can build a client account, and had been saying it could not
+
+If you ran the Blueprint, it planned the account, showed you the two checklists, and then
+printed this at the bottom:
+
+> _v1 stops here. When you approve, the automatic list is ready for one-shot staging (phase 2)._
+
+**That was wrong, and it had been wrong for months.** The Blueprint builds. You approve the
+plan, it dry-runs the automatic list without writing anything, shows you exactly what it
+would create, and on your go it builds: pipelines and stages, custom fields, tags, custom
+values, calendars, forms, funnel structure, templates, and workflows chained and verified,
+each object read back before anything that depends on it is created.
+
+The plan-only sentence was true of the first version. The builder was finished afterwards
+and nobody removed the old wording. It was in four files, and those files ship inside the
+package, so it has been on your machine reading the wrong thing to you the whole time.
+
+**Two of them were worse than a stale sentence.** One instructed the assistant to tell you
+execution was not available yet, so it was not merely present, it was being read out. And
+the description of `apply_build_plan` itself said `execute = live writes (not yet enabled)`
+three hundred lines above the code that performs those writes, which means an assistant
+reading that description could decline to run a build you had just asked for. Meanwhile the
+same skill file gave the correct build instruction further down, so it contradicted itself
+and the half you saw was the false one.
+
+**What has not changed is the gate.** Nothing is built until you say so, the dry run still
+writes nothing, and workflows are still created as drafts unless you ask for them
+published. The old wording carried that promise correctly, which is a large part of why the
+false half went unnoticed. The gate stays; only the claim that building does not exist is
+gone.
+
+A test now fails the build on any of the six ways this was phrased, anywhere in the skill or
+in that tool, so it cannot come back quietly.
+
+Counts unchanged: 248 tools, 51 modules, free tier 112.
+
 ## 3.77.0 — the account you aimed at, even when two things run at once
 
 `switch_location` used to change your API key first and your location a moment later.

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.77.0
+**Version:** 3.77.1
 
 ---
 

package/dist/index.js

@@ -36004,7 +36004,7 @@ function registerIntakeToBuildTools(server2, client, builderClient, registry2) {
       ).optional().describe("fromPreset only: client-specific copy overrides \u2014 subject/html for an email template, body for an SMS template. Copy ONLY; structure is never overridable. Overrides land on the template AND its reviewable asset. An unknown ref is an error, never a silent no-op."),
       useSavedPlan: import_zod75.z.boolean().optional().describe("Load the approved plan saved for the active location by an earlier execute (plans/<locationId>.json on this machine) instead of passing one. The right choice for ANY re-run: re-authoring a plan drifts and duplicates objects."),
       replaceSavedPlan: import_zod75.z.boolean().optional().describe("Only with a new `plan` whose planId differs from the saved one: confirms the operator approved the new plan, so it replaces the saved plan on execute. Without it, a differently named plan is refused while a saved plan exists."),
-      mode: import_zod75.z.enum(["dry_run", "execute"]).optional().describe("dry_run (default) = resolve/expand/scan/report, no writes. execute = live writes (not yet enabled)."),
+      mode: import_zod75.z.enum(["dry_run", "execute"]).optional().describe("dry_run (default) = resolve/expand/scan/report, no writes. execute = live writes. Run dry_run FIRST, show the operator the report, and run execute only on their go."),
       locationId: import_zod75.z.string().optional().describe("Target sub-account. MUST match the active location; if it differs the tool refuses (confirm/switch first)."),
       metHandoffs: import_zod75.z.array(import_zod75.z.string()).optional().describe('Handoff refs the operator has already satisfied (e.g. ["handoff.a2p"]) \u2014 lifts their gate so dependent workflows are not held DRAFT.'),
       publishWorkflows: import_zod75.z.boolean().optional().describe("If true, ungated workflows would be published instead of left DRAFT. Default false (DRAFT)."),
@@ -37360,7 +37360,7 @@ var require_package = __commonJS({
   "package.json"(exports2, module2) {
     module2.exports = {
       name: "@elitedcs/ghl-mcp",
-      version: "3.77.0",
+      version: "3.77.1",
       mcpName: "io.github.drjerryrelth/ghl-command",
       description: "GoHighLevel MCP Server for Claude. 248 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.77.0",
+  "version": "3.77.1",
   "mcpName": "io.github.drjerryrelth/ghl-command",
   "description": "GoHighLevel MCP Server for Claude. 248 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

@@ -2,7 +2,7 @@
 
 Blueprint turns a new client's intake into a complete, reviewable GoHighLevel build plan for that client's sub-account, then hands you two checklists: what GHL Command will build for you, and what you have to do yourself, in order. It plans. You approve. Nothing is built until you say so.
 
-v1 produces the reviewable build plan and the two-part checklist, and stops at the approval gate. One-shot auto-build is the next phase.
+The skill produces the reviewable build plan and the two-part checklist, and stops at the approval gate. On your approval it builds the automatic list for you through `apply_build_plan`: a dry run first, which writes nothing and reports exactly what it would create, then the live build on your go.
 
 ## Install
 

package/skills/blueprint/SKILL.md

@@ -8,9 +8,9 @@ compatibility: Claude Code, Claude Cowork, Claude.ai
 
 You are a **senior GoHighLevel solutions architect**. You turn a client's intake into a complete, build-ready account plan — clean, minimal, every automation wired to fire, in the order it must be built so nothing references a dead ID. You have one professional obsession: the GHL silent-failure bug, where an action points at a pipeline, stage, field, or workflow whose ID no longer exists and GHL skips it and everything beneath it with no error and a workflow that still shows green. You design so that can never happen.
 
-This skill produces a **build plan** (the contract in `references/brief-schema.md` and `references/build-plan-schema.md`) and renders it for human review. It runs against whatever account `get_current_location` returns. **It does not execute anything in v1** — it stops at the approval gate. Execution (`apply_build_plan`) is phase 2, owned by the MCP.
+This skill produces a **build plan** (the contract in `references/brief-schema.md` and `references/build-plan-schema.md`) and renders it for human review. It runs against whatever account `get_current_location` returns. **This skill itself never writes to the account** — it stops at the approval gate. Building is done by the MCP's `apply_build_plan`, which is live: after approval you run it `mode:"dry_run"` first, show the report, and only on the operator's go run `mode:"execute"` (STEP 9 below).
 
-> Account-agnostic, always. No hardcoded IDs, no dependency on any specific agency's stack. The plan carries symbolic **refs** (`pipeline.main`, `stage.new_lead`), never real GHL IDs. The phase-2 executor resolves ref → id at build time, after each object is created and verified. That is what kills the silent-failure class.
+> Account-agnostic, always. No hardcoded IDs, no dependency on any specific agency's stack. The plan carries symbolic **refs** (`pipeline.main`, `stage.new_lead`), never real GHL IDs. The executor resolves ref → id at build time, after each object is created and verified. That is what kills the silent-failure class.
 
 ## The pipeline you run
 

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

@@ -6,7 +6,7 @@ STATUS: v1, 2026-06-15. Owner: atlas. The required render: the v1 deliverable is
 - **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.
+- Nothing is built until the operator approves. Say so explicitly at the bottom, and say what happens next: a dry run that writes nothing, then the live build on their go.
 - 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.)
 
@@ -72,7 +72,7 @@ _Total: <X> objects across <Y> types._
 
 ---
 
-_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._
+_Nothing has been built yet. When you approve, the automatic list is staged for you: a dry run first, which writes nothing and reports exactly what it would create, then the live build on your go. Each step above is verified before the steps that depend on it run._
 ```
 
 ## Render notes