# Verify a page you just published (own the window, task-prefix the id):
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?

---
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 --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
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"}` — the
  SERVER renders the page exactly as a signed-out visitor sees it, via the `?view=public` URL
  param (adom/wiki#126: the request's user is nulled for that one render, the response is
  byte-identical to a logged-out visitor's, and private pages 404). The window STAYS on the
  shared profile with the session untouched — no isolated jar, no relaunch. Only for a
  deliberate publish-visibility check. (Pre-2.0.132 this minted a throwaway logged-out
  profile; the param replaced that entirely.)

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

**Switching views.** To show the user the other view of a wiki page, reopen or navigate the window
with `wikiView:"authed"` or `wikiView:"public"` yourself. (The Windows line has a taskbar right-click
task for this; macOS has no taskbar menu, so on a Mac the AI does it.)

## Historical note — pup WAS logged-out only (this is no longer true; see "Two views" above)

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

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