Pup - the AI's own browser - Commit

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 Issues15 Breadcrumbs Pull Requests Activity

← Commit history

pup-taskbar-states, for real this time (the previous commit message claimed these fixes but the script aborted before writing): cite #53/#54 as CLOSED with #70 as the open gap, fix the internal wipe-vs-converge contradiction (line 51 still said wiped while line 38 said converges), add overlaySize

John Lauer ·5da9fb899e ·2mo ago ·parent f827456

1 file changed +14−7

skills/pup-taskbar-states/SKILL.md+14−7

@@ -14,6 +14,9 @@ preview is DERIVED from the same sources listed here, so preview and reality can  - **`taskbarMode`** — `tiles` (default) | `aumid` | `plain`. Set with   `pup_configure {taskbarMode:"..."}` or by clicking a matrix cell in Settings.+- **`overlaySize`** — `50` | `66` | `75` (default) | `100`: the PERCENT of full size the badge is+  composited at (v2.0.262). At 100 the badge covers the thread tile's bottom line of TEXT; smaller+  keeps the name readable, which is the point of thread tiles. - **`overlayBadges`** — `on` (default) | `off`. The favicon badge in the button's top-right   corner. Independent of the mode; works in tiles and aumid; in plain mode Windows still   accepts a per-window overlay on the stacked stock button.@@ -47,8 +50,9 @@ preview is DERIVED from the same sources listed here, so preview and reality can ## Switching and semantics  - Switching modes re-identifies every live window immediately (stamp + button-rebuild nudge);-  switching to `plain` strips identity from live windows (registry keys + per-window-  properties wiped). Expect a one-time sub-second button rebuild per window on a switch.+  switching to `plain` CONVERGES every window onto Chrome's own native AUMID (see the pixel-sources+  section above — a VT_EMPTY wipe was tried and caused the two-CfT-buttons split; do not describe+  plain as a "wipe"). Expect a one-time sub-second button rebuild per window on a switch. - `tiles` takes precedence over the aumid grouping/style options; those two rows only apply in   `aumid` mode (the dialog grays them out otherwise). - Windows with no owning AI thread (rare) fall back to aumid-style identity even in tiles mode.@@ -69,9 +73,12 @@ re-queues, and the button rebuilds the moment you look away. While it is pending marks that button RED with the reason — pup never reports a green match against a taskbar it knows it has not applied. -## Known state gaps (tracked)+## Formerly-known state gaps (both CLOSED — kept so nobody re-reports them) -- Progress-bar paint through `pup_progress` has a targeting defect (issue #54) — the bar-  machinery itself works (direct-by-hwnd paints).-- A window whose hwnd is unresolved at plain-switch time can keep its branding until closed-  (issue #53).+- Progress-bar targeting (issue #54): CLOSED. Root cause was `minimalTouch` gating, not titles.+- Plain-switch straggler (issue #53): CLOSED.+- Structural since: the thread AUMID folds in a hash of the tile's CONTENT (v2.0.271 — Windows+  caches a button's icon PER AUMID, so only a virgin AUMID can change art), and the button rebuild+  waits for the icon registration to land first (v2.0.275).+- Genuinely OPEN: recovered windows that lose their `owner` silently downgrade to a category+  button — issue #70.