Adom Hydrogen (platform base)

@@ -1,51 +1,51 @@ --- name: hydrogen-adom-auth description: >-  Adom auth in HD — how login/logout works (auth intent flow), where the+  Adom auth in Hydrogen — how login/logout works (auth intent flow), where the   session token lives, the profile menu, and how the Adom session feeds the   setup steps. For Claude Code auth specifically, see hydrogen-claude-auth.   READ when troubleshooting Adom login failures, session token expiry, the   profile dropdown, or virgin-reset Adom-auth options. Trigger words —   adom login, login, logout, auth, session token, auth intent, confirmation   code, profile menu, avatar, sign in, sign out, auth proxy, clear session,-  HD adom login, Your profile, Your repositories.+  Hydrogen adom login, Your profile, Your repositories. ---  # Hydrogen -- Authentication Reference  ## Auth Flow Overview -HD uses an **auth intent** flow (no email/password entry in the app).+Hydrogen uses an **auth intent** flow (no email/password entry in the app). The backend creates a short-lived intent token on the Carbon API, opens the user's default browser to the Adom login page, and polls until the user completes sign-in in the browser.  ### Sequence -1. HD calls `invoke('auth_intent_start')` -> backend POSTs to+1. Hydrogen calls `invoke('auth_intent_start')` -> backend POSTs to    `https://carbon.adom.inc/auth/intents` with `{"max_age": 7776000}`    (90-day session). 2. Carbon returns `{token, confirmation_code, expires_at, auth_url}`.-3. HD opens the browser to the **`auth_url` Carbon returned**, falling back to+3. Hydrogen opens the browser to the **`auth_url` Carbon returned**, falling back to    `https://hydrogen.adom.inc/auth/intent?token={token}` (singular `intent`,    token as a query param — NOT `/auth/intents/{token}`).-4. HD displays the confirmation code on screen and shows a spinner.+4. Hydrogen displays the confirmation code on screen and shows a spinner. 5. Frontend polls `invoke('auth_intent_poll', {token})` every 2 seconds.    Backend GETs `https://carbon.adom.inc/auth/intents/{token}/status`. 6. When the user confirms in the browser, the response includes    `{state: "authenticated", session_token: "..."}`.-7. The backend saves the session token to HD's app-data directory on the host+7. The backend saves the session token to Hydrogen's app-data directory on the host    (the `hydrogen-session.txt` file) and a replay copy alongside it. 8. Frontend redirects to the dashboard.  ### Source files  - **Login page**: `src/routes/auth/login/+page.svelte`-- **Auth backend**: `src-tauri/crates/hd-app/src/lib.rs` (functions+- **Auth backend**: `src-tauri/crates/hydrogen-app/src/lib.rs` (functions   `auth_intent_start`, `auth_intent_poll`, `auth_proxy`,   `check_replay_credentials`, `replay_adom_login`). NOTE: the old   `src-tauri/src/lib.rs` is a pre-crate-split vestige — the live code is in the-  `hd-app` crate.+  `hydrogen-app` crate. - **Auth components**: `src/lib/components/auth/` (Header, Form, Footer,   SubmitButton, Error, Success) - **User API**: `src/lib/api/authenticated_user.ts`@@ -54,7 +54,7 @@ the user completes sign-in in the browser.  ## Session Token -**Location**: HD's app-data directory on the host (the `hydrogen-session.txt`+**Location**: Hydrogen's app-data directory on the host (the `hydrogen-session.txt` file).  A plain-text file containing the Adom session cookie value. Created by either:@@ -114,16 +114,16 @@ const result = await invoke('auth_proxy', {  ## Credential Replay -On login page mount, HD checks for saved credentials before starting the+On login page mount, Hydrogen checks for saved credentials before starting the full auth intent flow:  1. `invoke('check_replay_credentials')` checks if replay files exist on disk.-2. If the replay-session file exists (has_adom = true), HD shows a "REPLAY"+2. If the replay-session file exists (has_adom = true), Hydrogen shows a "REPLAY"    badge and a 5-second countdown. 3. `invoke('replay_adom_login')` attempts to authenticate using the saved    session token. 4. If replay succeeds, the user is logged in without opening a browser.-5. If replay fails, HD falls back to the normal auth intent flow.+5. If replay fails, Hydrogen falls back to the normal auth intent flow.  This makes re-login after a virgin reset instant when the user chose to preserve the Adom session token.@@ -132,7 +132,7 @@ preserve the Adom session token.  ## Claude Credentials -**Location**: HD's app-data directory on the host (the+**Location**: Hydrogen's app-data directory on the host (the `replay-claude-credentials.json` file).  Stores Claude Code OAuth credentials so they can be replayed into the@@ -234,7 +234,7 @@ avatar ? avatar.alt : 'unknown'; 3. If confirmed (app mode):    - `invoke('auth_proxy', {path: '/auth/logout', method: 'DELETE'})` -- server-side logout    - `invoke('auth_proxy', {path: '/auth/clear-local', method: 'POST'})` -- deletes `hydrogen-session.txt`-   - Clears auth-related domain preferences from `localStorage['hd-url-routing-prefs']`+   - Clears auth-related domain preferences from `localStorage['hydrogen-url-routing-prefs']` 4. Redirects to `/auth/login`.  ---@@ -293,7 +293,7 @@ document.querySelector('.skip-login a')?.click();  The setup/bootstrap process depends on a valid session token: -1. **inject-api-key** -- reads the HD-side `hydrogen-session.txt`, writes the+1. **inject-api-key** -- reads the Hydrogen-side `hydrogen-session.txt`, writes the    token into the workspace at `/var/run/adom/api-key` (mode 644) as the Adom    API key. If the token is missing or expired, this step fails and downstream    steps (adom-cli, gallia, etc.) cannot authenticate.

@@ -1,36 +1,36 @@ --- name: hydrogen-adom-desktop description: >-  What Hydrogen (HD) and Adom Bridge (AD) are, what each does, and how+  What Hydrogen (ah) and Adom Bridge (ab) are, what each does, and how   they work together — so the AI in the workspace knows it has HANDS on the-  user's real operating system. HD is the workspace app the user looks at; AD is+  user's real operating system. Hydrogen is the workspace app the user looks at; ab is   the bridge that reaches the user's actual machine to create files & folders,   run shell commands, take OS screenshots, launch apps, open browsers (Pup /-  native), and drive KiCad / Fusion 360. HD bundles AD during install and runs-  it in embedded mode, but AD is a standalone product that ALSO connects Adom-  cloud containers to a user's machine. HD also has a BUILT-IN desktop bridge of-  its own that serves a subset of AD's verbs.+  native), and drive KiCad / Fusion 360. Hydrogen bundles ab during install and runs+  it in embedded mode, but ab is a standalone product that ALSO connects Adom+  cloud containers to a user's machine. Hydrogen also has a BUILT-IN desktop bridge of+  its own that serves a subset of ab's verbs.   READ THIS to understand your reach beyond the workspace and how to invoke it.-  Trigger words — adom desktop, AD, ad cli, what can you do on my computer, reach+  Trigger words — adom desktop, ab, ad cli, what can you do on my computer, reach   my machine, create a file on my pc, make a folder on my desktop, run a command   on my machine, control the host, host screenshot, screenshot my screen, os   screenshot, open a file on my computer, control my desktop, bridge to my pc,   send file to my desktop, pull file from my desktop, hd and ad, two apps, how   do hd and ad work together, talk to hydrogen, desktop bridge, relay,-  embedded mode, AD hidden, hd_status, hd_api, shell_execute, adom-bridge-cli ping,+  embedded mode, ab hidden, hd_status, hd_api, shell_execute, adom-bridge-cli ping,   adom-bridge-cli status. ---  # Hydrogen ↔ Adom Bridge — your reach onto the user's real machine -You (the AI) run inside the **HD workspace** (a local Linux workspace on the-user's machine). That's a sandbox. **Adom Bridge (AD) is how you reach OUT of it+You (the AI) run inside the **Hydrogen workspace** (a local Linux workspace on the+user's machine). That's a sandbox. **Adom Bridge (ab) is how you reach OUT of it onto the user's actual operating system** — their real files, shell, screen, and-desktop apps. Knowing AD exists is the difference between "I can only work in+desktop apps. Knowing ab exists is the difference between "I can only work in here" and "I can create that file on your Desktop, screenshot your screen, and open it in KiCad." -> **Platform note:** HD's host layer (file/shell/screenshot/notification/window+> **Platform note:** Hydrogen's host layer (file/shell/screenshot/notification/window > control) is platform-specific. Before promising a host action on a given OS, > verify the capability with `adom-bridge-cli status` rather than assuming it. > For Windows/WSL2-specific host behavior, see the [[hydrogen-adom-desktop-windows]]@@ -38,36 +38,36 @@ open it in KiCad."  ## Two apps, two jobs -| | **Hydrogen (HD)** | **Adom Bridge (AD)** |+| | **Hydrogen (ah)** | **Adom Bridge (ab)** | |---|---|---| | What it is | The user-facing workspace app (Tauri). VS Code pane + Wiki + the runtime that hosts your workspace. | A bridge app that talks to the user's real OS and local apps. |-| What the user sees | The window they work in. | Usually nothing — HD hides it (embedded mode). |+| What the user sees | The window they work in. | Usually nothing — Hydrogen hides it (embedded mode). | | What it does for YOU | Hosts you, your editor, your tools. | Lets you act on the host: files, folders, shell, OS screenshots, app launch, KiCad/Fusion, browsers. |-| Runs without the other? | HD spawns AD. | **Yes** — AD is a standalone product; it also connects Adom *cloud* containers to a user's machine. |+| Runs without the other? | Hydrogen spawns ab. | **Yes** — ab is a standalone product; it also connects Adom *cloud* containers to a user's machine. | -**Why two apps:** AD came first and is genuinely powerful — it's what lets any-Adom cloud container reach into a user's desktop. Rather than reinvent it, HD-**bundles AD and makes it part of HD's install**, then puts it in *embedded mode*-so the user only ever manages one app (HD). The two talk to each other-constantly. See [hd-embedded-ad](../hd-embedded-ad/SKILL.md) for the embedding+**Why two apps:** ab came first and is genuinely powerful — it's what lets any+Adom cloud container reach into a user's desktop. Rather than reinvent it, Hydrogen+**bundles ab and makes it part of Hydrogen's install**, then puts it in *embedded mode*+so the user only ever manages one app (ah). The two talk to each other+constantly. See [hydrogen-embedded-ad](../hydrogen-embedded-ad/SKILL.md) for the embedding mechanics (tray ownership, lifecycle, standalone↔embedded transitions). -## HD's built-in bridge vs the embedded AD (dual-client)+## Hydrogen's built-in bridge vs the embedded ab (dual-client)  Here's the subtlety that matters when you reason about "who serves this verb?": **there are two desktop clients on the host, not one.** -1. **HD's own built-in bridge** — HD's `hd-app` crate implements a desktop bridge+1. **Hydrogen's own built-in bridge** — Hydrogen's `hydrogen-app` crate implements a desktop bridge    *itself* (`commands.rs::handle_command` → `screenshot.rs::handle_desktop_command`).-   It serves a **subset** of AD's verbs directly inside HD's process:+   It serves a **subset** of ab's verbs directly inside Hydrogen's process:    `list_windows, screenshot_window, screenshot_screen, open_folder, open_url,    bring_to_front, set_window_state, list_files, watch_files, install_kicad,    install_node, list_browsers` under the `desktop` app, plus the top-level apps    `caption, notify, shell, kicad, fusion360, browser` and the desktop verbs    `set_project_watch, trigger_project_watch, revoke_approvals`.-2. **The standalone AD, spawned `--embedded`** by HD's supervisor-   (`ad_supervisor.rs`). AD serves the **full** verb surface — including ones-   HD's built-in bridge does NOT implement:+2. **The standalone ab, spawned `--embedded`** by Hydrogen's supervisor+   (`ad_supervisor.rs`). ab serves the **full** verb surface — including ones+   Hydrogen's built-in bridge does NOT implement:    `desktop_record_*`, `desktop_recorder_*`, `desktop_list_monitors`,    `desktop_pull_glob`, `desktop_embedded_*`. @@ -81,28 +81,28 @@ adom-bridge-cli status   # → .capabilities lists what the connected client(s) ```  If `.capabilities` is missing `record` (or `desktop_list_monitors` errors with-"unknown desktop command"), the embedded AD isn't connected — only HD's built-in-bridge is — so recording / multi-monitor / glob-pull aren't available until AD+"unknown desktop command"), the embedded ab isn't connected — only Hydrogen's built-in+bridge is — so recording / multi-monitor / glob-pull aren't available until ab is up. Screenshots, window control, files, shell, captions, notifications and-the KiCad/Fusion/browser bridges all work off HD's built-in bridge regardless.+the KiCad/Fusion/browser bridges all work off Hydrogen's built-in bridge regardless. -## What AD/HD let you do on the user's real machine+## What ab/Hydrogen let you do on the user's real machine  All via the `adom-bridge-cli` CLI from inside the workspace. Rather than re-document every verb here, this is a **capability map → the focused skill**:  | Capability | Verb(s) / surface | Where it's documented | |---|---|---|-| **Create files/folders on the host** | `send_files` (container → desktop) | [hd-file-transfer](../hd-file-transfer/SKILL.md) |-| **Pull files from the host** | `pull_file` (desktop → container, SHA256-verified); browse + watch via `list_files` / `watch_files` | [hd-file-transfer](../hd-file-transfer/SKILL.md) |+| **Create files/folders on the host** | `send_files` (container → desktop) | [hydrogen-file-transfer](../hydrogen-file-transfer/SKILL.md) |+| **Pull files from the host** | `pull_file` (desktop → container, SHA256-verified); browse + watch via `list_files` / `watch_files` | [hydrogen-file-transfer](../hydrogen-file-transfer/SKILL.md) | | **Run a shell command on the host** | `shell_execute` (real host shell) | shell-trust model below | | **Screen/window control + screenshots** | `desktop_screenshot_screen` / `desktop_screenshot_window` / `desktop_list_windows`, `desktop_set_window_state`, `desktop_bring_to_front` | [hydrogen-self-screenshot](../hydrogen-self-screenshot/SKILL.md) |-| **Record the screen / a tab** | `desktop_record_*` (whole screen), `browser_record_*` (one tab) | [hd-recording](../hd-recording/SKILL.md) — AD-served, verify `record` capability |+| **Record the screen / a tab** | `desktop_record_*` (whole screen), `browser_record_*` (one tab) | [hydrogen-recording](../hydrogen-recording/SKILL.md) — ab-served, verify `record` capability | | **Desktop notifications** | `notify_user` (title/body/level + action buttons) | [hydrogen-notifications](../hydrogen-notifications/SKILL.md) | | **On-screen captions** | `caption` (always-on-top click-through overlay) | [hydrogen-captions](../hydrogen-captions/SKILL.md) | | **Open browsers** | `browser_*` (Pup) and the Browser Picker | [hydrogen-open-url](../hydrogen-open-url/SKILL.md), `pup` | | **Drive KiCad / Fusion 360 / Pup** | `kicad_*`, `fusion_*`, `browser_*` | [hydrogen-bridges](../hydrogen-bridges/SKILL.md) |-| **Embedded mechanics (tray/lifecycle)** | `desktop_embedded_*` | [hd-embedded-ad](../hd-embedded-ad/SKILL.md) — AD-served |+| **Embedded mechanics (tray/lifecycle)** | `desktop_embedded_*` | [hydrogen-embedded-ad](../hydrogen-embedded-ad/SKILL.md) — ab-served |  For the complete verb list run `adom-bridge-cli list_commands` (or see the `adom-bridge-cli` skill).@@ -110,7 +110,7 @@ For the complete verb list run `adom-bridge-cli list_commands` (or see the ### Host shell-trust model  `shell_execute` runs a **real command on the user's machine** (the host's native-shell). In **embedded mode HD auto-approves** shell commands so the AI isn't+shell). In **embedded mode Hydrogen auto-approves** shell commands so the AI isn't blocked on per-command approval dialogs — convenient, but it means anything you run there really runs. Revoke the standing auto-approval at any time: @@ -119,7 +119,7 @@ adom-bridge-cli shell_auto_approve '{"duration_secs":0}'   # turn auto-approve o ```  When you *don't* need a free-form shell, prefer the **no-escape structured-runners** over hand-quoted `shell_execute` (AD ≥ 1.8.50):+runners** over hand-quoted `shell_execute` (ab ≥ 1.8.50): `adom-bridge-cli run_script '{"interpreter":"bash|cmd|powershell","scriptB64":"<b64>"}'` and `adom-bridge-cli wsl_exec '{"distro":"<workspace-distro>","user":"adom","scriptB64":"<b64>"}'` — base64 the script so no quoting survives to be mangled. (`wsl_exec` is a@@ -127,7 +127,7 @@ Windows/WSL2 path — see the [[hydrogen-adom-desktop-windows]] companion.)  ### Auto-installing missing apps -If KiCad or Node.js is missing on the host, HD can trigger an unattended+If KiCad or Node.js is missing on the host, Hydrogen can trigger an unattended install on platforms that support it (see the [[hydrogen-adom-desktop-windows]] companion for the Windows winget verbs). The triggers: `install_kicad` fires when `kicad_list_versions` returns `errorCode:"kicad_not_installed"`;@@ -143,7 +143,7 @@ between the workspace and the host. The watcher fires on changes to so edits you make in the workspace land on the user's machine (and vice-versa) without manual `send_files`/`pull_file` round-trips. -## Talking to HD + AD from the CLI+## Talking to Hydrogen + ab from the CLI  You reach the host through the **`adom-bridge-cli` CLI**, which relays your commands over a WebSocket to the desktop client(s).@@ -156,20 +156,20 @@ adom-bridge-cli send_files '{"filePaths":["/tmp/x"],"saveTo":"<host dir>"}' adom-bridge-cli desktop_list_windows ``` -**Hydrogen control (the HD app itself):**+**Hydrogen control (the Hydrogen app itself):** ```bash-adom-bridge-cli hd_status            # is HD running + composed runtime state-adom-bridge-cli hd_screenshot        # window-bounded HD shot (resize <1500px before reading!)-adom-bridge-cli hd_log               # tail HD's log-adom-bridge-cli hd_launch            # start HD detached-# Direct HD control API (HTTP, no shell-escaping pain):+adom-bridge-cli hd_status            # is Hydrogen running + composed runtime state+adom-bridge-cli hd_screenshot        # window-bounded Hydrogen shot (resize <1500px before reading!)+adom-bridge-cli hd_log               # tail Hydrogen's log+adom-bridge-cli hd_launch            # start Hydrogen detached+# Direct Hydrogen control API (HTTP, no shell-escaping pain): adom-bridge-cli hd_api '{"method":"POST","path":"/setup/run-all","body":{}}' adom-bridge-cli hd_api '{"method":"GET","path":"/health"}' ```-`hd_api` hits HD's **control API** on its discovered port (fallback **47084**).+`hd_api` hits Hydrogen's **control API** on its discovered port (fallback **47084**). See the [[hydrogen-adom-desktop-windows]] companion for the host port-discovery file. -**Embedded-mode introspection (AD-served):**+**Embedded-mode introspection (ab-served):** ```bash adom-bridge-cli desktop_embedded_status   # embedded=true/false, enteredVia=launch-flag|runtime-adopt ```@@ -180,12 +180,12 @@ adom-bridge-cli desktop_embedded_status   # embedded=true/false, enteredVia=laun You (AI in the workspace)   └─ adom-bridge-cli <verb> '<json>'        ← CLI in the workspace        └─ relay  (adom-bridge-cli serve: WS :8765 + HTTP :8766, started in the workspace)-            └─ WebSocket ──► HD's built-in bridge AND/OR the embedded AD on the user's machine+            └─ WebSocket ──► Hydrogen's built-in bridge AND/OR the embedded ab on the user's machine                  └─ acts on the OS / KiCad / Fusion / Chrome ``` -- In HD the relay is started for you by the **`start-relay`** setup step; HD's-  built-in bridge and the embedded AD both connect to it. The host-side clients+- In Hydrogen the relay is started for you by the **`start-relay`** setup step; Hydrogen's+  built-in bridge and the embedded ab both connect to it. The host-side clients   reach your in-workspace relay — the exact networking depends on the runtime   (see the `hydrogen-networking` skill, and the [[hydrogen-adom-desktop-windows]] companion   for the WSL2 loopback-forwarding details).@@ -201,12 +201,12 @@ You (AI in the workspace)  ## What NOT to do -- **Never kill the host AD process** — the host AD is your relay bridge;+- **Never kill the host ab process** — the host ab is your relay bridge;   killing it severs your control channel (you can't get it back from in here).   (Windows-specific `taskkill` warnings live in the   [[hydrogen-adom-desktop-windows]] companion.)-- **Never hardcode `:9001` as HD's control API.** `9001` is real — it's AD's-  liveness beacon that AD probes to detect HD — but HD's actual control API is+- **Never hardcode `:9001` as Hydrogen's control API.** `9001` is real — it's ab's+  liveness beacon that ab probes to detect Hydrogen — but Hydrogen's actual control API is   **47084** (use `hd_api`, which reads the discovered port). - **Don't broad-kill `node`** — VS Code Server runs as node; killing it kills the   whole workspace.@@ -217,18 +217,18 @@ You (AI in the workspace)  When the user asks for something that lives on their real computer — "save this to my Desktop", "what's on my screen", "open this in KiCad", "run this command on-my machine" — that's an **AD** job, and you can do it. When it's about the+my machine" — that's an **ab** job, and you can do it. When it's about the workspace itself (editor, files under `/home/adom/project`, the runtime), that's-**HD**. Lead with what you can do, verify with `adom-bridge-cli ping`, then act.+**Hydrogen**. Lead with what you can do, verify with `adom-bridge-cli ping`, then act.  ## Related skills - [[hydrogen-adom-desktop-windows]] — Windows/WSL2 host specifics (paths, winget installs, loopback forwarding, taskkill)-- [hd-embedded-ad](../hd-embedded-ad/SKILL.md) — how HD bundles + embeds AD (tray, lifecycle, standalone↔embedded)+- [hydrogen-embedded-ad](../hydrogen-embedded-ad/SKILL.md) — how Hydrogen bundles + embeds ab (tray, lifecycle, standalone↔embedded) - [hydrogen-bridges](../hydrogen-bridges/SKILL.md) — the KiCad / Fusion / Puppeteer bridge ecosystem-- [hd-file-transfer](../hd-file-transfer/SKILL.md) — send/pull files, browse + watch the host filesystem+- [hydrogen-file-transfer](../hydrogen-file-transfer/SKILL.md) — send/pull files, browse + watch the host filesystem - [hydrogen-self-screenshot](../hydrogen-self-screenshot/SKILL.md) — host screenshots + window control-- [hd-recording](../hd-recording/SKILL.md) — screen vs tab recording (AD-served)+- [hydrogen-recording](../hydrogen-recording/SKILL.md) — screen vs tab recording (ab-served) - [hydrogen-notifications](../hydrogen-notifications/SKILL.md) — desktop toasts; [hydrogen-captions](../hydrogen-captions/SKILL.md) — on-screen caption overlay - [hydrogen-open-url](../hydrogen-open-url/SKILL.md) — the ways to open a URL (Pup, native browser, picker, …) - `pup` — driving Pup browser windows; `adom-bridge-cli` — the full CLI verb reference-- [hd-runtime-mode](../hd-runtime-mode/SKILL.md) — the HD↔AD relationship is identical across runtimes+- [hydrogen-runtime-mode](../hydrogen-runtime-mode/SKILL.md) — the Hydrogen↔ab relationship is identical across runtimes

@@ -3,18 +3,18 @@ name: hydrogen-api description: >   Complete reference for Hydrogen control API endpoints. The control   API runs on a dynamic port (find it via port discovery). Use these endpoints-  to drive HD programmatically: manage the workspace runtime, control Claude+  to drive Hydrogen programmatically: manage the workspace runtime, control Claude   Code, manipulate VS Code, manage workspace tabs, run setup steps, trigger   virgin reset, and more. ~159 endpoints. Two self-documenting sources of truth   list them live: GET /_manifest (curated grouped list) and GET /test/help   (the /test/* diagnostics).-  Trigger words: HD API, control API, HD endpoint, container exec, claude api,+  Trigger words: Hydrogen API, control API, Hydrogen endpoint, container exec, claude api,   iframe eval, workspace tabs, setup run-all, runtime status, reload vscode,   browser profiles, open url, virgin reset api, diagnostics, ad health,   test window-tree, ai cursor, setup panel, screenshot mode. --- -# HD Control API Reference+# Hydrogen Control API Reference  The control API exposes **~159 endpoints**. Don't trust a static count or list in this file to stay exhaustive — the API is **self-documenting**, with two live@@ -26,7 +26,7 @@ sources of truth you should hit first: | `GET /test/help` | Lists the `/test/*` diagnostics (window enumeration, UIA click, dialog classification, cascade reset). Gated behind `HD_TEST_API_ENABLED=1`. | `lib.rs:9723` |  **Base URL:** `http://127.0.0.1:<dynamic>` — the loopback address. The port is-dynamic per launch; read the live URL from `~/.adom/hd-control-url` — see+dynamic per launch; read the live URL from `~/.adom/hydrogen-control-url` — see "Finding the Control Port" below.  ## Finding the Control Port@@ -34,21 +34,21 @@ dynamic per launch; read the live URL from `~/.adom/hd-control-url` — see The control API port is dynamic (default 47084, auto-resolves conflicts).  ```bash-# From HD log+# From Hydrogen log adom-bridge-cli hd_log '{"tail":100}' | grep "control=" -# From inside the workspace — USE THIS. HD writes its live control URL to a discovery+# From inside the workspace — USE THIS. Hydrogen writes its live control URL to a discovery # file every launch, so you never hunt for the dynamic port:-CTRL="$(cat ~/.adom/hd-control-url)"; curl -sf "$CTRL/health"+CTRL="$(cat ~/.adom/hydrogen-control-url)"; curl -sf "$CTRL/health" ``` -⭐ **From the workspace, read `~/.adom/hd-control-url`** (e.g. `http://127.0.0.1:<control>`) — a-file, NOT an env var (your non-interactive Bash shells don't source `.bashrc`/`profile.d`). HD+⭐ **From the workspace, read `~/.adom/hydrogen-control-url`** (e.g. `http://127.0.0.1:<control>`) — a+file, NOT an env var (your non-interactive Bash shells don't source `.bashrc`/`profile.d`). Hydrogen rewrites it with the live dynamic port every launch. This is the channel for the UI command bus, the live ports map, Claude control, etc. — distinct from `adom-cli` (`ADOM_HYDROGEN_URL` → SSE), which is unchanged for web-hydrogen parity. -> For the host-side ways to discover the port (HD log/`ports.json`) and the+> For the host-side ways to discover the port (Hydrogen log/`ports.json`) and the > host runtime endpoints (`/wsl/*`, `/docker/*`, `/system/reboot`), see the > [[hydrogen-api-windows]] companion skill. @@ -56,36 +56,36 @@ which is unchanged for web-hydrogen parity.  | Method | Path | Description | |---|---|---|-| GET | `/health` | HD alive check — returns `{ok, port, service}` |+| GET | `/health` | Hydrogen alive check — returns `{ok, port, service}` | | GET | `/buildinfo` | Running build git SHA + build metadata (the only trustworthy "did my build ship?" check) | | GET | `/ports` | The 4 editable PortConfig ports (proxy, control, cdp, code_server) |-| GET | `/ports/all` | LIVE full port map — every port HD has bound, with status info |+| GET | `/ports/all` | LIVE full port map — every port Hydrogen has bound, with status info | -## AD-health diagnostics (`/ad/*`)+## ab-health diagnostics (`/ad/*`) -These verify the **adom-bridge-cli / relay / embedded-AD** half of HD is alive (the-bridge that connects this cloud container to HD). All GET, all return `{ok, ...}`.+These verify the **adom-bridge-cli / relay / embedded-ab** half of Hydrogen is alive (the+bridge that connects this cloud container to Hydrogen). All GET, all return `{ok, ...}`.  | Method | Path | Description | |---|---|---|-| GET | `/ad/health` | Overall embedded-AD health roll-up |+| GET | `/ad/health` | Overall embedded-ab health roll-up | | GET | `/ad/process` | Is the adom-bridge-cli process running |-| GET | `/ad/embedded` | Embedded-AD module status |+| GET | `/ad/embedded` | Embedded-ab module status | | GET | `/ad/workspace-direct` | ⭐ The **converged** check — direct path to the workspace relay (use this one) | | GET | `/ad/relay` | Relay (WS/HTTP) reachability | | GET | `/ad/liveness-beacon` | Liveness beacon freshness | | GET | `/ad/direct-api` | Direct-API reachability | | GET | `/ad/discovery-file` | Discovery file present + parseable | -## Driving HD's UI (command bus)+## Driving Hydrogen's UI (command bus) -Open/close/toggle any HD menu, dialog, or panel — the first-class alternative to CDP clicking. See the `hydrogen-ui` skill.+Open/close/toggle any Hydrogen menu, dialog, or panel — the first-class alternative to CDP clicking. See the `hydrogen-ui` skill.  | Method | Path | Body | Description | |---|---|---|---| | GET | `/ui/actions` | — | List every drivable UI action `{id,label,description,group}` (+ `_hints`) | | POST | `/ui/invoke` | `{"id":"ports.open"}` | Run a UI action; returns `{ok,value}` only after the frontend ran it |-| GET | `/auth-token` | HD session token |+| GET | `/auth-token` | Hydrogen session token | | GET | `/setup-status` | Overall setup completion state | | GET | `/diagnostics/all` | Run all diagnostic checks | | GET | `/diagnostics/{name}` | Run a single diagnostic check |@@ -120,7 +120,7 @@ These endpoints manage the active workspace runtime.  | Method | Path | Body | Description | |---|---|---|---|-| POST | `/eval` | `{"js":"..."}` | JS eval in main HD webview |+| POST | `/eval` | `{"js":"..."}` | JS eval in main Hydrogen webview | | POST | `/iframe-eval` | `{"js":"...","contextIndex":N}` | JS eval in a specific iframe context (0-14) | | POST | `/cdp-eval` | `{"expression":"..."}` | Direct Chrome DevTools Protocol eval | | POST | `/click` | `{"x":N,"y":N}` | Click at coordinates in webview |@@ -147,7 +147,7 @@ glides it, and can click. Use for demos or when the user should see where the AI  | Method | Path | Body | Description | |---|---|---|---|-| GET | `/capture/viewport` | — | Capture the HD webview viewport (PNG) |+| GET | `/capture/viewport` | — | Capture the Hydrogen webview viewport (PNG) | | POST | `/shot` | `{...}` | Screenshot primitive (see **hydrogen-self-screenshot** for the full workflow) |  ### Port hints@@ -229,12 +229,12 @@ glides it, and can click. Use for demos or when the user should see where the AI | POST | `/setup/countdown` | `{"seconds":N,"message":"..."}` | Show countdown overlay | | GET | `/setup/trigger` | — | Read trigger file | | DELETE | `/setup/trigger` | — | Delete trigger file |-| POST | `/config-reset` | — | Reset HD config |+| POST | `/config-reset` | — | Reset Hydrogen config |  > ⛔ **REFUSED as deprecated** (headless runs with no visible UI): > `POST /setup/run-all`, `POST /setup/run-step`, `POST /setup/virgin-reset`. > They return a refusal pointing at the UI-visible path.-> To run steps: use `POST /setup/step/<id>` or relaunch HD to auto-run the cascade.+> To run steps: use `POST /setup/step/<id>` or relaunch Hydrogen to auto-run the cascade.  ### Setup panel control @@ -263,9 +263,9 @@ glides it, and can click. Use for demos or when the user should see where the AI  | Method | Path | Body | Description | |---|---|---|---|-| POST | `/app/restart` | — | Restart the HD app (kills + respawns the binary) |-| POST | `/app/relaunch-frontend` | — | Relaunch the HD GUI (kill+respawn) while it is responsive |-| POST | `/window/foreground` | — | Bring the HD window to the foreground (unminimize + focus) |+| POST | `/app/restart` | — | Restart the Hydrogen app (kills + respawns the binary) |+| POST | `/app/relaunch-frontend` | — | Relaunch the Hydrogen GUI (kill+respawn) while it is responsive |+| POST | `/window/foreground` | — | Bring the Hydrogen window to the foreground (unminimize + focus) |  > Host OS reboot (`/system/*`) is platform-specific — see the > [[hydrogen-api-windows]] companion skill.@@ -280,12 +280,12 @@ disabled" otherwise). `GET /test/help` self-lists the whole cluster. |---|---|---|---| | GET | `/test/help` | — | Self-lists every `/test/*` endpoint | | GET | `/test/window-tree` | — | Enumerate all visible top-level windows |-| POST | `/test/focus` | `{"window":"..."}` | Focus HD (`self`) or a window by title substring |+| POST | `/test/focus` | `{"window":"..."}` | Focus Hydrogen (`self`) or a window by title substring | | POST | `/test/click-uia` | `{...}` | Poll UIAutomation for a Button by Name; Invoke when found | | GET | `/test/setup-steps` | — | Raw setup-steps.json + derived summary (alias: `/test/install-steps`) | | POST | `/test/dump-state` | `{...}` | Write a diagnostic bundle (logs, install-steps, runtime state, tasklist, window-tree) | | POST | `/test/reset-cascade` | — | Delete install-steps.json + emit setup-reset event |-| POST | `/test/screenshot-hd-window` | `{...}` | Capture HD's own window to a PNG file |+| POST | `/test/screenshot-hydrogen-window` | `{...}` | Capture Hydrogen's own window to a PNG file |  > The `/test/probe-dialogs` endpoint (classifies UAC / WSL2-update / MSI / > Docker-EULA blocker windows) is Windows-specific — see the

@@ -1,7 +1,7 @@ --- name: hydrogen-bridges description: >-  Complete reference for the HD bridge ecosystem: the built-in KiCad, Fusion 360,+  Complete reference for the Hydrogen bridge ecosystem: the built-in KiCad, Fusion 360,   and Puppeteer bridges, plus the extensible wiki bridge catalog (e.g. Blender)   and the full set of Adom Bridge capabilities. How they connect through adom-bridge-cli, the Bridge Manager   dialog, bridge status polling, and all bridge CLI commands. Use when the AI@@ -14,14 +14,14 @@ description: >  # Hydrogen -- Bridge Ecosystem -HD is the bridge between your Docker container and the user's Windows desktop.+Hydrogen is the bridge between your Docker container and the user's Windows desktop. All commands go through the relay at ws://localhost:8765/.  ---  ## Bridge Architecture -HD launches external bridge processes **on demand**. This is an **extensible**+Hydrogen launches external bridge processes **on demand**. This is an **extensible** ecosystem, not a fixed list — new bridges ship via the wiki catalog (see "Extensible bridge catalog" below). The core/first-party bridges: @@ -33,12 +33,12 @@ ecosystem, not a fixed list — new bridges ship via the wiki catalog (see  **Bridge ports have conventional defaults** (KiCad **8771**, Fusion **8773**, Pup **8851**), but adom-bridge-cli registers the **live** port at bridge launch and may pick a different one if a default is taken. To find the actual live port, run `adom-bridge-cli status` and look at `desktop.apps.<bridge>.bridgePort` (or `adom-bridge-cli bridge_list`). In practice you don't need the port directly — use the `adom-bridge-cli <verb>` CLI which routes to the right bridge automatically. -Bridges are launched on demand by HD. They are NOT always running. The Bridge+Bridges are launched on demand by Hydrogen. They are NOT always running. The Bridge Manager polls status every 15 seconds via Tauri `invoke('get_bridge_status')`.  ### What Adom Bridge can do (live capability list) -Bridges are only part of AD. Query the **authoritative, machine-specific** list:+Bridges are only part of ab. Query the **authoritative, machine-specific** list:  ```bash adom-bridge-cli status   # → .capabilities  and  .desktop.apps@@ -52,7 +52,7 @@ Mapping to where each is documented: |---|---|---| | `kicad` / `fusion360` / `browser` | the three built-in app bridges | this skill | | `screenshot` / `record` / `caption` | OS screenshots, screen/tab recording, recording captions | this skill (screenshots/recording); `caption` is recording-caption support |-| `files` | send_files / pull_file | **hd-file-transfer**, **hydrogen-adom-desktop** |+| `files` | send_files / pull_file | **hydrogen-file-transfer**, **hydrogen-adom-desktop** | | `notify` | desktop toast notifications | this skill | | `shell` | run a command on the user's PC (approval-gated) | **hydrogen-adom-desktop** | | `usb` | USB passthrough to the workspace (e.g. workcell hardware over USBIP) | not yet covered — query `adom-bridge-cli status`; future skill |@@ -99,7 +99,7 @@ each bridge's status. Auto-refreshes every 15 seconds. ### Features - Status badges with color-coded icons - Per-bridge install links when the target app is missing-- "Browse Bridge Catalog" button linking to the wiki (`/apps?tag=hd-bridge`)+- "Browse Bridge Catalog" button linking to the wiki (`/apps?tag=hydrogen-bridge`) - Polls `invoke('get_bridge_status')` on mount and every 15 seconds  > **App missing? You can auto-install it.** When the target app isn't installed,@@ -158,8 +158,8 @@ setTimeout(function() {  ## Prerequisites -Check connection: `adom-bridge-cli ping` -- returns "pong" if HD is connected.-If not connected, the user needs to launch HD on their Windows machine.+Check connection: `adom-bridge-cli ping` -- returns "pong" if Hydrogen is connected.+If not connected, the user needs to launch Hydrogen on their Windows machine.  --- @@ -279,10 +279,10 @@ bridge catalog** and installed on demand — for example the **Blender bridge** (`adom-blender-bridge`), which is NOT built in (it won't appear in `adom-bridge-cli status` until installed). To use a catalog bridge: -- **Discover:** Bridge Manager → "Browse Bridge Catalog" → wiki `/apps?tag=hd-bridge`.+- **Discover:** Bridge Manager → "Browse Bridge Catalog" → wiki `/apps?tag=hydrogen-bridge`. - **Reserved ports:** the `8900-8999` range is set aside for 3rd-party bridges. - **Enumerate what's actually live:** `adom-bridge-cli status` → `desktop.apps.*` lists-  every bridge AD currently knows about, with `bridgePort`, `status`, and whether+  every bridge ab currently knows about, with `bridgePort`, `status`, and whether   the target app was detected. **Treat that as the source of truth** for "what   bridges exist right now" — this skill's table lists the core ones, but new   catalog bridges will appear in `status` without being in this table.@@ -326,12 +326,12 @@ adom-bridge-cli shell_execute '{"command": "dir C:\\Github"}'  ## Screen Recording -> **Served by the embedded AD process, NOT HD's built-in bridge.** The+> **Served by the embedded ab process, NOT Hydrogen's built-in bridge.** The > `desktop_record_*` / `desktop_recorder_*` verbs only exist when the standalone-> AD (spawned `--embedded`) is connected. Verify before using:+> ab (spawned `--embedded`) is connected. Verify before using: > `adom-bridge-cli status` → `.capabilities` must include `record`. If it's absent,-> only HD's built-in bridge is up and these verbs return "unknown desktop-> command". See **hd-recording** for full details.+> only Hydrogen's built-in bridge is up and these verbs return "unknown desktop+> command". See **hydrogen-recording** for full details.  > **Tab-vs-desktop footgun.** `desktop_record_start` records the **whole screen** > and requires an explicit `confirmDesktopNotTabRecording:true` guard so you don't@@ -340,7 +340,7 @@ adom-bridge-cli shell_execute '{"command": "dir C:\\Github"}' > the Puppeteer bridge, no whole-screen capture).  ```bash-# Record entire desktop (AD-served; needs the confirm guard, zero dialogs)+# Record entire desktop (ab-served; needs the confirm guard, zero dialogs) adom-bridge-cli desktop_record_start '{"reason": "Demo recording", "confirmDesktopNotTabRecording": true}' adom-bridge-cli desktop_record_stop @@ -367,7 +367,7 @@ adom-bridge-cli desktop_screenshot_screen '{"maxWidth": 1500}'  ## Browser Profiles -HD can detect all browser profiles installed on the user's machine and open+Hydrogen can detect all browser profiles installed on the user's machine and open URLs in specific browsers/profiles.  **Control API endpoints**:@@ -384,7 +384,7 @@ URLs in specific browsers/profiles. - **hydrogen-ui** -- Adom menu layout where Bridge Manager lives - **hydrogen-networking** -- port architecture (conventional bridge ports + dynamic registration) - **hydrogen-adom-menu** -- the API Explorer (has bridge-related endpoints)-- **hydrogen-settings** -- HD settings surface+- **hydrogen-settings** -- Hydrogen settings surface - **hydrogen-self-screenshot** -- host screenshots, window control, and the ralph loop - **kicad-interaction** -- foundational KiCad desktop interaction rules - **pup** -- Puppeteer browser control via pup CLI

@@ -4,9 +4,9 @@ description: >   Paint labeled caption text on the Hydrogen workspace for demos/walkthroughs —   captions are CAPTURED BY RECORDINGS so they show up in the finished video. Drive the   WORKSPACE caption with `adom-cli hydrogen caption` — THE default, identical on-  web-Hydrogen AND HD (text positional; `-d` duration in SECONDS not ms; 30s auto-expire+  web-Hydrogen AND Hydrogen (text positional; `-d` duration in SECONDS not ms; 30s auto-expire   by default, 5-min hard cap, newest-wins, `hide` to clear; a raw-HTTP-  `POST .../current/caption` fallback exists for scripts hitting HD's API directly).+  `POST .../current/caption` fallback exists for scripts hitting Hydrogen's API directly).   Distinct from toasts (notifications) and TTS (audio). NOTE: a full-DESKTOP overlay   (over every window, on top of other apps) exists as a platform-specific companion —   see [[hydrogen-captions-windows]]. Trigger words — caption, on-screen caption, workspace@@ -29,16 +29,16 @@ so they end up in the finished video ("Step 3: run DRC →"). > - **toasts** — corner pop-ups via `POST /ui/toast` (transient notifications, see >   `hydrogen-notifications`); a caption is centered narration, a toast is a corner alert. > - **TTS** *audio* narration (`adom-tts`) — pair a caption with TTS for a narrated walkthrough.-> - the internal **auth-overlay caption** HD draws for login/auth flows — not something+> - the internal **auth-overlay caption** Hydrogen draws for login/auth flows — not something >   you trigger for demos. The workspace caption below is the one you drive.  ## Two caption surfaces — pick by WHAT you're recording -HD has **two** caption surfaces, each captured by a *different* kind of recording:+Hydrogen has **two** caption surfaces, each captured by a *different* kind of recording:  | Surface | Command | Renders | Captured by | Use when | |---|---|---|---|---|-| **Workspace caption** | `adom-cli hydrogen caption` | **inside the HD workspace** (webview overlay, web-Hydrogen style) | a recording/screenshot of the **HD window** (panel/workspace) | the demo is **inside HD** — captioning the workspace itself |+| **Workspace caption** | `adom-cli hydrogen caption` | **inside the Hydrogen workspace** (webview overlay, web-Hydrogen style) | a recording/screenshot of the **Hydrogen window** (panel/workspace) | the demo is **inside Hydrogen** — captioning the workspace itself | | **Desktop overlay** | platform-specific (see [[hydrogen-captions-windows]]) | **over the WHOLE desktop**, above every window | a **full-screen / desktop** recording | the demo shows **other apps** (KiCad, Fusion, a browser) or the whole screen |  **Match the caption to the recording.** A `screenshot panel` / workspace capture sees the@@ -52,9 +52,9 @@ screen pixels). Pick wrong and your caption won't be in the video.  ## Workspace caption — `adom-cli hydrogen caption` ⭐ THE DEFAULT -**Reach for this FIRST.** It's the *same* command on web Hydrogen and HD (adom-cli routes-through HD's workspace-events server → SSE → the frontend `captionStore`), so it stays-consistent across both — same principle as screenshots. Renders centered **inside the HD+**Reach for this FIRST.** It's the *same* command on web Hydrogen and Hydrogen (adom-cli routes+through Hydrogen's workspace-events server → SSE → the frontend `captionStore`), so it stays+consistent across both — same principle as screenshots. Renders centered **inside the Hydrogen workspace webview**. `show` takes the TEXT as a **positional arg** (NOT `--text`); the only flags are `-d`/`--duration`, `-p`/`--position`, `-s`/`--size` (no `id`, `x`/`y`, or `fontSize` — those are desktop-overlay-only). Subcommands: `show` / `hide`.@@ -72,9 +72,9 @@ default already covers "leave it up while I do a thing." (Note: the *desktop ove the platform companion uses **milliseconds** — the two surfaces differ; don't cross the units.) -> **Web-Hydrogen vs HD parity:** the **command + the SECONDS unit + `hide` are identical**+> **Web-Hydrogen vs Hydrogen parity:** the **command + the SECONDS unit + `hide` are identical** > on both (center/large rendering, `-d 20` held visibly). BUT the sane **lifecycle below-> (30s default / 300s cap / persist)** is verified on HD; web Hydrogen may still return the+> (30s default / 300s cap / persist)** is verified on Hydrogen; web Hydrogen may still return the > *older terse `_hint`* ("auto-hides after the specified duration") and may not enforce the > 30s-default/300s-cap yet. **So on web Hydrogen, don't assume a fat `-d` self-heals — pass > a sane duration.**@@ -87,7 +87,7 @@ units.) - **Newest wins:** showing another caption replaces the current one; `hide` clears immediately. - **No "forever" via adom-cli** — its `-d` is an unsigned int (rejects negatives) by   design. This is a **feature, not a gap**: adom-cli is the same binary on web-Hydrogen and-  HD, so "no persist via adom-cli" keeps both consistent and bounded (no abandoned+  Hydrogen, so "no persist via adom-cli" keeps both consistent and bounded (no abandoned   captions). A persist-until-hidden escape exists ONLY on the raw HTTP endpoint   (`{"duration":-1}`, below) — rarely needed. - **No `caption status` verb (yet).** There's no way to query "is a caption up / how long@@ -96,8 +96,8 @@ units.)   those). `-s` size: `small` / `medium` / `large`. - Needs a live workspace/editor session (the server returns 409 if none). -### Direct HTTP fallback — only for scripts already hitting HD's API-adom-cli is the consistent default; use HTTP **only** when a script talks to HD's API+### Direct HTTP fallback — only for scripts already hitting Hydrogen's API+adom-cli is the consistent default; use HTTP **only** when a script talks to Hydrogen's API directly. It's the **same caption, same lifecycle** — adom-cli just wraps this path with the workspace owner/repo. The caption lives on the **workspace-events server** (`ADOM_HYDROGEN_URL`, the proxy) — **NOT the control port**:@@ -118,7 +118,7 @@ Body: `{text, duration (SECONDS), position, size}`; clear with `{hide:true}`. ## Desktop overlay caption (over the whole screen)  For a caption that floats over **every window** (above other apps, the whole desktop) —-with ids, corners, and normalized x/y placement — HD provides a native always-on-top,+with ids, corners, and normalized x/y placement — Hydrogen provides a native always-on-top, click-through desktop overlay. That surface and its arguments are **platform-specific**; see **[[hydrogen-captions-windows]]**. 

@@ -1,15 +1,15 @@ --- name: hydrogen-capture-share description: >-  The in-HD screen-share + AI-consent surface that lets YOU (the AI) screenshot+  The in-Hydrogen screen-share + AI-consent surface that lets YOU (the AI) screenshot   the editor or the whole screen into the container. Covers the Screen Capture   dropdown in the editor toolbar (Share this tab / Share entire screen / Stop   sharing, plus Workspace / Full-screen screenshot), the Webview-vs-Pup Window   mode toggle, the panel/workspace/screen capture scopes + Element-Capture   RestrictionTarget, and the AI sharing-approval flow: SharingApprovalDialog-  ("AI wants access" + your reason), the ~3s auto-approve in HD, and the+  ("AI wants access" + your reason), the ~3s auto-approve in Hydrogen, and the   cancelable CountdownToast before capture starts. READ THIS before trying to-  screenshot the editor — a screenshot of HD's own UI requires an active share.+  screenshot the editor — a screenshot of Hydrogen's own UI requires an active share.   Trigger words — screen share, share this tab, share screen, screen capture   dropdown, capture the editor, screenshot the workspace, workspace screenshot,   AI wants access, sharing approval, consent dialog, countdown toast, start@@ -19,15 +19,15 @@ description: >  # Hydrogen — Screen Capture & Sharing (the AI-consent surface) -This is the surface **you (the AI) trigger to see HD's own screen.** To screenshot+This is the surface **you (the AI) trigger to see Hydrogen's own screen.** To screenshot the *editor* (panels, the workspace, or the whole monitor) into the container, a-**screen share must be active first.** You request it, the user consents once (HD+**screen share must be active first.** You request it, the user consents once (Hydrogen auto-approves in ~3s), a brief countdown plays, then you can capture frames.  > This is **not** the same as host OS screenshots. `desktop_screenshot_*` > (see [hydrogen-adom-desktop](../hydrogen-adom-desktop/SKILL.md)) take true OS screenshots via-> AD with zero dialogs. This skill is the **in-webview** share that captures what-> HD itself is rendering (the editor) via the browser's `getDisplayMedia`/Element+> ab with zero dialogs. This skill is the **in-webview** share that captures what+> Hydrogen itself is rendering (the editor) via the browser's `getDisplayMedia`/Element > Capture, gated by an in-app consent dialog. And it is distinct from > [hydrogen-permissions](../hydrogen-permissions/SKILL.md) (WebView2 auto-granting mic/cam OS > permissions) — that's a different layer.@@ -41,7 +41,7 @@ Store: `src/lib/stores/screenCaptureStore.ts`.  | Option | Description | What you get | |---|---|---|-| **Share this tab** | "Panels and workspace screenshots" | Captures HD's own webview — panels + workspace |+| **Share this tab** | "Panels and workspace screenshots" | Captures Hydrogen's own webview — panels + workspace | | **Share entire screen** | "Full display including other apps" | Captures the whole monitor (or a chosen window) |  **While sharing**, it shows `Sharing <surface>` ("entire screen" / "window" / "this@@ -57,8 +57,8 @@ tab") plus capture actions:  Below the share options is a **Window mode** toggle with two buttons — **Webview** and **Pup** (`windowModeStore`). It selects which window surface-capture/recording targets: HD's own embedded Webview, or a Pup (Puppeteer)-browser window. Webview = "see HD itself"; Pup = "see the AI-driven browser."+capture/recording targets: Hydrogen's own embedded Webview, or a Pup (Puppeteer)+browser window. Webview = "see Hydrogen itself"; Pup = "see the AI-driven browser."  ## Capture scopes & how a frame is taken @@ -71,7 +71,7 @@ type CaptureScope = 'screen' | 'workspace' | 'panel'; | Scope | Function | What it captures | |---|---|---| | `panel` | `capturePanel(panelId)` | a single editor panel |-| `workspace` | `captureWorkspace()` | the whole HD workspace surface |+| `workspace` | `captureWorkspace()` | the whole Hydrogen workspace surface | | `screen` | `captureScreen()` | the full display / shared window |  Other store entry points you'll see: `startTabCapture()`, `startScreenCapture()`,@@ -83,19 +83,19 @@ where `displaySurface` is `'browser'` (tab) / `'window'` / `'monitor'`.  ### Element Capture (RestrictionTarget) -When `'RestrictionTarget' in window` and `getDisplayMedia` are available, HD can+When `'RestrictionTarget' in window` and `getDisplayMedia` are available, Hydrogen can **restrict a tab capture to a single DOM element** so only that panel is in frame: `restrictCaptureTo(el)` builds a `RestrictionTarget.fromElement(el)` and calls `track.restrictTo(target)` (a short ~3s settle window). This is how a panel-scoped capture yields just the panel, not the whole webview. -> Native (Tauri) note: inside HD, tab/screen snapshots come from the native CDP+> Native (Tauri) note: inside Hydrogen, tab/screen snapshots come from the native CDP > path rather than a live `MediaStream`; the store still flips `isSharing` and sets > `displaySurface` to `'window'`/`'monitor'` so the same UI flow applies.  ## The AI sharing-approval flow -When you (or a bridge) need screen/mic access, HD shows a consent gate before any+When you (or a bridge) need screen/mic access, Hydrogen shows a consent gate before any capture. Source: `src/lib/components/editor/SharingApprovalDialog.svelte`, store `src/lib/stores/sharingApprovalStore.ts`. @@ -109,13 +109,13 @@ The request you send carries:   highlighted box. **Send a clear, specific reason** — it's the only thing the user   sees to decide. ("Screenshot the schematic panel to verify the layout," not   "capture screen.")-- **HD auto-approves after ~3 s** (`AUTO_MS = 3000`), showing-  "Auto permission will be given in N…". This is the HD-only fast path so you're+- **Hydrogen auto-approves after ~3 s** (`AUTO_MS = 3000`), showing+  "Auto permission will be given in N…". This is the Hydrogen-only fast path so you're   not blocked on hands-free flows. - **The user can override before it auto-fires:** flip share-type between   **Share this tab** and **Share entire screen**, toggle the **mic**, or pick a mic   device. Any interaction cancels the auto-countdown so they stay in control.-- On approve, HD starts the screen share first (tab or screen), then mic if+- On approve, Hydrogen starts the screen share first (tab or screen), then mic if   requested, and returns a result (`status: 'approved'`, with `sharing` + `mic`   details) to the requesting bridge. @@ -129,20 +129,20 @@ the toast is a real, abortable delay.  ## What this means for you (the AI) -1. **To screenshot HD's editor you need an active share.** If you're not sharing,+1. **To screenshot Hydrogen's editor you need an active share.** If you're not sharing,    call `promptScreenCapture(...)` / send a sharing request with a reason; don't    silently fail a `capturePanel`/`captureWorkspace`. 2. **Write the reason for a human.** It's your one chance to justify the access. 3. **Respect the override + countdown.** The user may switch share-type, deny mic,    or cancel the countdown — read the returned result before claiming success. 4. **Pick the right scope:** `panel` (one panel, Element-Capture-restricted),-   `workspace` (the HD surface), or `screen` (full display). Use Window mode-   (Webview vs Pup) to choose HD's own UI vs the AI browser.-5. **For host-OS screenshots that need no share at all,** use AD's+   `workspace` (the Hydrogen surface), or `screen` (full display). Use Window mode+   (Webview vs Pup) to choose Hydrogen's own UI vs the AI browser.+5. **For host-OS screenshots that need no share at all,** use ab's    `desktop_screenshot_*` instead (see Related skills).  ## Related skills-- [hd-recording](../hd-recording/SKILL.md) — screen/mic recording (same share + countdown machinery; in-app .webm recorder + AD desktop recording)+- [hydrogen-recording](../hydrogen-recording/SKILL.md) — screen/mic recording (same share + countdown machinery; in-app .webm recorder + ab desktop recording) - [hydrogen-self-screenshot](../hydrogen-self-screenshot/SKILL.md) — CDP per-panel screenshots + shotlog visual-verify loop - [hydrogen-permissions](../hydrogen-permissions/SKILL.md) — WebView2 auto-granting OS mic/cam/notification permissions (a *different* layer from this consent dialog)-- [hydrogen-adom-desktop](../hydrogen-adom-desktop/SKILL.md) — AD's dialog-free host OS screenshots (`desktop_screenshot_screen/_window`)+- [hydrogen-adom-desktop](../hydrogen-adom-desktop/SKILL.md) — ab's dialog-free host OS screenshots (`desktop_screenshot_screen/_window`)

@@ -1,11 +1,11 @@ --- name: hydrogen-claude-auth-description: How Claude Code authenticates inside HD — the OAuth flow that opens in your browser via the Browser Picker, where credentials are stored on host vs workspace, how HD backs them up so a workspace rebuild doesn't make you re-auth, the virgin-reset toggle that wipes Claude creds, and the 4-technique auth cascade HD runs if Claude isn't authenticated. READ when troubleshooting "Claude not authenticated", expired Claude tokens, re-authenticating after a virgin reset, or wondering where Claude credentials live. Trigger words — claude auth, claude code login, claude code authentication, claude not authenticated, claude oauth, claude credentials, claude session, claude.ai subscription, replay-claude-credentials.json, claude-auth, claude credential backup, claude re-auth, claude expired, claude.ai subscription button.+description: How Claude Code authenticates inside Hydrogen — the OAuth flow that opens in your browser via the Browser Picker, where credentials are stored on host vs workspace, how Hydrogen backs them up so a workspace rebuild doesn't make you re-auth, the virgin-reset toggle that wipes Claude creds, and the 4-technique auth cascade Hydrogen runs if Claude isn't authenticated. READ when troubleshooting "Claude not authenticated", expired Claude tokens, re-authenticating after a virgin reset, or wondering where Claude credentials live. Trigger words — claude auth, claude code login, claude code authentication, claude not authenticated, claude oauth, claude credentials, claude session, claude.ai subscription, replay-claude-credentials.json, claude-auth, claude credential backup, claude re-auth, claude expired, claude.ai subscription button. --- -# HD Claude Auth — how Claude Code signs in+# Hydrogen Claude Auth — how Claude Code signs in -Claude Code (the VS Code extension inside your HD workspace) authenticates separately from your Adom login. HD takes responsibility for making sure Claude is signed in throughout workspace rebuilds so you don't have to re-authenticate every time.+Claude Code (the VS Code extension inside your Hydrogen workspace) authenticates separately from your Adom login. Hydrogen takes responsibility for making sure Claude is signed in throughout workspace rebuilds so you don't have to re-authenticate every time.  For Adom auth (your hydrogen.adom.inc login), see [hydrogen-adom-auth](../hydrogen-adom-auth/SKILL.md). This skill is Claude-Code-specific. @@ -13,40 +13,40 @@ For Adom auth (your hydrogen.adom.inc login), see [hydrogen-adom-auth](../hydrog  1. The Claude Code extension panel shows a "Claude.ai Subscription" button when it isn't authenticated. 2. Clicking opens an OAuth URL to `claude.ai`.-3. HD's Browser Picker intercepts the URL (since it's a `*.claude.ai` link). The "Claude auth" branded variant of the picker appears with the work browser profile pre-selected and a 5-second auto-countdown.+3. Hydrogen's Browser Picker intercepts the URL (since it's a `*.claude.ai` link). The "Claude auth" branded variant of the picker appears with the work browser profile pre-selected and a 5-second auto-countdown. 4. The browser opens the Claude OAuth page; you complete sign-in (or it auto-completes if you're already signed in to claude.ai). 5. Claude returns OAuth credentials, which the extension stores at `/home/adom/.claude/.credentials.json` inside the workspace.-6. HD's setup step `claude-auth` notices the new credentials and **backs them up to the host** (in HD's app-data directory, as `replay-claude-credentials.json`) so future workspace rebuilds can replay them. The exact host path is platform-specific — see the platform layer for where it lives on your OS.+6. Hydrogen's setup step `claude-auth` notices the new credentials and **backs them up to the host** (in Hydrogen's app-data directory, as `replay-claude-credentials.json`) so future workspace rebuilds can replay them. The exact host path is platform-specific — see the platform layer for where it lives on your OS.  ## Where Claude credentials live  | Layer | Location | Purpose | |-------|----------|---------| | Inside workspace (live) | `/home/adom/.claude/.credentials.json` | Active credentials the extension and `claude` CLI both read |-| Host-side backup | `replay-claude-credentials.json` in HD's app-data dir on the host | Backup so a fresh workspace can be re-authenticated without re-OAuth |+| Host-side backup | `replay-claude-credentials.json` in Hydrogen's app-data dir on the host | Backup so a fresh workspace can be re-authenticated without re-OAuth | | VS Code secret store (in code-server's user data) | webview-internal, can't be inspected directly | The extension also keeps a secret per panel; this is what dictates the chat UI showing vs the auth button |  **Key insight**: each Claude Code panel instance keeps its own auth state. If one panel says "not authenticated", opening a NEW Claude Code conversation panel often shows the auth button fresh and lets you sign in cleanly. -## How HD keeps you signed in across workspace rebuilds+## How Hydrogen keeps you signed in across workspace rebuilds  When you virgin-reset and rebuild the workspace (assuming you DON'T check the "Claude credentials" toggle):  1. Workspace deleted + recreated by setup steps-2. Step `claude-auth` runs early — reads the `replay-claude-credentials.json` backup from HD's host app-data dir+2. Step `claude-auth` runs early — reads the `replay-claude-credentials.json` backup from Hydrogen's host app-data dir 3. If the file exists AND the `expiresAt` is still in the future → copies it into the new workspace at `/home/adom/.claude/.credentials.json` 4. Claude Code extension reads it on first launch → user stays signed in -If credentials are expired or missing, HD runs the **auth cascade** to get you signed in without manual fiddling.+If credentials are expired or missing, Hydrogen runs the **auth cascade** to get you signed in without manual fiddling.  ## The 4-technique auth cascade -If Claude isn't authenticated after setup, HD tries each technique in order until one works. Each call logs to the setup panel output so you see exactly what's happening.+If Claude isn't authenticated after setup, Hydrogen tries each technique in order until one works. Each call logs to the setup panel output so you see exactly what's happening.  | # | Technique | What it does | |---|-----------|--------------| | 1 | Detect auth failure | Scans all VS Code webview contexts for the "Claude.ai Subscription" button / "How do you want to log in?" text. Confirms whether the auth UI is reachable. |-| 2 | Open NEW conversation + auto-click auth button | The new-conversation panel re-evaluates auth state and shows the button cleanly. HD clicks it via the webview eval channel. |+| 2 | Open NEW conversation + auto-click auth button | The new-conversation panel re-evaluates auth state and shows the button cleanly. Hydrogen clicks it via the webview eval channel. | | 3 | Open Claude editor + auto-click auth button | If technique 2 didn't trigger a fresh auth state, opens a Claude editor (different VS Code command) and tries the same click. | | 4 | CLI fallback (`claude auth login`) | Runs `claude auth login` inside the workspace, extracts the OAuth URL from stdout, opens it in your browser via the Browser Picker. You paste the returned code into a VS Code terminal. | @@ -70,17 +70,17 @@ The setup panel's Virgin Reset section has a per-Claude-creds toggle: - A SECOND panel still has stale auth state. Close all Claude Code panels and open one fresh — it'll read the new credentials.  **Credentials backup file exists but Claude says expired**-- Open the `replay-claude-credentials.json` backup (in HD's host app-data dir) and check the `expiresAt` (epoch ms). Compare to current time. If past, you need to re-OAuth. HD's auth cascade will handle this on next setup run.+- Open the `replay-claude-credentials.json` backup (in Hydrogen's host app-data dir) and check the `expiresAt` (epoch ms). Compare to current time. If past, you need to re-OAuth. Hydrogen's auth cascade will handle this on next setup run.  **`claude auth status` says `loggedIn: true` but the extension says not authenticated** - **Known quirk**: the CLI and the VS Code extension use SEPARATE credential stores. `claude auth status` checks the CLI store; the extension uses VS Code secrets. Trust the extension UI (the "Claude.ai Subscription" button) over the CLI's status output.  **OAuth callback fails / browser shows "connection refused"**-- The callback URL is hitting a local port that HD hasn't forwarded to the host. Check the HD log for `[oauth] Callback port N detected` — HD should auto-start a proxy for it. If not, register the port manually via `adom-cli port-forward register <port> --visibility external`. (How host↔workspace port forwarding works is platform-specific — see the platform layer.)+- The callback URL is hitting a local port that Hydrogen hasn't forwarded to the host. Check the Hydrogen log for `[oauth] Callback port N detected` — Hydrogen should auto-start a proxy for it. If not, register the port manually via `adom-cli port-forward register <port> --visibility external`. (How host↔workspace port forwarding works is platform-specific — see the platform layer.)  ## Related skills  - [hydrogen-adom-auth](../hydrogen-adom-auth/SKILL.md) — Adom (hydrogen.adom.inc) login, separate from Claude-- [hd-browser-picker](../hd-browser-picker/SKILL.md) — the Browser Picker that routes the Claude OAuth URL, including the branded "Claude auth" variant+- [hydrogen-browser-picker](../hydrogen-browser-picker/SKILL.md) — the Browser Picker that routes the Claude OAuth URL, including the branded "Claude auth" variant - `hydrogen-setup-steps` — the `claude-auth` step and the auth cascade are part of setup - `hydrogen-volume` — explains why the host-side backup survives workspace rebuild

@@ -1,11 +1,11 @@ --- name: hydrogen-desktop-sse-description: How HD's local workspace API + SSE works (a.k.a. the workspace API) — replaces Carbon for workspace commands so the workspace's adom-cli controls HD, not cloud Hydrogen. Covers the full pipeline, routing, env vars, field format differences, port discovery, and hard-won lessons. Trigger words — HD SSE, workspace API, local API, adom-cli workspace, add-tab, move-tab, webview tab, EventSource, workspace_updated, ADOM_CARBON_URL, ADOM_HYDROGEN_URL, discovery port.+description: How Hydrogen's local workspace API + SSE works (a.k.a. the workspace API) — replaces Carbon for workspace commands so the workspace's adom-cli controls Hydrogen, not cloud Hydrogen. Covers the full pipeline, routing, env vars, field format differences, port discovery, and hard-won lessons. Trigger words — Hydrogen SSE, workspace API, local API, adom-cli workspace, add-tab, move-tab, webview tab, EventSource, workspace_updated, ADOM_CARBON_URL, ADOM_HYDROGEN_URL, discovery port. ---  # Hydrogen — Local Workspace API + SSE -> Platform note: HD runs the same local workspace API on every platform (Windows/WSL2,+> Platform note: Hydrogen runs the same local workspace API on every platform (Windows/WSL2, > macOS, Linux). For the WSL2-specific networking details (mirrored loopback, > `%APPDATA%\hydrogen-desktop\ports.json`, the `HD_RUNTIME=docker` runtime, relay > same-port behavior), see **[[hydrogen-desktop-sse-windows]]**.@@ -14,17 +14,17 @@ description: How HD's local workspace API + SSE works (a.k.a. the workspace API)  ``` Workspace adom-cli (the local workspace)-    → http://127.0.0.1:47083 (HD's proxy)-    → HD handles workspace commands locally + broadcasts SSE-    → HD frontend receives SSE, re-fetches workspace, renders+    → http://127.0.0.1:47083 (Hydrogen's proxy)+    → Hydrogen handles workspace commands locally + broadcasts SSE+    → Hydrogen frontend receives SSE, re-fetches workspace, renders  Cloud adom-cli (unchanged)     → carbon.adom.inc → Hydrogen web ``` -HD runs its own workspace API on port 47083 (reverse proxy, default — see PortConfig) so the workspace's adom-cli controls HD's UI, not cloud Hydrogen. No cross-talk between environments. The workspace reaches HD at `127.0.0.1:47083`.+Hydrogen runs its own workspace API on port 47083 (reverse proxy, default — see PortConfig) so the workspace's adom-cli controls Hydrogen's UI, not cloud Hydrogen. No cross-talk between environments. The workspace reaches Hydrogen at `127.0.0.1:47083`. -## Port 47083 routing (the hd-proxy / reverse-proxy)+## Port 47083 routing (the hydrogen-proxy / reverse-proxy)  All requests hit port 47083 (reverse proxy, default — see PortConfig). The router in `handle_request()` decides: @@ -42,7 +42,7 @@ The dev file server on port 1420 forwards `/api/*` directly to `handle_request()  **Endpoint:** `GET /api/workspaces/editor/{owner}/{repo}/current/events` -Uses `tokio::sync::broadcast` channel. On connect sends `{"type":"connected","connectionId":"hd-local"}`. Workspace mutations broadcast `{"type":"workspace_updated"}`.+Uses `tokio::sync::broadcast` channel. On connect sends `{"type":"connected","connectionId":"hydrogen-local"}`. Workspace mutations broadcast `{"type":"workspace_updated"}`.  **Frontend connects** in `PanelWorkspaceComponent.svelte` → `setupSSE()`. In Tauri mode, `$page.params` may be empty (adapter-static), so it falls back to `owner=local, repo=workspace`. @@ -72,12 +72,12 @@ Set when the workspace is created:  | Var | Value | Why | |---|---|---|-| `VSCODE_PROXY_URI` | `http://hd-hdlocal/proxy/{{port}}/` | Slug = `hdlocal` (last segment after `-`) |+| `VSCODE_PROXY_URI` | `http://hydrogen-hdlocal/proxy/{{port}}/` | Slug = `hdlocal` (last segment after `-`) | | `ADOM_CARBON_URL` | `http://127.0.0.1:47083` | Container discovery + non-workspace API | | `ADOM_HYDROGEN_URL` | `http://127.0.0.1:47083` | Workspace mutations (adom-cli sends these HERE, not to Carbon) | | `ADOM_DESKTOP_MODE` | `local` | Tells adom-cli it's a local environment | -`127.0.0.1` reaches HD on the host from inside the workspace. The canonical code-server port HD exposes on the host is 7380.+`127.0.0.1` reaches Hydrogen on the host from inside the workspace. The canonical code-server port Hydrogen exposes on the host is 7380.  **Also set in adom-cli config** (persists across sessions): ```bash@@ -86,7 +86,7 @@ adom-cli config set-token <session-token> ``` Plus manually write `hydrogen_url` to `~/.config/adom-cli/config.json` (no CLI command for it). -**API key** injected at `/var/run/adom/api-key` by bootstrap via `GET "$(cat ~/.adom/hd-control-url)/auth-token"` (the control URL is `http://127.0.0.1:<dynamic>`).+**API key** injected at `/var/run/adom/api-key` by bootstrap via `GET "$(cat ~/.adom/hydrogen-control-url)/auth-token"` (the control URL is `http://127.0.0.1:<dynamic>`).  ## Workspace Tree Format @@ -104,11 +104,11 @@ The frontend serializes splits with `first`/`second`, NOT `children`:  All tree traversal functions (`find_leaf_path`, `find_split_path`, `resolve_path`) must handle BOTH `children` array and `first`/`second` keys. -## REST Endpoint Field Names (adom-cli vs HD)+## REST Endpoint Field Names (adom-cli vs Hydrogen)  adom-cli sends different field names than you might expect: -| Endpoint | adom-cli sends | HD must read |+| Endpoint | adom-cli sends | Hydrogen must read | |---|---|---| | POST /tabs | `{panelId, panelType, displayName, initialState}` | Construct tab with UUID, merge initialState into panelState | | POST /moves | `{sourcePanelId, tabId, targetPanelId}` | NOT `sourcePanel`/`targetPanel` |@@ -153,10 +153,10 @@ The `onopen` handler PUTs workspace state → broadcasts `workspace_updated` → Three stacked issues: 1. `VSCODE_PROXY_URI` was `http://localhost:8080/...` → slug parsed as `8080` → called `/containers/8080` → Carbon 404 2. Container info response had flat `{"owner": "..."}` but adom-cli reads `container["repository"]["owner"]["name"]`-3. `ADOM_HYDROGEN_URL` wasn't set → workspace commands went to `hydrogen.adom.inc` instead of HD+3. `ADOM_HYDROGEN_URL` wasn't set → workspace commands went to `hydrogen.adom.inc` instead of Hydrogen  ### add-tab returned "Missing 'tab' in body"-HD expected `{"panelId", "tab": {id, panelType, panelState}}` but adom-cli sends `{"panelId", "panelType", "displayName", "initialState"}` — flat format. **Fix:** accept both, construct tab with UUID for the flat format.+Hydrogen expected `{"panelId", "tab": {id, panelType, panelState}}` but adom-cli sends `{"panelId", "panelType", "displayName", "initialState"}` — flat format. **Fix:** accept both, construct tab with UUID for the flat format.  ### move-tab returned "Source/target panel not found" Two issues:@@ -167,11 +167,11 @@ Two issues: `add_FrameNavigationStarting` was blocking ALL external URLs in child iframes, including legitimate webview panel content. **Fix:** stop blocking frame navigations entirely — webview panels need external URLs. URL interception for window.open still works via `on_new_window`.  ### Google showed "blocked" icon-Not an HD bug. Google sends `X-Frame-Options: SAMEORIGIN` which prevents iframe embedding. Sites that allow embedding (adom.inc, wiki) load fine.+Not an Hydrogen bug. Google sends `X-Frame-Options: SAMEORIGIN` which prevents iframe embedding. Sites that allow embedding (adom.inc, wiki) load fine. -## Port Discovery — How Any Client Finds HD+## Port Discovery — How Any Client Finds Hydrogen -All HD ports are dynamic (configurable via `ports.json`). The ONE constant is the **discovery port: 47080**. It never changes.+All Hydrogen ports are dynamic (configurable via `ports.json`). The ONE constant is the **discovery port: 47080**. It never changes.  ``` GET http://127.0.0.1:47080/discover@@ -200,11 +200,11 @@ Returns: | adom-bridge-cli relay | Control API port (was hardcoded 9001) | `curl :47080/discover` → use `control` field | | adom-cli in the workspace | Proxy + Hydrogen URL | Already set via `ADOM_CARBON_URL` env var at workspace creation | | External tools / diagnostics | Any port | Hit discovery, get the full map |-| Cloud Docker (this container) | All HD ports | `curl http://<desktop-ip>:47080/discover` via relay |+| Cloud Docker (this container) | All Hydrogen ports | `curl http://<desktop-ip>:47080/discover` via relay |  ### Implementation -Tiny `std::net::TcpListener` on port 47080 in `hd-app/src/lib.rs`. Runs on a plain OS thread (no tokio). Reads `get_runtime_ports()` on each request. Returns raw HTTP response with JSON body.+Tiny `std::net::TcpListener` on port 47080 in `hydrogen-app/src/lib.rs`. Runs on a plain OS thread (no tokio). Reads `get_runtime_ports()` on each request. Returns raw HTTP response with JSON body.  ```rust std::thread::spawn(move || {@@ -235,11 +235,11 @@ On first launch, defaults are written without scanning. Workspace-side ports (80  | File | What | |---|---|-| `src-tauri/crates/hd-proxy/src/lib.rs` | Workspace API, SSE, Carbon proxy, tree mutations (~1500 lines) |-| `src-tauri/crates/hd-docker/src/lib.rs` | Container env vars (CARBON_URL, HYDROGEN_URL, VSCODE_PROXY_URI) |-| `src-tauri/crates/hd-control/src/lib.rs` | `/auth-token` endpoint, `/ports` endpoint, `/setup/*` routes |-| `src-tauri/crates/hd-control/src/ports.rs` | PortConfig struct, load/save/resolve, DISCOVERY_PORT constant |-| `src-tauri/crates/hd-app/src/lib.rs` | Discovery server on :47080, port resolution at startup |+| `src-tauri/crates/hydrogen-proxy/src/lib.rs` | Workspace API, SSE, Carbon proxy, tree mutations (~1500 lines) |+| `src-tauri/crates/hydrogen-docker/src/lib.rs` | Container env vars (CARBON_URL, HYDROGEN_URL, VSCODE_PROXY_URI) |+| `src-tauri/crates/hydrogen-control/src/lib.rs` | `/auth-token` endpoint, `/ports` endpoint, `/setup/*` routes |+| `src-tauri/crates/hydrogen-control/src/ports.rs` | PortConfig struct, load/save/resolve, DISCOVERY_PORT constant |+| `src-tauri/crates/hydrogen-app/src/lib.rs` | Discovery server on :47080, port resolution at startup | | `src/lib/stores/portStore.ts` | Frontend Svelte store, `initPorts()`, `controlUrl()`, `codeServerUrl()` | | `src/lib/components/editor/workspaces/PanelWorkspaceComponent.svelte` | Frontend SSE setup, autosave, workspace re-fetch | | `scripts/hydrogen-bootstrap.sh` | Sets adom-cli config, injects API key, uses `HD_CONTROL_PORT` env var |

@@ -4,10 +4,10 @@ description: >   How Hydrogen reaches the user OUTSIDE the window — native OS toast   notifications + taskbar/dock attention — so the AI can proactively tell the user a   long job finished or that it needs them (great for hands-free / away-from-keyboard-  work). Covers HD's notify handler (levels info|warning|error|emergency, optional+  work). Covers Hydrogen's notify handler (levels info|warning|error|emergency, optional   <actions> buttons; emergency = a persistent attention request until the user looks)   and how to fire one with the `notify` desktop command / `adom-bridge-cli notify_user`.-  Also the in-app `/ui/toast` (a message INSIDE the HD window) and Pup's+  Also the in-app `/ui/toast` (a message INSIDE the Hydrogen window) and Pup's   browser_alert_window taskbar/dock nudge. The native OS-toast backend is   platform-specific (see [[hydrogen-notifications-windows]] for the Windows path);   cross-platform behavior is documented here. Trigger words — notify the user, send a@@ -15,12 +15,12 @@ description: >   bounce, get the user's attention, alert the user, notify_user, emergency notification,   urgent alert, notification actions, action buttons, ping the user, job done   notification, tell me when it's done, request attention, browser_alert_window, in-app-  toast, ui toast, /ui/toast, show a toast in HD, toast inside the window.+  toast, ui toast, /ui/toast, show a toast in Hydrogen, toast inside the window. ---  # Hydrogen — Notifications (reaching the user outside the window) -When the user isn't looking at HD — a long build is running, you've finished a job, or+When the user isn't looking at Hydrogen — a long build is running, you've finished a job, or you're **blocked and need them** — you can reach them on the OS level: a native **toast**, and for urgent cases a **persistent attention request** (a taskbar flash / dock bounce, depending on platform). This is what makes hands-free / away-from-keyboard work usable:@@ -35,8 +35,8 @@ don't just print a message into a panel nobody's watching — fire a notificatio  ## Firing a notification -Source: `src-tauri/crates/hd-app/src/notifications.rs` (`handle_notify` → `show_toast`).-Dispatched via the `notify` message; from the workspace use the AD CLI:+Source: `src-tauri/crates/hydrogen-app/src/notifications.rs` (`handle_notify` → `show_toast`).+Dispatched via the `notify` message; from the workspace use the ab CLI:  ```bash adom-bridge-cli notify_user '{"title":"Build complete","body":"hd_build_rust finished — exit 0","level":"info"}'@@ -55,7 +55,7 @@ Payload shape (`NotifyPayload`):  | Field | Notes | |---|---|-| `title` | Toast heading. (On some platforms HD prefixes the app identity — see the platform companion.) |+| `title` | Toast heading. (On some platforms Hydrogen prefixes the app identity — see the platform companion.) | | `body` | The message. | | `level` | `info` / `warning` / `error` / `emergency`. `warning`/`error`/`emergency` render as **long-duration** toasts; `info` is short. | | `actions` | Optional array of button labels rendered as buttons in the toast. Empty/omitted = no buttons. |@@ -63,7 +63,7 @@ Payload shape (`NotifyPayload`): ### Levels — and the `emergency` attention request  - `info` / `warning` / `error` — a standard toast (warnings and errors stay up longer).-- **`emergency`** — in addition to the toast, HD calls **`request_user_attention(Critical)`**+- **`emergency`** — in addition to the toast, Hydrogen calls **`request_user_attention(Critical)`**   on the main window and shows/unminimizes it. This produces a **persistent attention   request** (a taskbar flash on Windows, a dock bounce on macOS) that **keeps going until   the user actually interacts with the window/taskbar themselves** — it is *not* cleared by@@ -73,10 +73,10 @@ Payload shape (`NotifyPayload`): > The Windows-specific toast identity/title behavior (the AUMID "Adom" title quirk) and the > WinRT/orange-taskbar-flash details live in [[hydrogen-notifications-windows]]. -## In-app toast — `POST /ui/toast` (inside the HD window)+## In-app toast — `POST /ui/toast` (inside the Hydrogen window)  The notifications above reach the user **outside** the window (OS toast / taskbar). For a-lightweight message **inside** the HD window — the same toast UI the app uses for its own+lightweight message **inside** the Hydrogen window — the same toast UI the app uses for its own success/error messages — fire a control-API toast:  ```bash@@ -91,11 +91,11 @@ POST /ui/toast { "message": "Build finished ✅", "type": "success", "duration": | `duration` | ms before auto-dismiss (default 5000). **0 = persistent** until the user dismisses. | | `groupId` + `detail` | Optional: coalesce related toasts into one expandable group. | -It emits the `hd-toast` Tauri event, which the main window renders via the global+It emits the `hydrogen-toast` Tauri event, which the main window renders via the global `toastStore` (bottom-stacked toasts). **OS toast vs in-app toast:** use a `notify` OS toast-when the user may be **away from / not looking at** HD; use `/ui/toast` for an in-window-status cue while they're working in HD. (HD's native recording uses this for its auto-stop-notice — see [hd-recording](../hd-recording/SKILL.md).)+when the user may be **away from / not looking at** Hydrogen; use `/ui/toast` for an in-window+status cue while they're working in Hydrogen. (Hydrogen's native recording uses this for its auto-stop+notice — see [hydrogen-recording](../hydrogen-recording/SKILL.md).)  ## Pup's taskbar/dock nudge (`browser_alert_window`) @@ -122,6 +122,6 @@ Don't spam: one notification per meaningful event. Verify the bridge first (`adom-bridge-cli ping`) before claiming you notified them.  ## Related skills-- [hydrogen-adom-desktop](../hydrogen-adom-desktop/SKILL.md) — AD is what carries `notify_user` to the host; `ping`/`status` to verify the bridge and the `notify` capability-- [hydrogen-bridges](../hydrogen-bridges/SKILL.md) — the full AD capability list (`notify`, …) and Pup's `browser_alert_window`+- [hydrogen-adom-desktop](../hydrogen-adom-desktop/SKILL.md) — ab is what carries `notify_user` to the host; `ping`/`status` to verify the bridge and the `notify` capability+- [hydrogen-bridges](../hydrogen-bridges/SKILL.md) — the full ab capability list (`notify`, …) and Pup's `browser_alert_window` - [[hydrogen-notifications-windows]] — the Windows toast backend (WinRT, AUMID "Adom" title, orange taskbar flash)

@@ -3,12 +3,12 @@ name: hydrogen-open-url description: >   The decision guide for "open a URL / open a website" inside Hydrogen.   When the user says "open ti.com" / "pull up the datasheet page" / "show me-  that site", HD has SIX distinct ways to do it — a Hydrogen webview tab, an HD+  that site", Hydrogen has SIX distinct ways to do it — a Hydrogen webview tab, an Hydrogen   browser window, Pup (AI-drivable Chrome), a native desktop browser profile,   the Browser Picker chooser, or headless curl/fetch — each with different   trade-offs. READ THIS to pick the right one and to explain the options back to   the user instead of silently guessing. For the interception/plumbing behind the-  picker see hd-browser-picker; to drive Pup see pup; for webview tabs see+  picker see hydrogen-browser-picker; to drive Pup see pup; for webview tabs see   adom-workspace-control. Trigger words — open url, open website, open the site,   open ti.com, open a link, pull up the page, show me the website, view this url,   open in browser, which browser, how do I open, open the datasheet page, open in@@ -16,9 +16,9 @@ description: >   link options, wv, open in wv, open as wv, webview tab, wv tab. --- -# HD — Opening a URL (your options)+# Hydrogen — Opening a URL (your options) -When a user says **"open the ti.com website"** (or any URL), HD has several paths+When a user says **"open the ti.com website"** (or any URL), Hydrogen has several paths and a Browser Picker — but **don't hand the user the picker to decide.** Pick the best destination *for them* by use-case and **open it directly**, then offer the alternatives in one line. The right path depends on what they're doing — look at@@ -29,8 +29,8 @@ user — DON'T hand them the picker"** below for the rule.  | # | Option | Best when… | What the user sees | AI drives it? | |---|--------|-----------|--------------------|---------------|-| 1 | **Hydrogen webview tab** (aka **wv**) | the user wants the site *inside* HD, next to their work, and to keep it around | a panel/tab in the HD workspace | partly (reload/route) |-| 2 | **HD Browser Window** | a quick popout window owned by HD, not a full browser | a standalone HD-owned window | no |+| 1 | **Hydrogen webview tab** (aka **wv**) | the user wants the site *inside* Hydrogen, next to their work, and to keep it around | a panel/tab in the Hydrogen workspace | partly (reload/route) |+| 2 | **Hydrogen Browser Window** | a quick popout window owned by Hydrogen, not a full browser | a standalone Hydrogen-owned window | no | | 3 | **Pup (Puppeteer Chrome)** | **you** need to act on the page — screenshot, click, scrape, fill a form, verify | a real Chrome window on their desktop | **yes, fully** | | 4 | **Native desktop browser** | real logins/sessions, downloads, "just open it for me", auth flows | their own Chrome/Edge profile | no | | 5 | **Browser Picker** | you're not sure, or it's an auth/OAuth link — let the user choose (5s auto-default) | a chooser dialog | n/a (routes to one of the above) |@@ -50,10 +50,10 @@ keystrokes)."* Say it **once**, not every time (don't nag). This is exactly how  ## How you invoke each -All of these run from inside the HD workspace. The control API base URL is the live-value in `~/.adom/hd-control-url` — `http://127.0.0.1:<dynamic>` (WSL2 mirrored+All of these run from inside the Hydrogen workspace. The control API base URL is the live+value in `~/.adom/hydrogen-control-url` — `http://127.0.0.1:<dynamic>` (WSL2 mirrored networking shares loopback with the Windows host; the port is dynamic per launch).-Read it with `BASE="$(cat ~/.adom/hd-control-url)"` then hit `"$BASE/<endpoint>"`.+Read it with `BASE="$(cat ~/.adom/hydrogen-control-url)"` then hit `"$BASE/<endpoint>"`.  **1. Webview tab (wv)** — add a web-view tab pointed at the URL (`adom-workspace-control`, or `adom-cli hydrogen webview open-or-refresh --name <X> --url <url> --panel-id <id>`). Good@@ -61,13 +61,13 @@ for "keep this open while we work." ⚠️ **`open-or-refresh` needs `--panel-id tab** — without it you get *"Tab 'X' not found and --panel-id not provided"* (verified live 2026-06-14; get a panel id from `adom-cli hydrogen workspace get`). Re-running with the same `--name` once it exists just navigates/refreshes (no panel-id needed). Same `adom-cli` on-web-Hydrogen and HD — the consistent surface.+web-Hydrogen and Hydrogen — the consistent surface.  **2 / 4 / 5. Through the Browser Picker** — the single unifying entry point. POST-the URL and HD routes it (auto-picking a sensible default after a 5-second+the URL and Hydrogen routes it (auto-picking a sensible default after a 5-second countdown, or showing the chooser): ```bash-BASE="$(cat ~/.adom/hd-control-url)"   # http://127.0.0.1:<dynamic>+BASE="$(cat ~/.adom/hydrogen-control-url)"   # http://127.0.0.1:<dynamic>  # Auto-route (picker picks the best default in 5s — hands-free) curl -s -X POST -H 'Content-Type: application/json' \@@ -90,7 +90,7 @@ curl -s -X POST -H 'Content-Type: application/json' \   -d '{"url":"https://claude.ai/","browser":"edge","profileDir":"Default","fresh":true}' \   "$BASE/open-in-profile" ```-> ⚠️ **`/open-url` often replies `"HD timed out after 5s"` even when it SUCCEEDED**+> ⚠️ **`/open-url` often replies `"Hydrogen timed out after 5s"` even when it SUCCEEDED** > (verified live 2026-06-14: `{"url":"https://www.google.com"}` reported the timeout, but the > page opened in Edge). **Don't treat that as failure** — confirm with > `GET "$BASE/browser-picker/last-open"` → `{destination, url, fresh, ts}`. `fresh:false` =@@ -100,7 +100,7 @@ curl -s -X POST -H 'Content-Type: application/json' \  The picker's auto-default heuristic: `*.claude.ai`/`*.claude.com` and Adom `/auth/intent` → the user's work browser profile; unknown/right-click/iframe →-Pup; otherwise the user's last choice for that domain. See `hd-browser-picker`.+Pup; otherwise the user's last choice for that domain. See `hydrogen-browser-picker`.  **Fresh window (`"fresh":true`)** — the native-browser path (#4) can open the URL either as a tab in an already-running browser (default) or as a **brand-new window/@@ -109,7 +109,7 @@ a tab does not. So for **auth flows the user must complete** (Claude/Adom sign-i prefer `fresh:true` — the consent page comes to the front by itself, no manual focus. The Browser Picker defaults the "Open in a fresh window" toggle ON for auth URLs. On `/open-url`, `fresh` pre-seeds that toggle (the picker still shows; add `direct:true`-to skip it); `/open-in-profile` opens fresh directly. See `hd-browser-picker`.+to skip it); `/open-in-profile` opens fresh directly. See `hydrogen-browser-picker`.  **3. Pup** — open and then drive it with `adom-bridge-cli browser_*` verbs (`browser_open_window`, `browser_navigate`, `browser_screenshot`, `browser_eval`,@@ -149,22 +149,22 @@ profile."* Decide, act, offer alternatives — don't ask first.  Example — "open the texas instruments website" (login-likely → native work profile): ```bash-BASE="$(cat ~/.adom/hd-control-url)"+BASE="$(cat ~/.adom/hydrogen-control-url)" curl -s "$BASE/browser-profiles"     # pick the work profile (non-gmail email) curl -s -X POST -H 'Content-Type: application/json' \   -d '{"url":"https://www.ti.com","browser":"chrome","profileDir":"<work profileDir>"}' \   "$BASE/open-in-profile" ``` -## Govern routing policy — the picker is now a true FALLBACK (HD prefs API)+## Govern routing policy — the picker is now a true FALLBACK (Hydrogen prefs API) -The picker's per-domain memory is a first-class API (HD app behavior), so **the AI OWNS URL+The picker's per-domain memory is a first-class API (Hydrogen app behavior), so **the AI OWNS URL routing** — the picker only pops for a domain with **no stored policy AND no direct call**. Use this to set policy the user would otherwise click through the Manager for ("always open DigiKey in my work profile", "stop auto-opening X in Edge").  ```bash-BASE="$(cat ~/.adom/hd-control-url)"+BASE="$(cat ~/.adom/hydrogen-control-url)" # READ the policy map curl -s "$BASE/browser-picker/prefs" #   → {ok, prefs:{domains:{"<host>":{destination,label}, …}}}@@ -183,8 +183,8 @@ curl -s -X DELETE "$BASE/browser-picker/prefs"   - **native:** `browser:<browser>:<dir>` — e.g. `browser:edge:Default`, `browser:chrome:Profile 1`. **The profile dir is encoded in the ID** (no separate field). - **Discover valid native IDs** via `GET $BASE/browser-profiles` (maps each detected profile → its `browser`+`dir`); the 3 internal IDs are fixed above. - **`fresh` is NOT stored in prefs** — it's a per-OPEN flag (`/open-url {fresh:…}` / `/open-in-profile {fresh:…}`). Don't try to persist it here.-- **Writes hit the live Manager UI immediately** (the backend writes `hd-url-routing-prefs`-  localStorage + dispatches `hd-url-routing-prefs-changed`; an open Browser Picker Manager+- **Writes hit the live Manager UI immediately** (the backend writes `hydrogen-url-routing-prefs`+  localStorage + dispatches `hydrogen-url-routing-prefs-changed`; an open Browser Picker Manager   re-reads at once, and re-reads on open anyway).  **Net:** for a one-off open, *decide and call the direct endpoint* (`/open-in-profile`,@@ -193,7 +193,7 @@ policy so even user-initiated link clicks route there silently. The picker is no fallback for the genuinely-undecided.  ## Related skills-- [hd-browser-picker](../hd-browser-picker/SKILL.md) — the interception layers + picker dialog behind #2/#4/#5+- [hydrogen-browser-picker](../hydrogen-browser-picker/SKILL.md) — the interception layers + picker dialog behind #2/#4/#5 - `pup` — driving Pup browser windows (#3): navigate, screenshot, eval, reload - `adom-workspace-control` — adding/managing Hydrogen webview tabs (#1)-- [hd-runtime-mode](../hd-runtime-mode/SKILL.md) — none of this changes between the WSL2 and Docker runtimes+- [hydrogen-runtime-mode](../hydrogen-runtime-mode/SKILL.md) — none of this changes between the WSL2 and Docker runtimes

@@ -1,29 +1,29 @@ --- name: hydrogen-profile-menu-description: HD's profile menu — the user-avatar dropdown in the top-right corner that links to your Adom profile/repositories/molecules pages on adom.inc and contains the logout action. Logout is gated by a confirm dialog and returns you to the HD login page; logging in is the gate to using HD at all (no anonymous use). Use when the user asks about "log out", "logout", "sign out", "Your profile", "Your repositories", "Your molecules", the avatar dropdown, the login page, or "why am I locked out". Trigger words — profile menu, avatar menu, top-right avatar, user menu, log out, logout, sign out, confirm logout, login gate, login page, your profile, your repositories, your molecules, adom.inc profile, hd locked out, hd login required, return to login.+description: Hydrogen's profile menu — the user-avatar dropdown in the top-right corner that links to your Adom profile/repositories/molecules pages on adom.inc and contains the logout action. Logout is gated by a confirm dialog and returns you to the Hydrogen login page; logging in is the gate to using Hydrogen at all (no anonymous use). Use when the user asks about "log out", "logout", "sign out", "Your profile", "Your repositories", "Your molecules", the avatar dropdown, the login page, or "why am I locked out". Trigger words — profile menu, avatar menu, top-right avatar, user menu, log out, logout, sign out, confirm logout, login gate, login page, your profile, your repositories, your molecules, adom.inc profile, hd locked out, hd login required, return to login. --- -# HD Profile Menu+# Hydrogen Profile Menu -The profile menu is the dropdown that opens when you click your **circular user avatar in the top-right corner** of HD. It contains links to your Adom-account pages on `adom.inc` plus the logout action.+The profile menu is the dropdown that opens when you click your **circular user avatar in the top-right corner** of Hydrogen. It contains links to your Adom-account pages on `adom.inc` plus the logout action.  This is **separate from the Adom menu** (top-left logo). Different audiences, different functions — see [hydrogen-ui](../hydrogen-ui/SKILL.md) for the Adom menu.  ## Where your avatar image comes from -- **Logged in via Google** — HD displays the Google profile photo that Google gives us as part of the sign-in payload. You change it by changing your Google account photo.-- **Logged in via direct Adom login** (email/password style) — HD shows the avatar you've uploaded on `adom.inc`. To customize it, click **Your profile** in this menu to open your profile page on adom.inc and change the avatar there.+- **Logged in via Google** — Hydrogen displays the Google profile photo that Google gives us as part of the sign-in payload. You change it by changing your Google account photo.+- **Logged in via direct Adom login** (email/password style) — Hydrogen shows the avatar you've uploaded on `adom.inc`. To customize it, click **Your profile** in this menu to open your profile page on adom.inc and change the avatar there.  ## What's in the menu  | Item | Icon | Behavior | |------|------|----------|-| **Your profile** | person | `goTo('/users/<name>')` — navigates the HD webview to your Adom profile page |+| **Your profile** | person | `goTo('/users/<name>')` — navigates the Hydrogen webview to your Adom profile page | | **Your repositories** | folder | `goTo('/users/<name>/repositories')` — your repositories list | | **Your molecules** | atom / molecule | `goTo('/users/<name>/molecules')` — your molecules list |-| **Log out** | exit-arrow | Opens a confirm dialog → on confirm, clears the Adom session and returns to the HD login page |+| **Log out** | exit-arrow | Opens a confirm dialog → on confirm, clears the Adom session and returns to the Hydrogen login page | -> **Note (current behavior, verified 2026-06-12)**: the three "Your *" items call `goTo('/users/<name>/...')` (see `EditorNav.svelte` ~L2540-2557), i.e. they navigate the HD webview itself to the in-app `/users/...` route rather than opening adom.inc in the user's external browser. This is in-app navigation, not the Browser Picker. (The earlier "routes to internal HD views" concern has been narrowed to this expected in-app routing.)+> **Note (current behavior, verified 2026-06-12)**: the three "Your *" items call `goTo('/users/<name>/...')` (see `EditorNav.svelte` ~L2540-2557), i.e. they navigate the Hydrogen webview itself to the in-app `/users/...` route rather than opening adom.inc in the user's external browser. This is in-app navigation, not the Browser Picker. (The earlier "routes to internal Hydrogen views" concern has been narrowed to this expected in-app routing.)  ## Log out — the confirm dialog @@ -42,15 +42,15 @@ Clicking **Log out** opens this dialog: - **Cancel** — dismisses the dialog, you stay signed in - **Confirm** — wipes `hydrogen-session.txt` from `%APPDATA%\hydrogen-desktop\`, clears in-memory session state, and routes the webview to `/auth/login` -After Confirm: you land on the HD login page and **cannot use HD until you log in again.**+After Confirm: you land on the Hydrogen login page and **cannot use Hydrogen until you log in again.** -## Login is a gate to using HD+## Login is a gate to using Hydrogen -HD is **not usable without an Adom login**. There is no anonymous mode, no skip-login option once you're signed out. The (app)/+layout.svelte enforces this — if the session token is missing or expired, every protected route redirects to `/auth/login`.+Hydrogen is **not usable without an Adom login**. There is no anonymous mode, no skip-login option once you're signed out. The (app)/+layout.svelte enforces this — if the session token is missing or expired, every protected route redirects to `/auth/login`. -The login itself uses the auth-intent flow (no email/password entry in HD — you complete sign-in in your default browser, then HD picks up the session). See [hydrogen-adom-auth](../hydrogen-adom-auth/SKILL.md) for the full flow.+The login itself uses the auth-intent flow (no email/password entry in Hydrogen — you complete sign-in in your default browser, then Hydrogen picks up the session). See [hydrogen-adom-auth](../hydrogen-adom-auth/SKILL.md) for the full flow. -After successful login, HD restores you to the route you were trying to reach (or the dashboard).+After successful login, Hydrogen restores you to the route you were trying to reach (or the dashboard).  ## CSS selectors (for CDP eval / Claude automation) @@ -66,18 +66,18 @@ After successful login, HD restores you to the route you were trying to reach (o  ```bash # Open profile menu-echo "document.querySelector('.profile-dropdown-button')?.click()" | node C:\Users\john\hd-cdp.js+echo "document.querySelector('.profile-dropdown-button')?.click()" | node C:\Users\john\hydrogen-cdp.js  # Trigger logout-echo "Array.from(document.querySelectorAll('.dropdown-link')).find(e => e.textContent.includes('Log out'))?.click()" | node C:\Users\john\hd-cdp.js+echo "Array.from(document.querySelectorAll('.dropdown-link')).find(e => e.textContent.includes('Log out'))?.click()" | node C:\Users\john\hydrogen-cdp.js  # Confirm logout (after dialog appears)-echo "Array.from(document.querySelectorAll('button')).find(b => b.textContent.trim() === 'Confirm')?.click()" | node C:\Users\john\hd-cdp.js+echo "Array.from(document.querySelectorAll('button')).find(b => b.textContent.trim() === 'Confirm')?.click()" | node C:\Users\john\hydrogen-cdp.js ```  ## Related skills  - [hydrogen-adom-auth](../hydrogen-adom-auth/SKILL.md) — the Adom session token, login flow, profile loading - [hydrogen-claude-auth](../hydrogen-claude-auth/SKILL.md) — Claude Code auth (separate from Adom auth; logging out of Adom does NOT log you out of Claude)-- [hd-browser-picker](../hd-browser-picker/SKILL.md) — what opens the Your-*/external URLs in the user's chosen browser+- [hydrogen-browser-picker](../hydrogen-browser-picker/SKILL.md) — what opens the Your-*/external URLs in the user's chosen browser - [hydrogen-ui](../hydrogen-ui/SKILL.md) — the Adom menu (top-left, different dropdown)

@@ -1,24 +1,24 @@ --- name: hydrogen-self-screenshot description: >-  Screenshot HD from inside the workspace — a panel/webview (the welcome page, a+  Screenshot Hydrogen from inside the workspace — a panel/webview (the welcome page, a   tab), the whole workspace, OR the whole screen/desktop — using the BUILT-IN   `adom-cli hydrogen screenshot`. It saves a PNG into the container's   `screenshots/` folder and prints the path to Read. THE answer for "take a   screenshot of the welcome page", "screenshot the webview", "screenshot this   panel", "screenshot the editor", "screenshot my whole screen / the desktop",-  "show me what HD looks like", or verifying a UI change (ralph loop). Use this+  "show me what Hydrogen looks like", or verifying a UI change (ralph loop). Use this   even for "my whole screen / my desktop / my monitor" — that's the `screen`   scope. You do NOT need any image resizer. For a SPECIFIC element/region (a CPU   meter, a menu, a dialog, a toolbar) or an inline-b64 PNG, use the canonical   `POST /screenshot` control endpoint with a CSS `selector` (it ALWAYS region-clips   to that element) — and combine it with the UI command bus (`hydrogen-ui`: `ui/invoke`   to open a menu/dialog, then `/screenshot` its selector). Identical across web-  Hydrogen and HD. Trigger words — screenshot HD, screenshot the welcome page,+  Hydrogen and Hydrogen. Trigger words — screenshot Hydrogen, screenshot the welcome page,   screenshot the webview, screenshot a panel, screenshot a tab, screenshot the   workspace, screenshot the editor, screenshot my screen, screenshot the whole   screen, screenshot the desktop, capture my monitor, full screen capture,-  screenshot everything on screen, what does HD look like, adom-cli hydrogen+  screenshot everything on screen, what does Hydrogen look like, adom-cli hydrogen   screenshot, capture panel, capture workspace, capture screen, screenshot a region,   clip to selector, screenshot an element, screenshot a menu, screenshot a dialog,   region screenshot, b64 screenshot, POST /screenshot, /shot, screenshot without flash,@@ -26,9 +26,9 @@ description: >   image resizer, resize screenshot. --- -# HD — Screenshot a panel / webview / the workspace / the screen+# Hydrogen — Screenshot a panel / webview / the workspace / the screen -The built-in way to screenshot anything inside HD is the **`adom-cli hydrogen+The built-in way to screenshot anything inside Hydrogen is the **`adom-cli hydrogen screenshot`** command — the *same* `adom-cli` you already use. It captures the real rendered surface, drops a PNG into the container's `screenshots/` folder, and prints the path. Just `Read` that path. **No image resizer needed.**@@ -36,15 +36,15 @@ and prints the path. Just `Read` that path. **No image resizer needed.** ## Which screenshot tool? — the priority ladder  What you're capturing (and whether you want the teal flash) picks the tool. Default to-HD-native:+Hydrogen-native: -1. **HD content — a panel, the workspace, the editor, a webview, the screen+1. **Hydrogen content — a panel, the workspace, the editor, a webview, the screen    (the 99% case): `adom-cli hydrogen screenshot panel|workspace|screen`. THIS IS THE-   DEFAULT — reach for it first.** It's the *same* command in web Hydrogen and HD (HD is+   DEFAULT — reach for it first.** It's the *same* command in web Hydrogen and Hydrogen (Hydrogen is    meant to behave like web Hydrogen, and `adom-cli` is the one surface that's identical on    both), saves a PNG to your container's `screenshots/`, and you just `Read` it. Don't lead-   with an HD-only endpoint.-   - **HD-only enhancement / power path — `POST /screenshot {target, selector, b64, silent}`+   with an Hydrogen-only endpoint.+   - **Hydrogen-only enhancement / power path — `POST /screenshot {target, selector, b64, silent}`      (CDP).** Use ONLY when you need something `adom-cli` doesn't give you: a precise CSS      `selector` region-clip, an inline-base64 PNG (`b64`), or a `silent` (no-flash) grab — see      below. It does NOT exist in web Hydrogen, so it's a deliberate step OFF the consistent path.@@ -54,9 +54,9 @@ HD-native:  ## During a recording (multi-thread) — pick a coexisting method, never blind-retry -Adom users run **multiple AI threads on one HD**, so another thread may be recording the+Adom users run **multiple AI threads on one Hydrogen**, so another thread may be recording the screen while you capture. **Only the `adom-cli` SSE path (`screenshot panel/workspace/screen`)-is affected** — the CDP path coexists. HD makes this deterministic:+is affected** — the CDP path coexists. Hydrogen makes this deterministic:  - **Pre-flight `GET /capture/availability`** → reports the recording state plus, per method,   reliability + whether it coexists with a recording, a `recommended` method, and a `_hint`.@@ -71,18 +71,18 @@ is affected** — the CDP path coexists. HD makes this deterministic:   panel/workspace`) returns, the moment a recording is active, `{ok:false, error:"capture_busy",   retry_after_ms, alternatives:[{method:"cdp"}], _hint}` — never an empty body. **On   `capture_busy`: read `alternatives` and SWITCH — do NOT blindly retry the SSE path.**-- Authoritative recording state: `GET /recording/native/status`. See `hd-recording`.+- Authoritative recording state: `GET /recording/native/status`. See `hydrogen-recording`.  ## Pick the scope — panel / workspace / screen  | You want… | Command | Sub-command | |---|---|---| | ONE panel or webview tab (the welcome page, a viewer, the editor) | `adom-cli hydrogen screenshot panel …` | `panel` |-| The whole HD **workspace** (every panel side by side) | `adom-cli hydrogen screenshot workspace` | `workspace` |+| The whole Hydrogen **workspace** (every panel side by side) | `adom-cli hydrogen screenshot workspace` | `workspace` | | The whole **screen** — desktop, taskbar, OTHER apps | `adom-cli hydrogen screenshot screen` | `screen` |  **"My whole screen / my desktop / my monitor / everything"** → `adom-cli hydrogen-screenshot screen`. The HD `screen` scope captures the real desktop and saves the PNG into+screenshot screen`. The Hydrogen `screen` scope captures the real desktop and saves the PNG into your container, same as the others.  ## Do this — it saves a PNG and prints the path; then Read it@@ -149,15 +149,15 @@ display **awake** — leaving it active blocks the user's screensaver. After a o opened). Tab `panel`/`workspace` sharing doesn't hold the display, so this only matters once you've requested the `screen` scope. -## Why this works the same in HD as it does for web Hydrogen+## Why this works the same in Hydrogen as it does for web Hydrogen -`adom-cli` is **one binary** used by both web Hydrogen and HD — you can test these-commands anywhere. The difference is purely *where the work runs*: HD intercepts+`adom-cli` is **one binary** used by both web Hydrogen and Hydrogen — you can test these+commands anywhere. The difference is purely *where the work runs*: Hydrogen intercepts what adom-cli talks to. `adom-cli hydrogen <cmd>` hits `ADOM_HYDROGEN_URL`, which-in HD points at **HD's local proxy**. HD's proxy pulls out the **local hydrogen/SSE+in Hydrogen points at **Hydrogen's local proxy**. Hydrogen's proxy pulls out the **local hydrogen/SSE commands** (screenshot, webview, caption, notify, recording…) and runs them against-the HD frontend over SSE, while **carbon/cloud calls pass straight through** to the-cloud. For a screenshot: `PATCH /current/screenshot` → HD broadcasts an SSE+the Hydrogen frontend over SSE, while **carbon/cloud calls pass straight through** to the+cloud. For a screenshot: `PATCH /current/screenshot` → Hydrogen broadcasts an SSE `screenshot_request` → the frontend Element-Captures the panel → uploads it into **this container's** `screenshots/` folder → the CLI returns the saved path. So the command, and the returned path, behave the same — the bytes just land in your local@@ -175,19 +175,19 @@ container. `adom-cli hydrogen screenshot` above is the easy "save a panel/workspace/screen PNG" path. For **precise control** — a specific VS Code or webview surface, **any CSS region** (a meter, a menu, a dialog, a toolbar), or an inline PNG with no flash — use-HD's **canonical capture endpoint `POST /screenshot`** (aliases: `/shot`,+Hydrogen's **canonical capture endpoint `POST /screenshot`** (aliases: `/shot`, `/capture/viewport`). Read the control URL from the FILE — it's the dynamic port, and your non-login Bash shell won't have the env var:  ```bash-CTRL="$(cat ~/.adom/hd-control-url)"   # http://127.0.0.1:<dynamic>+CTRL="$(cat ~/.adom/hydrogen-control-url)"   # http://127.0.0.1:<dynamic> curl -s -X POST "$CTRL/screenshot" -H 'Content-Type: application/json' \   -d '{"target":"full","b64":true}' ```  | Field | Meaning | |---|---|-| `target` | the surface — `full`/`window` (whole HD window) · `vscode`/`editor`/`workbench`/`code` (the VS Code panel) · `shell`/`hd` (the Svelte shell: title bar, menus, panels) · a **webview url-substring** (e.g. `wiki`) · **or a TAB DISPLAY NAME** (e.g. `"ScreenA"`, `"VS Code"`) — see by-name note below |+| `target` | the surface — `full`/`window` (whole Hydrogen window) · `vscode`/`editor`/`workbench`/`code` (the VS Code panel) · `shell`/`hd` (the Svelte shell: title bar, menus, panels) · a **webview url-substring** (e.g. `wiki`) · **or a TAB DISPLAY NAME** (e.g. `"ScreenA"`, `"VS Code"`) — see by-name note below | | `selector` | **optional CSS selector — it ALWAYS WINS and region-clips to that element.** e.g. `.resource-bars` (CPU/RAM meter), `iframe[src*='wiki']`, `.setup-panel`, `.dialog`, `.dropdown-content.open` | | `b64` | `true` → returns the PNG inline as a `dataUrl` (decode + Read); else saved to a file in `screenshots/` | | `silent` | `true` → suppress the capture flash |@@ -206,15 +206,15 @@ returns ScreenA's pixels and leaves ScreenB active. The `adom-cli` SSE path (`screenshot panel --name ScreenA`) also activates + restores. This is the right call for "shot tab #2 while #4 is showing." -**The teal zap:** every HD-driven capture flashes a teal (`#00b8b0`) highlight on the+**The teal zap:** every Hydrogen-driven capture flashes a teal (`#00b8b0`) highlight on the captured **region** (just the panel/menu/region; full-window flash only for-`target:full`). Teal = HD-driven. Pass `silent:true` to suppress it.+`target:full`). Teal = Hydrogen-driven. Pass `silent:true` to suppress it.  ### Screenshot a menu / dialog / panel — open it, then clip to it The killer combo with the UI command bus (see **`hydrogen-ui`**): **open a surface → screenshot just that surface → close it** — no screen-clicking, no guessing where it is. ```bash-CTRL="$(cat ~/.adom/hd-control-url)"+CTRL="$(cat ~/.adom/hydrogen-control-url)" curl -s -X POST "$CTRL/ui/invoke"  -H 'Content-Type: application/json' -d '{"id":"adom-menu.open"}' curl -s -X POST "$CTRL/screenshot" -H 'Content-Type: application/json' -d '{"target":"shell","selector":".dropdown-content.open","b64":true}' curl -s -X POST "$CTRL/ui/invoke"  -H 'Content-Type: application/json' -d '{"id":"adom-menu.close"}'@@ -232,5 +232,5 @@ repeat. Log shots for the user with `shotlog inject -c hydrogen-ui -d "<desc>" <  ## Related skills - [hydrogen-capture-share](../hydrogen-capture-share/SKILL.md) — the sharing/approval UX behind `screenshot`-- [hd-recording](../hd-recording/SKILL.md) · [hydrogen-captions](../hydrogen-captions/SKILL.md) — sibling `adom-cli hydrogen` AV verbs+- [hydrogen-recording](../hydrogen-recording/SKILL.md) · [hydrogen-captions](../hydrogen-captions/SKILL.md) — sibling `adom-cli hydrogen` AV verbs - `shotlog` — the screenshot log viewer/injector

@@ -1,23 +1,23 @@ --- name: hydrogen-setup-steps-description: What HD's setup steps did to prepare your workspace — the install sequence that provisions the golden workspace image, injects your Adom session, wires up the relay, and walks the Claude auth gate. Use this skill when the user asks "what did setup do", "why is X installed", "re-run a setup step", "what's a virgin reset", or "why did step N fail". Trigger words — setup steps, install steps, setup panel, virgin reset, re-run step, Run All, what did setup do, why is X installed, setup failed, install-tools, hd setup, claude code extension install, gallia install, hd workspace ready.+description: What Hydrogen's setup steps did to prepare your workspace — the install sequence that provisions the golden workspace image, injects your Adom session, wires up the relay, and walks the Claude auth gate. Use this skill when the user asks "what did setup do", "why is X installed", "re-run a setup step", "what's a virgin reset", or "why did step N fail". Trigger words — setup steps, install steps, setup panel, virgin reset, re-run step, Run All, what did setup do, why is X installed, setup failed, install-tools, hd setup, claude code extension install, gallia install, hd workspace ready. --- -# HD Setup Steps — what was done to prepare your workspace+# Hydrogen Setup Steps — what was done to prepare your workspace -This is the platform-generic, user-facing Q&A about what HD's setup did. The+This is the platform-generic, user-facing Q&A about what Hydrogen's setup did. The exact per-platform step list, the workspace-provisioning commands, and the state-file name live in the companion [[hydrogen-setup-steps-windows]] skill (for Windows/WSL2). -When you first launched Hydrogen (or after a virgin reset), HD ran an+When you first launched Hydrogen (or after a virgin reset), Hydrogen ran an install sequence to turn a blank machine into a fully-tooled Adom workspace. The heavy tooling (code-server, gallia, the Adom CLIs, the claude CLI + Code extension, VS Code settings, and all `hd-*` skills) is already BAKED into the golden image; setup just provisions that image, injects your Adom session, wires up the relay, and walks the Claude auth gate. This skill explains what each phase did so you can help the user understand their environment, re-run-failed steps, or wipe and rebuild. See `hd-golden-image` for the baked-image+failed steps, or wipe and rebuild. See `hydrogen-golden-image` for the baked-image model.  The cascade is halt-on-failure, resume-not-restart, with per-step 3x@@ -43,16 +43,16 @@ auto-retry. The exact steps and ordering are platform-specific — see | ensure-sse | GATE: confirm the editor browser SSE session is connected so Welcome's webview-open doesn't 409 | | verify-workspace | GATE: battery confirming the proxy holds a real layout | | welcome | Open Claude Code, authenticate if needed, send the first prompt |-| open-welcome | GATE (final): open welcome.html in HD's right pane; hard-fails if the Welcome tab doesn't appear |+| open-welcome | GATE (final): open welcome.html in Hydrogen's right pane; hard-fails if the Welcome tab doesn't appear |  ### Steps that NO LONGER EXIST (baked into the golden image)  These are NOT setup steps anymore — they are baked at image-build time:-`install-gallia`, `install-hd-skills`, `verify-adom-bridge-cli`,+`install-gallia`, `install-hydrogen-skills`, `verify-adom-bridge-cli`, `install-claude-cli`, `install-claude-ext`, `write-vscode-settings`, `set-trusted-domains`, `clean-layout`. If a user asks "what installed gallia / the Claude extension / my skills / VS Code settings", the answer is: **baked-into the golden image at build time, not a setup step.** See `hd-golden-image`.+into the golden image at build time, not a setup step.** See `hydrogen-golden-image`.  ## Common user questions @@ -60,7 +60,7 @@ into the golden image at build time, not a setup step.** See `hd-golden-image`. claude CLI, the Claude Code extension, VS Code settings, or an `hd-*` skill, it was **baked into the golden image** — not run as a setup step. The setup steps only provision the image, inject your session, wire the relay, and walk Claude-auth. The setup panel (HD UI → bottom) lists every step with its current+auth. The setup panel (Hydrogen UI → bottom) lists every step with its current status.  **"Setup failed at step N"** → The setup panel shows the error. Most common@@ -88,17 +88,17 @@ which artifacts to delete (option keys in parentheses): | Install step state (`install_state`) | Marks all steps as pending so they re-run | Always (default on) | | Workspace (`container`) | PRISTINE wipe + re-provision — deletes the workspace AND everything in it, including your project files | Always (default on); your work is GONE | | Image tarball (`tarball`, legacy `image`) | Deletes the cached golden image (full re-download) | Rarely — only if the image is corrupted |-| Webview storage (`webview_storage`) | Queued wipe, flushed at next HD launch (restart_required) | Rarely |-| VS Code state (`vscode_state`) | Queued wipe, flushed at next HD launch (restart_required) | Rarely |+| Webview storage (`webview_storage`) | Queued wipe, flushed at next Hydrogen launch (restart_required) | Rarely |+| VS Code state (`vscode_state`) | Queued wipe, flushed at next Hydrogen launch (restart_required) | Rarely | | Adom session token (`adom_token`) | Deletes `hydrogen-session.txt`; forces re-login | Rarely | | Claude credentials (`claude_token`) | Deletes the host-side Claude creds backup; forces Claude re-auth | When Claude auth is stuck |  `confirmed_destructive` must be set. After toggling, hit "Wipe Selected", then "Run All" to rebuild. The workspace reset backs up Claude creds first UNLESS `claude_token` is checked; the `webview_storage` / `vscode_state` wipes are-queued and flushed at the next HD launch (restart_required), not immediate.+queued and flushed at the next Hydrogen launch (restart_required), not immediate. -CRITICAL: the workspace reset ONLY ever wipes HD's own workspace. It never+CRITICAL: the workspace reset ONLY ever wipes Hydrogen's own workspace. It never touches other workspaces, distros, or runtimes the user may have on the machine, and it performs NO reboot for the wipe. The platform-specific wipe commands are in [[hydrogen-setup-steps-windows]].@@ -112,7 +112,7 @@ commands are in [[hydrogen-setup-steps-windows]]. | `POST /setup/panel/run-virgin-reset` | Trigger virgin reset with the supplied toggle options | | `POST /setup/panel/show` | Open the setup panel from anywhere | -All on HD's control API at `http://127.0.0.1:47084`.+All on Hydrogen's control API at `http://127.0.0.1:47084`.  **DEPRECATED — now REFUSED, do not use:** `POST /wsl/unregister`, `POST /setup/virgin-reset`, `POST /setup/run-all`, `POST /setup/run-step`. Use@@ -121,14 +121,14 @@ All on HD's control API at `http://127.0.0.1:47084`. ## Setup state file  Setup writes its state to a per-step state file (one entry per step with-`status: pending|running|done|failed`, output text, percent complete). HD reads+`status: pending|running|done|failed`, output text, percent complete). Hydrogen reads this on launch to decide whether the setup panel auto-opens. The exact file name and location are platform-specific — see [[hydrogen-setup-steps-windows]].  ## Related skills  - [[hydrogen-setup-steps-windows]] — the concrete WSL2 16-step cascade, the import step, `wsl --unregister`, `setup-steps-wsl.json`, and the golden tarball-- `hd-golden-image` — the baked-image model: what's pre-installed vs. what setup does+- `hydrogen-golden-image` — the baked-image model: what's pre-installed vs. what setup does - `hydrogen-setup` — the setup-panel UX and virgin-reset toggles-- `hd-browser-picker` — used by claude-auth for the Claude auth OAuth flow+- `hydrogen-browser-picker` — used by claude-auth for the Claude auth OAuth flow - `hydrogen-adom-auth` — how the Adom session token (inject-api-key) gets injected

@@ -1,7 +1,7 @@ --- name: hydrogen-setup description: >-  HD setup panel: the install-step cascade, Run All, Rollback All, Virgin Reset+  Hydrogen setup panel: the install-step cascade, Run All, Rollback All, Virgin Reset   with toggles, and automated testing patterns. MUST READ before running setup,   testing steps, or doing virgin resets. Covers the step list, the virgin   reset toggle panel, how to keep auth during resets, and how Run All handles@@ -11,27 +11,27 @@ description: >  # Hydrogen -- Setup Panel & Virgin Reset -This is the platform-generic reference for the HD setup panel and virgin+This is the platform-generic reference for the Hydrogen setup panel and virgin reset. The host-platform specifics (the exact install cascade on Windows/WSL2, distro import/unregister mechanics, the per-platform step list and state file) live in the companion [[hydrogen-setup-windows]] skill.  ## Zero-Click Goal -The HD setup process targets ZERO manual clicks for the user. The heavy+The Hydrogen setup process targets ZERO manual clicks for the user. The heavy lifting is already done at image-build time: the golden workspace image ships with code-server, gallia, the Adom CLIs, the claude CLI + Code extension, VS Code settings, and all `hd-*` skills BAKED IN. Setup just provisions that image, injects the user's session, wires up the relay, and walks the single-human auth gate. If something is missing, HD downloads it — never tell the-user to install something manually. See the `hd-golden-image` skill for the+human auth gate. If something is missing, Hydrogen downloads it — never tell the+user to install something manually. See the `hydrogen-golden-image` skill for the baked-image model.  ## The Install Steps  The setup cascade is a halt-on-failure, resume-not-restart sequence with per-step 3x auto-retry. State is tracked per-step (status pending / running /-done / failed, output text, percent complete) and HD reads it on launch to+done / failed, output text, percent complete) and Hydrogen reads it on launch to decide whether the setup panel auto-opens. The exact step list, ordering, and state-file name are platform-specific — see [[hydrogen-setup-windows]]. @@ -53,17 +53,17 @@ Conceptually the steps fall into these phases: 5. **Gates + payoff** — gate on adom-cli reachability (carbon +    hydrogen-proxy), walk the single Claude auth gate, confirm the editor SSE    session, verify the proxy holds a real layout, open Claude Code and send the-   first prompt, and finally open welcome.html in HD's right pane (hard-fails+   first prompt, and finally open welcome.html in Hydrogen's right pane (hard-fails    if the Welcome tab doesn't appear).  ### Steps that NO LONGER EXIST (baked into the golden image)  These are NOT setup steps anymore — they are baked at image-build time and-must not be listed or "run": `install-gallia`, `install-hd-skills`,+must not be listed or "run": `install-gallia`, `install-hydrogen-skills`, `verify-adom-bridge-cli`, `install-claude-cli`, `install-claude-ext`, `write-vscode-settings`, `set-trusted-domains`, `clean-layout`. gallia, the Adom CLIs, the claude CLI + Code extension, code-server, settings, and all-`hd-*` skills are baked into the golden image. See `hd-golden-image`.+`hd-*` skills are baked into the golden image. See `hydrogen-golden-image`.  ## Panel Buttons @@ -91,10 +91,10 @@ live status badge showing the current state. The ONLY programmatic trigger is | Toggle (option key) | What it wipes | Status badges | |---|---|---| | Install step state (`install_state`) | Resets all steps to pending | CLEAN / EXISTS |-| Workspace (`container`) | PRISTINE wipe + re-provision of the workspace (ONLY HD's own workspace) | GONE / RUNNING / EXISTS |+| Workspace (`container`) | PRISTINE wipe + re-provision of the workspace (ONLY Hydrogen's own workspace) | GONE / RUNNING / EXISTS | | Image tarball (`tarball`, legacy `image`) | Deletes the cached golden image (full re-download) | CACHED / GONE |-| Webview storage (`webview_storage`) | Queued wipe, flushed at next HD launch (restart_required) | CLEAN / EXISTS |-| VS Code state (`vscode_state`) | Queued wipe, flushed at next HD launch (restart_required) | CLEAN / EXISTS |+| Webview storage (`webview_storage`) | Queued wipe, flushed at next Hydrogen launch (restart_required) | CLEAN / EXISTS |+| VS Code state (`vscode_state`) | Queued wipe, flushed at next Hydrogen launch (restart_required) | CLEAN / EXISTS | | Adom session token (`adom_token`) | Deletes `hydrogen-session.txt` | CLEAN / EXISTS | | Claude credentials (`claude_token`) | Deletes the host-side Claude creds backup | CLEAN / EXISTS | @@ -103,10 +103,10 @@ Selected"** at the bottom executes the reset for all checked toggles.  The workspace reset is a PRISTINE wipe + re-provision — it backs up Claude creds first UNLESS `claude_token` is checked. The `webview_storage` /-`vscode_state` wipes are queued and flushed at the next HD launch+`vscode_state` wipes are queued and flushed at the next Hydrogen launch (restart_required), NOT immediate; there is no reboot for the wipe. -CRITICAL — the virgin reset only ever touches HD's OWN workspace. It NEVER+CRITICAL — the virgin reset only ever touches Hydrogen's OWN workspace. It NEVER touches other workspaces, distros, or runtimes the user may have on the machine. The platform-specific commands (and the never-touch-global rule) are in [[hydrogen-setup-windows]].@@ -176,12 +176,12 @@ via the native browser Browser Picker. Runs LAST before the payoff steps. `ensure-sse` confirms the editor browser SSE session is connected (so the Welcome webview-open doesn't 409); `verify-workspace` confirms the proxy holds a real layout; `welcome` opens Claude Code and sends the first prompt; the-final `open-welcome` gate opens welcome.html in HD's right pane and HARD-FAILS+final `open-welcome` gate opens welcome.html in Hydrogen's right pane and HARD-FAILS if the Welcome tab doesn't appear.  > Note: gallia, the Adom CLIs, the claude CLI + Code extension, VS Code > settings, and `hd-*` skills are NOT setup steps — they are baked into the-> golden image. See `hd-golden-image`.+> golden image. See `hydrogen-golden-image`.  ## Workspace Recreation 

@@ -1,22 +1,22 @@ --- name: hydrogen-ui description: >-  HD's user interface: menus, dialogs, panels, login/logout, profile menu,+  Hydrogen's user interface: menus, dialogs, panels, login/logout, profile menu,   workspace layout, setup panel — and how to DRIVE them from the workspace via   the UI command bus (GET /ui/actions → POST /ui/invoke), the first-class way to-  open/close/toggle any HD menu or dialog (no CDP clicking). READ when the user-  asks you to open/close a dialog or menu, operate HD's UI, or you need to know-  where a UI element is. Trigger words — HD menu, HD dialog, HD panel, open+  open/close/toggle any Hydrogen menu or dialog (no CDP clicking). READ when the user+  asks you to open/close a dialog or menu, operate Hydrogen's UI, or you need to know+  where a UI element is. Trigger words — Hydrogen menu, Hydrogen dialog, Hydrogen panel, open   dialog, open menu, close dialog, drive UI, ui/actions, ui/invoke, command bus,   ports.open, settings.open, about dialog, profile menu, login, logout, settings,-  setup panel, Adom menu, HD UI.+  setup panel, Adom menu, Hydrogen UI. ---  # Hydrogen — UI Reference  ## Window Layout -HD's window has these regions (top to bottom, left to right):+Hydrogen's window has these regions (top to bottom, left to right):  ### Title Bar - **Left**: "jlauer12 / Hydrogen" — shows user + app name@@ -47,11 +47,11 @@ The main menu, opened by clicking the Adom logo at the top-left. Items are group - **Ports...** — opens the port configuration dialog (see hydrogen-ports) - **API Explorer...** — opens the control-API endpoint explorer dialog -**DESKTOP** (Tauri-only — won't appear in browser-served HD; in order)+**DESKTOP** (Tauri-only — won't appear in browser-served Hydrogen; in order) - **Adom Bridge** — brings the embedded Adom Bridge window to the foreground (taskbar); bus id `adom-bridge-cli.open` - **Zoom** — webview zoom controls (− %  +) with persistence across launches - **Fullscreen** — toggle fullscreen-- **Console** — show/hide the HD debug console window+- **Console** — show/hide the Hydrogen debug console window - **Developer Tools** — open the webview developer tools - **Dev Toolbar** — show/hide the Adom Dev Toolbar window (eval-in / shot / Claude control endpoints); bus id `dev-toolbar.toggle` @@ -64,7 +64,7 @@ The main menu, opened by clicking the Adom logo at the top-left. Items are group **ADMIN** - **Setup Steps** — opens the setup panel (the setup cascade for the active runtime); see hydrogen-setup-steps - **Virgin Reset** — opens the virgin reset section of the setup panel; see hydrogen-volume for what each toggle deletes-- **Browser Picker Manager** — configure per-domain default browser/profile prefs; see hd-browser-picker+- **Browser Picker Manager** — configure per-domain default browser/profile prefs; see hydrogen-browser-picker  ### Profile Menu (top-right avatar) Click the user avatar (circular photo) in the top-right corner.@@ -95,17 +95,17 @@ Appears when clicking external links. Shows detected browser profiles  ## Driving the UI — the command bus (PREFERRED, first-class) -⭐ **Every menu / dialog / panel HD has wired is a first-class action you drive over the control-API — no CDP, no `.click()`, no selector guessing.** This is how you operate HD's UI when the+⭐ **Every menu / dialog / panel Hydrogen has wired is a first-class action you drive over the control+API — no CDP, no `.click()`, no selector guessing.** This is how you operate Hydrogen's UI when the user says "open the Ports dialog", "open About", "show settings", etc. -**Get the control URL from the discovery file** `~/.adom/hd-control-url` (HD rewrites it with+**Get the control URL from the discovery file** `~/.adom/hydrogen-control-url` (Hydrogen rewrites it with the live, dynamic control port every launch; it's the host loopback, reachable from the workspace). Read it from a file, not an env var — your Bash tool runs non-interactive shells that don't source `.bashrc`/`profile.d`:  ```bash-CTRL="$(cat ~/.adom/hd-control-url)"+CTRL="$(cat ~/.adom/hydrogen-control-url)" ```  **Always do this in order:**@@ -147,7 +147,7 @@ item-level treatment over time. > `setup-panel.hide` action is on the wishlist.  ### Open a surface, then screenshot it (the killer combo)-Combine the bus with HD's canonical capture endpoint to grab any menu/dialog/panel with+Combine the bus with Hydrogen's canonical capture endpoint to grab any menu/dialog/panel with **no screen-clicking**: `POST /ui/invoke {id:"<x>.open"}` → `POST /screenshot {target:"shell", selector:"<open-state selector>"}` → `POST /ui/invoke {id:"<x>.close"}`. The `/screenshot` region-flash lands on that selector. Resolved selectors (verified live):@@ -155,14 +155,14 @@ The `/screenshot` region-flash lands on that selector. Resolved selectors (verif `.setup-panel`; **API Explorer** → `.dialog`. Full `/screenshot` reference (target/selector/ b64/silent) is in **[hydrogen-self-screenshot](../hydrogen-self-screenshot/SKILL.md)**. -> **This is HD-desktop-only and SEPARATE from `adom-cli`.** `adom-cli` drives *web-hydrogen's*-> UI via the SSE bridge (`ADOM_HYDROGEN_URL`) and is unchanged. For HD desktop's far richer UI+> **This is Hydrogen-desktop-only and SEPARATE from `adom-cli`.** `adom-cli` drives *web-hydrogen's*+> UI via the SSE bridge (`ADOM_HYDROGEN_URL`) and is unchanged. For Hydrogen desktop's far richer UI > control, use the command bus above — never `adom-cli` for this.  ## Legacy: raw CDP clicking (deprecated fallback — the command bus above is canonical) -⚠ The command bus (`/ui/actions` → `/ui/invoke`) is the canonical way to drive HD's UI. Before-it existed, UI was driven by CDP `.click()` on CSS selectors via the HD CDP eval channel. This+⚠ The command bus (`/ui/actions` → `/ui/invoke`) is the canonical way to drive Hydrogen's UI. Before+it existed, UI was driven by CDP `.click()` on CSS selectors via the Hydrogen CDP eval channel. This is brittle (selectors drift; multiple `localhost:1420` CDP targets) and the selectors below may be stale. Reach for CDP ONLY for an element not yet on the bus — and the better fix is to register it. Eval JS against the CDP endpoint (its port comes from `/discover` as `cdp`).