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

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

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

gflow_cli-0.78.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.78.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.78.0}/AGENTS.md

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

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

@@ -7,6 +7,284 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.78.0] — 2026-09-17
+
+### Added
+
+- **`--aspect 3:4` images now run on `flow.google.com`.** Flow's image settings there
+  render a fifth aspect radio (`3:4`) that the 2026-09-08 enumeration did not see, so gflow
+  refused it with exit 36. All five image aspects are now driven on both hosts.
+  ([#864](https://github.com/ffroliva/gflow-cli/issues/864))
+
+- **`gflow docs` — the documentation, reachable from the terminal.** 126 pages in `docs/`
+  and nothing in the CLI pointed at any of them, so at the moment of use the knowledge was
+  unreachable and the reader guessed. `gflow docs` lists the topics, `gflow docs <topic>`
+  prints one as raw Markdown (it pipes), and `gflow docs --search <term>` returns the
+  matching lines with `docs/FILE.md:LINE` beside each one. Read-only and offline — no
+  network, no account, no credits.
+
+  **The pages now ship inside the wheel** (`gflow_cli/_docs`; 1.3 MB of Markdown, **+0.58 MB
+  compressed** — the wheel goes 0.74 MB → 1.32 MB), because the user this was filed for
+  installed from PyPI and has no checkout; a command that could only print GitHub links
+  would not solve it. A build hook globs `docs/*.md`, so the topic list cannot drift and
+  `assets/`/`superpowers/` stay out — measured, after `force-include` + `exclude` silently
+  shipped 148 files it was told to exclude. The hook **refuses to build** when it finds no
+  pages: `Path.glob` on a missing directory returns empty, and `release.yml` is `uv build`
+  then publish, with nothing in between that would notice a wheel whose `gflow docs` is
+  empty for every user.
+
+  Search returns a **line, windowed**, not a file name: the rule that prompted this issue
+  lives inside a 4 000-character bullet in `MCP.md`, and answering "it is in MCP.md" leaves
+  the reader where they started. Curated `INDEX.md` § Topic shortcuts rank above raw body
+  text, all query terms must appear on the line, and a vague query reports how many hits it
+  held back instead of quietly truncating. A topic resolves from its slug, its file name,
+  either case or an unambiguous prefix — and never by building a path from what was typed,
+  so `gflow docs ../../etc/passwd` is an ordinary unknown-topic refusal.
+
+  No MCP twin, deliberately (`gflow update` is the precedent); the reasoning is recorded in
+  `cli_docs.py` rather than left implicit.
+  ([#861](https://github.com/ffroliva/gflow-cli/issues/861))
+
+- **`gflow video i2v --end-frame <local file>` now runs on `flow.google.com`.** Start+end
+  frame interpolation was the last i2v form the migrated composer refused: it exited 36
+  ("an end frame is not ported yet") on every account Flow has moved. Both frames are now
+  uploaded through the editor's own Upload entry and bound to the Start and End chips, and
+  the driver reads back two bound chips before it lets the app submit.
+
+  A bound end frame switches Flow to a different submit contract — rpc `nprQif`, an
+  interpolation model key, and both media ids in the body — which is why watching only the
+  classic submit rpcs made every start+end run time out *after* Flow had already accepted
+  the submit and billed it. The submit body is asserted before Flow acts on it, so a frame
+  that silently failed to bind is a refusal rather than a wrong generation you paid for.
+
+  The model key is **cohort-dependent** and matched by shape, not by literal:
+  `veo_3_1_interpolation_lite` and `omni_flash_i2v_8s_first_last` have both been captured
+  on live accounts (the second on 2026-09-17, see
+  `docs/superpowers/spikes/2026-09-17-migrated-end-frame-submit-contract.md`). Frames given
+  by media UUID or `@Name` are still not ported.
+  ([#639](https://github.com/ffroliva/gflow-cli/issues/639))
+
+### Fixed
+
+- **The Frames picker could not bind the frame it had just uploaded.** On
+  `flow.google.com`, `video i2v` matched a picker option with an *anchored* regex
+  (`^\s*<name>\s*$`), but a picker tile is a `mat-icon` ligature followed by the file
+  name and a locator reads both nodes as one string — `imageshero-ab12cd34.png` for an
+  asset named `hero-ab12cd34.png`. The anchors could never hold, so every i2v run on this
+  cohort ended in exit 32, *"the frame picker lists no asset named …"*, while the picker
+  had been listing it the whole time. The match is now containment on the display name,
+  which is run-unique by construction ([#792](https://github.com/ffroliva/gflow-cli/issues/792))
+  and therefore still cannot bind a stale copy of the same file. Covered by a new $0
+  route-intercepted e2e (`tests/features/frame_picker_binding.feature`) that renders the
+  icon node for real — a mocked picker passes against the bug.
+  ([#860](https://github.com/ffroliva/gflow-cli/issues/860))
+
+- **Flow's promo modal blocked the first click on a freshly loaded editor.** On
+  `flow.google.com` a `role="dialog"` panel over a new editor made `image t2i` fail as
+  exit 23 — *".settings-trigger-button did not accept a click within 5000 ms — it is
+  covered by div.cdk-overlay-backdrop"* — telling the user to file a selector-drift bug
+  when one click on the page fixes it permanently.
+
+  `_dismiss_dialog` already existed and its selector already matched. It was called at
+  the one moment it could not see anything: one frame after `domcontentloaded`, before
+  Angular has rendered the modal. That is why a blocked run logged **neither**
+  `migrated.dialog_dismissed` nor `migrated.dialog_not_dismissed` — the silence in the
+  incident's event stream was the evidence, not the absence of it. The dismissal now
+  also runs in `_open_pane`, where the image and video paths take their first click, the
+  same place the `glue` consent bar is already cleared. It stays best-effort: a modal
+  that refuses to go still falls through to the click post-mortem, which names the
+  backdrop, rather than becoming a second competing error path.
+  ([#859](https://github.com/ffroliva/gflow-cli/issues/859))
+
+- **The migrated `--end-frame` lane rejected omni's interpolation key.** The start+end
+  submit validator pinned the model key to `veo_3_1_interpolation_lite`, so
+  `omni_flash_i2v_*_first_last` submits — what the second measured cohort actually sends —
+  were refused as wire-format errors before Flow could act on them. The check is now
+  key-shape based: a submit whose model key contains `interpolation` or `first_last`
+  counts as start+end interpolation for any model, and the submit observer accepts the
+  bare `batchexecute` reply (no `rpcids` param) that the interpolation rpc answers on.
+  ([#639](https://github.com/ffroliva/gflow-cli/issues/639))
+- **Generating without a project works again on accounts Flow serves from
+  `flow.google.com`, and it no longer tells you to log in.** Every run without `--project`
+  (CLI) or `project` (MCP) starts by creating a project through labs.google's
+  `project.createProject`. Google has retired that route: it answers *"Flow RPCs have been
+  deprecated and disabled"* (404), or 401 for a session holding no labs token — measured
+  12/12 on four profiles. gflow reported the 401 as *"Authentication expired — run `gflow
+  auth login`"*, which no login could fix. When that route refuses, gflow now creates the
+  project on flow.google.com's projects page and reads the new id and title from Flow's own
+  reply; `gflow project create` and `gflow project rename` work there the same way.
+  `GFLOW_CLI_FLOW_HOST=labs.google` keeps the labs route and its error. Video runs without a
+  project now get it created up front, like images, so they route exactly as if you had
+  passed `--project`; MCP `gflow_generate_video` also honours `project_name`, which it
+  accepted and then ignored. Thanks to @iceblue03 (#863) and @ChandraLiuswanto (#561) for
+  the reports. ([#864](https://github.com/ffroliva/gflow-cli/issues/864),
+  [#561](https://github.com/ffroliva/gflow-cli/issues/561))
+- **An MCP server no longer fails a call because another call holds the profile.** Two
+  calls on one profile inside one server — a client retry, two agents sharing a server —
+  now run one after the other instead of the second failing with `ProfileLockedError`, and
+  a profile held by another process (a CLI run) is waited out for up to 180 s. A
+  `GFLOW_CLI_LEASE_WAIT_SECONDS` you set yourself, in the environment or a `.env`, still
+  wins. The CLI keeps failing fast. Thanks to @iceblue03 (#862).
+  ([#864](https://github.com/ffroliva/gflow-cli/issues/864))
+
+## [0.77.1] — 2026-09-17
+
+### Fixed
+
+- **A clean Windows install could not run a single command.** `configure_logging`
+  renders TEXT logs with `structlog.dev.ConsoleRenderer(colors=True)`, and structlog's
+  Windows `_init_terminal` raises `SystemError` outright when `colorama` is missing —
+  but `colorama` was never declared, and nothing in the runtime closure supplies it
+  (structlog keeps it an optional extra; rich ships its own Windows console handling).
+  Because the call sits in the Click *group* callback it runs before any subcommand
+  body, so every interactive command on a fresh Windows install aborted with a
+  traceback that named structlog and never gflow — the failure read as a broken
+  install rather than an incomplete one, and it made the README's Windows quick-start
+  fail as written. Piping stderr happened to escape it, since `AUTO` then resolves to
+  the JSON renderer, which is why non-interactive use and CI never saw it.
+
+  The only `colorama` edge in `uv.lock` came from **pytest**, a dev dependency — so
+  every developer machine had it transitively and no gate could see the gap.
+  `colorama` is now a declared `sys_platform == "win32"` runtime dependency, and
+  `tests/test_observability.py` fails if it is dropped again. Reproduced and verified
+  on a clean Python 3.13 venv: the same `gflow doctor` invocation that raised
+  `SystemError` before now runs to completion, on both the CLI and the MCP stdio
+  server. ([#846](https://github.com/ffroliva/gflow-cli/issues/846))
+- **The address scan in the migrated-host session probe was quadratic.** It reads a
+  1.28 MB `myaccount.google.com` response, and `[\w.+-]+@…` retries from every start
+  position and rescans its run before failing to find an `@` — so an unbroken run of
+  characters that class accepts cost O(n²). Measured: 5 000 chars 0.12 s, 10 000 0.48 s,
+  20 000 2.00 s, **40 000 12.07 s**. The class covers the entire URL-safe base64 alphabet,
+  which a Google page is full of, and the scan runs synchronously inside an `async def`,
+  so a stall blocks the event loop and cancellation cannot land until it returns.
+
+  Anchoring on the literal `@` (which lets CPython's `re` use its literal-prefix fast
+  search) and reading the local part backwards over a bounded 64-character window — the
+  RFC 5321 cap — makes the work proportional to the number of `@` in the document. Same
+  output for every address shape, including the Workspace and custom domains that #791
+  turned on: 40 000 chars now scan in under a millisecond, and 440 000 base64-shaped ones
+  in 0.2 ms. ([#852](https://github.com/ffroliva/gflow-cli/issues/852))
+- **The sign-in window never closed for an account Google serves from `flow.google.com`.**
+  `gflow auth login --browser chrome` watches the `labs.google` session endpoint to know
+  when to close Chrome — and for a migrated account labs hands off without ever minting a
+  session, so the one oracle the detector had could not answer. The window stayed open for
+  the full 600 s while the banner promised gflow would close it, and the timeout then
+  propagated *past* verification, so a sign-in that had completed perfectly was discarded
+  unread and the user got exit 12 for a login that worked. It is the first thing a new user
+  on a migrated account meets. v0.77.0 fixed the *verification* for these accounts, which
+  made the outcome correct only for users who closed the window themselves.
+
+  Two changes, and neither of them moves the authentication decision into a cookie. gflow
+  now also stops waiting when the jar carries both halves of a migrated session (the
+  `.google.com` SSO cookie **and** the `flow.google.com` app-session cookie) — that ends a
+  wait which had no other way to end; `verify_flow_profile` still asks a server about what
+  landed on disk, and is still the only thing that can call a login successful. And a
+  timeout no longer discards the profile unread: gflow reads it before failing, reports a
+  sign-in the detector missed as the success it is, and otherwise keeps the timeout's own
+  wording. A caller with no on-disk oracle to fall back on (`--browser internal`) keeps
+  waiting exactly as before. ([#849](https://github.com/ffroliva/gflow-cli/issues/849))
+- **`gflow update` could report a version for an install that no longer starts.** A package
+  manager replaces files in place, so an interrupted upgrade leaves a venv whose *metadata*
+  reads perfectly and whose *imports* are dead. `gflow update` only ever re-read the version,
+  so it called that state *"still 0.69.0"* and sent the user to a plain `uv tool upgrade` —
+  which cannot repair it, because it reads the same intact metadata, finds it current and
+  changes nothing. Measured on Windows: an aborted native-dependency swap left every command
+  dying on `AttributeError: module 'greenlet' has no attribute 'greenlet'`, and only
+  `uv tool install "gflow-cli==<version>" --force --reinstall` completed.
+
+  After the manager runs, `gflow update` now imports gflow-cli in a fresh isolated
+  interpreter *before* it looks at any version, and a failed import is reported as an
+  unusable install (exit 11) quoting that interpreter's own last line, with the forced
+  reinstall as the remediation. The probe is isolated (`-I`) so a `gflow_cli` directory in
+  the caller's working directory cannot answer on the venv's behalf, and a probe that could
+  not run at all is never reported as breakage.
+  ([#848](https://github.com/ffroliva/gflow-cli/issues/848))
+
+## [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
@@ -1427,7 +1705,6 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Fixed
 
-
 - **v0.66.1's migrated-origin fast-fail never fired on a real run
   ([#639](https://github.com/ffroliva/gflow-cli/issues/639)).** The guard read `page.url` once,
   at `get_ui_driver` entry — but `routes.project_editor_url` only ever builds a `labs.google`
@@ -1742,7 +2019,6 @@ completed exit 0, proving no regression. See
   credential, but account-correlatable, and it would otherwise reach any logged
   request body or diagnostics bundle verbatim.
 
-
 - **The offline test suite could `git checkout develop` in the developer's own
   clone ([#605](https://github.com/ffroliva/gflow-cli/issues/605)).** git's
   repository discovery walks *up* from `cwd`, and `--basetemp=tmp/pytest` puts
@@ -2382,7 +2658,6 @@ completed exit 0, proving no regression. See
 - **Remaining in-workflow package installs pinned (Scorecard Pinned-Dependencies).** The Pages build now installs MkDocs Material with `pip install --require-hashes` from a compiled `website/requirements.txt`; the PR-triage sandbox image (`Dockerfile.triage`) pins its Node base by digest and installs the Claude Code CLI via `npm ci` from a committed lockfile instead of a floating `npm install -g`; the CI dependency audit pins its `pip-audit` tool version (the non-gating weekly `deps-watch` job deliberately keeps a floating pip-audit — fresh advisory tooling is its purpose). New dependabot entries (uv / npm / docker) keep all three sets of pins fresh. The remaining deliberate won't-fix Scorecard alerts (SAST, Fuzzing, CII Best Practices) are dismissed on the repo with recorded reasons.
 - **OpenSSF Scorecard self-run.** A new SHA-pinned `scorecard.yml` workflow (weekly + on push to `develop`) runs the OpenSSF Scorecard supply-chain checks with `publish_results: true`, feeding the public API/badge and the repo Security tab — enabled deliberately after the permissions/pinning hardening so the first published score reflects the hardened state. The score surfaces as a badge in the README and on the website index page, with a docs/SECURITY.md section explaining what it measures; `release.yml`/`pages.yml` write scopes moved from workflow level to the jobs that need them.
 
-
 ## [0.56.0] — 2026-08-13
 
 ### Added
@@ -2476,10 +2751,6 @@ completed exit 0, proving no regression. See
 
 - **Fix video duration selector drift (#451).** Expanded duration control selector cascade to match modern Flow editor UI elements (`button`, `role='button'`, `role='option'`, `role='menuitem'`, `role='tab'`) while preserving fail-closed behavior on missing duration controls.
 
-
-
-
-
 ## [0.51.0] — 2026-08-05
 
 ### Security
@@ -3512,7 +3783,6 @@ completed exit 0, proving no regression. See
     mid-run edit to the home `.env` can no longer produce a task whose client config
     disagrees with the parameters the task derived from `get_settings()`.
 
-
 ## [0.24.0] — 2026-07-01
 
 ### Added
@@ -4771,8 +5041,6 @@ completed exit 0, proving no regression. See
 - `gflow auth login` now prints the launch strategy announcement before opening
   any browser window.
 
-
-
 > **Shell-friendly multi-prompt `t2i` + performance hardening.** This release 
 > promotes `gflow image t2i` to a variadic command that can consume multiple 
 > prompts from positional arguments, a line-delimited text file, or standard 
@@ -5201,7 +5469,10 @@ 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.78.0...HEAD
+[0.78.0]: https://github.com/ffroliva/gflow-cli/compare/v0.77.1...v0.78.0
+[0.77.1]: https://github.com/ffroliva/gflow-cli/compare/v0.77.0...v0.77.1
+[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.78.0}/KNOWN_ISSUES.md

@@ -16,7 +16,7 @@ Living list of behaviour that's broken, surprising, or limited by design — alo
 
 ### Flow is migrating to `flow.google.com`; generation coverage is partial but includes images
 
-- **Status:** Open (partially resolved) · **Severity:** High for unported forms · **Affected:** on accounts the rollout has reached, `gflow video t2v`, local-file `video i2v` / `r2v`, `gflow image t2i`, and local-file `gflow image i2i` now run on the migrated host. Image mode supports Nano Banana 2 / Pro, the four aspect ratios its radiogroup was enumerated with (16:9, 4:3, 1:1, 9:16), and count 1–4; `3:4` had no radio in that enumeration and is refused before submit rather than reported as selector drift. Image refs by UUID, `@Name` / `--reference-entity`, Agent instructions, Imagen 4, video end frames, video refs by UUID/name, scenes, extend, instructions and tools are not ported yet and fail before submit. **`character` is NOT in that list any more** — `character create` and `character list` work on the migrated host. Of the remainder, only the i2v-by-UUID case rests on a positive observation of absence (the Frames picker tiles carry no media id); `scenes`, `extend`, `instructions` and `tools` remain *unported by gflow*, never proven impossible on the host.
+- **Status:** Open (partially resolved) · **Severity:** High for unported forms · **Affected:** on accounts the rollout has reached, `gflow video t2v`, local-file `video i2v` / `r2v`, `gflow image t2i`, and local-file `gflow image i2i` now run on the migrated host. Image mode supports Nano Banana 2 / Pro, all five aspect ratios its radiogroup renders (16:9, 4:3, 1:1, 3:4, 9:16 — 3:4 appeared by 2026-09-17, #864), and count 1–4. Image refs by UUID, `@Name` / `--reference-entity`, Agent instructions, Imagen 4, video frame refs by UUID/name, scenes, extend, instructions and tools are not ported yet and fail before submit. **`character` is NOT in that list any more** — `character create` and `character list` work on the migrated host. Of the remainder, only the i2v-by-UUID case rests on a positive observation of absence (the Frames picker tiles carry no media id); `scenes`, `extend`, `instructions` and `tools` remain *unported by gflow*, never proven impossible on the host.
 - **Tracked:** [#639](https://github.com/ffroliva/gflow-cli/issues/639) · Reported 2026-09-02 against 0.59.0, 0.62.1, 0.63.0 and 0.65.0
 - **Confirmed live 2026-09-03 on a second, independent account** (`ffroliva`) — see [LIVE_VERIFICATION_v0.66.0](docs/LIVE_VERIFICATION_v0.66.0.md). A read-only probe of the migrated origin measured `i_total: 0`, reproducing the reporter's central measurement.
 - **`--reference-entity` was refused on `r2v` but not on `t2v`** ([#716](https://github.com/ffroliva/gflow-cli/issues/716), fixed in v0.71.0): the "not ported, exit 36" refusal above sat inside the r2v branch of the routing gate, so a `t2v` request carrying a character entity returned from that gate without its entities ever being inspected — and nothing downstream attaches one on this host. The generation was **submitted and billed** with the entity silently dropped, returning a plausible clip of the wrong person. The check is now mode-independent and ahead of every early return. If you ran `gflow video t2v @Name …` or `--reference-entity` on a moved account before this fix, the identity in those clips was never bound.
@@ -55,9 +55,8 @@ the clip). Two real clips were generated this way on 2026-09-05 — spike
 `docs/superpowers/spikes/2026-09-05-migrated-host-wire-protocol.md`. Routing
 (`GFLOW_CLI_FLOW_HOST=auto`): flow.google.com is the **default** host for that
 command on every account — moved or not; `flow.google.com` forces it for
-everything, and `labs.google` switches the migrated composer off. Limits today: `--project` is required (project creation from the
-migrated editor is not ported), and `t2v`, `i2v` from a local `--initial-frame` (no end frame,
-no UUID/`@Name` frame — the migrated Frames picker exposes no media id in its DOM, so a frame is
+everything, and `labs.google` switches the migrated composer off. Limits today: only `t2v`, `i2v` from local start (and end) frames (no UUID/`@Name` frame —
+the migrated Frames picker exposes no media id in its DOM, so a frame is
 found by the run-unique name gflow uploads it under, #792), and `r2v` from local `--ref` files
 (see the next paragraph), plus `image t2i` and local-file `image i2i` — unsupported
 forms still exit 36.
@@ -108,7 +107,7 @@ with the distinct, non-retryable exit 36 instead of the misleading
 `UiSelectorDriftError` (exit 23, "file a selector bug"). `_check_logged_in` also
 accepts the migrated host, so a migrated load is no longer misread as a
 logged-out session. The generation forms listed above and characters are driven;
-scenes, extend, instructions, tools, project creation, and the named reference/model
+scenes, extend, instructions, tools, and the named reference/model
 variants are the remaining work
 tracked here — no retry helps for those until each is ported.
 
@@ -1440,7 +1439,7 @@ key — surfaces as a `RuntimeError` that `auth/cookies.py` normalizes to
 
 - **Status:** Mitigated (crash → typed fail-fast rejection) · **Severity:** Low · **Affects:** all versions
 
-Chromium refuses to open two persistent contexts on the same `user-data-dir` simultaneously. Historically this surfaced as an unhelpful Chromium "ProcessSingleton: profile is locked" error partway through a run. As of the profile-lease hardening (production-readiness plan, slice D1/D3), gflow-cli enforces this itself: a cross-process advisory lock (`ProfileLease`, kernel `flock` on POSIX / `msvcrt.locking` on Windows) guards every profile directory. A second `gflow` invocation, `gflow serve` daemon task, or MCP call against an already-leased profile is rejected **immediately** by default — before any Chrome process starts — with a typed `ProfileLockedError` (**exit code 11**); it never silently corrupts the profile. Since #478, setting [`GFLOW_CLI_LEASE_WAIT_SECONDS`](docs/CONFIGURATION.md#gflow_cli_lease_wait_seconds) opts a waiter into a bounded wait that takes over as soon as the current holder finishes (holders always run to completion and are never asked to release early; same-process contention still fails fast — waiting on yourself would deadlock).
+Chromium refuses to open two persistent contexts on the same `user-data-dir` simultaneously. Historically this surfaced as an unhelpful Chromium "ProcessSingleton: profile is locked" error partway through a run. As of the profile-lease hardening (production-readiness plan, slice D1/D3), gflow-cli enforces this itself: a cross-process advisory lock (`ProfileLease`, kernel `flock` on POSIX / `msvcrt.locking` on Windows) guards every profile directory. A second `gflow` invocation, `gflow serve` daemon task, or MCP call against an already-leased profile is rejected **immediately** by default — before any Chrome process starts — with a typed `ProfileLockedError` (**exit code 11**); it never silently corrupts the profile. Since #478, setting [`GFLOW_CLI_LEASE_WAIT_SECONDS`](docs/CONFIGURATION.md#gflow_cli_lease_wait_seconds) opts a waiter into a bounded wait that takes over as soon as the current holder finishes (holders always run to completion and are never asked to release early; same-process contention still fails fast — waiting on yourself would deadlock). Since #864 an MCP server waits 180 s by default, and queues its own calls on one profile rather than rejecting the second.
 
 **Workaround:** use different profiles for parallel work — different profiles acquire independent leases and run fully concurrently.
 

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: gflow-cli
-Version: 0.76.0
+Version: 0.78.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/
@@ -53,6 +53,7 @@ Classifier: Typing :: Typed
 Requires-Python: >=3.11
 Requires-Dist: browser-cookie3>=0.20.1
 Requires-Dist: click>=8.1.0
+Requires-Dist: colorama>=0.4.6; sys_platform == 'win32'
 Requires-Dist: fastapi>=0.115.0
 Requires-Dist: httpx>=0.27.0
 Requires-Dist: mcp<3,>=2.0.0