gflow-cli 0.71.0__tar.gz → 0.71.1__tar.gz

{gflow_cli-0.71.0 → gflow_cli-0.71.1}/.codex-plugin/plugin.json

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

{gflow_cli-0.71.0 → gflow_cli-0.71.1}/AGENTS.md

@@ -42,7 +42,7 @@ by construction, so Codex / Cursor / Aider / `agy` read exactly what Claude Code
 
 ## Project at a glance
 
-- Unofficial Python CLI for [Google Flow](https://labs.google/fx/tools/flow) — drives Veo (image-to-video, text-to-video) and Imagen (text-to-image) generations from the terminal by reverse-engineering Flow's private REST API at `aisandbox-pa.googleapis.com` — and, for accounts Google has moved to `flow.google.com`, that frontend's `batchexecute` wire (text-to-video, and image-to-video from a local `--initial-frame`, today; `GFLOW_CLI_FLOW_HOST`).
+- Unofficial Python CLI for [Google Flow](https://labs.google/fx/tools/flow) — drives Veo (image-to-video, text-to-video) and Imagen (text-to-image) generations from the terminal by reverse-engineering Flow's private REST API at `aisandbox-pa.googleapis.com` — and, for accounts Google has moved to `flow.google.com`, that frontend's `batchexecute` wire (text-to-video, image-to-video from a local `--initial-frame`, and reference-to-video from local `--ref` files, today; `GFLOW_CLI_FLOW_HOST`).
 - Python 3.11+ · `uv`-managed · `hatchling` builds · Playwright Chromium transport · `pyright` strict · `ruff` · `pytest`.
 - Single-package modular monolith. Top-level modules under `src/gflow_cli/`: `api/`, `auth/`, `data/`, `mcp/`, `services/`, `tools/`, `ui/`, `worker/`, `browser_manager.py`, `cli.py`, `_cli_helpers.py`, `diagnostics.py`, `json_output.py`, `media.py`, `profile_lease.py`, `redaction.py`, `storage.py`, `winsec.py`, `cli_project.py`, `cli_character.py`, `cli_credits.py`, `cli_data.py`, `cli_image.py`, `cli_instructions.py`, `cli_models.py`, `cli_movie.py`, `cli_run.py`, `cli_scene.py`, `cli_tools.py`, `cli_video.py`, `chain.py`, `chain_manifest.py`, `cli_doctor.py`, `cli_update.py`, `composition.py`, `config.py`, `errors.py`, `file_integrity.py`, `flow_selectors/`, `update_check.py`, `exceptions.py`, `image_batch.py`, `movie_manifest.py`, `observability.py`, `paths.py`, `profile_store.py`.
 - Command surface: `gflow auth`, `gflow credits` (user/list — read-only Veo balance), `gflow image` (t2i/i2i/batch/upload/upscale), `gflow video` (t2v/i2v/r2v/chain/extend — `extend` continues an existing clip past Flow's 8s ceiling, server-seeded from the source so the join is continuous; no `batch` subcommand; the nonfunctional stub was removed, loop `gflow video t2v`/`i2v` from the shell for multi-clip runs), `gflow character` (create/list/show/rm/voices — reusable project-scoped Flow Character entities), `gflow scene` (create/show — Add Clip / Scenes, with `create --output` for credit-free server-side extended video), `gflow instructions` (persistent Agent-Mode brief cards — add/list/enable/disable/rm/apply/toggle-mode, credits-free, `--project` required), `gflow movie` (run/template — multi-scene manifest pipeline), `gflow tools` (list/show/run — prompt-rewriting tools, also `--tool` on generation commands), `gflow data` (catalog queries), `gflow doctor` (read-only pre-flight diagnostic, exit 33 = findings present), `gflow update` (self-update through the installer that put it here — uv tool / pipx / pip; `--check` only reports; source installs refused, exit 11; deliberately no MCP twin), `gflow project`, `gflow models`, `gflow run`, `gflow mcp` (run/setup — stdio MCP server), and `gflow serve` (Streamable HTTP at `/mcp`; `--transport sse` is deprecated).

{gflow_cli-0.71.0 → gflow_cli-0.71.1}/CHANGELOG.md

@@ -7,6 +7,103 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.71.1] — 2026-09-08
+
+### Fixed
+
+- **A blocked first upload no longer reads as a broken file or a broken network.** On the
+  migrated `flow.google.com` host, `video i2v --initial-frame` and `video r2v --ref` failed
+  on an account's **first** upload with `MediaUploadRejectedError` (exit 27) — *"no maseQ
+  reply within 60s of choosing the file — the upload never reached Flow or was dropped"* —
+  and advised re-encoding the image to strip metadata. Neither the file nor the network was
+  involved: Flow shows a one-time **"Rights to use this image"** confirmation *after* the
+  chooser hands the file over, and sends nothing until a human accepts it, so the driver
+  spent its whole budget waiting for a request the page had already declined to make.
+  Measured across 8 runs on 3 profiles — the two accounts that had uploaded before never saw
+  the dialog and uploaded fine, the account that never had failed 3/3, and accepting it once
+  made that account upload on the next run and every run after
+  ([spike](docs/superpowers/spikes/2026-09-08-migrated-upload-fails-two-ways.md)).
+
+  The driver now counts dialogs across the upload and, when one appeared *during* it, names
+  the one-time confirmation and tells the user to accept it once in a browser. **It is
+  counted rather than matched on purpose:** the dialog's two buttons are
+  `button.flow-button-medium` with no ligature and no data attribute, separable only by DOM
+  order, and its copy is translated — there is no anchor there that satisfies this project's
+  locale rule, whereas "a dialog appeared between the file being chosen and the wait
+  expiring" is upload-related by construction and cannot rot when Angular renames a class.
+
+  **gflow does not accept the dialog for you**, and there is no flag to make it: the dialog
+  affirms that *you* hold the rights to what you upload, it is one-off per account, and the
+  path already requires an interactive `gflow auth login` — so a setting that could never
+  safely default to on would be a flag nobody sets.
+
+  The driver also now watches the upload **request**, not just the response, so the timeout
+  splits into two distinct messages: `no upload request ever left the page` and `the request
+  left the page and Flow did not answer in time`. That distinction is load-bearing — the
+  second argues for a retry and the first argues against one — and it exposes a **second,
+  unfixed** failure on this path, an intermittent no-reply on already-consented accounts
+  (~1 run in 4) that keeps [#719](https://github.com/ffroliva/gflow-cli/issues/719) open and
+  now has its own [KNOWN_ISSUES.md](KNOWN_ISSUES.md) entry.
+  ([#719](https://github.com/ffroliva/gflow-cli/issues/719))
+
+### Documentation
+
+- **Three documents said things that were not true, and are corrected rather than quietly
+  patched.** [KNOWN_ISSUES.md](KNOWN_ISSUES.md) said Flow's first-upload terms dialog affected
+  "the legacy in-tree Compiled Growth worker, **NOT `gflow-cli` itself** … workaround: none
+  needed" — true of the old REST path, false since the migrated driver began using the
+  editor's own upload, so it was the entry a user hitting #719 would find and be *reassured*
+  by. [LIVE_VERIFICATION_v0.71.0](docs/LIVE_VERIFICATION_v0.71.0.md) labelled the `ci-probe`
+  profile **labs** when it is migrated, contradicting v0.70.0 one day earlier; in a repo where
+  "Flow's UI shows X" is not a fact until the host is named, that silently re-scoped every
+  conclusion keyed to it — and it helped a credit-based theory for #719 survive four runs.
+  Six "unreleased line" phrases, which go stale the moment a release ships and had accumulated
+  across four of them, are now dated from the CHANGELOG.
+
+### Added
+
+- **Two `$0` read-only dev instruments** for the migrated host.
+  [`scripts/dev/spike_migrated_queue_read.py`](scripts/dev/spike_migrated_queue_read.py) reads
+  a project's generation queue by listening to the page's own traffic — establishing that the
+  listing arrives on **`Zzl0ze`**, not the `jwpduf`/`as29s` progress polls, which is what a
+  future `gflow video status` ([#741](https://github.com/ffroliva/gflow-cli/issues/741)) should
+  read. [`scripts/dev/spike_migrated_upload_wire.py`](scripts/dev/spike_migrated_upload_wire.py)
+  drives the real `_upload_via_toolbar` with a listener on every request, which is how the
+  consent dialog above was found. Neither is wired into the CLI.
+
+- **Flow's agent mode no longer bricks the account for every later run.** On the migrated
+  `flow.google.com` host the composer carries an **agent-mode chip**
+  (`button.agent-mode-chip[aria-pressed]`). Pressed, Flow swaps `flow-prompt-box` for
+  `flow-creative-agent-prompt-box`: the `.settings-trigger-button` this driver waits on stays
+  in the DOM but gains a bare `hidden` (`display: none`, 0×0, not hit-testable), so
+  `wait_for(state="visible")` could never pass and every run died at 30 s as
+  `UiSelectorDriftError` (exit 23) — telling the user to file a frontend-drift bug about a
+  frontend that was working fine. Flow **remembers the chip per account**, so one click in a
+  browser broke every subsequent `gflow video t2v`, with nothing on the CLI to say why or how
+  to undo it. `ensure_editor` now leaves agent mode before the readiness gate, and if the
+  classic composer still does not come back it says *that* instead of blaming drift. Measured
+  2026-09-08 on two accounts, $0 —
+  [`scripts/dev/spike_migrated_composer_arms.py`](scripts/dev/spike_migrated_composer_arms.py),
+  finding in
+  [`docs/superpowers/spikes/2026-09-08-migrated-composer-agent-mode-hides-settings.md`](docs/superpowers/spikes/2026-09-08-migrated-composer-agent-mode-hides-settings.md).
+  The reporter's suggested anchor (`aria-label="Configuración"`) is not used: it is a translated
+  label, and the chip's own component class plus `aria-pressed` carry the same identity in every
+  locale. ([#749](https://github.com/ffroliva/gflow-cli/issues/749))
+
+  **Follow-up ([#752](https://github.com/ffroliva/gflow-cli/issues/752)):** the fix worked and
+  its diagnostics did not. Three states were collapsed into one message — the chip was clicked,
+  the chip was found but the click was blocked, the chip was clicked and the mode is still on —
+  and all three read as *"the chip was clicked to leave it … the mode may be pinned"*. A modal
+  eating the click sent the user to toggle a chip; genuine selector drift **after** the mode was
+  successfully left was reported as a pinned mode, so the drift bug never got filed. The chip's
+  `aria-pressed` is now read back before that claim is made, a blocked click raises at once
+  instead of waiting out the 20 s recovery window (worst case 55 s → 35 s), the click's own
+  exception is chained rather than truncated into a log line, and `_open_pane` — the same gate
+  one step later — guards on **visibility** rather than `count()`, so a mode flip mid-run maps
+  to exit 23 naming agent mode instead of escaping as a bare Playwright timeout. Searchable
+  entry added to [KNOWN_ISSUES.md](KNOWN_ISSUES.md), which the shipped message gave a user no
+  way to find.
+
 ## [0.71.0] — 2026-09-07
 
 ### Fixed
@@ -4483,7 +4580,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.71.0...HEAD
+[Unreleased]: https://github.com/ffroliva/gflow-cli/compare/v0.71.1...HEAD
+[0.71.1]: https://github.com/ffroliva/gflow-cli/compare/v0.71.0...v0.71.1
 [0.71.0]: https://github.com/ffroliva/gflow-cli/compare/v0.70.0...v0.71.0
 [0.70.0]: https://github.com/ffroliva/gflow-cli/compare/v0.69.0...v0.70.0
 [0.69.0]: https://github.com/ffroliva/gflow-cli/compare/v0.68.0...v0.69.0

{gflow_cli-0.71.0 → gflow_cli-0.71.1}/KNOWN_ISSUES.md

@@ -19,9 +19,9 @@ Living list of behaviour that's broken, surprising, or limited by design — alo
 - **Status:** Open (partially resolved) · **Severity:** High for everything except text-to-video, local-file image-to-video and local-file reference-to-video · **Affected:** on accounts the rollout has reached, `gflow video t2v`, `gflow video i2v --initial-frame <local file>` and `gflow video r2v --ref <local file>` now run on the migrated host (with `--project`); an end frame, a frame by UUID or `@Name`, references by `@Name` or `--reference-entity`, `image`, scenes, extend, instructions and tools are not ported yet and still exit 36. **`character` is NOT in that list any more** — `character create` was verified working on the migrated host in v0.70.0 and `character list` was re-verified there on 2026-09-07. This line claimed otherwise for a day, which is the dangerous direction for a stale doc to be stale in: a migrated user reading it concludes a working feature is impossible. Of the remainder, only the i2v-by-UUID case rests on a positive observation of absence (the Frames picker's tiles carry no media id); `scenes`, `extend`, `instructions` and `tools` have never had a probe run against them at all, so read them as *unported by gflow*, never as *impossible on the host*
 - **Tracked:** [#639](https://github.com/ffroliva/gflow-cli/issues/639) · Reported 2026-09-02 against 0.59.0, 0.62.1, 0.63.0 and 0.65.0
 - **Confirmed live 2026-09-03 on a second, independent account** (`ffroliva`) — see [LIVE_VERIFICATION_v0.66.0](docs/LIVE_VERIFICATION_v0.66.0.md). A read-only probe of the migrated origin measured `i_total: 0`, reproducing the reporter's central measurement.
-- **`--reference-entity` was refused on `r2v` but not on `t2v`** ([#716](https://github.com/ffroliva/gflow-cli/issues/716), fixed in the unreleased line, post-v0.70.0): the "not ported, exit 36" refusal above sat inside the r2v branch of the routing gate, so a `t2v` request carrying a character entity returned from that gate without its entities ever being inspected — and nothing downstream attaches one on this host. The generation was **submitted and billed** with the entity silently dropped, returning a plausible clip of the wrong person. The check is now mode-independent and ahead of every early return. If you ran `gflow video t2v @Name …` or `--reference-entity` on a moved account before this fix, the identity in those clips was never bound.
+- **`--reference-entity` was refused on `r2v` but not on `t2v`** ([#716](https://github.com/ffroliva/gflow-cli/issues/716), fixed in v0.71.0): the "not ported, exit 36" refusal above sat inside the r2v branch of the routing gate, so a `t2v` request carrying a character entity returned from that gate without its entities ever being inspected — and nothing downstream attaches one on this host. The generation was **submitted and billed** with the entity silently dropped, returning a plausible clip of the wrong person. The check is now mode-independent and ahead of every early return. If you ran `gflow video t2v @Name …` or `--reference-entity` on a moved account before this fix, the identity in those clips was never bound.
 - **The migrated composer DOES have an image mode** ([#692](https://github.com/ffroliva/gflow-cli/issues/692)): a code comment claimed, as "measured, not assumed", that it has none. Falsified 2026-09-07 — its settings overlay carries a `mode` radiogroup of `[imageImage, videocamVideo]`, present and hit-testable. Nothing was clicked on that axis and nothing was submitted, so this does **not** establish that `image` works on a moved account; it establishes only that the claim it cannot is unfounded. Read the remaining exit 36 as *gflow does not drive this yet*, never as *the host cannot do it*; see [the spike](docs/superpowers/spikes/2026-09-07-migrated-composer-has-an-image-mode.md).
-- **Image commands on a moved account** ([#673](https://github.com/ffroliva/gflow-cli/issues/673), fixed in the unreleased line, post-v0.68.0): through v0.68.0 `image t2i` / `i2i` (and `upscale`, `extend`) died with exit 1 `RecaptchaError` within seconds, before any submit, instead of the exit 36 above, because the labs client minted the reCAPTCHA token on the `flow.google.com` project grid before any migration guard ran. The guard now runs at the mint. If you still see a `RecaptchaError` on a moved account right after `auth login`, that is the labs logged-out landing page from the [#644](https://github.com/ffroliva/gflow-cli/issues/644) cookie harvest, not this.
+- **Image commands on a moved account** ([#673](https://github.com/ffroliva/gflow-cli/issues/673), fixed in v0.69.0): through v0.68.0 `image t2i` / `i2i` (and `upscale`, `extend`) died with exit 1 `RecaptchaError` within seconds, before any submit, instead of the exit 36 above, because the labs client minted the reCAPTCHA token on the `flow.google.com` project grid before any migration guard ran. The guard now runs at the mint. If you still see a `RecaptchaError` on a moved account right after `auth login`, that is the labs logged-out landing page from the [#644](https://github.com/ffroliva/gflow-cli/issues/644) cookie harvest, not this.
 
 Google is moving Flow off Labs onto its own origin. On a migrated page load,
 `https://labs.google/fx/tools/flow/project/<id>` redirects to
@@ -391,7 +391,7 @@ Evidence: [LIVE_VERIFICATION_v0.23.0](docs/LIVE_VERIFICATION_v0.23.0.md).
 
 ### Expanded chat sidebar left the composer unrecoverable (exit 23)
 
-- **Status:** **Resolved** in the unreleased line — fixed and A/B-verified live;
+- **Status:** **Resolved** in v0.60.0 — fixed and A/B-verified live;
   tracked in [#493](https://github.com/ffroliva/gflow-cli/issues/493)
 - **Severity:** High · **Affected:** `gflow image` / `gflow video` generation on
   accounts whose chat sidebar lacks the `edit_square` affordance, any locale
@@ -687,18 +687,52 @@ This is because Chromium holds an exclusive lock on its SQLite cookie database w
 ---
 
 
-### Flow's first-upload terms-of-use dialog ("Aviso") blocks the worker (worker-only)
+### Flow's one-time upload-terms dialog blocks the FIRST upload on an account
 
-- **Status:** Open · **Severity:** Low · **Affects:** the legacy in-tree Compiled Growth worker, NOT `gflow-cli` itself
+- **Status:** Mitigated · **Severity:** High until accepted (every `i2v --initial-frame` and `r2v --ref` on that account fails) · **Affects:** the migrated `flow.google.com` host, all versions through 0.71.0 · **Tracked:** [#719](https://github.com/ffroliva/gflow-cli/issues/719)
 
-Flow shows a one-time "Aviso" / "Notice" terms-of-use confirmation on the first image upload of a new account session. The legacy Playwright worker has to explicitly click "Concordo" / "Agree". `gflow-cli`'s API-driven path bypasses this dialog entirely (the REST endpoint already implies acceptance).
+Flow shows a one-time **"Rights to use this image"** confirmation the first time an account uploads a file. It renders **after** the file chooser has handed the file over, and Flow sends **nothing** until it is accepted — so the driver waited out its full 60 s budget for an upload request the page had already decided not to make, then reported:
 
-**Workaround in gflow-cli:** none needed.
+```
+MediaUploadRejectedError (exit 27): migrated host: no maseQ reply within 60s of choosing
+the file — the upload never reached Flow or was dropped
+```
+
+…and advised re-encoding the image to strip metadata. Neither the file nor the network was ever involved. Measured 2026-09-08 on three profiles, eight runs: the two accounts that had uploaded before never saw the dialog and uploaded fine; the account that never had failed 3/3. See [the spike](docs/superpowers/spikes/2026-09-08-migrated-upload-fails-two-ways.md).
+
+> **This entry previously said the opposite.** It read *"Affects: the legacy in-tree Compiled Growth worker, NOT `gflow-cli` itself"*, because *"gflow-cli's API-driven path bypasses this dialog entirely (the REST endpoint already implies acceptance)"*, with *"Workaround in gflow-cli: none needed."* That was true of the REST path and became false when the migrated driver started using the editor's **own** upload — so the entry a user hitting #719 would find was reassuring them about the exact thing that was breaking their run.
+
+**Mitigation** (v0.71.1): when the upload budget expires, the driver checks whether a dialog opened *during* the upload window and, if so, says so and points the user at the one-time acceptance instead of blaming the file.
+
+**Workaround / how to clear it — once per account, ever:** open the project on `flow.google.com`, upload any image by hand, and accept the dialog. Uploads on that account then stop hitting *this* failure.
 
-**Workaround in legacy worker:** see Compiled Growth's `flow_video.py` consent-dismiss block.
+> **Accepting does not make every upload succeed — there is a second, unrelated failure on this path.** See the next entry. If you have already accepted the dialog and an upload still times out, you are not looking at this issue and repeating the workaround will not help.
+
+**gflow does not accept it for you, by design.** The dialog affirms that *you* hold the rights to the content you upload; that is not a claim a tool may make on an account owner's behalf. It is also a 30-second step, once, on a path that already requires an interactive browser login (`gflow auth login`) — so automating it would buy nothing and assert something on your behalf. There is deliberately no config flag: a setting that can never safely default to on, on a once-per-account event, is a flag nobody sets.
+
+**Legacy worker:** Compiled Growth's `flow_video.py` clicks "Concordo" / "Agree" in its own consent-dismiss block. That is a different product decision, recorded here so the two are not confused.
 
 ---
 
+### An upload request leaves the page and Flow never answers (intermittent, migrated host)
+
+- **Status:** Open · **Severity:** Medium (intermittent; costs a re-run, spends nothing) · **Affects:** the migrated `flow.google.com` host, `video i2v --initial-frame` and `video r2v --ref` · **Tracked:** [#719](https://github.com/ffroliva/gflow-cli/issues/719)
+
+Distinct from the one-time upload-terms dialog above, and **not** fixed by accepting it. On an account that has already consented, roughly **1 upload in 4** sends the `maseQ` request — measured at 8 675 B for a 4 321-byte PNG, so the image is genuinely on the wire — and no reply ever arrives. Since v0.71.1 that reports:
+
+```
+MediaUploadRejectedError (exit 27): migrated host: no maseQ reply within 60s of choosing
+the file — the request left the page and Flow did not answer in time
+```
+
+The contrasting message, **`no upload request ever left the page`**, means something client-side stopped it before the network — the consent dialog above being the known cause.
+
+**Workaround:** re-run. The same file usually succeeds on the next attempt, and nothing is spent when it fails — Flow refuses before any submit.
+
+**Not the file.** Three different images were ruled out in [#719](https://github.com/ffroliva/gflow-cli/issues/719), including a 4.3 KB synthetic flat colour with no metadata, and the same file uploads successfully on other attempts. Re-encoding does not help; the remediation text that used to suggest it was wrong.
+
+**What is known.** A healthy upload window issues **4** POSTs; a failing one issued **24** — the full project-load rpcid inventory, firing ~2.6 s after the request went out, which is just before the ~2.8 s successful uploads take to answer. That has the shape of the page re-initialising underneath the in-flight upload, but no navigation event was captured, so the cause is unconfirmed. Measured 2026-09-08, 1 failure in 4 runs on one funded account — enough for "intermittent", not enough for a rate.
+
 ### Flow's release-notes ("What's new") changelog popup blocks first-run UI automation
 
 - **Status:** Mitigated · **Severity:** Medium · **Tracked:** [#26](https://github.com/ffroliva/gflow-cli/issues/26)
@@ -1169,6 +1203,32 @@ a `WireFormatError` about video bytes — neither naming the cause). `auto` now
 instead of a mid-run failure, and `GFLOW_CLI_PREFER_CLASSIC=1` is no longer the
 workaround anyone needs to discover.
 
+### Flow's agent-mode chip hides the settings trigger on `flow.google.com` (exit 23)
+
+- **Status:** Mitigated · **Severity:** High while it lasts (every video run on the account fails) · **Affects:** the migrated `flow.google.com` host, all versions through 0.71.0 · **Tracked:** [#749](https://github.com/ffroliva/gflow-cli/issues/749), follow-up [#752](https://github.com/ffroliva/gflow-cli/issues/752)
+
+The migrated composer has an **Agent** chip. Pressed, Flow swaps the prompt box and
+leaves `.settings-trigger-button` — the element this driver waits on — in the DOM under
+a bare `hidden` (`display: none`, 0×0). Flow **remembers the chip per account**, so a
+single click in a browser made every later `gflow video` run on that account die at 30 s
+as `UiSelectorDriftError` (exit 23), telling the user to file a frontend-drift bug about
+a frontend that was working correctly.
+
+**Mitigation** (v0.71.1): the readiness gate leaves agent mode by
+itself, so an account parked there recovers with no user action. If it cannot, the error
+now names which of three things happened rather than blaming drift:
+
+| The message says | What it means | What to do |
+|---|---|---|
+| `the account is in Flow's agent mode … the chip could not be clicked` | something is covering the chip (a modal) | dismiss it in a browser; re-run |
+| `the chip was clicked, and it is STILL pressed` | the mode is pinned on this account | turn the **Agent** chip off in a browser; re-run |
+| `agent mode was left, but the settings trigger … still did not become visible` | the mode is off — this is real selector drift | file a bug; it is not this issue |
+| `the chip could not be read back, so whether the mode is still on is unknown` | the page went dark mid-recovery | check the **Agent** chip in a browser *before* filing this as drift |
+| `the settings trigger … is not visible — the account is in Flow's agent mode` | the mode flipped **mid-run**, after the editor was already ready | turn the **Agent** chip off in a browser; re-run |
+
+**On 0.71.0 and earlier there is no recovery.** Open the project on
+`flow.google.com`, click the **Agent** chip off, and the account works again.
+
 ### Auth verification depends on Google's NextAuth session endpoint
 
 - **Status:** Mitigated · **Severity:** Low (degrades fail-closed) · **Affects:** issue #15 fix onward · **Tracked:** issue #15

{gflow_cli-0.71.0 → gflow_cli-0.71.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: gflow-cli
-Version: 0.71.0
+Version: 0.71.1
 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
@@ -198,7 +198,7 @@ gflow CLI  →  Provider (interchangeable)  →  Flow (ui_automation) / Mock (te
 
 **Current transport:** `ui_automation` drives Flow through a persistent Playwright Chromium profile. It is production-stable and verified end-to-end every release (see the per-release `LIVE_VERIFICATION_*` evidence files).
 
-**Two Flow frontends:** Google is moving accounts from `labs.google` onto `flow.google.com` ([#639](https://github.com/ffroliva/gflow-cli/issues/639)) — same product, different widget toolkit and wire protocol (`batchexecute` instead of `aisandbox-pa`). `flow.google.com` is the default host for what gflow has ported to it — text-to-video, and image-to-video from a local start frame, today — on every account; the rest of the matrix keeps the labs driver until ported (`GFLOW_CLI_FLOW_HOST`, see [CONFIGURATION](docs/CONFIGURATION.md#gflow_cli_flow_host)).
+**Two Flow frontends:** Google is moving accounts from `labs.google` onto `flow.google.com` ([#639](https://github.com/ffroliva/gflow-cli/issues/639)) — same product, different widget toolkit and wire protocol (`batchexecute` instead of `aisandbox-pa`). `flow.google.com` is the default host for what gflow has ported to it — text-to-video, image-to-video from a local start frame, and reference-to-video from local `--ref` files, today — on every account; the rest of the matrix keeps the labs driver until ported (`GFLOW_CLI_FLOW_HOST`, see [CONFIGURATION](docs/CONFIGURATION.md#gflow_cli_flow_host)).
 
 **What's blocked:** a pure HTTP transport for video generation. The video upload endpoint returns HTTP 401 under non-Chrome browsers plus a reCAPTCHA mint we cannot reproduce headlessly. Three earlier HTTP strategies (`evaluate_fetch`, `bearer`, `sapisidhash`) live under `src/gflow_cli/api/transports/experimental/` for research, off the production path.
 

{gflow_cli-0.71.0 → gflow_cli-0.71.1}/README.md

@@ -127,7 +127,7 @@ gflow CLI  →  Provider (interchangeable)  →  Flow (ui_automation) / Mock (te
 
 **Current transport:** `ui_automation` drives Flow through a persistent Playwright Chromium profile. It is production-stable and verified end-to-end every release (see the per-release `LIVE_VERIFICATION_*` evidence files).
 
-**Two Flow frontends:** Google is moving accounts from `labs.google` onto `flow.google.com` ([#639](https://github.com/ffroliva/gflow-cli/issues/639)) — same product, different widget toolkit and wire protocol (`batchexecute` instead of `aisandbox-pa`). `flow.google.com` is the default host for what gflow has ported to it — text-to-video, and image-to-video from a local start frame, today — on every account; the rest of the matrix keeps the labs driver until ported (`GFLOW_CLI_FLOW_HOST`, see [CONFIGURATION](docs/CONFIGURATION.md#gflow_cli_flow_host)).
+**Two Flow frontends:** Google is moving accounts from `labs.google` onto `flow.google.com` ([#639](https://github.com/ffroliva/gflow-cli/issues/639)) — same product, different widget toolkit and wire protocol (`batchexecute` instead of `aisandbox-pa`). `flow.google.com` is the default host for what gflow has ported to it — text-to-video, image-to-video from a local start frame, and reference-to-video from local `--ref` files, today — on every account; the rest of the matrix keeps the labs driver until ported (`GFLOW_CLI_FLOW_HOST`, see [CONFIGURATION](docs/CONFIGURATION.md#gflow_cli_flow_host)).
 
 **What's blocked:** a pure HTTP transport for video generation. The video upload endpoint returns HTTP 401 under non-Chrome browsers plus a reCAPTCHA mint we cannot reproduce headlessly. Three earlier HTTP strategies (`evaluate_fetch`, `bearer`, `sapisidhash`) live under `src/gflow_cli/api/transports/experimental/` for research, off the production path.
 

{gflow_cli-0.71.0 → gflow_cli-0.71.1}/docs/ARCHITECTURE.md

@@ -436,7 +436,7 @@ We attempted three pure-HTTP transport strategies before settling on `ui_automat
 
 All three now live as standalone modules under `src/gflow_cli/api/transports/experimental/` (`evaluate_fetch.py` / `bearer.py` / `sapisidhash.py`), preserved for reference and future iteration. None survives Google's anti-bot stack for mutation/generation endpoints, so the production path is `ui_automation`.
 
-**The migrated `flow.google.com` host (#639, v0.67.0).** Google is moving accounts off `labs.google` onto `flow.google.com`, a rewritten frontend with a different widget toolkit and a `batchexecute` wire instead of `aisandbox-pa` REST. `src/gflow_cli/api/transports/migrated_composer.py` drives that editor for text-to-video and for image-to-video from a local start frame — still through the same real-Chrome Playwright session — by operating the composer UI and then *observing* the app's own `batchexecute` replies (`YhhmEf`/`eb1hJf` submit, `jwpduf` status, `as29s` result) before downloading the clip. A start frame goes in through the editor's own Upload entry (the app's `maseQ` reply names the media id — `migrated.frame_uploaded`), is bound in the Frames picker by file name (`migrated.frame_bound`), and the submit *request* is inspected for that id and an i2v model key before the run is trusted (`WireFormatError` otherwise); a modal over a fresh editor is closed first (`migrated.dialog_dismissed`). `GFLOW_CLI_FLOW_HOST` routes between the two (`auto` = migrated host for every request it can serve, `--project` required there); the rest of the command matrix keeps `ui_automation` on unmoved accounts and exits 36 on moved ones. Recon: `docs/superpowers/spikes/2026-09-05-migrated-host-wire-protocol.md`.
+**The migrated `flow.google.com` host (#639, v0.67.0).** Google is moving accounts off `labs.google` onto `flow.google.com`, a rewritten frontend with a different widget toolkit and a `batchexecute` wire instead of `aisandbox-pa` REST. `src/gflow_cli/api/transports/migrated_composer.py` drives that editor for text-to-video, image-to-video from a local start frame, and reference-to-video from local `--ref` files (v0.70.0) — still through the same real-Chrome Playwright session — by operating the composer UI and then *observing* the app's own `batchexecute` replies (`YhhmEf`/`eb1hJf` submit, `jwpduf` status, `as29s` result) before downloading the clip. A start frame goes in through the editor's own Upload entry (the app's `maseQ` reply names the media id — `migrated.frame_uploaded`), is bound in the Frames picker by file name (`migrated.frame_bound`), and the submit *request* is inspected for that id and an i2v model key before the run is trusted (`WireFormatError` otherwise); a modal over a fresh editor is closed first (`migrated.dialog_dismissed`). `GFLOW_CLI_FLOW_HOST` routes between the two (`auto` = migrated host for every request it can serve, `--project` required there); the rest of the command matrix keeps `ui_automation` on unmoved accounts and exits 36 on moved ones. Recon: `docs/superpowers/spikes/2026-09-05-migrated-host-wire-protocol.md`.
 
 **Standalone-only transports.** `bearer` and `sapisidhash` discard any caller-supplied Playwright page and launch their own browser under a fresh `ProfileLease`, so they are **standalone-only** — they cannot run inside a `FlowApiClient` that already holds the profile lease (the second acquire would self-lock with `ProfileLockedError`). Selecting either via `GFLOW_CLI_TRANSPORT` (or the Python API) while the client owns the profile now fails fast with a clear `ConfigurationError` naming the transport, rather than the opaque lock error. `evaluate_fetch` is exempt: it reuses the client's shared page and takes no second lease. The standalone-only set lives in `STANDALONE_ONLY_TRANSPORTS` (`api/transports/__init__.py`); to drive `bearer`/`sapisidhash`, run them outside an owning client.
 

{gflow_cli-0.71.0 → gflow_cli-0.71.1}/docs/INDEX.md

@@ -149,7 +149,7 @@ Slash commands for Claude Code, stored in `.claude/commands/gflow/`. All prefixe
 **"How do I upgrade gflow-cli?"** → [USAGE § `gflow update`](USAGE.md#gflow-update) (`gflow update` runs the installer that put it here — uv tool / pipx / pip; `--check` only reports; source installs are refused with exit 11)
 **"How do I run the MCP server so an agent can't spend credits?"** → [CONFIGURATION § GFLOW_MCP_NO_SPEND](CONFIGURATION.md#gflow_mcp_no_spend) + [MCP § Option A2](MCP.md#option-a2-read-only-server) (`gflow mcp run --no-spend` / `GFLOW_MCP_NO_SPEND=1`; v0.57.0 — both generate tools go unregistered, not merely refused)
 **"Which Flow UI arm does a run require, and why did it exit 2 or 28?"** → [CONFIGURATION § GFLOW_CLI_UI_MODE](CONFIGURATION.md#gflow_cli_ui_mode) (`auto` ≡ `classic` for **both** images and video — video since v0.57.0/#299, images since #595; unreachable classic aborts pre-submit with exit 28, $0; explicit `agentic` on video exits 2)
-**"Which Flow frontend does a run drive — labs.google or the migrated flow.google.com — and why did it exit 36 or 11?"** → [CONFIGURATION § GFLOW_CLI_FLOW_HOST](CONFIGURATION.md#gflow_cli_flow_host) (`auto` = flow.google.com for every request it can serve — `t2v`, `i2v` from a local `--initial-frame`, and `r2v` from local `--ref` files, with `--project`, on moved and unmoved accounts; `flow.google.com` forces it; `labs.google` is the kill switch. On a moved account an end frame, a UUID/`@Name` frame, references by `@Name`/`--reference-entity` and everything except `t2v`/`i2v`/`r2v` exit 36, non-retryable, and a missing `--project` exits 11) · recon: [character surface + reCAPTCHA mint](superpowers/spikes/2026-09-06-migrated-character-surface-and-recaptcha.md), [migrated-host wire protocol](superpowers/spikes/2026-09-05-migrated-host-wire-protocol.md), [handoff mechanism](superpowers/spikes/2026-09-04-migrated-host-handoff-mechanism.md), [frames attach (i2v)](superpowers/spikes/2026-09-05-migrated-frames-attach.md) · evidence: [LIVE_VERIFICATION_v0.67.0](LIVE_VERIFICATION_v0.67.0.md) (t2v), [LIVE_VERIFICATION_v0.69.0](LIVE_VERIFICATION_v0.69.0.md) (i2v from a local start frame, v0.69.0), [LIVE_VERIFICATION_v0.70.0](LIVE_VERIFICATION_v0.70.0.md) (r2v on the migrated host; character create verified there in #703)
+**"Which Flow frontend does a run drive — labs.google or the migrated flow.google.com — and why did it exit 36 or 11?"** → [CONFIGURATION § GFLOW_CLI_FLOW_HOST](CONFIGURATION.md#gflow_cli_flow_host) (`auto` = flow.google.com for every request it can serve — `t2v`, `i2v` from a local `--initial-frame`, and `r2v` from local `--ref` files, with `--project`, on moved and unmoved accounts; `flow.google.com` forces it; `labs.google` is the kill switch. On a moved account an end frame, a UUID/`@Name` frame, references by `@Name`/`--reference-entity` and everything except `t2v`/`i2v`/`r2v` exit 36, non-retryable, and a missing `--project` exits 11) · recon: [character surface + reCAPTCHA mint](superpowers/spikes/2026-09-06-migrated-character-surface-and-recaptcha.md), [migrated-host wire protocol](superpowers/spikes/2026-09-05-migrated-host-wire-protocol.md), [handoff mechanism](superpowers/spikes/2026-09-04-migrated-host-handoff-mechanism.md), [agent mode hides the settings trigger](superpowers/spikes/2026-09-08-migrated-composer-agent-mode-hides-settings.md), [frames attach (i2v)](superpowers/spikes/2026-09-05-migrated-frames-attach.md) · evidence: [LIVE_VERIFICATION_v0.67.0](LIVE_VERIFICATION_v0.67.0.md) (t2v), [LIVE_VERIFICATION_v0.69.0](LIVE_VERIFICATION_v0.69.0.md) (i2v from a local start frame, v0.69.0), [LIVE_VERIFICATION_v0.70.0](LIVE_VERIFICATION_v0.70.0.md) (r2v on the migrated host; character create verified there in #703)
 **"Will this get my Google account flagged or banned? What protects me?"** → [ACCOUNT_SAFETY.md](ACCOUNT_SAFETY.md) — the operational answer in one place: rate limit vs WAF block vs ban (they are different), what the tool does to stay unremarkable (headed real Chrome, ±25% interaction jitter, 0.5–1.5 s submission pacing, one project per run, isolated profiles, refuse-don't-retry), what it deliberately does **not** do (no proxies, no fingerprint spoofing, no headless unlock), the knobs, the [#241](https://github.com/ffroliva/gflow-cli/issues/241) field data on what actually triggers a 403, and what we cannot promise. Legal statement: [DISCLAIMER](../DISCLAIMER.md)
 
 **"I got a 403 / `PUBLIC_ERROR_UNUSUAL_ACTIVITY` — what now?"** → [ACCOUNT_SAFETY § When Google does push back](ACCOUNT_SAFETY.md#when-google-does-push-back) (stop, cool down 30–60 min, use real Chrome meanwhile, switch profile, widen jitter); cadence evidence in [DEBUGGING § WAF cadence](DEBUGGING.md#waf-cadence); full entry in [KNOWN_ISSUES](../KNOWN_ISSUES.md)
@@ -158,7 +158,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.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.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.71.0 → gflow_cli-0.71.1}/docs/LIVE_VERIFICATION_v0.71.0.md

@@ -5,8 +5,17 @@
 > Flow for this release, and — just as importantly — what was **not**.
 
 **Date:** 2026-09-07 · **Profiles:** `ffroliva` (migrated `flow.google.com`, 501→ credits),
-`ci-probe` (labs, freemium, **no credit**) · **Host lane matters here**: several items below
-are migrated-host-specific.
+`ci-probe` (**migrated `flow.google.com`**, freemium, **no credit**) · **Host lane matters
+here**: several items below are migrated-host-specific.
+
+> **Host label corrected 2026-09-08.** This line said `ci-probe` was on **labs**, which
+> contradicted [LIVE_VERIFICATION_v0.70.0](LIVE_VERIFICATION_v0.70.0.md) one day earlier and
+> was wrong. Measured: `labs.google/fx/tools/flow` on that profile redirects to
+> `flow.google.com/` — the one-way migration redirect. In a repo where "Flow's UI shows X"
+> is not a fact until the host is named, a mislabelled host in a verification ledger
+> silently re-scopes every conclusion keyed to it — and this one helped make a credit
+> theory look plausible for #719 when the real cause was a one-time consent dialog
+> ([spike](superpowers/spikes/2026-09-08-migrated-upload-fails-two-ways.md)).
 
 ---
 

gflow_cli-0.71.1/docs/LIVE_VERIFICATION_v0.71.1.md

@@ -0,0 +1,147 @@
+# Live verification — v0.71.1
+
+> What was exercised against **real** Flow for this release, and — just as importantly —
+> what was **not**.
+
+**Date:** 2026-09-08 · **Profiles:** `ffroliva` (migrated `flow.google.com`, funded),
+`denon82` (migrated), `ci-probe` (migrated, non-paying, no credit) · **Cost: $0** — every run
+below stops before a submit; no Veo credit is reachable from any of them.
+
+> **Host note.** All three profiles are on the migrated host. `LIVE_VERIFICATION_v0.71.0`
+> said `ci-probe` was on **labs**; that was wrong and is corrected in this release. Measured:
+> `labs.google/fx/tools/flow` on that profile redirects to `flow.google.com/` — the one-way
+> migration redirect.
+
+---
+
+## 1. Agent-mode recovery names which of three things happened — VERIFIED ✅
+
+`pytest -m e2e -k agent_mode tests/e2e/test_migrated_host_e2e.py`, profile `ffroliva`,
+project `300f5260-…`. `e2e_auth`, $0. **Run twice** — once before the review fixes and again
+after, because the first run no longer covered the changed code.
+
+The test carries its own A/B control: it drives the account **into** agent mode through the
+chip a user would click, then neuters `AGENT_MODE_CHIP` so the recovery cannot fire.
+
+```
+15:20:56  migrated.navigate          flow.google.com/project/300f5260-…
+15:20:58  migrated.editor_ready                       <- healthy start
+             (test clicks the chip INTO agent mode; READY_ANCHOR goes hidden)
+             control arm  -> UiSelectorDriftError "did not become visible"
+15:21:53  migrated.agent_mode_exited  issue_ref=#749  <- fix arm
+15:21:53  migrated.editor_ready                       <- classic composer back
+1 passed in 104.93s
+```
+
+Five layers:
+
+1. **Control discriminates.** The neutered arm raised `did not become visible` — the
+   *ordinary drift* branch — not an agent-mode message. Pinned with `match=` this release, so
+   it can no longer pass on any drift, including one raised by the recovery firing wrongly.
+2. **Recovery fired.** `migrated.agent_mode_exited` present, once.
+3. **State restored.** `READY_ANCHOR` visible again, asserted after the fix arm.
+4. **No false positive on the happy path.** Neither `editor_ready` logged the new
+   `migrated.agent_mode_chip_pressed_while_ready` warning — the expected negative,
+   confirming the live account does hide the trigger in agent mode as measured.
+5. **Account left clean.** The test now restores agent mode in a `finally`; the chip was
+   `aria-pressed='false'` afterwards, so no later run inherits the state.
+
+## 2. The one-time upload-terms dialog — VERIFIED ✅, and unrepeatable hereafter
+
+Probe: `scripts/dev/spike_migrated_upload_wire.py`, which drives the **real**
+`_upload_via_toolbar` rather than a re-implementation, with a listener on every request.
+Finding: [`no maseQ reply` is two different bugs](superpowers/spikes/2026-09-08-migrated-upload-fails-two-ways.md).
+
+**The order was forced.** The dialog is one-off per account, so accepting it destroys the
+failing state permanently. The guard was written and verified against the live dialog
+**before** anything was clicked; the account owner then authorised the click explicitly.
+
+| # | Run on `ci-probe` | Result |
+|---|---|---|
+| 1–3 | pre-fix upload | `no maseQ reply within 60s` — the misleading message |
+| 4 | upload **with the guard** | a dialog opened during the upload window was named instead of the file being blamed |
+| 5 | the spike's `--accept-terms` (off by default) → click → retry, same session | **`media_id 8914400f-2c3c-41da-84a9-2e26a356d24e`** |
+| 6 | plain upload, fresh session | **uploaded, `dialog: None`, 4 POSTs** |
+
+Five layers:
+
+1. **The dialog is the blocker.** Run 4 named it while it was still on screen, from a live
+   DOM read: *"Rights to use this image — Make sure you have the necessary rights to any
+   content or files that you upload…"*.
+
+   > **Wording note.** Run 4 predates the review pass and emitted *"…no maseQ request was
+   > ever sent — Flow is holding the upload behind its one-time upload-terms confirmation"*.
+   > The shipped build hedges that claim, because a dialog count is evidence for a guess and
+   > not a fact, and it now observes the request rather than inferring it:
+   > *"a dialog opened after the file was chosen and no maseQ request left the page — most
+   > likely Flow's one-time upload-terms confirmation (host=migrated)"*. The behaviour under
+   > test is identical; only the sentence changed.
+2. **Accepting unlocks the upload.** Run 5 returned a real media id, immediately, in the same
+   session, on the account that had failed 3/3.
+3. **It never returns.** Run 6, fresh browser session, `dialog: None` and a healthy 4-POST
+   window — versus the 2-POST window of a blocked run.
+4. **The wire agrees.** `maseQ` POST observed leaving the page on every successful run and on
+   **none** of runs 1–4; `saw_expected_rpc` false throughout the blocked state.
+5. **Cross-account control.** `ffroliva` and `denon82`, which had uploaded before, never saw
+   the dialog and uploaded the same 4 321-byte 1280×720 PNG successfully — so the variable is
+   consent, not the file, not credits, and not the rpcid.
+
+> **Not repeatable from here.** All three available accounts have now accepted the dialog.
+> Re-verifying the guard's *firing* branch needs a Google account that has never uploaded on
+> `flow.google.com`. That is a named external blocker, not a skipped step; the guard's
+> non-firing branch — where the regression risk actually lives — is covered offline by a
+> control test and by the existing `e2e_video` i2v/r2v paths.
+
+## 3. `maseQ` is not renamed — VERIFIED ✅
+
+Six successful uploads across three profiles, each a `maseQ` POST → HTTP 200 → a media id the
+driver bound (`8b3ff931`, `d1c80c09`, `423176b3`, `8914400f`, `8787e007`, …). The 2026-09-05
+capture that established the rpcid still holds. This mattered because a renamed rpcid was
+#719's top-ranked hypothesis and the only one a constant change would have fixed.
+
+## 4. Flow's queue is readable at $0 — VERIFIED ✅ (instrument only)
+
+`scripts/dev/spike_migrated_queue_read.py`, `ffroliva`, project `c5550ed7-…`, two runs ten
+minutes apart with identical results, and a third ~20 h later.
+
+- **69 records, all on `Zzl0ze`.** An idle project load shows 15 distinct rpcids and
+  `jwpduf`/`as29s` are among **none** — those are progress polls, seen only because the driver
+  only ever watches a page mid-generation.
+- **Two record shapes.** Length 8 is a video generation with the model arm at `[7][0]`;
+  length 7 is an image with no status and no model. Read with one shape, all 34 images report
+  `status: null`, indistinguishable from a failed generation.
+- **Two `abra_r2v_8s` records sat at status 6 (`submitted`)** with no media URL, and were
+  **still** `submitted` when re-read ~20 h later, while a later run on the same project
+  reached status 3.
+
+Finding: [the migrated queue is readable on `Zzl0ze`](superpowers/spikes/2026-09-08-migrated-queue-is-readable-on-zzl0ze.md).
+
+This ships as an instrument only; no user-facing command reads the queue yet (#741).
+
+---
+
+## Recorded as NOT verified
+
+- **#719's second failure shape.** On a funded, already-consented account, ~1 upload in 4
+  sends the `maseQ` request (8 675 B) and never receives a reply, with the entire project-load
+  rpcid inventory firing 2.6 s later (24 POSTs versus 4 on a healthy run). Unfixed, unexplained,
+  and #719 stays open for it. This release only makes it *distinguishable*: the driver now
+  watches the request, so this reports *"the request left the page and Flow did not answer in
+  time"* rather than sharing a message with the consent case.
+- **Whether that 2.6 s burst is a page reload** ([#719](https://github.com/ffroliva/gflow-cli/issues/719)).
+  It has the shape of one — the full project-load rpcid set, at once — but no navigation event
+  was captured and nothing in `_upload_via_toolbar` navigates. **Blocker:** the shape occurs on
+  ~1 run in 4, so catching it with navigation instrumentation attached needs repeated paid-path
+  runs on a consented account; the instrument to do it is in the repo
+  (`scripts/dev/spike_migrated_upload_wire.py`).
+- **The labs.google behaviour of either fix** ([#639](https://github.com/ffroliva/gflow-cli/issues/639)).
+  Neither the agent-mode chip nor the upload-terms dialog was observed on labs.
+  **Blocker:** Google has migrated every account available here — `ffroliva`, `denon82` and
+  `ci-probe` all redirect from `labs.google/fx/tools/flow` to `flow.google.com/` — so there is
+  no labs cohort to test against. Both fixes are scoped to `migrated_composer` and cannot
+  affect the labs driver.
+- **`gflow image` / scenes / extend / instructions on the migrated host**
+  ([#639](https://github.com/ffroliva/gflow-cli/issues/639)). Untouched by this release and
+  still exit 36. **Blocker:** not implemented rather than unverifiable — PR #750 addresses the
+  image half and was excluded from this release because it is branched pre-#751 and conflicts
+  across six files.