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
Document the agent-activity taskbar progress indicator, its transition-only AD call pattern, and the measured blue-not-red rendering
1 file changed
+25
dev-skills/pup-bridge-debug/SKILL.md+25@@ -515,3 +515,28 @@ was never collapsed. Fixed: the injector now COUNTS its own tag and normalises t (`n===1` leave, `n===0` append, `n>1` strip-all-then-append). It only matches its OWN sid so it never fights `retagSessionTitle` on an adopted tab. Duplicated tags also risk AD's title-based window resolution landing on the wrong window — the exact class of bug behind earlier mis-branding.++## Agent-activity indicator: taskbar progress marks the window a thread is driving (v1.9.57)++John runs many AI threads at once and could not tell which pup window an agent was working in. The+taskbar PROGRESS bar answers it with ZERO AD work: `desktop_taskbar {progress:{state,value}}` already+exists, it paints ON the button (glanceable across the whole taskbar), and it is a SEPARATE channel+from the overlay icon, so the favicon overlay is untouched.++- `markSessionBusy(sessionId)` is called from the `/command` dispatch for any `browser_*` verb that is+ not in `PASSIVE_VERBS` (list/status/readiness/configure/prewarm/rescan/wait). A screenshot or an+ eval counts as driving; polling does not, or every window would read permanently busy.+- State is `indeterminate` (marquee), NOT a percentage. An agent's work has no known length and a+ fake percentage would be a lie.+- **Only transitions are sent to AD** (idle->busy once, busy->idle once after `BUSY_IDLE_MS` = 2500).+ A thread firing 200 verbs costs 2 AD calls, not 200. Verified in the log:+ `[activity] "act-a" agent driving — taskbar progress ON` ... `idle — taskbar progress OFF`.+- Cleared on both close paths (`clearSessionBusy`).+- Opt-out: `browser_configure {agentActivity:"off"}` (default on). It is the user's taskbar.++**Colour check (measured, matters):** both `indeterminate` and `normal` render BLUE (the Windows+accent), not red, so the bar reads as "working" and NOT as "error". Verified by painting+`indeterminate` on one window and `normal` value 65 on a neighbour in the same screenshot: the first+shows a sweeping blue marquee segment, the second a blue bar with a grey remainder. Do not assume a+progress bar means failure just because an early frame looked reddish, that maroon button tint is the+pre-existing AUTO-FLASH attention state (scheduleAutoFlash fires on mutating verbs), not progress.