# 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?

---
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 pup_* 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 — every pup window shares ONE durable profile (v1.9.162), so once the user signs into the wiki once it stays logged in everywhere; wikiView:"public" is the explicit logged-OUT view for publish-visibility checks. 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:** pup-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-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?
```

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 `pup_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.

## Two views: LOGGED-IN (default, shared profile) and PUBLIC (explicit `wikiView:"public"`) — show BOTH to verify visibility

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

- **Logged-in (the DEFAULT now, v1.9.162):** a plain `pup_open_window {url:"https://wiki.adom.inc/..."}`
  opens in the ONE shared `adom-you` profile — the same jar every other pup window uses — so once
  the user has signed into the wiki once, EVERY wiki window (and every other pup window) is already
  logged in. `wikiView:"authed"` is now just the explicit name for this default.
- **Public / anonymous (EXPLICIT):** `pup_open_window {url:"...", wikiView:"public"}` — this is
  the ONLY wiki view that gets a separate jar: a fresh logged-OUT isolated profile, because showing
  "what the world sees" requires being logged out. It does NOT accumulate anything and is only for
  a deliberate publish-visibility check.

**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, then it accumulates.** If the shared profile has not been signed into the wiki
yet, an authed open comes back `wikiLoginNeeded:true`. Sign in once: `pup_raise_os_window` with
a `foregroundReason` like `"sign into the Adom wiki"`, the user completes the hydrogen.adom.inc SSO,
and the session now lives in the ONE shared `adom-you` jar (v1.9.162) — so it is logged in for every
pup window from then on, not just wiki ones. Tell the user it is a one-time login.
(Container-identity auto-login — zero interactive step — is still tracked in `adom/wiki` #89.)

**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.