Taskbar button can render BLANK (overlay badge on empty tile) until something rebuilds the button

by adom

pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.

Overview Files Skills Discover Packages Releases Dependencies Issues17 Breadcrumbs Pull Requests1 Activity

Closed bug report

John Lauer · 2mo ago ·closed by John Lauer

Seen live by John on AdomLapper 2026-09-02 (pup 2.0.370, Win11): one pup taskbar button showed NO base art at all - just the small favicon overlay card top-right and the running pill - while sibling tiles (ah ship, Grok Bot, pup-bridge) rendered fine. Forensics: the window was hero-studio-8847, owner 'ah ship check windows'; its thread AUMID (Adom.Pup.thread.ah-ship-check-windows-426878.t7i6da0eb) WAS registered in HKCU with IconResource pointing at an EXISTING tile .ico, and pup's pending/red machinery reported nothing wrong. So the shell had cached a no-icon state for that button (most plausibly the identity stamp landed before the icon registration was readable - the v2.0.275 ordering guard may not cover the adoption/recovery stamp path) and nothing ever nudged the button afterward. A taskbarMode double-flip (tiles->aumid->tiles) rebuilt every button and the art appeared instantly, confirming registration+file were fine and only the shell's cached button was stale. Asks: (1) after registering a NEW thread AUMID key, always force a button rebuild nudge on windows stamped with it, including the adoption/recovery path; (2) the overlay badge compositor should not paint a badge onto a button whose base identity has not been verified applied - a badge on a blank tile is the most confusing possible rendering; (3) consider a periodic cheap audit comparing each live window's STAMPED aumid against the owner thread's CURRENT aumid, re-stamping on mismatch (related: #70, recovered windows silently downgrading). Evidence screenshots archived in the maintainer session 2026-09-02.

2 Replies

John Lauer · 2mo ago

Progress + a corrected premise. Shipped 2.0.378/379: (a) a recovered window whose identity would otherwise be a silent no-op at the idempotency gate now gets its AUMID registration re-asserted and one button rebuild; (b) [identity] and [thread-tile] events now land in the /status investigation log so stamps and nudges are auditable on a live box. Finding from that log on AdomLapper: a recovered window does NOT come back with _curAppId restored, so it takes the FULL stamp path (register -> brand -> stamp -> nudge) - the log shows exactly that sequence for a restored window ('restored persisted hwnd' -> 'stamped appId=...' -> 'button nudge: NUDGED'). So ask 1's premise (recovery skips the nudge) was wrong; the new gate branch is a safety net, not the cause. The ghost this morning therefore came from shell-side timing AFTER a correct stamp+nudge (most plausibly the rebuild landing before the shell could read the fresh registration), which a mode double-flip healed by rebuilding later. Not adding a speculative delayed second nudge without a repro; if the ghost recurs, the audit log will now show the exact stamp/nudge timeline to design against. Asks 2 (badge waits for verified base) and 3 (periodic stamped-vs-expected audit) remain open.

John Lauer · 2mo ago

Ask 3 shipped and proven in 2.0.386 (insiders): every 5 minutes pup reads each live window's ACTUAL stamped AUMID (SHGetPropertyStoreForWindow, one PowerShell per sweep for all hwnds) and compares it to what it believes; a mismatch is logged and re-stamped through the normal path (register + stamp + button rebuild). pup_rescan runs the same audit on demand, so a user or thread can heal a wrong taskbar icon immediately. Live proof on AdomLapper: audit ok (2 windows) -> I stamped a bogus id on pup-wiki with desktop_set_window_identity -> next rescan logged 'AUDIT MISMATCH "pup-wiki": stamped=Adom.Pup.audit-test expected=Adom.Pup.thread.pup-bridge-...' and re-stamped -> the following audit reported ok again. Ask 1 (recovery safety net) shipped in 2.0.378. Ask 2 (hold the overlay badge until the base identity is verified applied) is superseded by the audit: a ghost now self-heals within 5 minutes or on any rescan, and the audit log names the exact stamp timeline if it ever recurs. Closing.

John Lauer closed this · 2mo ago