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

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

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

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

@@ -7,6 +7,58 @@ 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
@@ -4867,7 +4919,8 @@ 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.1...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

{gflow_cli-0.73.1 → 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
@@ -220,11 +220,19 @@ at `z-index: 1000`, and Flow's composer is bottom-anchored in the same band. The
 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. **How widely it fires is unmeasured** — one
-account observed blocked, one observed already-consented — so treat the recurrence
-pattern as unknown rather than as once-per-profile. The labs driver survives it by
-accident; `_bypass_onboarding` carries a text match on "Agree". The migrated driver
-had no equivalent.
+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,
@@ -800,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
@@ -810,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.1 → gflow_cli-0.73.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: gflow-cli
-Version: 0.73.1
+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.1/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.1 → 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.1 → 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.1 → 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.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)
+**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.1 → gflow_cli-0.73.2}/docs/LIVE_VERIFICATION_v0.73.1.md

@@ -76,7 +76,36 @@ without spending quota a second time.
 
 ---
 
-## What was NOT verified, and why
+## 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.

gflow_cli-0.73.2/docs/LIVE_VERIFICATION_v0.73.2.md

@@ -0,0 +1,187 @@
+# Live verification — v0.73.2
+
+**Date:** 2026-09-12 · **Profile:** `ffroliva` (migrated host, `flow.google.com`) ·
+**Cost:** **zero** — every arm fails before submit, so no image and no Veo credits were
+spent.
+
+v0.73.2 is a diagnostics and error-clarity patch. It does **not** fix migrated login
+(#791) or the i2v dispatch failure reported in #792 — both remain open. What it fixes is
+the layer underneath those: the evidence a failure produces, and the advice a failure
+prints.
+
+One consequence worth stating plainly, because it decides whether this release is worth
+cutting at all: until now every failure on `flow.google.com` shipped an **unreadable**
+incident bundle. The reporter of #792 filed a wrong root cause *because* of it. This
+release is what makes the next report actionable.
+
+---
+
+## 1. The defect, measured before the fix (control arm)
+
+The claim under test: the migrated composer parks its own page on `about:blank` inside a
+bare `finally`, which runs on the **failure** path too — so `_capture_incident`
+photographs a blank page instead of the page that failed.
+
+Control: `develop` source, with only the new e2e test file checked out on top, driving a
+real failure (a syntactically valid but nonexistent `--project` UUID lands on Flow's 404
+and fails the `.settings-trigger-button` probe with exit 23).
+
+```
+tests/e2e/test_incident_quality_e2e.py::test_a_failed_generation_bundle_is_not_hollow
+FAILED in 46.27s
+```
+
+The bundle it produced, verbatim from the assertion:
+
+```json
+{"ligatures": [], "ligature_count": 0,
+ "signals": {"crop_present": false, "textboxes": 0},
+ "url": {"host_category": "other", "route": "other"},
+ "title": {"category": "other", "length": 0},
+ "tag_counts": {"div": 0, "button": 0, "input": 0, "textarea": 0,
+                "dialog": 0, "iframe": 0, "video": 0, "img": 0},
+ "viewport": {"width": 1280, "height": 720}}
+```
+
+That is field-for-field the signature [#792](https://github.com/ffroliva/gflow-cli/issues/792)
+reported from a different account, on a different OS, on a different command. The bug
+reproduces.
+
+## 2. The cure, measured with the same instrument
+
+Same test, same profile, same command shape, on the release branch:
+
+```
+tests/e2e/test_incident_quality_e2e.py::test_a_failed_generation_bundle_is_not_hollow
+1 passed in 37.80s
+```
+
+| Reading | Control (`develop`) | v0.73.2 |
+|---|---|---|
+| `tag_counts.div` | **0** | **25** |
+| `title.length` | **0** | **81** |
+| `url.host_category` | **`other`** | **`flow_app`** |
+| `url.route` | `other` | `/404` |
+| `ligature_count` | 0 | 1 (`arrow_back`) |
+| `signals.textboxes` | 0 | 1 |
+| `sensitive/screenshot.png` | **4,254 B** (blank frame) | **38.4 KB** (real page) |
+
+An earlier manual A/B on the same host, taken before the design was revised, produced the
+same two columns — so the result is not an artifact of the final implementation.
+
+## 3. Five-layer ledger — #792
+
+| Layer | Evidence |
+|---|---|
+| Artifact exists | Both arms wrote an incident bundle under `$GFLOW_CLI_HOME/incidents/2026-09-12/`; the CLI printed its path and a `report.md` |
+| Magic bytes / size | `screenshot.png` 4,254 B (control) vs 38,4xx B (fixed) — a blank 1280×720 PNG compresses to ~4 KB, a rendered Flow page ~10× that |
+| Shape | `ui.json` `tag_counts.div` 0 → 25, `title.length` 0 → 81, `host_category` `other` → `flow_app` |
+| Log invariants | Exit **23** in both arms with the same `UiSelectorDriftError` on `.settings-trigger-button` at `https://flow.google.com/404?reason=project` — i.e. the arms differ only in what was *captured*, not in what failed |
+| User-confirmable | The bundle directory is openable; the screenshot now shows the Flow 404 page rather than white |
+
+The test is committed, so this is a re-runnable regression, not a one-off observation:
+`pytest -m e2e tests/e2e/test_incident_quality_e2e.py` with `GFLOW_CLI_E2E_PROFILE` set.
+
+## 4. NOT live-verified this cycle — and why
+
+**#796 — `PROFILE_MARKER_MISSING`.** Offline only (unit + MCP-twin tests). Its live
+trigger is a cookie-store **decryption failure**, which does not occur on Windows/DPAPI —
+it is the macOS Keychain path tracked in #768. **Named external blocker: no macOS host
+available.** This is recorded, not omitted, and the issue stays open with `Refs`.
+
+A synthetic attempt to force the path is worth recording because it *failed informatively*:
+a deliberately corrupted cookie store raises `sqlite3.DatabaseError`, which is not
+normalized to `PermissionError`, so it bypasses the marker gate entirely and still prints
+"check network connectivity". Same misdirection class, different trigger — untouched by
+this release.
+
+To close it, on macOS: fail a login once on a fresh profile, then
+`GFLOW_CLI_LOG_LEVEL=DEBUG gflow auth status`, and confirm the outcome reads
+`profile_marker_missing` rather than `verification_error`.
+
+**#795 — the `credits` remediation string.** Offline only. The raise path is reachable
+live on this account (labs answers `200 {}` for migrated accounts), but the change is a
+message, and its correctness is a text assertion the unit test already makes. The *other*
+half of #795 — `credits` being labs-only on migrated accounts — is **not fixed** and stays
+open.
+
+**The two pre-existing `[Unreleased]` entries** (#756's `/about` retry measurement and the
+terminal-width test pin) were verified in their own PRs; the second touches no Flow
+surface at all.
+
+---
+
+## 5. Doc-review gate (`/gflow:doc-review`)
+
+Mechanical sections 0-7 **PASS**: repo hygiene (1073 files), doc links (29 files),
+website PII (25 files), `generate_website_docs.py --check` (20 files, nav complete),
+`check_release_artifacts.py`, council memory (49 files) — all green, re-run after every
+fix below. CHANGELOG footer correct (`[Unreleased]` empty, `compare/v0.73.1...v0.73.2`).
+`EXIT_CODE_MAP` is unchanged at 37 entries, range 3-38 — #796 adds a session *outcome*,
+not an error class, and `gflow auth status` still exits 1.
+
+Council: **GREEN** (cross-reference) / **YELLOW** (completeness) / **YELLOW** (drift).
+No RED. Eight findings fixed in this release-prep commit:
+
+| # | Finding | Fixed in |
+|---|---|---|
+| 1 | `docs/MCP.md` said the `/about` retry flag "was measured and could not be settled" — this release settles it 5/5 | `docs/MCP.md` |
+| 2 | `docs/USAGE.md` exit-31 row said the retry "is not measured" and linked the superseded 2026-09-10 spike | `docs/USAGE.md` |
+| 3 | `gflow_auth_status`'s new `profile_marker_missing` outcome (409, `retryable: false`) was undocumented | `docs/MCP.md` |
+| 4 | The same outcome was undocumented on the **CLI** surface | `docs/AUTHENTICATION.md` |
+| 5 | `gflow credits` being labs-only on migrated accounts (#795, open) appeared in no user doc | `docs/USAGE.md`, `docs/MCP.md`, `KNOWN_ISSUES.md` (x2) |
+| 6 | CHANGELOG undercounted the corrected `/about` sites ("two comments" — it is four) | `CHANGELOG.md` |
+| 7 | `docs/ARCHITECTURE.md`'s current-layout inventory had drifted again: no `flow_selectors/`, `_cli_helpers.py`, `exceptions.py`, `file_integrity.py`, `redaction.py` | `docs/ARCHITECTURE.md` |
+| 8 | `docs/USER_GUIDE.md` 1.3 told first-time users bare `gflow auth login`, contradicting README/AGENTS.md | `docs/USER_GUIDE.md` |
+
+Carried forward rather than fixed here, each with its reason:
+
+- **`src/gflow_cli/auth/verification.py:87`** — the `FlowSessionStatus` docstring still says
+  `detail` is "one of the **four** fixed strings"; `_DETAIL_BY_OUTCOME` has **five** since
+  #796. Found independently by the drift auditor and the mechanical pass. Left to the
+  implementer: this gate does not edit `src/`.
+- **`KNOWN_ISSUES.md` has no entry for #791, #792's dispatch half, or #768** — all open and
+  user-facing (titles confirmed via `gh issue view`). Not written here, because #791's
+  premise ("verification never passes for migrated accounts") is contradicted by this
+  repo's own [v0.72.0 ledger](LIVE_VERIFICATION_v0.72.0.md), which signed in six times on a
+  migrated account; an entry asserting it is universal would be exactly the n=1
+  generalisation the project forbids. Route through `/gflow:issue-assessment` first.
+
+---
+
+## Verdict
+
+The release's headline change is verified live on the affected surface, with a control
+arm, by a committed test. The two auth-message changes are verified offline with one
+named external blocker recorded above. Nothing in this release is claimed as verified
+that was not run.
+
+---
+
+## Gates
+
+Run on `chore/release-v0.73.2` (cut from `develop@15c58af0`), 2026-09-12.
+
+| Gate | Result |
+|---|---|
+| `check_repo_hygiene.py` | PASS |
+| `check_doc_links.py` | PASS |
+| `check_website_docs_pii.py` | PASS |
+| `generate_website_docs.py --check` | PASS (mirror in sync) |
+| `check_council_memory.py` | PASS |
+| `check_release_artifacts.py` | PASS — it caught the missing `docs/INDEX.md` ledger reference before the tag |
+| `ruff check src tests` | PASS |
+| `ruff format --check src tests` | PASS (467 files) |
+| `uv run pyright src` | PASS — **0 errors** |
+| `pytest` (offline, full) | **4241 passed, 24 skipped** on `develop@15c58af0` |
+| `pytest tests/auth tests/mcp tests/cli` | **884 passed** on the release branch |
+| `uv lock --check` | PASS (lockfile carries the 0.73.2 bump) |
+| `uv build` + ZIP-duplicate scan | PASS — wheel reports `__version__ = "0.73.2"`, 138 entries, no duplicates |
+| `/gflow:doc-review` | **PASS** — 8 fixes applied, two of them false claims this release contradicts |
+
+**One gate caveat worth recording.** `pyright` must be invoked as `uv run pyright src`
+(what CI runs). Invoked as `.venv/Scripts/python.exe -m pyright src` on this machine it
+reports **86 phantom errors** in `mcp/` and `ui/` — stable across re-runs, convincing
+(`"MCPServer" is unknown import symbol`), and entirely an artifact of how that invocation
+resolves the environment. The packages are correctly installed and the suite passes
+against them. It nearly blocked this release.

{gflow_cli-0.73.1/website → gflow_cli-0.73.2}/docs/MCP.md

@@ -94,8 +94,8 @@ The server registers three protocol surfaces:
 > different axis entirely: it buys a *look*, not an identity. Use
 > `gflow_character_list` to discover ids. See [REFERENCE_STRATEGIES](REFERENCE_STRATEGIES.md).
 
-* `gflow_auth_status(profile)`: Credit-free, non-interactive Flow session probe (#497) — wraps the same fail-closed `verify_flow_profile` check as `gflow auth status`. Returns `{"status": "authenticated", "profile", "user_email"}` or a problem-details error with a `remediation_hint`; a `verification_error` outcome means a network/endpoint problem, which re-login does not fix. Call it before a generation tool to fail fast on dead auth (the queue is async — without it, an auth failure surfaces only later from the daemon). Login/logout remain CLI-only (genuinely interactive).
-* `gflow_get_credits(profile, all_profiles)`: Read-only current Flow balance query. With `all_profiles=true`, inspects every saved profile sequentially and preserves successful balances plus `total_credits` when another profile fails. This tool spends no credits and returns no cookies, bearer tokens, or browser API keys. The balance funds Veo video generation; image generation uses separate per-model daily quotas.
+* `gflow_auth_status(profile)`: Credit-free, non-interactive Flow session probe (#497) — wraps the same fail-closed `verify_flow_profile` check as `gflow auth status`. Returns `{"status": "authenticated", "profile", "user_email"}` or a problem-details error with a `remediation_hint`; a `verification_error` outcome (HTTP 503, `retryable: true`) means a network/endpoint problem, which re-login does not fix, and a `profile_marker_missing` outcome (HTTP 409, `retryable: false`, #796) means the profile lost its `.gflow_browser_strategy` marker so its cookies cannot be read — neither a retry nor a re-login helps; re-run `gflow auth login --browser chrome` for that profile. Any other unauthenticated outcome is a dead session (HTTP 401). Call it before a generation tool to fail fast on dead auth (the queue is async — without it, an auth failure surfaces only later from the daemon). Login/logout remain CLI-only (genuinely interactive).
+* `gflow_get_credits(profile, all_profiles)`: Read-only current Flow balance query. With `all_profiles=true`, inspects every saved profile sequentially and preserves successful balances plus `total_credits` when another profile fails. This tool spends no credits and returns no cookies, bearer tokens, or browser API keys. The balance funds Veo video generation; image generation uses separate per-model daily quotas. **Labs-only:** on an account Google has migrated to `flow.google.com`, Flow's labs.google session mints no API token, so no balance can be read there — the tool reports that the labs session returned no access token, which is expected on that cohort and is not an auth fault. Open, tracked in #795.
 * `gflow_character_list(project, profile)`: Lists a project's saved Flow CHARACTER entities with their **entity ids** — read-only, spends no credits, drives a browser session. This is how an agent discovers what it can attach: an `entity_id` goes to `reference_entities`, a `display_name` can be used as an `@Name` mention. An empty list means the project genuinely has none.
 * `gflow_character_show(project, entity_id, name, profile)`: Shows one character by id or exact display name (exactly one selector required). An ambiguous name is refused rather than resolved arbitrarily — which is the reason to prefer the id. Read-only; drives a browser session.
 * `gflow_character_voices()`: Lists the preset voices available for Character TTS (name, description, sample URL). A static in-process lookup — no network, no browser, no profile, no cost. Call it to pick a valid voice name.
@@ -146,8 +146,11 @@ UI arm (`UiModeUnavailableError`), and a partially-completed sync
 (`SyncPartialError`). That list is `errors.RETRYABLE_ERRORS`, but it is no longer
 the whole answer: `errors.is_retryable` consults the **instance** first, so a raise
 site can override its class. One does today — Flow's `/about` redirect raises
-`FlowAppError` with `retryable: false`, because whether a retry helps there was
-measured and could not be settled ([#756](https://github.com/ffroliva/gflow-cli/issues/756)).
+`FlowAppError` with `retryable: false`, and since 2026-09-11 that is a **measurement**, not a
+preserved default: caught during a live occurrence, 5/5 consecutive attempts over ~3 minutes
+landed on `/about` again, on the account's own project with a healthy session — so a retry is
+doomed and costs ~35 s each ([#756](https://github.com/ffroliva/gflow-cli/issues/756)). The
+*cause*, and whether it ever clears, remain unmeasured.
 Read the flag off the envelope; never re-derive it from the class list.
 Everything
 else (auth, content-policy, configuration, security) is terminal