A retired labs tRPC route (404 "Flow RPCs have been deprecated") tells the user to simplify a prompt that does not exist #875

What happens

On a profile Flow serves from flow.google.com, every labs tRPC route that is not the project-create route answers HTTP 404 with Flow's own explanation:

Flow RPCs have been deprecated and disabled. Flow has migrated to https://flow.google.com.

gflow surfaces that as a bare WireFormatError (exit 7) carrying the class-default remediation:

Check request payload parameters or retry with a simpler prompt text. File a bug at https://github.com/ffroliva/gflow-cli/issues with the discovery payload above.

Both halves are wrong, and in the same way #803 and #789 were wrong — gflow asserting something nothing measured:

• "Check request payload parameters" — the payload is fine. The route is retired.
• "retry with a simpler prompt text" — there is no prompt. character list is a read.
• "File a bug" — we already know. Flow told us in the response body, and the body is the one thing the remediation does not repeat.

The user is sent to simplify a prompt that does not exist, then to file a bug for a condition the product documents in its own reply.

Live capture

gflow character list --profile <p> --project <id>, 2026-09-18, on a profile whose session cookies are healthy (flow_session_cookie_present: true, flow_session_cookie_expired: false, google_sapisid_present: true, 57 context cookies):

{"error_class": "WireFormatError",
 "problem": {"type": "https://gflow-cli.dev/errors/wire-format",
             "title": "Unexpected response shape from Flow",
             "status": 404,
             "detail": "Flow RPCs have been deprecated and disabled. Flow has migrated to https://flow.google.com.",
             "remediation_hint": "Check request payload parameters or retry with a simpler prompt text. File a bug ...",
             "route": "projectInitialData"},
 "discovery": {"route_name": "projectInitialData", "http_status": 404,
               "top_level_keys": ["error"],
               "body_prefix_redacted": "{\"error\": {\"json\": {\"message\": \"Flow RPCs have been deprecated and disabled. Flow has migrated to https://flow.google.com.\", \"code\": -32004, \"data\": {\"code\": \"NOT_FOUND\", \"httpStatus\": 404, ..."}}

Exit code 7.

Why this is not already covered

client.py:1866 _labs_project_route_refused recognises exactly this refusal — "Measured 2026-09-17 on four profiles, 12/12: 404 'Flow RPCs have been deprecated and disabled'" — but it is consulted only on the project-create path, where it silently falls through to the migrated composer. Every other caller of _get_json gets the raw WireFormatError.

Routes that reach it include projectInitialData (so gflow character list, capability listing) and, by inspection, the other labs tRPC reads. #639 tracks porting these to the migrated host; this issue is only about what gflow says in the meantime.

Suggested fix

Keyed on the observed answer, never on host membership (per AGENTS.md § Host-Membership Discipline): when a labs tRPC route answers 404 and the body carries Flow's deprecation message, attach a remediation that says so.

Two options, in order of preference:

1. Remediation only (smallest): keep WireFormatError/exit 7, pass an explicit remediation_hint naming the retired route and pointing at GFLOW_CLI_FLOW_HOST / Flow's migrated flow.google.com frontend: text-to-video is driven (v0.67.0); image, i2v/r2v, characters, scenes, extend, instructions, tools and project creation still pending #639. Cheap, no exit-code change, no test churn beyond the new assertion.
2. Reclassify to FlowHostMigratedError (exit 36), which already exists and whose message is written for exactly this situation. Truer, but it changes the exit code callers see on these routes, so it wants its own scenario pass.

Either way the fix belongs next to _labs_project_route_refused so the two cannot drift — the detection is already written and measured, it is just not reused.

Not covered here

Whether the same 404 shape reaches createEntity, commitWorkflow and the other write routes was not exercised in this run — only projectInitialData was observed. The detection should be keyed on the body, not on a route allowlist, so that does not block the fix, but a second observation would be worth having before closing.