Adom Google

Field report from tonight's first-run auth in a fresh container, filed at John's request: I got the token, but only after making him click through a Google "Something went wrong" retry, without a verified toast, and without ever learning that pup could have driven the consent for him. Each of those is an AI-hints gap in adom-google auth's output / the skill, not a bug in the token flow (which worked first time once Allow landed). Cheapest first:

1. The hands-free lane is missing from the hints: pup can drive the consent page

The auth output and the skill offer two lanes — the Adom extension window (nbrowser_open_window) and a clickable hyperlink. Neither mentions pup, yet pup's durable adom-you profile + credential vault (pup_login {submit:true, submitReason}) can sign into Google and click Allow with no human in the loop when a Google login is saved there. John's exact words: "you know you can use pup to auth to google now ... or just drive the google login yourself." Ask: a third lane in the hint block, with the recipe and its caveats — open the consent URL in pup (durable profile), pup_login if the sign-in page appears, click the account + Allow via pup_eval, and the FedCM "Sign in with Google" chooser caveat from the pup skill (it rejects in-page clicks; the classic accounts.google.com consent page does not). Plus the honest fallback order: pup (hands-free) → extension window + toast → hyperlink.

2. The toast step should be concrete, verifiable, and land the click on the consent window

The hint says "announce it FIRST" and shows a bare notify_user {title, body}. ab's own reply to that call comes back with _couldHaveDoneBetter: without focus a click opens Adom Bridge, not the consent window; and there is no guidance to read the reply or to use wait:true / scenario:"reminder" for a sticky prompt that returns the human's choice. I fired the bare toast, never verified it, and could not later tell John whether he was ever toasted. Ask: make the example notify_user {title, body, scenario:"reminder", focus:{titleContains:"Sign in - Google"}} (or hwnd from the window verb's reply), say "read the reply; poll notify_response", and put it AFTER the window exists (my sequence toasted first, then failed to open the window, then opened it — the toast pointed at nothing).

3. status is a trap for waiters

adom-google status exits 0 when NOT authorized, and its error text contains the words "authorized", "FULL", and "access" — so a naive until status | grep -qi authorized (what an AI writes to wait for the click) fires instantly on the failure message. I did exactly that. Ask: non-zero exit when unauthorized (or status --json with authorized: true|false), and an auth --wait/auth --json that blocks and prints one machine-readable line on success, so the AI never has to poll status at all.

4. Google's "Something went wrong" page has no recovery guidance

John hit Google's generic "Sorry, something went wrong there. Try again." on the first consent load. The hint block covers "Session Expired" (re-run auth) but not this; I guessed (re-ran auth for a fresh state, which worked). Ask: name it — "a fresh URL from re-running auth clears it; the earlier session is recovered, nobody clicks twice" — and have the running listener print a line when the callback is HIT so the AI can tell "user clicked, Google failed" from "user never clicked".

What went RIGHT, for the record: the gateway/broker flow itself was one Allow click to a full-scope token, the DM to Colby posted as John and read back verbatim, and the --body-file/@file convention on load/say — all fine. This issue is only about what the AI is told at the moments it has to act.