@koda-sl/baker-cli 0.447.0 → 0.448.0-dev.ccc3c9a37

package/README.md

@@ -36,7 +36,7 @@ export BAKER_X_ADS_ACCOUNT_ID="18ce53xyz"
 export BAKER_CHAT_ID="<chat-id>"
 ```
 
-- `BAKER_API_KEY` must start with `bk_` (or `bkr_` for the read-only credential a Session review runs with)
+- `BAKER_API_KEY` must start with `bk_` (or `bkr_` for the read-only credential a Session review runs with, or `bkv_` for the one a published report runs with)
 - A missing or malformed `BAKER_API_KEY` / `BAKER_API_URL` ends any command that talks to Baker with `NOT_CONFIGURED` (non-retryable, with a `fix`) naming the variable and the rule it broke — never its value
 - A malformed `BAKER_GOOGLE_ADS_CUSTOMER_ID`, `BAKER_LINKEDIN_AD_ACCOUNT_ID` or `BAKER_X_ADS_ACCOUNT_ID` ends it with `VALIDATION_ERROR` instead, whose `fix` says to correct or unset the variable
 - `BAKER_API_URL` is your Convex site URL — the deployment the CLI talks to, not an address to show anybody
@@ -47,6 +47,7 @@ export BAKER_CHAT_ID="<chat-id>"
 - `BAKER_X_ADS_ACCOUNT_ID` — default X Ads account ID (base36). Used when `--account-id` is not passed. If neither is set and exactly one X Ads account is connected, it is auto-selected.
 - `BAKER_CHAT_ID` — chat context for staged Work Action commands and staged Scheduled agent create/update/delete/unstage. `scheduled-agents run` does not require it. When set, it is also sent as an `x-baker-chat-id` header on every request, so library additions that apply immediately (images, videos, followed brands) are listed in that chat's changes as already applied.
 - `BAKER_THREAD_ID` — set per turn by the sandbox. Sent as an `x-baker-thread-id` header alongside the chat header, so the tools a command reports or changes are those of whoever sent this turn, even while someone else writes in another thread of the same chat.
+- `BAKER_KEY_SCOPE` — `report` while a report's data endpoint runs in the chat preview (set by the reports runtime). Sent as an `x-baker-key-scope` header, Baker then holds the key to what a published report may do — reads only — so a report that writes fails in the preview rather than once published. It can only narrow the key.
 
 ## Debug logging
 
@@ -221,10 +222,10 @@ baker ads google currency --customer-id 5904042878
 
 ### `baker ads google url-options`
 
-The UTM / tracking parameters in force on the account: the account-level Final URL Suffix and tracking template, plus every campaign that overrides them. Start here for any "add `utm_agency=…`" or agency-tag question.
+The UTM / tracking parameters in force on the account: the account-level Final URL Suffix and tracking template, plus every campaign, ad group and ad that overrides them. Start here for any "add `utm_agency=…`" or agency-tag question.
 
 ```bash
-baker ads google url-options --customer-id 1234567890          # overriding campaigns only
+baker ads google url-options --customer-id 1234567890          # overriding campaigns, ad groups and ads
 baker ads google url-options --customer-id 1234567890 --full   # every campaign read
 ```
 
@@ -235,15 +236,19 @@ Every value is a tagged union, never a bare string, so an unread level can never
   "ok": true,
   "data": {
     "account": { "final_url_suffix": { "state": "set", "value": "utm_source=google" } },
-    "campaigns": { "overriding": [], "omitted": 12 },
-    "levels_not_read": ["ad_group", "ad"]
+    "campaigns": { "overrides": [], "omitted": 12 },
+    "ad_groups": { "read": true, "overrides": [], "truncated": false },
+    "ads": { "read": true, "overrides": [], "truncated": false },
+    "levels_not_read": []
   }
 }
 ```
 
 `set` holds a value · `not_set` means Google carries none at that level · `not_read` means it was never observed. **Only `not_set` is a finding.**
 
-Writing it: `baker ads google campaigns update <id> --final-url-suffix "utm_source=google&utm_agency=baker"` stages a campaign-level override (it *replaces* the account value for that campaign, it does not merge). The **account** level is deliberately not stageable — Google writes it through `CustomerService`, outside the atomic publish batch, so it could not be published atomically nor reversed by discarding the chat. `--level account` stages nothing and returns a structured `error.fix` naming where to set it.
+Writing it: `baker ads google campaigns update <id> --final-url-suffix "utm_source=google&utm_agency=baker"` stages a campaign-level override (it *replaces* the account value for that campaign, it does not merge). The **account** level stages too: `baker ads google account update --customer-id … --final-url-suffix "utm_source=google&utm_agency=baker"` (or `campaigns update --level account --final-url-suffix …`, the same op) applies at publish with the rest of the draft; `""` clears it.
+
+**Account settings** — `baker ads google account update --customer-id …` stages the account's own settings: `--final-url-suffix`, `--tracking-template`, `--auto-tagging` / `--auto-tagging=false`, `--call-reporting`, `--call-conversions`, `--video-inventory EXPANDED|STANDARD|LIMITED`. One card per account (staging again amends it), shown before → after; a setting the account already holds is a no-op. Turning auto-tagging off stages with a warning (conversion tracking loses the gclid). The conversion action that counts calls is not writable through Google's API.
 
 ---
 
@@ -317,19 +322,19 @@ baker ads google query --list-presets
 
 Read it before interpreting any null. Field coverage is folded page by page on the `--out` path too, so the file summary reports it; `.resource_name` is never reported (the server strips it from every row).
 
-**A page is not the data set.** Without `--all`, a query returns one page capped by `--limit` (default 200, or the `LIMIT` in the statement, whichever is smaller). With `--all` every page is followed, but the statement's `LIMIT` still caps the read — and preflight adds one at `--limit` to any query that arrives without it, so `--all` on its own still stops at 200 rows. When the rows fill whichever cap is in force, or the API returns a cursor the run did not follow, the response carries a `TRUNCATED_RESULTS` warning:
+**A page is not the data set.** Every query is read a page at a time: without `--all` it returns one page of `--limit` rows (the preset's page size, else 200) and, when the account holds more, `pagination.cursor` — pass it back with `--cursor` (same query, same `--limit`) for the next page. `--all` follows every page until the account has no more rows; only a `LIMIT` written in the statement caps it. When the API returns a cursor the run did not follow, or the rows fill the statement's own `LIMIT`, the response carries a `TRUNCATED_RESULTS` warning:
 
 ```json
 {
   "ok": true,
   "warnings": [{ "code": "TRUNCATED_RESULTS", "message": "INCOMPLETE READ — ..." }],
-  "pagination": { "hasMore": true, "cursor": "eyJwYWdl..." },
+  "pagination": { "hasMore": true, "cursor": "skip:200.k3x9q2:" },
   "data": [...],
   "notice": "Read the \"warnings\" above before using these rows: TRUNCATED_RESULTS."
 }
 ```
 
-Never total or count from a response carrying it — re-run with `--all --limit 8192 --out data.csv` (one read returns at most 8,192 rows; split a bigger data set into narrower queries — a shorter date range or one campaign each) and check the re-run came back without the warning. A read that returns one row by construction — `FROM customer` with no segment selected, such as `--preset account-summary` — has no page to fill, so it never carries `TRUNCATED_RESULTS`, nor `CONVERSION_MIX`, since one account-wide row has no campaigns to total or compare. Warnings reach every output format, so no `--output` choice can hide one:
+Never total or count from a response carrying it — re-run with `--all --out data.csv` (it pages through every row, however many) and check the re-run came back without the warning. A read that returns one row by construction — `FROM customer` with no segment selected, such as `--preset account-summary` — has no page to fill, so it never carries `TRUNCATED_RESULTS`, nor `CONVERSION_MIX`, since one account-wide row has no campaigns to total or compare. Warnings reach every output format, so no `--output` choice can hide one:
 
 | `--output` | Where warnings land |
 |------------|---------------------|
@@ -370,9 +375,10 @@ The same lines also go to stderr. A read with nothing to report prints none of i
 | `--preset`      | Named query template (see presets below)                     |
 | `--date-range`  | Override preset date range: a Google literal (LAST_7_DAYS, LAST_30_DAYS, LAST_MONTH, etc.) or `BETWEEN 'YYYY-MM-DD' AND 'YYYY-MM-DD'` — there is no LAST_90_DAYS |
 | `--include-paused` | Include paused entities in preset results. Off by default: presets return only actually-serving entities (enabled campaign **and** ad group **and** ad). Google Ads has no single serving flag, so the whole chain must be `ENABLED` for an entity to serve. |
-| `--limit`       | Max rows per page (default 200, at most 8,192)               |
-| `--cursor`      | Pagination cursor from previous response                     |
-| `--all`         | Auto-paginate all results. Exhausts the pages, not the statement's `LIMIT` — pair it with a `LIMIT` in the statement above the expected row count (at most 8,192 — split bigger reads into narrower queries), and a read that still fills its cap is flagged `TRUNCATED_RESULTS` either way |
+| `--gaql`        | The GAQL statement as a flag, instead of the positional      |
+| `--limit`       | Rows per page (default: the preset's page size, else 200; at most 8,192). A page size, not a cap |
+| `--cursor`      | `pagination.cursor` from the previous page (same query, same `--limit`) |
+| `--all`         | Follow every page until the account has no more rows. Only a `LIMIT` written in the statement stops it early, and a read that fills that `LIMIT` is flagged `TRUNCATED_RESULTS` |
 | `--out`         | Write data to file (format from extension: .csv, .jsonl, .json) |
 | `--append`      | Append to existing file (skip CSV headers)                   |
 | `--output`      | Output format: `json` \| `csv` \| `jsonl` \| `md`           |
@@ -393,9 +399,21 @@ The same lines also go to stderr. A read with nothing to report prints none of i
 | `negative-list-attachments`| Which campaigns each shared list covers | ALL_TIME        |
 | `search-terms`         | Actual user queries triggering ads       | LAST_7_DAYS        |
 | `ad-copy-performance`  | Ad headline/description effectiveness    | LAST_30_DAYS       |
-| `asset-performance`    | PMax asset performance labels            | LAST_30_DAYS       |
+| `asset-performance`    | PMax assets: serving status + metrics    | LAST_30_DAYS       |
 | `shopping-products`    | Product-level shopping metrics           | LAST_30_DAYS       |
 | `account-summary`      | Account-level totals                     | LAST_30_DAYS       |
+| `pmax-channels`        | PMax spend/results per channel (Search, YouTube, Display, …) | LAST_30_DAYS |
+| `pmax-placements`      | Where PMax ads showed (impressions)      | LAST_30_DAYS       |
+| `placements`           | Display / Video / Demand Gen placements with cost and conversions | LAST_30_DAYS |
+| `rsa-assets`           | Each RSA headline/description: pin, approval, own metrics | LAST_30_DAYS |
+| `landing-pages`        | Final URLs with clicks, cost, speed score, mobile-friendly share | LAST_30_DAYS |
+| `geo-performance`      | Results by country and location type (in vs interested in) | LAST_30_DAYS |
+| `age-performance` / `gender-performance` | Results by age range / gender per ad group | LAST_30_DAYS |
+| `ai-max-search-terms`  | AI Max search terms with the headline and landing page used | LAST_30_DAYS |
+| `account-budget`       | Account budget: limit, served, pending change | —               |
+| `recommendations`      | Google's open recommendations with impact | —                 |
+| `campaign-simulations` / `keyword-bid-simulations` | Google's what-if points (budget, tCPA, tROAS, CPC bid) | — |
+| `campaigns`, `budgets`, `ad-groups`, `keywords`, `ads`, `assets`, `asset-groups`, `audiences`, `conversion-actions`, `bidding-strategies`, `labels`, `campaign-criteria`, `ad-group-criteria`, `ad-group-bid-modifiers`, `account-exclusions`, `shared-sets`, `campaign-negative-keywords`, `ad-group-negative-keywords` | Inventories behind the `<thing> list` commands | — |
 
 Every preset except the negatives lists and `account-summary` filters to **actually-serving entities** by default — the full status chain (`campaign.status = 'ENABLED' AND ad_group.status = 'ENABLED' AND ad_group_ad.status = 'ENABLED'`, as applicable) — and selects the status columns so you can see them. Pass `--include-paused` to widen to `!= 'REMOVED'` (keeps paused, still drops removed). Raw GAQL (no `--preset`) has no such default: a query over a serving-hierarchy resource without a status filter emits a `SERVING_SCOPE` warning reminding you to add the chain, because Google Ads has no single serving flag.
 
@@ -411,13 +429,12 @@ The CLI rejects or automatically corrects common GAQL mistakes before hitting th
 
 | Pattern | Behavior | Warning/error emitted |
 |---------|----------|-----------------------|
-| Missing LIMIT | Adds `LIMIT 200` | `"Added LIMIT 200. Use --limit to override."` |
 | Bare `keyword.text` / `keyword.match_type` | Rewrites to `ad_group_criterion.*` (resource-scoped forms like `shared_criterion.keyword.text` pass through untouched) | `"keyword.text → ad_group_criterion.keyword.text"` |
 | `shopping_performance_view.product_*` | Rewrites to `segments.product_*` | Field renamed |
 | `campaign.status = 'ACTIVE'` | Rewrites to `= 'ENABLED'` | Enum corrected |
 | `segments.conversion_action_name` with `metrics.cost_micros` | Rejects; split into separate conversion-action and spend queries | `INCOMPATIBLE_FIELDS` with `fix.action: "split_query"` |
 | `DURING` with a literal Google does not accept (`LAST_90_DAYS`, `LAST_12_MONTHS`, `THIS_YEAR` …) | Rejects before any request; `DURING` takes only `TODAY`, `YESTERDAY`, `LAST_7_DAYS`, `LAST_14_DAYS`, `LAST_30_DAYS`, `LAST_BUSINESS_WEEK`, `THIS_MONTH`, `LAST_MONTH`, `THIS_WEEK_SUN_TODAY`, `THIS_WEEK_MON_TODAY`, `LAST_WEEK_SUN_SAT`, `LAST_WEEK_MON_SUN` | `INVALID_DATE_RANGE`, with `fix.correctedCommand` spelling the same window as `BETWEEN 'YYYY-MM-DD' AND 'YYYY-MM-DD'` |
-| `--limit` outside 1–8,192, or a statement `LIMIT` above 8,192 | Rejects before any request — one read returns at most 8,192 rows | `VALIDATION_ERROR` naming the cap and how to split a bigger read; a statement `LIMIT` also gets `fix.correctedCommand` at `LIMIT 8192` |
+| `--limit` outside 1–8,192 | Rejects before any request — one page holds at most 8,192 rows | `VALIDATION_ERROR` pointing at `--all --out` for bigger reads |
 | `FROM ad_group_criterion` without `negative` field | Warns | `"ad_group_criterion returns BOTH positive and negative keywords. Use --preset positive-keywords or negative-keywords."` |
 
 Auto-fixed queries proceed normally. Warnings appear in the response:
@@ -456,7 +473,7 @@ Google keeps account history in two layers, and neither reaches past 90 days:
 
 | Scope       | Reach   | What you get                                                        |
 |-------------|---------|---------------------------------------------------------------------|
-| `detail`    | 30 days | What changed, old → new value, and who changed it                   |
+| `detail`    | 30 days | What changed — a `changes` list of `{ field, old, new }` per changed field — and who changed it |
 | `summary`   | 90 days | Which resources were added, changed or removed — no values, no user  |
 
 Beyond 90 days there is no API. Infer the change from a monthly spend trend per campaign
@@ -481,6 +498,43 @@ baker ads google changes --customer-id 1234567890 --days 60 --scope summary
 
 ---
 
+### `baker ads google keywords forecast` / `keywords themes`
+
+```bash
+baker ads google keywords forecast --customer-id 1234567890 --text "running shoes:PHRASE,trail shoes:EXACT" --max-cpc 1.2 --location 2724 --language 1003
+baker ads google keywords forecast --customer-id 1234567890 --text "crm software" --match-type BROAD --daily-spend 20 --strategy MAXIMIZE_CONVERSIONS --start 2026-11-01 --end 2026-11-30
+baker ads google keywords themes --customer-id 1234567890 --keywords "trail shoes,road shoes" --ad-groups 111,222
+```
+
+`forecast` returns Google's Keyword Planner forecast (v25) for the whole period under one bidding strategy: `{ source: "keyword_planner_forecast", period, forecast_clicks, forecast_cost_micros, forecast_conversions, forecast_average_cpc_micros, forecast_average_cpa_micros }`. `--max-cpc` alone is Manual CPC; `--daily-spend` is Maximize clicks (or Maximize conversions with `--strategy`). Without `--start/--end` it forecasts the 30 days from tomorrow. `themes` returns which existing ad group each keyword fits (`suggestions`) and the ad groups Google could not read a theme from (`unusable_ad_groups`).
+
+### `baker ads google previews` / `invoices` / `identity-verification` / `brands`
+
+```bash
+baker ads google previews --customer-id 1234567890 --asset-groups 6743268912        # Performance Max, Google's preview page
+baker ads google previews --customer-id 1234567890 --ads 111~222                     # a Video campaign's ad, live on YouTube
+baker ads google invoices --customer-id 1234567890 --month 2026-09
+baker ads google identity-verification --customer-id 1234567890
+baker ads google brands --customer-id 1234567890 --prefix nike                     # brand entity ids for a BRANDS list
+```
+
+Read-only. A refusal that is the account's situation comes back as a structured error the agent carries on from: `NOT_INVOICED` (not billed by monthly invoicing — no invoices through the API), `VERIFICATION_NOT_READABLE` (verification status is only readable through the API on monthly invoicing), `NO_PREVIEW_FOR_AD_TYPE` (only video ads of Video campaigns preview by ad). Each `error.fix` says where the answer lives instead.
+
+### `baker ads google <thing> list`
+
+What exists, with the id or resource name each write command takes — one inventory preset read through `query`, so it pages (`--limit`, `--cursor`, `--all --out`) and formats (`--output`) the same way. Paused entities are listed; removed ones are not; `--serving-only` narrows to what serves.
+
+```bash
+baker ads google campaigns list --customer-id 1234567890
+baker ads google keywords list --customer-id 1234567890 --all --out keywords.csv
+baker ads google negative-keywords list --customer-id 1234567890 --level adGroup
+baker ads google keyword-lists list --customer-id 1234567890 --members
+```
+
+Lists exist for `campaigns`, `budgets`, `ad-groups`, `keywords`, `negative-keywords` (`--level campaign|adGroup`), `keyword-lists` (`--members` for the terms), `ads`, `assets`, `asset-groups`, `audiences`, `conversions`, `bidding-strategies`, `labels`, `campaign-criteria`, `ad-group-criteria`, `ad-group-bid-modifiers` and `account-exclusions`.
+
+---
+
 ### `baker ads google keywords discover`
 
 Discover keyword ideas from seed keywords or URLs.
@@ -488,6 +542,7 @@ Discover keyword ideas from seed keywords or URLs.
 ```bash
 baker ads google keywords discover --customer-id 1234567890 --seeds "running shoes,athletic footwear"
 baker ads google keywords discover --customer-id 1234567890 --url "https://competitor.com" --limit 50
+baker ads google keywords discover --customer-id 1234567890 --seeds "running shoes" --cursor <next_page_token>   # next page
 ```
 
 **Response:**
@@ -601,6 +656,8 @@ Reference not-yet-created resources with `g_temp_*` refs returned by earlier `cr
 ```bash
 # Build a Search campaign bottom-up, chaining temp refs
 baker ads google budgets create --customer-id 1234567890 --name "Search budget" --amount 50
+# Delivery is always STANDARD: --delivery ACCELERATED is refused (Google stores such a budget but will
+# not attach it to a campaign).
 # → { ref: "g_temp_ab12", ... }
 baker ads google campaigns create --customer-id 1234567890 --name "Brand — Search" \
   --channel-type SEARCH --budget-ref g_temp_ab12 --bidding-strategy MANUAL_CPC \
@@ -633,6 +690,10 @@ baker ads google campaigns update <campaign-id> --customer-id 1234567890 \
 # --ai-max-url-expansion (final URL expansion, needs text customization). An omitted switch
 # keeps the campaign's value; a combination Google refuses is refused at staging.
 baker ads google campaigns update <campaign-id> --customer-id 1234567890 --ai-max --ai-max-text
+# Bidding is per campaign type — staging refuses a pair Google does not take and names the ones it does.
+# Target impression share (Search only) needs its whole goal on a new strategy:
+baker ads google campaigns update <campaign-id> --customer-id 1234567890 --bidding-strategy TARGET_IMPRESSION_SHARE \
+  --impression-share 70 --impression-share-location ABSOLUTE_TOP_OF_PAGE --max-cpc 2
 baker ads google ad-groups create --customer-id 1234567890 --name "Brand terms" --campaign-ref g_temp_<campaign>
 baker ads google keywords add --customer-id 1234567890 --ad-group-ref g_temp_<adgroup> --text "brand name" --match-type EXACT
 # Shared negative keyword list → attach to the campaign
@@ -666,7 +727,7 @@ baker ads google ads create --customer-id 1234567890 --ad-group-ref g_temp_<adgr
 # Video ad — the YouTube video is its own asset first, then referenced by --video-assets
 baker ads google assets create --customer-id 1234567890 --file '{"type":"youtubeVideo","youtubeVideoId":"dQw4w9WgXcQ"}'
 baker ads google ads create --customer-id 1234567890 --ad-group-ref g_temp_<adgroup> --format video \
-  --video-assets g_temp_<video> --final-url https://example.com
+  --video-assets g_temp_<video> --business-name "Acme" --logo-image-assets g_temp_<img_logo> --final-url https://example.com
 # Demand Gen ad — image refs the same way
 baker ads google ads create --customer-id 1234567890 --ad-group-ref g_temp_<adgroup> --format demandGen \
   --headlines "Discover the app" --descriptions "Try it free today" --business-name "Acme" --final-url https://example.com \
@@ -681,6 +742,8 @@ baker ads google ads create --customer-id 1234567890 --ad-group-ref g_temp_<adgr
 # App campaign ad — images are fields on the ad itself, same asset-ref flow
 baker ads google ads create --customer-id 1234567890 --ad-group-ref g_temp_<adgroup> --format app \
   --headlines "Insure your dog" --descriptions "Refunds in 2 hours" --image-assets g_temp_<img1>,g_temp_<img2>
+# Call ads are retired — Google's API has no call ad, so --format call is refused. Stage a responsive
+# search ad and have the user add the phone number as a call asset in Google Ads.
 # Change a live ad's content — every field you pass replaces its current value, so list what you want to keep
 baker ads google ads update <adId> --customer-id 1234567890 --format app \
   --headlines "Insure your dog" --descriptions "Refunds in 2 hours" \
@@ -702,9 +765,16 @@ baker ads google asset-groups attach --customer-id 1234567890 \
 baker ads google asset-groups detach customers/1234567890/assetGroupAssets/6718302454~402654762568~PORTRAIT_MARKETING_IMAGE \
   --customer-id 1234567890
 
+# Audiences — each type carries what Google builds it from (a type alone is refused)
+baker ads google audiences create --customer-id 1234567890 --file '{"name":"Pricing visitors","type":"RULE_BASED","rule":{"include":[{"conditions":[{"operator":"CONTAINS","value":"/pricing"}],"lookbackWindowDays":30}],"prefill":true}}'
+# BASIC takes "conversionActions", LOGICAL "logic", LOOKALIKE "lookalike" — each naming lists/actions
+# that already exist in the account (not g_temp_* refs). `baker ads google audiences create --help` has one example per type.
+
 # Review / undo / amend staged changes
 baker ads google draft list                  # readable campaign ▸ ad group ▸ ad tree + completeness advisories
 baker ads google draft list --json           # raw JSON envelope for scripting
+baker ads google draft validate              # dry run the whole draft against Google (validateOnly) — per-op verdicts
+baker ads google draft validate --full       # every op, with the built request and Google's raw answer
 baker ads google draft show g_temp_ab12      # full staged payload — the receipt before publish
 baker ads google draft amend g_temp_ab12 --patch '{"amountMicros": 60000000}'   # update in place, never remove+recreate
 baker ads google draft remove g_temp_ab12    # cascades to dependents
@@ -719,7 +789,17 @@ baker tag-manager draft show --chat <chat-id> gtm_temp_ab12
 baker actions draft --chat <chat-id>
 ```
 
-Command groups: `budgets`, `campaigns`, `ad-groups`, `keywords` (add/update/remove), `negative-keywords`, `keyword-lists`, `ads`, `assets` (create/update/attach/detach), `asset-groups` (create/update/attach/detach — Performance Max), `audiences`, `conversions` (create/update/goal/upload), `bidding-strategies`, `labels`, `campaign-criteria` (add/update/remove), and `draft`. Amounts are in major currency units (converted to micros). Money/bids: `--amount`, `--cpc-bid`, `--target-cpa`, `--target-cpc`, `--max-cpc` take major units; `--target-roas` a ratio. `--target-cpc` pairs with `--bidding-strategy TARGET_CPC` and is Demand Gen only. `--max-cpc` sets the max CPC bid ceiling for `TARGET_IMPRESSION_SHARE` / `TARGET_SPEND` / `PERCENT_CPC` and must be paired with `--bidding-strategy`. Less-common ops accept a `--file` payload — a path to a JSON file, or the JSON object written inline (flags override its keys). Updates target a resource name or bare id as the positional argument; a target that names an op staged earlier **amends it in place**.
+**Budgets and portfolios** — `budgets create --total 300` stages a total budget (one amount over the campaign's flight; Search, Performance Max and Demand Gen; the campaign needs `--end-date`; never shared) instead of `--amount`'s daily one, and `budgets update --total` moves it. `campaigns create|update --portfolio-ref <ref>` puts a campaign on a portfolio bid strategy (checked against the campaign type); staging a campaign's own `--bidding-strategy` while it is on a portfolio takes it off (with a warning). `budgets remove <id>` and `bidding-strategies remove <id>` remove a budget / portfolio once no campaign uses it — staging refuses while one does, unless the same draft removes or moves those campaigns; publish removes the campaigns first.
+
+**Shopping campaigns** — `campaigns create --channel-type SHOPPING --merchant-id <id>` (`merchant-center list` shows the Merchant Center accounts linked to the account; staging refuses any other) with optional `--feed-label`, `--shopping-priority low|medium|high` and `--local-inventory`; `campaigns update` changes those three (`--clear-feed-label`), never the Merchant Center. `ad-groups create --type SHOPPING_PRODUCT_ADS` creates the ad group with its "All products" listing group, and `ads create --format shoppingProduct` its product ad (no copy — the feed supplies it). A retail Performance Max campaign takes `--merchant-id` / `--feed-label` too.
+
+**App, Travel and Hotel campaigns** — App: `campaigns create --channel-type MULTI_CHANNEL --sub-type APP_CAMPAIGN|APP_CAMPAIGN_FOR_ENGAGEMENT --app-id <package or App Store id> --app-store google|apple --app-goal installs|installs-volume|in-app|in-app-install-cost|value [--app-conversions <ids>]` (each goal takes one bidding strategy; App ads are created enabled — Google refuses a paused one, so `ads create --format app` defaults to `ENABLED`). Travel: `--channel-type TRAVEL --travel-account-id <id>` on Maximize conversion value with `--target-roas`. Hotel: `--channel-type HOTEL --hotel-center-id <id>`. Staging asks Google (validate-only) whether the app, the travel account or Hotel Center is there and refuses with what to ask the user when it is not. Smart campaigns are refused (their business setting cannot be validated).
+
+**Dynamic Search Ads and frequency caps** — `campaigns create|update --dsa-domain <domain> --dsa-language <code> [--dsa-supplied-urls-only]` (Search only; an update may change one field; it cannot be removed) and `--frequency-cap <cap>/<day|week|month>[/<campaign|ad-group|ad>][/<impressions|video-views>]` (repeatable, replaces the campaign's caps; `--clear-frequency-caps`; Display and existing Video campaigns only).
+
+**Performance Max creative controls** — `campaigns create|update` take `--term-exclusion` / `--messaging-restriction` (text guidelines; a Search create needs `--ai-max --ai-max-text`), the generated-asset switches `--generated-text --url-expansion --video-enhancement --image-enhancement --image-extraction --image-design-versions` (each `=false` to turn off), `--brand-guidelines` on create (link the business name and a square logo to the campaign in the same draft) and `--main-color --accent-color --font`. `campaigns enable-brand-guidelines <id> --business-name-asset --logo-assets [--landscape-logo-assets] [--final-url-domain] | --auto-populate` turns brand guidelines on for an existing campaign at publish (no dry run: `draft validate` shows it unchecked).
+
+Command groups: `account` (update), `budgets` (create/update/remove), `campaigns`, `ad-groups`, `keywords` (add/update/pause/resume/remove), `negative-keywords` (add/update/remove — `update <resource name> --text --match-type` publishes as a replace of the live negative), `keyword-lists` (create/rename/delete a list — `--type NEGATIVE_KEYWORDS|NEGATIVE_PLACEMENTS|BRANDS|ACCOUNT_LEVEL_NEGATIVE_KEYWORDS`; add/remove its members — keywords, or `--placement/--app/--youtube-channel/--youtube-video/--brand`; attach/detach), `ads`, `assets` (create/update/attach/detach), `asset-groups` (create/update/attach/detach — Performance Max), `audiences`, `conversions` (create/update/goal/upload), `bidding-strategies` (create/update/remove), `labels` (create/update/remove; attach/detach on a campaign, ad group, ad or keyword — `--level --on --label-ref`), `campaign-criteria` (add/update/remove — locations, languages, schedule, devices, radius, carriers, operating systems, and exclusions of placements, apps, YouTube, topics, demographics, content types, IP addresses, web pages, brand lists), `ad-group-criteria` (add/update/remove — placements, topics, demographics, web pages, Demand Gen locations/languages/combined audience; `update --bid-modifier --max-cpc --status`), `ad-group-bid-modifiers` (add/update/remove — one ad group's own device bid), `account-exclusions` (add/remove — account-wide site, app, YouTube, content-type, IP and negative-keyword-list exclusions; `add --placement --youtube-channel --youtube-video --app --content-label --ip` comma-separated, or `--file`), `merchant-center` (list), and `draft`. `audiences attach` takes `--user-list`, `--interest` or `--custom-segment`. Amounts are in major currency units (converted to micros). Money/bids: `--amount`, `--cpc-bid`, `--target-cpa`, `--target-cpc`, `--max-cpc` take major units; `--target-roas` a ratio. `--target-cpc` pairs with `--bidding-strategy TARGET_CPC` and is Demand Gen only. `--max-cpc` sets the max CPC bid ceiling for `TARGET_IMPRESSION_SHARE` / `TARGET_SPEND` / `PERCENT_CPC` and must be paired with `--bidding-strategy`. Less-common ops accept a `--file` payload — a path to a JSON file, or the JSON object written inline (flags override its keys). Updates target a resource name or bare id as the positional argument; a target that names an op staged earlier **amends it in place**.
 
 **A device criterion can be added, but never removed** — `campaign-criteria add` with a device criterion works, but Google then rejects `campaign-criteria remove` on it forever, including on a criterion you added yourself (and Baker refuses the removal before publish). Adjust it instead with `campaign-criteria update customers/<cid>/campaignCriteria/<campaignId>~<criterionId> --bid-modifier <n>`: `1` for no adjustment, `1.25` to bid 25% more, `0.9` to bid 10% less, `0` to stop serving on that device. Locations, languages and ad schedules remove normally.
 
@@ -733,16 +813,22 @@ Command groups: `budgets`, `campaigns`, `ad-groups`, `keywords` (add/update/remo
 
 **Retiring a conversion action** — `status` accepts `ENABLED` and `REMOVED` only. Google denies `HIDDEN` on every conversion-action write, so to stop bidding toward an action while it keeps measuring use `--no-primary`, and to stop it counting at all use `"status": "REMOVED"`. Conversion actions **Google owns** cannot be changed at all — Smart campaign call/directions actions, the in-ad lead form's submit, YouTube subscriptions and follow-on views, Floodlight and Search Ads 360 imports, store visits, codeless webpage actions. Staging any edit to one, a rename included, is refused up front; there is no manual route either, since the Google Ads interface will not change them.
 
+**Validating the draft** — `baker ads google draft validate` sends the whole staged draft to Google exactly as publish would (same batching and order), with `validateOnly: true`, so nothing is applied. Each op comes back `accepted`, `refused` (with the reason publish would record), `blocked` (a change it depends on is refused), `unchecked` (only publish can check it — a new asset group, whose text assets are created first) or `applied` (an earlier publish did). Compact by default (counts plus the ops that need attention); `--full` lists every op with its request and Google's raw answer.
+
 **Reviewing the draft** — `baker ads google draft list` renders everything you've staged as a grouped campaign ▸ ad group ▸ ad tree (with non-blocking completeness advisories), the CLI counterpart to the dashboard's Google Ads tab. Pass `--json` for the raw envelope. Once the chat has published it reports the outcome instead — `published · N applied, M failed`, with a `✗` line naming each op that did not land and why. Aim for a fully built campaign — 2–4 ad groups, ≥5 keywords each, 2–4 RSAs with 8–12 headlines, ≥4 sitelinks / ≥3 callouts / ≥1 structured snippet, and ≥1 shared negative list; the advisories flag what's still thin.
 
 **Amending a staged op** — `draft amend <ref> (--file patch.json | --patch '<json>')` merges a JSON patch into an already-staged op's payload (objects deep-merge, `null` deletes a key, arrays/scalars replace) and re-validates it in full. Always prefer this over removing and re-staging — it preserves the op's ref (so dependents don't break) and its position in the draft. `draft show <ref>` prints the full staged payload (including warnings/annotations) so you can verify a change looks right before publish.
 
+**Tracking warnings** — Tag Manager stage, amend, list and show responses provide repair hints whenever warnings remain. The compact `tag-manager draft list` prints the warnings beside their changes. Resolve the intended event role and technical gaps, then read the draft again before finishing; progress and diagnostics are not counted just to clear an alert. Adding and then removing a conversion that was never live cancels that proposal, so it disappears from the review.
+
 **Reading an earlier chat's changes** — `draft list` and `draft show` take `--chat <chat-id>` to read another chat in the same company instead of the current one. Every staged-draft family accepts it: `ads google|meta|linkedin draft list|show`, `tag-manager draft list|show`, `actions draft`, `tags draft`, and `scheduled-agents list|get` (`list` leaves briefs out; `get <id>` or `list --full` returns them). A published draft is kept in full, so this returns what that chat actually wrote — every headline, bid and target — plus each op's outcome and error. Use it when asked to redo or reapply earlier work rather than reconstructing copy from a summary. Read-only: staging, `amend`, `remove` and `clear` stay bound to `BAKER_CHAT_ID`, so one chat can never edit another's draft. To re-run only the changes a publish failed to land, use the chat's **Retry** control in the dashboard — it re-sends exactly those and leaves the ones that applied untouched.
 
 **Already-satisfied writes aren't staged** — an update or pause/resume whose every field already holds the requested value on the live account is dropped instead of staged: the envelope returns `"staged": false, "noop": true` with a `reason` ("this ad is already Paused on Google Ads"), plus a hint. This is a success, not an error — there is nothing to publish. Only a positively-read live snapshot can trigger it; a failed or empty read always stages. Batch responses list the dropped ops under `skipped`, and `count` reflects what actually entered the draft.
 
 **Batch keyword adds** — `keywords add`, `negative-keywords add`, and `keyword-lists add` take a whole batch in one command: comma-separate `--text` entries and/or pass `--file <list.txt>` (one keyword per line). A `:EXACT`/`:PHRASE`/`:BROAD` suffix per entry overrides the `--match-type` default. Batches stage all-or-nothing as one request (limit 500); each keyword still lands as its own draft op, so it stays individually removable/amendable.
 
+**Bulk changes — one file, one call** — `draft stage --file ops.json [--customer-id <id>]` stages up to 500 ops of any mix of kinds in one request: the file is a JSON array (or JSON Lines) of whole ops `{"kind","customerId"?,"target"?,"payload"?}`; `--customer-id` fills ops that leave it out. All-or-nothing on validity (an error names `ops[i]`); ops the account already satisfies come back as `skipped`. An op may name a `g_temp_*` ref from an earlier call, not one from the same file. `draft amend --file amends.json` (no ref) amends many staged ops at once from `[{"ref","patch"}, …]`, all or none. The `--file` create commands (`assets create|attach`, `audiences create`, `conversions create`, `bidding-strategies create`, `labels attach`, `campaign-criteria add`, `ad-group-criteria add`) take a JSON array of payloads too. `keywords pause|resume <target>…` (or `--file`, one resource name per line) change many keywords' status in one call, and `keyword-lists remove --list-ref <id> --text "a,b:EXACT"` takes terms out of a shared negative list — the CLI reads the list to find each member (no `:MATCH_TYPE` = every match type), or takes members by resource name / `listId~criterionId`. Five single stages of one kind in a row on a chat earn a `LOOP:` hint pointing at these. A chat's draft holds any number of ops (each is its own record); only one op over `GOOGLE_DRAFT_OP_MAX_BYTES` (512 KB) is refused — the stage or amend stages nothing and answers `OP_TOO_LARGE` with an `error.fix` (split that change).
+
 **Pausing or removing a keyword returns a per-ad-group hint** — `keywords update --status PAUSED|REMOVED` and `keywords remove` come back with hints telling you to base the decision on `keyword_view` rows carrying `ad_group.id` + `ad_group_criterion.criterion_id`, never on campaign totals. A keyword's criterion id is derived from its text + match type, so every copy of the same keyword across ad groups shares one id and any aggregate blends the copy holding the history with the copies that never served. The `keyword-analysis` and `positive-keywords` presets select both ids so one query identifies each copy. A bid or URL edit gets no hint — only a pause/removal can strand history.
 
 ---
@@ -1441,8 +1527,11 @@ baker analytics sources --map --source <id> --field email={{contact.email}} --fi
 baker analytics sources --create-hubspot --property lifecyclestage --value customer   # an event HubSpot keeps for Baker each time the property changes
 baker analytics sources --create-hubspot --property deal_value --operator greaterThan --value 1000   # any condition a Form's filter can say
 baker analytics sources --map --source <id> --field email={{work_email}} --field value={{deal_value}} --field currency=EUR   # repoint a HubSpot read
+baker analytics sources --create-activecampaign --events subscribe,deal_update   # ActiveCampaign's webhook sends these; each is an activecampaign.<event>
 ```
 
+**ActiveCampaign events.** `--create-activecampaign [--events …] [--name …] [--account <id>]` makes a source that ActiveCampaign's own webhook sends to — set up on the account when the chat is published (at once outside a chat), deleted when the source is removed. Each arrival is an event named `activecampaign.<event>` (`activecampaign.subscribe`, `activecampaign.deal_update`, …), about its contact, with the rest of the payload as `properties.*` — the name a scheduled agent on `event.received` is narrowed to.
+
 **Sources: where events reach Baker from a server.** Measure → Sources is three built-in doors — the Baker landings, the website tag, and **the client's own server** — plus the connections Baker reads (HubSpot today). `--server` prints the server's one address: made once, the same for ever, `counting` at once, Baker's own format (`sending-events` is the contract; `X-Baker-Mode: test` rehearses). A HubSpot event is a trigger in HubSpot's own words, kept by HubSpot's journal each time the property changes and counted within a minute. `--create --name <tool>` still makes an address for a tool that cannot be told what to send — its first send is a masked sample counted as nothing until `--map` confirms the rows — but the dashboard no longer offers those; a tool worth reading is a connection, requested from the Sources page. Each `--field` is a **template**: text with `{{path}}` mentions, one thing per mention (`--field currency=EUR` types a value, `--field first_name="{{who.first}} {{who.last}}"` joins two; there is no `{{a|b}}` fallback); a bare path is read as its mention when the sample has it. From then on every arrival is an ordinary event carrying `baker_source: <name>`, listed by `feed --source <name>`, and `--pause`, `--resume` and `--remove` are by `--source <id>`.
 
 **`--preview` then `--create-hubspot --property <name> [--operator <op>] --value <value>… [--name <name>] [--field <field>=<template>…] [--amount-property <n> --currency <c>]`: a HubSpot event.** HubSpot keeps each change to the property for Baker, filtered to the condition — on any plan, nothing to set up in HubSpot, an account of any size — and every contact whose new value satisfies the condition is one event, within a minute, named after the source (default: the trigger's words). The condition is any a Form's filter can say, by the property's kind: `is` / `isNot` (a dropdown, `--value` repeated for several), `contains` / `startsWith` / `endsWith` (text), `greaterThan` / `lessThanOrEqual` … (numbers), `isAfter` / `isBetween` (dates, `YYYY-MM-DD`), `isEmpty` / `isNotEmpty` (any); `--operator` is `is` when unsaid. Names, kinds and operators come from `baker hubspot contacts properties` and row properties from `baker hubspot contacts fields`; `--preview --property … [--operator …] --value … [--field …] [--contact <id or email>]` says how many contacts satisfy it today (NOT counted — only contacts that come to satisfy it from now on are) and returns `preview.record`, the one most recently there or the one asked for, to check every row against before making anything. `--set-trigger --source <id> --property … [--operator …] --value …` changes what an event watches later: the rows stay and `countingSince` moves to now. The connection must be allowed to read contacts, and a refusal names the reconnect. `counting` at once, no URL; the source carries `hubspot { property, propertyLabel, kind, operator, values, valueLabels }`, `countingSince`, `listening` (whether HubSpot has been told to keep its changes: `listening`, `not_configured` or `failed`, with a `detail`), `lastError` and `mapping` — the same field → template table as an address, over the contact's properties plus `{{id}}`, defaulting to HubSpot's standard ones (email, phone, the contact id, name, address, `hs_google_click_id`, `hs_facebook_click_id`); a `--field` row at creation replaces the default it names, `--map --field` replaces the whole set later, and `--amount-property … --currency …` is the short spelling for the `value` and `currency` rows. `--field properties.<name>=<template>` adds an extra property of the event (`--field properties.plan={{plan_tier}}`): it breaks the event down on Measure → Events and a send reads it back as `{{properties.<name>}}`. A deal is watched the same way with `--object deal`, and a lead with `--object lead` (`baker hubspot leads properties|fields`) — where HubSpot records qualification and disqualification as the lead's stage. A deal's or a lead's event is about its contacts (`--contacts every|first`), read as `{{contact.<name>}}`; a lead has no amount. Leads need Sales Hub Professional or Enterprise. Where the event is sent on (Meta, Google Ads…) is `sends`, edited on the event's own card on the Sources page.
@@ -1553,14 +1642,15 @@ baker experiment update --id a3f91c2b --because "…"              # a live one
 baker experiment status                                          # the verdict on every test, first; dates as calendar dates
 baker experiment status --id a3f91c2b --full                     # one test, with everything the dashboard reads and the posteriors
 baker experiment history --landing oferta                        # every finished test on a page: claim, numbers, decision, learning
+baker experiment start … --hold                                  # publish both versions with the split off, for the client to approve by link first
 baker experiment pause --id a3f91c2b                             # everyone sees the original for now
-baker experiment resume --id a3f91c2b                            # the split picks up with the same sides
+baker experiment resume --id a3f91c2b                            # the split picks up with the same sides; a held test starts here, dated from now
 baker experiment finish --id a3f91c2b --keep variant --learning "…"   # end it now; say which version stays and what it taught
 baker experiment cancel --id a3f91c2b                            # call it off: staged → gone, live → ended, original kept
 baker experiment fold                                            # make the page's own content the version that was kept
 ```
 
-**A page has variants. A variant is never a page.** The variant is a real built folder at `src/pages/oferta--1/`, so it gets every quality gate a page gets — which matters, because it is about to be shown to half the client's visitors. What it does not get is a public address: it is absent from the Landings list and the sitemap, names the page's URL as its canonical, and `/oferta--1/` returns **404** at the edge. It is as indexable as the page it is a version of, deliberately — half the crawls of `/oferta/` are served the variant, so a `noindex` on it is a `noindex` on the live page. Both versions answer at `/oferta/`. Assignment happens while the HTML is served, so there is no flicker and nothing for an ad blocker to suppress, and the split is a path rewrite and never a redirect. To look at one side deliberately, `/oferta/?_bkr_preview=a` and `?_bkr_preview=b` serve it exactly, with no assignment and no cookie.
+**A page has variants. A variant is never a page.** The variant is a real built folder at `src/pages/oferta--1/`, so it gets every quality gate a page gets — which matters, because it is about to be shown to half the client's visitors. What it does not get is a public address: it is absent from the Landings list and the sitemap, names the page's URL as its canonical, and `/oferta--1/` returns **404** at the edge. It is as indexable as the page it is a version of, deliberately — half the crawls of `/oferta/` are served the variant, so a `noindex` on it is a `noindex` on the live page. Both versions answer at `/oferta/`. Assignment happens while the HTML is served, so there is no flicker and nothing for an ad blocker to suppress, and the split is a path rewrite and never a redirect. To look at one side deliberately, `/oferta/?_bkr_preview=a` and `?_bkr_preview=b` serve it exactly, with no assignment and no cookie — and they keep answering while the test is paused and after it ends, up to `fold`, which removes the other version's file. That window is how a client is shown a version at all.
 
 **The goal is one event, named by its key.** `--goal submit:book-a-call` — the same vocabulary the event stream uses (`form:<flow>:<node>:<trigger>`, `submit:<flow>`, `page:<name>`, `exit:<host>`), and `baker analytics conversions --candidates` lists the keys these pages produce. Not a conversion *name*, which groups several keys: a variant that swaps the page's Form for a shorter one converts on a different key, and a name would either count both endings as one outcome or count the new version as never converting at all — `--variant-goal` gives the new version its own event when it has one. The goal is fixed for the life of the test and the verdict is read on it alone. Every other conversion the company counts comes back under `secondary` on every result, with the same interval and a one-word reading, and decides nothing. A conversion counts for a visitor wherever it happens after they were shown a version — on the page, on another page, in a delivered lead, or in a deal the CRM posted a week later by email.
 
@@ -1771,6 +1861,38 @@ baker ga4 draft clear
 
 ---
 
+### ActiveCampaign reads (`baker activecampaign`)
+
+Read the connected ActiveCampaign account live; nothing is stored and nothing in ActiveCampaign changes.
+
+```bash
+baker activecampaign account                                   # contacts, site tracking on/off + tracking account id, allowed domains, event tracking
+baker activecampaign campaigns [--status completed] [--since 2026-09-01] [--limit 20]   # email reports, most recently sent first
+baker activecampaign automations [--active-only]               # on/off, entered/exited, what starts each one
+baker activecampaign contacts [--email a@b.com | --tag <id|name> | --list <id|name> | --search <text>] [--limit 20]
+baker activecampaign deals [--pipeline <id|title>] [--stage <id|title>] [--status open|won|lost] [--owner <id|username|email>]
+baker activecampaign pipelines | lists | tags [--search <text>] | fields | users
+```
+
+Campaign rows carry `sends`, `opens`, `uniqueOpens`, `clicks`, `uniqueClicks`, `unsubscribes`, `hardBounces`, `softBounces` and `rates` (`open`, `click`, `unsubscribe` and `bounce` as shares of sends; `clickToOpen` as unique clicks over unique opens; `null` before anything is sent). Deal values are in the currency's major units, and `totals` sums every matching deal per currency. Every command takes `--account <id>` when the company has more than one ActiveCampaign connection, and `--full` adds each row's untouched ActiveCampaign payload as `raw`. Nothing connected answers `NO_ACTIVECAMPAIGN_CONNECTION`, a key ActiveCampaign stopped accepting `ACTIVECAMPAIGN_RECONNECT_REQUIRED` — both with a `request_connection` fix.
+
+### ActiveCampaign changes (`baker activecampaign stage` / `unstage` / `drafts`)
+
+Stage a custom contact field, list, tag or deal pipeline on the connected ActiveCampaign account. Nothing changes in ActiveCampaign until the chat is published; then each change is created — or, when the account already has it (a field by its personalization tag, the rest by name), reused rather than duplicated.
+
+```bash
+baker activecampaign stage field --utm                                   # UTM_SOURCE, UTM_MEDIUM, UTM_CAMPAIGN, UTM_CONTENT, UTM_TERM
+baker activecampaign stage field --title "Plan" --type dropdown --options "Basic,Pro"
+baker activecampaign stage list --name "Webinar sign-ups"
+baker activecampaign stage tag --name "hot-lead"
+baker activecampaign stage pipeline --title "Inbound" --stages "New lead,Qualified,Won" --currency usd
+baker activecampaign drafts [--chat <id>]                                # what is staged; after Publish, what happened to each
+baker activecampaign unstage <ref|name|perstag>                          # drop one staged change
+baker activecampaign unstage --all                                       # drop every staged change
+```
+
+A field is put on every list. Field types: `text`, `textarea`, `date`, `datetime`, `dropdown`, `listbox`, `radio`, `checkbox`, `hidden`; `dropdown`, `listbox`, `radio` and `checkbox` need `--options`. A new pipeline gets exactly `--stages`; an existing one only gains the stages it lacks. Every `stage` takes `--account <id>` when the company has more than one ActiveCampaign connection.
+
 ### Google Search Console (`baker gsc`)
 
 GSC commands for PPC-SEO arbitrage, brand halo analysis, and negative keyword discovery.
@@ -1850,7 +1972,7 @@ Ads start from what customers said. Three commands carry the process; the agent
 ```bash
 baker creatives brief [--adset <id>] [--account-id act_<id>] [--no-research]   # one read: viewer, account bottleneck, what works, taste, customer quotes, ideas on file
 baker creatives ideas [--full]                                 # check and rank src/creatives/_ideas/*.md; build_next
-baker creatives make <idea> [--slug <s>] [--adset <id>] [--reference <adId>] [--spec <beats.json>] [--from-idea] [--series <lead>]
+baker creatives make <idea> [--slug <s>] [--adset <id>] [--reference <adId> [--platform meta|linkedin|tiktok|google]] [--spec <beats.json>] [--from-idea] [--series <lead>]
 baker creatives translate --slug <ad> --to es-MX,es-CO,pt-BR [--copy-file <json>] [--note "<brief>"] [--again]   # the same ad in other languages, one design
 baker creatives learn [--days <n>] [--dry-run]                 # what each idea's ads did, written back onto the idea
 ```
@@ -2005,7 +2127,7 @@ baker research customers --dry-run                   # print, write nothing
 
 ### `baker research advertisers "keyword"`
 
-Returns a ranked list of **domains** competing for one keyword in Google, with average SERP position, relevance rating, estimated traffic value and visibility — domain economics, **NOT ad copy**. Despite the name it returns no headlines, descriptions or creative of any kind; for a competitor's actual ad copy use `baker winning-ads content <adId>` (Meta/LinkedIn only — Google SERP ad copy is not available anywhere in Baker).
+Returns a ranked list of **domains** competing for one keyword in Google, with average SERP position, relevance rating, estimated traffic value and visibility — domain economics, **NOT ad copy**. Despite the name it returns no headlines, descriptions or creative of any kind; for a competitor's actual ad copy use `baker winning-ads content <adId>` (Meta, LinkedIn, TikTok and Google, for brands the library tracks) or, for a one-off Google read, `baker research google-ads <domain> --copy`.
 
 Defaults to `--location us` and `--language en` when omitted; the response carries a `query_context` showing which pair was used, so always set both for non-US or non-English markets.
 
@@ -3405,12 +3527,20 @@ A Google Drive folder is never added with `add`: the agent calls `request_connec
 
 Search the **ad-dna** corpus of scored "winning" competitor ads for reference creatives to reproduce (e.g. with `baker canvas`), and manage the brands your library tracks (`follow` / `following` / `feed` / `unfollow`). Each result carries a presigned media URL (~1h TTL), the ad's DNA summary, and scores. The CLI authenticates with the normal `BAKER_API_KEY`; the Baker backend proxies the request to the ad-dna service with a server-held token — no extra credential in the sandbox.
 
-> The corpus has **Meta + LinkedIn** connectors, so `--platform` inputs are limited to `meta,linkedin`. (Older result rows may still carry a legacy platform string.)
+> The corpus reads **Meta, LinkedIn, TikTok and Google Ads** (`--platform meta,linkedin,tiktok,google`). Google search text ads are `--format text`; only Google display and YouTube ads can be a design reference.
+
+> Rows are compact by default. `--fields a,b` keeps only those columns in every `--output` on `search`, `feed`, `winners`, `ads`, `advertisers`, `following` and `content`; on ad rows a name only `--full` carries (`angle`, `hook_archetype`, …) comes back on its own, and a name no row carries is refused with `error.fix.validValues`.
 
 > Backend env: the Convex deployment must have `AD_DNA_API_TOKEN` set (`npx convex env set AD_DNA_API_TOKEN …`). `AD_DNA_API_URL` is optional and defaults to `https://ads.withbaker.com`.
 
 > Replaces the old `baker ads google library` tree, which has been removed. Competitor-by-keyword discovery still lives at `baker research advertisers`.
 
+`baker winning-ads profile <advertiserId>` returns what one brand is doing: an estimated spend in USD (a range over every ad since `since`, the last 30 days, and a minimum, split by channel in `by_platform` — a channel that publishes no delivery is marked `unpriced`; `ads_counted` says how many ads were measured, estimated from similar ads, or not counted for lack of reach), what it launched lately and which of those still run, the concepts it tested and the version it kept, its format and platform mix, top landing pages, audiences and similar brands. `--platform` narrows it, `--full` returns everything. `baker winning-ads launches [--since 7] [--advertiser a,b]` lists what the followed brands (or the named ones) launched in the last N days and which still run. Both say, for every launch, whether it was a `new` idea, another version of one still in `testing`, or a version built on a `winner` the brand had already kept; the profile also counts new ideas per week and `unique_ideas` overall.
+
+`baker winning-ads landings <advertiserId>` lists every landing page the brand's ads point to, most ads first, with how many ads point there, how many still run, the platforms and when each was last used. `address_only` marks an address only Google search ads print: Google publishes no search ad's destination, so it may not be a real page and is never analysed. `--analyse` studies the top 5 pages not analysed yet (`--pages a,b` to name them): each page's headline, value propositions, offer, pricing, calls to action, proof, audience and sections in order. Analysis takes a few minutes per page and is shared by every company, so a page analysed once is ready for all. `--platform` narrows it, `--full` returns every field.
+
+`baker winning-ads search-copy <advertiserId>` reads what a brand says on Google Search from its search ads: every headline with its hook (category, brand, free, price_discount, outcome, proof, new_timely, comparison, audience, location, feature, call_to_action, question), its descriptions, sitelinks and callouts. Each is `running` or `dropped` (every ad that carried it has stopped), with how many ads carried it and the longest any ran. `hooks` compares the running headlines' hooks with the dropped ones; `rival_headlines` lists headlines naming a competitor. `part_totals` counts every part of each kind; `--part <headlines|descriptions|sitelinks|callouts> --offset <n>` reads one list a page at a time (`next_offset` until null). `--running` keeps what still runs, `--limit` sets rows per list or page (default 15), `--full` adds dates and every address the ads show (Google publishes no search ad's destination, only that address).
+
 `baker winning-ads refresh <advertiserId>` re-scrapes a followed brand so its newest ads land in the library. It applies immediately and runs at most once every 6 hours per brand; inside that window it answers `RATE_LIMITED` with an `error.fix` naming when the brand can be refreshed again. While a follow or the last refresh is still collecting the brand's ads, it starts nothing and says so.
 
 ### `baker winning-ads search <query>`
@@ -3461,6 +3591,7 @@ baker winning-ads search "delivery driver recruitment" --audience-temperature 0_
 | `--hook-archetype <list>` | Narrow to ads on a proven hook **seed** (from `winning-ads hooks`) |
 | `--format-pattern <list>` | Narrow to statics in these containers (from `winning-ads formats`, e.g. `comparison_table`) |
 | `--diverse` | One varied page (different brands, containers, hooks) instead of rank order; ignores paging |
+| `--all-kinds` | Also return Google search text, Shopping and app ads. By default only designed pictures and videos come back; `--format text` (or a query asking for search ads) returns search ads alone |
 | `--output json\|md\|files` | Output format (default json) |
 | `--fields <list>` | Only these row fields (e.g. `advertiser,container,mechanism`); a `--full`-only field turns `--full` on, an unknown one is refused with `error.fix.validValues` |
 | `--full` | Include DNA detail + longevity |
@@ -3520,7 +3651,7 @@ billed; the hint names the platform the fit was asked on, so a TikTok or LinkedI
 
 | Flag | Default | Description |
 |---|---|---|
-| `--platform <meta\|linkedin\|tiktok>` | `meta` | Which platform the id is on |
+| `--platform <meta\|linkedin\|tiktok\|google>` | `meta` | Which platform the id is on. The fit reads a still picture: a video ad (YouTube included) is refused (`VIDEO_REFERENCE`, read it with `content`), and on Google a search text ad, Shopping listing or app-install ad is refused (`NOT_A_DESIGN_REFERENCE`) |
 | `--full` | off | The whole answer, with the reasoning per element |
 
 ### `baker winning-ads advertisers <brand>`
@@ -3532,17 +3663,31 @@ baker winning-ads advertisers "Acme" --output md          # find our own adverti
 baker winning-ads advertisers "Deel" --platform meta --output md
 ```
 
-### `baker winning-ads follow "<domain | profile URL | brand>" --platform meta|linkedin`
+### `baker winning-ads follow "<website | brand | link>"`
 
-Add **all** of a brand's ads to your library — every platform (Meta + LinkedIn) and every country → `POST /api/ad-library/follow`. `--platform` is **required**, but it only tells us how to read your `input` (Facebook vs LinkedIn URL); it does **not** limit what we track. A bare domain is best: we resolve both the Meta page and the LinkedIn company from it and track both. Discovery is never region-scoped. The result `status` is one of:
+Add **all** of a brand's ads to your library — every platform (Meta, LinkedIn, TikTok, Google Ads), every account it runs there, and every country → `POST /api/ad-library/follow`. Paste whatever you have: a website is best — we resolve every Facebook page and LinkedIn company the site links (a brand often runs one per market), its TikTok account, and every Google Ads entity running its ads (never a reseller) — but a brand name or any profile / ad-library link works too. Discovery is never region-scoped. `--platform` is accepted and ignored. The result `status` is one of:
 
 - `following` — the brand is already in the corpus; you're now subscribed (no wait).
 - `added` — a new brand was queued for ingestion; its ads appear as discovery completes (a `hints[]` note flags this).
-- `ambiguous` — the input mapped to multiple brands; pick one from `candidates` and re-run with a more specific domain/URL.
+- `ambiguous` — the input mapped to multiple brands; pick one from `candidates` and re-run with a more specific website/link.
+
+`suggestions` lists accounts only *named* like the brand (say, another country's Facebook page its site doesn't link). They are not tracked; `hints[]` carries a ready `add-accounts` command for them.
 
 ```bash
-baker winning-ads follow "deel.com" --platform meta
-baker winning-ads follow "https://www.linkedin.com/company/acme" --platform linkedin --label "Acme (competitor)"
+baker winning-ads follow "deel.com"
+baker winning-ads follow "https://www.linkedin.com/company/acme" --label "Acme (competitor)"
+```
+
+### `baker winning-ads discover "<website | brand | link>"`
+
+The `accounts` and `suggestions` a follow would find, without following anything → `POST /api/ad-library/discover`. Paid lookups. Each account is compact — `platform`, `name`, `followers`, `ads_url` (its public ad library, to check it is the brand's) and `input` (what to paste into `add-accounts`); `--full` adds every other field the lookup read.
+
+### `baker winning-ads add-accounts <advertiser> "<link,link,...>"`
+
+Track more accounts under a brand you already follow — another market's Facebook page, a second LinkedIn company, another Google Ads entity → `POST /api/ad-library/accounts/add`. Each input is a profile or ad-library link, a Google advertiser id (`AR…`) or a website; up to 20. The response lists `added`, `already_tracked`, and `failed` (with a reason per input); one input failing never blocks the rest. An account that already belongs to a different brand in the library is refused — follow it as its own brand.
+
+```bash
+baker winning-ads add-accounts adv_123 "https://www.facebook.com/barkibu.it,AR01614014350098432001"
 ```
 
 ### `baker winning-ads following`
@@ -3576,18 +3721,28 @@ baker winning-ads feed --advertiser adv_123,adv_456 --platform meta --output md
 | `--limit <n>` | Total winners across all follows 1–200 (default 40) |
 | `--winner-category <list>` | Restrict to specific winner categories |
 | `--format <list>` | Restrict to specific formats (e.g. `static,video`) |
+| `--all-kinds` | Also return Google search text, Shopping and app ads (default: designed pictures and videos only; `--format text` returns search ads alone) |
 
 ### `baker winning-ads winners <advertiser>`
 
-Top winning ads for one advertiser id → `GET /api/ad-library/advertiser-winners` (use `feed` for all your follows at once). Same lean winner cards as `search` (add `--full` for DNA + longevity). Supports `--top N` and `--platform meta|linkedin`.
+Top winning ads for one advertiser id → `GET /api/ad-library/advertiser-winners` (use `feed` for all your follows at once). Same lean winner cards as `search` (add `--full` for DNA + longevity). Supports `--top N`, `--platform meta|linkedin|tiktok|google` (omit it for the top winners across every platform) and `--per-platform`, which adds `by_platform`: each platform's own top winners, since scores don't compare across platforms.
 
 ```bash
-baker winning-ads winners adv_123 --top 15 --output md
+baker winning-ads winners adv_123 --per-platform --top 5 --output md
+```
+
+### `baker winning-ads ads <advertiser>`
+
+Every ad one advertiser has run → `GET /api/ad-library/advertiser-ads`, one row per distinct ad, the same cards as `winners`. `--platform meta|linkedin|tiktok|google` narrows it to one platform (omit it for all together), `--format video,static,carousel,text` to those formats (`text` is a Google search ad), `--running all|running|stopped` to what still runs or what stopped. Rows come strongest first. Pages with `--limit` (1-100, default 24) and `--offset`: the response carries `total` and `next_offset` (`null` on the last page).
+
+```bash
+baker winning-ads ads adv_123 --platform google --running running --output md
+baker winning-ads ads adv_123 --offset 24
 ```
 
 ### `baker winning-ads content <ad-id>`
 
-Read what's **inside** one ad → `GET /api/ad-library/ad-content`. `search`/`winners`/`feed` return a lean shortlist; this opens a single `ad_id` so you can understand a reference before reproducing it. For a **video** it returns the spoken `transcript`, the `on_screen_text` overlays, and the ad `copy` (`primary_text`/`headline`/`cta`). A **static** or **carousel** ad returns the text drawn into the image, each line led by its job and card (`card 2 · headline: …`); a static also returns its `format_pattern`. Add `--full` for how the ad is built (composition, colours, CTA drawn in the image, markers such as price tags or badges), how it persuades (awareness stage, mechanism, pain points, desires, value props, proof, objections handled), what it offers (offer type, pricing, entry price, guarantee, urgency, bonus), and for video its speech, pacing, soundtrack and each overlay's role + position (e.g. `GLOBAL PAYROLL @0.5s [hook, top]`). Fields the ad does not carry are left out. `--platform meta|linkedin|tiktok` selects which platform the id is on (default `meta`).
+Read what's **inside** one ad → `GET /api/ad-library/ad-content`. `search`/`winners`/`feed` return a lean shortlist; this opens a single `ad_id` so you can understand a reference before reproducing it. For a **video** it returns the spoken `transcript`, the `on_screen_text` overlays, and the ad `copy` (`primary_text`/`headline`/`cta`, plus `landing_url`; a Google ad also carries `google_ad_type`). A **static** or **carousel** ad returns the text drawn into the image, each line led by its job and card (`card 2 · headline: …`); a static also returns its `format_pattern`. Add `--full` for how the ad is built (composition, colours, CTA drawn in the image, markers such as price tags or badges), how it persuades (awareness stage, mechanism, pain points, desires, value props, proof, objections handled), what it offers (offer type, pricing, entry price, guarantee, urgency, bonus), and for video its speech, pacing, soundtrack and each overlay's role + position (e.g. `GLOBAL PAYROLL @0.5s [hook, top]`). Fields the ad does not carry are left out. `--platform meta|linkedin|tiktok|google` selects which platform the id is on (default `meta`).
 
 ```bash
 baker winning-ads content adg_123                          # transcript + on-screen text + copy
@@ -3603,6 +3758,22 @@ Stop following a brand by advertiser id → `POST /api/ad-library/unfollow`. Ret
 baker winning-ads unfollow adv_123
 ```
 
+### Decisions about text (`baker decide`)
+
+Typed questions about text, answered by Jev (a decision model) with a probability: a yes/no (`noul`), one option of your set (`choice`) or a level on a scale (`score`). Read-only, text only, never generates prose. Works with a `bk_`, `bkr_` or `bkv_` key, so a published Report can call it.
+
+```bash
+baker decide --questions '{"b2b":{"type":"noul","question":"Is `message` written for a business buyer?"}}' --state '{"message":"…"}'
+baker decide --questions questions.json --items ads.json --state '{"advertiser":"Notion"}' [--full]
+```
+
+- `--questions` (required): `{ "<name>": { "type": "noul", "question" } | { "type": "choice", "question", "options": { "<key>": "<meaning>" } } | { "type": "score", "question", "levels": [lowest, …, highest] } }`.
+- `--items`: `[{ "id", "text": "…" | { "<field>": "…" } }]`. Every question is asked about every item, which reaches Jev as `` `item` `` inside its own question. Up to 500 items of 4,000 characters, 2,000 questions per call; packed into requests of up to 200 questions sent at once.
+- `--state`: shared context, or the text itself when there are no items (inline JSON, a file, `-`, or plain text).
+- Each flag that takes JSON accepts it inline, as a file path, or `-` for stdin.
+- Output: `{ model, answers | items: [{ id, answers | null }], unanswered, requests, costUsd }`. A noul is `{ noul }`; a choice `{ choice, probability, confidence }`; a score `{ score, level, confidence }`. `--full` adds every option's `probabilities`.
+- When the model does not answer, the error carries `fix.action: "degrade"`: carry on without the answers rather than abort.
+
 ### Scheduled agents (`baker scheduled-agents`)
 
 A Scheduled agent is a **trigger** and a **prompt**. When the trigger fires, a Session opens with that prompt and does the job — there is no Task in between. `create`, `update`, and `delete` stage draft ops on `BAKER_CHAT_ID` and apply when the chat is published. `unstage` takes back what this chat staged on one item before Publish (`--index <n>` for one change only, by its index in `list` → `draft.ops`). `list` and `get` include draft state when `BAKER_CHAT_ID` is set; `get` on a published item also returns `runsAs` — who each run acts as and which tools it loads. `run` fires a published item immediately and does not require a chat id. Publishing every run unreviewed is switched on by the user on the item, never through the CLI: `--auto-publish` is refused with an `ask_user` fix.
@@ -3726,11 +3897,11 @@ Read and shape this workspace's Forms (flows). Operates on the local `_data.json
 
 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.
+**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 set with `baker flows connect` whenever the agent knows the answer (an email's recipients and subject always; a connected platform's resource; a webhook with no token), and otherwise 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
 baker flows list                                   # every Form + how many confidential fields still need setup
-baker flows show contact                           # confidential fields + whether the destination changed under this Form
+baker flows show contact                           # confidential fields, where each sealed destination sends (never a credential), and drift
 baker flows show contact --full                    # include the full flow tree (secret values redacted)
 
 baker flows schema                                 # both vocabularies + the customForm field types
@@ -3745,11 +3916,14 @@ baker flows options calendly                        # what a step/destination ca
 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 --side-effect se-pipedrive-1         # Pipedrive / GoHighLevel / ActiveCampaign contact: the account is the destination
+baker flows connect contact --side-effect se-email-1 --email "ana@x.com, luis@x.com" --subject "New lead — Contact"   # an email destination: the agent states it, never a card
+baker flows connect contact --side-effect se-httpWebhook-1 --url https://hooks.example.com/lead   # a webhook that needs no token
 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
+baker flows map contact --map email=email --map 'tags="withbaker-"+tracking:page_path' --write   # ActiveCampaign: fields read off the account; tag each lead with its page
 baker flows map contact --side-effect <id> --hubspot-form <guid> --prune-missing --write   # drop dead mappings
 baker flows map contact --from map.json --replace --write   # the slot becomes exactly this; drops everything not named
 baker flows normalize contact --write              # repairs a nulled optional; runs pre-commit anyway
@@ -3759,12 +3933,13 @@ 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.
 - **`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>`.
+- **`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, a GoHighLevel contact and an ActiveCampaign 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>`.
+- **`--email` / `--url` replace a destination whole, so they leave alone what only the user can set.** `--all --email` passes over an email that replies to the visitor's own answer (and says so in its hints); naming one is refused. A webhook that sends a credential keeps its address until the user re-enters both through `request_flow_input`. Unreadable settings are also left alone by default. For one unreadable email, `--replace-unreadable --email <complete list> --subject <text>` replaces the old setup when the user intends replacement, without revealing it. Never use this to add to an unknown recipient list; it cannot override `--all`, a known visitor reply, or a webhook. `flows show` reads back only destinations sealed for this company.
 - **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.
+- **`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, ActiveCampaign by field key (`email`, `firstName`, a custom field's id, `tags`, `lists`, `automations`, `note`, or a qualified `deal.title` / `account.name` / `event.name`), Crmble by field id. That is why there is no `--key`, and why `--entity` and `--custom`/`--standard` are required rather than defaulted for Pipedrive and GoHighLevel.
 - **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.
-- **A CRM mapping's field type is derived from the destination, never defaulted.** Every CRM record types `fieldType` as required, and it is the account's answer, not the agent's — HubSpot builds its submission key as `<objectTypeId>.<fieldType>.<fieldName>`, so a wrong type on a date property skips the `YYYY-MM-DD` coercion and the value is dropped. `--hubspot-form <formGuid>` (or `"hubspotForm"` in the mapping file) reads every property's type and object type off the form, so nothing has to state one. Where a destination cannot be read, put the type on the LEFT — `c0ffee:varchar=email` — which leaves `:` on the right for the value kinds. A mapping with no type from either route is refused, never written without one.
+- **A CRM mapping's field type is derived from the destination, never defaulted.** Every CRM record types `fieldType` as required, and it is the account's answer, not the agent's — HubSpot builds its submission key as `<objectTypeId>.<fieldType>.<fieldName>`, so a wrong type on a date property skips the `YYYY-MM-DD` coercion and the value is dropped. `--hubspot-form <formGuid>` (or `"hubspotForm"` in the mapping file) reads every property's type and object type off the form, so nothing has to state one. An `activeCampaignContact` mapping reads the connected ActiveCampaign account's field list on every call — no flag — so its types (`standard`, `custom`, `tags`, `lists`, `automations`, `deal`, `account`, `note`, `event`) are derived too, a custom field may be named by its id, personalization tag or label (stored as the id) — or as `custom.<TAG>` for one that is only staged so far, resolved when each lead is sent — and a name the account does not have is refused with the list of the ones it does. Its `tags`, `lists` and `automations` mappings are comma-separated names or ids that may mix text and variables, e.g. `tags="withbaker-"+tracking:page_path`; `deal.title` or `deal.pipeline` creates a deal (`deal.value` in major units, `deal.stage` / `deal.owner` by name or id), `account.name` finds or creates the lead's company, `note` leaves a note and `event.name` records an event (it needs the account's event key on the connection). The answer's `hints` name a list, automation, pipeline, stage or user the account does not have, a deal nothing creates, and an event with no event key. Where a destination cannot be read, put the type on the LEFT — `c0ffee:varchar=email` — which leaves `:` on the right for the value kinds. A mapping with no type from either route is refused, never written without one.
 - **`email` maps like anything else**, into `body.fields`, while `body.format` is `"json"`. A `"body"`-format email is one written message with no keys to address, and `map` refuses it rather than reshaping the body.
 - **A Form can look finished and be losing every lead.** HubSpot refuses a submission that names a property it does not have — the whole submission, not the field — and the visitor still reaches the thank-you screen. Baker re-checks each Form's destination and `baker flows show <slug>` reports what it found: `data.drift[]` carries **one entry per drifted destination** — a Form with two HubSpot side effects has two mappings, two form ids and two repairs — each with the severity, a sentence naming the fields, the side-effect id and that destination's HubSpot form id; the hints carry one repair command per entry. `drift: null` means the check could not be made and is not the same answer as `[]`.
 - **`--prune-missing` is the repair; `--replace` is not.** With `--side-effect <id>` and `--hubspot-form <guid>`, `--prune-missing` drops exactly the mappings whose destination field is absent from that form's live field list, names each one in `dropped`, and leaves every other mapping alone. It needs no `--map` and runs on its own. `--replace` drops everything the call does not name, so using it to remove three dead mappings means first restating the ten good ones correctly.
@@ -3774,7 +3949,7 @@ Notes:
 - **`normalize` exists so authoring a Form does not require remembering an exception.** `oauthProviderId` is an optional `string`, so a `null` there fails typecheck one build later — it is repaired and staged instead of rejected.
 
 - **Secrets never travel through this CLI or the chat.** `show` reports only whether each field is configured (`[set]`/`[missing]`, `[connected]`/`[needs connection]`, selected/not selected) — never a value. Configured secrets appear only as `[configured]` ciphertext markers.
-- Confidential side-effect types: `httpWebhook`, `zapier`, `crmble` (typed credentials); `pipedrive`, `googleSpreadsheet`, `hubspotForm`, `goHighlevelContact` (OAuth connection + resource); `email`. Widget node types needing a resource pick: `calendly`, `savvycal`, `hubspot`, `hubspotMeeting`, `highlevel`, `highlevelForm`.
+- Confidential side-effect types: `httpWebhook`, `zapier`, `crmble` (typed credentials); `pipedrive`, `googleSpreadsheet`, `hubspotForm`, `goHighlevelContact`, `activeCampaignContact` (connected account + resource); `email`. Widget node types needing a resource pick: `calendly`, `savvycal`, `hubspot`, `hubspotMeeting`, `highlevel`, `highlevelForm`.
 - `request_flow_input` changes stage on the chat's branch and apply when the chat is published; discarding the chat drops them.
 
 ### Action Items (`baker actions`)
@@ -4309,10 +4484,14 @@ A skill fills only what you did **not** pin — `--model`, `--aspect-ratio` and
 
 ## Creative Canvas
 
+Static-ad guidance prefers a ready company Avatar whenever an actor is needed, chosen for the buyer context. A real founder or testimonial author uses their verified likeness; if it cannot be found, use initials or no face. The shared creative instructions also call for deliberate complete-logo selection, one consistent primary CTA treatment, and deterministic rendering of recognizable interfaces. Screen guidance distinguishes laptops and notebook computers from paper notebooks beside a phone.
+
 The creative canvas runs declarative JSON pipelines. You author a graph of nodes (text, image, video, audio, composition, control-flow), `baker canvas run` it, and every node's output drops to disk under `canvas/<run_id>/` so you can watch progress and consume the artifacts.
 
 Auth: same `BAKER_API_KEY` + `BAKER_API_URL` as the rest of the CLI.
 
+Static resizes, fixes and series continuations keep why the original ad works and the elements its concept depends on, alongside the previous image. Older specs carry their persuasion mechanism and its reason instead. Automatic spec repairs preserve the concept, mechanism, message, brand (including the CTA color) and native interface; they can correct the execution without changing the idea. Change those choices explicitly in `prompt.json` when the brief changes.
+
 ### Quick start
 
 ```bash
@@ -5972,7 +6151,7 @@ A completed render the review calls ready (`verdict` `ready` or `ready_with_note
 
 **Static ads: the run corrects a blocking defect itself.** When the review of a static ad finds a blocking defect, `baker canvas run` makes up to 3 more renders (`AUTO_FIX_ROUNDS` in `static-autofix.ts`) before it reports, correcting each defect at the layer that causes it: words or a logo where an interface covers them (Reels, Stories) or the frame cuts them are **placed and extended** (`withExtendedSizes`): a `static_place` node reads where everything sits and shrinks the ad (to 60% at most) into the size's safe area, and a `static_extend_merge` node has the ad's own model paint the margins that leaves and keeps its painting as one picture across the whole frame, laying the ad's own pixels back only over the words, logo and buttons the placing read (padded and feathered, so no edge of the shrunk ad shows; the whole ad is laid back, as before, when nothing was read or the painting moved the words), so the model is never asked to move anything (a size already inside its area is passed on with nothing painted or billed, and one whose words sit too far out for a shrink to clear, or that the placing found inside its area while the review still blocks it, is laid out again instead, never placed the same way twice; a button is placed by its shape, its words grown by 0.7 of their height on every side, as the review judges it); a defect the spec asked for (a second subject, stars with no named source, a concept that does not read) and any defect of a native screen corrects the spec first (`static-spec-repair.ts`: a model rewrites `prompt.json` for those findings alone, every line of the copy kept word for word), then draws the ad again from it (a native screen redraws free); a picture wrong as a whole or in three places or more is made again from its brief, told what the last one got wrong, but only in a round with another after it unless the brief caused the defect; anything else on the picture is a `--fix` of the chosen picture for its own findings (`correctionOf`: the words to erase, the line to re-letter or add), naming what the last edit was already asked for, while each re-laid size the review flagged follows as an edit of its own last layout (`withSizesFollowingFix`), keeping what an earlier round fixed in it, and a size it found nothing blocking on is delivered as it was (`keep`, nothing in it made again or placed); anything else on a re-laid size alone edits just that size from its own last layout (`withRelayEdit`); sizes that do not show the same ad (`SIZES:`) are always the re-laid ones' fault, since every size follows the chosen picture, so they are laid out again to show exactly what it shows, never the picture edited to match them. A size a round did not touch (its file the same byte for byte) keeps the round before's verdict (`carryUnchanged`) and is not read again: the review reads only the sizes the round changed. Each correction is told what earlier rounds fixed so it keeps it right (`keptRules`), and starts from the best attempt so far: one that came out with more blocking defects than an earlier attempt is set aside and the earlier one corrected instead (`correctFrom`). Each round is one render (a fix, or one request per re-laid size) and prints `[autofix] round N of 3: …` on stdout; the final JSON's hints start with "Corrected automatically before this result, …" and its review is of the corrected version. Blocking findings left after the rounds keep the hints below. A round that would only repeat the correction that just left its defect in place (a chosen option, `--use-variant`, is only ever corrected) is not run: that version is reported as it is. `--no-autofix` reports after the first render.
 
-**Static ads: correct a version, or use another of its variants.** Correct a finished version with `--fix "<what to change>"`: one render takes that version (the last one, or `--from <run_id>`) as its first reference and changes only what you said, keeping the picture, the layout and every other word; it replaces the variants and the judge, and every size is made again from the corrected picture. **A `prompt.json` changed only in its words, their positions or its colours** since the version shown is made the same way, as an edit of that version (`[edit]` in the output, the instruction read off the change); three new options are asked for only with `--regenerate static_variants`. A `--fix` whose defect is still blocking afterwards is recorded, and asking for it again with the same words exits 2 with `no_progress`. When every blocking finding is on re-laid-out sizes, the first hint says to lay out those sizes again (`--regenerate adapt_<size>`) before any `--fix`. Every static run's hints say what it cost in credits and what for. There is no render limit per creative. Use another variant with `--use-variant <sha256>` (`--from <run_id>`, default the last render): when the person asks in the chat for another of a version's variants over the judge's pick, every size is made again from that picture, and the only requests re-lay it out for each other size; `--regenerate adapt_9x16` lays out one size again from the same chosen picture when only that size came out wrong (after a `--fix` or `--use-variant`, from that corrected or chosen picture, so the size never brings back the uncorrected one; `--from <run_id>` names another version).
+**Static ads: correct a version, or use another of its variants.** Correct a finished version with `--fix "<what to change>"`: one render takes that version (the last one, or `--from <run_id>`) as its first reference and changes only what you said, keeping the picture, the layout and every other word, and every size is made again from the corrected picture. **A correction grows on top of the version it starts from**: the run executes that version's own graph (its variants, the prefilter and pick, every earlier correction) with each of those steps pinned to the outputs that version recorded (free, never re-rendered, whatever `prompt.json` says now), then appends `edit_1` (the picture as its first reference, framed for the master as a variant is) and makes the sizes from it; a second correction appends `edit_2` on `edit_1`. `--use-variant` wires the chosen variant from the version's own `gen` as a `chosen` step, and a `--regenerate adapt_<size>` keeps the version's picture the same way. So the run record, and the dashboard's workflow of each version, show the whole history: options, pick, edits, sizes. The canvas file is never rewritten. Every static run keeps the graph it executed in the asset store (`graphUrl` on its run record, up to 4 MB), so a version rendered in another workspace ("Edit creative …" from a new chat, `--from <run_id>`) grows the same way, its steps pinned to the outputs its run record holds; only a run recorded before graphs were kept is corrected from its picture by URL. **A `prompt.json` changed only in its words, their positions or its colours** since the version shown is made the same way, as an edit of that version (`[edit]` in the output, the instruction read off the change); three new options are asked for only with `--regenerate static_variants`. A `--fix` whose defect is still blocking afterwards is recorded, and asking for it again with the same words exits 2 with `no_progress`. When every blocking finding is on re-laid-out sizes, the first hint says to lay out those sizes again (`--regenerate adapt_<size>`) before any `--fix`. Every static run's hints say what it cost in credits and what for. There is no render limit per creative. Use another variant with `--use-variant <sha256>` (`--from <run_id>`, default the last render): when the person asks in the chat for another of a version's variants over the judge's pick, every size is made again from that picture, and the only requests re-lay it out for each other size; `--regenerate adapt_9x16` lays out one size again from the same chosen picture when only that size came out wrong (after a `--fix` or `--use-variant`, from that corrected or chosen picture, so the size never brings back the uncorrected one; `--from <run_id>` names another version).
 
 #### `baker canvas scaffold-video <video> [flags]`
 
@@ -6102,11 +6281,11 @@ The canvas is validated before it is written. stdout returns `{ ok, canvas_path,
 
 **Who sees the ad.** `--target-adset <id>` names the Meta ad set the ad will run in. Before anything is billed, the viewer its targeting reaches is read exactly as `baker ads meta adsets --audience` reads it (`temperature`, what they already `knows`, `placements`) and written to `_definition.md` as `targetAdSet` and `viewer` (an existing definition keeps every other field). The sizes, the brief and the prefilter keep clear of that viewer's placements (`staticSafeArea`; `automatic`, a bare `facebook`/`instagram` or no placements is Advantage+, Reels included), and every `baker canvas run` checks the ad against that viewer. With no ad account, give the viewer from the Knowledge: `--viewer-temperature cold|warm|hot [--viewer-knows brand,offer,product] [--viewer-placements <placement,…>]`, recorded with `source: knowledge`; next to `--target-adset` they correct the read, and its `reasons` say so. A bad value exits 2 (`invalid_viewer`) before any billed pass; an ad set that cannot be read never stops the scaffold (a hint says why, and the sizes keep clear of every placement). With neither flag, a `viewer` (or `targetAdSet`) already in `_definition.md` is used as it is. stdout carries `target_adset`, `viewer` and a `checklist.viewer` line.
 
-**After a run** the CLI reads the finished ad back on what makes a static win, not a checklist of elements: every delivered image's pixel shape against its format; **every line of `prompt.json`'s copy (in-scene and designed alike) read back with its box by a box reader and compared** (a line more than 2% off, missing, or joined by words nobody asked for is blocking; case and punctuation fold, as does a capital I read as an l (one stroke in a sans-serif), accents do not; words the picture adds are blocking only when set at the copy's usual size or making a claim (a figure, a price, an offer), and otherwise a note, as a screen's code, a poster or a mug in the scene, except a price (a currency sign beside a figure) the copy does not hold, blocking at any size and blurred by the correction, the document it is on kept; every render is asked for no readable prices on a bill, quote, receipt, screen or price tag beyond the copy; a copy line is "on the ad twice" only when most of its words repeat, never a word or two echoed on a prop; on a native screen, which code typesets from the spec, a line read differently is the reader's error and only a missing one counts); **the ad's own copy and its logo measured against the format's safe area** (`staticSafeArea`, the one owner of those areas; `must-show.ts` decides what is measured: never what the scene prints, nor a copy line printed again in the scene while the line itself sits clear). On a 9:16, which runs in Stories and Reels alike, what Stories' header or bottom bar covers (and any other app's interface named) is said as "where Stories and Reels cover it" ("where Reels covers it" for an ad set that runs only in Reels) and blocks for the logo, the button, the headline, the figure and the offer, while a supporting line (body, caption, label, small print) there is a note; what only Reels' taller footer covers is one note, and only for the lead line, since Stories shows it and the 9:16 is laid out in Stories' band; words merely close to where an app draws are no finding. The steps that place a size clear of an interface (`static_safe_fit`, `static_place`) are told the same copy (`prompt.json`'s lines, their roles, and the brand's name and the logo's words, a wordmark read close to them counting as the logo) and move the ad for those alone, a supporting line included only where the frame cuts it; on a feed image such as a 4:5, only a design margin, so words close to the edge are a warning and only words the frame cuts are blocking); a copy line written over two lines (`"15%\noff"`) is matched part by part wherever the reader finds each; designed type in a colour far from the brand palette is a warning; supporting lines too small to read on a phone are one note per size; the main line set smaller than a supporting one is a note, the brand's wordmark never counted as part of a line that starts with its name; the logo set twice is a note, a far smaller mark printed on something in the scene (a hoodie, a bag) is not. When the copy names a real person ("Lautaro Suarez, CTO at Vibiz", "田中 美咲、Acme 創業者"; read by a text model in any language, cached by copy, `scripts/named-people-evals`), the run casts them as themselves before it renders (`baker avatars research --create`, their avatar's sheet added to `prompt.json` `references` as a `PERSON_n`), and a face shown as a named person the ad has no photo of is blocking. When the reader cannot answer, the vision pass transcribes the copy instead and judges the safe zones by eye. Then one vision pass for clipping, overlaps, artifacts, one dominant idea, the brand with the logo covered and the concept's mechanisms (each finding typed by the model with the item it answers, what it is about, what is wrong and the edges that cut it, which the grading and the automatic correction read instead of its words), with every format shown a second time at phone-feed thumbnail size (240px wide, same call): a lead message unreadable at that size is blocking. A missing logo, CTA or copy is never a finding; a logo that is drawn and broken is. stdout carries `verdict` (`ready` | `ready_with_notes` | `needs_fixes` | `not_reviewed`), `judge` (the per-candidate scores) and hints that end with what the run made; the findings are stored on the run as its `review`. `needs_fixes` means the ad is not done even though every node completed, and the run is recorded with `presentable: false` so it is never shown as a version; every fix is an edit to `prompt.json` and a re-run (wrong words: the lines in `copy`; wrong picture: the `scene`; a bad roll: `--regenerate static_variants`; one size wrong while the chosen picture is right: `--regenerate adapt_<size>`, which re-lays it out, named in the hints); a blocking defect is first corrected by the run itself (`--autofix`, above). The checks rank the variants before the pick and the judge only breaks an exact tie, comparing pairwise against the compiled brief, knowing the brand and the viewer; every variant stays on offer to the person in Baker. Within one chat turn an ad gets two runs you start (each with its automatic corrections) and about 12 minutes in all: a correction round that would take it past that is not started (`[autofix] not started`), the version shown as it stands, and no render starts once it is spent or once the ad is `ready` or `ready_with_notes`: the next is refused (`CONFLICT`, exit 2) with what to show instead; the person's next message starts a new turn (`turn-renders.ts`). When a defect still stands after the automatic rounds, the hints say to fix it with a `--fix`, then by changing the spec or the approach, and if it still cannot be fixed to show the best version and name what is left in one plain sentence, without a question.
+**After a run** the CLI reads the finished ad back on what makes a static win, not a checklist of elements: every delivered image's pixel shape against its format; **every line of `prompt.json`'s copy (in-scene and designed alike) read back with its box by a box reader and compared** (a line more than 2% off, missing, or joined by words nobody asked for is blocking; case and punctuation fold, as does a capital I read as an l (one stroke in a sans-serif), accents do not; words the picture adds are blocking only when set at the copy's usual size or making a claim (a figure, a price, an offer), and otherwise a note, as a screen's code, a poster or a mug in the scene, except a price (a currency sign beside a figure) the copy does not hold, blocking at any size and blurred by the correction, the document it is on kept; every render is asked for no readable prices on a bill, quote, receipt, screen or price tag beyond the copy; a copy line is "on the ad twice" only when most of its words repeat, never a word or two echoed on a prop; on a native screen, which code typesets from the spec, a line read differently is the reader's error and only a missing one counts); **the ad's own copy and its logo measured against the format's safe area** (`staticSafeArea`, the one owner of those areas; `must-show.ts` decides what is measured: never what the scene prints, nor a copy line printed again in the scene while the line itself sits clear). On a 9:16, which runs in Stories and Reels alike, what Stories' header or bottom bar covers (and any other app's interface named) is said as "where Stories and Reels cover it" ("where Reels covers it" for an ad set that runs only in Reels) and blocks for the logo, the button, the headline, the figure and the offer, while a supporting line (body, caption, label, small print) there is a note; what only Reels' taller footer covers is one note, and only for the lead line, since Stories shows it and the 9:16 is laid out in Stories' band; words merely close to where an app draws are no finding. The steps that place a size clear of an interface (`static_safe_fit`, `static_place`) are told the same copy (`prompt.json`'s lines, their roles, and the brand's name and the logo's words, a wordmark read close to them counting as the logo) and move the ad for those alone, a supporting line included only where the frame cuts it; on a feed image such as a 4:5, only a design margin, so words close to the edge are a warning and only words the frame cuts are blocking); a copy line written over two lines (`"15%\noff"`) is matched part by part wherever the reader finds each; designed type in a colour far from the brand palette is a warning; supporting lines too small to read on a phone are one note per size; the main line set smaller than a supporting one is a note, the brand's wordmark never counted as part of a line that starts with its name; the logo set twice is a note, a far smaller mark printed on something in the scene (a hoodie, a bag) is not. When the copy names a real person ("Lautaro Suarez, CTO at Vibiz", "田中 美咲、Acme 創業者"; read by a text model in any language, cached by copy, `scripts/named-people-evals`), the run casts them as themselves before it renders (`baker avatars research --create`, their avatar's sheet added to `prompt.json` `references` as a `PERSON_n`), and a face shown as a named person the ad has no photo of is blocking. When the reader cannot answer, the vision pass transcribes the copy instead and judges the safe zones by eye. Then one vision pass for clipping, overlaps, artifacts, one dominant idea, the brand with the logo covered and the concept's mechanisms (each finding typed by the model with the item it answers, what it is about, what is wrong and the edges that cut it, which the grading and the automatic correction read instead of its words), with every format shown a second time at phone-feed thumbnail size (240px wide, same call): a lead message unreadable at that size is blocking. A missing logo, CTA or copy is never a finding; a logo that is drawn and broken is. stdout carries `verdict` (`ready` | `ready_with_notes` | `needs_fixes` | `not_reviewed`), `judge` (the per-candidate scores) and hints that end with what the run made; the findings are stored on the run as its `review`. `needs_fixes` means the ad is not done even though every node completed, and the run is recorded with `presentable: false` so it is never shown as a version; every fix is an edit to `prompt.json` and a re-run (wrong words: the lines in `copy`; wrong picture: the `scene`; a bad roll: `--regenerate static_variants`; one size wrong while the chosen picture is right: `--regenerate adapt_<size>`, which re-lays it out, named in the hints); a blocking defect is first corrected by the run itself (`--autofix`, above). The checks rank the variants before the pick and the judge only breaks an exact tie, comparing pairwise against the compiled brief, knowing the brand and the viewer; every variant stays on offer to the person in Baker. Within one chat turn an ad gets two runs you start (each with its automatic corrections) and about 12 minutes in all: a correction round that would take it past that is not started (`[autofix] not started`), the version shown as it stands, and no render starts once it is spent; once the ad is `ready` or `ready_with_notes` only a correction of it starts (`--fix`, `--regenerate adapt_<size>`, or an edit of its words or colours), within the same two runs, and anything else is refused (`CONFLICT`, exit 2) with what to show instead; the person's next message starts a new turn (`turn-renders.ts`). When a defect still stands after the automatic rounds, the hints say to fix it with a `--fix`, then by changing the spec or the approach, and if it still cannot be fixed to show the best version and name what is left in one plain sentence, without a question.
 
 The render prompt is **model-aware**: each model's profile (`src/engine/lib/prompt-profiles.ts`) sets its shape, word budget, picture order and request params. gpt-image gets short labelled sections with the constraints last; Gemini gets sentences that give the reason and a positive closing list of the only words allowed. A profile change, or a new model on the router (`src/engine/lib/image-model-router.ts`), is re-run on the static bench (`scripts/creative-evals`, `--job static`) before it ships. Run `baker canvas critique` on the scaffolded canvas for an advisory read before you spend.
 
-**A reference from the winners library goes in by id.** `--source-ad-id <ad_id> --source-platform meta|linkedin|tiktok [--source-advertiser-id <id>]` (the ids beside the ad in `baker winning-ads search`) fetches the library's structured read of that ad, the same one `baker winning-ads content <ad_id> --full` returns, and writes it into `prompt.json` as a `reference` block: `{ ad_id, platform, advertiser, advertiser_id, format_pattern, layout: { composition, focal_subject, aspect_ratio, background, palette_mood, colors, production, aesthetic, cta_in_image, markers }, message: { mechanism, awareness, sophistication, angle, hook_archetype, pain_points, desires, value_props, objections_handled, proof, risk_reversal }, offer: { offer_type, pricing_model, entry_price, no_credit_card, guarantee, guarantee_days, urgency, bonus }, text_blocks: [{ text, role, position }], copy: { primary_text, headline, cta } }` (filled fields only). The describe pass still reads the pixels but is told that read as grounding, so the two cannot disagree on the container or the mechanism; when it names no `winning_mechanisms`, the library's container + mechanism seeds the list. The source ids (`sourceAdId`, `sourcePlatform`, `sourceAdvertiserId`, and `sourceAdvertiser` from the library when `--advertiser` is absent) are written to `_definition.md` and synced to the creative at scaffold time. A library read that fails warns, records the ids anyway and scaffolds from the picture alone (`hints`: `REFERENCE NOT READ`); with no picture either, the command exits 2 (`source_unavailable`). `baker canvas sync-definition` re-reads the three ids from `_definition.md` on every sync.
+**A reference from the winners library goes in by id.** `--source-ad-id <ad_id> --source-platform meta|linkedin|tiktok|google [--source-advertiser-id <id>]` (the ids beside the ad in `baker winning-ads search`) fetches the library's structured read of that ad, the same one `baker winning-ads content <ad_id> --full` returns, and writes it into `prompt.json` as a `reference` block: `{ ad_id, platform, advertiser, advertiser_id, format_pattern, layout: { composition, focal_subject, aspect_ratio, background, palette_mood, colors, production, aesthetic, cta_in_image, markers }, message: { mechanism, awareness, sophistication, angle, hook_archetype, pain_points, desires, value_props, objections_handled, proof, risk_reversal }, offer: { offer_type, pricing_model, entry_price, no_credit_card, guarantee, guarantee_days, urgency, bonus }, text_blocks: [{ text, role, position }], copy: { primary_text, headline, cta } }` (filled fields only). The describe pass still reads the pixels but is told that read as grounding, so the two cannot disagree on the container or the mechanism; when it names no `winning_mechanisms`, the library's container + mechanism seeds the list. The source ids (`sourceAdId`, `sourcePlatform`, `sourceAdvertiserId`, and `sourceAdvertiser` from the library when `--advertiser` is absent) are written to `_definition.md` and synced to the creative at scaffold time. A library read that fails warns, records the ids anyway and scaffolds from the picture alone (`hints`: `REFERENCE NOT READ`); with no picture either, the command exits 2 (`source_unavailable`). `baker canvas sync-definition` re-reads the three ids from `_definition.md` on every sync.
 
 ```bash
 baker canvas scaffold-static-ad --source-ad-id adg_123 --source-platform meta --slug spring-offer --platform meta --target-adset 120249211706990208
@@ -6138,6 +6317,10 @@ baker canvas run ./static-ad.canvas.json
 
 Scaffolding runs (and bills) the two vision passes; **running** the result generates billed images. `baker canvas validate` does not check that the `[TODO]` paths exist — supply the real files before `run`.
 
+Size adaptations move and proportionally scale the existing composition first, keeping its background treatment, including intentional flat colour. Generation, adaptation, correction and series briefs preserve plausible anatomy, device proportions, scale, perspective and support, and reflow text while preserving letter shapes. Recognizable app controls remain native; marketing overlays stay visibly separate. Shared guidance records applicable intent and constraints briefly in `_definition.md`, then carries them into `prompt.json` (Markdown is not a render input). Direct briefs need no invented winner or fixed template; reference adaptations reason through the mechanism, transfer hypothesis and what must survive. `creatives make` returns this preparation hint before rendering. Choose the represented role and inspect existing Avatars before creating a new actor; a real founder or customer keeps their verified identity.
+
+During continuations, the accepted image's screen content takes priority over geometry references unless explicitly changed. Laptop scenes receive guidance for a real laptop and consistent display, keyboard and hinge perspective.
+
 #### `baker canvas rerun <slug> [flags]` (deprecated)
 
 Now `baker canvas run --slug <slug>`; `rerun` stays as a hidden alias for one release and prints a deprecation note. Every `canvas run` of a creative records a portable snapshot (the canvas JSON plus the local files it ingests: prompt blueprints, composition dirs, reference images) in durable storage, so `run --slug` can rebuild `src/creatives/<slug>/` in a workspace that never had it. A snapshot whose files are exactly the last one uploaded for the creative is reused without a request, and a file the store already holds is not uploaded again. Files the snapshot could not include (missing at run time, or oversized) are listed as warnings.
@@ -7019,3 +7202,9 @@ Pushing to `main` with changes in `packages/cli/` triggers the GitHub Actions wo
 npx convex env set BAKER_CLI_VERSION <version>   # Override sandbox version
 npx convex env remove BAKER_CLI_VERSION          # Clean up after testing
 ```
+
+### Agreed tracking setup and external questionnaire diagnostics
+
+`baker analytics plan [--full]` reads the effective session plan. `--json @preparation.json` stages journeys, event purposes and readiness, optionally wiring conversion definitions, funnel steps and a managed Tag Manager installation. The generated base queues early events and runs before event tags; repeating preparation replaces its own draft operations. These changes apply only at Publish. Waiting events record the missing change and owner; prepared tags do not imply accepted events. The full request contract and example are in the scaffold's [analytics tool doc](../../apps/scaffold-template/__tooling__/docs/tools/baker/analytics.md#shared-journey-and-tracking-plan).
+
+`baker analytics questionnaire [--name questionnaire_step] [--days 7] [--inactivity 30]` reports distinct attempts reaching/completing/skipping questions and distinguishes pending, abandoned and incomplete steps. The external app must emit the documented attempt/version/sequence contract. The report refuses truncated histories above 600 events and excludes attempts without an observed start; no observations do not establish zero abandonment.