Pup - Puppeteer Bridge

Lint a malformed wiki URL and name the real cause, instead of letting the caller invent one. The HD build thread opened https://wiki.adom.inc/adom-wiki-skillpack, got 'Page not found', and reported to John that 'org pages are invisible to logged-out readers'. That conclusion was WRONG and cost trust: the window was signed in as John the entire time (pup's auto-login had worked), the page exists and is public, and the URL was simply missing its OWNER segment — wiki.adom.inc pages are owner-qualified as // (and ///blob/ for a file). pup already knew the URL 404'd and knew the host, so it could have named the cause. It now does: on a render failure, a new wikiUrlLint() detects a wiki URL with no owner segment (including the /blob/ form), suggests the corrected URL, tells the caller to confirm the real owner with 'adom-wiki page get ' rather than trust the guess, and explicitly says NOT to conclude anything about permissions or login until the URL is right and re-checked. Known non-page routes (apps, skills, components, discover, login, api, ...) are excluded. Unit-tested 6/6 against the thread's three real URLs plus valid controls.

Make a bridge upgrade REPAIR the jump-list task commands on windows that already exist. This is why John's 'Switch to public view' still failed after 1.9.115 fixed the command format: a jump-list task embeds a full CLI command line, and stampPupIdentity only re-commits the list when the appId CHANGES, so any window whose category was unchanged across the upgrade kept its OLD identity-less command and the click was refused silently — while the very same verb worked perfectly when I called it from the CLI, which is exactly why my verification passed and his click did not. On every bridge start pup now clears the jump-list dedupe key for all recovered sessions before the startup brand sweep, so the re-attach is real instead of a no-op and every surviving window gets task commands matching the running version. One AD call per live window, once per boot.

Correct the record on the jump-list blip. The v1.9.112 post-stamp jump-list re-commit did NOT fix it: three fresh windows each got exactly 1 AUMID registration plus 1 re-commit and all still showed the flyout for ~200-300ms before it vanished. The re-commit stays (attaching the destination list to the live button is correct hygiene) but its comment no longer claims to be the cure. The blip is UNRESOLVED and now tracked on adom/adom-desktop#40 with all four eliminated hypotheses and the measurements behind each, plus a decisive diagnostic AD can run on its own window (AD flips its own AUMID for the mode signal, so if AD's own flyout blips the behaviour is inherent to runtime AUMID retagging and reproduces without a bridge).

Jump-list first-right-click dismissal: re-commit the destination list once the taskbar button actually exists. Reached by ELIMINATION, with measurements: nothing fires while windows are idle (0 log lines across 40s), windows that registered exactly ONE AUMID blip too (so it is not category churn), and a registry-only vs Start-Menu-shortcut A/B showed no difference (so it is not the missing shortcut). What every FRESH window shares is that the identity stamp RECREATES the taskbar button (Win11 bakes a button's identity at creation) while the jump list was committed BEFORE the stamp — deliberately, so the header art bakes. So the button is born pointing at a destination list committed against a button that did not yet exist, and the first right-click is the shell reconciling that, which is exactly why the second click works. pup now re-commits the list ~1.6s after a successful stamp, guarded so a superseded stamp does not clobber a newer one. Still a hypothesis until John re-tests a freshly opened window.

A detected render failure must LEAD the response, not hide behind cosmetics (John, reading a real launcher-mockup response). The 1.9.106 verdict was correct and the calling AI did act on it ('Dev server crashed. Let me restart it'), but _hint opened with a FAVICON nag, then a power lecture, then a browser inventory, so the single most important fact — that the page was a 404 — sat screens down past 32 permission strings and an availableBrowsers list. Rich hints are the right instinct; burying the critical one behind cosmetic ones is not. When renderCheck.ok is false, _hint now opens with the failure, the signals, the HTTP status, what the page actually says, an explicit do-NOT-report-success, and the screenshot command, then appends the cosmetic hints marked as secondary.

Stop reporting ok:true for a page that plainly did not render (John's catch). The launcher-mockup thread opened a .adom.cloud app that served '404 page not found'; pup answered ok:true, said nothing, and the AI reported success. Telling the caller to screenshot was too weak, so pup now LOOKS: a new probeRender() checks the loaded document (main-frame HTTP status captured from goto, plus 404 / 'Cannot GET' / server-error / visible-stack-trace text, effectively-blank body, zero stylesheets loaded, broken images) and the open response carries a machine-readable renderCheck{ok,httpStatus,signals,excerpt}. When it detects a failure, _verifyRender no longer offers advice — it LEADS with 'THIS PAGE DID NOT RENDER CORRECTLY, pup checked it, do NOT report success', names the signals, quotes the page, and says do not tell the user it works while this warning is present. Fixed my own silent bug along the way: the HTTP status was being assigned to a 'session' variable that does not exist in launchSession, so it was throwing into a catch and capturing nothing; it is now stashed on the page object.

Put the owning AI thread ABOVE the taskbar hover-preview, where John was actually looking. The header Windows draws above the preview IS the window title (Chrome derives it from document.title), so the tooltip work in 1.9.101 was real but invisible there. The thread tag now LEADS the title — 'adom-tsci · Example Domain (session: x)' — so it survives the ~25-30 char truncation in that header and answers 'which of my 20 threads made this window' at a glance. Implemented WITHOUT adding a third title mutator: the code already documents that two observers writing the same region ping-pong forever, peg the renderer and flood CDP (which hung browser_open_tab on Edge), so the wiki glyph and the new thread tag are now ONE composed prefix slot under ONE observer, applied in a fixed order, and stripping only ever removes decorations we know we wrote (never a page title that merely contains a middot). Tag capped at 18 chars; re-asserted after navigation.

Fix the owning-thread stamp missing on the window that matters most. The v1.9.101 stamp ran at dispatch and could only find a session that ALREADY existed — but on browser_open_window the session is created inside the handler, so the window a thread had just created got no identity and its hover tooltip read '(no AI-thread identity yet)'. The owner is now stamped as soon as the session is real, so a freshly opened pup window immediately shows 'adom-tsci · galliaApril' on its taskbar preview.

Surface the owning AI thread on the taskbar hover preview (John's ask). pup was DISCARDING the caller identity AD stamps on every relayed bridge request (X-Adom-Caller-Thread / X-Adom-Caller-Container); it now captures both, stamps the FIRST thread to touch a session as that window's owner, tracks lastDrivenBy so a handoff stays visible, and LEADS the thumbnail tooltip with 'thread · container'. With ~20 threads running at once a pup window is effectively an AI thread, so this turns an anonymous Chrome preview into 'that's my adom-tsci thread'. The tooltip is the only UNCAPPED text surface on the preview (the header above the thumbnail is the window title and truncates ~25-30 chars). Also fixes a line that has been wrong since native-first: the tooltip claimed 'Chrome for Testing' unconditionally and now reports the browser actually driving the window, plus the sessionId.

Make pup insist the AI LOOKS at what it just rendered (John's ask). browser_open_window / browser_open_tab / browser_navigate / browser_reload now return a _verifyRender instruction: the exact browser_screenshot command, a concrete checklist of what to look for (blank/white page, unstyled flash of plain HTML meaning CSS never loaded, a stack trace or framework error overlay, missing images, broken or overlapping layout, content cut off, a dev-server 'Cannot GET /', or the wrong build), and the ralph-test loop — fix the source, reload, screenshot AGAIN until the render is genuinely correct. The framing that matters: ok:true means the NAVIGATION worked and says NOTHING about whether the page painted. Wording escalates when the URL looks like the caller's own work in progress (localhost, LAN IP, file://, .adom.cloud, .local; classifier unit-tested 7/7), which is the lazy-AI case John described. Success responses only; never overwrites a handler that already spoke about verification. Also teaches ship.sh AD 1.9.180's caller-identity contract (ADOM_AI_THREAD + per-call reason on gated verbs).

Make pup insist the AI LOOKS at what it just rendered (John's ask). The common failure: an AI generates or edits an app, opens it in pup, sees ok:true, and reports success to the user without ever screenshotting the result — but ok:true only means the NAVIGATION worked, it says nothing about whether the page painted, whether CSS loaded, or whether a stack trace is filling the viewport. browser_open_window / browser_open_tab / browser_navigate / browser_reload now return a _verifyRender instruction with the exact browser_screenshot command, a concrete checklist of what to look for (blank page, unstyled HTML, error overlay, missing images, broken layout, Cannot GET, wrong build), and the ralph-test loop: fix, reload, screenshot AGAIN until the render is genuinely correct. Wording escalates when the URL looks like the caller's own work in progress (localhost, a LAN IP, file://, .adom.cloud, .local — classifier unit-tested 7/7), which is exactly the case John described. Success responses only; never overwrites a handler that already spoke about verification.