@koda-sl/baker-cli 0.414.0 → 0.415.0

package/README.md

@@ -3576,6 +3576,14 @@ baker flows schema side-effect googleSpreadsheet
 
 baker flows add-node contact --type text --name "Thanks"
 baker flows add-side-effect contact --node <nodeId> --type googleSpreadsheet   # triggerId comes from the step
+baker flows connect contact --side-effect se-hubspotForm-1 --hubspot-form <formId>   # attach the connected HubSpot account + form, no card
+baker flows connect contact --all --hubspot-form <formId>   # every hubspotForm step still unwired, one call
+baker flows options calendly                        # what a step/destination can use: calendly, savvycal, highlevel, highlevelForm, googleSpreadsheet
+baker flows connect contact --node book --resource <id>          # fill a Calendly/SavvyCal/GoHighLevel step yourself
+baker flows connect contact --side-effect se-gsheet-1 --resource <spreadsheetId>   # a sheet Baker can reach (--tab to pick the tab)
+baker flows connect contact --side-effect se-gsheet-1 --new-sheet "Contact leads" --columns "Name,Email"   # create one and wire it
+baker flows connect contact --side-effect se-pipedrive-1         # Pipedrive / GoHighLevel contact: the account is the destination
+baker flows connect contact --all --type googleSpreadsheet --same-as madrid:se-gsheet-1   # copy another Form's destination
 baker flows map contact --from map.json --write     # a whole mapping at once — past ~3 fields, use this
 baker flows map contact --map A=nombre --write      # one or two fields
 baker flows map contact --hubspot-form <guid> --from map.json --write   # HubSpot: field types read off the form
@@ -3587,7 +3595,9 @@ baker flows normalize contact --write              # repairs a nulled optional;
 Notes:
 
 - **`schema` takes the kind as an argument because `hubspot` is both** — a node type (embeds a form on the page) and a side-effect type (fires a behavioural event). They are different things with one name.
-- **Configure the destination before you map.** `columnMapping`/`fieldMapping` describe a *specific* destination — sheet columns, a portal's field names — that only `request_flow_input` can see, and that call returns it. A mapping written first is valid JSON that ships and drops every submission; `verify` blocks the half-wired result.
+- **`connect` wires a HubSpot form without asking the user.** When HubSpot is connected and the agent knows which form is meant, `baker flows connect <slug> --hubspot-form <formId> [--side-effect <id>]` attaches the account and the form to a `hubspotForm` side effect (`--all`: every one in the Form still missing it, never repointing one already wired) — the same thing the chat card writes, sealed by Baker so the config never passes through the agent. It refuses a form with spam prevention (captcha) on, and returns `destination.formGuid` for `map --hubspot-form`. The card (`request_flow_input`) stays for an unconnected account or an ambiguous choice.
+- **`options` + `connect` do the same for every other connected platform.** `baker flows options <kind>` lists what the connected account holds (Calendly events, SavvyCal links, GoHighLevel calendars and forms, the Google spreadsheets Baker can reach); `connect --node|--side-effect <id> --resource <id>` writes exactly what the card would. Pipedrive and a GoHighLevel contact take no resource. `--new-sheet` creates a spreadsheet in the connected Google account (Google only lets Baker reach sheets it created or the user chose), `--same-as <slug>:<id>` copies another Form's wired destination, `--all --type <kind>` fills every unwired one of a kind. Nothing connected answers `NOT_CONNECTED` with the `request_connection` fix; several accounts connected need `--account <id>`.
+- **Configure the destination before you map.** `columnMapping`/`fieldMapping` describe a *specific* destination — sheet columns, a portal's field names — that only `connect` or `request_flow_input` can set, and both return it. A mapping written first is valid JSON that ships and drops every submission; `verify` blocks the half-wired result.
 - **`map` reads the record shape off the side effect's type.** One property name, four record shapes: a Sheet is addressed by column letter, HubSpot by property name, Pipedrive and GoHighLevel by field key, Crmble by field id. That is why there is no `--key`, and why `--entity` and `--custom`/`--standard` are required rather than defaulted.
 - **A mapping is usually eight to fifteen fields, so `--from` is the main door.** It takes `{ "map": { "<destField>": "<value>" } }` from a file or stdin; `--map` flags are for one or two. Both produce identical output.
 - **Most CRM fields are not fed by a form field.** The value grammar is a bare form field (`nombre`), `field:Step.name` when two steps share a name, `tracking:utm_source`, `global:Name`, `code:exposed_value`, a `"literal"`, or any of those joined with `+`. Tracking names are validated against the engine's own `TRACKING_FIELD_IDS`, read out of the workspace rather than copied — attribution columns are the most common CRM mapping there is, and they were unexpressible before.