@elitedcs/ghl-mcp 3.72.1 → 3.72.3

package/CHANGELOG.md

@@ -1,5 +1,56 @@
 # Changelog
 
+## 3.72.3 — the waits in a built account can actually go live
+
+Blueprint builds a client's account and then asks whether to publish the workflows or
+leave them as drafts for review. Say publish, and the ones with a wait of a day or more
+were refused by GoHighLevel and stayed as drafts. The build still reported them as
+created, so the account looked finished when the follow-up sequences were not running.
+
+The cause was one word. GoHighLevel takes `minutes` and `hour`, but for days it wants
+`days`, and we were sending `day`. It is not a rule you can guess: a workflow that is
+nothing but a wait accepts the singular quite happily, which is why this went unnoticed.
+It only fails on the shape a real nurture has, a message followed by a wait, which is
+every follow-up sequence the presets build. **123 of the waits in the shipped presets
+were affected.**
+
+Workflows already in an account are untouched and keep working; this was only ever about
+newly built ones.
+
+**The second half is the reporting.** A workflow that could not be published was still
+counted as built, and the summary read the same as a run where nobody asked to publish at
+all: it suggested turning on publishing, to someone who had just turned it on. The real
+reason sat further down the report where nobody looks first. A build now says plainly
+which workflows could not be published, what GoHighLevel said about each, that they are
+sitting as drafts and not running, and that repeating the build will not help.
+
+## 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