---
name: pup-adom-wiki
user-invocable: true
description: "Driving the Adom wiki (wiki.adom.inc) inside a pup window — the common case of loading, viewing, and VERIFYING wiki pages with the browser_* verbs. Use when the user says show me the wiki / open my wiki page in pup / verify my page rendered / check the hero/version/download card / does my published page look right. Covers: pup shows the RENDERED page (use the adom-wiki CLI for API tasks like publish/search/releases — NOT pup); wiki pages are component-heavy with nested scroll, so use the shadow-DOM-survey + scroll-the-element techniques; and the LOGIN situation — pup currently sees the wiki LOGGED OUT (auto-login from the container identity isn't supported yet; tracked in adom/wiki discussion #89), so don't claim logged-in-only content and offer auto-login only once that lands. Trigger words: adom wiki, wiki.adom.inc, show me the wiki, open the wiki in pup, open my wiki page, verify my wiki page, check my hero, wiki version chip, download card, wiki page rendered, is my page live, wiki login pup, log into the wiki."
---

**Parent skill:** adom-desktop-puppeteer-bridge  ·  See also: `pup` (start here), `pup-screenshots-recording` (the tricky-pages techniques), the `adom-wiki` skill (the CLI for API work).

# pup — driving the Adom wiki

Loading `wiki.adom.inc` pages into pup to **look at the rendered result** is one of pup's most common
jobs — confirming a page you just published looks right, a hero renders, a version chip updated, a
download card is correct. This skill is the wiki-specific playbook.

## pup VIEWS the rendered page; the `adom-wiki` CLI DOES the work

- **API / authoring tasks — use the `adom-wiki` CLI, not pup:** publishing pages, pushing files, cutting
  releases, `pkg` work, searching/discovery, discussions, breadcrumbs. These are authenticated Bearer-token
  operations the CLI already does; driving them through a browser form would be slower and fragile.
- **pup is for the rendered VIEW:** open the page, screenshot it, verify the hero/version/sections rendered,
  count cards, click through tabs. After any `adom-wiki` publish, showing the LIVE page in pup (cache-bust
  with `?v=<ver>`) is the standard "prove it shipped" step.

```bash
# Verify a page you just published (own the window, task-prefix the id):
adom-desktop browser_open_window '{"sessionId":"wiki-mypage","owner":"mypage","url":"https://wiki.adom.inc/adom/my-slug?v=1.2.3"}'
adom-desktop browser_eval        '{"sessionId":"wiki-mypage","expr":"document.title"}'   # confirm it loaded
adom-desktop browser_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
window instead of piling up tabs.

## Wiki pages are component-heavy — use the tricky-pages techniques

The wiki renders widgets (download cards, sample-prompt cards, the hero) and often puts content in a
**nested scroll container**. So the usual gotchas apply (full detail in `pup-screenshots-recording` →
"Driving & verifying tricky pages"):
- To find/count something (download cards, skills, files), **count in `browser_eval` by document-Y**
  (`rect.top + window.scrollY`), don't eyeball a screenshot that may have overshot.
- To screenshot a specific widget, **`el.scrollIntoView({block:'center'})`** — `window.scrollTo` does
  nothing on the wiki's inner scroll box.
- If a `querySelectorAll` comes back empty, first **survey for shadow roots** — most wiki widgets are
  plain DOM, so an empty result usually means the selector, not a shadow root.

## Login — pup sees the wiki LOGGED OUT (for now)

## Two views: PUBLIC (default) and LOGGED-IN (`wikiView:"authed"`) — and why you show BOTH

pup can now open a wiki page from **either viewpoint**, and the killer use is showing the user
**both** to verify publish visibility:

- **Public / anonymous (default):** `browser_open_window {sessionId, url:"https://wiki.adom.inc/..."}`
  — a fresh logged-out profile: exactly what the WORLD sees.
- **Logged-in:** `browser_open_window {sessionId, url:"...", wikiView:"authed"}` — routes to pup's
  reserved persistent authed-wiki profile whose cookie jar holds a 30-day SSO session.

**Use ONE window normally.** Don't open two windows for the same page — that double-reloads and
annoys. Just pick the view the task needs. The ONLY time to compare both is a deliberate
visibility check after a publish, and even then flip the SAME window between views rather than
opening two. Example John cares about: *"I published an app where the
public should get only the binaries but I keep the source private — did the AI accidentally leak
the source?"* The public view answers that directly (if you can see `src/` there, it leaked). The
response `_hint` tells you which view you opened and nudges you to open the other.

**One-time login for the authed view.** The first `wikiView:"authed"` open (or after the ~30-day
session expires) comes back with `wikiLoginNeeded:true`. To sign in: `browser_raise_os_window`
with a `foregroundReason` like `"sign into the Adom wiki"` so the user completes the
hydrogen.adom.inc SSO once; the session then persists in the authed profile and every later
`wikiView:"authed"` open is logged in automatically. Tell the user it is a one-time login.
(Container-identity auto-login — no interactive step — is still tracked in `adom/wiki` #89; when it
lands, this becomes zero-touch.)

**The user can flip the view themselves (v1.9.3).** Every wiki pup window carries a **taskbar
right-click menu** task — "🔓 Switch to logged-in view" on a public window, "📖 Switch to public
view" on an authed one. Clicking it relaunches THAT window under the other cookie jar and brings it
on-screen (no thread involvement — it's a pure user affordance). So if the user asks "how do I see
the logged-in version," you can tell them to right-click the pup taskbar button and pick "Switch to
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

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.

## Common wiki-in-pup tasks

- **"Show me my page in pup"** → open `https://wiki.adom.inc/<type>/<slug>?v=<ver>`, screenshot, hand over
  the link. (For the user's own machine, respect the background-by-default rule unless they said "show me.")
- **Verify a publish** → open the page, confirm the version chip + hero + your changed section rendered
  (read the screenshot; a curl 200 is NOT verification).
- **Count/verify a widget** (download cards, skills, files) → DOM-count by document-Y, then scroll the
  element in + screenshot to confirm.