chore(release): v0.74.0 by ffroliva · Pull Request #811 · ffroliva/gflow-cli

ffroliva · 2026-09-14T19:43:13Z

Summary

Cuts v0.74.0 from develop@7a44dff6 (10 commits since v0.73.2). Signed tag v0.74.0 is already pushed and the Release workflow is running; this PR brings the bump commit and the full integration history onto main.

Merge with --merge, never --squash — the branch carries the whole unreleased batch.

What ships

video: portrait (9:16) dispatch fails with UiSelectorDriftError — driver captures a blank page while the app is live (reproducible; landscape OK) #792 — every local file the migrated driver uploads is run-unique, so a re-run stops binding a stale look-alike; and the Frames picker is confirmed when it does not commit on the pick. Covers video i2v --initial-frame, video r2v --ref and image i2i --ref, because the fix went into the shared upload leg. Reported, root-caused and verified on the affected cohort by @ai4U23.
credits: labs-gated on migrated accounts, and the error blames SAPISID for a host it never contacted #795 — gflow credits stops sending migrated accounts into a re-login loop at the raise site they actually hit; credits list --json carries the per-profile remediation_hint again.
Migrated host: agent-only composer (no classic composer) — video t2v --project fails with UiSelectorDriftError, .settings-trigger-button hidden, no agent-mode-chip #799 — an agent-only flow.google.com composer exits 25 (FlowAgentUiError, retryable: false) instead of 23. Reported with DOM evidence by @Cstanish127.
feat(sponsors): support section, hall of fame and PyPI funding link #809 — sponsors Support section, hall of fame, PyPI Funding link. No CLI or MCP surface change.

What this release deliberately does NOT fix

#791 (login verification for migrated accounts) is still open, and it blocks two reporters outright. It was not attempted blind: the #791 state is SAPISID + a live flow.google.com session + no labs NextAuth token, and none of the nine profiles on the maintainer's machine is in it. An oracle that decides AUTHENTICATED on a fail-open path is not something to ship unverified. The auth slice of PR #793 is wanted for 0.75.0.

gflow credits also remains unavailable on migrated accounts (#795 stays open for the capability), and there is still no driver for the agent-only composer (#799 stays open).

Gates

Impeccable Routine green: repo hygiene (1088 files), doc links (63 files), website-docs PII, website mirror in sync, council memory, ruff check, ruff format --check (469 files), pyright src 0 errors.
Full offline suite: 4321 passed, 7 skipped, 92.22% coverage, 8m01s.
check_release_artifacts.py green.
Live-verify at zero cost: see docs/LIVE_VERIFICATION_v0.74.0.md.
- video: portrait (9:16) dispatch fails with UiSelectorDriftError — driver captures a blank page while the app is live (reproducible; landscape OK) #792 — tests/e2e/test_migrated_i2v_e2e.py 2 passed in 29.54s against real Flow, including the forced confirm branch.
- credits: labs-gated on migrated accounts, and the error blames SAPISID for a host it never contacted #795 — verified on the cohort it is for: auth status green, credits user exit 3 with the honest remediation, credits list --json carrying it per profile.
- Migrated host: agent-only composer (no classic composer) — video t2v --project fails with UiSelectorDriftError, .settings-trigger-button hidden, no agent-mode-chip #799 — not verified, named blocker: no account here is in the agent-only cohort.
- r2v and i2i attach paths were not driven to completion; the ledger says so and says why.
Doc-review council: 3 auditors. Claim accuracy NO BLOCKERS, cross-reference NO CONTRADICTIONS, overclaim audit returned 3 findings which are fixed in the release commit.

Test plan

CI matrix green
SonarCloud quality gate green
Release workflow published to PyPI + GitHub Releases
Back-merge main into develop

@ai4U23

…unique (#800) Two defects on Flow's migrated flow.google.com host, reported and root-caused by @ai4U23, who verified the fix end-to-end on the affected cohort. 1. The Frames picker no longer commits on the option click for some cohorts; it waits for its own "Add to prompt". gflow sat out FRAME_COMMIT_HIDDEN_S for an auto-close that never came and raised UiSelectorDriftError with the asset already picked, failing i2v before submit (no credits spent). The picker now gets a grace period and, if still up, its confirm is clicked -- scoped to the live pane and gated on is_visible(), since the method reopens the picker up to three times and a detached pane's button still counts. Anchored on button.detail-add-to-prompt-btn, measured on the Frames entry (scripts/dev/spike_frames_picker_confirm.py) rather than on the translated label the report used. The same spike killed the obvious structural shortcut: the popover's other visible button is header-close-btn, so "the button that is not an asset option" would have clicked Close. 2. Both attach paths find their upload again BY DISPLAY NAME -- the Frames picker searches it (i2v), the @ mention queries it (r2v) -- and Flow lists an upload under the name it was given. A re-run of the same file left two identical entries and the lookup could bind the stale one. i2v leaned on the picker's newest-first sort to break the tie; that is a sort assumption about someone else's app, and it lost. Uploads now carry a run-unique display name, handed over as a Playwright FilePayload so nothing is copied to disk. Fixed once in _unique_display_name + _upload_via_toolbar, not on the path the issue names: attach_references reaches the same upload leg and re-uses reference images across runs by design, so r2v was the likelier victim. Applies to video i2v, video r2v and image i2i alike. The fake could not model any of this -- it closed the picker unconditionally on an option click, so the commit assertion tested the fake, not Flow. It now models a picker that stays open, one with no confirm, one that ignores its own confirm, and a library that lists an upload under the name it was uploaded with. It also raises the REAL Playwright TimeoutError on waits: with the stand-in, a narrowed except silently tests nothing. Also adds docs/MCP.md section 6 "Troubleshooting a failed tool call", routed from docs/INDEX.md -- cohort triage, an envelope -> cause -> action table, and how to recognise a pre-v0.73.2 blank incident bundle as no evidence at all. Verified: full offline suite (4248 passed, 92%), ruff, pyright strict, 5 doc and hygiene gates, SonarCloud green. Live $0 e2e on a migrated account: the happy path passed, and a forced-grace run drove the confirm branch itself against real Flow (confirm_clicked=False -- the picker had already closed, is_visible() correctly skipped the click, the chip bound, which is the measurement the no-op safety claim needed). Eleven-dimension council review; every finding addressed or answered. Not verified, named external blocker: the confirm CLICK has never executed against live Flow, because no picker on this cohort stays open. Covered offline across all three outcomes and A/B-controlled; the #792 reporter is the verifier. The r2v half of the naming fix is offline-only -- it shares the upload leg the i2v e2e exercised live, but its own attach was not re-run. Refs #792

…#801) The canary had been RED with an identical failure set since 2026-09-11, and every run posted the same comment ending "Canary gates nothing. Triage at your convenience." A standing condition -- a capability Flow took away from this account, already understood -- looked exactly like fresh drift, which is the thing the canary exists to catch. The set being UNCHANGED was the informative part, and nothing reported it. RED is not demoted. The module docstring is emphatic that labelling a real regression "ignore me" is how the signal dies, and #560's council review already caught one such demotion. This only adds what a single run cannot say: continuity(previous, failing) -> (state, note) a pure function beside `classify`, fingerprinting the sorted failing set (order-insensitive -- pytest promises no stable order and a reshuffle is not new). Same set as last time -> "Unchanged for N consecutive runs", and say that a red nobody owns is how a canary trains red-blindness. Different set -> "The failing set changed since the last run", the arm worth looking at today. The note REPLACES the flat triage line rather than sitting beside it: a report saying both "at your convenience" and "broken for four nights" is arguing with itself, and the reader believes the softer half. Only RED and GREEN update the streak. AUTH-EXPIRED and DEFERRED learned nothing about Flow, so one night with Chrome open must not erase a week-old red. State lives in tmp/canary-state.json (gitignored, disposable). Every read and write degrades to "no continuity known" rather than taking the nightly down -- a test caught int() raising on a hand-edited value, which would have done exactly that. Verified by running the real script twice, dry-run, $0: run 1 -> RED, first-ever fingerprint, no streak claimed (correct) run 2 -> RED, {"fingerprint": "7ac1eca0bf29", "runs": 2}, "Unchanged for 2 consecutive runs." Those runs also produced the finding the feature exists to surface: today's set is NOT the nightly's. The four credits/aisandbox failures are identical -- the standing condition (#795, this account losing the ya29 Bearer around 2026-09-11) -- while the two agent-mode transport tests now pass and a different test has joined. A stable core with flapping edges, which is exactly what the report could not say. Gates: ruff, ruff format, pyright strict, 4 doc/hygiene checks, 4261 passed, 92%. Refs #559

…802) stop re-deriving a credits auth verdict through a browser (#802) `gflow credits` on a migrated account told users their SAPISID cookie was broken and to re-run `gflow auth login`. Every clause was wrong, and the advice is harmful: on a profile with no browser-strategy marker a failed FIRST login rolls that marker back -- the #791 spiral. v0.73.2 fixed the remediation for the raise site where labs mints no token. It could not help the cohort that gets a token and has aisandbox-pa reject it, because that message was never coming from a credits raise site at all: services/credits.py::_fetch caught its own accurate verdict in a bare `except Exception` and re-derived it through Chrome, failing inside the SHARED, route-blind _run_with_aisandbox_retry. The good message was being computed and then discarded. The browser is no longer consulted once aisandbox-pa has ANSWERED -- it asks the same endpoint for the same Bearer and gets the same refusal. The other site (labs 200, no token) KEEPS its browser rescue: httpx sends labs.google cookies only while the browser carries the full jar and bootstraps a real navigation, which can renew a session httpx cannot. If that rescue fails too, the fast path's diagnosis survives rather than the route-blind default. Council D1 falsified the first commit's blanket re-raise; D14 reached the same place independently. `credits list` now reports the remediation per profile -- it rendered only the class title, so the multi-profile surface and gflow_get_credits(all_profiles=true) were the one door that still could not say why. Measured live on a migrated profile at $0: `credits user` ~7 s -> 2 s with no browser launch; across 9 saved profiles `credits list` drops from 9 Chrome launches to 6 (3 skip it, 4 keep their rescue, 2 fail unrelated); 9 of 9 rows now carry a remediation where none did. Two e2e tests, cohort-agnostic by construction, both run live on the migrated cohort and both took the failure branch. The pre-existing happy-path e2e tests stay RED -- that is the real capability loss (#559), not test rot. Nine council dimensions resolved; CodeRabbit's two findings fixed. `credits` itself remains unavailable on the migrated host, so #795 stays open; the class default still reaches every non-credits aisandbox route, filed as #803. Refs #795, #791

@Cstanish127

… drift (#804) name the agent-only composer instead of calling it selector drift (#804) Google has put some accounts on a flow.google.com composer with NO classic arm: the only prompt box is the agent panel, and aspect/model/count are Agent-settings defaults rather than per-request controls. Every control the migrated driver reaches for is structurally absent, so gflow waited out the 30 s readiness gate and raised UiSelectorDriftError -- exit 23, which reads as OUR frontend bug and invites a retry that cannot work. @Cstanish127 reported it with the DOM capture that made it diagnosable. It now raises FlowAgentUiError: exit 25, retryable=False, $0, pre-submit. THE DISCRIMINATOR IS THE CHIP. The DOM is identical to #749's recoverable agent mode -- settings trigger present under a bare `hidden` -- which is why it read as drift. What separates them is that a recoverable account still has a button.agent-mode-chip to turn off and this one has none, so AGENT_MODE_CHIP_ANY exists alongside AGENT_MODE_CHIP (pressed-only). A trigger that has LEFT the DOM stays drift: that is a renamed selector, our bug. MEASURED, not assumed. The fix rests on whether Playwright reports <button hidden=""> as present-but-invisible; a fake answers whatever it was written to answer, so tests/api/transports/test_agent_only_composer.py measures it against real Chromium on the reporter's markup. Two negative controls were then run against LIVE Flow at $0: healthy migrated composer (ffroliva, real project page) trigger visible, agent-mode-chip present and UN-PRESSED -> False live /about landing (denon82, #756) trigger absent -> False The first corrected a claim in this PR's own comment. An un-pressed chip is not "never observed" -- it is the NORMAL state of a healthy migrated composer, which is the point: a working account on this host HAS a chip, so having none is genuinely anomalous. The state never observed is an un-pressed chip beside a HIDDEN trigger. `retryable` moved from FlowAppError to the error base, under the condition FlowAppError's own comment set ("move it up if, and only if, a second class needs it"), then narrowed in documentation: six subclasses with their own __init__ reject it loudly rather than being threaded through for a case no raise site has. A test pins that split so the note cannot rot. Eight council dimensions plus CodeRabbit, all resolved. D4 proved the fail-closed branch was uncovered (migrated_composer.py 80% -> 93%); D9 found two prose contradictions that survived a clean rebase; D15 moved the 23->25 note to ### Changed and corrected "exit 25" to "exit-25-equivalent"; D14 de-duplicated a third copy of the Chromium fixture; D1 found FlowApiError's legacy branch eating `retryable=`. NAMED BLOCKER: that Flow still SERVES this DOM is unverified -- no account available to us is in that cohort. #799 stays open for that and for the agent-panel driver, which is not implemented. Refs #799

…from host membership (#807) measure both Flow domains, and stop asserting capability from host membership (#807) Two spikes and the vocabulary change they force. No behaviour changes: the source edits are error strings, docstrings and one env-var description. SPIKE 1 -- labs vs flow.google.com, protocol by protocol. A sweep of all 31 prior spike notes found ZERO mentions of gRPC, gRPC-Web, raw protobuf, WebSockets, SSE or the negotiated HTTP version. Never ruled out; never looked for. 3 accounts x 2 entry points x 2 runs: * labs.google/fx/tools/flow returns HTTP 308 PERMANENT REDIRECT, 6/6 visits -- server-side, and a different mechanism from the client-side /about redirect. * The graduated app's Angular root is `aisandbox-root`, the same name as aisandbox-pa.googleapis.com. One product lineage, two frontends. * No WebSocket, SSE, gRPC or raw protobuf on Flow's hosts. The one application/json+protobuf per run is OneGoogle's account bar. STOMP is moot -- it rides on a WebSocket and there is none. * HTTP/3 (QUIC) dominates. Never recorded, and invisible through Playwright. SPIKE 2 -- is there a push channel during an ACTIVE generation? No. Zero WebSocket events, zero streaming, across the full submit->completion lifecycle at zero Veo credits. The mechanism is neither polling nor push: ogiZ0b is dispatched ONCE and answered 19.687s / 19.841s later with the finished images in the reply. The instrument had to be fixed mid-spike to see it -- the first version recorded response ARRIVAL only, which cannot tell "sent late" from "held open for 20s". THE VOCABULARY. "X is labs-only" and "on a migrated account, X fails" use host membership to predict capability. Host membership is uniform across the surveyed profiles where capability is not, and no account here can reach labs to test a labs-only claim -- making it unfalsifiable, not merely unproven. Corrected wherever it was a live claim, including two strings people actually read: credits.py told USERS the endpoint was labs-only (aisandbox is shared), mcp/tools.py told AGENTS a capability was labs-only (gflow has not ported it), and migrated_composer.py blamed Flow for a model missing from our own matcher table. AGENTS.md carries the rule so it is enforced rather than swept once. NOT changed: "migrated host" as a NAME, the identifiers FlowHostMigratedError / GFLOW_CLI_FLOW_HOST / migrated_composer.py, released CHANGELOG entries and dated spike notes, and the skills that QUOTE "labs-only" as the phrase to avoid. THREE AUDITS, and the sharpest findings were against this branch's own work: a listener leak that corrupted the saved evidence (fixed, all evidence regenerated); a pre-registered "unmeasured" verdict that the findings then failed to apply to their own data; two false claims introduced while removing false claims, one contradicting its own docstring five lines above; and an over-broad rule that could have read as "delete the host branching". The WebSocket negative was A/B-validated by pointing the detector at a page that does open a socket, and the one blind-spot class (COOP: same-origin) was ruled out for both hosts. HONEST LIMITS: the video path is unmeasured for push, and spike 2 CORRECTS its own premise there -- images use a held response, video polls, so an absence on one is not an absence on the other. 3 of 9 profiles were surveyed (the three with a live Flow session). This is not "labs is gone": v0.67.0 drove a pt-locale account through the labs route, and migrated_route's labs arm is still reached routinely for reasons unrelated to host. Spike 2's script was committed BEFORE its data existed, which is the ordering gap spike 1 could not prove. Refs #639, #791

Bumps the github-actions group with 2 updates: [astral-sh/setup-uv](https://github.com/astral-sh/setup-uv) and [github/codeql-action/upload-sarif](https://github.com/github/codeql-action). Updates `astral-sh/setup-uv` from 10.0.1 to 10.1.0 - [Release notes](https://github.com/astral-sh/setup-uv/releases) - [Commits](astral-sh/setup-uv@20cfd1b...bec219d) Updates `github/codeql-action/upload-sarif` from 4.37.9 to 4.38.0 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@cdf488f...b96794f) --- updated-dependencies: - dependency-name: astral-sh/setup-uv dependency-version: 10.1.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: github-actions - dependency-name: github/codeql-action/upload-sarif dependency-version: 4.38.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: github-actions ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Bumps the python-minor-patch group with 5 updates: | Package | From | To | | --- | --- | --- | | [platformdirs](https://github.com/tox-dev/platformdirs) | `4.11.7` | `4.11.8` | | [mcp](https://github.com/modelcontextprotocol/python-sdk) | `2.1.1` | `2.2.0` | | [sse-starlette](https://github.com/sysid/sse-starlette) | `3.4.10` | `3.4.11` | | [ruff](https://github.com/astral-sh/ruff) | `0.16.6` | `0.16.7` | | [pyright](https://github.com/RobertCraigie/pyright-python) | `1.1.411` | `1.1.414` | Updates `platformdirs` from 4.11.7 to 4.11.8 - [Release notes](https://github.com/tox-dev/platformdirs/releases) - [Changelog](https://github.com/tox-dev/platformdirs/blob/main/docs/changelog.rst) - [Commits](tox-dev/platformdirs@4.11.7...4.11.8) Updates `mcp` from 2.1.1 to 2.2.0 - [Release notes](https://github.com/modelcontextprotocol/python-sdk/releases) - [Changelog](https://github.com/modelcontextprotocol/python-sdk/blob/main/RELEASE.md) - [Commits](modelcontextprotocol/python-sdk@v2.1.1...v2.2.0) Updates `sse-starlette` from 3.4.10 to 3.4.11 - [Release notes](https://github.com/sysid/sse-starlette/releases) - [Commits](sysid/sse-starlette@v3.4.10...v3.4.11) Updates `ruff` from 0.16.6 to 0.16.7 - [Release notes](https://github.com/astral-sh/ruff/releases) - [Changelog](https://github.com/astral-sh/ruff/blob/main/CHANGELOG.md) - [Commits](astral-sh/ruff@0.16.6...0.16.7) Updates `pyright` from 1.1.411 to 1.1.414 - [Release notes](https://github.com/RobertCraigie/pyright-python/releases) - [Commits](RobertCraigie/pyright-python@v1.1.411...v1.1.414) --- updated-dependencies: - dependency-name: platformdirs dependency-version: 4.11.8 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: python-minor-patch - dependency-name: mcp dependency-version: 2.2.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: python-minor-patch - dependency-name: sse-starlette dependency-version: 3.4.11 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: python-minor-patch - dependency-name: ruff dependency-version: 0.16.7 dependency-type: direct:development update-type: version-update:semver-patch dependency-group: python-minor-patch - dependency-name: pyright dependency-version: 1.1.414 dependency-type: direct:development update-type: version-update:semver-patch dependency-group: python-minor-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

…s client timer (#808) Closes the last open question from the 2026-09-14 protocol spikes, and the only one that cost credits. Spike #2 settled the image path (ogiZ0b held open ~19.7 s, one response, no push and no poll) and then corrected its own premise: video uses a poll loop, a different mechanism, so an absence on images was never an absence on video. This measures video directly. One t2v generation on ffroliva (veo_3_1_lite, x1, ~10 credits), full submit->completion lifecycle instrumented. THE ANSWER. It is a fixed client timer and Flow's page owns it. Seven consecutive jwpduf inter-DISPATCH gaps span 10 ms end to end (5.002 5.009 5.011 5.005 5.008 5.001 5.004, mean 5.006, stdev 3.5 ms). The same eight polls' ARRIVAL gaps have stdev 178 ms and spread 641 ms -- fifty times wider, pure network jitter. That ratio is what excludes the alternative: a cadence sent in response to anything would inherit that thing's jitter, so dispatch spacing would be at least as ragged as arrival spacing. A clock the network cannot perturb is a local clock. No collapse at completion (last inter-dispatch gap 5.004 == first 5.002). The job finished during the poll dispatched at 53.554; that poll's own reply carried status 3, and as29s went out 34 ms later -- the client reacting to the answer it asked for. Nothing inbound between polls: the only non-batchexecute responses are four GA4 /g/collect beacons (204 No Content) and one play.google.com/log, both outbound telemetry, the latter sitting between two dispatches 5.011 s apart. Nothing is held open either -- every poll answered in under 0.81 s, against ogiZ0b's 19.7 s on the image path. So push is now measured absent on BOTH generation paths rather than generalised from one, and "we could subscribe instead of polling" is refuted by measurement for video as it already was for images. The 5 s interval is a floor we read, not a latency knob we hold. Recorded in docs/ARCHITECTURE.md and the migrated-host memory so a future proposal meets it. PRE-REGISTRATION. The video arm and its five readings were committed and pushed BEFORE the run; spike #1 could not prove that ordering and had to say so. The note applies the reading to its own data outcome by outcome -- including the arm that fired while its consequent was refuted ("a client timer WE OWN; latency is OURS to tune"), which is recorded as a correction rather than reworded away. THE DETECTOR'S OWN BLIND SPOT, measured rather than argued. Every survey in this series bound page.on(...), but a service worker's fetches are reported on the BrowserContext, so a page-scoped zero cannot tell "no such traffic" from "traffic on a surface I never bound". Binding both and diffing them found 3 responses per run that the page never sees, identical across two $0 image runs: play.google.com/log, and two recaptcha/enterprise/* (one application/binary), plus one dedicated worker, recaptcha/enterprise/webworker.js. Surveys #1 and #2 and this PR's own video run each missed those three, and both sibling notes now say so. None is a channel, and with the wider listener plus Network.webTransport* registered for the first time here, the count is still zero WebSocket, SSE and WebTransport -- the conclusion stands on a wider surface than it was argued on. Target.setAutoAttach was deliberately not used: flattened child sessions arrive with a sessionId Playwright does not route to a CDPSession, so those events would drop silently, which is a detector that looks armed and is not. THREE INSTRUMENT BUGS, which are the recurring failure here rather than the Flow surface. Keying dispatch times by url[:200] would have destroyed the result -- all 8 jwpduf URLs are byte-identical at that truncation, measured -- and was fixed before the run. protocols keyed at [:300] against events at [:200] left 62 responses including every poll with no HTTP version; fixed, and no h2/h3 claim is made from the video capture (spike_two_domain_protocol_survey.py is unaffected, it truncates both sides at 300). str(record)[:120] truncated the terminal fields, so "done=True, 1,273,409 bytes" reached stdout and never the evidence file the note cited them to; sourcing corrected and those fields are now recorded by name, which also keeps the signed video_url out. COST SAFETY. --runs defaulted to 2 in both modes, so appending --mode video to the committed image invocation silently doubled a real bill while the banner computed that total and printed it. Now 1 for video, 2 for image. Page check-in moved into finally: except Exception does not catch Ctrl-C and the video arm holds a pooled page for up to poll_timeout_s. ALSO. check_doc_links.py now audits docs/superpowers/spikes/ whole instead of by hand-maintained allowlist -- every spike note ever written was outside the gate; all 34 pass, so nothing is grandfathered (29 -> 63 files). The third-party host census is named once, because ogads-pa has been re-derived as "not Flow" in three separate notes; none of those hosts should ever be blocked or route-aborted, and gflow has no machinery that would, which is correct for a project whose premise is that Google's stack rejects browsers advertising automation. Reviewed by an 8-dimension council (D0/D2/D3/D5/D14 green; D1/D4/D9/D13 yellow); every must-fix applied. All local gates green; CI 16/16 including SonarCloud.

…ing link (#809) README gains a Support section with one-click sponsor links, a Gold logo row at the top and a hall of fame; docs/SPONSORS.md lists every tier (mirrored to the website). scripts/ci/update_sponsors.py regenerates both blocks from GitHub Sponsors, rendering only public sponsorships with escaped, validated data; .github/workflows/sponsors.yml runs it daily and commits only the three generated pages to develop. pyproject.toml adds the Funding URL. No CLI or MCP surface changes.

It had been sitting untracked AND un-ignored in the repo root -- the state one `git add -A` turns into an accidental commit. Tracking it deliberately closes that; ignoring it was the other valid answer. The file is gflow-cli-specific (`wing: gflow-cli`, 11 rooms, 39 exclude patterns) and the miner reads it from THIS project's root, so it is this repo's own config rather than a sibling-repo fixture. Its comments carry measured tuning, not preferences: source and generated data are deliberately not mined because memory should hold what the repo cannot give back -- code is already here at full fidelity and greppable, and chunking it severs function bodies from their call sites (.py alone was 12,797 of 19,951 drawers here, 64%). The `diary` room carries no keywords on purpose: log/notes/session hijacked USAGE.md into 180 drawers. Two other repository names appeared in those comments as supporting evidence. This repo is public and neither name appeared anywhere else in it, so they are described positionally instead; every figure and every lesson is unchanged. Five exclude patterns are inert against the miner's current readable-extension set and are kept deliberately, with a note saying why, so the next reviewer does not re-derive it.

coderabbitai · 2026-09-14T19:43:22Z

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: a41bf9e0-a87a-4b18-a86b-4a8fe8ebb1b3

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

ffroliva and others added 11 commits September 13, 2026 17:31

chore(release): v0.74.0

89cd93e

ffroliva merged commit 479009e into main Sep 14, 2026
17 checks passed

ffroliva deleted the chore/release-v0.74.0 branch September 14, 2026 19:52

Navigation Menu

Repository navigation

chore(release): v0.74.0 - #811

chore(release): v0.74.0#811
ffroliva merged 11 commits into
mainfrom
chore/release-v0.74.0

ffroliva commented Sep 14, 2026

Uh oh!

coderabbitai Bot commented Sep 14, 2026

Review skipped

Uh oh!

Uh oh!

This branch was previously deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

ffroliva commented Sep 14, 2026

Summary

What ships

What this release deliberately does NOT fix

Gates

Test plan

Uh oh!

coderabbitai Bot commented Sep 14, 2026

Review skipped

Uh oh!

Uh oh!

This branch was previously deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant