gflow-cli 0.76.0__tar.gz → 0.77.0__tar.gz

{gflow_cli-0.76.0 → gflow_cli-0.77.0}/.codex-plugin/plugin.json

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

gflow_cli-0.77.0/.github/workflows/mcp-registry.yml

@@ -0,0 +1,132 @@
+name: MCP Registry
+
+# Publishes server.json to the Official MCP Registry — the listing that feeds the
+# downstream directories (PulseMCP ingests it; GitHub's MCP gallery is built on it).
+#
+# This is CALLED by release.yml (`uses:` + `needs: build-and-publish`), never triggered
+# by an event. Two reasons, both learned the hard way:
+#
+#  1. `on: release: published` does not work here. release.yml creates the Release with
+#     the default GITHUB_TOKEN, and GitHub starts no workflow runs from
+#     GITHUB_TOKEN-created events — so it never fired once, on any release, with nothing
+#     going red (#841). Creating the Release with a user PAT would fix that, at the price
+#     of a credential that expires every 366 days on a path that runs a handful of times
+#     a year. A call has no such fuse.
+#  2. Ordering. `mcp-publisher` proves namespace ownership by reading the `mcp-name:`
+#     token out of the PUBLISHED PyPI README, and PyPI metadata is frozen per release, so
+#     the wheel must be up first. `needs: build-and-publish` enforces that structurally,
+#     rather than by two files happening to agree about step order.
+#
+# Being called also pins the publish to the release TAG, so server.json is the released
+# one — the wrong-ref hazard that republished 0.75.0 over 0.76.0 (#841) cannot arise on
+# this path at all. It still can on a hand dispatch, which is what the guard below is for.
+#
+# Registry auth is GitHub Actions OIDC: the runner exchanges its own short-lived identity
+# token for registry credentials, which is why this needs `id-token: write` and nothing
+# else. No token of any kind is stored for, or handed to, the registry.
+
+on:
+  workflow_call:
+    inputs:
+      version:
+        description: "Version being published, with or without a leading `v`. Must match server.json on the checked-out ref."
+        required: true
+        type: string
+  # Manual re-run, e.g. a release whose registry publish failed after PyPI succeeded.
+  # `version` is REQUIRED because a dispatch publishes whatever the REF carries:
+  # dispatching `develop` before the release back-merge lands republishes the PREVIOUS
+  # version, green, with nothing downstream noticing. That happened on v0.76.0 (#841).
+  workflow_dispatch:
+    inputs:
+      version:
+        description: "Version to publish, e.g. 0.76.0. Must match server.json on the dispatched ref."
+        required: true
+        type: string
+
+# Write scopes live at JOB level (Scorecard Token-Permissions: a workflow-level
+# write grant reaches every job, current and future).
+permissions:
+  contents: read
+
+jobs:
+  publish:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      id-token: write # OIDC exchange with registry.modelcontextprotocol.io
+    env:
+      # Pinned by version AND digest: this step runs in a job holding id-token
+      # write and publishes publicly under io.github.ffroliva, so a moved tag
+      # must not silently change the binary that does it.
+      MCP_PUBLISHER_VERSION: "1.8.1"
+      MCP_PUBLISHER_SHA256: "a06c9096dcb9727c13555b6be26c7effa707b01f06a4c561ba7a3635443cf2cc"
+    steps:
+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
+        with:
+          persist-credentials: false
+
+      - name: server.json must carry the version being published
+        # The repo-side agreement (pyproject == __init__ == plugin.json == uv.lock ==
+        # server.json) is already a merge gate in check_repo_hygiene.py, so the only way
+        # these disagree is publishing from the WRONG REF — which is exactly what
+        # happened on v0.76.0 (#841) and what this catches.
+        #
+        # `inputs` is documented for exactly the two triggers this workflow declares.
+        env:
+          EXPECTED_VERSION: ${{ inputs.version }}
+        run: |
+          set -euo pipefail
+          expected="${EXPECTED_VERSION#v}"
+          if [ -z "${expected}" ]; then
+            echo "::error::No version to check against (neither a dispatch input nor a release tag). Refusing to publish."
+            exit 1
+          fi
+          # Checked explicitly: a missing file would otherwise abort on jq's own error
+          # and lose the diagnostic below, which is the part an operator needs.
+          if [ ! -f server.json ]; then
+            echo "::error::server.json is absent on this ref — nothing to publish."
+            exit 1
+          fi
+          # A pre-release must never become the registry's ACTIVE listing — that is what
+          # PulseMCP and GitHub's MCP gallery ingest. release.yml skips the call for one,
+          # so reaching here means a hand dispatch asked for it explicitly. Refuse anyway.
+          case "${expected}" in
+            *-*|*a*|*b*|*rc*)
+              echo "::error::${expected} is a pre-release. Publishing it would make it the registry's active listing."
+              exit 1
+              ;;
+          esac
+          declared=$(jq -r '.version' server.json)
+          packaged=$(jq -r '[.packages[]?.version] | join(", ")' server.json)
+          if ! jq -e --arg v "${expected}" '.version == $v and all(.packages[]?.version; . == $v)' server.json >/dev/null; then
+            echo "::error::Publishing ${expected}, but server.json on this ref declares ${declared} (packages: ${packaged})."
+            echo "::error::A dispatch publishes whatever the REF carries. Dispatch the release tag, or wait for the back-merge to land on develop (#841)."
+            exit 1
+          fi
+          echo "server.json declares ${declared} on every version site — matches the version being published."
+
+      - name: Install mcp-publisher
+        env:
+          GH_TOKEN: ${{ github.token }}
+        run: |
+          set -euo pipefail
+          archive="${RUNNER_TEMP}/mcp-publisher_linux_amd64.tar.gz"
+          gh release download "v${MCP_PUBLISHER_VERSION}" \
+            --repo modelcontextprotocol/registry \
+            --pattern 'mcp-publisher_linux_amd64.tar.gz' \
+            --output "${archive}" --clobber
+          echo "${MCP_PUBLISHER_SHA256}  ${archive}" | sha256sum -c -
+          tar -xzf "${archive}" -C "${RUNNER_TEMP}" mcp-publisher
+          "${RUNNER_TEMP}/mcp-publisher" --version
+          echo "${RUNNER_TEMP}" >> "${GITHUB_PATH}"
+
+      - name: Validate server.json
+        # Never `init` here: it only writes a TEMPLATE server.json, refuses when a
+        # real one exists, and exits 1 — which would abort the run before login.
+        run: mcp-publisher validate
+
+      - name: Authenticate with the registry (GitHub Actions OIDC)
+        run: mcp-publisher login github-oidc
+
+      - name: Publish
+        run: mcp-publisher publish

{gflow_cli-0.76.0 → gflow_cli-0.77.0}/.github/workflows/release.yml

@@ -16,6 +16,8 @@ jobs:
     permissions:
       contents: write # for creating GitHub Releases
       id-token: write # for PyPI Trusted Publishing (OIDC)
+    outputs:
+      prerelease: ${{ steps.tag_kind.outputs.prerelease }}
     environment:
       name: pypi
       url: https://pypi.org/p/gflow-cli
@@ -64,6 +66,25 @@ jobs:
             exit 1
           fi
 
+      - name: Classify the tag
+        # Single source of truth for prerelease-ness. It gates BOTH the GitHub Release
+        # flag and whether the MCP Registry publish runs at all; as two copies of the
+        # same four-clause expression those would eventually disagree.
+        #   - semver suffixes:  v1.2.3-alpha1, v1.2.3-rc1, v1.2.3-beta1  (any '-')
+        #   - PEP 440 suffixes: v1.2.3a1, v1.2.3b1, v1.2.3rc1            (any a / b / rc)
+        # Stable tags like v1.2.3 contain none of these.
+        id: tag_kind
+        env:
+          TAG: ${{ github.ref_name }}
+        run: |
+          set -euo pipefail
+          case "${TAG}" in
+            *-*|*a*|*b*|*rc*) prerelease=true ;;
+            *)                prerelease=false ;;
+          esac
+          echo "prerelease=${prerelease}" >> "${GITHUB_OUTPUT}"
+          echo "${TAG} -> prerelease=${prerelease}"
+
       - name: Build
         run: uv build
 
@@ -77,8 +98,24 @@ jobs:
         with:
           generate_release_notes: true
           files: dist/*
-          # Pre-release detection covers both conventions:
-          #   - semver suffixes:  v1.2.3-alpha1, v1.2.3-rc1, v1.2.3-beta1   (any '-' qualifies)
-          #   - PEP 440 suffixes: v1.2.3a1, v1.2.3b1, v1.2.3rc1             (any 'a' / 'b' / 'rc')
-          # Stable tags like v1.2.3 contain none of these substrings.
-          prerelease: ${{ contains(github.ref_name, '-') || contains(github.ref_name, 'a') || contains(github.ref_name, 'b') || contains(github.ref_name, 'rc') }}
+          prerelease: ${{ steps.tag_kind.outputs.prerelease == 'true' }}
+
+  mcp-registry:
+    # The registry listing is part of the release, not a follow-up, so it is CALLED here
+    # rather than triggered by the Release above. `on: release: published` never fired
+    # once: the Release is created with the default GITHUB_TOKEN, and GitHub starts no
+    # workflow runs from GITHUB_TOKEN-created events (#841). A user PAT would fix that
+    # and add a 366-day expiry to a path that runs a few times a year; a call adds none.
+    #
+    # `needs:` is also what guarantees the ordering mcp-publisher requires — it reads the
+    # `mcp-name:` token from the PUBLISHED PyPI README, so the wheel must be up first.
+    # And the call runs against this TAG, so server.json is the released one.
+    needs: build-and-publish
+    # A pre-release must never become the registry's ACTIVE listing.
+    if: needs.build-and-publish.outputs.prerelease != 'true'
+    permissions:
+      contents: read
+      id-token: write # OIDC exchange with registry.modelcontextprotocol.io
+    uses: ./.github/workflows/mcp-registry.yml
+    with:
+      version: ${{ github.ref_name }}

{gflow_cli-0.76.0 → gflow_cli-0.77.0}/CHANGELOG.md

@@ -7,6 +7,91 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.77.0] — 2026-09-16
+
+### Fixed
+
+- **Accounts Flow moved to `flow.google.com` could not sign in at all.** Verification used
+  exactly one oracle — `labs.google/fx/api/auth/session` — which answers `200 {}` forever for
+  a migrated account, so a perfectly usable Flow workspace reported *"Signed in to Google, but
+  not to the Flow app"* and gflow refused every command. A total lockout, not a degraded
+  feature. When labs declines **and** the profile carries a `flow.google.com` app-session
+  cookie, gflow now confirms the session against the host that actually serves the app.
+
+  The cookie only **gates** that check; it never decides one. A cookie on disk outlives a
+  password change or a "sign out of all devices", so the decision is where the request lands:
+  a revoked session is redirected off `myaccount.google.com`, which is server-attested in a
+  way page content is not. The account's address is a display label only, so a page reshape
+  cannot cost a user their login.
+
+  **Google Workspace accounts are covered.** An earlier revision gated authentication on an
+  `@gmail.com`-only pattern, which silently declined every custom domain — `dev@axelate.io`,
+  `user@mycompany.com`, even `user@googlemail.com` — leaving this bug open for them while
+  appearing fixed. `docs/AUTHENTICATION.md` documents Workspace SSO as supported.
+  Live-verified on a Workspace account: `AUTHENTICATED`, correct address, 2/2.
+
+  **This also prevents a profile downgrade.** A failed verification rolled the Chrome marker
+  back, flipping `channel_for_profile` from `chrome` to `None` and silently demoting
+  generation to bundled Chromium on a profile created with `--browser chrome`. The rollback is
+  gated on `not verified`, so a verification that now succeeds never triggers it. Measured
+  before and after on the same profile, same cookies: exit 8 / marker gone -> exit 0 / marker
+  intact. ([#791](https://github.com/ffroliva/gflow-cli/issues/791),
+  [#796](https://github.com/ffroliva/gflow-cli/issues/796))
+- **Three lists of "the release version sites" disagreed, and one lived inside the gate that
+  catches the disagreement.** `check_repo_hygiene.py`'s docstring said three files, its own
+  `_check_version_agreement` checked five (six occurrences), and `skills/release/SKILL.md`
+  named a fourth set omitting `server.json` and `uv.lock` — so a release engineer met each
+  omission as a gate failure at the point of highest pressure. There are in fact **seven
+  sites across three separate gates**, and no list knew them all; coverage was complete, but
+  discoverability was not. The skill now carries the one canonical table, its staging step
+  stages all seven, and `tests/test_release_version_sites.py` **parses** that table rather
+  than restating it — a constant would have been the fourth disagreeing copy.
+  ([#839](https://github.com/ffroliva/gflow-cli/issues/839))
+
+### Changed
+
+- **`wait_until="networkidle"` on the `ui_automation` bootstrap is documented, not removed.**
+  [#836](https://github.com/ffroliva/gflow-cli/issues/836) proposed dropping it, on the theory
+  that a held-open connection made it burn the full 45 s ceiling. Measured on a live profile,
+  5 navigations per arm: it fires every time and reached the ceiling **0/5**, so there is no
+  hang — but it costs **3422 ms mean against 1022 ms** for the prescribed pattern, with 4x the
+  spread. Removing it turned the #580/#584 navigation ratchet red: both call sites are in that
+  test's exemption set by name, because `goto(domcontentloaded)` returns 591–797 ms *before*
+  Flow's locale redirect lands and `networkidle` is what absorbs it. The issue read two call
+  sites with different constraints as one contradiction. The measurement and the probe ship so
+  the next reader finds them instead of re-deriving this.
+
+- **The MCP Registry publish never ran — not once, on any release that shipped with it.**
+  `mcp-registry.yml` triggered on `release: published`, but `release.yml` creates the Release
+  with the default `GITHUB_TOKEN`, and GitHub starts no workflow runs from
+  `GITHUB_TOKEN`-created events. Measured on v0.76.0: a real Release published
+  (`draft=false`, `prerelease=false`), the workflow file on the default branch, and
+  `gh run list --workflow=mcp-registry.yml` returning **zero runs, ever**. The trigger was
+  structurally dead rather than mistimed, so it would not have begun working at the next
+  release. `release.yml` now **calls** the workflow (`uses:` + `needs: build-and-publish`)
+  instead of relying on an event, so there is nothing for the token rule to block. A
+  user-owned PAT on the Release step was the alternative and was rejected on maintenance
+  grounds: fine-grained tokens expire after at most 366 days, which puts a scheduled failure
+  on a path that runs a handful of times a year. `needs:` also enforces the ordering
+  `mcp-publisher` requires — it reads the `mcp-name:` token from the *published* PyPI README —
+  which previously rested on two files agreeing about step order. Registry authentication is
+  unchanged: GitHub Actions OIDC, with no token stored for or handed to the registry.
+  ([#841](https://github.com/ffroliva/gflow-cli/issues/841))
+- **A manual registry dispatch could publish a superseded version, green, with nothing
+  noticing.** A dispatch publishes whatever `server.json` says *on the dispatched ref*.
+  Dispatching `develop` after the v0.76.0 tag but before the back-merge landed republished
+  `0.75.0` to the registry, and the run succeeded. Both triggers now take a required `version`
+  input, asserted against every version field in `server.json`, and fail the run on a
+  mismatch instead of publishing. ([#841](https://github.com/ffroliva/gflow-cli/issues/841))
+- **A pre-release would have become the MCP Registry's *active* listing.** `release.yml` fires
+  on every `v*.*.*` tag, including `v1.2.3rc1`, and that listing is what PulseMCP and GitHub's
+  MCP gallery ingest. While the publish was dead this was latent; repairing it would have
+  armed it. The call is now skipped for pre-releases, and the workflow refuses a pre-release
+  version outright if one reaches it by hand. The prerelease classification has a single
+  definition shared by the GitHub Release flag and the registry gate, rather than two copies
+  of the same expression that would drift. Found by council review, not in production.
+  ([#841](https://github.com/ffroliva/gflow-cli/issues/841))
+
 ## [0.76.0] — 2026-09-16
 
 ### Fixed
@@ -5201,7 +5286,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.76.0...HEAD
+[Unreleased]: https://github.com/ffroliva/gflow-cli/compare/v0.77.0...HEAD
+[0.77.0]: https://github.com/ffroliva/gflow-cli/compare/v0.76.0...v0.77.0
 [0.76.0]: https://github.com/ffroliva/gflow-cli/compare/v0.75.0...v0.76.0
 [0.75.0]: https://github.com/ffroliva/gflow-cli/compare/v0.74.0...v0.75.0
 [0.74.0]: https://github.com/ffroliva/gflow-cli/compare/v0.73.2...v0.74.0

{gflow_cli-0.76.0 → gflow_cli-0.77.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: gflow-cli
-Version: 0.76.0
+Version: 0.77.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.76.0 → gflow_cli-0.77.0}/RELEASE.md

@@ -24,6 +24,40 @@ When a tag matching `v*.*.*` is pushed, GitHub Actions:
 4. Creates a GitHub Release and attaches the built artifacts.
 5. Marks tags containing PEP 440 alpha, beta, or release-candidate markers as
    GitHub prereleases.
+6. Publishes `server.json` to the Official MCP Registry — `release.yml` **calls**
+   `mcp-registry.yml` with `needs: build-and-publish`. Full releases only; the call is
+   skipped for prereleases so an `rc` never becomes the registry's active listing.
+
+### Why the registry publish is called, not triggered
+
+Worth knowing before anyone "tidies" it into an event trigger. It used to hang off
+`on: release: published`, and it **never fired once**, on any release, with nothing going
+red ([#841](https://github.com/ffroliva/gflow-cli/issues/841)): GitHub starts no workflow
+runs from events created with the default `GITHUB_TOKEN`, which is what creates the Release
+in step 4.
+
+A user PAT on that step would also fix it, and was rejected: fine-grained tokens expire
+after at most 366 days, so it puts a scheduled failure on a path that runs a handful of
+times a year. **There is no secret to rotate in the current design.** `needs:` additionally
+enforces the ordering `mcp-publisher` requires — it reads the `mcp-name:` token out of the
+*published* PyPI README, so the wheel has to be up first — and the call runs against the
+release tag, so `server.json` is always the released one.
+
+### If the release job fails after PyPI
+
+The PyPI upload is step 3 and the Release is step 4, so a failure in between leaves the wheel
+**already published**. `pypa/gh-action-pypi-publish` runs without `skip-existing`, so re-running
+the workflow fails on the duplicate filename, and re-tagging is not permitted. Recover by hand:
+
+```bash
+gh release create vX.Y.Z --generate-notes dist/*
+gh workflow run mcp-registry.yml --ref vX.Y.Z -f version=X.Y.Z
+```
+
+The registry publish needs its own dispatch because it hangs off the release job via
+`needs:`, so a failed release job means it never ran. Dispatch it against the **tag** — a
+branch publishes whatever `server.json` that branch carries, which is how v0.76.0
+republished 0.75.0.
 
 ## Prerelease Versus Full Release
 

{gflow_cli-0.76.0 → gflow_cli-0.77.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.76.0
+ARG GFLOW_VERSION=0.77.0
 RUN pip install --no-cache-dir "gflow-cli==${GFLOW_VERSION}"
 
 VOLUME ["/data"]

{gflow_cli-0.76.0 → gflow_cli-0.77.0}/docs/DISTRIBUTION.md

@@ -24,7 +24,7 @@ channel no longer accepts anything).
 | Channel | Audience | Submit via | Status | Last verified |
 |---|---|---|---|---|
 | [PyPI](https://pypi.org/project/gflow-cli/) | Python users, every downstream scraper | `uv publish` (release) | listed | 2026-09-14 |
-| [Official MCP Registry](https://registry.modelcontextprotocol.io) | Agent devs; feeds other registries | `mcp-publisher`, automated on release (#829) | **automated — first run is v0.76.0's own release job** | 2026-09-16 |
+| [Official MCP Registry](https://registry.modelcontextprotocol.io) | Agent devs; feeds other registries | `mcp-publisher`, called by `release.yml` (#829; wiring repaired in #841) | **listed** · `0.76.0` active · automation repaired but **not yet exercised** — v0.77.0 is its first real run | 2026-09-16 |
 | [Glama](https://glama.ai/mcp/servers/ffroliva/gflow-cli) | Broad MCP audience (87k servers) | Web form | **listed** · claimed · rated **A** · release **0.75.0** published · Auto-Release on | 2026-09-15 |
 | [MCP Market](https://mcpmarket.com/server/gflow-cli) | Consumer discovery | — (crawled us) | **listed** | 2026-09-14 |
 | [skills.sh](https://skills.sh/ffroliva/gflow-cli) | Cross-agent skill users | — (telemetry) | **listed** | 2026-09-14 |
@@ -55,17 +55,46 @@ channel no longer accepts anything).
 Ranked by reach per hour of work. The eight submissions are out; what is left is gated on one
 thing, and it is not a distribution task.
 
+> ⚠️ **Repaired in #841, and v0.77.0 is the first release that will actually test it.**
+> For every release through v0.76.0 the registry publish never fired. It hung off
+> `release: published`, but `release.yml` creates the Release with the default
+> `GITHUB_TOKEN`, and GitHub starts no workflow runs from `GITHUB_TOKEN`-created events.
+> Measured on v0.76.0 — a real Release published, and the workflow had **zero runs, ever**
+> ([#841](https://github.com/ffroliva/gflow-cli/issues/841)). v0.76.0 was published by hand.
+>
+> **It is now called, not triggered.** `release.yml` invokes `mcp-registry.yml` directly
+> (`uses:` + `needs: build-and-publish`). No event, so nothing for the token rule to block —
+> and no credential to rotate. A user PAT was the other way to fix it and was rejected on
+> maintenance grounds: a 366-day expiry on a path that runs a few times a year is another
+> scheduled silent-ish failure, which is the shape of the bug being fixed.
+>
+> `needs:` is also what enforces the ordering — `mcp-publisher` reads the `mcp-name:` token
+> from the **published** PyPI README, so the wheel must be up first. And the call runs
+> against the release **tag**, so the wrong-ref hazard below cannot arise on this path.
+>
+> **Pre-releases are excluded.** `release.yml` fires on every `v*.*.*` tag including
+> `v1.2.3rc1`, and an `rc` must never become the registry's *active* listing — the one
+> PulseMCP and GitHub's MCP gallery ingest. The call is skipped for them, and the workflow
+> refuses a pre-release version outright if one ever reaches it by hand.
+>
+> **The manual path remains, and its ordering hazard is unchanged.** `gh workflow run
+> mcp-registry.yml --ref <ref> -f version=X.Y.Z` publishes whatever `server.json` says **on
+> that ref**, so dispatching `develop` before the release back-merge lands republishes the
+> *previous* version. That happened on v0.76.0. The `version` input is now required and
+> asserted against `server.json`, so the mismatch fails the run instead of publishing green.
+
 1. **Publish to the Official MCP Registry** — the one that feeds the others (PulseMCP ingests it;
-   GitHub's gallery is built on it). **v0.75.0 is the release that unblocks it**, and this document
+   GitHub's gallery is built on it). **v0.75.0 was the release that unblocked it**, and this document
    ships in it: PyPI metadata is frozen per release, so the rewritten summary, the three sidebar
    links and the ten classifiers take effect on that upload, and `mcp-publisher` can only verify
    ownership once the `mcp-name:` token is in the *published* README.
 
-   **This is now automated.** `.github/workflows/mcp-registry.yml` runs on `release: published`,
-   which fires after `release.yml` has uploaded the wheel, and authenticates with GitHub Actions
-   OIDC — no PAT, no device-code flow, no human step. It becomes live once it reaches the default
-   branch at the next release; `v0.75.0` itself therefore still needed either one manual publish or
-   the arrival of `v0.76.0`.
+   **This is automated as of #841** — it was not before, and v0.76.0 went out by hand.
+   `release.yml` calls `.github/workflows/mcp-registry.yml` as a reusable workflow, with
+   `needs: build-and-publish` so it runs after the wheel is on PyPI, and it authenticates to
+   the registry with GitHub Actions OIDC — **no token is stored for, or handed to, the
+   registry, and none is needed to trigger it.** The call runs against the release tag, so the
+   publish always carries the released `server.json`.
 2. **Check Glama after the next release.** The Dockerfile is built and 0.75.0 is released, which
    met punkpeye's Glama gate. Auto-Release is meant to publish each GitHub release by itself, but
    it has never fired for us yet, and an unpinned build has already used a commit hours out of
@@ -107,7 +136,7 @@ Absolutising them fixes it, but `scripts/ci/check_doc_links.py` validates relati
 disk and would stop checking them — so the fix is absolutise **plus** teach the checker to map our
 own `blob/main/` URLs back to paths. Tracked, not done here.
 
-### Official MCP Registry — submit as soon as v0.75.0 is on PyPI
+### Official MCP Registry — listed since v0.75.0, automated since #841
 
 Schema `2025-12-11`, read live. `ServerDetail` requires `name`, `description`, `version`;
 `description` is capped at **100 characters**; `name` must match `^[a-zA-Z0-9.-]+/[a-zA-Z0-9._-]+$`
@@ -131,9 +160,11 @@ so `uvx gflow-cli mcp run` works — which is also what a user types first, the
 just installed.
 
 Publishing runs in CI: `.github/workflows/mcp-registry.yml`, on `release: published` (plus
-`workflow_dispatch` for a re-run). It authenticates with **GitHub Actions OIDC**, so no personal
-access token is ever created or handed to the registry, and the `mcp-publisher` download is pinned
-by version *and* sha256 because that job holds `id-token: write`.
+`workflow_dispatch -f version=X.Y.Z` for a re-run). It authenticates with **GitHub Actions OIDC**,
+so **no token is ever handed to the registry**, and the `mcp-publisher` download is pinned by
+version *and* sha256 because that job holds `id-token: write`. **No personal access token is
+involved anywhere in this path** — not for the registry, and not to start the workflow: it is
+called by `release.yml` rather than triggered by an event (#841).
 
 The equivalent by hand, if you ever need it locally:
 

{gflow_cli-0.76.0 → gflow_cli-0.77.0}/docs/INDEX.md

@@ -169,7 +169,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.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.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.