gflow-cli 0.96.0__tar.gz → 0.96.1__tar.gz

{gflow_cli-0.96.0 → gflow_cli-0.96.1}/.codex-plugin/plugin.json

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

{gflow_cli-0.96.0 → gflow_cli-0.96.1}/CHANGELOG.md

@@ -7,6 +7,22 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.96.1] — 2026-11-08
+
+### Fixed
+
+- **Omni 1.2 Flash start+end (`video i2v --model omni-1.2-flash --end-frame`) runs instead of
+  exiting 7.** Its submit carries a `*_i2v_fl_*` model key that gflow's start+end check did not
+  know, so a valid run was refused after Flow had already billed it (#1178, by @Eighty20Digital).
+- **A video submit gflow refuses is stopped before it leaves the browser, so it is not billed.**
+  The check used to watch requests already on their way to Flow; it now runs as a route guard
+  that aborts a wrong start+end, start-only or reference submit unsent, and the error says
+  nothing was billed (#1178).
+- **An Omni 1.2 end frame above 10 seconds is refused before any upload** (exit 2 on the CLI, a
+  bad-parameter error over MCP). Flow drops the end frame there and bills a start-only clip,
+  as measured by the reporter at 12s and 15s on a Google AI plan; start-only Omni 1.2 keeps
+  3–15s (#1178).
+
 ## [0.96.0] — 2026-11-07
 
 ### Added
@@ -6888,7 +6904,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.96.0...HEAD
+[Unreleased]: https://github.com/ffroliva/gflow-cli/compare/v0.96.1...HEAD
+[0.96.1]: https://github.com/ffroliva/gflow-cli/compare/v0.96.0...v0.96.1
 [0.96.0]: https://github.com/ffroliva/gflow-cli/compare/v0.95.0...v0.96.0
 [0.95.0]: https://github.com/ffroliva/gflow-cli/compare/v0.94.0...v0.95.0
 [0.94.0]: https://github.com/ffroliva/gflow-cli/compare/v0.93.0...v0.94.0

{gflow_cli-0.96.0 → gflow_cli-0.96.1}/KNOWN_ISSUES.md

@@ -428,7 +428,8 @@ Upgrade first (`gflow update`). The locale refutation below applies to the Portu
 labs cohort it was measured on.
 
 **What actually happens today.** gflow accepts `--duration 4`, `6` or `8` on the
-Veo 3.1 models, `10` on `omni-flash`, and every integer 3–15 on `omni-1.2-flash` — the CLI no longer refuses a
+Veo 3.1 models, `10` on `omni-flash`, and every integer 3–15 on `omni-1.2-flash` (at most `10`
+with an end frame, #1178) — the CLI no longer refuses a
 duration it cannot know your account supports. What it still cannot do is tell
 your cohort apart before opening the browser, so on an account that renders no
 duration row the run reaches Flow's settings popover and fails there — on the

{gflow_cli-0.96.0 → gflow_cli-0.96.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: gflow-cli
-Version: 0.96.0
+Version: 0.96.1
 Summary: CLI and MCP server for Google Flow — drive Veo text-to-video, image-to-video and Imagen image generation from the terminal.
 Project-URL: Homepage, https://github.com/ffroliva/gflow-cli
 Project-URL: Documentation, https://ffroliva.github.io/gflow-cli/

{gflow_cli-0.96.0 → gflow_cli-0.96.1}/docker/Dockerfile

@@ -45,7 +45,7 @@ RUN apt-get update && apt-get install -y --no-install-recommends \
 # Deliberately NOT pinned: google-chrome-stable. Chrome's apt repo keeps only the current
 # build, so a pinned version stops resolving within weeks. The trade-off is that this
 # layer caches indefinitely and a rebuild is what picks up a newer Chrome.
-ARG GFLOW_VERSION=0.96.0
+ARG GFLOW_VERSION=0.96.1
 RUN pip install --no-cache-dir "gflow-cli==${GFLOW_VERSION}"
 
 VOLUME ["/data"]

{gflow_cli-0.96.0 → gflow_cli-0.96.1}/docs/INDEX.md

@@ -173,7 +173,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.96.0](LIVE_VERIFICATION_v0.96.0.md) (**2026-11-07, 1 Veo lite clip on the release tree.** t2v; Omni 1.2 durations 3–15 and its MCP twin; Omni r2v 4/6/10s; agent-only reload on CLI and MCP; paid Omni clips on the PR #1174 head.) Previous: [LIVE_VERIFICATION_v0.95.0](LIVE_VERIFICATION_v0.95.0.md) (**2026-11-07, 1 Veo lite clip.** t2v on the release tree; weekly upload e2e against the live endpoint 8/8 incl. EU consent and 410; local telemetry e2e 6/6; production D1 left at 0 rows; byte-exact `mcp setup` backup.) Previous: [LIVE_VERIFICATION_v0.94.0](LIVE_VERIFICATION_v0.94.0.md) (**2026-11-07, 1 Veo lite clip.** t2v on the release tree, local usage counters and telemetry e2e, CLI and MCP usage stats.) Previous: [LIVE_VERIFICATION_v0.93.0](LIVE_VERIFICATION_v0.93.0.md) (**2026-11-05, 82 Veo credits over the session.** Video delivery after #1153, lost t2v reply on CLI and MCP, revoked session.) Previous: [LIVE_VERIFICATION_v0.92.1](LIVE_VERIFICATION_v0.92.1.md) (**2026-10-30, $0.** MCP schema, #1121.). Previous: [LIVE_VERIFICATION_v0.92.0](LIVE_VERIFICATION_v0.92.0.md) (**2026-10-29, no Veo credits.** GHSA-hqfj-4jww-76f2: MCP `output` / `out_dir` / `profile` escapes refused live on the release head, an inside `output` lands; MCP upscale e2e and the #1035 BDD re-run 3/3. #1114 measured on real mounts, Linux and Windows) · previous: [LIVE_VERIFICATION_v0.91.0](LIVE_VERIFICATION_v0.91.0.md) (**2026-10-26/28.** Release-tree e2e 7/7: #1097 MCP `wait=false` runs and #1102 SEP-2663 `tasks/get` over stdio; selector drift; auth verification. Paid on their PRs: #723 r2v with a character 3/3, #1112 lost video submit reply 2/2. #988 blocked: no profile here is served the agent-only composer) · previous: [LIVE_VERIFICATION_v0.90.0](LIVE_VERIFICATION_v0.90.0.md) (**2026-10-25, no Veo credits in the release run.** Release-tree e2e 15/15: #772 a local `--ref` uploaded once per project (CLI, MCP, and a recorded image the project no longer holds); #1091 unwritable output exit 11; #934 `run --resume`; #745 credit shortfall; #1083 selector drift; the two re-armed canary tests; #796 and #481 verified at $0 on their PRs; #941 on its PR with one veo-lite clip) · previous: [LIVE_VERIFICATION_v0.89.1](LIVE_VERIFICATION_v0.89.1.md) (**2026-10-24, no Veo credits.** Release-tree e2e 9 passed, 1 skipped (credit-spending video case): lost image replies recovered from the grid on t2i and i2i (#1075), upscale straight after generating with no pause (#1067), visible model picker, auth and pre-submit regressions; hidden-picker, `/about` and declined-upload paths offline, blockers named) · previous: [LIVE_VERIFICATION_v0.89.0](LIVE_VERIFICATION_v0.89.0.md) (**2026-10-23, no Veo credits.** Release-tree e2e 20/20 (one re-run after #1010's lost reply body): #1039 default project CLI+MCP; #974/#1053 a missing project is exit 11 on generation, upscale and extend; #1038 nano2.1; #914 warm-client upscale; #892 pre-submit gate; #927 window position; #984/#1059 held profile exit 11 on the PR branches) · previous: [LIVE_VERIFICATION_v0.88.0](LIVE_VERIFICATION_v0.88.0.md) (**2026-10-22, no Veo credits.** #1036 browser proxy through a local proxy; #1037 slow-link create; #992 lost-reply readback; #1035 failed image download keeps the ids; #1041 quiet output; #1026 internal login) · previous: [LIVE_VERIFICATION_v0.87.1](LIVE_VERIFICATION_v0.87.1.md) (**2026-10-22, $0 apart from one Veo lite clip for the #795 spike.** #795: `gflow credits` balance equals Flow's account menu on two accounts, CLI and MCP; #1027: 2K image upscale and both video exports pass with the shared blob capture; project create/rename re-run for the shared `_rpc_reply`) · older: [LIVE_VERIFICATION_v0.87.0](LIVE_VERIFICATION_v0.87.0.md) (**2026-10-22, Veo lite clips under the e2e grant.** #1023: auth status/renew/MCP twin verify again after labs' session URL went 410; #1010: a lost submit reply makes one submit and a non-retryable exit 9, image and video; #1013, #995, #997, #986, #1014 e2e passed on the release tree; image-upscale body loss filed as #1027) · older: [LIVE_VERIFICATION_v0.86.0](LIVE_VERIFICATION_v0.86.0.md) (**2026-10-17/18, 2 Veo extends (owner-approved).** #991: `video extend` on flow.google.com — paid single-segment extend passed on the release tree, plus 3 $0 route-guard e2e; #989: agent-only composer — classic-composer regression 11 passed, agent-only path blocked externally (no account in that cohort; run live by 3 outside users); #982: `auth renew` 4 passed incl. stale→readable and /about) · previous: [LIVE_VERIFICATION_v0.85.0](LIVE_VERIFICATION_v0.85.0.md) (**2026-10-14, 0 credits.** #723/#979: `@Character` on flow.google.com images — 4-scenario e2e (CLI t2i, MCP, i2i + character, id-only refusal) passed on the release tree; #975: multi-prompt `t2i --project-name` — e2e passed) · previous: [LIVE_VERIFICATION_v0.84.0](LIVE_VERIFICATION_v0.84.0.md) (**2026-10-12, 0 credits.** #970: `gflow run --project` generates every row into an existing project — e2e passed on our account and the contributor's; #971: multi-prompt `t2i --project` — new e2e passed; no MCP twin for either) · previous: [LIVE_VERIFICATION_v0.83.2](LIVE_VERIFICATION_v0.83.2.md) (**2026-10-11, 0 credits.** #963: `--duration` binds in a Vietnamese pane — locale e2e failed on develop and passed after the fix, and a notice-only cookie bar is now acknowledged; #957: image upscale e2e passed on the CLI and over MCP; #962: `auth status` probe uses the profile's channel, unverified on a host without Chrome) · previous: [LIVE_VERIFICATION_v0.83.1](LIVE_VERIFICATION_v0.83.1.md) (**2026-10-08, 0 credits.** #958: the default image model `nano2` runs Nano Banana 2.1 on flow.google.com — e2e failed on develop and passed after the fix; CLI and MCP twins each wrote a JPEG; 2.1 measured as replacing 2 on two accounts) · previous: [LIVE_VERIFICATION_v0.83.0](LIVE_VERIFICATION_v0.83.0.md) (**2026-10-06/07.** #948: a billed flow.google.com video run no longer exits 7 — t2v, i2v and r2v e2e passed after the fix, reproduced before it; `data download` e2e 2 passed after a 302 regression was caught and fixed; #922: image and video upscale e2e passed, CLI and MCP image twins wrote the same JPEG, MCP video wrote 1920x1080, a 1080p export measured 0 credits) · previous: [LIVE_VERIFICATION_v0.82.1](LIVE_VERIFICATION_v0.82.1.md) (**2026-10-02.** A reCAPTCHA mint failure typed with a live-measured retry flag (#915, e2e 2 passed, $0); a busy catalog no longer fails a successful generation (#900, real SQLite, no Flow surface); a video's workflow id recorded (#898, 1 veo-lite clip)) · previous: [LIVE_VERIFICATION_v0.82.0](LIVE_VERIFICATION_v0.82.0.md) (**2026-10-01.** `"ref": "batch:N"` and local-file refs on `gflow run` verified by a BDD e2e on flow.google.com: in place, no re-upload, lineage recorded; 1 veo-lite clip for the #926 e2e) · previous: [LIVE_VERIFICATION_v0.81.0](LIVE_VERIFICATION_v0.81.0.md) (**2026-09-30, 3 veo-lite clips.** The off-screen generation browser (#923) measured unchanged for image and video, window placement read back from Chrome, focus-steal measured and documented; #919 verified at merge) · previous: [LIVE_VERIFICATION_v0.80.0](LIVE_VERIFICATION_v0.80.0.md) (**2026-09-29, 0 Veo credits.** `--resolution` 360p/720p proven by driving the real settings pane on `omni_flash` and refusing the credit-spending submit, on the CLI transport **and** the MCP twin; `nano2-lite` e2e 2 passed; #891 measured before/after — `gflow run` `[nano2, imagen4]` went from exit 1 `RecaptchaError` with a lost results table to exit 36 naming the model, plus 3 e2e (fresh, warm, MCP) with a spy asserting zero client mints; #896 `e2e_data` 2 passed, its failure path offline-only. Named blockers: rendered resolution (needs a billed clip), the `/about` re-check arm, labs-served accounts.) · previous: [LIVE_VERIFICATION_v0.79.1](LIVE_VERIFICATION_v0.79.1.md) (**the signed-media download survives a dropped connection, verified 2026-09-22 at $0.** All three download sites route through one new shared helper, and that helper was driven through a real Flow clip route and a real signed CDN transfer by `pytest -m e2e_data` — 2 passed in 20.74 s, `ftyp` magic, byte length equal to the size Flow reports, and **no `url=` on any log event**. The retry itself could not wait for an organic reset — 20/20 clean here against the reporter's 2-in-6 — so it was **measured against a real TCP RST with an A/B control**: with `max_retries` the transfer recovers on a second connection, with it disabled the identical fault kills the call, and three attempts at a 5 s timeout finish in 1.57 s rather than ~15 s, proving the backoff shares one budget. **Two sites are NOT live-verified and name their blockers:** the composer call site needs a billed generation and `gflow credits` answers 401 on this account (#795), so no credits were spent; and the labs download cannot be reached at all from here (HTTP 308, 6/6 profiles). Offline: 21 new tests, full sweep 2143 passed.) · earlier: [LIVE_VERIFICATION_v0.79.0](LIVE_VERIFICATION_v0.79.0.md) (**the migrated host stops echoing a model it never observed, verified 2026-09-18 at $0.** `model_name_type` is `null` on `flow.google.com` in a real `image t2i --json`, with every sibling field populated — which is what makes the null a result rather than an empty envelope; the first read of it was flat rather than into `images[]` and returned `None` for everything, and that instrument error was discarded rather than reported. Both surfaces ran: `test_e2e_t2i_runs_on_a_moved_account` and `test_e2e_mcp_i2i_runs_on_the_migrated_host`, 2 passed in 86 s. **`gflow data download` was tested on an image and failed** — 45 s, then a message blaming the project, the trash and your prompt; recovery is video-only and the release notes now say so (#877). **#803 is NOT live-verified and names its blocker:** reaching those raise sites needs a non-JSON or token-less aisandbox reply, and the labs route refuses first with a 404 — itself a misleading error, filed as #875. Offline: 4 new unit tests, 1775 passed.) · previous: [LIVE_VERIFICATION_v0.78.0](LIVE_VERIFICATION_v0.78.0.md) (**generating with no project on `flow.google.com` — and video from a start frame — verified 2026-09-17.** The release exists because labs.google's `project.createProject` is retired — 404 *"Flow RPCs have been deprecated and disabled"* with a labs token, 401 without, 0 successes in 12 across four profiles — and gflow reported the 401 as an expired login. Creation and rename are driven on flow.google.com and read back from Flow's own `jHPbke` / `o8DA4` replies; the CLI and the MCP twin are each exercised separately, and both video paths reach a real submit that is aborted before Flow can bill it. Two failures are recorded and re-tested rather than explained away — one MCP image reply that did not reproduce under a four-run A/B, and a Chrome launch starved by a concurrent coverage run that passed in 36 s alone. The 3:4 image aspect is re-measured on the live radiogroup, five radios where 2026-09-08 saw four. Three items are NOT verified and each names its blocker: no labs-served account, no entitled `/about` account, no non-`en` locale. **#860 is the one thing here that cost credits, deliberately:** the only proof that a start frame binds is a real generation, so ten i2v clips were generated and downloaded on a live migrated account — `migrated.frame_uploaded` → `frame_bound` → `submit_observed` → `download`, the middle event being the one that could not fire before this release. **#859 is recorded as UNOBSERVED, not verified** — its dismissal ran on every one of those runs and no promo modal ever appeared, so the $0 route-intercepted e2e is what covers it. `gflow docs` (#861) is verified from the built wheel, which is its whole contract: 127 topics, `docs/FILE.md:LINE` search hits, no network and no checkout.) · previous: [LIVE_VERIFICATION_v0.77.1](LIVE_VERIFICATION_v0.77.1.md) (**a four-fix patch release, verified 2026-09-17 at ZERO cost.** The headline is #846: the published package could not run a single interactive command on a clean Windows install, because `ConsoleRenderer(colors=True)` needs `colorama` and nothing declared it. Verified as a controlled A/B on a fresh Python 3.13 venv — `SystemError` before, exit 33 after — plus an arm with stderr piped that shows why the AUTO/JSON split hid this from every CI job, and the MCP twin run separately. #848's import probe is exercised against a **deliberately broken venv** and an intact one, including the contract that a probe which cannot run reports nothing rather than reporting breakage. #852 is re-measured on the release head: 40 000 base64-shaped chars fall from 12.07 s to 0.020 ms with identical output on Workspace and custom domains. **#849 is a NAMED BLOCKER, not an omission** — its end-to-end behaviour needs a fresh interactive Google sign-in, which no agent can perform; its live A/B is recorded on PR #851 and its e2e file re-ran 4/4 here. **Seven live e2e failures are recorded rather than hidden**, and controlled: the release changes exactly four source files and none of them is a failing test's module.) · previous: [LIVE_VERIFICATION_v0.77.0](LIVE_VERIFICATION_v0.77.0.md) (**the migrated-host login lockout (#791), verified as a controlled A/B on a real Google **Workspace** account at ZERO cost — same profile, same cookies untouched between arms, so the only variable is the code: exit 8 with the Chrome marker rolled back and `channel_for_profile` collapsed to `None`, then exit 0 with the marker intact and the account recorded. The refusal path is measured too — of 10 local profiles, 5 reproduce #791 and exactly one carries both required cookies: 4 refusals, 1 upgrade, 0 false positives. v0.76.0 recorded this fix as **withdrawn**; the approach that shipped is a different one, server-attested on the landing URL rather than on client-rendered DOM. An earlier revision gated auth on an `@gmail.com`-only pattern that silently declined every custom domain — the account used here is one, which is why this is its verification. **#796 is reproduced and prevented**, not merely reported: it was filed as *'not yet reproduced end-to-end'*. **Two rows are named blockers, not omissions:** the MCP Registry publish (#841) cannot be rehearsed before a real tag push, so this release is its first exercise; and the migrated-host generation e2e cannot run here at all — every account bounces to `/about`, A/B-controlled against `develop` so it is not mistaken for a regression.) · previous: [LIVE_VERIFICATION_v0.76.0](LIVE_VERIFICATION_v0.76.0.md) (**a diagnostics-and-distribution release, verified 2026-09-16 at ZERO cost — no Veo credits, no image generation, no Flow submit.** The decisive arm is #833's **negative** control, run first-hand on two real accounts rather than relayed: `flow-pinhole-unavailable-screen` is **0** on both `ffroliva` and `denon82` while `aisandbox-root` is **1**, so the guard does not fire on accounts that HAVE Flow access and the zero is a real absence rather than a page that never booted — a guard with only a positive arm is indistinguishable from one that is permanently on. Both accounts settled at **`/about`**, which is the state that broke this release's *withdrawn* #791 oracle, and the exit-39 signal reads a component that only exists on the unavailable screen, so `/about` cannot mimic it. mcpservers.org is verified with a **404 negative control** because the listing 403s to `curl` and a naive check would have called the link dead. **#791 is NOT in this release and was withdrawn rather than deferred**: a fix passed eight council dimensions and was then refuted by a five-day-old spike nobody had routed to it — Flow's `/about` hop is decided client-side with zero requests to Flow, and *"the backend grants access while the frontend declines to open it"* (#756), so the probe would have reported authenticated users as logged out, reintroducing #791 as its own cure; the e2e caught it by going red on a live account whose state moved mid-session. **Two rows are blocked by the platform rather than by effort:** the Docker sign-in needs a WSL-integrated Docker host, and the MCP Registry publish cannot be observed until this very tag reaches `main`, since both triggers resolve the workflow from the default branch.) · previous: [LIVE_VERIFICATION_v0.75.0](LIVE_VERIFICATION_v0.75.0.md) (**a distribution-and-hardening release, verified 2026-09-15 on `ffroliva` at ZERO cost — no Veo credits, no image generation, no Flow submit.** The `gflow serve` token fix is an **A/B against the released 0.74.0 wheel from PyPI**, not a diff read: the token was *set* in both arms, so the probe measures whether it is checked — before, `no token 200/200` with 13 tools listed and `wrong 200/200`; after, `401/401` with zero tools and `WWW-Authenticate: Bearer realm="gflow"`, while the correct token still gets 200. Loopback DNS-rebinding was re-confirmed at **421**/**403** because the fix forwards the bind host and getting that wrong would silently disable protection that works today — and an earlier draft of the accompanying advisory claimed that protection was *disabled*, a false claim caught by measuring rather than re-reading. #813's guard is verified against a **real wheel in a real venv installed without extras**, the arm first proving it is in that state (`av present: False  PIL present: False`); the decisive row is that a **nonexistent** manifest still exits **20** on the dependency error rather than file-not-found, which is what shows the guard precedes the manifest read and not merely the generation. The Rich escape fix is verified on the **console render separated from the structlog JSON** — matching the JSON line would have been a false pass, since `--json` was never affected — with a **neutered control** through the same Rich version reproducing the bug exactly: `UNESCAPED -> pip install 'gflow-cli'` against `ESCAPED -> pip install 'gflow-cli[chain]'`. Also: `gflow-cli.exe` exists in the built wheel so `uvx gflow-cli` resolves at all, and the wheel carries 138 entries with **zero** ZIP duplicates. **Three items recorded as NOT verified rather than omitted:** a successful multi-link `chain` run spends Veo credits and stays outstanding e2e debt on #813 — what changed is the refusal path, which *is* verified; `gflow credits` against a working balance is impossible here because the account still returns 401, pre-existing **#795** and unrelated to this release; and the SSE arm of the token fix was exercised on loopback only, a deliberate scope limit, since binding a LAN address to test it would put an authenticated daemon on a live network for the run. **Two rows are blocked by the platform rather than by effort:** the PyPI metadata and the MCP Registry listing are both unobservable until this release is uploaded — PyPI renders the last artefact's metadata, and `mcp-publisher` reads its ownership token out of the *published* README.) · previous: [LIVE_VERIFICATION_v0.74.0](LIVE_VERIFICATION_v0.74.0.md) (**the migrated driver's run-unique uploads and its Frames-picker confirm, plus the `credits` remediation, verified 2026-09-14 on `ffroliva` at ZERO cost — every arm is a read or an upload-and-stop.** The confirm branch is the interesting one: this cohort's picker closes on its own, so the branch would never execute against live Flow by accident, and the e2e drives `FRAME_COMMIT_GRACE_S` to **0.001** so the grace expires before Flow can auto-close and **every** run enters it — the difference between a named blocker and an unrun claim. A *genuinely stuck* picker still cannot be produced here and stays `Refs #792`, verifier the reporter. #795 was verified on the cohort it is for, because this account is now in it — `auth status` green, `credits user` exit **3** with `detail` `credits endpoint returned 401` and `route: credits`, where v0.73.2 printed the class-default *"SAPISID cookie missing… re-run `gflow auth login`"*, advice that is wrong in every word there and that can roll a profile's strategy marker back and start the #791 spiral; the `credits list --json` envelope carries the per-profile `remediation_hint` that used to be dropped. **Two items recorded as NOT verified rather than omitted:** #799's exit-25 raise site needs an account in the agent-only cohort — the maintainer's accounts are served `flow.google.com` but still have the recoverable agent chip, so the state is structurally unreachable on them, a named blocker and #799 stays open; and neither `r2v` nor `i2i` had its own attach path driven to completion — `r2v` was not attempted (its e2e spends Veo credits), while `i2i` **was** attempted twice and failed both times at exit 23, before reaching the code under test, because the `--project` UUID came from `gflow project list` (the aisandbox catalog) and those ids 404 on `flow.google.com` — a harness error, recorded rather than dropped, which left a side finding: gflow reports Flow's own `/404?reason=project` as `UiSelectorDriftError`, blaming our selectors for Flow's 404. **#791 is not fixed and was not attempted blind** — all nine local profiles were probed at $0 and none is in the #791 state (SAPISID + a live `flow.google.com` session + no labs NextAuth token); four print its exact symptom string and none of them is it, because that string is also what a stale profile says.) · previous: [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)
+**What was actually live-verified for the latest release?** → latest: [LIVE_VERIFICATION_v0.96.1](LIVE_VERIFICATION_v0.96.1.md) (**2026-11-08, 1 Omni 1.2 + 1 lite clip.** Omni 1.2 start+end lands with matching first/last frames; route guard e2e 4/4 on CLI and MCP; t2v.) Previous: [LIVE_VERIFICATION_v0.96.0](LIVE_VERIFICATION_v0.96.0.md) (**2026-11-07, 1 Veo lite clip on the release tree.** t2v; Omni 1.2 durations 3–15 and its MCP twin; Omni r2v 4/6/10s; agent-only reload on CLI and MCP; paid Omni clips on the PR #1174 head.) Previous: [LIVE_VERIFICATION_v0.95.0](LIVE_VERIFICATION_v0.95.0.md) (**2026-11-07, 1 Veo lite clip.** t2v on the release tree; weekly upload e2e against the live endpoint 8/8 incl. EU consent and 410; local telemetry e2e 6/6; production D1 left at 0 rows; byte-exact `mcp setup` backup.) Previous: [LIVE_VERIFICATION_v0.94.0](LIVE_VERIFICATION_v0.94.0.md) (**2026-11-07, 1 Veo lite clip.** t2v on the release tree, local usage counters and telemetry e2e, CLI and MCP usage stats.) Previous: [LIVE_VERIFICATION_v0.93.0](LIVE_VERIFICATION_v0.93.0.md) (**2026-11-05, 82 Veo credits over the session.** Video delivery after #1153, lost t2v reply on CLI and MCP, revoked session.) Previous: [LIVE_VERIFICATION_v0.92.1](LIVE_VERIFICATION_v0.92.1.md) (**2026-10-30, $0.** MCP schema, #1121.). Previous: [LIVE_VERIFICATION_v0.92.0](LIVE_VERIFICATION_v0.92.0.md) (**2026-10-29, no Veo credits.** GHSA-hqfj-4jww-76f2: MCP `output` / `out_dir` / `profile` escapes refused live on the release head, an inside `output` lands; MCP upscale e2e and the #1035 BDD re-run 3/3. #1114 measured on real mounts, Linux and Windows) · previous: [LIVE_VERIFICATION_v0.91.0](LIVE_VERIFICATION_v0.91.0.md) (**2026-10-26/28.** Release-tree e2e 7/7: #1097 MCP `wait=false` runs and #1102 SEP-2663 `tasks/get` over stdio; selector drift; auth verification. Paid on their PRs: #723 r2v with a character 3/3, #1112 lost video submit reply 2/2. #988 blocked: no profile here is served the agent-only composer) · previous: [LIVE_VERIFICATION_v0.90.0](LIVE_VERIFICATION_v0.90.0.md) (**2026-10-25, no Veo credits in the release run.** Release-tree e2e 15/15: #772 a local `--ref` uploaded once per project (CLI, MCP, and a recorded image the project no longer holds); #1091 unwritable output exit 11; #934 `run --resume`; #745 credit shortfall; #1083 selector drift; the two re-armed canary tests; #796 and #481 verified at $0 on their PRs; #941 on its PR with one veo-lite clip) · previous: [LIVE_VERIFICATION_v0.89.1](LIVE_VERIFICATION_v0.89.1.md) (**2026-10-24, no Veo credits.** Release-tree e2e 9 passed, 1 skipped (credit-spending video case): lost image replies recovered from the grid on t2i and i2i (#1075), upscale straight after generating with no pause (#1067), visible model picker, auth and pre-submit regressions; hidden-picker, `/about` and declined-upload paths offline, blockers named) · previous: [LIVE_VERIFICATION_v0.89.0](LIVE_VERIFICATION_v0.89.0.md) (**2026-10-23, no Veo credits.** Release-tree e2e 20/20 (one re-run after #1010's lost reply body): #1039 default project CLI+MCP; #974/#1053 a missing project is exit 11 on generation, upscale and extend; #1038 nano2.1; #914 warm-client upscale; #892 pre-submit gate; #927 window position; #984/#1059 held profile exit 11 on the PR branches) · previous: [LIVE_VERIFICATION_v0.88.0](LIVE_VERIFICATION_v0.88.0.md) (**2026-10-22, no Veo credits.** #1036 browser proxy through a local proxy; #1037 slow-link create; #992 lost-reply readback; #1035 failed image download keeps the ids; #1041 quiet output; #1026 internal login) · previous: [LIVE_VERIFICATION_v0.87.1](LIVE_VERIFICATION_v0.87.1.md) (**2026-10-22, $0 apart from one Veo lite clip for the #795 spike.** #795: `gflow credits` balance equals Flow's account menu on two accounts, CLI and MCP; #1027: 2K image upscale and both video exports pass with the shared blob capture; project create/rename re-run for the shared `_rpc_reply`) · older: [LIVE_VERIFICATION_v0.87.0](LIVE_VERIFICATION_v0.87.0.md) (**2026-10-22, Veo lite clips under the e2e grant.** #1023: auth status/renew/MCP twin verify again after labs' session URL went 410; #1010: a lost submit reply makes one submit and a non-retryable exit 9, image and video; #1013, #995, #997, #986, #1014 e2e passed on the release tree; image-upscale body loss filed as #1027) · older: [LIVE_VERIFICATION_v0.86.0](LIVE_VERIFICATION_v0.86.0.md) (**2026-10-17/18, 2 Veo extends (owner-approved).** #991: `video extend` on flow.google.com — paid single-segment extend passed on the release tree, plus 3 $0 route-guard e2e; #989: agent-only composer — classic-composer regression 11 passed, agent-only path blocked externally (no account in that cohort; run live by 3 outside users); #982: `auth renew` 4 passed incl. stale→readable and /about) · previous: [LIVE_VERIFICATION_v0.85.0](LIVE_VERIFICATION_v0.85.0.md) (**2026-10-14, 0 credits.** #723/#979: `@Character` on flow.google.com images — 4-scenario e2e (CLI t2i, MCP, i2i + character, id-only refusal) passed on the release tree; #975: multi-prompt `t2i --project-name` — e2e passed) · previous: [LIVE_VERIFICATION_v0.84.0](LIVE_VERIFICATION_v0.84.0.md) (**2026-10-12, 0 credits.** #970: `gflow run --project` generates every row into an existing project — e2e passed on our account and the contributor's; #971: multi-prompt `t2i --project` — new e2e passed; no MCP twin for either) · previous: [LIVE_VERIFICATION_v0.83.2](LIVE_VERIFICATION_v0.83.2.md) (**2026-10-11, 0 credits.** #963: `--duration` binds in a Vietnamese pane — locale e2e failed on develop and passed after the fix, and a notice-only cookie bar is now acknowledged; #957: image upscale e2e passed on the CLI and over MCP; #962: `auth status` probe uses the profile's channel, unverified on a host without Chrome) · previous: [LIVE_VERIFICATION_v0.83.1](LIVE_VERIFICATION_v0.83.1.md) (**2026-10-08, 0 credits.** #958: the default image model `nano2` runs Nano Banana 2.1 on flow.google.com — e2e failed on develop and passed after the fix; CLI and MCP twins each wrote a JPEG; 2.1 measured as replacing 2 on two accounts) · previous: [LIVE_VERIFICATION_v0.83.0](LIVE_VERIFICATION_v0.83.0.md) (**2026-10-06/07.** #948: a billed flow.google.com video run no longer exits 7 — t2v, i2v and r2v e2e passed after the fix, reproduced before it; `data download` e2e 2 passed after a 302 regression was caught and fixed; #922: image and video upscale e2e passed, CLI and MCP image twins wrote the same JPEG, MCP video wrote 1920x1080, a 1080p export measured 0 credits) · previous: [LIVE_VERIFICATION_v0.82.1](LIVE_VERIFICATION_v0.82.1.md) (**2026-10-02.** A reCAPTCHA mint failure typed with a live-measured retry flag (#915, e2e 2 passed, $0); a busy catalog no longer fails a successful generation (#900, real SQLite, no Flow surface); a video's workflow id recorded (#898, 1 veo-lite clip)) · previous: [LIVE_VERIFICATION_v0.82.0](LIVE_VERIFICATION_v0.82.0.md) (**2026-10-01.** `"ref": "batch:N"` and local-file refs on `gflow run` verified by a BDD e2e on flow.google.com: in place, no re-upload, lineage recorded; 1 veo-lite clip for the #926 e2e) · previous: [LIVE_VERIFICATION_v0.81.0](LIVE_VERIFICATION_v0.81.0.md) (**2026-09-30, 3 veo-lite clips.** The off-screen generation browser (#923) measured unchanged for image and video, window placement read back from Chrome, focus-steal measured and documented; #919 verified at merge) · previous: [LIVE_VERIFICATION_v0.80.0](LIVE_VERIFICATION_v0.80.0.md) (**2026-09-29, 0 Veo credits.** `--resolution` 360p/720p proven by driving the real settings pane on `omni_flash` and refusing the credit-spending submit, on the CLI transport **and** the MCP twin; `nano2-lite` e2e 2 passed; #891 measured before/after — `gflow run` `[nano2, imagen4]` went from exit 1 `RecaptchaError` with a lost results table to exit 36 naming the model, plus 3 e2e (fresh, warm, MCP) with a spy asserting zero client mints; #896 `e2e_data` 2 passed, its failure path offline-only. Named blockers: rendered resolution (needs a billed clip), the `/about` re-check arm, labs-served accounts.) · previous: [LIVE_VERIFICATION_v0.79.1](LIVE_VERIFICATION_v0.79.1.md) (**the signed-media download survives a dropped connection, verified 2026-09-22 at $0.** All three download sites route through one new shared helper, and that helper was driven through a real Flow clip route and a real signed CDN transfer by `pytest -m e2e_data` — 2 passed in 20.74 s, `ftyp` magic, byte length equal to the size Flow reports, and **no `url=` on any log event**. The retry itself could not wait for an organic reset — 20/20 clean here against the reporter's 2-in-6 — so it was **measured against a real TCP RST with an A/B control**: with `max_retries` the transfer recovers on a second connection, with it disabled the identical fault kills the call, and three attempts at a 5 s timeout finish in 1.57 s rather than ~15 s, proving the backoff shares one budget. **Two sites are NOT live-verified and name their blockers:** the composer call site needs a billed generation and `gflow credits` answers 401 on this account (#795), so no credits were spent; and the labs download cannot be reached at all from here (HTTP 308, 6/6 profiles). Offline: 21 new tests, full sweep 2143 passed.) · earlier: [LIVE_VERIFICATION_v0.79.0](LIVE_VERIFICATION_v0.79.0.md) (**the migrated host stops echoing a model it never observed, verified 2026-09-18 at $0.** `model_name_type` is `null` on `flow.google.com` in a real `image t2i --json`, with every sibling field populated — which is what makes the null a result rather than an empty envelope; the first read of it was flat rather than into `images[]` and returned `None` for everything, and that instrument error was discarded rather than reported. Both surfaces ran: `test_e2e_t2i_runs_on_a_moved_account` and `test_e2e_mcp_i2i_runs_on_the_migrated_host`, 2 passed in 86 s. **`gflow data download` was tested on an image and failed** — 45 s, then a message blaming the project, the trash and your prompt; recovery is video-only and the release notes now say so (#877). **#803 is NOT live-verified and names its blocker:** reaching those raise sites needs a non-JSON or token-less aisandbox reply, and the labs route refuses first with a 404 — itself a misleading error, filed as #875. Offline: 4 new unit tests, 1775 passed.) · previous: [LIVE_VERIFICATION_v0.78.0](LIVE_VERIFICATION_v0.78.0.md) (**generating with no project on `flow.google.com` — and video from a start frame — verified 2026-09-17.** The release exists because labs.google's `project.createProject` is retired — 404 *"Flow RPCs have been deprecated and disabled"* with a labs token, 401 without, 0 successes in 12 across four profiles — and gflow reported the 401 as an expired login. Creation and rename are driven on flow.google.com and read back from Flow's own `jHPbke` / `o8DA4` replies; the CLI and the MCP twin are each exercised separately, and both video paths reach a real submit that is aborted before Flow can bill it. Two failures are recorded and re-tested rather than explained away — one MCP image reply that did not reproduce under a four-run A/B, and a Chrome launch starved by a concurrent coverage run that passed in 36 s alone. The 3:4 image aspect is re-measured on the live radiogroup, five radios where 2026-09-08 saw four. Three items are NOT verified and each names its blocker: no labs-served account, no entitled `/about` account, no non-`en` locale. **#860 is the one thing here that cost credits, deliberately:** the only proof that a start frame binds is a real generation, so ten i2v clips were generated and downloaded on a live migrated account — `migrated.frame_uploaded` → `frame_bound` → `submit_observed` → `download`, the middle event being the one that could not fire before this release. **#859 is recorded as UNOBSERVED, not verified** — its dismissal ran on every one of those runs and no promo modal ever appeared, so the $0 route-intercepted e2e is what covers it. `gflow docs` (#861) is verified from the built wheel, which is its whole contract: 127 topics, `docs/FILE.md:LINE` search hits, no network and no checkout.) · previous: [LIVE_VERIFICATION_v0.77.1](LIVE_VERIFICATION_v0.77.1.md) (**a four-fix patch release, verified 2026-09-17 at ZERO cost.** The headline is #846: the published package could not run a single interactive command on a clean Windows install, because `ConsoleRenderer(colors=True)` needs `colorama` and nothing declared it. Verified as a controlled A/B on a fresh Python 3.13 venv — `SystemError` before, exit 33 after — plus an arm with stderr piped that shows why the AUTO/JSON split hid this from every CI job, and the MCP twin run separately. #848's import probe is exercised against a **deliberately broken venv** and an intact one, including the contract that a probe which cannot run reports nothing rather than reporting breakage. #852 is re-measured on the release head: 40 000 base64-shaped chars fall from 12.07 s to 0.020 ms with identical output on Workspace and custom domains. **#849 is a NAMED BLOCKER, not an omission** — its end-to-end behaviour needs a fresh interactive Google sign-in, which no agent can perform; its live A/B is recorded on PR #851 and its e2e file re-ran 4/4 here. **Seven live e2e failures are recorded rather than hidden**, and controlled: the release changes exactly four source files and none of them is a failing test's module.) · previous: [LIVE_VERIFICATION_v0.77.0](LIVE_VERIFICATION_v0.77.0.md) (**the migrated-host login lockout (#791), verified as a controlled A/B on a real Google **Workspace** account at ZERO cost — same profile, same cookies untouched between arms, so the only variable is the code: exit 8 with the Chrome marker rolled back and `channel_for_profile` collapsed to `None`, then exit 0 with the marker intact and the account recorded. The refusal path is measured too — of 10 local profiles, 5 reproduce #791 and exactly one carries both required cookies: 4 refusals, 1 upgrade, 0 false positives. v0.76.0 recorded this fix as **withdrawn**; the approach that shipped is a different one, server-attested on the landing URL rather than on client-rendered DOM. An earlier revision gated auth on an `@gmail.com`-only pattern that silently declined every custom domain — the account used here is one, which is why this is its verification. **#796 is reproduced and prevented**, not merely reported: it was filed as *'not yet reproduced end-to-end'*. **Two rows are named blockers, not omissions:** the MCP Registry publish (#841) cannot be rehearsed before a real tag push, so this release is its first exercise; and the migrated-host generation e2e cannot run here at all — every account bounces to `/about`, A/B-controlled against `develop` so it is not mistaken for a regression.) · previous: [LIVE_VERIFICATION_v0.76.0](LIVE_VERIFICATION_v0.76.0.md) (**a diagnostics-and-distribution release, verified 2026-09-16 at ZERO cost — no Veo credits, no image generation, no Flow submit.** The decisive arm is #833's **negative** control, run first-hand on two real accounts rather than relayed: `flow-pinhole-unavailable-screen` is **0** on both `ffroliva` and `denon82` while `aisandbox-root` is **1**, so the guard does not fire on accounts that HAVE Flow access and the zero is a real absence rather than a page that never booted — a guard with only a positive arm is indistinguishable from one that is permanently on. Both accounts settled at **`/about`**, which is the state that broke this release's *withdrawn* #791 oracle, and the exit-39 signal reads a component that only exists on the unavailable screen, so `/about` cannot mimic it. mcpservers.org is verified with a **404 negative control** because the listing 403s to `curl` and a naive check would have called the link dead. **#791 is NOT in this release and was withdrawn rather than deferred**: a fix passed eight council dimensions and was then refuted by a five-day-old spike nobody had routed to it — Flow's `/about` hop is decided client-side with zero requests to Flow, and *"the backend grants access while the frontend declines to open it"* (#756), so the probe would have reported authenticated users as logged out, reintroducing #791 as its own cure; the e2e caught it by going red on a live account whose state moved mid-session. **Two rows are blocked by the platform rather than by effort:** the Docker sign-in needs a WSL-integrated Docker host, and the MCP Registry publish cannot be observed until this very tag reaches `main`, since both triggers resolve the workflow from the default branch.) · previous: [LIVE_VERIFICATION_v0.75.0](LIVE_VERIFICATION_v0.75.0.md) (**a distribution-and-hardening release, verified 2026-09-15 on `ffroliva` at ZERO cost — no Veo credits, no image generation, no Flow submit.** The `gflow serve` token fix is an **A/B against the released 0.74.0 wheel from PyPI**, not a diff read: the token was *set* in both arms, so the probe measures whether it is checked — before, `no token 200/200` with 13 tools listed and `wrong 200/200`; after, `401/401` with zero tools and `WWW-Authenticate: Bearer realm="gflow"`, while the correct token still gets 200. Loopback DNS-rebinding was re-confirmed at **421**/**403** because the fix forwards the bind host and getting that wrong would silently disable protection that works today — and an earlier draft of the accompanying advisory claimed that protection was *disabled*, a false claim caught by measuring rather than re-reading. #813's guard is verified against a **real wheel in a real venv installed without extras**, the arm first proving it is in that state (`av present: False  PIL present: False`); the decisive row is that a **nonexistent** manifest still exits **20** on the dependency error rather than file-not-found, which is what shows the guard precedes the manifest read and not merely the generation. The Rich escape fix is verified on the **console render separated from the structlog JSON** — matching the JSON line would have been a false pass, since `--json` was never affected — with a **neutered control** through the same Rich version reproducing the bug exactly: `UNESCAPED -> pip install 'gflow-cli'` against `ESCAPED -> pip install 'gflow-cli[chain]'`. Also: `gflow-cli.exe` exists in the built wheel so `uvx gflow-cli` resolves at all, and the wheel carries 138 entries with **zero** ZIP duplicates. **Three items recorded as NOT verified rather than omitted:** a successful multi-link `chain` run spends Veo credits and stays outstanding e2e debt on #813 — what changed is the refusal path, which *is* verified; `gflow credits` against a working balance is impossible here because the account still returns 401, pre-existing **#795** and unrelated to this release; and the SSE arm of the token fix was exercised on loopback only, a deliberate scope limit, since binding a LAN address to test it would put an authenticated daemon on a live network for the run. **Two rows are blocked by the platform rather than by effort:** the PyPI metadata and the MCP Registry listing are both unobservable until this release is uploaded — PyPI renders the last artefact's metadata, and `mcp-publisher` reads its ownership token out of the *published* README.) · previous: [LIVE_VERIFICATION_v0.74.0](LIVE_VERIFICATION_v0.74.0.md) (**the migrated driver's run-unique uploads and its Frames-picker confirm, plus the `credits` remediation, verified 2026-09-14 on `ffroliva` at ZERO cost — every arm is a read or an upload-and-stop.** The confirm branch is the interesting one: this cohort's picker closes on its own, so the branch would never execute against live Flow by accident, and the e2e drives `FRAME_COMMIT_GRACE_S` to **0.001** so the grace expires before Flow can auto-close and **every** run enters it — the difference between a named blocker and an unrun claim. A *genuinely stuck* picker still cannot be produced here and stays `Refs #792`, verifier the reporter. #795 was verified on the cohort it is for, because this account is now in it — `auth status` green, `credits user` exit **3** with `detail` `credits endpoint returned 401` and `route: credits`, where v0.73.2 printed the class-default *"SAPISID cookie missing… re-run `gflow auth login`"*, advice that is wrong in every word there and that can roll a profile's strategy marker back and start the #791 spiral; the `credits list --json` envelope carries the per-profile `remediation_hint` that used to be dropped. **Two items recorded as NOT verified rather than omitted:** #799's exit-25 raise site needs an account in the agent-only cohort — the maintainer's accounts are served `flow.google.com` but still have the recoverable agent chip, so the state is structurally unreachable on them, a named blocker and #799 stays open; and neither `r2v` nor `i2i` had its own attach path driven to completion — `r2v` was not attempted (its e2e spends Veo credits), while `i2i` **was** attempted twice and failed both times at exit 23, before reaching the code under test, because the `--project` UUID came from `gflow project list` (the aisandbox catalog) and those ids 404 on `flow.google.com` — a harness error, recorded rather than dropped, which left a side finding: gflow reports Flow's own `/404?reason=project` as `UiSelectorDriftError`, blaming our selectors for Flow's 404. **#791 is not fixed and was not attempted blind** — all nine local profiles were probed at $0 and none is in the #791 state (SAPISID + a live `flow.google.com` session + no labs NextAuth token); four print its exact symptom string and none of them is it, because that string is also what a stale profile says.) · previous: [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.96.0 → gflow_cli-0.96.1}/docs/LIVE_VERIFICATION_v0.96.0.md

@@ -58,3 +58,13 @@ four passed when re-run alone.
 | `pytest --cov` (`-n 8`) | 6027 passed, 12 skipped, 1 failed: `test_packaging.py::test_built_distributions_contain_sql_migrations`, which passed alone (2/2) and with `tests/data` under `-n 8` (173/173); the full-suite run kept no traceback |
 | `check_release_artifacts.py` | ✅ release artifacts OK |
 | `/gflow:doc-review` | _Council verdict: RED across 3 auditors (completeness RED, cross-reference YELLOW, drift RED). All findings were docs lagging #1174/#1177, none code: `docs/USAGE.md` called 10s "exclusively omni-flash"; the `video chain` help said "10s remains omni-flash-only"; resolution was "omni-flash only" in USAGE, the MCP docstring and `VideoRequest`; Omni 1.2's reference cap of 7 and its chain refusal were missing from the cap and chain lists; the video-production skill, KNOWN_ISSUES and MOVIE.md omitted the 3–15 range; no user doc described the #1142 reloads before exit 36 (now in USAGE, KNOWN_ISSUES, MCP.md and the gflow-cli skill); this ledger over-claimed that the forced e2e covers every gate (it covers the reference-upload gate). All fixed in the release-prep commit, website and plugin mirrors regenerated. Deferred: README's "5-model Veo picker" count, 720p on Omni 1.2 (unmeasured), the video-production skill's claim that `--duration` without `--model` exits 2 (pre-existing). Council reports at `tmp/council/0{1,2,3}-*.md` (local-only)._ |
+
+## Post-tag evidence
+
+| Check | Result |
+|---|---|
+| Signed tag | `v0.96.0` on `9fd03513`, SSH-signed (`git cat-file -p v0.96.0` carries one `BEGIN SSH SIGNATURE`) |
+| `Release` workflow | run 42427395129: success (`build-and-publish`, `mcp-registry / publish`) |
+| GitHub Release | `v0.96.0`, published 2026-11-07T23:55:56Z, not a prerelease |
+| PyPI | `https://pypi.org/pypi/gflow-cli/0.96.0/json` lists `gflow_cli-0.96.0-py3-none-any.whl` and `gflow_cli-0.96.0.tar.gz` |
+| Release PR | #1179 merged into `main` (merge commit `3188d2b1`), every check green incl. SonarCloud; back-merge `ea7a94ff` into `develop` |

gflow_cli-0.96.1/docs/LIVE_VERIFICATION_v0.96.1.md

@@ -0,0 +1,53 @@
+# Live verification — v0.96.1
+
+Release ledger for v0.96.1: Omni 1.2 Flash start+end frames, video submits refused before they
+are billed, and the 10s Omni 1.2 end-frame cap (#1178, PR #1181).
+
+## Environment
+
+| | |
+|---|---|
+| Profile | `ffroliva` (real-browser Chrome strategy) for the release runs; `denon82` for the spike |
+| Host Flow served | `flow.google.com` |
+| Entrypoint | the real `gflow` CLI (`uv run gflow` in the release worktree); the e2e drives the CLI through `CliRunner` and the MCP tool in-process |
+| OS | Windows 11 |
+| Tree | `chore/release-v0.96.1` (cut from `fbabf435`, the PR #1181 merge head) |
+| Veo credits spent | 1 Omni 1.2 8s 360p clip + 1 veo-lite clip on the release tree (`ffroliva` 660 → 642: 18 credits); 2 Omni 1.2 8s clips billed by the spike's miss on `denon82` |
+
+## Summary
+
+| Change | Surface | Verified live? | Cost |
+|---|---|---|---|
+| Plain text-to-video on the release tree (step 0) | `gflow video t2v "a ceramic cup on a wooden table, soft morning light" --profile ffroliva --model veo-lite` | ✅ exit 0 in 115s, 2,526,417 bytes, `ftypisom`, 7.93s, 720x1280 h264 + aac, 24 fps | 1 lite clip |
+| Omni 1.2 start+end runs (#1178) | `gflow video i2v start.png "…" --end-frame end.png --model omni-1.2-flash --duration 8 --resolution 360p --aspect 9:16` | ✅ exit 0 in 119s, 1,665,326 bytes, `ftypmp42`, 8.04s, 360x640 h264 + aac, 24 fps; first frame mean RGB (201,54,33) = the red start input, last frame (41,78,196) = the blue end input | 1 Omni 1.2 clip |
+| Route guard on both doors (#1178) | `tests/e2e/test_omni12_start_end_guard_e2e.py` on the release tree | ✅ 4 passed (CLI and MCP × right frames, swapped end id): the guard passes Omni 1.2's body-only `nprQif` with its `*_i2v_fl_*` key and both ids; a swapped end id is aborted unsent ("billed nothing"), and the safety route sees no submit | $0 |
+| Same e2e on the PR head | `550bf16a`, `ffroliva` | ✅ 4 passed; credits 660 before and after | $0 |
+| 10s end-frame cap (#1178) | DTO, CLI (exit 2) and MCP (400 before queueing) | Offline only: `tests/api/test_omni_1_2.py`, `tests/cli/test_cli_video.py`, `tests/mcp/test_server.py` | $0 |
+| Version | `gflow --version` | ✅ `gflow, version 0.96.1` | $0 |
+
+### What these runs do not prove
+
+- **The over-10s end-frame behaviour.** No account here has a Google AI plan (`denon82`'s
+  slider stops at 10s), so the cap rests on the reporter's measurement
+  at 12s and 15s on Google AI Ultra. Blocker: no account in that tier. #1178 stays open for it.
+- **A batched `rpcids=X,nprQif` submit.** Never observed; the guard, like the observer before
+  it, reads the first rpc id. Not measured, not handled.
+
+### Found by this cycle
+
+- The spike's first route predicate matched the URL `rpcids` only, missed Omni 1.2's body-only
+  `nprQif`, and two Omni 1.2 clips were billed on `denon82`. That is the bug class the route
+  guard closes; the spike now routes every `batchexecute` (spike doc, "The miss").
+- `test_video_extend_migrated_e2e.py::test_e2e_extend_submit_contract_at_zero_cost` fails on
+  unchanged develop too (no `rqZuUc`, no model key in `fZytfe`): filed as #1180, unrelated.
+
+## Gates
+
+| Gate | Result |
+|---|---|
+| `check_repo_hygiene.py`, `check_website_docs_pii.py`, `generate_website_docs.py --check`, `check_council_memory.py`, `generate_plugin_skills.py --check` | ✅ clean |
+| `check_doc_links.py` | ✅ after this ledger (the only misses were links to it) |
+| ruff, ruff format, pyright strict | ✅ clean, 615 files formatted, 0 errors |
+| `pytest --cov` (`-n 8`) | ✅ 6056 passed, 12 skipped, 93% |
+| `check_release_artifacts.py` | ✅ release artifacts OK |
+| `/gflow:doc-review` | _Council verdict: YELLOW across 3 auditors (completeness YELLOW, cross-reference GREEN, drift GREEN); no false claim. Fixed in the release-prep commit: the USAGE exit-7 row, the i2v and r2v exit-7 lines and MCP.md's retryable section now say a refused video submit is aborted unsent (hint: *billed nothing*) and how to tell it from one already sent; USAGE's Omni 1.2 section says start+end works; the i2v `--model` help and the gflow-cli skill carry the 10s end-frame cap. Deferred: no Omni model is named in `llms.txt`/README (pre-existing). Council reports at `tmp/council/0{1,2,3}-*.md` (local-only)._ |

{gflow_cli-0.96.0 → gflow_cli-0.96.1}/docs/MCP.md

@@ -84,7 +84,7 @@ The server registers three protocol surfaces:
 ### Tools (Executable actions)
 * `gflow_generate_image(prompt, model, aspect, count, reference_images, reference_entities, reference_entity_names, tools, profile, project, project_name, instructions, ui_mode, output, wait)`: Triggers text-to-image / image-to-image (Imagen / Nano Banana). There is no `seed` parameter: Flow picks the seed and the image request cannot carry one (removed in [#1013](https://github.com/ffroliva/gflow-cli/issues/1013), as the CLI's `--seed` was in v0.8.0). A completed result reports the catalogued seed under `seed`: the seed Flow chose on the classic image paths, `0` on the agentic / agent-only arms (which observe none), `null` if none was recorded — the MCP twin of `gflow image t2i --json`'s `images[].seed`. `instructions` is an optional list of ephemeral agent-instruction strings (agentic cohort only). `reference_images` switches to i2i and accepts **either a local file path or a generated image's Flow media UUID**. A UUID reference is attached by **selecting the already-existing asset in Flow's reference picker — no duplicate copy is uploaded** (locating the tile by the media id in its thumbnail URL, and searching the recorded display name to surface it when needed); gflow falls back to uploading the asset's on-disk local file only when it can't be located in place (e.g. it lives in a different project's picker). `project` generates into an existing Flow project id (mirrors CLI `--project`; when omitted, [`GFLOW_CLI_PROJECT`](CONFIGURATION.md#gflow_cli_project) is used unless `project_name` asks for a new project, #1039) — pass the reference's project to keep it selectable in place. `ui_mode` selects the Flow UI arm (`auto`/`classic`/`agentic`, mirroring CLI `--ui-mode`, matched case-insensitively). Since [#595](https://github.com/ffroliva/gflow-cli/issues/595) `auto` means "no arm was asked for" and **resolves to `classic`** — the arm that can satisfy an image request — so an account in Flow's agentic cohort aborts pre-submit (exit-28 equivalent envelope, zero credits) instead of failing mid-run with selector drift or video bytes; the agentic arm is bound only when named. Passing `instructions` forces `agentic` automatically, so `ui_mode="classic"` + `instructions` is a hard conflict rather than a silent drop. An unknown value returns a 400 problem-details envelope. See [CONFIGURATION § GFLOW_CLI_UI_MODE](CONFIGURATION.md#gflow_cli_ui_mode).
   `model` is `nano2` (Nano Banana 2.1 on flow.google.com; `nano2.1` also accepted), `nano2-lite` (Nano Banana 2 Lite), `nano-pro` (Nano Banana Pro) or `image4` (Imagen 4, no longer in Flow's menu); other aliases are accepted too. On migrated `flow.google.com` accounts, T2I and local-file I2I are supported with Nano Banana 2.1 (`nano2`, #958) / 2 Lite / Pro, all five aspects (16:9, 4:3, 1:1, 3:4, 9:16) and count 1–4; the page owns reCAPTCHA and the `ogiZ0b` submit. `@Name` character mentions in the prompt are attached through the composer's `@` picker and verified as character chips before submit (#723). `reference_entities` must be paired with `reference_entity_names` there (an id alone is refused, exit 36); a `reference_images` UUID is referenced in place when the catalog records it in the same `project` (#995), and a local `reference_images` file is uploaded into the project once and mentioned in place on later calls with the same file, like the CLI's `--ref` ([#772](https://github.com/ffroliva/gflow-cli/issues/772)); an output path gflow cannot write ends in the exit-11-equivalent envelope, with the image still in the Flow project ([#1091](https://github.com/ffroliva/gflow-cli/issues/1091)); other UUID references, instructions and Imagen 4 remain pre-submit refusals there. An agent-only composer (see below) takes T2I only. The queued (`wait=false`) and blocking (`wait=true`) calls use the same typed payload and worker path.
-* `gflow_generate_video(prompt, mode, aspect, initial_frame, end_frame, reference_images, reference_entities, reference_entity_names, model, duration, resolution, count, tools, profile, project, project_name, ui_mode, output, wait)`: Triggers vertical or landscape video generation (Veo). `mode` is `t2v`/`i2v`/`r2v`; `model` (`veo_lite`/`veo_fast`/`veo_quality`/`omni_flash`/`omni_1_2_flash`, aliases accepted), `duration` (seconds — 4/6/8 for Veo 3.1, 4/6/8/10 for omni_flash, every integer 3–15 for omni_1_2_flash; with no `model`, 4/6/8/10), `resolution` ('360p' or '720p', supported on the Omni models; on any other model, or on the labs editor, the job fails pre-submit with the exit-11-equivalent envelope and no credits spent). **Whether Flow renders a duration control at all is account/cohort-dependent**: on an account that renders none, the job is accepted here and fails in the worker pre-submit (exit 23 equivalent on the labs driver, exit 11 equivalent on the migrated `flow.google.com` host — now the default t2v route, #650 — no credits spent either way) rather than being rejected up front — see [KNOWN_ISSUES](https://github.com/ffroliva/gflow-cli/blob/main/KNOWN_ISSUES.md) (#451/#288/#630), and `count` mirror the CLI `gflow video` flags — an omitted `model` lets the transport apply its i2v veo-lite default (issue #125), and every model — `omni_flash` included — accepts i2v with a start frame and with an end frame (wire-verified 2026-09-02, issue #626); `i2v` requires `initial_frame`, `r2v` requires `reference_images` **or** `reference_entities`; `project` generates into an existing Flow project id (mirrors CLI `--project`; when omitted, [`GFLOW_CLI_PROJECT`](CONFIGURATION.md#gflow_cli_project) is used unless `project_name` asks for a new project, #1039); on an account Google has moved to `flow.google.com` (`GFLOW_CLI_FLOW_HOST`, read from the server/daemon environment, not per call — see [CONFIGURATION § GFLOW_CLI_FLOW_HOST](CONFIGURATION.md#gflow_cli_flow_host)) omitting `project` creates one there first (#864); there, on the classic migrated composer (an agent-only one takes text-to-video only — see below), the ported modes are text-to-video; image-to-video with a **local** `initial_frame`, optionally with a **local** `end_frame` (start+end interpolation, #639) (the file is uploaded through the editor and bound on the Start chip by display name — it stays in the Flow project like any upload, under a **run-unique** name: `hero.png` is listed as `hero-a1b2c3d4.png`, so a re-run cannot bind an earlier upload — [#792](https://github.com/ffroliva/gflow-cli/issues/792)); and reference-to-video with local `reference_images` (each file is uploaded the same way — run-unique name included — and attached as an `@` mention of *that* name in the prompt; `duration` there accepts every integer from `3` through `15` with explicit `model="omni_1_2_flash"` (set through its duration slider; Google AI plans are required above `10`) and `4/6/8/10` with explicit `omni_flash`; Veo or an unspecified model accepts only `8`, because measured shorter Veo requests dropped the references and billed text-to-video, so any other value returns the exit-11-equivalent envelope. An omitted r2v duration still pins `8` to avoid inheriting the editor's previous setting). A Flow media UUID as `initial_frame` or `end_frame`, a character on `t2v` or `i2v`, and `reference_entities` without paired `reference_entity_names` return the exit-36-equivalent envelope; `r2v` takes a saved character when each `reference_entities` id is paired with its `reference_entity_names` entry, with or without local `reference_images` ([#723](https://github.com/ffroliva/gflow-cli/issues/723)); a **local-file** `end_frame` is ported (#639). `initial_frame`, `end_frame`, and `reference_images` each accept **either a local file path or the Flow image UUID of a generated asset** — pass a generated image's id straight in to chain image→video, and gflow attaches it for you. Since v0.58.0 (#529) the CLI and MCP surfaces are unified for i2v frames: the UUID keeps its identity and is enriched with the catalog's recorded display name plus an integrity-verified local fallback, so the transport prefers **selecting the exact asset in the project's media picker** (no duplicate upload) and re-uploads the recorded local file only when the tile is unreachable — and only if its byte count/SHA-256 still match. A UUID that isn't in your local asset catalog is rejected up front with a clear "Reference Not Found" error; a catalogued asset with neither a display name nor a verified local file gives a "Reference Not Usable" error (re-generate it or pass a local path). `r2v` UUID refs are resolved to the recorded local file for upload. `ui_mode` selects the Flow UI arm (#299 PR-A, mirroring CLI `--ui-mode`) and **applies to every mode of this tool, including `r2v`** — unlike the CLI, where `video r2v`/`chain` have no flag and follow the env-only path. On labs and the classic migrated composer, video generation has **only a classic driver**, so `auto` ≡ `classic`: both verify the classic editor pre-submit and abort before spending credits if it is unreachable. `ui_mode="agentic"` is rejected with a 400 problem-details envelope, because no agentic video driver exists yet. (An agent-only migrated composer is routed before this check: text-to-video runs through its chat agent under `ui_mode` `auto` or `classic` — `"agentic"` is still rejected with the 400 above, before any browser work — and other video forms return the exit-36-equivalent envelope before anything is clicked.) Values are matched case-insensitively. (MCP tools return envelopes, never process exit codes — the CLI equivalents of these aborts are exit 28 and exit 2 respectively.) See [CONFIGURATION § GFLOW_CLI_UI_MODE](CONFIGURATION.md#gflow_cli_ui_mode).
+* `gflow_generate_video(prompt, mode, aspect, initial_frame, end_frame, reference_images, reference_entities, reference_entity_names, model, duration, resolution, count, tools, profile, project, project_name, ui_mode, output, wait)`: Triggers vertical or landscape video generation (Veo). `mode` is `t2v`/`i2v`/`r2v`; `model` (`veo_lite`/`veo_fast`/`veo_quality`/`omni_flash`/`omni_1_2_flash`, aliases accepted), `duration` (seconds — 4/6/8 for Veo 3.1, 4/6/8/10 for omni_flash, every integer 3–15 for omni_1_2_flash, at most 10 with an `end_frame`; with no `model`, 4/6/8/10), `resolution` ('360p' or '720p', supported on the Omni models; on any other model, or on the labs editor, the job fails pre-submit with the exit-11-equivalent envelope and no credits spent). **Whether Flow renders a duration control at all is account/cohort-dependent**: on an account that renders none, the job is accepted here and fails in the worker pre-submit (exit 23 equivalent on the labs driver, exit 11 equivalent on the migrated `flow.google.com` host — now the default t2v route, #650 — no credits spent either way) rather than being rejected up front — see [KNOWN_ISSUES](https://github.com/ffroliva/gflow-cli/blob/main/KNOWN_ISSUES.md) (#451/#288/#630), and `count` mirror the CLI `gflow video` flags — an omitted `model` lets the transport apply its i2v veo-lite default (issue #125), and every model — `omni_flash` included — accepts i2v with a start frame and with an end frame (wire-verified 2026-09-02, issue #626); `i2v` requires `initial_frame`, `r2v` requires `reference_images` **or** `reference_entities`; `project` generates into an existing Flow project id (mirrors CLI `--project`; when omitted, [`GFLOW_CLI_PROJECT`](CONFIGURATION.md#gflow_cli_project) is used unless `project_name` asks for a new project, #1039); on an account Google has moved to `flow.google.com` (`GFLOW_CLI_FLOW_HOST`, read from the server/daemon environment, not per call — see [CONFIGURATION § GFLOW_CLI_FLOW_HOST](CONFIGURATION.md#gflow_cli_flow_host)) omitting `project` creates one there first (#864); there, on the classic migrated composer (an agent-only one takes text-to-video only — see below), the ported modes are text-to-video; image-to-video with a **local** `initial_frame`, optionally with a **local** `end_frame` (start+end interpolation, #639) (the file is uploaded through the editor and bound on the Start chip by display name — it stays in the Flow project like any upload, under a **run-unique** name: `hero.png` is listed as `hero-a1b2c3d4.png`, so a re-run cannot bind an earlier upload — [#792](https://github.com/ffroliva/gflow-cli/issues/792)); and reference-to-video with local `reference_images` (each file is uploaded the same way — run-unique name included — and attached as an `@` mention of *that* name in the prompt; `duration` there accepts every integer from `3` through `15` with explicit `model="omni_1_2_flash"` (set through its duration slider; Google AI plans are required above `10`) and `4/6/8/10` with explicit `omni_flash`; Veo or an unspecified model accepts only `8`, because measured shorter Veo requests dropped the references and billed text-to-video, so any other value returns the exit-11-equivalent envelope. An omitted r2v duration still pins `8` to avoid inheriting the editor's previous setting). A Flow media UUID as `initial_frame` or `end_frame`, a character on `t2v` or `i2v`, and `reference_entities` without paired `reference_entity_names` return the exit-36-equivalent envelope; `r2v` takes a saved character when each `reference_entities` id is paired with its `reference_entity_names` entry, with or without local `reference_images` ([#723](https://github.com/ffroliva/gflow-cli/issues/723)); a **local-file** `end_frame` is ported (#639). `initial_frame`, `end_frame`, and `reference_images` each accept **either a local file path or the Flow image UUID of a generated asset** — pass a generated image's id straight in to chain image→video, and gflow attaches it for you. Since v0.58.0 (#529) the CLI and MCP surfaces are unified for i2v frames: the UUID keeps its identity and is enriched with the catalog's recorded display name plus an integrity-verified local fallback, so the transport prefers **selecting the exact asset in the project's media picker** (no duplicate upload) and re-uploads the recorded local file only when the tile is unreachable — and only if its byte count/SHA-256 still match. A UUID that isn't in your local asset catalog is rejected up front with a clear "Reference Not Found" error; a catalogued asset with neither a display name nor a verified local file gives a "Reference Not Usable" error (re-generate it or pass a local path). `r2v` UUID refs are resolved to the recorded local file for upload. `ui_mode` selects the Flow UI arm (#299 PR-A, mirroring CLI `--ui-mode`) and **applies to every mode of this tool, including `r2v`** — unlike the CLI, where `video r2v`/`chain` have no flag and follow the env-only path. On labs and the classic migrated composer, video generation has **only a classic driver**, so `auto` ≡ `classic`: both verify the classic editor pre-submit and abort before spending credits if it is unreachable. `ui_mode="agentic"` is rejected with a 400 problem-details envelope, because no agentic video driver exists yet. (An agent-only migrated composer is routed before this check: text-to-video runs through its chat agent under `ui_mode` `auto` or `classic` — `"agentic"` is still rejected with the 400 above, before any browser work — and other video forms return the exit-36-equivalent envelope before anything is clicked.) Values are matched case-insensitively. (MCP tools return envelopes, never process exit codes — the CLI equivalents of these aborts are exit 28 and exit 2 respectively.) See [CONFIGURATION § GFLOW_CLI_UI_MODE](CONFIGURATION.md#gflow_cli_ui_mode).
 
 > **Attaching a saved character (the identity axis).** Three routes reach Flow's
 > `referenceEntities` wire and they dedupe against each other: an `@Name` mention inside
@@ -190,6 +190,10 @@ site can override its class. Among them, Flow's `/about` redirect raises
 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
+A video submit gflow refuses on flow.google.com ([#1178](https://github.com/ffroliva/gflow-cli/issues/1178)) is
+`WireFormatError`, `retryable: false`, aborted before it was sent (its hint says nothing was
+billed): re-running the same inputs usually repeats the refusal, so check the frames or
+references first. The
 second is the migrated **agent-only composer** ([#799](https://github.com/ffroliva/gflow-cli/issues/799)),
 which gflow drives through its chat agent: there `FlowAgentUiError` carries `retryable: false`
 because it means the agent did something other than what was asked — a credit
@@ -582,4 +586,4 @@ values, and signed media URLs before pasting anything into an issue. If you have
 incident bundle, say so — but do not paste it: it contains prompts and can contain
 identity-bearing attributes.
 
-Omni 1.2 uses `model="omni_1_2_flash"` (alias `omni-1.2-flash`), integer durations 3–15 and optional 360p/720p. CLI, direct MCP and queued MCP preserve the explicit model and duration. Unavailable account durations fail before Send; no model fallback or rounding is performed.
+Omni 1.2 uses `model="omni_1_2_flash"` (alias `omni-1.2-flash`), integer durations 3–15 (at most 10 with an `end_frame`: above that Flow drops the end frame and bills a start-only clip, so it is refused before queueing, [#1178](https://github.com/ffroliva/gflow-cli/issues/1178)) and optional 360p/720p. CLI, direct MCP and queued MCP preserve the explicit model and duration. Unavailable account durations fail before Send; no model fallback or rounding is performed.

{gflow_cli-0.96.0 → gflow_cli-0.96.1}/docs/PROJECT_STATUS.md

@@ -4,6 +4,19 @@
 
 ## Current release
 
+**v0.96.1 — alpha.** Omni 1.2 start+end frames, and refused video submits are no longer billed.
+
+**Fixed (#1178, by @Eighty20Digital).** `video i2v --model omni-1.2-flash --end-frame` is no longer
+refused with exit 7: its submit carries a `*_i2v_fl_*` model key gflow did not know. A video submit
+gflow refuses (a dropped frame, the wrong asset) is now stopped before it leaves the browser, so
+Flow bills nothing; before, the check only saw requests already sent. An Omni 1.2 end frame above
+10 seconds is refused before upload, because Flow drops the end frame there and bills a
+start-only clip (reporter's measurement on a Google AI plan).
+
+Full ledger: [LIVE_VERIFICATION_v0.96.1](LIVE_VERIFICATION_v0.96.1.md).
+
+<details><summary>v0.96.0 — Omni 1.2 Flash, Omni r2v lengths, agent-only reload</summary>
+
 **v0.96.0 — alpha.** Omni 1.2 Flash, any Omni r2v length, and a reload past the agent-only composer.
 
 **Omni 1.2 Flash (#1168, by @vietanhjp93).** `--model omni-1.2-flash` (alias `omni-1.2`; MCP
@@ -19,6 +32,8 @@ the classic composer can take gets up to three free reloads before the same exit
 
 Full ledger: [LIVE_VERIFICATION_v0.96.0](LIVE_VERIFICATION_v0.96.0.md).
 
+</details>
+
 <details><summary>v0.95.0 — weekly usage reports after a one-time notice</summary>
 
 **v0.95.0 — alpha.** Weekly usage reports, after a one-time notice, with consent required in the EU/EEA.
@@ -799,6 +814,7 @@ migrated accounts (#795), and the agent-only composer driver (#799, #824 open).
 
 | Milestone | Status |
 |---|---|
+| Omni 1.2 start+end, video submits refused before they are billed, 10s end-frame cap (#1178) | ✅ done (v0.96.1) |
 | Omni 1.2 Flash 3–15s (#1168), Omni r2v 4/6/10s (#1167), agent-only composer reload (#1142) | ✅ done (v0.96.0) |
 | Weekly usage reports after a one-time notice, EU/EEA consent, `gflow telemetry on\|off` (#1164) | ✅ done (v0.95.0) |
 | Local usage counters, `gflow data stats` + `gflow_usage_stats`, `gflow telemetry status\|show` (#1164) | ✅ done (v0.94.0) |

{gflow_cli-0.96.0 → gflow_cli-0.96.1}/docs/USAGE.md

@@ -665,8 +665,8 @@ All prompts in a batch share one Flow project. The editor is opened once and sta
 > **Shared video flags** (`t2v` / `i2v` / `r2v`):
 > `--model [omni-flash|omni-1.2-flash|omni-1.2|veo-lite|veo-fast|veo-quality|veo-lite-lp]`
 > (omit → Flow's current UI default), `--duration [3..15]` (4/6/8 for Veo 3.1;
-> 4/6/8/10 for omni-flash; every integer 3–15 for omni-1.2-flash; 4/6/8/10 when
-> `--model` is omitted),
+> 4/6/8/10 for omni-flash; every integer 3–15 for omni-1.2-flash (at most 10 with `--end-frame`); 4/6/8/10
+> when `--model` is omitted),
 > `--count INTEGER` (1–4; >1 multiplies credit cost), `--aspect [9:16|16:9]`,
 > `--profile NAME`, `--out-dir DIR` (default `tmp/`).
 > **`--duration` support across models**: Flow's settings
@@ -675,7 +675,8 @@ All prompts in a batch share one Flow project. The editor is opened once and sta
 > those controls (positive capture: a third, contributor-owned account on `labs.google`, 2026-09-04, PR #650;
 > the historical negative matrix on `denon82` remains valid for its cohort).
 > 10s needs `omni-flash` or `omni-1.2-flash`; 11–15s needs `omni-1.2-flash` (above 10 needs a
-> Google AI plan, else exit 11 before submit). Passing `--duration 10` with a Veo model
+> Google AI plan, else exit 11 before submit) and no `--end-frame` (with one, Omni 1.2 stops
+> at 10s: Flow drops the end frame above that and bills a start-only clip). Passing `--duration 10` with a Veo model
 > fails fast with exit 2 before any browser work. On a cohort where Flow renders no
 > duration control for Veo, omit `--duration` to accept Flow's default.
 > `--count` is enforced **fail-closed**: if Flow's count control cannot be
@@ -778,7 +779,8 @@ the editor's frame slot via the media dialog, then Flow fires
 > Start-frame picker under the name it was uploaded with (see below), and refuses
 > to submit unless the app's own
 > submit body carries that upload's media id with an image-to-video model key (exit 7
-> otherwise: the labs #125 shape, where an unbound frame silently goes out as text-to-video).
+> otherwise, aborted before it is sent, so nothing is billed (#1178; see exit 7): the labs #125 shape,
+> where an unbound frame would go out as text-to-video).
 > A UUID or `@Name` frame exits 36 there; a local `--end-frame` is ported (#639). An
 > account served labs.google keeps the labs driver for the unported forms.
 >
@@ -865,8 +867,8 @@ gflow video r2v "blend these worlds" --ref a.png --ref b.png --ref c.png --model
 > an `@` **mention** in the prompt — references are not a chip slot on this host. A run
 > whose references have not all attached is refused **before** submit (exit 32), and the
 > app's own submit body must carry every uploaded media id with a reference-to-video model
-> key (exit 7 otherwise) — the failure being a full-price clip with none of your references
-> on it. A character entity is attached there through the composer's `@` picker when
+> key (exit 7 otherwise, aborted before it is sent, so nothing is billed, #1178; see exit 7) — sent, that
+> would have been a full-price clip with none of your references on it. A character entity is attached there through the composer's `@` picker when
 > `--reference-entity` is paired with `--reference-entity-name` (#723), and its chip is
 > verified before submit; an id without a name exits 36, and a video `@Name` exits 29
 > because the character catalog cannot be read on that host.
@@ -882,7 +884,9 @@ gflow video r2v "blend these worlds" --ref a.png --ref b.png --ref c.png --model
 
 Use explicit `--model omni-1.2-flash` (alias `omni-1.2`) with `video t2v`, `i2v`
 or `r2v`. It accepts every integer `--duration` from 3 through 15, and optional
-`--resolution 360p` or `720p`. Omni 1.1 aliases and model defaults are unchanged.
+`--resolution 360p` or `720p`. Start+end `i2v` (`--end-frame`) works since v0.96.1 and stops
+at 10: above that Flow
+drops the end frame and bills a start-only clip, so gflow exits 2 before any upload. Omni 1.1 aliases and model defaults are unchanged.
 On flow.google.com the driver binds the `flow-duration-slider` index and reads
 back the displayed seconds. Missing/changed controls and unavailable durations
 fail before Send; free accounts offer 3–10, Google AI plans offer 3–15.
@@ -2217,7 +2221,7 @@ shell scripts can branch on the failure mode without parsing stderr.
 | `4`  | `RateLimitError`      | Quota / rate limit hit, exhausted retries        | Wait + reduce `GFLOW_CLI_CONCURRENCY`                      |
 | `5`  | `ContentPolicyError`  | Flow rejected the prompt (200 + empty `media[]`) | Soften prompt wording                                      |
 | `6`  | `NetworkError`        | Network failure persisted across 3 attempts. A failed download of media Flow already made (`MediaDownloadError`) is `retryable: false` ([#941](https://github.com/ffroliva/gflow-cli/issues/941)): use `gflow data download` instead of re-running — including a signed-media download whose connection dropped on every attempt ([#895](https://github.com/ffroliva/gflow-cli/issues/895)), or whose signed URL answered an HTTP error such as an expired link (exit 7 until #941 part 2) | Check connectivity — **but read the error's own `remediation_hint` first.** When a *generation* download fails this way the clip was already produced and billed: the hint names it, and `gflow data download <media_id>` recovers it for free. Re-generating pays twice |
-| `7`  | `WireFormatError`     | Unexpected response shape — Flow API changed. **Also `RpcResponseUnavailableError`** (flow.google.com): Chrome lost the reply body of a project create, rename or upload ([#1009](https://github.com/ffroliva/gflow-cli/issues/1009)), or a project create or rename got no reply within 120 s ([#1037](https://github.com/ffroliva/gflow-cli/issues/1037)), and gflow could not confirm the outcome by reading the project back | File a bug (do NOT include captured tokens or signed URLs). **For `RpcResponseUnavailableError` the write may have saved:** open the project and check its title or the uploaded file before re-running, or you may get a duplicate (see [KNOWN_ISSUES](../KNOWN_ISSUES.md)) |
+| `7`  | `WireFormatError`     | Unexpected response shape — Flow API changed. **Also a refused video submit** (flow.google.com, [#1178](https://github.com/ffroliva/gflow-cli/issues/1178)): the submit was not the run asked for (a dropped frame, another asset) and gflow aborted it before it was sent — the hint then says *billed nothing*; without that hint it was already sent and may be billed, so check the project before re-running. **Also `RpcResponseUnavailableError`** (flow.google.com): Chrome lost the reply body of a project create, rename or upload ([#1009](https://github.com/ffroliva/gflow-cli/issues/1009)), or a project create or rename got no reply within 120 s ([#1037](https://github.com/ffroliva/gflow-cli/issues/1037)), and gflow could not confirm the outcome by reading the project back | File a bug (do NOT include captured tokens or signed URLs). **For `RpcResponseUnavailableError` the write may have saved:** open the project and check its title or the uploaded file before re-running, or you may get a duplicate (see [KNOWN_ISSUES](../KNOWN_ISSUES.md)) |
 | `8`  | `AuthMissingError`    | Required auth credential is absent from profile   | `gflow auth login --profile <name>`                        |
 | `9`  | `TransportTimeoutError` | Browser/API operation exceeded its timeout (incl. an i2v frame UUID not found in the media picker, #287; or a wedged submission stage — the error names the stage and your Playwright version) | Retry; raise the relevant timeout. **If the detail says `clicking submit`, `not terminal`, `unreadable` or `was lost`, or `--json` shows `retryable: false`, the submit already went out ([#1010](https://github.com/ffroliva/gflow-cli/issues/1010)): check the project in Flow before re-running, because a re-run bills again.** A lost **image** reply is recovered from the project grid since v0.89.1 ([#1075](https://github.com/ffroliva/gflow-cli/issues/1075)), so exit 9 there means the grid did not show exactly the requested images. A lost **video** reply is followed to the clip when the run uploaded a file (`--ref`, `--initial-frame`, `--end-frame`; [#1112](https://github.com/ffroliva/gflow-cli/issues/1112)), so exit 9 with `unreadable` there means no clip, or more than one, carried the upload. A one-clip t2v run is followed by its exact prompt and model ([#1141](https://github.com/ffroliva/gflow-cli/issues/1141)), so `was lost` there means the project listing could not name exactly one clip; t2v with `--count` above 1 and character-only r2v still exit 9. For a frame-UUID miss verify the UUID belongs to the `--project` passed; for a `stage_stalled` abort check your Playwright is in range (see [KNOWN_ISSUES](../KNOWN_ISSUES.md)) |
 | `10` | `WafRejectionError`   | Flow security layer rejected the request          | Change prompt/request and retry                            |

{gflow_cli-0.96.0 → gflow_cli-0.96.1}/docs/superpowers/memory/credit-free-route-abort-verification.md

@@ -38,6 +38,12 @@ captured request.
   [[flow-credit-free-spike-harness]].
 - Caveat: `route.abort()` proves the SUBMIT payload, not generation success — a
   final paid run still validates poll + download + the response-echo backstop.
+- **On flow.google.com (`batchexecute`), the snippet above bills on a miss.** Raw
+  `post_data` raises on gzip bodies, and a URL-keyed match missed Omni 1.2's body-only
+  `nprQif` (#1178: two clips billed). Route `**/batchexecute**`, read the body with
+  `request_body()`, resolve the rpc with `url_rpcid(url) or body_rpcid(body)`, and run a
+  positive control on the SAME model before route-aborting a paid submit. See
+  [[migrated-host-driver-wire-lessons]].
 
 Relates to [[movie-consistency-feature]], [[rest-path-capability-matrix]],
 [[verification-ledger-5-layer]].

{gflow_cli-0.96.0 → gflow_cli-0.96.1}/docs/superpowers/memory/migrated-host-driver-wire-lessons.md

@@ -156,6 +156,16 @@ rounds); e2e `tests/e2e/test_migrated_host_e2e.py`. Read this before re-mining t
 - **The Ingredients submit is rpcid `MZZa6b`** — not `YhhmEf` (t2v) and not `eb1hJf`
   (i2v). Several rounds of recon reported "r2v never submits" purely because only the
   first was being watched. Any new sub-mode: find its rpcid before concluding anything.
+- **Omni 1.2's start+end submit (`nprQif`) names its rpc in the BODY only** — Omni 1.1's
+  carries it in the URL `rpcids`. A `page.route` keyed on the URL missed both Omni 1.2
+  submits in the #1178 spike and they were billed. Route every `batchexecute`
+  (`BATCHEXECUTE_GLOB`), read bodies with `request_body()` (raw `post_data` raises on
+  gzip), resolve the rpc with `url_rpcid(url) or body_rpcid(body)`, and pass other
+  requests on with `fallback()` so an outer guard (extend) still runs. Its key is
+  `macaron_cookie_i2v_fl_<n>s[_<res>]`.
+- **A `page.on("request")` check cannot stop a bill** — the request is already on its
+  way. Video submits are refused by the route guard in `submit_and_observe` (#1178); the
+  observer stays as the backstop for a request the route never saw.
 - **Enter commits a mention; a typed query alone inserts nothing** and leaves the picker
   open. And mentions need real key events (`keyboard.type`) where prompt text needs
   `insert_text` — the latter dispatches input events with no keystrokes, so the mention

{gflow_cli-0.96.0 → gflow_cli-0.96.1}/docs/superpowers/memory/video-model-capability-matrix.md

@@ -25,6 +25,13 @@ profile carried every reference id under `abra_r2v_{4,8,10}s_360p` (1.1) and
 `macaron_cookie_r2v_{3,8}s_360p` (1.2). The 8s-only r2v rule was measured on Veo Lite
 and still applies to Veo. Spike: `docs/superpowers/spikes/2026-11-07-omni12-duration-slider.md`.
 
+**Update 2026-11-08 (#1178):** Omni 1.2 start+end submits on `nprQif` with
+`macaron_cookie_i2v_fl_<n>s[_360p]` (no resolution suffix at 720p), measured at 8s on
+`denon82`. With an end frame it is capped at 10s: the reporter measured Flow submitting
+12s and 15s without the end frame on a Google AI Ultra account (no account here can
+reach past 10s, so that cap is theirs, not re-measured). Spike:
+`docs/superpowers/spikes/2026-11-08-omni12-interpolation-key.md`.
+
 **🎯 ROOT CAUSE of [[#451]]/#288:** `api/video.py:44` claims "the four `VEO_3_1_*`
 models cap at 8s" — presuming they render a duration control. **They render none.**
 `_select_video_duration` hunts a control the selected model never draws, so the