gflow-cli 0.88.0__tar.gz → 0.89.1__tar.gz

{gflow_cli-0.88.0 → gflow_cli-0.89.1}/.codex-plugin/plugin.json

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

{gflow_cli-0.88.0 → gflow_cli-0.89.1}/.env.template

@@ -242,6 +242,12 @@
 # derivation (tab title / page hints) fails.
 # GFLOW_CLI_PROJECT_NAME=
 
+# Default Flow project id for image t2i/i2i, video t2v/i2v/r2v, `gflow run`
+# and the MCP generate tools when no --project / --project-name is given (#1039).
+# Unset = a new project per run. Never used by extend, upscale, scene, character
+# or instructions. See docs/CONFIGURATION.md#gflow_cli_project.
+# GFLOW_CLI_PROJECT=
+
 # -----------------------------------------------------------------------------
 # Debugging (see docs/CONFIGURATION.md; HAR/traceback are opt-in and can
 # expose secrets)

{gflow_cli-0.88.0 → gflow_cli-0.89.1}/.github/workflows/governance-advisory.yml

@@ -39,3 +39,10 @@ jobs:
           git fetch --no-tags origin "$BASE_REF" || true
           uv run python scripts/ci/check_materiality.py \
             --base "origin/$BASE_REF"
+
+      - name: Gutted docs + orphaned references to deleted paths (advisory, #713)
+        # Same `env:` pattern as above — never interpolate BASE_REF into the body.
+        env:
+          BASE_REF: ${{ github.base_ref }}
+        run: |
+          uv run python scripts/ci/check_deletions.py --base "origin/$BASE_REF"

{gflow_cli-0.88.0 → gflow_cli-0.89.1}/CHANGELOG.md

@@ -7,6 +7,177 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.89.1] — 2026-10-24
+
+### Added
+
+- **An advisory CI check for what a change silently removes**
+  ([#713](https://github.com/ffroliva/gflow-cli/issues/713)). `scripts/ci/check_deletions.py`,
+  run by the Governance advisory workflow, warns when a Markdown doc under `docs/` or at the root loses far more lines than
+  it gains (more than 50 net and 3x), and lists every tracked file still referencing a path the
+  PR deletes (e.g. a Dependabot `directory:` entry). It never fails the build.
+
+### Fixed
+
+- **A redirect to flow.google.com/about now names the one measured cause**
+  ([#1080](https://github.com/ffroliva/gflow-cli/pull/1080), superseding [#881](https://github.com/ffroliva/gflow-cli/pull/881); [#902](https://github.com/ffroliva/gflow-cli/issues/902)).
+  Exit 31 used to say only "open the project in a browser". On the account that
+  reproduces it, the cause was Google asking the account to "Confirm it's you" while its
+  cookies were healthy; the hint now says to run `gflow auth login`, which waits on that
+  check. The exit code and `retryable: false` are unchanged.
+
+- **Upscaling an image right after generating it no longer fails as selector drift**
+  ([#1067](https://github.com/ffroliva/gflow-cli/issues/1067)). Flow lists a just-made
+  tile on the project grid only after a reload, so the upscale waited 30 s on a page that
+  could never show it and ended in exit 23. It now reloads the grid every 10 s within the
+  same budget: three grid loads for an image upscale, two for a video upscale (the video
+  reload is covered offline; the live run was the image upscale).
+
+- **An image whose reply Chrome loses is still returned** on flow.google.com
+  ([#1075](https://github.com/ffroliva/gflow-cli/issues/1075)). Flow made the image every
+  time; only the submit reply's body was unreadable, and the run ended in exit 9. gflow
+  now reads the new tile off the project grid and downloads it. When the grid does not
+  show exactly the requested number of new images, the run still stops with exit 9, now
+  naming the project page to check.
+
+- **A hidden model picker on flow.google.com is refused instead of trusted**
+  ([#788](https://github.com/ffroliva/gflow-cli/issues/788)). When the picker was in the
+  page but hidden (an agent-mode screen), gflow read its text, took the requested model as
+  already selected, and went on to generate with whatever Flow had bound, billing it.
+  Image and video runs now stop with exit 23 before submitting, naming the hidden picker.
+
+- **An image Flow refuses on upload is reported as declined, not as a broken reply**
+  ([#755](https://github.com/ffroliva/gflow-cli/issues/755)). When Flow answers an upload
+  with its INVALID_ARGUMENT refusal (measured for a 1x1 PNG), the error now says Flow
+  declined the image and suggests a normal-sized one, instead of "answered 200 without a
+  media id". The exit code (27) is unchanged.
+
+- **A successful `character create` keeps the character's id and name in the local
+  catalog** ([#737](https://github.com/ffroliva/gflow-cli/issues/737)). The completion
+  record replaced the whole metadata column, so succeeded rows kept the voice and media
+  ids but lost which character they belonged to (0 of 104 rows on one machine). The
+  `entity_id` and `name` written when the create started are now carried over.
+
+## [0.89.0] — 2026-10-23
+
+### Added
+
+- **MCP `gflow_list_models`** ([#883](https://github.com/ffroliva/gflow-cli/issues/883)).
+  MCP clients can now read the model catalog that `gflow models --json` prints (names,
+  Flow menu labels, accepted aliases, reference caps, durations, aspects, tiers) instead
+  of hard-coding one. It needs no profile or browser and spends nothing.
+
+- **`GFLOW_CLI_PROJECT` sets a default project**
+  ([#1039](https://github.com/ffroliva/gflow-cli/issues/1039), reported by @error-Sench).
+  Every generation run without `--project` used to create a new Flow project, so a loop
+  of `image t2i` calls left one project per call. Set `GFLOW_CLI_PROJECT=<id>` (in the
+  environment or `.env`) and `image t2i`/`i2i`, `video t2v`/`i2v`/`r2v`, `gflow run`
+  and the MCP generate tools use that project instead, printing a line on stderr that
+  says so. `--project` and a typed `--project-name` still win (`GFLOW_CLI_PROJECT_NAME`
+  names the pinned project instead). It is never used by `extend`, `upscale`, `scene`,
+  `character` or `instructions`, where `--project` means a specific existing project;
+  `image batch` and `image upload` have no `--project` and are unchanged. A pin the local catalog records only under another profile is
+  refused before a browser starts (exit 2), because a project belongs to one account.
+
+- **`gflow models` shows the name Flow's menu uses**
+  ([#1038](https://github.com/ffroliva/gflow-cli/issues/1038), reported by @error-Sench).
+  Each image model now has a `label` in the table and in `--json`: Nano Banana 2.1,
+  Nano Banana Pro, Nano Banana 2 Lite. `NARWHAL`'s label also names labs' Nano Banana 2,
+  and Imagen 4 is marked as no longer in Flow's menu. `--model nano2.1` and `nano-2.1`
+  (and the same values in a batch file, a `gflow run` config and over MCP) now select
+  the `nano2` tier, the one Flow calls 2.1. `character create --model` keeps its own two
+  choices. A model-selector hint on flow.google.com named `nano-banana-2`, which `--model`
+  rejects; it now says `nano2`.
+
+### Fixed
+
+- **A rejected upload (exit 27) now writes an incident bundle**
+  ([#770](https://github.com/ffroliva/gflow-cli/issues/770)). The error can only say that
+  some dialog opened after the file was chosen; the bundle's screenshot shows which one.
+
+- **An upscale or extend on the same client after a flow.google.com run no
+  longer fails with a reCAPTCHA error** ([#914](https://github.com/ffroliva/gflow-cli/issues/914)).
+  After an image, video or upload run gflow parks its page on `about:blank`, and the
+  next call read that page as the labs host and tried to mint reCAPTCHA there. The
+  route now remembers that the page was parked from flow.google.com. This was reachable when one
+  `FlowApiClient` was reused in a script; a single CLI run or MCP task was not affected.
+
+- **A failed download of a finished, billed clip is no longer marked `retryable`**
+  ([#941](https://github.com/ffroliva/gflow-cli/issues/941), part 1). `MediaDownloadError`
+  inherited `retryable: true` from `NetworkError`. A scheduler that re-runs anything
+  retryable would generate, and pay for, the clip a second time. On the generation
+  downloads (flow.google.com and labs), the clip writer and the image download (whose
+  re-run spends daily quota again), it is now `retryable: false`
+  in `--json`, MCP envelopes and the worker record. The fix is `gflow data download` /
+  `gflow_download_media`, which spends nothing and stays `retryable: true`. Exit code 6
+  is unchanged.
+
+- **flow.google.com failure diagnostics no longer leak account identifiers**
+  ([#890](https://github.com/ffroliva/gflow-cli/issues/890)). When the image submit
+  button was covered, the drift error named the covering element with its raw `id` and
+  class list, which on a signed-in page can hold the account email. It now names only
+  the tag and framework class tokens (`div.glue-cookie-notification-bar`), as the click
+  post-mortem already did. The composer also stopped writing its own screenshot and
+  DOM snapshot into `<out>/ui-failures/`. Those files sat outside the incident bundle's
+  review boundary and retention, and the snapshot carried the page title. The incident
+  bundle still captures both.
+  The same holds on the remaining paths
+  ([#1062](https://github.com/ffroliva/gflow-cli/issues/1062)): the labs count-panel DOM
+  dump (page title, element ids, class lists, labels and text) is removed, the debug
+  screenshots written next to your output now follow `GFLOW_CLI_INCIDENT_CAPTURE`, and
+  agent-mode recovery errors show the page URL without its query.
+
+- **A profile open in your own Chrome window is now exit 11 with a clear message, not
+  an unexpected error** ([#984](https://github.com/ffroliva/gflow-cli/issues/984)). When
+  a Chrome you opened yourself holds the profile, Chrome refuses gflow's launch with
+  "the profile is already in use by another instance". That text matched none of the
+  checks for a stale gflow browser, so `credits user` (and any generation command)
+  ended in `UnexpectedError`, exit 1. It is now `ProfileLockedError` (exit 11, MCP
+  `profile-locked`), telling you to close that window or use another `--profile`.
+  `auth login` (both `--browser internal`, which exited 1, and `--browser chrome`,
+  which fell back to a second launch and exited 8) and the Playwright cookie read do
+  the same ([#1059](https://github.com/ffroliva/gflow-cli/issues/1059)).
+
+- **`gflow image batch` reports manifest errors as exit 11, like `gflow run`**
+  ([#935](https://github.com/ffroliva/gflow-cli/issues/935)). The same malformed row
+  exited 11 under `gflow run --config` and 2 under `gflow image batch`. A manifest's
+  contents are configuration, so both now exit 11 with a `Manifest error:` line. That
+  includes a row `ref`, which `image batch` does not support. Scripts that branched on
+  exit 2 for a bad `image batch` manifest need to check 11.
+
+- **Image and video generation into a `--project` id Flow will not open now fails in
+  seconds with exit 11, not as selector drift** ([#974](https://github.com/ffroliva/gflow-cli/issues/974)). Flow
+  answers such an id with its `flow.google.com/404?reason=project` page; gflow waited
+  30 s for the composer and reported exit 23 ("Flow's UI changed"), telling a user with a
+  typo the wrong cause. It now recognises that page by its URL and stops with a
+  configuration error naming the id as not found or not accessible to the account, not
+  retryable, on the CLI and over MCP (`image t2i`/`i2i`, `video t2v`/`i2v`/`r2v`,
+  `gflow run`). `image upscale`, `video upscale` and `video extend` into such a project
+  now end with the same exit 11 instead of exit 23 or a transport timeout (exit 9)
+  ([#1053](https://github.com/ffroliva/gflow-cli/issues/1053)). They still wait out
+  their own page budget (about 30 s) first.
+
+- **A downloaded clip's media id is checked before it becomes a filename**
+  ([#1004](https://github.com/ffroliva/gflow-cli/issues/1004)). Hardening: the local
+  branch of the shared clip saver, used by the flow.google.com and agent-only video
+  downloads, wrote `<media_id>.mp4` without the check the cloud branch applied, and so
+  did `gflow data download`'s flow.google.com recovery. An id holding a path separator
+  is now refused before anything is written.
+
+- **A cloud storage URI with `video -o`, `video chain`, `movie run --stitch` or MCP
+  `output` is refused before billing** ([#1008](https://github.com/ffroliva/gflow-cli/issues/1008)). With
+  `GFLOW_CLI_STORAGE_URI` set to `s3://` or `gs://`, the clip comes back as a bucket
+  object, which `-o/--output` and the MCP video `output` could not move to a local path
+  and `video chain` and `movie run --stitch` could not hand to ffmpeg. Each failed with a raw exception after
+  Flow had billed the clip. gflow now stops before submitting, with exit 11 (an MCP
+  configuration error) naming the setting.
+
+- **`video upscale` no longer says "Image upscale unavailable"**
+  ([#966](https://github.com/ffroliva/gflow-cli/issues/966)). Exit 22's title, shared by
+  the image and video upscale paths, is now "Upscale unavailable for this account" in the
+  CLI message, `--json` and MCP error envelopes. The exit code and `type` are unchanged. A refused
+  2K image upscale no longer advises `--scale 2k`.
+
 ## [0.88.0] — 2026-10-22
 
 ### Added
@@ -6405,7 +6576,9 @@ shell-script template that branches on these codes.
 
 First skeleton. Not functional end-to-end yet.
 
-[Unreleased]: https://github.com/ffroliva/gflow-cli/compare/v0.88.0...HEAD
+[Unreleased]: https://github.com/ffroliva/gflow-cli/compare/v0.89.1...HEAD
+[0.89.1]: https://github.com/ffroliva/gflow-cli/compare/v0.89.0...v0.89.1
+[0.89.0]: https://github.com/ffroliva/gflow-cli/compare/v0.88.0...v0.89.0
 [0.88.0]: https://github.com/ffroliva/gflow-cli/compare/v0.87.1...v0.88.0
 [0.87.1]: https://github.com/ffroliva/gflow-cli/compare/v0.87.0...v0.87.1
 [0.87.0]: https://github.com/ffroliva/gflow-cli/compare/v0.86.0...v0.87.0

{gflow_cli-0.88.0 → gflow_cli-0.89.1}/KNOWN_ISSUES.md

@@ -17,7 +17,7 @@ Living list of behaviour that's broken, surprising, or limited by design — alo
 ### Every command lands on `flow.google.com/about` (exit 31) while `gflow auth status` says the session is fine
 
 - **Status:** Open · **Severity:** High for the affected account (nothing runs) · **Affected:** measured on one account (`denon82`, 2026-09-23). Other `/about` occurrences are not yet shown to share the cause.
-- **Tracked:** [#902](https://github.com/ffroliva/gflow-cli/issues/902) (`auth login` cannot clear it) · [#888](https://github.com/ffroliva/gflow-cli/issues/888) · [#756](https://github.com/ffroliva/gflow-cli/issues/756)
+- **Tracked:** [#902](https://github.com/ffroliva/gflow-cli/issues/902) (`auth login` could not clear it before v0.80.0; it now waits on the check) · [#888](https://github.com/ffroliva/gflow-cli/issues/888) · [#756](https://github.com/ffroliva/gflow-cli/issues/756)
 - **Evidence:** [spike](docs/superpowers/spikes/2026-09-23-about-cta-leads-to-google-reauth.md)
 
 Flow sends every visit to its public landing page `/about`, while every Google and Flow cookie
@@ -27,12 +27,13 @@ waiting for the account to re-verify its identity.
 
 **Through v0.79.1, `gflow auth login` does not fix it.** It sees the valid cookies, reports
 `Flow session verified` in about half a second, and closes Chrome before Google can ask (#902).
-From the next release, the login watches where the page lands. If Flow sends it to `/about`, the
+Since v0.80.0 the login watches where the page lands. If Flow sends it to `/about`, the
 login keeps Chrome open and asks you to press the page's main button and finish "Confirm it's
 you". If you close the window or the time limit runs out first, it exits 12
 (`IdentityRecheckPendingError`) instead of reporting success. The failing state could not be
 reproduced live for this fix, because the one measured account was already cleared by hand. The
-detection is tested offline only.
+detection is tested offline only. Since v0.89.1 a run that lands on `/about` (exit 31) names this
+cause in its hint and points at `gflow auth login --profile <name>` ([#1080](https://github.com/ffroliva/gflow-cli/pull/1080)).
 
 **Workaround (needs the account password):** with no gflow command running, open real Chrome on
 the profile directory yourself:
@@ -845,7 +846,7 @@ The contrasting message, **`no upload request ever left the page`**, means somet
 
 ### Chrome loses a reply body although Flow saved the write (migrated host)
 
-- **Status:** Mitigated · **Severity:** Medium (intermittent; the write usually saved) · **Affects:** the migrated `flow.google.com` host, local uploads (`--initial-frame`, `--ref`, `i2i` files), project create and rename · **Tracked:** [#1009](https://github.com/ffroliva/gflow-cli/issues/1009)
+- **Status:** Mitigated · **Severity:** Medium (intermittent; the write usually saved) · **Affects:** the migrated `flow.google.com` host, local uploads (`--initial-frame`, `--ref`, `i2i` files), project create and rename, image submits · **Tracked:** [#1009](https://github.com/ffroliva/gflow-cli/issues/1009), [#1075](https://github.com/ffroliva/gflow-cli/issues/1075)
 
 Distinct from #719 above, where no reply arrives at all. Here the reply arrives, but Chrome cannot hand its body over: `Network.getResponseBody: No data found for resource with given identifier`. Our spike saw it on 2 of 45 real `maseQ` uploads, and a fresh reload found both uploads saved ([spike](docs/superpowers/spikes/2026-10-20-migrated-upload-reply-body-eviction.md)). Before the fix, gflow reported the upload as a refused file (exit 27).
 
@@ -853,6 +854,8 @@ A project create or rename whose reply is late, not lost, takes the same path: o
 
 **Mitigation:** gflow now opens the project in a second tab and reads the outcome back: the new project's id, the saved title, or exactly one tile with the run's unique file name and a media id. Nothing is submitted twice. The readback can take up to about two minutes on a slow page.
 
+**Image submits (since v0.89.1, [#1075](https://github.com/ffroliva/gflow-cli/issues/1075)).** Flow had made the image every reported time. gflow now reads the run's new tile(s) off the project grid and downloads them, taking exactly the requested count once it holds still for a few seconds; an i2i reference is never counted. Any other count, or a grid it cannot read, still ends in exit **9** (`retryable: false`) naming the project page, and so does a lost **video** submit reply: check the project before re-running.
+
 **If it cannot confirm the outcome**, the command exits **7** with `RpcResponseUnavailableError` (`retryable: false`). The write may have saved. Open the project on flow.google.com and look for the title or the file name in the error before you re-run, or you may get a duplicate project or upload. `gflow run` does not re-upload a reference file after this error in the same run.
 
 ### Flow's release-notes ("What's new") changelog popup blocks first-run UI automation
@@ -1479,6 +1482,7 @@ now names which of three things happened rather than blaming drift:
 | `agent mode was left, but the settings trigger … still did not become visible` | the mode is off — this is real selector drift | file a bug; it is not this issue |
 | `the chip could not be read back, so whether the mode is still on is unknown` | the page went dark mid-recovery | check the **Agent** chip in a browser *before* filing this as drift |
 | `the settings trigger … is not visible — the account is in Flow's agent mode` | the mode flipped **mid-run**, after the editor was already ready | turn the **Agent** chip off in a browser; re-run |
+| `the model picker (arrow_drop_down) is hidden in the settings pane` (since v0.89.1, [#788](https://github.com/ffroliva/gflow-cli/issues/788)) | the pane opened but its model picker is hidden, so `--model` cannot be checked; nothing was submitted | if the **Agent** chip is on, turn it off in a browser; re-run |
 
 **On 0.71.0 and earlier there is no recovery.** Open the project on
 `flow.google.com`, click the **Agent** chip off, and the account works again.

{gflow_cli-0.88.0 → gflow_cli-0.89.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: gflow-cli
-Version: 0.88.0
+Version: 0.89.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.88.0 → gflow_cli-0.89.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.88.0
+ARG GFLOW_VERSION=0.89.1
 RUN pip install --no-cache-dir "gflow-cli==${GFLOW_VERSION}"
 
 VOLUME ["/data"]

{gflow_cli-0.88.0 → gflow_cli-0.89.1}/docs/AGENT_GUIDE.md

@@ -85,6 +85,7 @@ doc changes. Everything else: assess before you build.
 | Conventional branch prefix | `check_repo_hygiene.py::_check_branch_name` | **advisory** (warns; never blocks — platforms create `claude/*` / `dependabot/*` branches, and it no-ops in CI's detached-HEAD checkout) |
 | predict / council on material paths | `governance-advisory.yml` + `check_materiality.py` | **advisory** (recommendation in the job summary) |
 | Traceability (plan reference + tests) | `check_materiality.py` | **advisory** (report-only) |
+| Gutted docs + references to deleted paths | `governance-advisory.yml` + `check_deletions.py` | **advisory** (`::warning::` + job summary; [#713](https://github.com/ffroliva/gflow-cli/issues/713)) |
 
 ### Materiality coverage (path → recommended gate)
 

{gflow_cli-0.88.0 → gflow_cli-0.89.1}/docs/AUTHENTICATION.md

@@ -259,6 +259,13 @@ login paths use it, including the Passive Capture fallback (as Chrome's
 outside `GFLOW_CLI_HOME`. This protects your primary system Chrome profile from
 accidental interference or data corruption.
 
+
+**Profile open in another Chrome window.** If a Chrome window you opened yourself has this
+profile's directory open, Chrome refuses gflow's launch. `gflow auth login`, credits and
+generation then stop with exit 11 (`ProfileLockedError`) and say to close that window or
+use another `--profile` ([#984](https://github.com/ffroliva/gflow-cli/issues/984),
+[#1059](https://github.com/ffroliva/gflow-cli/issues/1059)).
+
 ### `gflow auth status`
 
 Reports where the profile lives, then **proves the session**: it probes the Flow session endpoint with the profile's cookies (no browser, no credits) and exits `0` only when the session is verified — `1` otherwise. Handy for scripts: `gflow auth status && gflow run ...`.

{gflow_cli-0.88.0/website → gflow_cli-0.89.1}/docs/CONFIGURATION.md

@@ -63,6 +63,27 @@ A profile maps to a directory `$GFLOW_CLI_HOME/profile_<name>/`. Profiles are is
 4. Auto: if exactly one `profile_*` dir exists, it's the de-facto default
 5. Fail with the list of available profiles (lowest)
 
+### `GFLOW_CLI_PROJECT`
+
+**What:** Default Flow project id for generation runs that name no project
+([#1039](https://github.com/ffroliva/gflow-cli/issues/1039)).
+**Values:** a Flow project id (1-128 letters, digits or hyphens); anything else fails at startup (exit 11).
+**Default:** unset, so every generation run without `--project` creates a new project.
+**CLI override:** `--project <id>`, or `--project-name <title>` for a new project.
+
+Set, `image t2i`/`i2i`, `video t2v`/`i2v`/`r2v`, `gflow run` and the MCP
+`gflow_generate_image`/`gflow_generate_video` tools generate into it, and say so on stderr.
+
+- `--project` (or a `gflow run` config's `"project"`) wins, and so does a `--project-name`
+  typed on the command line (MCP `project_name`), which asks for a new named project.
+  `GFLOW_CLI_PROJECT_NAME` does not: it names the pinned project.
+- It is ignored where `--project` names the project that owns existing media
+  (`video extend`, `upscale`) or is required (`scene`, `character`, `instructions`).
+  `image batch` and `image upload` have no `--project` and still create their own project.
+- A project belongs to one Google account. When the local catalog records the id only
+  under other profiles, the run is refused before a browser starts (exit 2; MCP: a 400
+  envelope). An id the catalog has never seen is used as given.
+
 ### `GFLOW_CLI_OUTPUT_DIR`
 
 **What:** Root directory where downloaded assets land. Subfolders are created per kind/date.
@@ -467,7 +488,7 @@ per-command `--proxy` flags (the setting covers one-off runs:
 
 **What:** Which Flow frontend gflow drives. Google has moved Flow from `labs.google/fx/tools/flow` onto `flow.google.com` ([#639](https://github.com/ffroliva/gflow-cli/issues/639)) — measured 2026-09-14, the old labs URL answers **HTTP 308 Permanent Redirect** on every account we tested. The two are the same product (the new frontend's own root element is `aisandbox-root`) on different widget toolkits and different wire protocols, so each has its own driver. Which host you are served does **not** tell you which capabilities work — see [the survey](../docs/superpowers/spikes/2026-09-14-two-domain-protocol-survey.md).
 **Values:**
-- `auto` (default) — **`flow.google.com` is the default host for every video request it can serve today** (`video t2v`, local-file `video i2v` and `video r2v`; with no `--project`, one is created first, #864). Image requests use the migrated composer for `image t2i` and local-file `image i2i` where `flow.google.com` is what Flow serves, and stay on labs where labs is. A request the new host cannot serve keeps the labs driver where labs is what Flow serves; where flow.google.com is, there is no labs fallback and unsupported forms exit 36/11 before submit.
+- `auto` (default) — **`flow.google.com` is the default host for every video request it can serve today** (`video t2v`, local-file `video i2v` and `video r2v`; with no `--project` and no `GFLOW_CLI_PROJECT`, one is created first, #864). Image requests use the migrated composer for `image t2i` and local-file `image i2i` where `flow.google.com` is what Flow serves, and stay on labs where labs is. A request the new host cannot serve keeps the labs driver where labs is what Flow serves; where flow.google.com is, there is no labs fallback and unsupported forms exit 36/11 before submit.
 - `flow.google.com` — force the migrated composer for everything, including what it cannot serve yet (those requests then exit 36/11 instead of falling back).
 - `labs.google` — never use the migrated composer; where Flow serves `flow.google.com`, requests fail with exit 36 (kill switch).
 **Default:** `auto`
@@ -503,10 +524,10 @@ per-command `--proxy` flags (the setting covers one-off runs:
 
 ### `GFLOW_CLI_INCIDENT_CAPTURE`
 
-**What:** Automatically writes a **private incident bundle** on relevant operational failures (Flow app crash, agentic-cohort/UI-mode errors, selector drift, transport timeouts, WAF/network/wire-format errors, profile-lock contention, unexpected exceptions while a page is alive) under `<GFLOW_CLI_HOME>/incidents/<YYYY-MM-DD>/<UTC-stamp>-<incident-id>-<rand>/`. See [DEBUGGING § Automatic incident bundles](DEBUGGING.md#automatic-incident-bundles) for the bundle layout and triggers.
+**What:** Automatically writes a **private incident bundle** on relevant operational failures (Flow app crash, agentic-cohort/UI-mode errors, selector drift, transport timeouts, a rejected upload (#770), WAF/network/wire-format errors, profile-lock contention, unexpected exceptions while a page is alive) under `<GFLOW_CLI_HOME>/incidents/<YYYY-MM-DD>/<UTC-stamp>-<incident-id>-<rand>/`. See [DEBUGGING § Automatic incident bundles](DEBUGGING.md#automatic-incident-bundles) for the bundle layout and triggers.
 **Values:** `true` | `false`
 **Default:** `true`
-**When to disable:** shared machines where even structural failure metadata should not persist, or scripted runs that must write nothing outside the output dir.
+**When to disable:** shared machines where even structural failure metadata should not persist, or scripted runs that must write nothing outside the output dir. Disabling it also stops the `debug_*.png` failure screenshots gflow writes next to your output (#1062), so `false` means no page captures at all.
 
 **Privacy:** the automatic artifacts (`manifest.json`, `ui.json`, `network.json`, `browser.json`, and the pre-filled `report.md` bug-report template) are built from an explicit allowlist — no prompts, tokens, cookies, headers, request/response bodies, signed URLs, raw page titles, raw error/console text, or unknown hosts/routes ever enter them. The screenshot is inherently sensitive (it can show your account identity, prompts, and media) and therefore lives under the bundle's `sensitive/` subdirectory — **review it before sharing**. Nothing is ever uploaded; retention is bounded (at most 50 complete bundles / 250 MiB, pruned oldest-first at startup). Raw HAR capture stays separate and strictly opt-in via `GFLOW_CLI_HAR_PATH`.
 
@@ -674,4 +695,4 @@ gflow image t2i "test idea" --profile experiments
 | Every browser step times out, while `curl` and `HTTPS_PROXY` work | Google is reachable only through a proxy, and the browser ignores `HTTPS_PROXY` | Set [`GFLOW_CLI_BROWSER_PROXY`](#gflow_cli_browser_proxy) to the same proxy, then `gflow auth renew` |
 | `ProfileAccessError` (exit code 11) | Chrome cannot write the profile directory (Windows access denied) | Grant write access to the whole profile directory, or use a writable profile. See [Profile-directory permissions](#profile-directory-permissions-at-browser-launch) |
 | Output files don't appear where I expect | Flag > env > .env > default — check actual resolved path | `gflow image t2i ... --verbose` shows the resolved output path |
-| `ProfileLockedError` (exit code 11) | Two concurrent calls against the same profile — the cross-process `ProfileLease` fails fast (never waits) on same-profile contention, whether the second holder is another `gflow` process, the `gflow serve` daemon, or an MCP call | Wait for the first call to finish, or use `--profile other` — different profiles run fully in parallel, each with its own lease |
+| `ProfileLockedError` (exit code 11) | A Chrome window you opened yourself holds the profile (close it, #984), or two concurrent calls against the same profile — the cross-process `ProfileLease` fails fast (never waits) on same-profile contention, whether the second holder is another `gflow` process, the `gflow serve` daemon, or an MCP call | Wait for the first call to finish, or use `--profile other` — different profiles run fully in parallel, each with its own lease |

{gflow_cli-0.88.0/website → gflow_cli-0.89.1}/docs/DEBUGGING.md

@@ -118,6 +118,7 @@ Captured: `FlowAppError` (31), `FlowAgentUiError` (25),
 `UiSelectorDriftError` (23), `FlowAccountChooserError` (38),
 `TransportTimeoutError` (9), `BrowserSessionClosedError` (15),
 `WireFormatError` (7), `WafRejectionError` (10), `NetworkError` (6),
+`MediaUploadRejectedError` (27, [#770](https://github.com/ffroliva/gflow-cli/issues/770)),
 unexpected exceptions while a page is alive, and `ProfileLockedError` (11)
 as a **metadata-only** bundle (no Chrome is launched; the local human output
 also shows the recorded lock owner's PID/start-time evidence — advisory

{gflow_cli-0.88.0 → gflow_cli-0.89.1}/docs/EXTERNAL_STORAGE.md

@@ -45,10 +45,13 @@ local layout:
 
 The layout is the same whichever host Flow serves (labs.google or flow.google.com).
 Before #1003, a flow.google.com video ignored the storage URI and was written locally.
-With a cloud storage URI, `gflow video -o/--output`, `gflow video chain` and an MCP
-`output_file` do not work yet on either host: each needs the clip as a local file
+With a cloud storage URI, `gflow video -o/--output`, `gflow video chain`,
+`gflow movie run --stitch` and an MCP video
+`output` cannot work on either host: each needs the clip as a local file, and the
+clip is a bucket object. gflow refuses that combination before submitting, with exit 11
+(an MCP configuration error), so nothing is billed
 ([#1008](https://github.com/ffroliva/gflow-cli/issues/1008)). Leave the storage URI unset
-for those runs.
+for those runs, or drop the option and fetch the clip from the bucket.
 
 `<ext>` is corrected from the actual bytes before upload. For example, if Flow
 returns JPEG bytes for an image request originally planned as `.png`, the object