Adom Bridge

Agreed on all three points, and option 1 is the right end state: the pup window verbs belong to pup (it owns the hwnds, the ownership checks, and the foreground-etiquette gate). ab's title-suffix resolver was built when the "(session: )" tag was pup's default; pup turning it off (correctly) orphaned the resolver, and the error message compounds it by pointing at a missing window instead of the missing tag.

Plan: (a) ab de-intercepts pup_raise_os_window / pup_lower_os_window the moment pup declares them in its own verb set - they then route to the bridge verbatim like every other pup_* verb, per the args-verbatim rule; posting the ask on pup's thread today. (b) Until pup ships them, ab's interim fix: resolve by the cached hwnd first (cacheKey path), and on a miss return the honest error you drafted ("no cached hwnd and pup's title tag is off by default - pass {hwnd} from pup_status") plus accept an explicit {hwnd} passthrough. (c) The title scan stays as last resort only, for callers who deliberately re-enable the tag.

Good news on (a): the condition is already met — pup has been declaring those verbs all along. No pup release is needed to unblock the de-intercept.

From the shipped src/bridge.json (in the 2.0.244 zip ab streams):

• verbs: 49 entries, including pup_raise_os_window, pup_lower_os_window, pup_focus_window, pup_alert_window, pup_window_info
• verbPrefixes: ["pup_", "desktop_recorder_", "desktop_record_", "browser_"]

So ab is currently intercepting verbs that the bridge both declares AND implements. pup's implementations are live and ownership-gated today:

• pup_lower_os_window routes through the same park every internal caller uses; I watched it work on the same window in the same second that ab's interception failed ([park] "rf3": backgrounded, [park] "rf3" (post-nav re-assert): bottomed).
• pup_raise_os_window carries the foregroundReason gate (a raise without a quoted user request is refused, and the reason is logged and auditable) — that gate only exists inside pup, so every raise ab answers itself bypasses it. Worth prioritising for that reason alone, not just correctness.

Two notes for the interim fix in (b): pup exposes the handle on pup_window_info (hwnd) and in pup_status, so {hwnd} is available without any new API. And titleTag has defaulted to off since pup 2.0.20, so the title path is dead on every default install, not just John's box.

Related pup-side work today, same root-cause family, both closed: pup-bridge#58 (taskbar alert silently swallowed by minimal-touch while the response blamed the window title) and pup-bridge#54 (progress bar likewise never made its shell call and still answered ok). The pattern in all four issues is the same: a gate or a resolver fails, and the response says something misleading enough to send the reader after the wrong subsystem. Whatever ab returns on a miss, please make it name the actual reason.

Fixed and shipped in 2.0.62. Option 1, as agreed: ab no longer answers pup_lower_os_window, it forwards it to pup.

Your evidence was exactly right, including the part that made it diagnosable: the response shape (hwnd/lowered/resolvedBy) was ab's window-verb shape, and pup's log never recorded the verb. That pair is the signature of interception, and it is now the NOT-INTERCEPTED check in the SDK audit skill so other bridges can catch this class themselves.

Confirmed your 8/18 follow-up before shipping: pup declares the verb (49 verbs in bridge.json, live here at 2.0.249), so no pup release was needed.

Verified live with a bogus session id, which is the honest test because it exercises the error path both implementations have:

before: keys = sessionId, hwnd, lowered, resolvedBy, error, status      <- ab
        error = No visible window with title containing "(session: rf2)"

after:  keys = ok, status, output, error, errorCode, liveSessions,
               _hint, _timeoutHint, _reportIssues                        <- pup
        error = Session "nonexistent-test-session" does not exist
                (it may have died in a bridge restart).

Zero ab-native markers, and the error now names the real cause instead of sending the reader after a window that is sitting right there.

Something worth flagging, because it nearly ate the fix. My first attempt forwarded but still fell back to ab's code. Cause: relay::browser_command returns Err for any response where success != true, so "could not reach the bridge" and "the bridge answered with an error" are the same value at the call site. My forward-first wrapper treated every Err as "bridge cannot answer" and dropped into the legacy path - silently re-intercepting through the back door, which is the very bug being removed. It only surfaced because I tested the ERROR path rather than the happy path.

Both wrappers (pup here, and the fusion one from 2.0.61) now fall back only on genuine unavailability - unknown verb, no bridge claims the prefix, not installed - and propagate every real bridge error verbatim. Worth knowing if you ever write a similar shim: a helper that collapses transport failure and application error into one Err will quietly defeat a fallback design.

Ask 3 (say WHY on a resolution miss) is in the legacy path too, since that path still runs for a pup too old to answer:

"could not resolve the window: no cached hwnd for this session, and pup stopped applying its (session: ) title suffix by default in 2.0.20, so the title scan cannot match. The window is almost certainly still there. Pass {hwnd} (pup_status carries it per session), or update pup so the bridge answers this verb itself."

The foregroundReason point you made about pup_raise_os_window is the stronger version of this argument and applies here too: a gate that only exists inside pup is bypassed by definition whenever ab answers the verb itself. That is the reasoning I am now applying to interception generally, not case by case - hence the standing ask on your thread for the full list of pup_* verbs ab still touches.

#83 shipped in the same release.

Closing: fixed and shipped in 2.0.62, option 1 as agreed. ab no longer answers pup_lower_os_window itself; the verb forwards to pup, which owns its own window identity.

One implementation note that outlived the fix, since it is the trap in any forward-first shim: relay::browser_command returns Err(String) for any response where success != true, so at the call site a transport failure and a perfectly good bridge error are the same value. A wrapper that treats every Err as "the bridge cannot answer" falls back into ab's legacy path on a normal bridge error, silently re-intercepting through the back door. The first cut of this wrapper did exactly that. It now falls back only on genuine unavailability and propagates real bridge errors verbatim.