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

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

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

gflow_cli-0.77.1/.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.1}/.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.1}/CHANGELOG.md

@@ -7,6 +7,164 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [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 +1585,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 +1899,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 +2538,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 +2631,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 +3663,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 +4921,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 +5349,9 @@ shell-script template that branches on these codes.
 
 First skeleton. Not functional end-to-end yet.
 
-[Unreleased]: https://github.com/ffroliva/gflow-cli/compare/v0.76.0...HEAD
+[Unreleased]: https://github.com/ffroliva/gflow-cli/compare/v0.77.1...HEAD
+[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.77.1}/PKG-INFO

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

{gflow_cli-0.76.0 → gflow_cli-0.77.1}/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.1}/docker/Dockerfile

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

{gflow_cli-0.76.0 → gflow_cli-0.77.1}/docs/AUTHENTICATION.md

@@ -216,6 +216,24 @@ watches for the completed Flow sign-in and closes the window itself, then prints
 verified account. If you close the window yourself it still works: gflow verifies the
 profile exactly the same way and does not treat a manual close as an error.
 
+**What "watches for the sign-in" means, and why it has two signals.** The primary one is the
+Flow session endpoint on `labs.google` — the cookie jar is never the authentication
+decision, because a cookie can be present while the endpoint still rejects. But for an
+account Google serves from `flow.google.com`, labs hands off without ever minting a session,
+so that endpoint is an oracle that cannot answer: through v0.77.0 those logins held the
+window open for the full timeout while this page promised the opposite
+([#849](https://github.com/ffroliva/gflow-cli/issues/849)). 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 second signal ends a wait; it does not decide
+anything. Verification still runs afterwards, against a server, on what actually landed on
+disk, and it is still the only thing that can call a login successful.
+
+**A timeout is not a verdict either.** If neither signal fires, gflow closes the window and
+*still* reads the profile before failing — "gflow verifies what's on disk either way" is the
+promise the sign-in banner makes, and it now holds on every path. A sign-in that completed
+while the detector was blind is reported as the success it is; one that really did not
+happen keeps the timeout's own wording, which is the message that explains the wait.
+
 **Automatic fallback, with nothing to choose.** If Playwright can't resolve a Chrome channel
 on this machine (a Chromium-only Linux box, for instance), or Google rejects the browser
 anyway, `gflow auth login` falls back to the earlier **Passive Capture** flow: Chrome

{gflow_cli-0.76.0 → gflow_cli-0.77.1}/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.77.0` active · automation **exercised and working** — v0.77.0 published itself unaided | 2026-09-17 |
 | [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,50 @@ 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 proved it.** The registry now serves
+> `io.github.ffroliva/gflow-cli` at **0.77.0, status `active`, published
+> 2026-09-16T18:53:54Z** — from the release run itself, with no hand-publish.
+>
+> For every release through v0.76.0 the 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;
+> v0.77.0 was not. Verified against the live registry API on 2026-09-17.
+>
+> **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 +140,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 +164,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: