direct-cli 0.5.2__tar.gz → 0.5.3__tar.gz

{direct_cli-0.5.2 → direct_cli-0.5.3}/.github/workflows/quality.yml

@@ -38,6 +38,9 @@ jobs:
       - name: Type check
         run: mypy .
 
+      - name: Pyright
+        run: pyright
+
       - name: Run offline tests
         # Offline default comes from pyproject addopts (skips the live-network
         # markers). integration_write stays in — it replays VCR cassettes offline.

{direct_cli-0.5.2 → direct_cli-0.5.3}/CHANGELOG.md

@@ -1,9 +1,279 @@
 # Changelog
 
-## Unreleased
+## 0.5.3 — 2026-10-07
+
+### Fixed
+
+**`masters update` — the whole-form save can no longer silently wipe the
+campaign's target actions or Metrika counters, whichever field the call
+mutates (#872).**
+
+The edit page has exactly one save button and the save submits the WHOLE
+form, so every update — not just a URL/UTM one — resubmits the "Целевые
+действия" table and the counters section. The #836 protection (settled
+pre-save baselines + pre-click guard + post-save verification) was gated
+on `landing_url`/`tracking_params` being present, so a
+`masters update --weekly-budget` run saved a mid-hydration, emptied
+target-action table as a success: 4 live Мастер кампаний lost their
+goals and stopped spending (0₽/day with a healthy weekly budget). The
+protection now keys on the save itself: every mutating `update_master`
+call reads the same baselines, refuses to click Save when a protected
+section no longer matches its baseline ("Refusing to save"), and
+verifies the untouched goal set after the reload — an unchanged-table
+call with an unreadable baseline on a rendered section aborts instead of
+saving blind. A max-clicks campaign (no target-actions section rendered)
+and add/remove-target-action calls keep their existing semantics. On
+success the result row now carries `TargetActions` — the verified goal
+set that survived the save — so a `--from-file` batch shows the
+protected goals per campaign instead of an implicit absence of failure.
+Cost: an unchanged-table update spends a few extra seconds stabilizing
+the section reads.
+
+The protection also checks each goal's **price (CPA)**, not just which
+goals are present (#876). The save resubmits every goal's bid, so a price
+that shifts or resets while the goal stays would let the strategy keep
+spending at a different bid with no visible symptom. Both the pre-click
+guard and the post-save check now compare the full `{GoalId: Price}` map
+(the baseline with any `--target-action-price` changes applied), and
+`TargetActions` in the result row is `[{"GoalId": …, "Price": …}]`.
+
+**`direct playwright login` — honest `verified` reporting (#870).**
+
+`verified` in the command's output now reflects what actually happened:
+a render timeout during verification saves the session with
+`verified: false` and exit code 0 (previously the whole command failed;
+the #692 invariant — never CLAIM a verified session without a rendered
+page — is now carried by the explicit `false`, which JSON consumers
+should check). A live check that lands on Yandex's login page judges the
+auth cookies' (`Session_id`/`sessionid2`) `expires_utc` before claiming
+they expired — long-lived tracking cookies no longer mask a dead session
+— and a headless run gets one headful retry for the bot challenge. A
+stale Chromium ProcessSingleton lock (a previous CLI browser process
+that died with its `hostname-PID` symlink still on disk) is cleared and
+the launch retried once instead of failing with a raw
+`SingletonLock: File exists` traceback; `masters login` gained
+`--allow-no-tty` for scripted runs whose window is visible anyway.
 
 ### Added
 
+**`bidmodifiers` — live-only type `RETARGETING_SEARCH_ADJUSTMENT` (#871).**
+
+Adds the search-retargeting bid modifier type the live API accepts but the
+published WSDL and docs do not declare (confirmed by direct probes,
+2026-10-07): the add payload nests under
+`RetargetingSearchAdjustments` (a list, like `RetargetingAdjustments`),
+requires `--retargeting-condition-id` together with `--value`, and `get`
+selects it via `--types` alone — the type has no per-type
+`RetargetingSearchAdjustmentFieldNames` parameter (the live API rejects it).
+
+**Known limitation (#890):** Yandex currently rejects creating this
+modifier server-side (5005 on every documented retargeting-list class,
+while older types create fine on the same campaign) — the type appears to
+be a half-enabled pilot. The CLI mirrors the confirmed signature so
+`bidmodifiers add --type RETARGETING_SEARCH_ADJUSTMENT` works the moment
+the API enables acceptance; `--dry-run` shows the exact payload.
+
+**`masters list` — strategy and weekly budget per campaign.**
+
+Every GridCampaigns row already carries the grid's «Бюджет и стратегия»
+column (live capture 2026-10-03), so `masters list` now surfaces it with no
+extra page request: `Strategy` (the grid's raw enum — `OPTIMIZE_CLICKS` /
+`OPTIMIZE_CONVERSIONS` — passed through verbatim rather than remapped),
+`WeeklyBudget` (`strategy.budget.sum` when its `period` is `WEEK`), and the
+strategy scalars `AvgCpa` / `GoalId` / `PayForConversion` / `IsAutoBudget`,
+plus `EndDate` alongside the existing `StartDate`. Rows without a strategy
+object (e.g. drafts) report all of these as `null`.
+
+**`masters status` — inspect the active browser session with no network call (#862).**
+
+Reports which of `_open_session`'s tiers `masters` commands would currently
+use — the CLI's own persistent profile from `masters login` (tier 1.5), a
+saved `direct playwright login` session (tier 2), or neither (tier 3,
+fresh Chrome-cookie decrypt on every call) — plus the persistent profile's
+path/usability and the saved session's existence/expiry (reusing
+`direct_cli.browser.store.session_status`, the same read `direct playwright
+doctor` already does). Never launches a browser or touches Yandex; unlike
+every other `masters` subcommand, `status` is pure on-disk inspection.
+Defaults to `text` output like other local reference/diagnostic commands
+(`direct playwright doctor`, `trackingparams`). An explicit `--profile-dir`
+on the `status` call itself reports tier 1 ("explicit --profile-dir"),
+matching `_open_session`'s real precedence: a real `masters` read command
+given the same flag always decrypts fresh from that profile, bypassing
+tier 1.5/2 entirely — `status` models that override instead of reporting a
+tier the real command would not actually use (cycle-review of #864).
+
+**`masters update --add-video-url` — select an already-uploaded video (#812).**
+
+Adds a video to a campaign's "Варианты видео" section by selecting one the
+account has already uploaded to some other campaign, instead of uploading a
+new local file. Yandex keeps a single account-wide video library shared
+across all campaigns, exposed on the video manager modal's "Ваши кампании"
+tab.
+
+Live-verified 2026-08-26 (campaign 713234191, throwaway, read-only up to
+Cancel — no Save was clicked): selecting a card there
+(`VideoSuggestionsEditor.CreativeSourcePanel.USER` →
+`SuggestedCreativesContainer.SuggestedCreative.Select.<url>`) immediately
+moves it into the modal's `SelectedCreativesGrid` — no async upload-processing
+wait needed, since the video already exists server-side. The 2-video cap is
+enforced client-side: selecting a 3rd disables `VideoSuggestionsEditor.Save`
+and changes its label to "Выбрано больше 2 видео", the same Save button the
+upload flow uses. Mutually exclusive with `--add-video` (and `AddVideoUrl`
+with `AddVideo` in `--from-file`/`--masters-json` batch rows).
+
+`--add-video`'s own file-upload sequence remains **NOT LIVE-VERIFIED**
+(issue #812's original ask) — only the surrounding modal's DOM was confirmed
+live in #811; a real `set_input_files` upload was never attempted on this
+account.
+
+Requesting a URL already present in the campaign's video set is a safe
+no-op — the library tab's Select control is a TOGGLE, not an idempotent
+"ensure selected" button, so a blind click on an already-selected card
+would have deselected it and Save would have persisted that as a removal.
+`--add-video-url` now checks the current set first and returns without
+opening the modal when the video is already there, and correctly reports
+no change was made (no `AddedVideoUrl` in the JSON output, no false "did
+not save as requested" from the post-save verification pass).
+
+**`direct dictionaries get-retargeting-goals` — domain/app → `ExternalId` (#852).**
+
+Direct Commander can resolve a site address or app name into the
+`ExternalId` used by `RetargetingList(Type=AUDIENCE) -> Rules[].Arguments[].ExternalId`,
+but `direct-cli` had no equivalent. It calls `getRetargetingGoals`, an
+**undocumented/internal v5 method** not declared in the `dictionaries` WSDL
+(confirmed live: it is absent from the cached WSDL, no `X-Direct-Commander`
+header is required or wanted, and Yandex gives no stability guarantees for
+it). `--name` and `--ids` are mutually exclusive and one is required:
+
+```
+direct dictionaries get-retargeting-goals --name exist.ru
+direct dictionaries get-retargeting-goals --ids 19000000660,19000001592
+```
+
+A `--name` search can return more than one goal `Type` for similar names
+(e.g. `HOST` and `APPLICATION`) — pick the entry with the `Type` your use
+case needs. Unblocks `axisrow/yandex-direct-mcp-plugin#168`.
+
+**`direct history get` — read «История изменений» (#837).**
+
+The API has no per-field change journal at all: `changes.checkCampaigns`
+reports only `ChangesIn: SELF|CHILDREN|STAT`, `changes.check` returns bare
+lists of changed IDs, and Live v4's `GetEventsLog` logs system events
+(`BannerModerated`, `MoneyOut`, …). None of them answer "who changed this
+field, when, and from what to what" — the question that arises after a bulk
+edit silently drops a strategy goal or a Metrika counter.
+
+That history exists only in the web interface, so this is a new browser-backed
+group alongside `masters`, sharing its session stack (`--headful`/
+`--profile-dir`/`--chrome-profile`, no `--login`):
+
+```
+direct history get --campaign-ids 77593206 --categories CAMPAIGN_STRATEGY
+direct history get --date-from 2026-07-01 --date-to 2026-08-13 --limit 50
+```
+
+A separate group rather than a `masters` subcommand because the section is
+account-wide: its records cover ordinary ТГО/ЕПК campaigns, ad groups and ads
+as much as Мастера, and `--campaign-ids` is only a filter over that.
+
+Like `masters list` (#639), it does not scrape the DOM — it replays the
+section's own data call, `POST /web-api/user-action-log/api`. Live recon
+established two things that differ from the campaigns grid: `variables.login`
+is required (dropping it returns HTTP 200 with `errors: ["Нет прав"]`, not an
+auth failure), while the URL-level `ulogin` parameter is *not* needed — the
+opposite of `GridCampaigns`, where one's own login as `ulogin` causes HTTP
+401. Filters are applied server-side; results paginate automatically.
+
+Each record carries `Datetime`, `Login`, `ChangeSource`, `Category`,
+`EventType` and `CampaignId`/`CampaignName`, with the event's own fields under
+`Event`, passed through as-is because it is a union with a different shape per
+`EventType`. A dropped strategy goal reads directly off
+`Event.oldStrategy.goalId` → `Event.newStrategy.goalId`.
+
+Pagination de-duplicates on `gtid`: the cursor is a timestamp with one-second
+granularity, so consecutive pages overlap on records sharing a second. Live
+measurement over 2026-07-01..08-13 returned 6877 rows for 3257 distinct
+records — an inflation invisible in a two-page check, since the first overlap
+landed on page 3.
+
+**`masters update --from-file` / `--masters-json` — update many campaigns in
+one browser session (#834).**
+
+`masters update` took exactly one campaign id, so editing 10–20 Мастеров
+кампаний meant 10–20 separate CLI processes, each launching its own Chromium
+and re-entering Yandex. A live run of 17 campaigns (#829) showed that it is
+the repeated re-entry — not the editing — that fails.
+
+Batch mode follows the existing API-command convention (`keywords add`,
+#562): a JSONL plan via `--from-file`, or the same array inline via
+`--masters-json`, mutually exclusive with each other and with a positional
+`CAMPAIGN_ID`, and supported only with `--format json`.
+
+```
+direct masters update --from-file plan.jsonl --moderation-statuses
+```
+
+```jsonl
+{"CampaignId": 713234064, "Headlines": {"1": "Новый заголовок"}}
+{"CampaignId": 713231614, "LandingUrl": "https://lp.example.ru/x"}
+```
+
+Each row is one campaign: PascalCase keys that mirror this command's own
+flags 1:1, with slot numbers and positions **1-based exactly as in
+`--headline "2=..."`**. Rows are fully typed-checked before the first save
+(the same bounds, enum values and duplicate rules Click enforces for the
+flags), so a typo in the last row cannot leave earlier campaigns already
+mutated. An unknown key is an error naming the row and the allowed set,
+never a silent skip.
+
+Execution notes:
+
+- the whole plan runs over **one** browser session, paced between campaigns
+  (`--pacing-ms`, default 1000);
+- a campaign that fails is reported with an `Error` and does not stop the
+  rest; the command exits non-zero afterwards (#816/#831 semantics);
+- if the session goes stale mid-plan it is re-opened once and the run
+  resumes from the first campaign that was never saved — **an
+  already-saved campaign is never saved twice**;
+- `--moderation-statuses` reads each campaign's current statuses after its
+  save. Moderation usually has not run yet at that point, so this is a
+  snapshot, not a final verdict;
+- `--dry-run` validates the plan (including that local image/video files
+  exist) and prints what would be applied without opening a browser. It now
+  works for a single `CAMPAIGN_ID` too, printing the same report shape.
+
+**`masters get --tracking-params` — read a campaign's UTM string (#824).**
+
+`masters get` never returned `TrackingParams`, either set or empty: the
+overview page it reads has no such field at all — "UTM-метки и параметры
+URL" only exists on the edit page, behind the "Дополнительные параметры"
+spoiler. This left `masters update --tracking-params`'s own result as the
+only evidence a save had taken effect, with no independent way to audit a
+batch of campaigns afterwards.
+
+A flag on the existing `get`, not a new subcommand — same shape as
+`--moderation-statuses` (#814): one more edit-page navigation, merged into
+the same result rather than paying for it on every `get`.
+
+```
+direct masters get 74736436 --tracking-params
+```
+
+adds `TrackingParams` to the result:
+
+- a UTM string is set → the string itself;
+- the field is mounted and genuinely empty → `""`;
+- the section could not be confirmed readable within the wait budget →
+  `TrackingParams` is omitted, rather than reporting a misleading `""`
+  (mirrors how the DRAFT overview path already omits an unreadable
+  `LandingUrl`).
+
+Reuses `_read_tracking_params`/`_wait_for_utm_section`, the same reader
+`masters update`'s own verify path already relies on (#769/#774), so `get`
+and `update --tracking-params` agree on what "empty" vs "unreadable" means
+for this field. Without the flag, `get`'s output and page loads are
+unchanged.
+
 **`masters get --moderation-statuses` — detect per-element moderation
 rejections in Мастер кампаний (#814).**
 
@@ -107,10 +377,277 @@ All real-page interactions in this recon pass were abandoned via the
 modal's Cancel button (never Save) — the campaign's saved image set is
 confirmed unchanged before and after.
 
+**`masters counters get` — read a Мастер's linked Metrika counters (#842).**
+
+Sibling of `masters targetactions get`/`masters audience get`, and the missing
+half of the target-action story: a goal can only be added from a *linked*
+counter's goals, so "`--add-target-action` can't find the goal" and "no counter
+is linked at all" used to look identical from the CLI.
+
+```
+direct masters counters get 713234204
+```
+
+Each entry carries the raw tag `Text` plus the `CounterId`/`Domain` parsed from
+it. `SectionPresent` disambiguates the empty case: `false` means the "Счетчики
+Яндекс Метрики" block is not on the page at all (see #843 below), `true` with
+`Count: 0` is the genuinely counter-less campaign.
+
+Two read hazards found live and guarded against, both of which make a
+single-sample read confidently wrong rather than merely early:
+
+* The block is briefly present in the initial render and is **unmounted** once
+  the form settles on a `max-clicks` campaign (measured on 74736436: `block=1`
+  at t+0, `block=0` from t+3s) — the mirror image of this module's usual
+  hydration races, where absence is the transient state.
+* A linked tag's own text hydrates in two stages — `"72112213"` at t+0, then
+  `"gc.ksamata.ru • 72112213\n30 целей"` from t+4s. The early value has no
+  separator, so it parses to `CounterId: null` even though the id is right
+  there.
+
+Both are handled by polling for a *stable* reading, mirroring
+`_wait_for_target_actions_settled`.
+
 ### Fixed
 
-**`masters` — `_metrika_counter_identity` now normalizes surrounding
-whitespace around a non-empty counter id (#809).**
+**`masters login` — no more visible blinking probe tab next to the login
+form (#858).**
+
+`login_persistent_session` (`direct_cli/browser/session.py`) detected a
+completed manual login by keeping a second, visible tab open in the same
+browser window and re-navigating it to the campaigns grid once a second
+(`probe.goto(GRID_URL)` + HTML marker scans in a loop) until the session
+appeared or the timeout hit. Next to the form the user was typing into, that
+tab blinked/reloaded every second with no explanation — the motivation (never
+navigate the page the human is typing into, so a half-filled form or a pending
+2FA prompt is never wiped) was right, but the mechanism was both noisy UX and
+a heavyweight way to ask "is there a session cookie yet".
+
+The wait now polls the shared cookie jar instead: `context.cookies()` is read
+every second for Yandex's SSO session cookies (`Session_id`/`sessionid2` —
+the same jar `_chrome_crypto` copies out of Chrome to authenticate a fresh
+context, so their presence *is* the Direct session). No navigation and no
+second tab happen while the user is still typing. Only when a session-cookie
+signature appears (or changes after a rejected attempt — a stale
+`Session_id` left in a reused profile does not re-trigger the probe every
+second) is a short-lived probe tab opened for a single verification
+navigation, running the same fail-closed checks as before (`commit`
+navigation per #686, marker poll per #692, captcha and login-page content
+scans) on the full marker budget rather than a 1s slice, then closed. The
+page the human is typing into is never navigated, exactly as before.
+
+Verification outcomes are now a tri-state: authenticated (login recorded,
+command exits), login-page-served (conclusive "jar does not add up to a valid
+session" — wait for different cookies), or inconclusive (unrendered page,
+retried next tick). The one-shot verification's navigation reuses #865's
+`_goto_with_network_retry` unchanged: a transient network-layer abort
+(issue #857's `net::ERR_ABORTED` on a flaky VPN) is retried in place, and a
+connection that stays dead fails as `BrowserNetworkError` — never mistaken
+for an auth problem. A browser/context that dies mid-wait (crash, or the
+user closing the window to abort the login) fails fast with a clean "run
+`direct masters login` again" error instead of a raw PlaywrightError
+traceback — every call such a death can break is CDP-only, so retrying it
+until the timeout could never succeed (review of #858). The session-cookie
+signature also rejects look-alike domains (`notyandex.ru`) that a bare
+`endswith("yandex.ru")` would have accepted.
+
+**`masters` status parsing — read the header status element, not the whole
+page body (#848).**
+
+`masters archive`/`suspend` refused to act on campaign 107705868 with
+`Could not determine current status … (unrecognised status text) — refusing to
+click blind`, while the same error's own diagnostic reported the page's
+`CampaignHeader.ActionButton.stop` ("Остановить кампанию") as present and
+enabled — i.e. the campaign was plainly ACTIVE. The refusal itself is correct
+behaviour (never click blind), but it left the campaign unreachable by every
+lifecycle command.
+
+`_read_status_text` matched four fixed Russian phrases as substrings of
+`inner_text("body")` — the entire page. Live recon 2026-08-14 established that
+`CampaignHeader.Status` carries the status verbatim in *every* state, not just
+DRAFT as this module's older comments assumed: confirmed on real campaigns as
+"Кампания активна" (713234142), "Кампания остановлена" (107705868) and
+"Кампания в\xa0архиве" (100571135). The parser now reads that element first and
+falls back to body text only when it is absent or unrecognised.
+
+Matching the header node also removes the substring-over-everything failure
+mode: the dashboard renders free-form moderation prose that mentions the
+campaign (confirmed live on 713234142: "…Кампания запущена из\xa0прошедших
+модерацию элементов объявления"), so which status won depended on which
+unrelated banners happened to be rendered. Marker comparison is additionally
+normalised over case, U+00A0 and collapsed whitespace, so a marker can no
+longer silently never match over an invisible character — a pitfall that had
+already cost a full debugging pass twice (#704, #730).
+
+Unrecognised text still returns `None`, so the refuse-to-click-blind guard is
+unchanged.
+
+**`masters update --add-metrika-counter` — read the suggestion popup at all,
+and accept a bare counter id (#846).**
+
+The counter autocomplete could never match anything, for any input. The option
+search was scoped to `[data-testid="MetrikaCountersTagGroup.editor.listBox"]`,
+but no element carries that testid: live recon (campaign 74099856) found the
+suggestions are portalled into a `dc-Popup` under `<body>` — outside the editor
+subtree entirely — and the `…editor.listBox` string appears only as the *prefix*
+of each option's own testid, `…editor.listBox.{counter id}`. The locator
+resolved to zero elements, `get_by_role("option")` under it always counted 0,
+and every add timed out.
+
+The timeout was reported as "No suggestion exactly matching {text} appeared",
+which blamed the caller's text for a selector bug — the operator in #846 spent
+three attempts (bare id, domain, full `label • domain • id` line) trying to
+respell a value that was never being compared against anything.
+
+Options are now located directly by that testid prefix, and because the testid
+carries the counter id, `--add-metrika-counter` accepts the **bare numeric id**:
+
+```
+direct masters update <id> --promotion-goal max-conversions \
+  --add-metrika-counter 72112213
+```
+
+The id is matched against the option's own id, never as a substring of the
+display text, so a short id cannot silently select a counter whose label or
+domain merely contains those digits. The full suggestion line still works. This
+closes the round trip with `masters counters get`, whose `CounterId` can now be
+passed straight back in — its tag text (`gc.ksamata.ru • 72112213`) has a
+different shape from the suggestion (`Ксамата Директ • gc.ksamata.ru •
+72112213`) and never could be.
+
+Both failure messages now diagnose rather than accuse: a non-match lists what
+Yandex actually offered, and an empty list points at account access to the
+counter, since the search runs server-side on partial input (typing `7211`
+surfaces the full suggestion).
+
+Live-verified end to end on campaign 74099856: the counter links, its tag
+renders, and the "Счетчик отсутствует" warning under «Целевые действия» clears.
+That recon was deliberately not saved.
+
+**`masters counters get` — stop reporting an unstable `SectionPresent` (#846).**
+
+The same campaign could report `SectionPresent: true` in one run and `false` in
+the next with no update in between. `_metrika_counters_section_present` already
+polled for a *stable* answer rather than trusting one sample — the block is
+briefly rendered at t+0 on a max-clicks campaign and unmounted once the form
+settles (~t+3000ms live) — but its stability window was calibrated shorter than
+the transient it guards against.
+
+At 500ms × 3 ticks the loop settles after 3 samples spanning 2 gaps, ~1.0s: it
+certified "stably present" a full 2 seconds *before* the unmount. Whether a run
+saw `true` or `false` came down to how the poll ticks happened to line up
+against the flip.
+
+The window is now 500ms × 8 (~3.5s of agreement) against its own 8s budget,
+rather than borrowing the autocomplete's 5s. The budget must exceed *flip +
+window*, not just the window, because the run of agreement only starts after
+the flip — at 5s the max-clicks case never settled at all and reached the right
+answer only through the "report the last read" fallback, which is not a
+property worth depending on. Both outcomes now settle deliberately:
+max-conversions at ~3.5s, max-clicks at ~6.5s.
+
+The presence locator is also re-resolved per sample instead of once before the
+loop. Playwright locators are lazy and re-query on each `count()`, so this was
+not itself the live bug, but a loop whose entire purpose is watching the DOM
+change should not depend on that implicitly.
+
+Regression tests model the live timeline against the fake clock and fail on the
+old constants.
+
+**`masters update` — apply Metrika counters BEFORE target actions (#844).**
+
+`update_master` linked counters ~200 lines *after* it added target actions, so
+`--add-metrika-counter` together with `--add-target-action` in one call was
+impossible by construction: the "Добавить" popup only lists goals belonging to
+an already-linked counter, so the goal was looked up against the counter set as
+it stood before the counter was attached, and the call failed with "Could not
+find goal N in the 'Добавить' target-action popup".
+
+This is an ordering bug, not a hydration race — waiting longer at the old
+position never helped, because the counter simply was not linked yet.
+Live-confirmed on campaign 74736436: the same call that used to fail now links
+the counter and adds the goal, and the restore path
+
+```
+direct masters update <id> --promotion-goal max-conversions \
+  --add-metrika-counter "…" --add-target-action "<goal_id>=150"
+```
+
+completes end to end — which matters because none of its three parts can be
+applied on their own (`max-conversions` will not save without a goal, and a goal
+cannot be added without a counter).
+
+**`masters update --add-metrika-counter` — name the promotion-goal
+precondition instead of blaming markup drift (#843).**
+
+The command failed with "Could not click the 'Счетчики Яндекс Метрики' launcher
+button — Yandex may have changed the page's markup", sending the operator
+hunting for a drifted testid that had not drifted. Live recon confirmed the
+selector is correct and the section simply does not exist yet: on campaign
+74736436 (goal `max-clicks`) both the launcher and the whole
+`MetrikaCountersBlock` settle to absent, and both mount once the goal is
+switched to `max-conversions`. The error now says so and names the fix — pass
+`--promotion-goal max-conversions` in the same call, since it is applied before
+counters.
+
+**`masters update --promotion-goal` — retry a swallowed dropdown click, and
+report Yandex's own rejection text (#840).**
+
+`--promotion-goal max-conversions` failed with "Could not find the 'Максимум
+целевых действий' option in the 'Цель продвижения' dropdown — Yandex may have
+changed the page's markup" on campaigns whose markup had not changed at all.
+Live recon (campaign 74736436) confirmed the heading, the trigger XPath and
+the `CampaignTargetSelect.TargetSelect.ListBox.INVOLVED_CONVERSION` testid all
+still match; instrumenting a failing run found the real cause — the same
+menu-trigger hydration race as #723/#725. The trigger already matched
+(`count=1`) while un-hydrated (`aria-expanded=None`, empty `inner_text()`), so
+Playwright's actionability check passed, the click landed on a node with no
+React handler attached, and nothing opened. Because the option rows exist in
+the DOM only while the dropdown is open, the follow-up `option.click()` then
+misreported a hydration race as a markup change. `_set_promotion_goal` now
+opens the dropdown through `_click_and_wait_for_popup` (retrying the open),
+like the other menu/modal triggers in this module.
+
+Saves refused by Yandex's client-side validation are also no longer reported
+with a generic "Yandex may have rejected the value". `update_master` now reads
+the inline error text before `_verify_saved`'s reload discards it and quotes it
+back — closing the follow-up the module docstring's "Save verification"
+paragraph had left open. On a campaign with no Metrika goals, switching to
+`max-conversions` is refused outright (the save request is never sent), and the
+error now names why: "Добавьте хотя бы одну цель для сайта, чтобы создать и
+запустить кампанию." Note that the "Счетчики Яндекс Метрики" section itself
+only renders once the promotion goal is `max-conversions`, so a campaign that
+lost both needs the counter, the goal and the promotion goal set in one call.
+
+**`masters launch`/`masters update --launch` — diagnose an empty "Целевые
+действия" table instead of a generic redirect timeout (#823).**
+
+Yandex silently refuses to save/launch a DRAFT campaign with no Яндекс
+Метрика conversion goal ("Добавьте хотя бы одну цель для сайта, чтобы
+создать и запустить кампанию") — same failure mode `create_master` already
+diagnoses (#777), but the edit page's launch/save-as-draft click
+(`_click_draft_terminal_button`, shared by `launch_master` and
+`update_master --launch`) previously only reported the generic "Yandex did
+not redirect away from the edit page" message on timeout, with no clue as
+to why. Neither terminal button ever gains a disabled/`aria-disabled`
+marker in this state, so a caller had to rediscover the root cause by hand
+each time (live-reported in #823: a cloned Мастер кампаний whose landing
+URL was then changed via `masters update --landing-url` lost its inherited
+goals, and `masters launch` failed identically on three consecutive
+attempts, including `--headful`).
+
+On timeout, `_click_draft_terminal_button` now re-reads the "Целевые
+действия" table (reusing `_wait_for_target_actions_settled`/
+`_read_target_actions_or_none`, the same reader `create_master`'s pre-click
+gate uses — confirmed to be the identical widget on both pages) and raises
+a specific error naming the empty goals table when that's the cause,
+falling back to the original generic message otherwise. This diagnosis
+itself polls for up to another ~25s after the original redirect deadline
+already elapsed, so a merely-slow (not stuck) Yandex redirect can land
+*during* the diagnosis; `page.url` is re-checked immediately before each
+`raise` so a redirect landing mid-diagnosis is treated as success rather
+than reported as a false failure on an already-successful, no-rollback
+launch/save (cycle-review PR #826, Codex).
 
 The suggestion-text format (`"{label} • {domain/path} • {numeric counter
 id}"`) and the read-back tag-display format (`"{domain} • {numeric
@@ -331,6 +868,40 @@ Code review on #782/PR #784 found two edge cases in `delete_master`
 
 ### BREAKING CHANGES
 
+**`masters` batch commands stream JSONL instead of a pretty JSON array (#866).**
+
+`masters get|suspend|resume|launch|archive` with several campaign IDs used to
+buffer every per-ID outcome in memory and print a single pretty JSON array
+after the whole loop. A process killed mid-batch (a wrapper's subprocess
+timeout — the Yandex Direct MCP plugin runs these with a 180 s default — or
+OOM/crash) took every already-applied mutation's report with it: a caller of
+irreversible `launch`/`archive` had no way to learn which campaigns had
+already changed, and a blind retry re-applied live mutations. Transport-level
+sibling of #766/#816, which fixed the in-process cases.
+
+- With `--format json` (the default), each ID's outcome — the resulting row,
+  or its `{"CampaignId": ..., "Error": ...}` entry — is printed the moment it
+  is known, as one compact JSON object per line (JSONL), with an explicit
+  `flush()` after every record. stdout in a non-tty subprocess is
+  block-buffered, so without the per-record flush nothing would survive a
+  kill; on POSIX `subprocess.run` attaches the flushed partial stdout to
+  `TimeoutExpired`, so wrappers (and the plugin's
+  `CliTimeoutError.partial_stdout`) can now reconcile a partial batch without
+  any plugin-side change.
+- **Migration:** parse stdout line-by-line instead of as one JSON document
+  (`for line in stdout.splitlines(): json.loads(line)`). Single-ID output
+  remains a single JSON object (one line, still `json.loads`-able whole); a
+  zero-ID batch prints `[]`. An empty batch keeps `json.loads`-compatibility
+  for that case only.
+- `_with_session`'s stale-session self-heal re-runs the whole operation, so
+  IDs completed before the auth failure appear once per real attempt — every
+  line is a genuine outcome, and the trailing lines are the final attempt's.
+- `--output` gets the same per-record durability: the file is opened once and
+  each record is written+flushed into it as its ID completes (previously a
+  single pretty array written at the end).
+- Non-JSON formats (`text`/`table`/`csv`/`tsv`) are unchanged — consolidated
+  end-of-run output; they are human-readable reports, not machine streams.
+
 **`masters add` now requires `--add-target-action` (#777).**
 
 `masters add` previously could not create a campaign at all. Yandex's create