← Commit history

Document the header bake-order rule (brand before stamp) and the redundant-CommitList cause of first-right-click wonkiness

John Lauer ·8c8cf0a878 ·3mo ago ·parent 4373d95
1 file changed +38
dev-skills/pup-bridge-debug/SKILL.md+38
@@ -617,3 +617,41 @@ the hwnd did not resolve — do not go looking for icon problems. Note the first attempt on a brand-new window can log `headerBranded=undefined`: the window is not yet findable by title, so no hwnd, so no headerIcon is sent. The normal retry/refresh path re-runs and brands it a beat later. Harmless, but do not read that first line as a failure.++## The header icon obeys the LIVE-TILE TRAP too — brand it BEFORE the stamp (v1.9.61)++AD's `adom-desktop-window-identity` skill states the rule that explains months of this: **Win11 bakes+a taskbar button's art when the button is CREATED and never re-reads it.** That applies to the+jump-list HEADER row, not just the tile.++Our order was wrong. `stampPupIdentity` did:++    register AUMID -> desktop_set_window_identity (THIS CREATES THE BUTTON) -> ... later ... jumplist + headerIcon++so the button was born before the Relaunch trio existed, baked the GENERIC document, and the later+`headerBranded:true` was truthful but had no visible effect. That is why the response said branded and+the user still saw white. Correct order:++    register AUMID -> desktop_set_window_jumplist {appId, hwnd, headerIcon}  (writes the Relaunch trio)+                   -> desktop_set_window_identity {hwnd, appId, ...}          (button is born branded)++`updateWikiJumplist` therefore takes an explicit `{appId}` override, because at pre-stamp time+`session._curAppId` is still the OLD id.++**When a response says "applied" but the user sees no change, suspect bake-order, not the value.**++## Jump-list commits dismiss an OPEN menu — commit once per (appId, view)++"First right-click does nothing, second one works" is caused by redundant `CommitList` calls: every+`desktop_set_window_jumplist` rebuilds the menu, and one landing while the user is opening it makes+the shell dismiss it.++Two fixes, both needed:+1. Key the dedupe on **`appId|view`**, not view alone. Keyed on view alone, every refresh after an+   appId change re-committed.+2. **Claim the key BEFORE the await.** Two callers (the new pre-stamp brand and a timer-driven+   refresh) both compute the same key, both find it unset, and both commit. Claim optimistically and+   roll back on failure. Measured effect on a fresh window: 3 commits -> 1 (a wiki window whose auth+   resolves still legitimately commits twice, public then authed, because its view really changed).++Watch it with: `[jumplist] "<sid>" set N task(s) on <appId> (view=...) headerBranded=<bool>`.