Pup - the AI's own browser

@@ -409,7 +409,10 @@ threads; pass `wikiView:"authed"|"public"` on pup_open_window instead. Details:   identity). Never navigate/close a window you don't own. - **One window, many tabs** — use `pup_open_tab`, not a second `pup_open_window`, for multi-URL work. - **`pup_readiness`** (not `pup_status`) answers "is it ready / which browser?".-- **No semicolons in `pup_eval`** — use the comma operator or an IIFE.+- **`pup_eval` accepts statement lists since v2.0.274** (`location.assign('...'); 'done'` works: a+  syntax error in the expression form retries via Runtime.evaluate with devtools-console semantics,+  and a genuinely bad expression now FAILS with `eval_failed` instead of ok-wrapping the error).+  The comma-operator/IIFE habit still produces the cleanest single-expression results. - **Complex page fighting you?** (a `querySelectorAll` comes back empty, or a screenshot overshoots the   target) — it's usually shadow DOM or a nested scroll container. Verify by DOM, scroll the *element* not   the window, count before you eyeball. See `pup-screenshots-recording` → "Driving & verifying tricky pages."

@@ -23,9 +23,9 @@ download card is correct. This skill is the wiki-specific playbook.  ```bash # Verify a page you just published (own the window, task-prefix the id):-adom-bridge-cli pup_open_window '{"sessionId":"wiki-mypage","owner":"mypage","url":"https://wiki.adom.inc/adom/my-slug?v=1.2.3"}'-adom-bridge-cli pup_eval        '{"sessionId":"wiki-mypage","expr":"document.title"}'   # confirm it loaded-adom-bridge-cli pup_screenshot  '{"sessionId":"wiki-mypage"}'                            # read it — did the hero/version render?+adom-bridge-cli --ai-thread "<your thread>" pup_open_window '{"sessionId":"wiki-mypage","url":"https://wiki.adom.inc/adom/my-slug?v=1.2.3"}'+adom-bridge-cli --ai-thread "<your thread>" pup_eval        '{"sessionId":"wiki-mypage","expr":"document.title"}'   # confirm it loaded+adom-bridge-cli --ai-thread "<your thread>" pup_screenshot  '{"sessionId":"wiki-mypage"}'                            # read it — did the hero/version render? ```  Reuse **one** window per page (stable `sessionId` like `wiki-<slug>`) so re-publishes refresh the same@@ -83,20 +83,20 @@ the logged-in version," you can tell them to right-click the pup taskbar button logged-in view" (or just reopen with `wikiView:"authed"` yourself). This requires AD ≥1.9.139; on older AD the menu simply isn't there. -## Historical note — pup used to be logged-out only+## Historical note — pup WAS logged-out only (this is no longer true; see "Two views" above) -pup drives a **fresh, isolated browser** with no cookies, so it views the wiki **logged out** — it sees-only public content. There is currently **no supported way to auto-login pup as the container's identity**:-the wiki uses centralized Adom SSO (`hydrogen.adom.inc`), the container's token works only as an API-`Authorization: Bearer` header (not as a browser cookie), and there's no magic-link / token→session-endpoint. So:-- **Don't claim you can see logged-in-only features**, and don't offer to "log you in" today — you can't-  (and you must never drive the SSO form with the user's password).-- The clean fix — a one-time magic-link the container can mint from its own token — is **requested in-  `adom/wiki` discussion #89**. Once it ships, this skill gains an "offer + do auto-login" flow: when a-  task clearly needs logged-in features, pup can say *"I can log you into the wiki automatically — want-  me to?"* and do it with zero credentials. Until then, if a task needs a signed-in view, tell the user-  they'd need to log in themselves.+This section is kept as history only, because its old present-tense wording ("don't claim you can+see logged-in features, you can't") sat directly under a section saying logged-in is the DEFAULT,+and a skim could believe either one. The current truth is the "Two views" section: since v1.9.162+the shared adom-you profile carries the wiki session, so an authed view is the default and a+one-time interactive sign-in unlocks it for every window.++What used to be true: pup opened a fresh isolated browser per window, no cookies, so every wiki+view was anonymous, and there was no supported container-identity auto-login (the container's+Bearer token is an API credential, not a browser cookie). The rule that DOES survive from that era:+**never drive the SSO form with the user's password** — the one-time login is the user's own+interactive step via `pup_raise_os_window`. Zero-step container-identity auto-login (a magic link+minted from the container token) remains tracked in `adom/wiki` discussion #89.  ## Common wiki-in-pup tasks