@elitedcs/ghl-mcp 3.72.0 → 3.72.2

package/CHANGELOG.md

@@ -1,5 +1,66 @@
 # Changelog
 
+## 3.72.2 — a form you read back can be saved again
+
+A subscriber tried to edit one of her forms the documented way: read it with
+`get_form_full`, change one thing, hand it back to `update_form`. It was refused. She
+tried again from an exact copy of the payload. Refused again. Then she found it herself,
+stripped one key by hand, and the identical edit saved first time.
+
+She was right. GoHighLevel's form builder writes every custom field with the field's id
+under two spellings, `Id` and `id`, holding the same value. On her form 42 of 58 fields
+carried the pair; standard fields like name and email never do. Sitting in GoHighLevel it
+is harmless. The trouble starts on the way back out, because editing a form means
+repeating the whole document, and a document that says the same id twice per field, once
+capitalised and once not, is asking to be repeated wrongly.
+
+**`get_form_full` now returns one of them, and `update_form` accepts either.** A key is
+dropped only when another key beside it means the same thing in a different case and
+holds exactly the same value, so nothing is lost: the value is still there under the
+name that survives. Where two such keys hold *different* values, both are kept, because
+that is real information and picking one would be a guess. Forms built by the intake
+installer are unaffected; they save by a different route and were never part of this.
+
+If you have been working around this by hand, you can stop. Proven before release
+against a real form on a live account: saved with both spellings, saved again with one,
+edit kept, every custom field intact.
+
+Counts unchanged: 247 tools, 51 modules, free tier 111.
+
+## 3.72.1 — a client's work stops shipping in the package
+
+An audit of the published 3.72.0 tarball found somebody else's proprietary material
+inside it. Not a leak of customer data, and nobody did it on purpose: the packaging
+allow-list named `skills` as a whole directory, so every file that landed in that folder
+published itself along with the release.
+
+What was in there. A launch-event preset built from a partner agency's own client
+blueprint, their compliance playbook and a protected live account: ten named workflows,
+twenty-five custom values, an event calendar and the whole compliance handoff chain.
+Three more presets credited real client accounts by name in their provenance lines. The
+compiled bundle carried a real GoHighLevel account id with a label identifying whose it
+was, and one shipped example held a real sandbox id.
+
+That preset stays in the source tree, because it is a legitimate tool for the agency that
+wrote it. It is now excluded from what gets published. Every client and partner name is
+out of the published files, and the two account lists that used to be compiled into the
+bundle now come from `account-rules.json` in your own application-support directory. A
+fresh install declares no accounts at all, which is the stricter default: without a
+declared practice account every account needs an explicit recorded approval before
+anything is built, and an account you mark off-limits is refused even when an approval
+exists.
+
+Engineering comments recording where a workflow shape was captured are untouched. They
+live in source that is never published, and they are how the next person knows a node
+shape came from a real account rather than a guess.
+
+A new check reads the actual file list `npm pack` would publish and fails the build if a
+client name, a real-looking account id, or a file on the never-publish list appears in it.
+It caught two files that a careful pass by hand had already missed.
+
+Counts unchanged: 247 tools, 51 modules, free tier 111. No tool behaviour changed.
+
+
 ## 3.72.0 — an audit that counts your workflows once
 
 A member ran the account audit on a large agency account. The report came back claiming
@@ -2494,7 +2555,7 @@ Two bugs caught when exercising v3.4.0's `health_check` and `validate_workflow`
 Also: `src/index.ts` startup `validateApiKey()` had the same wrong-endpoint bug as `health_check`; fixed for consistency. Buyers will now see "API key validated" or a clear 403 message on startup instead of silent ambiguity.
 
 ### Verified end-to-end
-Re-ran the spawn-handshake test against QA Test Clinic v3:
+Re-ran the spawn-handshake test against a protected account:
 - `health_check` returns 5/5 PASS ("All systems go.")
 - `validate_workflow` on the CLL Onboarding Form Submitted workflow correctly scans 2 references (form.id + self-referencing workflow.id), reports 0 issues, surfaces the self-reference as an informational note.
 
@@ -2634,7 +2695,7 @@ For Claude that means: when you ask it to read, build, or edit a workflow using
 | v3.2.0 | **13** | **44** | 57 |
 
 ### Round-trip verified
-- Real `form_submission` workflow from QA Test Clinic v3 parses cleanly through the new typed variant.
+- Real `form_submission` workflow from a protected account parses cleanly through the new typed variant.
 - 8 synthetic typed-trigger samples match their respective variants and are correctly rejected by sibling variants (discrimination works as expected).
 
 ### Files changed