gflow-cli 0.73.0__tar.gz → 0.73.2__tar.gz

{gflow_cli-0.73.0 → gflow_cli-0.73.2}/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "gflow",
-  "version": "0.73.0",
+  "version": "0.73.2",
   "description": "Reusable development and operations workflows for gflow-cli",
   "author": {
     "name": "Flavio Oliva",

{gflow_cli-0.73.0 → gflow_cli-0.73.2}/CHANGELOG.md

@@ -7,6 +7,80 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.73.2] — 2026-09-12
+
+### Fixed
+
+- **A missing browser-strategy marker no longer reports as a network problem (#796).**
+  The Playwright cookie reader refuses a profile whose `.gflow_browser_strategy` marker
+  is absent, and that `SecurityError` was flattened into `VERIFICATION_ERROR` — whose
+  guidance is "check network connectivity", for a file on the user's own disk. It is
+  also precisely the state a failed first login leaves behind, since that rolls the
+  marker back. A new `PROFILE_MARKER_MISSING` outcome carries its own message and the
+  remediation that actually works (`gflow auth login --browser chrome`), on the CLI and
+  on the MCP twin (HTTP 409, `retryable: false` — it is neither a network blip nor an
+  expired session).
+- **`gflow credits` no longer blames SAPISID for a host it never contacted (#795).** When
+  labs.google answers 200 with no `access_token` — the normal shape for an account Google
+  has migrated to `flow.google.com` — the failure was raised as "aisandbox-pa
+  authentication failed" with the remediation "SAPISID cookie missing, expired, or
+  unreadable". aisandbox-pa had not been contacted, and SAPISID was present and fine, so
+  the advice sent users into a re-login loop that cannot terminate on that cohort. The
+  remediation now names the real cause. `credits` itself remains labs-only on migrated
+  accounts — tracked in #795.
+- **Incident bundles from a `flow.google.com` failure are no longer blank (#792).** The
+  migrated composer parked its pooled page on `about:blank` in a bare `finally`, so on
+  the FAILURE path it navigated away *before* `FlowApiClient._capture_incident` read the
+  page — whose own contract is to stage the bundle "while the page is still alive".
+  Every migrated video and image failure therefore shipped `tag_counts.div = 0`, a white
+  screenshot and `host_category = "other"` beside a network journal that proved the app
+  was alive, which reads exactly like a lost browser tab and is unusable as evidence.
+  The park is deferred past the capture and drained at the **top of the next run**, before
+  the route decision reads `page.url` — which is where the invariant it protects (a stale
+  project URL must not route the next request) is actually consumed, and the only place
+  that also covers the `post_with_retry` path, where a retryable 5xx re-enters the
+  transport without passing the client's failure boundary at all. Cancellation still
+  attempts the park inline and latches, since no bundle is staged for it.
+  Note a failure bundle's `sensitive/screenshot.png` is now a real capture of the
+  logged-in page rather than a blank frame — the review-before-sharing posture in
+  SECURITY.md applies to it as it already did to every other screenshot.
+
+- **The `/about` landing's `retryable=False` is now a measurement, not a preserved
+  default.** A live occurrence was caught on a second account and the #756 stability
+  probe re-run unmodified: **5/5** attempts landed on `/about` over ~3 minutes, on the
+  account's own project, with a healthy session — so a retry is doomed and costs ~35 s
+  each. Four places that said the measurement *could not* be made are corrected — two
+  code comments, the exit-31 row in [USAGE](docs/USAGE.md) and the `retryable` note in
+  [MCP](docs/MCP.md); behaviour is unchanged. Still unmeasured: the cause, and whether
+  it ever clears.
+- **An auth-status test no longer depends on how wide the terminal is.** Several steps
+  assert a substring of Rich's output, which hard-wraps — so a temp path landing near
+  the wrap column split `experiments` into `profile_e` + `xperiments` and failed on
+  formatting rather than behaviour. Pinned at the shared `CliRunner` fixture, which is
+  the one chokepoint for every invoke in that file.
+
+## [0.73.1] — 2026-09-11
+
+### Fixed
+
+- **Google's cookie-consent bar no longer blocks generation on `flow.google.com`.**
+  The `glue` bar is fixed at `z-index: 1000` and Flow's composer is bottom-anchored in
+  the same band, so the bar sat on the settings trigger *and* on the image submit:
+  `elementFromPoint` over each returned the bar in 5/5 rendered samples, on the same
+  profile and project where the click had landed 3/3 the day before. Every image and
+  video run on a re-prompted profile failed, before any submit, so nothing was billed.
+  The driver now clears the bar before its first click. It **rejects** rather than
+  accepts — both remove the bar, and only one answers a consent question on your
+  behalf. Reported by @stgmt in [#780](https://github.com/ffroliva/gflow-cli/issues/780);
+  measured in [the 2026-09-11 spike](docs/superpowers/spikes/2026-09-11-migrated-cookie-bar-blocks-the-composer.md).
+- **A click post-mortem now names the thing on top, not its inner node.** The occluder
+  allowlist matched `cdk|mat|mdc|flow` class prefixes on the element `elementFromPoint`
+  returned — but a consent bar puts an unnamed label span there and keeps its identity
+  in an `id` the allowlist deliberately drops, so #776's attribution reported
+  `it is covered by span`. It now adds Google's `glue` prefix and climbs to the nearest
+  ancestor that names itself, reporting `div.glue-cookie-notification-bar`. Unchanged
+  for the CDK overlays that already worked, and the `id` is still never echoed.
+
 ## [0.73.0] — 2026-09-10
 
 ### Security
@@ -4845,7 +4919,9 @@ shell-script template that branches on these codes.
 
 First skeleton. Not functional end-to-end yet.
 
-[Unreleased]: https://github.com/ffroliva/gflow-cli/compare/v0.73.0...HEAD
+[Unreleased]: https://github.com/ffroliva/gflow-cli/compare/v0.73.2...HEAD
+[0.73.2]: https://github.com/ffroliva/gflow-cli/compare/v0.73.1...v0.73.2
+[0.73.1]: https://github.com/ffroliva/gflow-cli/compare/v0.73.0...v0.73.1
 [0.73.0]: https://github.com/ffroliva/gflow-cli/compare/v0.72.0...v0.73.0
 [0.72.0]: https://github.com/ffroliva/gflow-cli/compare/v0.71.1...v0.72.0
 [0.71.1]: https://github.com/ffroliva/gflow-cli/compare/v0.71.0...v0.71.1

{gflow_cli-0.73.0 → gflow_cli-0.73.2}/KNOWN_ISSUES.md

@@ -98,7 +98,7 @@ is a per-account setting the labs.google app applies on every load (measured
 once the account is flagged, re-running will not land the old frontend. Earlier text here said the rollout
 "flaps" and told you to retry; that observation straddled the account's one-time
 switch and is withdrawn. The REST surface (`gflow project list`, `gflow data …`)
-is unaffected. Automated callers now receive `retryable: false` so retry loops
+is unaffected; `gflow credits` is **not** — its token comes from `labs.google`, which mints none for a moved account ([#795](https://github.com/ffroliva/gflow-cli/issues/795), open; see the quota entry below). Automated callers now receive `retryable: false` so retry loops
 stop instead of burning a doomed attempt each time.
 
 **What gflow does today for the rest of the matrix:** recognises the migrated
@@ -210,6 +210,44 @@ on the first try.
 with `uv tool run --from gflow-cli python -c "import importlib.metadata as m; print(m.version('playwright'))"`.
 Installs from PyPI are unaffected.
 
+### Google's cookie-consent bar covers the composer on the migrated host — fixed in 0.73.1
+
+- **Status:** Fixed in 0.73.1 ([#780](https://github.com/ffroliva/gflow-cli/issues/780)) · **Affects:** `flow.google.com`, all versions through 0.73.0
+- **Severity:** High while it fires (every image and video run on that profile fails) · **Cost:** none — it fails before any submit, so no credits are spent
+
+Google's `glue` consent bar (`#glue-cookie-notification-bar-1`) is `position: fixed`
+at `z-index: 1000`, and Flow's composer is bottom-anchored in the same band. The bar
+therefore lands **on** the settings trigger *and* on the image submit button.
+Measured 2026-09-11 on the `ci-probe` profile: `elementFromPoint` over each returned
+the bar's label span in 5/5 rendered samples, on the same profile and project where
+the click had landed 3/3 the day before.
+
+**Who gets it:** anyone who has not yet dismissed it on that origin. The gate is a
+single key, `localStorage["glue.CookieNotificationBar"]` on `flow.google.com` — not a
+cookie, which is why no profile here carries `SOCS`. A clean browser profile reads the
+bar visible 4/4, and removing that key on a consented profile brings it straight back
+with both controls covered again. So it is the **default state**, and a stored
+dismissal is what removes it: every new gflow profile meets it on its first Flow load,
+and any profile whose stored dismissal Google resets meets it again — as `ci-probe` did
+within seventeen hours.
+
+The labs driver survives it by accident; `_bypass_onboarding` carries a text match on
+"Agree". The migrated driver had no equivalent.
+
+Through 0.73.0 the run fails at exit 23 with `it is covered by span` — the element on
+top is the bar's label, whose identity lives in an `id` the occluder allowlist drops,
+so the message named nothing actionable.
+
+0.73.1 dismisses the bar before the first click, choosing **reject** over accept
+(both clear it; only one answers a consent question for you), and teaches the
+post-mortem to climb to the nearest ancestor that names itself, so any bar that
+still refuses to go is reported as `div.glue-cookie-notification-bar`.
+
+**Workaround on 0.73.0 and earlier:** open that profile once in Chrome and dismiss
+the bar by hand. Consent persists in the profile.
+
+Evidence: [`docs/superpowers/spikes/2026-09-11-migrated-cookie-bar-blocks-the-composer.md`](docs/superpowers/spikes/2026-09-11-migrated-cookie-bar-blocks-the-composer.md).
+
 ### One-time Flow banner/modal can cover the composer on first load
 
 - **Status:** Open ([#369](https://github.com/ffroliva/gflow-cli/issues/369))
@@ -770,9 +808,9 @@ A block that survives dismissal now aborts pre-submit with exit 23 (probe `overl
 
 ---
 
-### No in-CLI quota visibility — resolved
+### No in-CLI quota visibility — resolved on labs, still open on the migrated host
 
-- **Status:** Resolved 2026-09-05
+- **Status:** Resolved 2026-09-05 for `labs.google` accounts · **Open** on accounts Google has migrated to `flow.google.com` · **Tracked:** [#795](https://github.com/ffroliva/gflow-cli/issues/795)
 
 Use `gflow credits user` for the selected profile or `gflow credits list` for all saved
 profiles. Both commands query Flow's current read-only credits endpoint with the saved browser
@@ -780,6 +818,17 @@ session; `--json` provides a stable automation contract. The equivalent MCP surf
 `gflow_get_credits`. The reported balance funds Veo video generation; image generation consumes
 separate per-model daily quotas.
 
+**On a migrated account there is still no in-CLI quota visibility.** The credits endpoint is
+reached with a token minted by `labs.google`, and for an account Google has moved to
+`flow.google.com` that session answers `200` with no `access_token` — it never mints one. So
+`gflow credits user` / `list` and `gflow_get_credits` fail on that cohort with "the labs.google
+session returned no access token". Through 0.73.1 this was reported as "aisandbox-pa
+authentication failed … SAPISID cookie missing, expired, or unreadable", which sent migrated
+users into a re-login loop that cannot terminate: aisandbox-pa had not been contacted and
+SAPISID was present and fine. 0.73.2 fixes the *message* only — the remediation now names the
+real cause. Reading a balance on the migrated host is **not** implemented
+([#795](https://github.com/ffroliva/gflow-cli/issues/795), open). Generation is unaffected.
+
 ---
 
 ### `gflow serve` / MCP worker queue: interrupted post-submit tasks need manual reconciliation

{gflow_cli-0.73.0 → gflow_cli-0.73.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: gflow-cli
-Version: 0.73.0
+Version: 0.73.2
 Summary: Unofficial CLI for Google Flow — drive Veo image-to-video generations from the terminal.
 Project-URL: Homepage, https://github.com/ffroliva/gflow-cli
 Project-URL: Issues, https://github.com/ffroliva/gflow-cli/issues

{gflow_cli-0.73.0/website → gflow_cli-0.73.2}/docs/ARCHITECTURE.md

@@ -113,14 +113,15 @@ When the project converges on the hexagonal target above, modules graduate to la
 > **Note: this document describes the TARGET architecture, not the current
 > package layout.** The current shape (per [PLAN.md § 2](../PLAN.md#2-architecture-steady-state)
 > and [ADR #2](../PLAN.md#5-decision-log-adrs-in-miniature)) is the simpler
-> `src/gflow_cli/{api/, auth/, data/, mcp/, services/, tools/, ui/, worker/}`
-> packages plus flat modules — the `cli*.py` adapters, `browser_manager.py`,
-> `chain*.py`, `composition.py`, `config.py`, `diagnostics.py`, `errors.py`,
-> `image_batch.py`, `json_output.py`, `media.py`, `movie_manifest.py`,
-> `observability.py`, `paths.py`, `profile_lease.py`, `profile_store.py`,
-> `storage.py`, `update_check.py` (the once-a-day notice and `gflow update`'s
-> `run_update`; its Click surface is `cli_update.py`), and `winsec.py` (inventory refreshed for
-> v0.56.0, #507 — it had drifted a dozen modules behind).
+> `src/gflow_cli/{api/, auth/, data/, flow_selectors/, mcp/, services/, tools/, ui/,
+> worker/}` packages plus flat modules — the `cli*.py` adapters, `_cli_helpers.py`,
+> `browser_manager.py`, `chain*.py`, `composition.py`, `config.py`, `diagnostics.py`,
+> `errors.py`, `exceptions.py`, `file_integrity.py`, `image_batch.py`, `json_output.py`,
+> `media.py`, `movie_manifest.py`, `observability.py`, `paths.py`, `profile_lease.py`,
+> `profile_store.py`, `redaction.py`, `storage.py`, `update_check.py` (the once-a-day
+> notice and `gflow update`'s `run_update`; its Click surface is `cli_update.py`), and
+> `winsec.py` (inventory refreshed for v0.73.2 — it had drifted again since the v0.56.0
+> refresh in #507; `AGENTS.md` carries the same list and is the one to diff against).
 > The DDD layout below was deferred indefinitely; converge toward it incrementally
 > if/when a second `Provider` justifies the split (`gflow serve` shipped as a
 > thin adapter over the same core rather than forcing it).

{gflow_cli-0.73.0 → gflow_cli-0.73.2}/docs/AUTHENTICATION.md

@@ -242,7 +242,7 @@ Probing Flow session (may take up to ~45s on a slow network)...
 Flow session verified as you@example.com.
 ```
 
-> Note: `cookies_present: True` only confirms the file exists. The final verdict line is the live probe result: a dead session prints a `gflow auth login` remediation hint and exits 1; a probe that cannot reach the endpoint (offline, 5xx) also exits 1 but suggests checking connectivity instead of re-logging in.
+> Note: `cookies_present: True` only confirms the file exists. The final verdict line is the live probe result, and it has three failing shapes — all exit 1, each with a different hint. A **dead session** prints a `gflow auth login` remediation hint. A probe that **cannot reach the endpoint** (offline, 5xx) suggests checking connectivity instead of re-logging in. And a profile **missing its `.gflow_browser_strategy` marker** — the state a failed *first* login leaves behind, since that rolls the marker back — says so and points at `gflow auth login --browser chrome --profile <name>`; it is local profile state, not a network fault, and "check connectivity" would send you to the wrong place ([#796](https://github.com/ffroliva/gflow-cli/issues/796), 0.73.2). The MCP twin `gflow_auth_status` reports the same three as HTTP 401, 503 (`retryable: true`) and 409 (`retryable: false`) — see [MCP.md](MCP.md).
 
 ### `gflow auth list`
 

{gflow_cli-0.73.0 → gflow_cli-0.73.2}/docs/DEBUGGING.md

@@ -157,7 +157,14 @@ bundle a user emails you:
 It prints a scorecard (grade, per-question YES/NO/N/A, privacy verdict). The
 live e2e benchmark (`tests/e2e/test_incident_quality_e2e.py`, credit-free)
 enforces quality floors on real bundles so a regression that hollows out the
-evidence fails CI even though the artifacts still exist.
+evidence is caught even though the artifacts still exist.
+
+**It is an opt-in gate, not a CI one** — it needs `-m e2e` and
+`GFLOW_CLI_E2E_PROFILE`, so nothing runs it on a pull request. And until #792 it
+graded only bundles captured deliberately on a *healthy* page, which is how a bug
+that hollowed out every **failure** bundle on the migrated host survived it. The
+file now also drives a real failed generation and asserts the DOM capture is not
+blank; run it before shipping anything that touches capture or page lifecycle.
 
 ### Worker / daemon correlation
 

{gflow_cli-0.73.0 → gflow_cli-0.73.2}/docs/INDEX.md

@@ -160,7 +160,7 @@ Slash commands for Claude Code, stored in `.claude/commands/gflow/`. All prefixe
 **"A command failed — where is the incident bundle and what's in it?"** → [DEBUGGING § Automatic incident bundles](DEBUGGING.md#automatic-incident-bundles) (layout, triggers, review-before-sharing); privacy boundaries: [SECURITY § Automatic incident bundles](SECURITY.md#automatic-incident-bundles-gflow_cli_incident_capture-default-on); disable via [CONFIGURATION § GFLOW_CLI_INCIDENT_CAPTURE](CONFIGURATION.md#gflow_cli_incident_capture)
 **"Flow's UI broke a selector — how do I diagnose it?"** → [DEBUGGING § Inspecting Flow's live UI](DEBUGGING.md#inspecting-flows-live-ui)
 **"What does each `ui_automation.*` log event mean?"** → [DEBUGGING § Listener & HTTP-layer debugging](DEBUGGING.md#listener--http-layer-debugging)
-**What was actually live-verified for the latest release?** → latest: [LIVE_VERIFICATION_v0.73.0](LIVE_VERIFICATION_v0.73.0.md) (**four error paths that stopped lying about what went wrong, verified 2026-09-10 on `ci-probe` and `denon82` at $0 — no run below reaches a Veo submit.** The decisive arm is an **A/B**, not an inspection: the pre-fix run printed an `accounts.google.com` challenge URL together with the OAuth `state` and `client_id`, and the identical command after the fix gave the same exit 38 and the same landing named with **five secret matches down to zero** — reading the post-fix output alone would only have shown that *these* secrets were absent. A second arm **falsified a claim already written into PR #775's body**: it said the change fixed the RED canary, and the live run showed `denon82` had moved to `accounts.google.com` mid-run, a landing the classifier excluded **by design**, with a unit test encoding the wrong reason — the offline suite was green throughout and could not have caught it. #776's happy path is verified by a real `gflow image t2i` (exit 0, 367 135-byte JPEG, `image_settings_applied` and `prompt_typed` both present, so **three of the four converted click sites** clicked successfully through the new helper); its **failure** path is real Chromium driving a page we wrote, which proves the mechanism and explicitly **not** that Flow still produces that state. **Three items recorded as NOT verified rather than omitted:** the `/about` redirect stopped reproducing (**0/5**, reported as *unmeasured* rather than argued into a retry flag), the `/fx/api/auth/*` landing moved before the run reached it, and #764's *success* path — an external contribution whose error boundary this release verifies but whose auto-selection needs an account currently behind a Google password challenge. The fourth converted click site is the **video** submit, unrun because it spends Veo credits, named rather than implied.) · previous: [LIVE_VERIFICATION_v0.72.0](LIVE_VERIFICATION_v0.72.0.md) (**auto-closing `gflow auth login`, verified 2026-09-09 on a migrated account at $0 across six runs.** Four paths: auto-close fires (`probe=in_context` at `elapsed_s` **84.8**, reproduced 3x), a manual close still verifies from disk (exit 0, never exit 12), `--browser auto` selects and completes, and a window closed **mid-2FA** is noticed in **2 s** (exit 8) where it previously ran the full 600 s deadline with the session endpoint touched **zero** times. **Two runs were discarded rather than counted**, and that is the useful part: the first returned exit 0 at `elapsed_s: 0.2` because a throwaway profile had survived the previous session and nobody signed in — a cached session reading as a clean pass — and three attempts at the manual-close path all returned exit 0 while being the *auto-close* path in disguise, separable only by an **absent** `probe=in_context`. The manual path was obtained by widening the poll interval for one run so the competing branch could not fire; the 2FA path by killing the profile's own Chrome, because hand-timing lost every race on a host that completes passkey sign-in in ~15 s. **Recorded as NOT verified rather than omitted:** the migrated-host image slice (#692) was **re-run this cycle** — CLI `t2i` PASSED first-hand on a moved account, while the queued-MCP `i2i` twin failed with a typed non-retryable exit 27 whose **cause is unknown** — some dialog opened after the file was chosen and no `maseQ` left the page, on an account that has ALREADY consented, so the message's "most likely the one-time upload-terms dialog" does not fit; no incident bundle was written, so nothing names the dialog, and it is filed for a spike rather than guessed; the subprocess fallback is unit-tested only; and the OAuth-callback *mechanism* behind the poll fix is **inferred, not proven** — a host-only gate does not exclude NextAuth's callback, since it runs on the app's own origin, yet all four sign-ins passed under it, so #769 carries the spike that would settle it.) · previous: [LIVE_VERIFICATION_v0.71.1](LIVE_VERIFICATION_v0.71.1.md) (**two migrated-host error paths stopped blaming the wrong thing, 2026-09-08, $0 across three profiles.** The agent-mode recovery landed earlier in this same release (#749) and worked, but its first cut collapsed three outcomes into one message — chip clicked / chip found but click blocked / chip clicked and mode still on — so a modal eating the click sent users to toggle a chip that was never the problem, and genuine selector drift *after* the mode was left was filed under an account setting the driver had already changed. Verified by an e2e that drives the account INTO agent mode and carries its own neutered-selector control; run **twice**, because review fixes landed after the first run and it no longer covered the code. **The larger find:** an account's FIRST upload on this host is blocked by Flow's one-time *"Rights to use this image"* dialog, which renders *after* the file chooser hands the file over — so `_dismiss_dialog` never sees it and the driver spent 60 s waiting for a request the page had already declined to make, then advised re-encoding the image. Six runs on `ci-probe` close the chain: guard fires while the dialog is up → owner-authorised accept → uploads (`media_id 8914400f`) → fresh session uploads clean with `dialog: None`. The order was forced, because the dialog is one-off and accepting it destroys the failing state — so the guard was written and verified BEFORE anything was clicked, and its firing branch is now unrepeatable here. `maseQ` is confirmed **not** renamed (six uploads, three profiles), killing #719's top hypothesis. Also: Flow's queue listing is on **`Zzl0ze`**, not the `jwpduf`/`as29s` progress polls, and two `abra_r2v_8s` records sat at status 6 for ~20 h unseen by any CLI command (#741). Three documents are corrected rather than patched — a KNOWN_ISSUES entry that told #719's reader this dialog did not affect gflow-cli, and a v0.71.0 host label calling `ci-probe` *labs* when it is migrated, which helped a credit-based theory survive four runs. Recorded as NOT verified: #719's second failure shape — an upload request that leaves the page and is never answered, ~1 run in 4 — which is unfixed and keeps #719 open.) · previous: [LIVE_VERIFICATION_v0.71.0](LIVE_VERIFICATION_v0.71.0.md) (**`gflow character create --voice` verified end to end for the first time, 2026-09-07 on profile `ffroliva`.** Before this release a repo-wide grep for `--voice` across `tests/e2e/` matched **nothing** — every voice test was a unit test of the hardcoded `VOICES` constant and the one that looked live parsed a fixture, so a voice that silently failed to attach was invisible to the whole suite while the command exited 0. A live create + `character show` read-back settles a contradiction between two of our own documents: `sent='Charon' stored='Charon' identical=True`, so the Capitalized canonical form round-trips and `CHARACTER_RECON.md`'s "preset id is the lowercased name" does not describe today's wire. Both docs also now record that `personalityNotes` is **Agent-scoped** per Flow's own editor copy, not a control on the audio engine. **A claim that was in the code is overturned:** the `_unported_form` entity guard said the submit "never produces a reply" and that the backend refuses — in fact `MZZa6b` replies with a null payload and the generation is **accepted and queued** (Flow types it `abra_r2v_8s` and renders it); the failure is the *observer*, which waits out `SUBMIT_REPLY_BUDGET_S` (60 s, calibrated on 4.0–4.6 s replies against an idle queue) and exits 9 while the video is still rendering. The guard stays until the observer is fixed, because a timeout reported on a healthy generation is worse than an explicit refusal. Also verified: credit shortfall reports exit **37** with `_raise_if_out_of_credits` called from **both** give-up paths — and it is *short for the selected model*, not empty (the measured account held **50** and asked for `veo-quality`, which costs **100**); the "+ New project" CTA anchored structurally on `add` (Tier-1 matches **1** where every previous entry matched **0**, control 47 ligature nodes) after this same release first asserted the control did not exist and a $0 run disproved it in one click; and the incident-bundle DOM dump de-blinded — it queried `i.google-symbols` only, so **every bundle a migrated user sent carried an empty ligature list**, which is why #727 and #731 stayed invisible. One item recorded as NOT verified rather than omitted: whether a bound character's **voice reaches rendered audio** (#738) — attachment is proven, application is not, because no entity-bound generation has yet returned a file to measure. The blocker is no longer credits or account access but retrieval, and the measurement is pre-calibrated: plate-bound takes of one character gave **88 / 103 / 118 Hz** against a **4.3 Hz** engine noise floor, so an applied Algenib should sit near its sample's **163.3 Hz**.) · previous: [LIVE_VERIFICATION_v0.70.0](LIVE_VERIFICATION_v0.70.0.md) (**reference-to-video on the migrated `flow.google.com` host, verified 2026-09-06 on profile `denon82`.** Three r2v runs bound their references every time; the decisive one is semantic rather than structural — two hand-drawn reference images went in and the clip came back carrying the same marker strokes, face and paper texture, which is what separates "Flow bound the reference" from "Flow accepted and ignored it". A four-beat, two-character piece was then produced end to end and joined with the concat filter: 19.000s, 1280x576, `clip_qa` **ok**, A/V **+0.000s**, both actors recognisable across every cut from one face plate plus the canon repeated verbatim. Also verified as exit-code corrections on the real CLI: `-o <existing directory>` now exits **2 in 0.8s** instead of exit 1 after ~2 min **and a billed, orphaned clip**; `character create` on a moved account exits **36 immediately** instead of a bare `RuntimeError` exit 1 after a 20s wait. Four items recorded as NOT verified rather than omitted: #692's original failure could not be reproduced [the reporter's own re-run was on a build without the fix, so it shows the failure is intermittent, not that the fix works]; Flow CHARACTER entities were never exercised because `character create` cannot run on any account available here; `image`/`scene`/`movie`/`extend` all exit 36 on the migrated host and no unmoved account exists here; and the sign-in-interstitial fidelity question from #699 has no bundle evidence either way.) · previous: [LIVE_VERIFICATION_v0.68.0](LIVE_VERIFICATION_v0.68.0.md) (`gflow update` self-upgrading a real `uv tool` and a real `pipx` install from their own running `gflow.exe` to the PyPI release, Windows 11, zero credits — see its own row below) · previous: [LIVE_VERIFICATION_v0.67.0](LIVE_VERIFICATION_v0.67.0.md) (the migrated `flow.google.com` driver — see its own row below) · previous: [LIVE_VERIFICATION_v0.64.0](LIVE_VERIFICATION_v0.64.0.md) (**#626 `--model omni-flash --end-frame` — first+last interpolation on Omni 1.1 Flash, verified 2026-09-02.** The guard this release removes was evidence-gated, so it was retired on evidence: a route-aborted submit capture on **two distinct Google accounts** (`ffroliva`, `denon82`) fired `video:batchAsyncGenerateVideoStartAndEndImage` with `startImage` AND `endImage` non-null at **zero credits**, ruling out a single-account artifact. The decisive layer is semantic, not structural: the paid 4s generation's **last frame IS the supplied end image** and its first frame is the start image — two visibly different subjects — which is the only check that distinguishes "Flow bound the end frame" from "Flow accepted and ignored it", and which layers 1–4 would pass either way. Render: 4.01s / 720×1280 / h264+aac / 2.4 MB, `MEDIA_GENERATION_STATUS_SUCCESSFUL`. The static capability table is **deleted**, not corrected — it went stale silently once and would again; a post-submit route check (`_assert_i2v_route`) now fails a run whose end frame Flow dropped back to the `StartImage` route, catching a rollback on any account without anyone re-reading a support page. One item is recorded as NOT verified rather than omitted: `--duration 10` + end frame is **submit-verified only** (`duration_set seconds=10` on the correct route with both images bound), because the status poll returned HTTP 401 mid-run and a retry 401'd at `project.create` before submitting — [#561](https://github.com/ffroliva/gflow-cli/issues/561), pre-existing, so verification was stopped rather than spending further credits on an environmental fault.) · previous: [LIVE_VERIFICATION_v0.63.0](LIVE_VERIFICATION_v0.63.0.md) (**`gflow video extend` — continuing a clip past Flow's 8s ceiling, verified 2026-09-01 on profile `ffroliva`, 20 Veo credits.** The decisive observation is that segment 2's `source_media_id` **is** segment 1's `media_id` (`0c9364f3…` seeded from `b9458021…`, then `648f9291…` seeded from `0c9364f3…`) — tail-only chaining, which no mock can establish; had it re-seeded from the source, the output would have been two divergent continuations of the same moment instead of one continuous shot. `extend_model_resolved` logged `candidate_count=99` against `SERVICE_TIER_INTERMEDIATE`, proving the key came from the live capability listing rather than a constant, and plan cost matched actual spend (`20 credits total, balance 875` → `Extended — 2/2 segment(s), 20 credits`). Render: 23.02s / 1280×720 / 24fps / h264+aac. **The run found a defect the offline suite is structurally incapable of seeing:** an extend segment carries **7.000000s** of content, not the 8 Flow advertises and bills, so server-side concat pads every internal seam with a frozen frame and digital silence (15s at −75.1 dB against −29 neighbours, reproduced on a second independent render) — filed in KNOWN_ISSUES with the three questions that must be answered before any clamp, and the reason `--extend N` on t2v/i2v was deliberately NOT shipped. Seven items are recorded as NOT verified rather than omitted: portrait `9:16`, `--aspect` against a mismatched source, chains longer than 2 segments, `--resume-from` against a live partial scene, the insufficient-credits refusal, a live Ctrl+C, and `OperationKind.EXTEND` rows.) · previous: [LIVE_VERIFICATION_v0.62.1](LIVE_VERIFICATION_v0.62.1.md) (**#604 `--model omni-flash` selects again after Flow's `Omni Flash` → `Omni 1.1 Flash` rename, verified 2026-08-30 on profile `ffroliva` at ZERO Veo credits.** The production `_select_video_model` was driven against the real picker: the shipped selector resolves verbatim — `model_selected model=omni_flash via="[role='menuitem']:has-text('Omni'):has-text('Flash'):not(:has-text('[Lower Priority]'))"` — and all six cases came back as expected: the four offered tiers SELECT, a tier Flow does not offer REFUSES, and a deliberately ambiguous selector REFUSES rather than resolving `.first`. Selection happens before submit, so the whole matrix is free. The transport's own refusal diagnostic read the live menu back as `Omni 1.1 Flash / Veo 3.1 - Lite / Fast / Quality`, independently corroborating the fixture. Four items are recorded as NOT verified rather than omitted: the rename *direction* [the `Omni Flash` baseline is a different account, locale and date], an actual `Omni ... [Lower Priority]` entry [Flow has never offered one], a full credit-spending generation on omni-flash, and #539's absence question, which stays open.) · previous: [LIVE_VERIFICATION_v0.62.0](LIVE_VERIFICATION_v0.62.0.md) (**#595 `auto` ≡ `classic` for images, verified 2026-08-28 on profile `ci-probe` — an account Flow had moved to the agentic cohort the day before — at ZERO Veo credits.** With no flags and no env vars the run logged `ui_driver.ui_mode.attempt_exit_agent` → `ui_driver.bound mode=classic ui_mode=classic` and generated a real 768x1376 JPEG (exit 0); the day before, the identical command on the same account bound `auto`→`agentic` and failed. The same log independently closed **#183**: `mode_switch_trigger` and `image_mode_tab`, the selectors it reported as unfindable, both matched. #591 was proven against the real 500-row catalog — **0** occurrences of the string `"None"`, 31 proper JSON `null`s, over a catalog holding 119 NULL-bearing rows. #592 shows exactly one `client.account_locale_cached` per command. Three items are recorded as NOT verified rather than omitted: the exit-28 abort on a *pinned* agentic account, the #597 batch inter-prompt guard, and any fresh announcement modal — the last two because all three accounts have already acked the current changelog, so no modal can be raised until Google ships the next one.) · previous: [LIVE_VERIFICATION_v0.61.0](LIVE_VERIFICATION_v0.61.0.md) (**#539 video-model refusal + #586 image-model refusal and server-side attribution, verified 2026-08-26/27 on profile `denon82`, ONE Veo generation total** — the video fix was proven by a **zero-credit A/B against the stashed pre-fix source running on live Flow**: the old code returned SELECTED for `veo-lite-lp`, a model Flow does not offer to this account, and for a deliberately ambiguous selector matching 3 entries; the new code refuses both with exit 18 naming what Flow offered. Model selection happens before submit, so refusals cost nothing and the A/B was free. The happy path still generates: `--model omni-flash` → exit 0, a real 2.2 MB `ftypisom` mp4, catalog recording `omni_flash`. Two items are recorded as NOT verified rather than omitted: three of #584's four navigation-settle sites were never exercised [no bearer refresh occurred in these runs], and #582's canary self-re-exec has its first real exercise tonight. Also falsified: #539's recorded note that the video picker uses a different trigger — the two constants are byte-identical strings, and the repeated empty menu captures were the capture's own fault.) · previous: [LIVE_VERIFICATION_v0.60.0](LIVE_VERIFICATION_v0.60.0.md)
+**What was actually live-verified for the latest release?** → latest: [LIVE_VERIFICATION_v0.73.2](LIVE_VERIFICATION_v0.73.2.md) (**the blank incident bundle, reproduced and then cured by a committed e2e test, 2026-09-12 on `ffroliva` at ZERO cost — every arm fails before submit.** The decisive layer is an **A/B run through the same instrument**, not an inspection: on `develop` the new test FAILS in 46.3 s and prints the bundle it got — `tag_counts.div = 0`, `title.length = 0`, `host_category = "other"`, a 4,254-byte screenshot — which is field-for-field the signature [#792](https://github.com/ffroliva/gflow-cli/issues/792) reported from a different account, a different OS and a different command; on the fix it PASSES in 37.8 s with `div` **25**, `title.length` **81**, `host_category` **`flow_app`**, `route` `/404` and a 38.4 KB screenshot. Both arms exit **23** on the same `.settings-trigger-button` drift at `flow.google.com/404?reason=project`, so the arms differ only in what was *captured*, never in what failed. **The reporter's own bundle contained the refutation of their diagnosis**: viewport 1280x720 is `client.py`'s client-owned page, not the 1920x1080 a stray transport tab would have — it was always the driven page, photographed one navigation too late, and the portrait correlation had no mechanism behind it. The existing quality benchmark could not have caught this: it captures deliberately on a **healthy** page, so it graded only bundles that were never at risk. **Recorded as NOT verified rather than omitted:** #796's `PROFILE_MARKER_MISSING` is offline-only because its live trigger is a cookie-store **decryption** failure, which does not occur on Windows/DPAPI — it is the macOS Keychain path of [#768](https://github.com/ffroliva/gflow-cli/issues/768), a **named external blocker**, and the issue stays open; a synthetic attempt to force it failed informatively, since a corrupt store raises `sqlite3.DatabaseError`, bypasses the marker gate and still prints "check network connectivity" — the same misdirection from a different trigger, untouched here. #795's remediation string is unit-asserted only, and the *other* half of #795 — `credits` being labs-only on migrated accounts — is **not fixed**.) · previous: [LIVE_VERIFICATION_v0.73.1](LIVE_VERIFICATION_v0.73.1.md) (**Google's `glue` consent bar covering the migrated composer, measured and then cured, 2026-09-11 on `ci-probe` for one image generation and no Veo credits.** The premise was nearly rejected: both prior sightings of that selector in this repo are labs.google, and the 2026-09-10 spike had read 159 DOM samples on this exact host and project and watched the click land 3/3 — it simply never looked for a cookie bar. Seventeen hours later the bar was up: `position: fixed`, `z-index: 1000`, spanning y 547-655 of a 655 px viewport, with `elementFromPoint` over the settings trigger AND over the image submit both returning `span#glue-cookie-notification-bar-1-label` in **0 of 5** rendered samples hit-testable. **The control arm is what makes it a cure rather than a coincidence**: the same probe re-run through the driver's own `_dismiss_cookie_bar` restored both controls to **4/4**, one attempt, no error. A full `gflow image t2i` then ran end to end on the merged code — `status: ok`, a 807,761-byte `ffd8ffe0` JPEG that Pillow reads as 1376x768 RGB, matching the requested 16:9 and the reply's own dimensions, with `migrated.editor_ready` at 2.0 s and **no** `cookie_bar_not_dismissed`. A side finding the control arm produced by accident: the bar's buttons are `__accept` then `__reject` in DOM order, so anything taking "the first button" accepts cookies for the operator — the shipped fix anchors on reject. **Three items recorded as NOT verified rather than omitted:** the cure against a live bar outside the browser, because this release's own control arm consumed the consent on the only profile that had it; **prevalence**, because the second profile never reached an editor (both arms redirected to `/about`) so it is one account blocked and one already-consented, and KNOWN_ISSUES says so rather than generalising from n=1; and the video path live, which shares the identical function on the identical control but spends Veo credits.) · previous: [LIVE_VERIFICATION_v0.73.0](LIVE_VERIFICATION_v0.73.0.md) (**four error paths that stopped lying about what went wrong, verified 2026-09-10 on `ci-probe` and `denon82` at $0 — no run below reaches a Veo submit.** The decisive arm is an **A/B**, not an inspection: the pre-fix run printed an `accounts.google.com` challenge URL together with the OAuth `state` and `client_id`, and the identical command after the fix gave the same exit 38 and the same landing named with **five secret matches down to zero** — reading the post-fix output alone would only have shown that *these* secrets were absent. A second arm **falsified a claim already written into PR #775's body**: it said the change fixed the RED canary, and the live run showed `denon82` had moved to `accounts.google.com` mid-run, a landing the classifier excluded **by design**, with a unit test encoding the wrong reason — the offline suite was green throughout and could not have caught it. #776's happy path is verified by a real `gflow image t2i` (exit 0, 367 135-byte JPEG, `image_settings_applied` and `prompt_typed` both present, so **three of the four converted click sites** clicked successfully through the new helper); its **failure** path is real Chromium driving a page we wrote, which proves the mechanism and explicitly **not** that Flow still produces that state. **Three items recorded as NOT verified rather than omitted:** the `/about` redirect stopped reproducing (**0/5**, reported as *unmeasured* rather than argued into a retry flag), the `/fx/api/auth/*` landing moved before the run reached it, and #764's *success* path — an external contribution whose error boundary this release verifies but whose auto-selection needs an account currently behind a Google password challenge. The fourth converted click site is the **video** submit, unrun because it spends Veo credits, named rather than implied.) · previous: [LIVE_VERIFICATION_v0.72.0](LIVE_VERIFICATION_v0.72.0.md) (**auto-closing `gflow auth login`, verified 2026-09-09 on a migrated account at $0 across six runs.** Four paths: auto-close fires (`probe=in_context` at `elapsed_s` **84.8**, reproduced 3x), a manual close still verifies from disk (exit 0, never exit 12), `--browser auto` selects and completes, and a window closed **mid-2FA** is noticed in **2 s** (exit 8) where it previously ran the full 600 s deadline with the session endpoint touched **zero** times. **Two runs were discarded rather than counted**, and that is the useful part: the first returned exit 0 at `elapsed_s: 0.2` because a throwaway profile had survived the previous session and nobody signed in — a cached session reading as a clean pass — and three attempts at the manual-close path all returned exit 0 while being the *auto-close* path in disguise, separable only by an **absent** `probe=in_context`. The manual path was obtained by widening the poll interval for one run so the competing branch could not fire; the 2FA path by killing the profile's own Chrome, because hand-timing lost every race on a host that completes passkey sign-in in ~15 s. **Recorded as NOT verified rather than omitted:** the migrated-host image slice (#692) was **re-run this cycle** — CLI `t2i` PASSED first-hand on a moved account, while the queued-MCP `i2i` twin failed with a typed non-retryable exit 27 whose **cause is unknown** — some dialog opened after the file was chosen and no `maseQ` left the page, on an account that has ALREADY consented, so the message's "most likely the one-time upload-terms dialog" does not fit; no incident bundle was written, so nothing names the dialog, and it is filed for a spike rather than guessed; the subprocess fallback is unit-tested only; and the OAuth-callback *mechanism* behind the poll fix is **inferred, not proven** — a host-only gate does not exclude NextAuth's callback, since it runs on the app's own origin, yet all four sign-ins passed under it, so #769 carries the spike that would settle it.) · previous: [LIVE_VERIFICATION_v0.71.1](LIVE_VERIFICATION_v0.71.1.md) (**two migrated-host error paths stopped blaming the wrong thing, 2026-09-08, $0 across three profiles.** The agent-mode recovery landed earlier in this same release (#749) and worked, but its first cut collapsed three outcomes into one message — chip clicked / chip found but click blocked / chip clicked and mode still on — so a modal eating the click sent users to toggle a chip that was never the problem, and genuine selector drift *after* the mode was left was filed under an account setting the driver had already changed. Verified by an e2e that drives the account INTO agent mode and carries its own neutered-selector control; run **twice**, because review fixes landed after the first run and it no longer covered the code. **The larger find:** an account's FIRST upload on this host is blocked by Flow's one-time *"Rights to use this image"* dialog, which renders *after* the file chooser hands the file over — so `_dismiss_dialog` never sees it and the driver spent 60 s waiting for a request the page had already declined to make, then advised re-encoding the image. Six runs on `ci-probe` close the chain: guard fires while the dialog is up → owner-authorised accept → uploads (`media_id 8914400f`) → fresh session uploads clean with `dialog: None`. The order was forced, because the dialog is one-off and accepting it destroys the failing state — so the guard was written and verified BEFORE anything was clicked, and its firing branch is now unrepeatable here. `maseQ` is confirmed **not** renamed (six uploads, three profiles), killing #719's top hypothesis. Also: Flow's queue listing is on **`Zzl0ze`**, not the `jwpduf`/`as29s` progress polls, and two `abra_r2v_8s` records sat at status 6 for ~20 h unseen by any CLI command (#741). Three documents are corrected rather than patched — a KNOWN_ISSUES entry that told #719's reader this dialog did not affect gflow-cli, and a v0.71.0 host label calling `ci-probe` *labs* when it is migrated, which helped a credit-based theory survive four runs. Recorded as NOT verified: #719's second failure shape — an upload request that leaves the page and is never answered, ~1 run in 4 — which is unfixed and keeps #719 open.) · previous: [LIVE_VERIFICATION_v0.71.0](LIVE_VERIFICATION_v0.71.0.md) (**`gflow character create --voice` verified end to end for the first time, 2026-09-07 on profile `ffroliva`.** Before this release a repo-wide grep for `--voice` across `tests/e2e/` matched **nothing** — every voice test was a unit test of the hardcoded `VOICES` constant and the one that looked live parsed a fixture, so a voice that silently failed to attach was invisible to the whole suite while the command exited 0. A live create + `character show` read-back settles a contradiction between two of our own documents: `sent='Charon' stored='Charon' identical=True`, so the Capitalized canonical form round-trips and `CHARACTER_RECON.md`'s "preset id is the lowercased name" does not describe today's wire. Both docs also now record that `personalityNotes` is **Agent-scoped** per Flow's own editor copy, not a control on the audio engine. **A claim that was in the code is overturned:** the `_unported_form` entity guard said the submit "never produces a reply" and that the backend refuses — in fact `MZZa6b` replies with a null payload and the generation is **accepted and queued** (Flow types it `abra_r2v_8s` and renders it); the failure is the *observer*, which waits out `SUBMIT_REPLY_BUDGET_S` (60 s, calibrated on 4.0–4.6 s replies against an idle queue) and exits 9 while the video is still rendering. The guard stays until the observer is fixed, because a timeout reported on a healthy generation is worse than an explicit refusal. Also verified: credit shortfall reports exit **37** with `_raise_if_out_of_credits` called from **both** give-up paths — and it is *short for the selected model*, not empty (the measured account held **50** and asked for `veo-quality`, which costs **100**); the "+ New project" CTA anchored structurally on `add` (Tier-1 matches **1** where every previous entry matched **0**, control 47 ligature nodes) after this same release first asserted the control did not exist and a $0 run disproved it in one click; and the incident-bundle DOM dump de-blinded — it queried `i.google-symbols` only, so **every bundle a migrated user sent carried an empty ligature list**, which is why #727 and #731 stayed invisible. One item recorded as NOT verified rather than omitted: whether a bound character's **voice reaches rendered audio** (#738) — attachment is proven, application is not, because no entity-bound generation has yet returned a file to measure. The blocker is no longer credits or account access but retrieval, and the measurement is pre-calibrated: plate-bound takes of one character gave **88 / 103 / 118 Hz** against a **4.3 Hz** engine noise floor, so an applied Algenib should sit near its sample's **163.3 Hz**.) · previous: [LIVE_VERIFICATION_v0.70.0](LIVE_VERIFICATION_v0.70.0.md) (**reference-to-video on the migrated `flow.google.com` host, verified 2026-09-06 on profile `denon82`.** Three r2v runs bound their references every time; the decisive one is semantic rather than structural — two hand-drawn reference images went in and the clip came back carrying the same marker strokes, face and paper texture, which is what separates "Flow bound the reference" from "Flow accepted and ignored it". A four-beat, two-character piece was then produced end to end and joined with the concat filter: 19.000s, 1280x576, `clip_qa` **ok**, A/V **+0.000s**, both actors recognisable across every cut from one face plate plus the canon repeated verbatim. Also verified as exit-code corrections on the real CLI: `-o <existing directory>` now exits **2 in 0.8s** instead of exit 1 after ~2 min **and a billed, orphaned clip**; `character create` on a moved account exits **36 immediately** instead of a bare `RuntimeError` exit 1 after a 20s wait. Four items recorded as NOT verified rather than omitted: #692's original failure could not be reproduced [the reporter's own re-run was on a build without the fix, so it shows the failure is intermittent, not that the fix works]; Flow CHARACTER entities were never exercised because `character create` cannot run on any account available here; `image`/`scene`/`movie`/`extend` all exit 36 on the migrated host and no unmoved account exists here; and the sign-in-interstitial fidelity question from #699 has no bundle evidence either way.) · previous: [LIVE_VERIFICATION_v0.68.0](LIVE_VERIFICATION_v0.68.0.md) (`gflow update` self-upgrading a real `uv tool` and a real `pipx` install from their own running `gflow.exe` to the PyPI release, Windows 11, zero credits — see its own row below) · previous: [LIVE_VERIFICATION_v0.67.0](LIVE_VERIFICATION_v0.67.0.md) (the migrated `flow.google.com` driver — see its own row below) · previous: [LIVE_VERIFICATION_v0.64.0](LIVE_VERIFICATION_v0.64.0.md) (**#626 `--model omni-flash --end-frame` — first+last interpolation on Omni 1.1 Flash, verified 2026-09-02.** The guard this release removes was evidence-gated, so it was retired on evidence: a route-aborted submit capture on **two distinct Google accounts** (`ffroliva`, `denon82`) fired `video:batchAsyncGenerateVideoStartAndEndImage` with `startImage` AND `endImage` non-null at **zero credits**, ruling out a single-account artifact. The decisive layer is semantic, not structural: the paid 4s generation's **last frame IS the supplied end image** and its first frame is the start image — two visibly different subjects — which is the only check that distinguishes "Flow bound the end frame" from "Flow accepted and ignored it", and which layers 1–4 would pass either way. Render: 4.01s / 720×1280 / h264+aac / 2.4 MB, `MEDIA_GENERATION_STATUS_SUCCESSFUL`. The static capability table is **deleted**, not corrected — it went stale silently once and would again; a post-submit route check (`_assert_i2v_route`) now fails a run whose end frame Flow dropped back to the `StartImage` route, catching a rollback on any account without anyone re-reading a support page. One item is recorded as NOT verified rather than omitted: `--duration 10` + end frame is **submit-verified only** (`duration_set seconds=10` on the correct route with both images bound), because the status poll returned HTTP 401 mid-run and a retry 401'd at `project.create` before submitting — [#561](https://github.com/ffroliva/gflow-cli/issues/561), pre-existing, so verification was stopped rather than spending further credits on an environmental fault.) · previous: [LIVE_VERIFICATION_v0.63.0](LIVE_VERIFICATION_v0.63.0.md) (**`gflow video extend` — continuing a clip past Flow's 8s ceiling, verified 2026-09-01 on profile `ffroliva`, 20 Veo credits.** The decisive observation is that segment 2's `source_media_id` **is** segment 1's `media_id` (`0c9364f3…` seeded from `b9458021…`, then `648f9291…` seeded from `0c9364f3…`) — tail-only chaining, which no mock can establish; had it re-seeded from the source, the output would have been two divergent continuations of the same moment instead of one continuous shot. `extend_model_resolved` logged `candidate_count=99` against `SERVICE_TIER_INTERMEDIATE`, proving the key came from the live capability listing rather than a constant, and plan cost matched actual spend (`20 credits total, balance 875` → `Extended — 2/2 segment(s), 20 credits`). Render: 23.02s / 1280×720 / 24fps / h264+aac. **The run found a defect the offline suite is structurally incapable of seeing:** an extend segment carries **7.000000s** of content, not the 8 Flow advertises and bills, so server-side concat pads every internal seam with a frozen frame and digital silence (15s at −75.1 dB against −29 neighbours, reproduced on a second independent render) — filed in KNOWN_ISSUES with the three questions that must be answered before any clamp, and the reason `--extend N` on t2v/i2v was deliberately NOT shipped. Seven items are recorded as NOT verified rather than omitted: portrait `9:16`, `--aspect` against a mismatched source, chains longer than 2 segments, `--resume-from` against a live partial scene, the insufficient-credits refusal, a live Ctrl+C, and `OperationKind.EXTEND` rows.) · previous: [LIVE_VERIFICATION_v0.62.1](LIVE_VERIFICATION_v0.62.1.md) (**#604 `--model omni-flash` selects again after Flow's `Omni Flash` → `Omni 1.1 Flash` rename, verified 2026-08-30 on profile `ffroliva` at ZERO Veo credits.** The production `_select_video_model` was driven against the real picker: the shipped selector resolves verbatim — `model_selected model=omni_flash via="[role='menuitem']:has-text('Omni'):has-text('Flash'):not(:has-text('[Lower Priority]'))"` — and all six cases came back as expected: the four offered tiers SELECT, a tier Flow does not offer REFUSES, and a deliberately ambiguous selector REFUSES rather than resolving `.first`. Selection happens before submit, so the whole matrix is free. The transport's own refusal diagnostic read the live menu back as `Omni 1.1 Flash / Veo 3.1 - Lite / Fast / Quality`, independently corroborating the fixture. Four items are recorded as NOT verified rather than omitted: the rename *direction* [the `Omni Flash` baseline is a different account, locale and date], an actual `Omni ... [Lower Priority]` entry [Flow has never offered one], a full credit-spending generation on omni-flash, and #539's absence question, which stays open.) · previous: [LIVE_VERIFICATION_v0.62.0](LIVE_VERIFICATION_v0.62.0.md) (**#595 `auto` ≡ `classic` for images, verified 2026-08-28 on profile `ci-probe` — an account Flow had moved to the agentic cohort the day before — at ZERO Veo credits.** With no flags and no env vars the run logged `ui_driver.ui_mode.attempt_exit_agent` → `ui_driver.bound mode=classic ui_mode=classic` and generated a real 768x1376 JPEG (exit 0); the day before, the identical command on the same account bound `auto`→`agentic` and failed. The same log independently closed **#183**: `mode_switch_trigger` and `image_mode_tab`, the selectors it reported as unfindable, both matched. #591 was proven against the real 500-row catalog — **0** occurrences of the string `"None"`, 31 proper JSON `null`s, over a catalog holding 119 NULL-bearing rows. #592 shows exactly one `client.account_locale_cached` per command. Three items are recorded as NOT verified rather than omitted: the exit-28 abort on a *pinned* agentic account, the #597 batch inter-prompt guard, and any fresh announcement modal — the last two because all three accounts have already acked the current changelog, so no modal can be raised until Google ships the next one.) · previous: [LIVE_VERIFICATION_v0.61.0](LIVE_VERIFICATION_v0.61.0.md) (**#539 video-model refusal + #586 image-model refusal and server-side attribution, verified 2026-08-26/27 on profile `denon82`, ONE Veo generation total** — the video fix was proven by a **zero-credit A/B against the stashed pre-fix source running on live Flow**: the old code returned SELECTED for `veo-lite-lp`, a model Flow does not offer to this account, and for a deliberately ambiguous selector matching 3 entries; the new code refuses both with exit 18 naming what Flow offered. Model selection happens before submit, so refusals cost nothing and the A/B was free. The happy path still generates: `--model omni-flash` → exit 0, a real 2.2 MB `ftypisom` mp4, catalog recording `omni_flash`. Two items are recorded as NOT verified rather than omitted: three of #584's four navigation-settle sites were never exercised [no bearer refresh occurred in these runs], and #582's canary self-re-exec has its first real exercise tonight. Also falsified: #539's recorded note that the video picker uses a different trigger — the two constants are byte-identical strings, and the repeated empty menu captures were the capture's own fault.) · previous: [LIVE_VERIFICATION_v0.60.0](LIVE_VERIFICATION_v0.60.0.md)
 **"Was the playwright upper bound raised, and on what evidence?"** → [LIVE_VERIFICATION_playwright_1.61](LIVE_VERIFICATION_playwright_1.61.md) (**`>=1.59.0,<1.60.0` → `>=1.61.0,<1.62.0` verified 2026-08-05, 1 Imagen + 1 Veo credit** — the 2026-08-03 regression that motivated the bound does NOT reproduce on 1.61.0: a live `i2v` drove the full chain with `image_uploaded status=200` → `frame_attached` → `generate_captured status=200` with `startImage` parsed, where **1.62.0 hung silently at exactly that upload step**; live `i2i` local-ref attach passed outright [96.7s]. **1.62.0 stays excluded** — never root-caused. Also found, A/B-proven pre-existing on BOTH 1.59.0 and 1.61.0: Flow dropped the duration-tab UI, so **`--duration` is currently broken for i2v** — `UiSelectorDriftError` fires correctly [refusing rather than silently accepting Flow's default, #288] but the selector needs re-deriving; that is why the i2v proof was driven via the CLI without `--duration`, and Flow's own server-side `PUBLIC_ERROR_VIDEO_GENERATION_TIMED_OUT` means no finished mp4 is claimed).
 **"Where is the reverse-engineered wire protocol for a feature?"** → the `*_RECON.md` design docs: [CHARACTER_RECON](CHARACTER_RECON.md) (Flow character entity protocol), [IMAGE_UPSCALE_RECON](IMAGE_UPSCALE_RECON.md) (`/v1/flow/upsampleImage` wire). Naming convention: one `<FEATURE>_RECON.md` per reverse-engineered surface, kept as the durable spec after the feature ships. Pre-capture research recons: [ASSET_TAGGING_RECON](ASSET_TAGGING_RECON.md) (`@`-mention asset tagging — shipped in v0.40.0, see [LIVE_VERIFICATION_v0.40.0](LIVE_VERIFICATION_v0.40.0.md)).
 **"What was live-verified for v0.66.1?"** → [LIVE_VERIFICATION_v0.66.1](LIVE_VERIFICATION_v0.66.1.md) — **the two migrated-origin fixes, verified 2026-09-03 on profile `ffroliva` at ZERO credits, on BOTH sides of what was then read as a flapping rollout** (superseded 2026-09-04: the handoff is a one-way per-account flag and exit 36 is non-retryable since). On a real `flow.google.com` load `get_ui_driver` raised `FlowHostMigratedError` in **0 ms** (was ~36 s: ~8 s detect window + ~24 s crop cascade + 4 s URL settle), exit 36, `retryable: true` (then; `false` since 2026-09-04), `ui_driver.migrated_host_bail` logged; `await_url_settled` returned `null` in **0 ms** (measured 4018 ms before); and the locale was recovered as `en` from `html lang=en-GB` where the URL gave `null`. The no-regression half is the stronger evidence: minutes later the same command landed on the OLD host and completed **exit 0** with a real 768x1376 JPEG in 42.2 s, proving the host guard is scoped and does not short-circuit the working path. Three items recorded as NOT verified rather than omitted: driving the migrated frontend (still impossible, #639 stays open), the pt-BR recovery live (measured `html lang=pt` on `denon82` but exercised live only on `en-GB`), and the `en-GB`→`en` region reduction against a locale where region is load-bearing (`zh-Hans`/`zh-Hant`) — only two locales observed.

gflow_cli-0.73.2/docs/LIVE_VERIFICATION_v0.73.1.md

@@ -0,0 +1,136 @@
+# Live verification — v0.73.1
+
+**Date:** 2026-09-11 · **Profile:** `ci-probe` (migrated host, `flow.google.com`) ·
+**Project:** `1e4efe0d-…` · **Cost:** one image generation (daily quota; **zero Veo
+credits**), everything else navigation and DOM reads.
+
+v0.73.1 is a two-part patch on the migrated `flow.google.com` driver. Both parts are on
+the path every image and video generation takes, so the whole release is live-verifiable
+and none of it is exempt.
+
+---
+
+## 1. The defect, measured before the fix
+
+The claim under test is that Google's `glue` consent bar covers the composer's controls.
+Nothing in this repo had ever observed it on this host, and the
+[2026-09-10 spike](superpowers/spikes/2026-09-10-migrated-click-blocked.md) had read 159
+DOM samples on this exact profile and project and watched the click land 3/3.
+
+`scripts/dev/spike_migrated_cookie_bar.py`, 6 samples across the composer-mount window:
+
+| Reading | Result |
+|---|---|
+| bar elements matched / visible | 6 / 6 |
+| settings trigger hit-testable | **0 of 5 rendered** |
+| image submit hit-testable | **0 of 5 rendered** |
+| what `elementFromPoint` returned over each | `span#glue-cookie-notification-bar-1-label` |
+| bar geometry | `position: fixed`, `z-index: 1000`, y 547→655 of a 655 px viewport |
+
+Both controls sit inside that band. Full writeup:
+[`superpowers/spikes/2026-09-11-migrated-cookie-bar-blocks-the-composer.md`](superpowers/spikes/2026-09-11-migrated-cookie-bar-blocks-the-composer.md).
+
+## 2. The cure, measured with a control arm
+
+Same script, `--dismiss`, which imports the driver's own `_dismiss_cookie_bar` rather
+than clicking the bar itself — so the arm always measures what ships.
+
+| Reading | Before | After |
+|---|---|---|
+| bar elements visible | 4 / 4 | **0 / 4** |
+| settings trigger hit-testable | 0 / 3 rendered | **4 / 4** |
+| image submit hit-testable | 0 / 3 rendered | **4 / 4** |
+| dismissal error | — | none, one attempt |
+
+---
+
+## 3. Five-layer ledger — `gflow image t2i` end-to-end through the fixed path
+
+The command a user actually runs, pure CLI, on the merged code:
+
+```
+gflow image t2i "a single white ceramic cup on a grey stone table, soft daylight" \
+  --profile ci-probe --project 1e4efe0d-… --model nano-pro --aspect 16:9 --json
+```
+
+| Layer | Evidence |
+|---|---|
+| **1. File count** | 1 file written, `images/2026-09-11/2c3ed966-…_1.jpg` |
+| **2. Magic bytes** | `ffd8ffe0` — JPEG SOI + APP0 |
+| **3. Dimensions / shape** | Pillow reads `JPEG (1376, 768) RGB`; 807,761 bytes. Matches the requested `--aspect 16:9` and the reply's `dimensions` block |
+| **4. Structlog invariants** | `migrated.navigate` → `migrated.editor_ready` (2.0 s) → `migrated.image_model_already_selected` (`GEM_PIX_2`) → `migrated.image_settings_applied` (`IMAGE_ASPECT_RATIO_LANDSCAPE`, count 1) → `migrated.prompt_typed` (63 chars). **No `migrated.cookie_bar_not_dismissed`**, and no `UiSelectorDriftError` |
+| **5. User-confirmable artifact** | `status: ok`, media `2c3ed966-c851-48b5-99c2-1b3f5846c4dc`, workflow `43d6138a-…`, seed 998497784, signed `flow-content.google` URL, local JPEG on disk |
+
+`migrated.cookie_bar_dismissed` is **absent** in this run and that is the expected
+reading: the spike's control arm had already consumed consent on this profile, so the
+run exercised the bar-free path. That is the regression risk the new call introduces —
+a dismissal that runs on every generation — and it is the half this release can prove
+live.
+
+## 4. A no-submit repeat of the same path
+
+`ensure_editor` → `apply_image_settings` → `_close_pane` driven directly, $0, no prompt
+typed and nothing submitted: editor ready in 2 s, `🍌 Nano Banana Pro` bound, aspect and
+count bound, pane closed clean. Confirms the new call is inert when no bar is present,
+without spending quota a second time.
+
+---
+
+## Addendum, same day — the two open items closed
+
+Both were recorded below as *not verified* at tag time. Both were then measured, and this
+section is the record rather than a rewrite of what shipped.
+
+**Prevalence — answered by mechanism.** A count of users is not obtainable here (no
+telemetry), but the gate is: `localStorage["glue.CookieNotificationBar"]` on the
+`flow.google.com` origin. Not a cookie, which is why no profile carried `SOCS`. A clean
+browser profile reads the bar visible **4/4**; a second untouched authenticated profile
+(`pr389fresh2`) read **5/5**. Removing that one key on `ci-probe` — touching no cookie,
+so no auth — flipped the editor from *both controls hit-testable* to **both covered by
+`span#glue-cookie-notification-bar-1-label`**. So the bar is the origin's default state
+and a stored dismissal is what removes it: every fresh profile meets it, and any profile
+whose dismissal Google resets meets it again.
+
+**The cure, against a live bar, on the released build.** With the bar restored by that
+intervention, the ordinary CLI command ran on `cli_version: 0.73.1`:
+`migrated.editor_ready` → **`migrated.cookie_bar_dismissed`** 86 ms later →
+`image_settings_applied` → `prompt_typed` → `status: ok`, media `257d8f79-…`, a
+651,576-byte `ffd8ffe0` JPEG that Pillow reads as 1024×1024 RGB.
+
+Still not measured: the *covering* geometry on a second account's editor. `denon82` and
+`pr389fresh2` both redirect to `/about`, so origin-level presence is measured on three
+profiles and the occlusion on one.
+
+---
+
+## What was NOT verified at tag time, and why
+
+*(The first two are closed by the addendum above; kept as written for the record.)*
+
+**The cure against a live bar, outside the browser.** The consent state is not summonable
+on demand, and this release's own control arm consumed it on the only profile that had it.
+The dismissal is therefore proven live in the *before/after* of §2 and in the browser by
+`tests/e2e/test_click_attribution_bdd.py` (8/8, with a stashed-source control run where
+both new scenarios fail), but no post-fix CLI generation has yet run against a bar that
+was up at the time.
+
+**Prevalence.** One account observed blocked, one (`denon82`) observed already-consented —
+and that second run never reached an editor, because both arms redirected to
+`flow.google.com/about`. How widely the bar fires is unmeasured, and `KNOWN_ISSUES.md`
+says so rather than generalising from n=1.
+
+**The video path, live.** `_dismiss_cookie_bar` sits in `_open_pane`, which video shares,
+and the offline suite pins that (`test_the_consent_bar_is_cleared_on_the_video_path_too`).
+No live video run was made: it spends Veo credits and exercises the identical function on
+the identical control. Named here rather than implied.
+
+## Gates
+
+| Gate | Result |
+|---|---|
+| `ruff check` / `ruff format --check` | clean, 467 files |
+| `pyright src` | 0 errors |
+| `pytest -m "not live and not e2e and not smoke"` | 4234 passed, 24 skipped |
+| `pytest -m e2e` (click attribution) | 8 passed |
+| repo hygiene · doc links · website PII · mirror drift · council memory | all green |
+| SonarCloud (PR #782) | gate passed |