@koda-sl/baker-cli 0.384.0-dev.4699b7308 → 0.385.0

package/README.md

@@ -163,7 +163,7 @@ Multi-platform ad commands. Google, Meta, and LinkedIn support both reads and **
 
 ### `baker ads google accounts`
 
-List all accessible Google Ads accounts. Run this first to find account IDs.
+List the Google Ads accounts selected for this company. Run this first to find account IDs.
 
 ```bash
 baker ads google accounts
@@ -788,7 +788,7 @@ Read X Ads campaigns, line items, promoted tweets, creatives, audiences, and ana
 
 | Subcommand | What it returns |
 |---|---|
-| `accounts` | All accessible X Ads accounts |
+| `accounts` | X Ads accounts selected for this company that X currently lists |
 | `funding` | Funding instruments for an account |
 | `campaigns` | Campaigns (filter by `--funding-instrument-ids`, `--campaign-ids`) |
 | `line-items` | Line items / ad groups (filter by `--campaign-ids`, `--line-item-ids`) |
@@ -892,7 +892,7 @@ baker ads meta insights --object act_123 --level adset \
 baker ads meta activities --account-id act_123 --days 7
 
 # "Which Page should this ad run from?"
-baker ads meta pages                                                 # Facebook Pages the user manages (tasks shows which can ADVERTISE)
+baker ads meta pages                                                 # Pages with promotingAccountIds and hasPageAccessToken
 
 # "What is the lead form collecting, and how many came in?"
 baker ads meta lead-forms --page-id 100635183117758                  # instant forms on a Page + lead counts
@@ -930,6 +930,8 @@ baker ads meta custom-conversions --account-id act_123          # id, event cate
 baker ads meta custom-conversions --account-id act_123 --full   # raw rule JSON, retention, timestamps
 ```
 
+Use a Page only with an ad account listed in its `promotingAccountIds`. Instant-form reads need `hasPageAccessToken: true` on that Page and the company's lead-ads permissions.
+
 **Custom Conversions** — a marketer's own conversion (a pixel event narrowed by a rule, e.g. "PageView on /gracias"), which is what "my conversions" almost always means. To optimize an ad set toward one, pass `--custom-conversion-id <id>` and nothing else: Baker reads the conversion off Meta at stage time and fills its pixel, event category and rule, the same four fields Ads Manager stores. Staging refuses an archived or unavailable conversion, one not built on a pixel, and one belonging to another ad account. Deleting one — in Events Manager or over the API — archives it: it leaves the panel but stays readable on the account, so the listing still shows it flagged `archived`.
 
 `custom-conversions create` stages a new one (`--name`, `--pixel-id`, `--custom-event-type`, plus `--url-contains "/gracias"` or `--rule-file`). A rule is a tree of `and`/`or` over `{"<field>":{"<operator>":<value>}}` leaves, where the field is `URL`, `event`, `referrer` or any event parameter the pixel sends (`value`, `content_category`, or your own), so `--url-contains` is only the single-URL shortcut and `--rule-file` reaches the rest. Meta accepts an unmatchable rule and reports success, so staging refuses unknown operators, bare values, empty branches and two conditions written side by side where `and` was meant, before the op is staged. A case-sensitive `contains` is a real operator and gets through — on a URL always write `i_contains`. It is create-only, because Meta's edge offers neither update nor a delete that removes — which is also why staging refuses a create whose pixel, event category and rule already exist, live on the account or staged earlier in the same chat, or one that would pass Meta's cap of 100 per account. An ad set in the same chat can chain to it with `--custom-conversion-id meta_temp_*`.
@@ -997,9 +999,8 @@ To find one entity by name, pass `--name-contains <text>` to `campaigns`, `adset
 
 ```
 accounts            # ad accounts in the connected scope
-accounts --include-all   # every account the token can see (admin/debug)
 account             # single-account detail (currency, balance, business, status)
-businesses          # /me/businesses
+businesses          # businesses linked to selected ad accounts
 campaigns           # ACTIVE-only by default
 adsets              # filter by --campaign-id
 ads                 # filter by --adset-id or --campaign-id
@@ -1125,7 +1126,6 @@ baker ads linkedin bid-pricing --account-id 503001492 \
 
 ```
 accounts                       # accounts in the connected picker scope
-accounts --include-all         # every account the token can see
 account                        # single-account detail (currency, type, status)
 
 campaign-groups                # default ACTIVE-only
@@ -1497,7 +1497,7 @@ A Google Analytics connection made before writes shipped is read-only and every
 
 ### `baker ga4 properties`
 
-List accessible GA4 properties. Run this first to find property IDs.
+List the GA4 properties selected for this company. Run this first to find property IDs.
 
 ```bash
 baker ga4 properties
@@ -3409,7 +3409,7 @@ baker scheduled-agents templates --delete weekly-posthog-check
 
 ### Marketing Tags (`baker tags`)
 
-Read the client's marketing/analytics tags (Meta pixel, ChatGPT Ads pixel, GA4, Google Ads, GTM, Clarity, Hotjar, PostHog, …) — production tags overlaid with the changes staged in this chat.
+Read the client's marketing/analytics tags (Meta pixel, GA4, Google Ads, GTM, Clarity, Hotjar, PostHog, …) — production tags overlaid with the changes staged in this chat.
 
 **The CLI is read-only.** Every tag change (create, edit, delete) goes through the `request_tag_input` tool (`baker_ui` MCP server): the agent proposes one or more changes — each becomes a tab in one blocking approval form — pre-filling the non-secret fields it knows; the user reviews, edits, fills secret fields, and approves or skips each tab. Approved changes stage on the chat and apply when the chat is published; discarding the chat drops them.
 
@@ -3425,7 +3425,6 @@ Notes:
 - **Both reads restate the write path, on stderr.** `list` and `draft` end with the two lines that say the approval form is the only way to change a tag, that it rides on every turn, and that a tag change is never a Task. They are there because a chat concluded from its tool list alone that the form did not exist, never called it, and filed the change as a Task for the user to carry out by hand. stdout stays the list, so piping it is unaffected; `--json` carries the same lines in the envelope's `hints`.
 - **`list` prints each tag's full readable config.** Every non-secret field is shown in full under the tag — the Clarity `projectId`, GA4 `measurementId`, the entire custom `code` snippet, etc. — so the agent reuses a stored value to pre-fill a follow-up change instead of asking the user for something already installed. Secrets are never among these fields. (`--json` emits the same data as the raw envelope.)
 - **Secrets never travel through this CLI or the chat.** Secret fields (`accessToken`, `apiSecret`, `authorizationToken`, `apiKey`, `conversionToken`, `oauthProviderId`) are entered only in the dashboard's secure tag form and flow straight into the staged draft; tool responses only ever name which secret fields are set/pending.
-- A `chatgptAds` tag takes a Pixel ID. Its optional `apiKey` is the Conversions API key and enables the server copy of page and Form events; the key stays out of the CLI and published page.
 - Staged creates get a server-generated `tag_temp_*` ref (returned in the tool result and printed by `list`). Use it (or a real tag id) as flow side-effect `tagIds` — the published tag keeps resolving under the temp ref.
 - Proposing a delete on a `tag_temp_*` ref drops the staged create instead.
 - Single-instance types (`code`, `posthog`, `datafast`) reject a second instance against the chat's effective view.
@@ -3435,8 +3434,6 @@ Notes:
 
 Read and shape this workspace's Forms (flows). Operates on the local `_data.json` files only; no secret values are ever decrypted or printed.
 
-For ChatGPT Ads conversions, add a `chatgptAds` side effect to the Form step, choose a supported event name, and use `baker flows map` to map `advancedMatching` and optional `eventParams` (`value` and `currency`).
-
 **A Form has two halves, split by a trust boundary.** Its *structure* — steps, conditions, side effects, field mappings — is yours, and the write subcommands below edit exactly that. Its *confidential* half — connection secrets, OAuth accounts, third-party field definitions (HubSpot, Calendly, HighLevel, SavvyCal) — is configured through the `request_flow_input` tool (`baker_ui` MCP server): the agent authors the surrounding structure and references it by `nodeId`/`sideEffectId`, and the user enters secrets, connects accounts, and picks resources in the dashboard. Those values are written (encrypted, where a secret) into the Form on the chat's branch and go live when the chat is published. Nothing any of these commands does touches a live system.
 
 ```bash
@@ -3754,6 +3751,10 @@ baker schema tag-manager read   # Kebab-case paths resolve to their registered n
 
 Not every command registers a schema. On `NOT_FOUND` the error carries a structured `fix` pointing at `--help` and the family's agent doc (`__tooling__/docs/tools/baker/<family>.md` in sandboxes). Every top-level family's `--help` also ends with a `Full guide:` line pointing at that doc; `packages/cli/__tests__/doc-coverage.test.ts` fails CI if a mounted command is missing from its family doc.
 
+### `baker tag-manager containers`
+
+Lists the company's selected Tag Manager containers that the connected Google account can still open. If access to a selected container was lost, the response names it in `unavailableContainers` and asks the user to reconnect with an account that can open it.
+
 ## `baker studio` — make new imagery
 
 The generation lane. `baker images` **sources** what already exists; `baker studio` **makes** what doesn't. Every call opens a *batch* — one brief, 1-8 takes, rendered in parallel — recorded against the calling chat and shown in the dashboard Studio next to the batches the client ran themselves.

package/dist/{chunk-CHJOTJTZ.js → chunk-FGHMWBUD.js}

@@ -20,9 +20,9 @@ import {
   shouldEscalate
 } from "./chunk-HJEMOSPH.js";
 
-// ../../.pnpm-store/v10/links/@/safe-stable-stringify/2.5.0/766ad107c42df28eeadaf0ac2f9089c8a9e200f6ba0b2b1a817b8d536cbdcc49/node_modules/safe-stable-stringify/index.js
+// ../../node_modules/.pnpm/safe-stable-stringify@2.5.0/node_modules/safe-stable-stringify/index.js
 var require_safe_stable_stringify = __commonJS({
-  "../../.pnpm-store/v10/links/@/safe-stable-stringify/2.5.0/766ad107c42df28eeadaf0ac2f9089c8a9e200f6ba0b2b1a817b8d536cbdcc49/node_modules/safe-stable-stringify/index.js"(exports, module) {
+  "../../node_modules/.pnpm/safe-stable-stringify@2.5.0/node_modules/safe-stable-stringify/index.js"(exports, module) {
     "use strict";
     var { hasOwnProperty } = Object.prototype;
     var stringify = configure2();
@@ -1123,7 +1123,7 @@ function resolveAdaptFormats(params) {
   return params.formats ?? [];
 }
 
-// ../../.pnpm-store/v10/links/@/safe-stable-stringify/2.5.0/766ad107c42df28eeadaf0ac2f9089c8a9e200f6ba0b2b1a817b8d536cbdcc49/node_modules/safe-stable-stringify/esm/wrapper.js
+// ../../node_modules/.pnpm/safe-stable-stringify@2.5.0/node_modules/safe-stable-stringify/esm/wrapper.js
 var import__ = __toESM(require_safe_stable_stringify(), 1);
 var configure = import__.default.configure;
 var wrapper_default = import__.default;
@@ -9986,4 +9986,4 @@ export {
   defaultRegistry,
   createEngineFromEnv
 };
-//# sourceMappingURL=chunk-CHJOTJTZ.js.map
+//# sourceMappingURL=chunk-FGHMWBUD.js.map