Skip to content

docs(recon): the migrated mint guard refuses a host that can mint (#692) - #705

Merged
ffroliva merged 2 commits into
developfrom
bugfix/692-mint-on-project-route
Sep 6, 2026
Merged

ffroliva merged 2 commits into
developfrom
bugfix/692-mint-on-project-route

Conversation

@ffroliva

@ffroliva ffroliva commented Sep 6, 2026

Copy link
Copy Markdown
Owner

Summary

Two $0 probes and a corrected comment. No behavioural change — deliberately.

#692's reporter gets RecaptchaError + exit 1 where they expect FlowHostMigratedError + exit 36. #694 hardened that path, but the failure still cannot be reproduced here, so this PR does not stack a speculative fix on top of it. Per the Iron Law, a fix for a failure never observed is a guess with formatting.

What it does add is evidence that changes what we can tell the reporter — and corrects a comment that would misdirect whoever ports gflow image next.

flow.google.com CAN mint

Measured on ci-probe, on the same page pool the client uses:

route recaptcha scripts site key grecaptcha.enterprise mint
flow.google.com/ (root grid) 0 — false ❌ RecaptchaError
flow.google.com/project/<id> 2 6LdsFiUsAAAA… true ✅ OK, 2404-char token

The mint runs on the pooled bootstrap page, which the client-side handoff leaves on the root grid — and only the root grid carries no script. That is also why the reporter's bundle shows route: "/": diagnostics.py maps both hosts to host_category: flow_app, so the route is the only tell.

So the guard's stated reason — "the migrated host has no recaptcha/enterprise.js" — is false about the host and true only about one route on it.

The outcome is still right, for a different reason

gflow image is UI-driven (mint → drive the composer), and the migrated project composer has no image-generation mode. Enumerated by opening the closed surfaces rather than inferring from the default view:

  • the add menu is a media library: movie Scenes · image Images · videocam Videos · upload Upload media
  • the settings overlay's radios are dashboard Grid / campaign_all Batch and S/M/L — layout, not mode
  • [role=tab] = 0, and no image-generation ligature anywhere

Image generation does exist on that host — but only inside the character editor (see #703).

So exit 36 is correct today. When the composer gains an image mode, the fix is to route the mint to a project page, not to keep refusing the origin. That sentence is now in the code, where the wrong one used to be.

Test plan

  • scripts/dev/spike_migrated_recaptcha_mint.py — A/B of both routes, re-runnable, $0
  • scripts/dev/spike_migrated_image_capability.py — opens every closed surface (add menus, settings overlay) rather than reading the default view, $0
  • ruff, ruff format --check, pyright 0 errors, repo hygiene over 1012 files
  • tests/api/test_client_migrated_mint.py — 10 passed (unchanged behaviour, as intended)
  • Comment-and-scripts only; no Flow surface behaviour changed, so no e2e applies

Refs #692 — stays open. The reporter's failure is still unreproduced, and this changes nothing about whether #694 fixes it.

Adds two $0 probes and corrects the comment that justifies the guard, which
was imprecise in a way that would misdirect whoever ports `gflow image`
next.

Measured on ci-probe, same page pool the client uses:

  flow.google.com/            0 recaptcha scripts, no grecaptcha  -> mint FAILS
  flow.google.com/project/ID  2 scripts, site key 6LdsFiUsAAAA…,
                              grecaptcha.enterprise present       -> mint OK,
                                                                     2404-char token

So flow.google.com is NOT unable to mint. The mint runs on the pooled
bootstrap page, which the client-side handoff leaves on the ROOT GRID, and
only the root grid carries no script. That is also why #692's reporter
bundle shows route: "/" — diagnostics.py maps both hosts to
host_category: flow_app, so the route is the only tell.

The guard's OUTCOME is still right, for a different reason than it states:
`gflow image` is UI-driven, and the migrated project composer has no
image-generation mode. Its add menu is a media library (Scenes / Images /
Videos / Upload media) and its settings radios are grid/batch and size —
enumerated by opening them, not inferred from the default view. Image
generation exists on that host only inside the character editor.

No behavioural change. #694's hardening stands, and the reporter's failure
still cannot be reproduced here, so nothing speculative is shipped on top
of it — per the Iron Law, a fix for a failure never observed is a guess
with formatting. What changes is that the next person reads an accurate
reason: when the composer gains an image mode, route the mint to a project
page rather than continuing to refuse the origin.
git never descends into an ignored directory, so the negation added in #703
for scripts/dev/har-spike/artifacts/.gitkeep could never take effect — the
file was never tracked. Removed rather than restructured: the capture
scripts create the directory at runtime, so nothing needs to hold it open.
@ffroliva
ffroliva merged commit d975e0c into develop Sep 6, 2026
15 checks passed
@ffroliva
ffroliva deleted the bugfix/692-mint-on-project-route branch October 22, 2026 19:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant