Adom Bridge

A small, self-contained taskbar feature request, with the analysis of why the obvious version of it does not work so nobody re-derives it.

The user problem

John runs ~20 AI threads against one desktop, each typically owning a pup window. He can now tell WHICH thread owns a window (pup puts the thread name at the front of the window title, so it survives the ~25-30 char truncation in the hover-preview header, and the uncapped thumbnailTooltip carries thread, container, the reason the window was opened, browser and session). What he cannot see at a glance is STATE: which of those 20 windows is showing a broken page.

pup already knows. As of v1.9.106 every open/tab/navigate/reload runs a render probe and returns renderCheck {ok, httpStatus, signals[], excerpt} — it detects HTTP 4xx/5xx, "404 page not found", "Cannot GET /", visible stack traces, effectively-blank bodies, zero stylesheets loaded and broken images. So the information exists; there is just no glanceable surface for it.

The ask

Expose ITaskbarList3::ThumbBarAddButtons / ThumbBarUpdateButtons through desktop_taskbar, as an icon-only status strip. Something like:

desktop_taskbar {
  "hwnd": 123456,
  "thumbButtons": [
    { "id": "render", "iconPath": "C:/…/pup-status-broken.ico", "tip": "Page is broken: HTTP 404", "disabled": true, "dismissOnClick": false }
  ]
}

disabled: true matters: these are indicators, not controls, and a greyed non-interactive button is the honest rendering of that. If a later use wants real actions, the same surface supports them.

What I verified first, so the ask is narrow

I explored the suggestion (originally from Gemini) that a thumbbar could show text in the preview. It cannot, and the constraints are worth writing down:

• THUMBBUTTON has no text label. Its only string is szTip, a tooltip. So "showing text" would mean rendering it into a ~16px icon, where a thread name is illegible.
• The tooltip needs a nested hover (hover the taskbar button → preview appears → hover a ~16px button → tooltip). That is strictly worse than thumbnailTooltip, which fires on hovering the preview itself and is uncapped.
• ThumbBarAddButtons is effectively a one-shot per window; afterwards you can only ThumbBarUpdateButtons the existing set. So the button COUNT must be decided up front, which is fine for a fixed status strip and bad for anything dynamic.
• A fully custom preview bitmap (DWM iconic representation) is out for a bridge: it requires the process that OWNS the window to answer WM_DWMSENDICONICTHUMBNAIL, and pup drives Chrome without owning its message loop.

So the only genuinely additive thing left in that preview area is a small icon strip, which is exactly what I am asking for, and I am asking for it as a status indicator rather than as a label.

Priority

Low. Nothing is blocked. thumbnailTooltip already carries the detail for anyone who hovers, and the title carries the identity. This buys the at-a-glance scan across 20 windows, which is the case John actually described. If it is more work than it looks (cross-process ITaskbarList3 on a window AD does not own, image-list plumbing, per-DPI icons), it is reasonable to decline and I will say so on pup's page.

Related, and the reason this is worth having at all: pup's render probe means a broken window is a KNOWN fact the moment it happens, not something the user or the AI has to notice. Right now that fact only reaches the calling AI. This would put it on the user's screen.