@elitedcs/ghl-mcp 3.76.0 → 3.77.1

package/guide/guide.html

@@ -4,7 +4,7 @@
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>GHL Command — User Guide</title>
-<!-- guides-hash: a372a7f6a8ce5823 -->
+<!-- guides-hash: 2bcfa41ad790fe7c -->
 <style>
 /* Deliberately light in every environment, including a dark-mode OS. This is a
    reference document people read at length, print, and save to PDF, and a page

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@elitedcs/ghl-mcp",
-  "version": "3.76.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