@koda-sl/baker-cli 0.170.0-dev.9ace16483 → 0.173.0-dev.6ecd65d29

package/README.md

@@ -1047,7 +1047,7 @@ Each finding: `{id, area, check, status, severity, evidence, fix: {explanation,
 
 - OAuth tokens auto-refresh server-side. On 401, reconnect LinkedIn from dashboard → integrations.
 - Account scoping: backend rejects calls against an account not in the picker selection.
-- Pinned API version: `Linkedin-Version: 202604` (declared in `oauth/constants.ts`). Bump as a coordinated change — LinkedIn deprecates monthly with a ~12-month support window.
+- Pinned API version: `Linkedin-Version: 202606` (declared in `oauth/constants.ts`). Bump as a coordinated change — LinkedIn deprecates monthly with a ~12-month support window. The floor is `TRACKING_PARAM_DYNAMIC_MIN_API_VERSION` (`CREATIVE_NAME` needs 202606), asserted in `ads/linkedin/utils.test.ts`.
 - Cache TTLs: accounts/account-detail 1h, listings 30m, analytics 15m–6h (depends on date range), facets 7d, urn-resolve 1h, bid-pricing/forecast 6h, audience-size 1h.
 - `--skip-cache` (server-side) and `--no-cache` (client-side, where supported) on any command.
 
@@ -1159,46 +1159,6 @@ baker ga4 query --dimensions "date,sessionSourceMedium" --metrics "sessions,conv
 
 ---
 
-### Alarms (`baker alarm`)
-
-How an unattended run reaches a human about something that cannot wait until tomorrow. This is the only thing that interrupts someone out of hours — anything that can wait is `baker actions create --priority urgent`.
-
-Every alarm must carry the evidence that contradicts everything being fine, and the backend **refuses** it when the evidence does not. An all-zeros analytics reading is not evidence on its own: broken tracking, no traffic, a dead page and a failed check all look identical. Paid clicks over the same window are what turn zeros into proof.
-
----
-
-### `baker alarm raise`
-
-Wake a human. Reasons: `tracking_broken`, `spend_anomaly`, `access_lost`, `site_down`.
-
-```bash
-baker alarm raise --reason tracking_broken --url https://acme.com/demo --window-hours 24 \
-  --analytics-answered true --sessions 0 --clicks 47 --spend-micros 82000000
-
-baker alarm raise --reason site_down --url https://acme.com/demo --http-status 503   # 'none' if it never responded
-baker alarm raise --reason spend_anomaly --platform google-ads --window-hours 24 \
-  --spend-micros 400000000 --baseline-spend-micros 50000000
-baker alarm raise --reason access_lost --platform google-ads --provider-error "USER_PERMISSION_DENIED"
-```
-
-`--analytics-answered false` means the provider errored, timed out, or the token expired. That is **not** zero sessions, and the gate refuses it — otherwise a broken check pages somebody about the client's tracking.
-
-Response: `raised: true` (a human was contacted), `deduped: true` (already open — counted, not re-sent), or `raised: false` with a `refusal` explaining what the evidence failed to show. Repeats for an open condition never page twice.
-
----
-
-### `baker alarm checked`
-
-Record that a check came back clean.
-
-```bash
-baker alarm checked --reason tracking_broken --scope "6 landings"
-```
-
-Run it whenever a check finds nothing. Without it, "nothing was wrong" and "nobody looked" are the same silence. It never closes an alarm somebody was already woken for — one clean reading does not prove a fix.
-
----
-
 ### Google Search Console (`baker gsc`)
 
 GSC commands for PPC-SEO arbitrage, brand halo analysis, and negative keyword discovery.
@@ -2706,7 +2666,7 @@ Permissions enforced server-side:
 
 ### `baker mcp connected | list | add | remove`
 
-See every third-party tool a chat can reach (managed integrations + custom servers) and manage **custom MCP servers** — point the agent at any remote HTTPS MCP endpoint. Registered tools appear as `mcp__<name>__*` on the next chat message.
+See everything a chat can reach — managed integrations, custom servers, and connected platforms — and manage **custom MCP servers** by pointing the agent at any remote HTTPS MCP endpoint. Registered tools appear as `mcp__<name>__*` on the next chat message.
 
 ```bash
 baker mcp connected
@@ -2717,6 +2677,7 @@ baker mcp add --name mine --url https://my.dev/mcp --scope user
 baker mcp remove --name weather
 ```
 
+- `connected` returns three lists. `managed` and `custom` are MCP tools the agent calls directly; `platforms` are the accounts the company signed in to (HubSpot, Google Ads, GA4, Search Console, Tag Manager, LinkedIn Ads), each with its login and the resources it may read. A platform has **no** `mcp__*` tools — it is read through its own command family — so it is listed here to keep the agent from concluding a working connection is missing.
 - `--url` must be the **full MCP endpoint** (commonly ending in `/mcp`), HTTPS and public; loopback / private / cloud-metadata hosts are rejected. A bare domain frequently accepts the OAuth sign-in and then serves no tools, so every address is handshake-checked after it changes: `connected` and `list` report `usable: false` plus a `problem` (and a `suggestedAddress` when the server advertises a better endpoint) for a server that isn't serving tools, or `lastCheck: failed` when the last check only hit an outage — that one may work anyway, and a later turn re-checks it automatically. Repointing a server at a different host clears its saved sign-in: a token belongs to the host that issued it, so the server has to be connected again.
 - Scope is two independent choices — audience (just you / everyone) × level (this company / whole org):
   - `--scope company` (default) — everyone in this company.
@@ -2763,9 +2724,9 @@ baker history list --category ads --full    # ad writes with raw metadata
 
 ---
 
-### `baker hubspot forms list | view` · `baker hubspot meetings list | view`
+### `baker hubspot forms list | view | submissions` · `baker hubspot workflows list` · `baker hubspot pipelines list` · `baker hubspot contacts summary | lookup` · `baker hubspot meetings list | view`
 
-Read-only view of the company's **connected HubSpot account** — the forms and meeting links (calendars) that live there, plus the settings inside HubSpot that decide how each behaves once placed in a Form. Fetched from HubSpot live on every call; nothing is cached.
+Read-only view of the company's **connected HubSpot account** — the forms and meeting links (calendars) that live there, the leads those forms received, and the workflows, deal pipelines, and contact records a lead runs through afterwards. Fetched from HubSpot live on every call; nothing is cached and nothing is ever written back.
 
 The reason this exists: a form's **post-submit action** (inline thank-you vs redirect to a URL), its embed version, its consent mode, and a calendar's booking fields are *not* persisted onto the flow node when a form is picked. They cannot be read from `_data.json` or `baker flows show` — only from here.
 
@@ -2776,6 +2737,12 @@ baker hubspot forms list --embed-type legacy    # only legacy-embed forms
 baker hubspot forms view <formId>               # fields, consent mode, full configuration
 baker hubspot forms view <formId> --full        # + the raw HubSpot payload
 baker hubspot forms view <formId> --as-node     # the form.external blob for a flow node
+baker hubspot forms submissions <formId>        # how many leads it received, and when
+baker hubspot forms submissions <formId> --days 90 --full
+baker hubspot workflows list --enabled-only     # what runs after a lead is captured
+baker hubspot pipelines list                    # where a lead lands, and the stages after it
+baker hubspot contacts summary --days 30        # are recent leads being worked? (counts only)
+baker hubspot contacts lookup lead@example.com  # was this one lead picked up?
 baker hubspot meetings list                     # every calendar + whether booking redirects
 baker hubspot meetings view <slug>              # booking-form fields for one calendar
 baker hubspot meetings view <slug> --as-node    # the form.external blob for a flow node
@@ -2783,9 +2750,16 @@ baker hubspot meetings view <slug> --as-node    # the form.external blob for a f
 
 **`forms list` flags:** `--search <text>` (name substring), `--redirecting-only`, `--embed-type legacy|v4|unknown`. Rows carry only what it takes to choose; `portalId` is returned once on `data`, not per row.
 **`forms view`:** positional `<formId>`; `--full` adds the untouched HubSpot payload; `--as-node` returns the resource blob instead of the readable view.
+**`forms submissions`:** positional `<formId>`; `--days <1-365>` (default 30) sets the window; `--full` adds each submission's field values. The default response is counts and dates only — `total`, `inWindow`, `lastSubmittedAt`, and per-day counts — because submissions carry the lead's own contact details. `truncated: true` means the page budget ran out before the window was covered, so `inWindow` is a floor rather than an exact count.
+**`workflows list` flags:** `--search <text>`, `--enabled-only`. Disabled workflows are listed too — a form wired to one that is off looks connected and does nothing.
+**`pipelines list`:** no flags; stages come back in the order they run in HubSpot.
+**`contacts summary` flags:** `--days <1-365>` (default 30) over contact creation date. Returns counts only — total contacts, how many have an owner, and the lifecycle-stage split — never a name or an email. `truncated: true` means the page budget ran out, so the counts are floors.
+**`contacts lookup`:** positional `<email>`; returns that contact's lifecycle stage, owner, the account (company) it was filed under, and associated deals with their stage. `companyReadable: false` means the connection does not cover accounts, so a null `company` is unknown rather than absent. `found: false` means no contact with that email — the lead never reached the CRM, which is a finding rather than an error.
 **`meetings list` flags:** `--search <text>`, `--redirecting-only`.
 **`meetings view`:** positional `<slug>` — the only reliable source for a calendar's booking fields (HubSpot omits `customParams` from the list endpoint, so `fieldCount: null` there means unknown, not zero); `--as-node` as above.
 
+**`HUBSPOT_RECONNECT_REQUIRED`** is returned when HubSpot is connected but that account never granted access to what the command needs — a HubSpot grant is fixed at the moment the user approves it, so an account connected before a capability shipped cannot serve it. It is not the same as `NO_HUBSPOT_CONNECTION`: the connection works, and only the user can widen it by reconnecting from Brain → Integrations → Tools. The error carries a `fix` describing exactly that.
+
 **`--as-node`** returns exactly the object a flow node's `form.external` expects, so an agent can wire a HubSpot step by editing the flow's `_data.json` instead of interrupting the user with the `request_flow_input` approval form. It includes two fields the dashboard picker omits and the renderer needs: `configuration.postSubmitAction` (drives post-submit redirect suppression) and `region` (selects the v4 embed host — without it a v4 form on a eu1/ap1 portal loads the wrong script host).
 
 **Response:**