app

Pup - Puppeteer Bridge

Public Made by Adom

by adom

pup is the AI's own browser: a real, full Chrome on the user's desktop that the AI fully controls (a sandbox, not the user's signed-in browser). Rides Bridge; pup_* verbs open windows and tabs, navigate, screenshot, and eval JS.

skillspuppuppeteerbrowseradom-bridgebridgepup-bridge
Overview Files Skills Discover Packages Releases Dependencies Issues5 Breadcrumbs Pull Requests Activity

Commit History

latest 1000 ← Back to Activity
The jump-list picture is now a REAL screenshot (John: 'your fake mockup is horrible. only screenshots will tell the real story' - and he was the one whose right-click made it possible). Captured live on his machine via the burst pattern: pup toasts 'right-click it and hold the menu open', runs a ~1s screenshot loop, and auto-picks the frame with the largest Win11-menu-colored region above the taskbar; the winning frame shows the actual flyout (Adom Pup / Pin to taskbar / Close all windows) above the real highlighted pup button, cropped tight and doubled for legibility. The setting description now explains what the user is looking at: these are the DEFAULT entries; turning the setting on adds pup's wiki tasks (Switch to logged-in view / Switch to public view). The dev skill records why the direct approaches failed (AD right-click focuses-first + the Win11 first-click blip; the window-class watcher missed) and names burst capture as the go-to pattern.
John Lauer · d0098f4 · 9d ago
Publish 1.9.266
John Lauer · 2b30bd2 · 9d ago
AUMID explainer tooltip + honest jump-list labeling. (1) John: 'put a tooltip hover in the settings for aumid explaining better what that stands for, what the feature is built into windows, and technically how it works' - the AUMID row now carries an info badge whose tooltip explains: AUMID = Application User Model ID, a Windows-native feature; every taskbar button is a GROUP keyed by this ID; normally all of an app's windows share the app's ID (why 5 Chrome windows stack under one button); pup writes a unique per-window ID via the Windows property system so each window gets its own button; and the catch - changing a window's ID makes Windows destroy and recreate its button, which is the suspected crash vector and why pup stamps exactly once at creation. Built per the tooltips skill: body-appended fixed div, 600ms reveal, clamped to the viewport on both axes, never a title attr. (2) The jump-list image is now explicitly labeled an ILLUSTRATION pending a real screenshot: two live capture attempts failed (a grouped button showed hover thumbnails instead of the flyout; a pixel-hunt retarget hit the Adom Desktop window's teal UI instead of a taskbar tile) and per the mouse-takeover protocol the mouse work stopped there rather than flailing.
John Lauer · ae5f69e · 9d ago
Publish 1.9.265
John Lauer · cadacf3 · 9d ago
Settings dialog round 3 (John's live review, four fixes). (1) The AUMID example now shows ONLY pup windows ('can you NOT show me other taskbar icons in this view? it confuses me') - a clean synthetic comparison built from his machine's real Chrome icon and the real pup tile: OFF = the same 5 windows stacked under ONE Chrome button; ON = the same 5 windows as 5 separate buttons. (2) Split vs grouped got its own comparative images ('that setting is REALLY confusing'), switching with the pulldown like icon-style: split = 5 separate buttons; grouped = one Adom Pup button wearing a 5-count. (3) TEST FLASH diagnosis ('the test flash button didn't work'): Windows never flashes the button of the FOCUSED window, and he clicked test while the dashboard was his active window - the caveat is now printed right under the test button, and the flash-all response reports how many buttons the flash was actually delivered to, shown in the toast ('N of M delivered'). (4) Jump-list real-screenshot capture is next (his mockup verdict: 'horrible. only screenshots will tell the real story') - this build carries the groundwork; the capture lands as an asset swap.
John Lauer · a2819b7 · 9d ago
Publish 1.9.264
John Lauer · 4816423 · 9d ago
Icon-style choice made comparable (John: 'i need to see a std vs category otherwise i have no idea what i'm choosing. perhaps show me the alternate screenshot depending on which pulldown item i choose'). The icon-style row now shows a simulated taskbar strip of the SAME five pup windows under the currently selected style - standard: five identical pup tiles ('every icon identical'); category: each window wearing its own tile ('icon shows what each window is') - built from the real shipped .ico art, and the image SWAPS INSTANTLY when the pulldown changes (before the save round-trip) so compare/contrast is one click back and forth.
John Lauer · 0c0c235 · 9d ago
Publish 1.9.263
John Lauer · 798d070 · 9d ago
Canonical term corrected to TASKBAR FLASH (John: 'what does windows call that feature... cuz that's probably the name we should use cuz is it always orange?'). Windows' own name is 'flashing' (FlashWindowEx; Microsoft docs: 'the taskbar button flashes'; the steady lit state is the attention state) - and it is NOT reliably orange: the color follows the system accent/attention theme (salmon on his Windows 11, classic orange on Windows 10). So 'orange highlight' was wrong twice and the OS term wins: every user-visible string now says taskbar flash / flash (buttons, header tooltips, toasts, both settings rows, the test buttons now 'test flash'/'clear flash'), with color described as accent-dependent. Full naming decision trail recorded in the dev skill, superseding the orange-highlight entry.
John Lauer · 194a2e3 · 9d ago
Publish 1.9.262
John Lauer · ef41e40 · 9d ago
Settings dialog round 2, all from John's live review. (1) PICTURES: users won't know what AUMID is, so the dialog now shows real screenshots - the AUMID row shows his actual taskbar in both states (off: windows share one Chrome button / on: every window its own icon, from the split-mode era captures); the icon-style row shows the real standard tile next to the five category tiles (wiki signed-out, wiki signed-IN padlock, open web, adom app, mixed) extracted from the shipped .ico files; the jump-list row shows an illustration built from pup's REAL jump-list entries (Switch to logged-in view / Switch to public view). Served from icons/settings-ex via /dashboard/example. (2) TEST BUTTONS: a 'test' button on the caption row shows a sample AI-foreground caption at the configured duration (new test-caption action), and the orange-highlight row got 'test highlight' / 'clear highlight' buttons with a live count of open pup windows right beside them so the user knows exactly what will light up. (3) CONSISTENT NAME: the FlashWindowEx attention state is now called the ORANGE HIGHLIGHT in every user-visible string (buttons, tooltips, toasts, settings labels) - John always calls it that and the UI calling it 'flash' made settings unrecognizable; internal identifiers keep their names (UI-language rule, recorded in the dev skill). (4) DEFAULT CORRECTED: orange highlight on new window defaults ON (it always had been until my settings build wrongly defaulted it off); stored 'off' values migrate to on unless the user chose off in the dialog themselves (choice-marker).
John Lauer · 0572a04 · 9d ago
Publish 1.9.261
John Lauer · 484929e · 9d ago
AUMID icon-style sub-setting (John: 'show another sub-setting that lets you pick to just use one standard icon for all aumid windows, or the 4 (or 5) custom ones you made that try to differentiate between logged out and logged in state of wiki, the world icon, the adom app icon, etc'). New aumidIconStyle pref, default 'standard' (one pup tile for every stamped window - least shell churn for the crash experiment); 'category' switches to the custom per-category set (pup-cat-wiki / wiki-in padlock / web world icon / app / mixed). Enforced at pupIconPath, the single place stamp art is resolved, so the stamp, the jump-list header, and the dashboard /stampicon endpoint all follow it. Rendered as a dependent sub-select under the AUMID toggle, enabled only when the experiment is on.
John Lauer · dac3574 · 9d ago
Publish 1.9.260
John Lauer · 9a6f4a0 · 9d ago
Settings endpoint actually works + readable caption default (ralph caught my own regression before John did, then his live feedback landed too). (1) THE BUG: in the dashboard action handler the parsed request body is 'a' and 'body' is the raw string - my set-setting block read body.key, so every settings change failed with 'unknown setting or value' (and the fg action's tab-switch read body.tabId, silently never switching). One-word class of bug, fixed to a.key/a.value and the already-parsed tid. (2) John: '2s feels too fast cuz i can't read' - the caption duration default is now 3.5s (slider 0.5s to 5s unchanged), with a one-time migration of stored 2000 (the hours-old previous default, not a dialog choice). (3) Ralph's [send to bg] check exposed a real interplay bug: a deliberate browser_lower z-bottoms the window but Windows KEEPS its input focus, and the no-fault watch then mislabeled that residual focus as 'surfaced without pup' and re-marked the window foreground - a lower now disarms the watch. (4) Ralph hardening: settings checks drive the endpoint from INSIDE the page (immune to cmd.exe quote-mangling, which was producing 'unknown action' from shell-side curl), and the raise-path curl timeout gets headroom (45s).
John Lauer · de7d831 · 9d ago
Publish 1.9.259
John Lauer · 2f7a2e1 · 9d ago
The pup settings dialog (John: 'we need a settings dialog in the dashboard now', + 'if there are other prefs i forgot about, add those too', + the orange-hilite toggle). A gear button in the dashboard header opens a modal with FOURTEEN live preferences, each wired to a real behavior gate and persisted across bridge updates: (1) AUMID taskbar icons, default OFF - John's EXPLICIT experiment re-decision per the dev-skills/pup-aumid-decisions process rule ('then i can play around with having it on or off and see if aumid is what is crashing the app or not'); on = one gentle stamp per window at creation, each window its own icon, with the split/grouped sub-select enabled only when on; (2) jump lists, default OFF; (3) the 20s foreground watch (no-fault caption), default on; (4) caption-on-AI-foreground, default ON, with a sub-slider for duration (0.5s to 5s, default 2s) that enables/disables with its toggle - a USER-chosen duration may exceed the AI 2s anti-rudeness cap because that cap exists to stop the AI, not the user; (5) favicon overlay badges; (6) orange highlight on new-window open, default off; (7) flash on agent activity; (8) taskbar progress bar; (9) sleep/crash recovery; (10) auto-fill saved logins; (11) issue-report hints; (12) minimal-touch master mode; plus grouping and duration as dependent sub-controls. Server side: whitelisted set-setting action with validation, settings ride the SSE snapshot, every change answers back with a toast. Toggles follow the adom-ui-design toggle rules (role=switch, aria-checked, two visual differences between states). Ralph grew 4 effect checks: roundtrip persistence, unknown-key rejection, dialog renders all controls, and the slider disables when its parent toggle turns off.
John Lauer · 9c534a5 · 9d ago
Publish 1.9.258
John Lauer · 08daf17 · 9d ago
Dashboard self-reloads when the bridge version changes (John hovered the new err tooltip and saw nothing - his open dashboard page was baked from the previous build; the SSE feeds it fresh DATA but the RENDER code is load-time). The page now bakes its own version and reloads once when the SSE reports a different bridge version, so an open dashboard always follows the bridge within one SSE tick of an update.
John Lauer · 2a0e8bd · 9d ago
Publish 1.9.257
John Lauer · ba7553d · 9d ago
The err tag explains itself (John: 'if there's an err, let the tooltip show what the error is'). The window snapshot now carries the last 5 actual error entries (console.error text / uncaught exception message, truncated to 160 chars), and the red 'N err' tag's tooltip lists them, newest last, instead of leaving the user with a bare count.
John Lauer · 82c6522 · 9d ago
Publish 1.9.256
John Lauer · 33c1e0f · 9d ago
Sleep/wake recovery, ungated (John, back after a day with the lid closed to a dashboard full of 'browser lost': 'a laptop going to sleep is quite a common occurrence so you need to make sure after a wake that you are able to get back to the previous state you were in'). ROOT CAUSE - the third victim of the gated-interval disease: the crash/lost-browser recovery loop lived inside the health interval whose first line is 'if (minimalTouch()) return', so in the normal mode NOTHING ever recovered a lost session; his three windows sat dead for a day while the machinery to revive them was one dead gate away. Fix: recovery moved to its OWN ungated 20s interval with sleep detection (a >90s gap between ticks = the machine slept; logged), recovering every _lostBrowser session via recoverOrRelaunchSession - reconnect if that profile's Chrome survived the sleep, else relaunch at the last URL with logins intact from disk, with the existing per-session backoff. The minimal-touch nuance is recorded so nobody re-gates it: minimal-touch forbids killing/restarting a LIVE Chrome behind the user's back; it does not forbid resurrecting DEAD windows - that restoration is exactly what the user wants. Hung-Chrome teardown (which kills) stays gated. The gated-interval disease (three victims: overlay enforcer, user-activity watcher, recovery) is now a named banned practice in dev-skills/pup-bridge-dev: every new loop gets its own interval with an explicit written gate decision.
John Lauer · 2be9d1b · 9d ago
Publish 1.9.255
John Lauer · 8050cbe · 10d ago
Foreground captions on EVERY raise path + the NO-FAULT WATCH (two John additions to the iron law). (1) 'if a user asks to fg, you show a caption for 2 seconds explaining the reason. do you do that? cuz i asked you 100 times' - the browser_raise verb captioned, but the FIVE other raise paths routed through osRaiseSessionWindow (wiki view toggle, sign-in raise, wiki auto-login, heal-retry, assisted-click) captioned NOTHING. Now enforced at the choke point: osRaiseSessionWindow takes a reason and captions it for 2s; all five call sites carry genuine reasons; assisted_click passes null since it narrates its own captions. A new raise path without a caption is now definitionally a bug. Also honest context: until 1.9.244 this morning, even the paths that DID caption were showing for ~30s not 2s because the expiry never reached AD (the duration parameter rename) - all 100 asks were being betrayed by one wrong parameter name. (2) The NO-FAULT WATCH ('if the window does get foreground by chrome itself or a focus or some other reason, you watch it for 20 seconds and put up a caption saying it was not my fault'): for 20s after each background open/nav, pup polls the OS foreground only while armed; if the window surfaces without a pup raise it captions 'This window was NOT foregrounded by Adom: JavaScript, a focus change, Chrome itself, or your own click raised it. Not me!' for 2s, marks it foreground (iron law: whatever raised it, it stays up), and backs off. CAPTION ONLY, never a knockback - the knockback variant was 1.9.252, killed same day. Both recorded as clauses 3 and 4 of the IRON LAW in dev-skills/pup-bridge-dev.
John Lauer · 9b1951e · 10d ago
Publish 1.9.254
John Lauer · 7a64941 · 10d ago
The fg-steal guard is REMOVED, same day it shipped (John: 'if the user clicks that windows taskbar icon to bring it to the fg, you MUST do it immediately - forcing it to the background for 20 seconds is RUDE AS FUCK'). He is right, and the SOLVED PLAYBOOK in dev-skills/pup-bridge-dev already prohibited exactly this - 'do NOT add any loop that re-parks after the initial park; every such loop, no matter how clever (input-timing, short windows, stability watches), eventually yanks a real user's click; John proved each variant failed' - I built 1.9.252 without re-reading it. Removed: the guard interval, the guard arming in reassertBottomAfterNav, the 3-strike logic, and the osRestoreForeground AttachThreadInput helper (the playbook says new code never needs it: with --no-startup-window the browser is a background process and the OS itself denies it the foreground - and the live measurement agreed). KEPT, because they fix the disruption at the SOURCE per the playbook: the hwnd-targeted background call (BestWindow picked the largest window of the process instead of the session's own - the wrong-window 'backgrounded' lie), and a diagnostic-only focus measurement at window creation that logs ONLY if the playbook assumption ever breaks. The IRON LAW (bg always; a user's taskbar click wins immediately and unconditionally) is now recorded verbatim at the top of the playbook with the incident log.
John Lauer · 69bf931 · 10d ago
Publish 1.9.253
John Lauer · 645b713 · 10d ago
The adom-theme foreground disruption, ROOT-CAUSED and fixed at the source (John: 'i don't believe you that chrome is auto-foregrounding the windows' - he was right to push back; the evidence for self-raising was my own scheduled re-assert log lines, not detected raises). The REAL mechanism, from reading the code paths: (1) Target.createTarget{newWindow} can grab OS focus at creation (the codebase's own launch-path comments acknowledge the same grab at browser launch); (2) the immediate 'backgrounded' call resolves its target as the LARGEST VISIBLE window of the process (BestWindow) - wrong window whenever the shared profile has several, so it claimed success while the new window kept its creation focus; (3) the post-nav park moved the still-FOCUSED window on-screen, surfacing it in the user's face; (4) osBottomUnlessForeground then read that focus as user intent and refused to bottom it until the user clicked away. Fixes: creation now MEASURES the OS foreground before/after createTarget and logs it (no more theories), and if focus moved it is handed straight back to the user's window (AttachThreadInput restore) while the new window is still off-screen and invisible - so parks act on an unfocused window and nothing ever surfaces; osBackgroundWindowByPid accepts the session's own hwnd and only falls back to BestWindow when none is known; browser_lower passes it. The 1.9.252 fg-guard stays as a safety net but the narrative is corrected: the code's own doctrine (v1.8.49) is that Chrome does NOT self-raise after startup.
John Lauer · dee9c00 · 10d ago
Publish 1.9.252
John Lauer · 4d7c816 · 10d ago
FG-STEAL GUARD (John: 'why did that pup window that just opened to the adom-theme disrupt me in the foreground?'). Diagnosis from the log: the ats-publish window (hd-theme thread) was born off-screen, backgrounded, and bottomed post-nav as designed - but Chrome SELF-RAISES parked windows on late paints / in-page focus(), the sibling adom-vscode-wiki window needed SIX re-bottoms in a row, and once the scripted re-asserts end a late raise STICKS. The v1.9.180 user-activity watcher that would have caught it is minimal-touch-gated, i.e. dead in the normal mode (the same dead-under-the-gate disease as the overlay enforcer). Fix: an ungated fg-steal guard - for 20s after any background open/navigation (armed inside reassertBottomAfterNav so every open/nav/new-tab path arms it), pup polls the OS foreground at 2.5s ONLY while a guard is armed (zero steady-state cost) and immediately bottoms a background pup window found holding the foreground without a granted foregroundReason, returning the screen to the user. Three knockbacks inside one guard window means a human is insisting, so the human wins: guard backs off and marks the window user-foreground. Deliberately NOT gated by minimal-touch: user protection, same doctrine as the foreground-reason caption. Rule + history recorded in dev-skills/pup-bridge-dev.
John Lauer · bd80192 · 10d ago
Publish 1.9.251
John Lauer · 50d5537 · 10d ago
Footer printed a literal '·' - the entity was set via textContent, which does not parse HTML. Real middle-dot character now.
John Lauer · 1979349 · 10d ago
Publish 1.9.250
John Lauer · 4e5391e · 10d ago
Dashboard brought into adom-ui-design compliance (John: 'did you follow our ui design skills when making your app? what does it say about headers and icons?' - honest answer was no, so now it does). HEADER (skill section 5): replaced the pill-soup row with the canonical 44px single-row three-zone header - brand zone left (16px monochrome currentColor icon + 'pup ยท live windows' in Familjen Grotesk 600 accent, with the app-info POPOVER on 600ms hover / 220ms hide grace carrying version, platform, bridge uptime, deps, and the clickable wiki link), 1px hairline, subject zone center (subject name + muted JetBrains Mono meta line with windows/tabs/icons/LED/updated, hidden below 720px), icon-button actions right (flash-all / clear / close-all as monochrome stroke SVGs with tooltips + aria-labels). The VERSION IS OUT OF THE ROW (the skill explicitly bans it inline; popover only). Filter + search moved to a toolbar bar below. ICONS (section 9): 'monochrome white, no exceptions... and the favicon' - the teal favicon violated the master rule, redrawn as #e6edf3 strokes on the dark ground tile, same two-windows+pulse concept. COLOR: the whole stylesheet used #12e0c4, a WRONG retyped teal (the skill's own cautionary tale is a one-digit teal error reaching 148 files) - every accent is now the real #00b8b1, on-accent #05221f, grounds/borders/text on the token values, body text at --text-body not max-contrast white. FONTS: brand faces loaded (Familjen Grotesk headings, Satoshi body, JetBrains Mono for the data/meta line) instead of the system stack. FEEDBACK (section 3): every dashboard action now answers back with a bottom-center toast (success green / error red sticky-8s / info) reporting what actually happened including the clear-flashes swept count, and the POST /ui/toast narration hook is built so the AI can talk over the live app (delivered via the SSE snapshot). Ralph grew 5 compliance checks: header exactly 44px, version NOT in the header row, favicon monochrome (accent-hex grep), /ui/toast answers, toasts render.
John Lauer · e279ea4 · 10d ago
Publish 1.9.249
John Lauer · f3c47eb · 10d ago
Strip scope made explicit: TASKBAR (pup), with a tooltip stating it mimics ONLY pup-managed Chrome buttons. Root of John's 'not accurate to what is showing in the taskbar': two teal-tile buttons on his real taskbar that the mimic does not show were identified definitively (via window enumeration with owning process) as Hydrogen Desktop and Adom Desktop app windows - other Adom apps wearing the same teal brand tile, never pup windows. The mimic was right not to model them, but claiming 'TASKBAR' without scope read as a whole-taskbar claim, which is how the green MATCH light looked like a lie next to visibly unmodeled tiles. The 1.9.248 untracked-window detection remains for the case that IS pup's to own (zombie windows of pup Chrome processes - it caught one, hwnd 14552128, before that process exited).
John Lauer · cc0ddf1 · 10d ago
Publish 1.9.248
John Lauer · 68b3214 · 10d ago
AUMID REVERTED + the dashboard stops lying about taskbar match (two John callouts). (1) THE AUMID RELAPSE: v1.9.245 re-enabled per-window AUMID stamping off an ambiguous feasibility question, silently reversing the settled 2026-07-29 no-AUMID decision that took two days of pain to reach (minimal-touch measured verdict: 'not branding the icons is making pup perform better'; overlays yes, AUMIDs no). John: 'we just spent 2 days having you stop using aumid and you just started using aumid again?' REVERTED in full: the stamp gate is absolute again under minimal-touch (no once escape hatch), the create-path stamp is re-gated, the enforcer stamping is removed. Windows stamped during the relapse keep their buttons until they close (the AUMID property lives on the window; un-stamping would destroy buttons again) and the dashboard models them truthfully as legacy. The complete decision history, the Windows facts, and the process rule for ever revisiting this (name the decision being reversed + get explicit consent FIRST; a question is not a mandate) are recorded in the new dev-skills/pup-aumid-decisions/SKILL.md. (2) THE LYING LED (John: 'your dashboard view of the windows taskbar icons is not accurate to what is showing in the taskbar and yet you have a green led indicating it is'): the MATCH light was a model-consistency check dressed as a glass-consistency check - it never looked for real taskbar buttons pup is not modeling at all. Windows offers no read-back API for button art, but pup CAN catch the worst lie: the snapshot now enumerates every visible window of pup-managed Chrome processes (cached 12s) and diffs against tracked session hwnds; any untracked window renders as a dashed ? ghost button in the strip, forces the header LED red with 'N UNTRACKED', and its tooltip says exactly why. The LED semantics + never-overclaim rule are recorded in the dev skill. Also purged a pre-existing em-dash from the strip tooltip.
John Lauer · 54f995f · 10d ago
Publish 1.9.247
John Lauer · e492f6c · 10d ago
Stamp enforcement retries on a 45s cooldown instead of once-ever. The create-time stamp can race the fresh window's title tag (unfindable for a beat), and the enforcer's single lifetime attempt left such a window permanently unstamped and grouped into the process button (audit2-hn, caught live in John's audit round 2, 3 of 4 windows stamped). Same philosophy as overlay enforcement: converge, gently, until true.
John Lauer · 7dd0ba2 · 10d ago
Publish 1.9.246
John Lauer · 35e5874 · 10d ago
Strip base icon now matches the REAL stamped button (John's audit rule: dashboard must truly represent the windows taskbar). With per-window stamping live, a stamped window's real taskbar button shows the icon the stamp registered - the teal Adom category tile - not the Chrome exe icon, but the dashboard strip still drew Chrome as the base. New /dashboard/stampicon endpoint serves the exact ico pupIconPath registered for that session (largest PNG entry), and stamped buttons in the strip/tree use it; unstamped process-group buttons keep the real browser exe icon. This also retroactively explains the two mystery teal tiles in the earlier audit: leftover stamped pup windows, not another app. Ralph note: the full-button suite runs 15/16 on 1.9.245 with the one failure being the test's own 10s curl timeout tripping on the raise path (which can legitimately run a 9s PowerShell hwnd resolve); test timeout raised to 30s. The glass flash check is now conclusive: flash-all lit the real taskbar +156 attention pixels and clear-flashes removed it to 0 residual.
John Lauer · 616c8f8 · 10d ago
Publish 1.9.245
John Lauer · c202346 · 10d ago
One taskbar icon per window + tabs born in the right window (John's audit + his ask: 'why are all the windows you opened in the same taskbar icon? when i say to pup open a window i generally want them as separate taskbar icons. is that not as feasible now that you do everything under the adom-you profile?'). It IS feasible: window identity is a per-HWND property, not per-process, so the shared profile is irrelevant. pup now gives every window a ONE-TIME gentle AUMID stamp at creation (and the 10s enforcer catches up any unstamped survivor once) - one stamp, one button recreation, then done: none of the category re-stamp churn or jump-list machinery that made the old split mode invasive (those stay off under minimal-touch). After a stamp the taskbar button is REBORN bare, so the overlay is marked unpainted and the enforcer immediately repaints the new button with the window's favicon badge. The dashboard mimic groups accordingly: stamped window = its own button; only unstamped windows (stamp pending/failed, e.g. PDF viewers) share the process button. ALSO fixed the audit's phantom '-split1-' sessions: browser_open_tab created tabs via newPage(), which has NO window affinity - Chrome dropped the tab into the process's most-recently-active window, and the (correct) drag-out detector then adopted the displaced original as a new session. Tabs are now created FROM INSIDE the session's own window via CDP Runtime.evaluate window.open() with userGesture:true (satisfies the popup blocker with no global flag), with newPage() as fallback. Ralph's grouping assertion updated to stamped+process-group arithmetic.
John Lauer · 677dd39 · 10d ago
Publish 1.9.244
John Lauer · 17f4053 · 10d ago
The forever-caption, killed at the root + no more fg/bg toggle + em-dash purge (John: 'i clicked bring to fg and you left the caption up forever. i've told you 100 times to only show that caption for 2 seconds'). ROOT CAUSE: the 2-second clamp NEVER REACHED AD. AD renamed its desktop_caption expiry arg - old builds took expiresInMs, current builds take duration - and pup still sent only expiresInMs, so AD ignored it and used its 30-SECOND default; pup's PUP_CAPTION_MAX_MS clamp was clamping a value nobody read. pupCaption and wikiCaption now send BOTH spellings so every AD build honors its own, and the foreground-reason caption shows for exactly the 2 seconds the standing rule requires. Also purged em-dashes from every user-visible caption/toast string (the no-em-dash rule applies to everything pup puts on screen, not just chat). And per John ('the notion that you would swap bring-to-fg to send-to-bg is asinine - the user alt-tabs to background in a nanosecond, your toggle can never be accurate'): window rows now ALWAYS show both [bring to fg] and [send to bg] statically - no state-derived swapping, because pup's foreground flag cannot track alt-tab reality. Both gotchas recorded in dev-skills/pup-bridge-dev.
John Lauer · d054637 · 10d ago
Publish 1.9.243
John Lauer · 482d1fc · 10d ago
Never-red overlays, clear-flashes that truly clears, fg/bg buttons, full-coverage ralph (four John asks in one build). (1) RED LEDS GALORE root cause: the overlay enforcer added in 1.9.236 sat inside the health interval whose FIRST LINE is 'if (minimalTouch()) return' - minimal-touch is the normal mode, so the enforcer never ran once; after every bridge restart all windows sat bare until some verb happened to repaint. Enforcement now has its OWN ungated 10s interval (overlays are explicitly allowed in minimal-touch, v1.9.191), and rescanProfile repaints every reattached session ~1.5s after a restart - so model==glass within seconds and a window is never knowingly bare longer than ~10s. (2) CLEAR-FLASHES: the 1.9.242 hwnd tracking was per-boot, so flashes started before a bridge restart (every ship) were invisible to the sweep - exactly what John hit twice. clear-all now ENUMERATES every visible top-level window of every pup-managed Chrome process (same PS enum as the badge resolver, filtered to pup's own PIDs so the user's personal Chrome is untouched) and stops each one - no bookkeeping to lose; response reports the swept count. (3) Every window row gets [bring to fg]/[send to bg] and every tab row gets [fg]/[bg] - implemented as loopback self-calls into the REAL raise/lower verbs so every safety behaviour applies unchanged (on-screen caption with the reason, standard reveal geometry, badge re-assert after reveal); a dashboard click is the user acting, which satisfies the foreground gate by definition. (4) The ralph suite now drives EVERY dashboard button and asserts EFFECTS: fg/bg assert the foreground flag + active tab actually changed; flash/clear assert ON GLASS via taskbar screenshots (attention-pixel count must rise on flash-all and fall back after clear) plus the enumerated sweep count; close-all asserts 0 windows remain; collapse/jump/filter widgets asserted in-DOM.
John Lauer · ed1f7c2 · 10d ago
Publish 1.9.242
John Lauer · b82d3bf · 10d ago