gflow-cli 0.89.0__tar.gz → 0.90.0__tar.gz

{gflow_cli-0.89.0 → gflow_cli-0.90.0}/.codex-plugin/plugin.json

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

{gflow_cli-0.89.0 → gflow_cli-0.90.0}/.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.89.0 → gflow_cli-0.90.0}/CHANGELOG.md

@@ -7,6 +7,148 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.90.0] — 2026-10-25
+
+### Added
+
+- **`gflow run --resume` picks up where a run stopped**
+  ([#934](https://github.com/ffroliva/gflow-cli/issues/934)). With the same config,
+  project and output folder, a row whose images are already on disk and recorded in the
+  local catalog as that project's is shown as `RESUMED` and not generated again, and a
+  `batch:N` child references it in place. Before, a re-run regenerated every row, parents
+  included, spending image quota twice. `--resume` needs `--project` or a config
+  `"project"` (exit 11 otherwise). CLI only, like `gflow run` itself.
+
+### Fixed
+
+- **`image i2i --ref <file>` no longer uploads the same file again on every run**
+  ([#772](https://github.com/ffroliva/gflow-cli/issues/772)). On flow.google.com, a loop
+  over prompts with one `--ref` file left one copy of that image in the project's library
+  per run. The first upload is now recorded in the local catalog, and a later run in the
+  same project with the same file (same path, same bytes) mentions that image in place.
+  If it was deleted from the project since, the file is uploaded again and the new copy
+  recorded. The MCP image tool does the same. On labs, a file not yet recorded in the
+  project still goes through the editor's own filename dedup (#314).
+
+- **A corrupt cookie store is no longer reported as a network problem**
+  ([#796](https://github.com/ffroliva/gflow-cli/issues/796)). When a profile's Chrome
+  cookie database could not be read as a database, `gflow auth status` said "check
+  network connectivity". It now names the cookie store and says to close any Chrome
+  window using the profile and run `gflow auth login` again. The MCP `gflow_auth_status`
+  tool returns a new `cookie_store_unreadable` outcome (HTTP 409, `retryable: false`)
+  instead of the retryable `verification_error` (#796).
+
+- **The MCP `wait` parameter is described where agents read it**. `gflow_generate_image`
+  and `gflow_generate_video` now carry a `wait` description in `tools/list`: the default
+  `true` runs the generation inside the call, which can outlast a client's tool timeout,
+  and `false` only enqueues it and returns a `task_id` for `tasks/get`. It also says that
+  no gflow command runs the queue worker yet, so a `wait=false` job is never generated
+  (`tasks/get` keeps reporting it as `working`; #1097). The default is unchanged. See
+  [MCP](docs/MCP.md) (#481).
+
+- **`movie run` refuses costume `variants` on an entity character**
+  ([#724](https://github.com/ffroliva/gflow-cli/issues/724)). A variant appends a text
+  delta to the prompt, but an `identity = "entity"` character's body reference already
+  fixes one outfit, so the two contradicted each other inside one generation with no
+  telling which would win. Such a manifest used to run; it is now a configuration error
+  (exit 11) when it is parsed, before any browser starts, and the message says what to do
+  instead: one entity per costume, sharing the same `face_prompt`. Variants on
+  `identity = "text"` characters are unchanged.
+
+- **An output folder gflow cannot write is exit 11, not "Unexpected error"**
+  ([#1091](https://github.com/ffroliva/gflow-cli/issues/1091)). After a successful
+  generation, a failed local write (for example `--out` pointing at a protected folder)
+  kept the media id (#1035) but then ended in the catch-all, with exit 1 and a "file a
+  bug" message. It now ends as a configuration error (exit 11) that says the asset is
+  still in the Flow project. This covers image downloads, upscale and extend exports and
+  scene output, on both the CLI and MCP; a generated video clip keeps its exit 6
+  ([#1003](https://github.com/ffroliva/gflow-cli/issues/1003)).
+
+- **A credit shortfall on flow.google.com is recognised in every UI language, and only
+  when Flow shows it** ([#745](https://github.com/ffroliva/gflow-cli/issues/745)). The
+  warning anchor had an English `aria-label` half, which Flow translates; it is now the
+  warning button's class alone (the measured element carries both). And the check now
+  requires the warning to be visible, so a hidden one Flow keeps mounted cannot turn a
+  real selector drift into "top up your credits" (exit 37).
+
+- **Selector drift is watched again, on flow.google.com**
+  ([#1083](https://github.com/ffroliva/gflow-cli/issues/1083)). The nightly GitHub
+  `selector-probe` workflow loaded the labs.google editor, which redirects to
+  flow.google.com for every account we hold, so it failed as "no recognizable editor" on
+  every run from 2026-08-21 and checked nothing. The selector registry gains a
+  `migrated_editor` surface built from the migrated composer's own constants, graded by a
+  new `$0` `e2e_auth` test that the local canary runs nightly (`run_canary.py --project`);
+  the dead workflow is retired. The canary's labs REST upload test now skips with the
+  measured reason (labs.google serves no session token) instead of reading as RED.
+
+- **The flow.google.com reference-to-video chip-count refusal states the numbers it
+  compared** ([#745](https://github.com/ffroliva/gflow-cli/issues/745)). The guard counts
+  image references and characters together, but the message printed only the image
+  count, so a mismatch caused by a character read as "1 requested but 1 on the prompt".
+  It now reads, for example, "1 image reference(s) + 1 character(s) = 2 chip(s) requested
+  but 1 on the prompt".
+
+### Changed
+
+- **A signed media URL that answers an HTTP error is a failed download, exit 6, not
+  exit 7** ([#941](https://github.com/ffroliva/gflow-cli/issues/941), part 2). After Flow
+  reports a clip done, an error status on its download link (an expired link, for example)
+  used to raise `WireFormatError` (exit 7) and leave the clip `pending` in the catalog. It
+  now raises `MediaDownloadError` (exit 6, `retryable: false`) naming the clip, so the
+  catalog marks it generated and `gflow data download <media_id>` recovers it for free.
+  Scripts that branch on exit 7 for this case should branch on 6.
+
+## [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
@@ -6525,7 +6667,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.89.0...HEAD
+[Unreleased]: https://github.com/ffroliva/gflow-cli/compare/v0.90.0...HEAD
+[0.90.0]: https://github.com/ffroliva/gflow-cli/compare/v0.89.1...v0.90.0
+[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

{gflow_cli-0.89.0 → gflow_cli-0.90.0}/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:
@@ -393,7 +394,7 @@ has not landed yet stay nameless until the next sync sweep.
 
 ### `gflow run --config` references cannot resume (#913)
 
-- **Status:** Open · **Severity:** Low (a re-run regenerates; nothing is lost) · **Affected:** every `gflow run --config` with `"ref"` rows (`batch:N` or a local file)
+- **Status:** Mitigated ([#934](https://github.com/ffroliva/gflow-cli/issues/934): `gflow run --resume`) · **Severity:** Low (a re-run regenerates; nothing is lost) · **Affected:** every `gflow run --config` with `"ref"` rows (`batch:N` or a local file)
 - **Tracked:** [#913](https://github.com/ffroliva/gflow-cli/issues/913)
 
 A run with `"ref": "batch:N"` rows has no resume: a re-run creates a new project (or, with
@@ -402,6 +403,10 @@ it. The handle that makes in-place referencing work (Flow's reply for the parent
 only within the run that generated it. A local-file `ref` is uploaded again into the
 re-run's new project for the same reason.
 
+**Mitigation:** `gflow run --resume` with the same project and output folder skips every
+row whose files are on disk and recorded in the catalog as that project's images, and its
+`batch:N` children reference it in place. A local-file `ref` is still uploaded again.
+
 ### Video duration control is absent on some account cohorts
 
 - **Status:** Mitigated — fail-fast shipped in
@@ -845,7 +850,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 +858,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 +1486,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.89.0 → gflow_cli-0.90.0}/PKG-INFO

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

{gflow_cli-0.89.0 → gflow_cli-0.90.0}/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.89.0 → gflow_cli-0.90.0}/docs/AUTHENTICATION.md

@@ -281,7 +281,7 @@ Probing Flow session (may take up to ~45s on a slow network)...
 Flow session verified as you@example.com.
 ```
 
-> Note: `cookies_present: True` only confirms the file exists. The final verdict line is the live probe result, and it has three failing shapes — all exit 1, each with a different hint. A **dead session** prints a `gflow auth login` remediation hint. A probe that **cannot reach the endpoint** (offline, 5xx) suggests checking connectivity instead of re-logging in. And a profile **missing its `.gflow_browser_strategy` marker** — the state a failed *first* login leaves behind, since that rolls the marker back — says so and points at `gflow auth login --browser chrome --profile <name>`; it is local profile state, not a network fault, and "check connectivity" would send you to the wrong place ([#796](https://github.com/ffroliva/gflow-cli/issues/796), 0.73.2). The MCP twin `gflow_auth_status` reports the same three as HTTP 401, 503 (`retryable: true`) and 409 (`retryable: false`) — see [MCP.md](MCP.md).
+> Note: `cookies_present: True` only confirms the file exists. The final verdict line is the live probe result, and it has four failing shapes — all exit 1, each with a different hint. A **dead session** prints a `gflow auth login` remediation hint. A probe that **cannot reach the endpoint** (offline, 5xx) suggests checking connectivity instead of re-logging in. And a profile **missing its `.gflow_browser_strategy` marker** — the state a failed *first* login leaves behind, since that rolls the marker back — says so and points at `gflow auth login --browser chrome --profile <name>`; it is local profile state, not a network fault, and "check connectivity" would send you to the wrong place ([#796](https://github.com/ffroliva/gflow-cli/issues/796), 0.73.2). A **corrupt or unreadable cookie store** says so and tells you to close any Chrome window using that profile, then run `gflow auth login --profile <name>` again; if that login reports the same, its hint names the last resort: delete the profile's `Default/Network/Cookies` file (this signs the profile out) and log in again ([#796](https://github.com/ffroliva/gflow-cli/issues/796), 0.90.0). The MCP twin `gflow_auth_status` reports the four as HTTP 401, 503 (`retryable: true`), 409 (`retryable: false`) and 409 (`cookie_store_unreadable`, `retryable: false`) — see [MCP.md](MCP.md).
 
 ### `gflow auth renew`
 

{gflow_cli-0.89.0/website → gflow_cli-0.90.0}/docs/CONFIGURATION.md

@@ -407,8 +407,9 @@ unaffected and always opens where you can see it.
 | animation frames / 100 ms timer ticks in 5 s | 300 / 50 | 295 / 50 |
 
 Chrome does not throttle an off-screen window: the page still counts as visible.
-Windows clamps very large offsets, so `-30000,-30000` lands at `-21845,-21845`, still
-past any monitor, on every launch measured. A visible position such as `100,100` opened
+On Windows, `-30000,-30000` landed at `-21845,-21845` (a clamp) on every launch measured
+in September 2026, and at `-30000,-30000` unclamped from 2026-10-25. Either way it is past
+any monitor. A visible position such as `100,100` opened
 exactly there on 8 of 10 launches. In the other two the window was found elsewhere, and
 once it was seen moving mid-run: a visible window can be moved like any other once it
 is open. Not yet measured on macOS or

{gflow_cli-0.89.0 → gflow_cli-0.90.0}/docs/DATA_LAYER.md

@@ -210,7 +210,8 @@ async worker (which mirrors its `generation_queue.error_json` failure into
   (`MediaDownloadError`, exit 6, `error_type=media-download`, #896) also marks that
   clip's asset `MEDIA_GENERATION_STATUS_SUCCESSFUL`: the operation failed, the
   generation did not, and `gflow data download <media_id>` recovers it for free. An
-  HTTP error answer on the signed URL (e.g. an expired link) still leaves it `pending`.
+  HTTP error answer on the signed URL (e.g. an expired link) is the same
+  `MediaDownloadError` and marks it the same way (#941; it was exit 7 and stayed `pending`).
 - A poll that COMPLETES with a Flow-reported failure (`succeeded=false`) is
   recorded as `failed` with `error_type=generation-failed` and the
   `failure_reasons` as detail — not as a success.

{gflow_cli-0.89.0 → gflow_cli-0.90.0}/docs/E2E_TESTING.md

@@ -340,54 +340,36 @@ tokens**. Published content is sanitized for a public repo: SHA, pass/fail
 counts, duration, failure class, and failing test *names* only — never raw logs,
 profile paths, prompts, or signed URLs.
 
-## Selector drift probe (#563)
+## Selector drift check (#563, moved to the canary in #1083)
 
-The canary answers *"does gflow still work on the maintainer's cohort?"*; the
-probe answers *"which Flow DOM selector moved?"* — from hosted CI, with no
-maintainer machine involved. It walks the structured selector inventory in
-`gflow_cli.flow_selectors` (the incident families from #404/#493/#313) against
-a live editor at the pinned 1920×1080 viewport: navigate and read only, **$0**,
-never submits.
+The canary answers *"does gflow still work on the maintainer's cohort?"*; the drift check
+answers *"which Flow DOM selector moved?"*. It grades the structured selector inventory in
+`gflow_cli.flow_selectors` against a live editor: navigate and read only, **$0**, never
+submits.
 
-Runs via `.github/workflows/selector-probe.yml` on `schedule` (05:00 UTC daily)
-plus `workflow_dispatch`. **Never add a `pull_request` trigger**: same-repo
-branch PRs receive repository secrets while running attacker-editable probe
-code (fork PRs are safe — GitHub withholds secrets — but the same-repo case is
-not).
+**Where it runs.** `tests/e2e/test_migrated_selector_drift_e2e.py` (`e2e_auth`) grades the
+registry's `migrated_editor` surface (flow.google.com) with the probe's own `resolve` and
+report, so the nightly canary runs it with every other `$0` tier. Give the canary a project
+the profile owns: `run_canary.py --project <id>` (or `register_task.ps1 -Project <id>`);
+without one the test skips.
 
-### Exit contract
+**Why it moved.** It used to run from `.github/workflows/selector-probe.yml` against the
+labs.google editor with one NextAuth cookie. labs answers 308 to flow.google.com for every
+account we hold, so that workflow exited 2 ("no recognizable editor") on every run from
+2026-08-21 until it was retired, about two months in which nothing watched for drift
+(#1083). Running it in GitHub would now need a full Google session in repository secrets;
+the canary already holds a warm profile on the maintainer's machine.
 
-| Exit | Meaning | Action |
+### Reading the report
+
+| Grade | Meaning | Action |
 |---|---|---|
-| `0` | every registered selector resolved (`ok` / `FALLBACK[n]` / `n/a`) | none |
-| `1` | **drift** — a selector graded MISS or AMBIGUOUS; the report names its key | re-derive that selector, ship a registry edit |
-| `2` | **inconclusive** — expired token, dead project, known alternate UI state, or no recognizable editor arm | fix the credential/project; says nothing about Flow |
-
-Keeping `1` and `2` apart is the whole design: an expired credential must never
-be published as "Google changed the page". The deciding gate is a poll on
-production's own arm indicators (the six `crop_*` variants ⇒ classic, the
-agentic ligatures ⇒ agentic); a page showing neither within 25 s — a sign-in
-wall renders neither — is inconclusive, not drift. Mode-scoped selectors absent
-on the observed arm grade `n/a` (`EXPECTED_ABSENT`), never drift — the probe's
-first two live runs landed on opposite arms (classic locally, agentic on the
-runner) and both graded clean.
-
-### Secrets and token care
-
-Two repository secrets, from a **dedicated throwaway Google account**, never
-the maintainer's: `GFLOW_CI_SESSION_TOKEN` (the
-`__Secure-next-auth.session-token` cookie) and `GFLOW_CI_PROJECT_ID` (any
-project that account owns — a deleted id renders an error shell the probe
-reports as exit 2).
-
-The token **re-issues on every profile open** (observed live 2026-08-21: three
-values in 15 minutes; the first CI dispatch failed exit 2 on a superseded
-snapshot). Harvest accordingly: open the throwaway profile once, read the
-cookie, close the browser, `gh secret set GFLOW_CI_SESSION_TOKEN` from stdin —
-and never reopen that profile without re-syncing the secret afterwards. The
-value also hard-dies at day 30 with no warning. Either way an aged token shows
-as a red exit-2 run, never as drift, and the nightly schedule itself is the
-aging test.
+| `ok` / `FALLBACK[n]` | the selector resolved (a later candidate held for `FALLBACK`) | none; a FALLBACK says how far the page drifted |
+| `n/a` | a mode-scoped entry is absent on the arm Flow served (e.g. the agent-only composer's anchor on a classic account) | none |
+| `DRIFT` / `AMBIGUOUS` | the selector matched nothing, or more than one element where one is expected | the canary turns RED and names the key; re-derive that selector and edit the registry |
+
+`scripts/probe/run_probe.py` still holds `resolve` and `render_report`; its labs `editor`
+surface is kept for an account that is served labs, which none of ours is today.
 
 ---
 
@@ -403,6 +385,7 @@ tests/
     ├── conftest.py                       # e2e_profile_dir, e2e_nosession_profile,
     │                                     #   e2e_env (shared fixtures)
     ├── test_auth_verification_e2e.py     # [e2e, e2e_auth]
+    ├── test_migrated_selector_drift_e2e.py # [e2e, e2e_auth] registry vs flow.google.com — 0 credits
     ├── test_auth_renew_e2e.py            # [e2e, e2e_auth] `gflow auth renew` leaf — 0 credits
     ├── test_credits_refresh_e2e.py       # [e2e, e2e_auth] `--refresh` on CLI + MCP — 0 credits
     ├── test_transports_e2e.py            # [e2e, e2e_{auth,image,batch,video}]