app
Pup - the AI's own browser
Public Made by Adomby 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.
← Commit history
v2.0.585 (insiders): z-order: ab's desktop_clear_window_attention raises the window to z1 (adom-bridge#199), undoing every park at open and after navigation; pup re-bottoms after any attention clear unless the window is the user's foreground. Plus 2.0.584: input beats the birth grace, extension windows park at birth, inset frame.
3 files changed
+27−2
dev-skills/pup-user-foreground/SKILL.md+23@@ -115,6 +115,29 @@ loaded gun pointed at the user's click. HIDE one. A hidden pup window is therefore always pup's own mess, and re-showing it can only ever give the user back something pup took. +## The birth grace may override FLAGS, never INPUT (2.0.584, John 2026-09-15)++R6's birth grace (8 s, no granted raise) skipped BOTH user signals inside the shared primitive, on the+reasoning that "the taskbar button did not exist yet". It exists the instant the window is shown, and+John's exact objection was "within like 200 ms a human might click the windows taskbar icon to see the+window": that click was undone by the +2.5 s re-assert for the rest of the grace. The 2.0.26 insight+already told us how to tell them apart: a programmatic self-raise happens with IDLE HANDS. So inside the+grace the primitive now still honors "keyboard or mouse input in the last 5 s" as a person (hands off,+10 min memory, logged `[park] ... a person raised it, hands off`), and only the lagging session flags+are ignored. Chrome's PDF pop and first-paint raise still get caught: they happen with idle hands.+The extension lane parks to z-bottom ONCE at birth and schedules no re-assert at all: Chrome never+self-activates a window created with focused:false (measured 2026-09-15: the user's Gmail stayed z0), so+on that lane a re-assert could only ever undo a human. Before 2.0.584 the extension open never parked+at all and every new window sat at z1, right under the user's active window, above all their other work.++**And the park was being undone by ab (adom-bridge#199, 2.0.585).** `desktop_clear_window_attention` raises+the window to z1 on every call (measured on AdomLapper: bottom -> z16, clear -> z1; progress and flash leave+z-order alone). pup calls that clear right after the birth park and after every navigation, so "parked at+z-bottom: true" in the log was true for a few milliseconds. Workaround in `activity::clear_attention`: after+a real clear (the helper already returns early when the window is the user's foreground) send the window+back to the bottom. When you see a window at z1 that the log says was parked, suspect whatever ran AFTER+the park, and measure each step alone: that is how this one was found.+ ## The history that hardened each rule (do not re-learn these live) | Era | Lesson |
src/extension/manifest.json+1−1@@ -1,7 +1,7 @@ { "manifest_version": 3, "name": "Adom Pup",- "version": "0.4.1",+ "version": "0.4.2", "description": "Toolbar for Adom Pup browser windows: annotate, snip, view toggle, dashboard, owner info. Thin trigger surface - the pup bridge is the engine.", "action": { "default_popup": "popup.html",
src/extension/worker.js+3−1@@ -416,7 +416,9 @@ async function pupExtPollOnce() { for (const w of wins) { if (w.type !== 'normal') continue; try {- await chrome.windows.update(w.id, { state: 'normal', left: wa.left, top: wa.top, width: wa.width, height: wa.height });+ // 2.0.584: the standard inset frame (pup-bridge-dev: work area inset 10 px on every side), so a parked+ // window reads as deliberately placed, never as a maximize that lost. z-order untouched.+ await chrome.windows.update(w.id, { state: 'normal', left: wa.left + 10, top: wa.top + 10, width: Math.max(320, wa.width - 20), height: Math.max(240, wa.height - 20) }); fitted++; } catch (e) {} }