bootstrap
Adom Hydrogen (Windows / WSL2)
Public Made by Adomby adom
The Windows (WSL2) platform layer for Hydrogen.
← Commit history
Publish 0.3.18
23 files changed
+173−180
package.json+1−1page.json+1−1skills/hydrogen-api/SKILL.md+2−2skills/hydrogen-bridges/SKILL.md+54−54skills/hydrogen-container-stats/SKILL.md+1−1skills/hydrogen-container-windows/SKILL.md+1−1skills/hydrogen-container/SKILL.md+26−27skills/hydrogen-demo-recording/SKILL.md+4−4skills/hydrogen-desktop-sse/SKILL.md+2−2skills/hydrogen-eda-discovery-windows/SKILL.md+2−2skills/hydrogen-embedded-bridge/SKILL.md+4−4skills/hydrogen-file-transfer/SKILL.md+7−7skills/hydrogen-networking/SKILL.md+5−5skills/hydrogen-notifications/SKILL.md+4−4skills/hydrogen-open-url/SKILL.md+2−2skills/hydrogen-ports/SKILL.md+10−10skills/hydrogen-recording/SKILL.md+14−14skills/hydrogen-screen-lock/SKILL.md+1−1skills/hydrogen-setup-steps/SKILL.md+6−9skills/hydrogen-setup/SKILL.md+3−6skills/hydrogen-topology/SKILL.md+18−18skills/hydrogen-ui/SKILL.md+2−2skills/hydrogen-volume/SKILL.md+3−3package.json+1−1@@ -4,7 +4,7 @@ "type": "bootstrap", "title": "Adom Hydrogen (Windows / WSL2)", "brief": "The Windows (WSL2) platform layer for Hydrogen.",- "version": "0.3.17",+ "version": "0.3.18", "description": "The Windows platform layer for Hydrogen, where the workspace runs in a WSL2 Ubuntu distro. Depends on adom/hydrogen-bootstrap (the platform-generic layer, which bundles the generic hydrogen-* skills) and adds everything specific to the WSL2 runtime: the WSL2/networking/lifecycle hydrogen-* skills (BUNDLED here by design, John+Kyle 2026-07-16) and the WSL2 code-server workbench seed. Sibling adom/hydrogen-mac-bootstrap carries the parallel mac skills. This is the package the golden WSL2 image installs.", "org": "adom", "tags": [
page.json+1−1@@ -4,7 +4,7 @@ "slug": "hydrogen-windows-bootstrap", "title": "Adom Hydrogen (Windows / WSL2)", "brief": "The Windows (WSL2) platform layer for Hydrogen.",- "version": "0.3.17",+ "version": "0.3.18", "author": { "name": "John Lauer", "email": "[email protected]"
skills/hydrogen-api/SKILL.md+2−2@@ -110,7 +110,7 @@ which is unchanged for web-hydrogen parity. (typed injection) can outlive the relay timeout: the work still completes on Hydrogen's side, so verify state instead of re-firing. - **Getting files OUT (recordings, screenshots): streamed binary, never base64.** Endpoints- return paths inside the WSL distro; a remote container pulls them with `adom-bridge-cli+ return paths inside the WSL distro; a remote container pulls them with `adom-bridge --target <desktop> pull_file {filePaths:["\\\\wsl$\\Adom-Workspace\\<path>"], saveTo:...}` (1 MiB binary chunks, sha256-verified, no practical size limit). `/recording/native/stop` returns the ready-made `fileWindows` UNC path. Full demo-video pipeline: the@@ -140,7 +140,7 @@ which is unchanged for web-hydrogen parity. (Canonical since 1.0.47; the old `/ad/*` spellings still answer as aliases.) -These verify the **adom-bridge-cli / relay / embedded-ab** half of Hydrogen is alive (the+These verify the **adom-bridge / 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 |
skills/hydrogen-bridges/SKILL.md+54−54@@ -3,7 +3,7 @@ name: hydrogen-bridges description: > 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+ and the full set of Adom Bridge capabilities. How they connect through adom-bridge, the Bridge Manager dialog, bridge status polling, and all bridge CLI commands. Use when the AI needs to take screenshots, control KiCad/Fusion/browser, transfer files, interact with the user's desktop, or check bridge status. Trigger words --@@ -31,7 +31,7 @@ ecosystem, not a fixed list — new bridges ship via the wiki catalog (see | `fusion-bridge` | Fusion 360 Bridge | 8773 | Fusion 360 | Control Fusion 360 CAD/CAM and EAGLE PCB | | `puppeteer-bridge` | Puppeteer Bridge | 8851 | Chrome for Testing | Chrome automation, screenshots, and recording | -**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.+**Bridge ports have conventional defaults** (KiCad **8771**, Fusion **8773**, Pup **8851**), but adom-bridge 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 status` and look at `desktop.apps.<bridge>.bridgePort` (or `adom-bridge bridge_list`). In practice you don't need the port directly — use the `adom-bridge <verb>` CLI which routes to the right bridge automatically. 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')`.@@ -41,7 +41,7 @@ Manager polls status every 15 seconds via Tauri `invoke('get_bridge_status')`. Bridges are only part of ab. Query the **authoritative, machine-specific** list: ```bash-adom-bridge-cli status # → .capabilities and .desktop.apps+adom-bridge status # → .capabilities and .desktop.apps ``` On a typical machine `.capabilities` =@@ -55,7 +55,7 @@ Mapping to where each is documented: | `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 |+| `usb` | USB passthrough to the workspace (e.g. workcell hardware over USBIP) | not yet covered — query `adom-bridge status`; future skill | > `.desktop.apps` also reports, per app: `bridgeRunning`, `installed`, `running`, > `version` — use it to check whether the target app (KiCad/Fusion/Chrome) is@@ -77,7 +77,7 @@ interface BridgeInfo { display_name: string // e.g. "KiCad Bridge" version: string // e.g. "1.0.0" description: string- port: number // conventional default; live port via `adom-bridge-cli status`+ port: number // conventional default; live port via `adom-bridge status` status: 'running' | 'stopped' | 'not_installed' app_detected: boolean // true if target app (KiCad, Fusion, Chrome) is found app_name: string // e.g. "KiCad"@@ -106,7 +106,7 @@ each bridge's status. Auto-refreshes every 15 seconds. > the dialog shows an install link — but the AI doesn't have to stop there. For > KiCad and Node.js you can trigger an **unattended install** instead of > asking the user to download:-> `adom-bridge-cli desktop_install_kicad '{}'` / `adom-bridge-cli desktop_install_node '{}'`.+> `adom-bridge desktop_install_kicad '{}'` / `adom-bridge desktop_install_node '{}'`. > (The install mechanism is platform-specific; the verb reports if unsupported. > Fusion 360 cannot be installed programmatically — surface the link for that.) @@ -159,7 +159,7 @@ setTimeout(function() { ## Prerequisites -Check connection: `adom-bridge-cli ping` -- returns "pong" if Hydrogen is connected.+Check connection: `adom-bridge ping` -- returns "pong" if Hydrogen is connected. If not connected, the user needs to launch Hydrogen on their machine. ---@@ -168,16 +168,16 @@ If not connected, the user needs to launch Hydrogen on their machine. ```bash # Full screen capture-adom-bridge-cli desktop_screenshot_screen+adom-bridge desktop_screenshot_screen # Resized for Claude vision (default to this)-adom-bridge-cli desktop_screenshot_screen '{"maxWidth": 1500}'+adom-bridge desktop_screenshot_screen '{"maxWidth": 1500}' # Specific window by HWND-adom-bridge-cli desktop_screenshot_window '{"hwnd": 12345}'+adom-bridge desktop_screenshot_window '{"hwnd": 12345}' # List all capturable windows-adom-bridge-cli desktop_list_windows+adom-bridge desktop_list_windows ``` **AI guidance:**@@ -190,46 +190,46 @@ adom-bridge-cli desktop_list_windows ## Browser Automation (Puppeteer Bridge) -Port: default **8851** (adom-bridge-cli registers the live port; see `adom-bridge-cli status`). Auto-downloads Chrome for Testing if not present.+Port: default **8851** (adom-bridge registers the live port; see `adom-bridge status`). Auto-downloads Chrome for Testing if not present. ```bash # Open browser window-adom-bridge-cli browser_open_window '{"url": "https://example.com"}'+adom-bridge browser_open_window '{"url": "https://example.com"}' # Screenshot current tab-adom-bridge-cli browser_screenshot '{"sessionId": "default"}'+adom-bridge browser_screenshot '{"sessionId": "default"}' # Evaluate JavaScript-adom-bridge-cli browser_eval '{"js": "document.title", "sessionId": "default"}'+adom-bridge browser_eval '{"js": "document.title", "sessionId": "default"}' # Navigate-adom-bridge-cli browser_navigate '{"url": "https://...", "sessionId": "default"}'+adom-bridge browser_navigate '{"url": "https://...", "sessionId": "default"}' # List open windows/tabs-adom-bridge-cli browser_list_windows+adom-bridge browser_list_windows # Record tab (CDP screencast, zero dialogs)-adom-bridge-cli browser_record_start '{"sessionId": "default"}'-adom-bridge-cli browser_record_stop '{"sessionId": "default"}'+adom-bridge browser_record_start '{"sessionId": "default"}'+adom-bridge browser_record_stop '{"sessionId": "default"}' ``` --- ## KiCad Bridge -Port: default **8771** (adom-bridge-cli registers the live port; see `adom-bridge-cli status`). Requires KiCad to be installed on the user's machine.+Port: default **8771** (adom-bridge registers the live port; see `adom-bridge status`). Requires KiCad to be installed on the user's machine. ```bash-adom-bridge-cli kicad_open_board '{"path": "<host path to board.kicad_pcb>"}'-adom-bridge-cli kicad_open_schematic '{"path": "<host path to schematic.kicad_sch>"}'-adom-bridge-cli kicad_open_3d_viewer-adom-bridge-cli kicad_run_drc '{"path": "..."}'-adom-bridge-cli kicad_screenshot_all-adom-bridge-cli kicad_window_info-adom-bridge-cli kicad_send_key '{"key": "ctrl+s"}'-adom-bridge-cli kicad_list_versions-adom-bridge-cli kicad_install_symbol '{"path": "/tmp/symbol.kicad_sym", "library": "MyLib"}'-adom-bridge-cli kicad_install_library '{"path": "/tmp/footprints", "name": "MyFootprints"}'+adom-bridge kicad_open_board '{"path": "<host path to board.kicad_pcb>"}'+adom-bridge kicad_open_schematic '{"path": "<host path to schematic.kicad_sch>"}'+adom-bridge kicad_open_3d_viewer+adom-bridge kicad_run_drc '{"path": "..."}'+adom-bridge kicad_screenshot_all+adom-bridge kicad_window_info+adom-bridge kicad_send_key '{"key": "ctrl+s"}'+adom-bridge kicad_list_versions+adom-bridge kicad_install_symbol '{"path": "/tmp/symbol.kicad_sym", "library": "MyLib"}'+adom-bridge kicad_install_library '{"path": "/tmp/footprints", "name": "MyFootprints"}' ``` **Always run `kicad_window_info` BEFORE any KiCad operation** to check for modal dialogs —@@ -241,12 +241,12 @@ you detect a KiCad error/blocking dialog** (a save-permission error, a file-form DRC blocker). Each entry is `{hwnd, ownerHwnd, title}` (e.g. `title:"Error"`): ```bash-adom-bridge-cli kicad_window_info '{}'+adom-bridge kicad_window_info '{}' # → { editors:[...], hasModalDialogs:true, # modalDialogs:[{ "hwnd":200934, "ownerHwnd":6163368, "title":"Error" }], projectManager:{...} } ``` - ⚠️ `modalDialogs` gives the **title + hwnd, NOT the body text**. To read *what the error says*,- **screenshot the dialog by its hwnd**: `adom-bridge-cli desktop_screenshot_window '{"hwnd":200934}'`+ **screenshot the dialog by its hwnd**: `adom-bridge desktop_screenshot_window '{"hwnd":200934}'` → read the saved PNG. (Verified live 2026-06-15: a `ctrl+s` on a read-only board surfaced `hasModalDialogs:true` + a `title:"Error"` entry; screenshotting its hwnd read *"Insufficient permissions to save file …"*.)@@ -260,14 +260,14 @@ adom-bridge-cli kicad_window_info '{}' ## Fusion 360 Bridge -Port: default **8773** (adom-bridge-cli registers the live port; see `adom-bridge-cli status`). Requires Fusion 360 to be installed on the user's machine.+Port: default **8773** (adom-bridge registers the live port; see `adom-bridge status`). Requires Fusion 360 to be installed on the user's machine. ```bash-adom-bridge-cli fusion_start-adom-bridge-cli fusion_import_step '{"path": "<host path to model.step>"}'-adom-bridge-cli fusion_export_step '{"path": "<host path to output.step>"}'-adom-bridge-cli fusion_board_info-adom-bridge-cli fusion_electron_run '{"command": "..."}'+adom-bridge fusion_start+adom-bridge fusion_import_step '{"path": "<host path to model.step>"}'+adom-bridge fusion_export_step '{"path": "<host path to output.step>"}'+adom-bridge fusion_board_info+adom-bridge fusion_electron_run '{"command": "..."}' ``` ---@@ -277,21 +277,21 @@ adom-bridge-cli fusion_electron_run '{"command": "..."}' Bridges are a growing ecosystem. The three above (KiCad / Fusion 360 / Puppeteer) are **built into Adom Bridge**. Additional bridges are published to the **wiki 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+(`adom-blender-bridge`), which is NOT built in (it won't appear in `adom-bridge status` until installed). To use a catalog 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+- **Enumerate what's actually live:** `adom-bridge status` → `desktop.apps.*` lists 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.-- **Invoke any bridge** through the `adom-bridge-cli <verb>` CLI; it routes to the+- **Invoke any bridge** through the `adom-bridge <verb>` CLI; it routes to the right bridge automatically (you rarely need the port directly). > Maintainer note: keep this skill in sync by periodically running-> `adom-bridge-cli status` against a fully-bridged machine and reconciling the table.+> `adom-bridge status` against a fully-bridged machine and reconciling the table. --- @@ -299,10 +299,10 @@ status` until installed). To use a catalog bridge: ```bash # Send file from Docker to the desktop-adom-bridge-cli send_files '{"files": [{"path": "/home/adom/project/output.pdf"}]}'+adom-bridge send_files '{"files": [{"path": "/home/adom/project/output.pdf"}]}' # Pull file from the desktop to Docker (remotePath uses the host's native path convention)-adom-bridge-cli pull_file '{"remotePath": "<host path to data.csv>", "localPath": "/tmp/data.csv"}'+adom-bridge pull_file '{"remotePath": "<host path to data.csv>", "localPath": "/tmp/data.csv"}' ``` ---@@ -311,16 +311,16 @@ adom-bridge-cli pull_file '{"remotePath": "<host path to data.csv>", "localPath" ```bash # Toast notification-adom-bridge-cli notify_user '{"message": "Build complete!", "duration_ms": 5000}'+adom-bridge notify_user '{"message": "Build complete!", "duration_ms": 5000}' # Open URL in user's browser-adom-bridge-cli desktop_open_url '{"url": "https://..."}'+adom-bridge desktop_open_url '{"url": "https://..."}' # Open folder in the OS file manager-adom-bridge-cli desktop_open_folder '{"path": "<host folder path>"}'+adom-bridge desktop_open_folder '{"path": "<host folder path>"}' # Execute shell command in the host's native shell (requires user approval)-adom-bridge-cli shell_execute '{"command": "<host shell command>"}'+adom-bridge shell_execute '{"command": "<host shell command>"}' ``` ---@@ -330,7 +330,7 @@ adom-bridge-cli shell_execute '{"command": "<host shell command>"}' > **Served by the embedded ab process, NOT Hydrogen's built-in bridge.** The > `desktop_record_*` / `desktop_recorder_*` verbs only exist when the standalone > ab (spawned `--embedded`) is connected. Verify before using:-> `adom-bridge-cli status` → `.capabilities` must include `record`. If it's absent,+> `adom-bridge status` → `.capabilities` must include `record`. If it's absent, > only Hydrogen's built-in bridge is up and these verbs return "unknown desktop > command". See **hydrogen-recording** for full details. @@ -342,12 +342,12 @@ adom-bridge-cli shell_execute '{"command": "<host shell command>"}' ```bash # 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+adom-bridge desktop_record_start '{"reason": "Demo recording", "confirmDesktopNotTabRecording": true}'+adom-bridge desktop_record_stop # Record a single browser tab (CDP screencast, zero dialogs) — prefer this for one tab-adom-bridge-cli browser_record_start '{"sessionId": "default"}'-adom-bridge-cli browser_record_stop '{"sessionId": "default"}'+adom-bridge browser_record_start '{"sessionId": "default"}'+adom-bridge browser_record_stop '{"sessionId": "default"}' ``` ---@@ -356,7 +356,7 @@ adom-bridge-cli browser_record_stop '{"sessionId": "default"}' ```bash # 1. Take screenshot-adom-bridge-cli desktop_screenshot_screen '{"maxWidth": 1500}'+adom-bridge desktop_screenshot_screen '{"maxWidth": 1500}' # 2. Read the screenshot (it's saved to /screenshots/) # 3. Analyze with Claude vision # 4. Make changes
skills/hydrogen-container-stats/SKILL.md+1−1@@ -122,7 +122,7 @@ Or if the workspace is in a broken state: **"Why is CPU showing 200% / 1600%?"** It's not — the displayed % is capped at 100 for the bar fill, but the tooltip shows the real number. CPU of `100% of 16 cores` means 1 full vCPU pegged. -**"Why does RAM stay constant at ~4% even when I'm doing nothing?"** Code-server, the relay, gallia, the adom-vscode HTTP API, etc. all run in the workspace all the time. ~700 MB baseline is normal.+**"Why does RAM stay constant at ~4% even when I'm doing nothing?"** Code-server, the relay, the adom-vscode HTTP API, etc. all run in the workspace all the time. ~700 MB baseline is normal. **"The 'restart needed' badge appeared — what happened?"** Almost always a hiccup after the host woke from sleep/hibernate, leaving the workspace or code-server unreachable. Click Restart Workspace in the Adom menu (top-left); Hydrogen restarts the workspace, re-ensures code-server, and the badge clears.
skills/hydrogen-container-windows/SKILL.md+1−1@@ -56,7 +56,7 @@ KiCad/Fusion/file-transfer bridge commands that reference host files use **Windo ## Golden-image specifics -The distro is imported from a full pre-baked image — gallia, the Adom CLIs, the claude CLI + Code extension, code-server (pinned), VS Code settings, and all `hd-*` skills are baked in at image-build time, NOT installed by setup steps.+The distro is imported from a full pre-baked image, then the update-packages step installs the Adom CLIs and skills from the wiki registry (adom/hydrogen-windows-bootstrap); the image itself carries the claude CLI + Code extension, code-server (pinned), VS Code settings, and all `hd-*` skills are baked in at image-build time, NOT installed by setup steps. ## Related skills
skills/hydrogen-container/SKILL.md+26−27@@ -27,13 +27,13 @@ You are running inside the **local workspace** managed by Hydrogen (ah). Hydroge If you ever need to confirm: `cat /etc/os-release`, `uname -m`, `/usr/lib/code-server/bin/code-server --version`. Don't speculate about alpine/arm64 — Ubuntu 24.04 matches the cloud container. -## Setup is via Hydrogen's setup-steps, NOT gallia bootstrap.sh+## Setup is via Hydrogen's setup-steps, NOT a bootstrap script -Hydrogen provisions this workspace through its own **setup-steps** flow, shown as the "Install Tools" panel in the Hydrogen UI. It is a **different code path** than cloud containers, which run `gallia/scripts/bootstrap.sh`.+Hydrogen provisions this workspace through its own **setup-steps** flow, shown as the "Install Tools" panel in the Hydrogen UI. It is a **different code path** than cloud containers, which are provisioned by the Adom platform's own container bootstrap. -Most tooling is NOT installed by a step — it's BAKED into the golden image at image-build time (gallia, the Adom CLIs, the claude CLI + Code extension, code-server, VS Code settings, and all `hd-*` skills). The provisioning step imports the golden image if the workspace isn't already registered, and the relay is started by the `start-relay` step. See `[[hydrogen-setup-steps]]`.+Most tooling is NOT installed by a step — it's BAKED into the golden image at image-build time (the Adom CLIs and skills from the wiki registry package adom/hydrogen-windows-bootstrap, the claude CLI + Code extension, code-server, VS Code settings, and all `hd-*` skills). The provisioning step imports the golden image if the workspace isn't already registered, and the relay is started by the `start-relay` step. See `[[hydrogen-setup-steps]]`. -When debugging install issues here, the source of truth is Hydrogen's setup-steps code — its step IDs (`ensure-workspace`, `install-adom-vscode`, `set-env-vars`, `inject-api-key`, `start-relay`, `claude-auth`, etc.) map 1:1 to what ran on this workspace. There is NO `install-claude-ext` / `install-claude-cli` / `install-gallia` / `write-vscode-settings` step — those are baked. Do NOT chase bugs into `bootstrap.sh` — that script lives in the baked image but Hydrogen itself never invokes it.+When debugging install issues here, the source of truth is Hydrogen's setup-steps code — its step IDs (`wait-codeserver`, `update-packages`, `activate-editor`, `set-env-vars`, `inject-api-key`, `configure-vscode`, `ensure-adom-bridge-cli`, `install-brand-fonts`, `start-relay`, `test-direct-connect`, `test-relay`, `test-adom-cli`, `install-claude-cli`, `claude-auth`, `ensure-sse`, `verify-workspace`, `welcome`, `verify-setup`, `open-welcome`) map 1:1 to what ran on this workspace. There is no `install-the Adom CLIs`, `install-claude-ext` or `write-vscode-settings` step: that work is baked into the image or done by `update-packages` and `configure-vscode`. There is no bootstrap.sh to chase bugs into. ## VS Code extension caveats @@ -51,10 +51,10 @@ If this returns user data, all adom-cli commands work (containers, repos, orgs, ## Relay server is running -The adom-bridge-cli relay runs on ports 8765 (WebSocket) / 8766 (HTTP) inside this workspace. The `start-relay` setup step launches it.+The adom-bridge relay runs on ports 8765 (WebSocket) / 8766 (HTTP) inside this workspace. The `start-relay` setup step launches it. Check health: `curl -sf http://127.0.0.1:8766/health`-Check desktop connection: `adom-bridge-cli ping`+Check desktop connection: `adom-bridge ping` The host control API is reachable from inside the workspace at `127.0.0.1`. The port is dynamic per launch, so read the live URL from `~/.adom/hydrogen-control-url` (`http://127.0.0.1:<dynamic>`): `BASE="$(cat ~/.adom/hydrogen-control-url)"; curl "$BASE/health"`. @@ -62,48 +62,48 @@ The host control API is reachable from inside the workspace at `127.0.0.1`. The ### Screenshots (zero dialogs, instant) ```bash-adom-bridge-cli desktop_screenshot_screen # full screen capture-adom-bridge-cli desktop_screenshot_screen '{"maxWidth":1500}' # resized for Claude vision-adom-bridge-cli desktop_screenshot_window '{"hwnd": N}' # capture specific window-adom-bridge-cli desktop_list_windows # list all windows with handles+adom-bridge desktop_screenshot_screen # full screen capture+adom-bridge desktop_screenshot_screen '{"maxWidth":1500}' # resized for Claude vision+adom-bridge desktop_screenshot_window '{"hwnd": N}' # capture specific window+adom-bridge desktop_list_windows # list all windows with handles ``` Default to `maxWidth: 1500, format: "png"` for UI screenshots. Use `"jpeg"` for natural photos, `"webp"` for smaller files. ### Browser automation (Puppeteer) ```bash-adom-bridge-cli browser_open_window '{"url": "https://..."}'-adom-bridge-cli browser_screenshot '{"sessionId": "default"}'-adom-bridge-cli browser_eval '{"js": "document.title"}'-adom-bridge-cli browser_navigate '{"url": "..."}'+adom-bridge browser_open_window '{"url": "https://..."}'+adom-bridge browser_screenshot '{"sessionId": "default"}'+adom-bridge browser_eval '{"js": "document.title"}'+adom-bridge browser_navigate '{"url": "..."}' ``` ### KiCad bridge ```bash-adom-bridge-cli kicad_open_board '{"path": "/path/to/board.kicad_pcb"}'-adom-bridge-cli kicad_screenshot_all-adom-bridge-cli kicad_run_drc '{"path": "..."}'-adom-bridge-cli kicad_window_info+adom-bridge kicad_open_board '{"path": "/path/to/board.kicad_pcb"}'+adom-bridge kicad_screenshot_all+adom-bridge kicad_run_drc '{"path": "..."}'+adom-bridge kicad_window_info ``` (Paths to host files use the host's native path convention.) ### Fusion 360 bridge ```bash-adom-bridge-cli fusion_start-adom-bridge-cli fusion_import_step '{"path": "..."}'-adom-bridge-cli fusion_export_step '{"path": "..."}'+adom-bridge fusion_start+adom-bridge fusion_import_step '{"path": "..."}'+adom-bridge fusion_export_step '{"path": "..."}' ``` ### File transfer ```bash-adom-bridge-cli send_files '{"files": [{"path": "/home/adom/file.txt"}]}'-adom-bridge-cli pull_file '{"remotePath": "<host path>", "localPath": "/tmp/file.txt"}'+adom-bridge send_files '{"files": [{"path": "/home/adom/file.txt"}]}'+adom-bridge pull_file '{"remotePath": "<host path>", "localPath": "/tmp/file.txt"}' ``` ### Desktop interaction ```bash-adom-bridge-cli notify_user '{"message": "Build complete", "duration_ms": 3000}'-adom-bridge-cli desktop_open_url '{"url": "https://..."}'-adom-bridge-cli desktop_open_folder '{"path": "<host folder path>"}'+adom-bridge notify_user '{"message": "Build complete", "duration_ms": 3000}'+adom-bridge desktop_open_url '{"url": "https://..."}'+adom-bridge desktop_open_folder '{"path": "<host folder path>"}' ``` ## What's different from Adom cloud containers@@ -120,7 +120,6 @@ adom-bridge-cli desktop_open_folder '{"path": "<host folder path>"}' ## Environment variables - `ADOM_DESKTOP_MODE=local` — indicates Hydrogen local mode-- `GALLIA_SERVICE=local` — tells gallia this is a local workspace - `VSCODE_PROXY_URI=http://localhost:7380/proxy/{{port}}/` — code-server's proxy (Platform layers may set additional host-specific env vars — see your platform bootstrap's version of this skill.)
skills/hydrogen-demo-recording/SKILL.md+4−4@@ -6,7 +6,7 @@ description: > output, then speed the footage 10x to 30x in video-post and lay an adom-tts voiceover on top, so a viewer sees exactly what using an app in Hydrogen feels like. Covers the whole pipeline end to end: driving Hydrogen's control API (in-workspace OR from a remote container- via adom-bridge-cli hd_api), the high-fps native recorder, multi-tab multi-prompt demos,+ via adom-bridge hd_api), the high-fps native recorder, multi-tab multi-prompt demos, getting the mp4 out (streamed binary, never base64), and the post-production handoff. Trigger words: demo video, record a demo, ah demo, demo recording, record the typing, screen record ah, record ai prompt, app demo, demo pipeline, speedup demo, tts overlay@@ -40,12 +40,12 @@ CTRL=$(cat ~/.adom/hydrogen-control-url) curl -s -X POST "$CTRL/claude/inject" -H 'Content-Type: application/json' -d '{...}' ``` -**From a remote container** (hw, cloud): go through the adom-bridge-cli relay's+**From a remote container** (hw, cloud): go through the adom-bridge relay's pass-through verb. Never curl through the relay (quoting gets mangled) and never hunt for the port (hd_api auto-discovers it): ```bash-adom-bridge-cli hd_api '{"method":"POST","path":"/claude/inject","body":{...}}'+adom-bridge hd_api '{"method":"POST","path":"/claude/inject","body":{...}}' ``` `hd_*` verbs auto-route to the desktop running Hydrogen; `desktop_*` and `pull_file` need@@ -131,7 +131,7 @@ and you lose the stop response, `GET /recording/native/status` when idle returns Never base64 an mp4 through an exec channel: ```bash-adom-bridge-cli --target <desktop> pull_file '{"filePaths":["<fileWindows value>"],"saveTo":"<dir>"}'+adom-bridge --target <desktop> pull_file '{"filePaths":["<fileWindows value>"],"saveTo":"<dir>"}' ``` ## Step 5: post-production
skills/hydrogen-desktop-sse/SKILL.md+2−2@@ -133,7 +133,7 @@ adom-cli hydrogen workspace move-tab \ --to-panel-id desktop-pane-left # 5. Screenshot to verify-adom-bridge-cli hd_screenshot+adom-bridge hd_screenshot ``` ## What Broke and Why@@ -194,7 +194,7 @@ Returns: | Client | What it discovers | How | |---|---|---|-| adom-bridge-cli relay | Control API port (was hardcoded 9001) | `curl :47080/discover` → use `control` field |+| adom-bridge relay | Control API port (was hardcoded 9001) | `curl :47080/discover` → use `control` field | | adom-cli in the workspace (the WSL2 distro) | 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 Hydrogen ports | `curl http://<desktop-ip>:47080/discover` via relay |
skills/hydrogen-eda-discovery-windows/SKILL.md+2−2@@ -4,7 +4,7 @@ description: > Windows companion to hydrogen-eda-discovery: the ready-to-run probe for detecting EDA tools that have NO bridge (Altium, OrCAD, Cadence/Allegro, EAGLE, DipTrace, Eplan) on a Windows host via install-path scans and process listing through- adom-bridge-cli run_script. The generic discovery playbook (branching, the+ adom-bridge run_script. The generic discovery playbook (branching, the community pitch, etiquette) lives in hydrogen-eda-discovery. Trigger words: detect altium windows, detect orcad windows, program files scan, eda probe windows, no-bridge eda detection, powershell eda probe.@@ -35,7 +35,7 @@ Get-Process -ErrorAction SilentlyContinue | ForEach-Object { "RUNNING: $($_.ProcessName)" } | Select-Object -Unique PS )-adom-bridge-cli run_script "{\"interpreter\":\"powershell\",\"scriptB64\":\"$SCRIPT\"}"+adom-bridge run_script "{\"interpreter\":\"powershell\",\"scriptB64\":\"$SCRIPT\"}" ``` Notes:
skills/hydrogen-embedded-bridge/SKILL.md+4−4@@ -18,7 +18,7 @@ How ab launches when nobody owns it: - Main window opens on launch (unless `--start-hidden`) - Autostart shortcut in `%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\AdomDesktop.lnk` → launches on every boot - Registered in Add/Remove Programs (HKLM `Uninstall\AdomDesktop`)-- Auto-update polls `wiki.adom.inc/api/v1/pages/adom-bridge-cli/files/version.json` every 4h+- Auto-update polls `wiki.adom.inc/api/v1/pages/adom-bridge/files/version.json` every 4h - Footer shows the user's email + a "Sign in" / "Sign out" link This is what ab looked like before Hydrogen existed and what it reverts to when Hydrogen vanishes.@@ -102,7 +102,7 @@ Both transitions emit a `mode-changed` event so the frontend can update the foot Expected. Hydrogen's installer deleted ab's autostart shortcut, so ab doesn't launch on boot. ab only runs when Hydrogen spawns it. Hydrogen's tray includes ab's menu items. -To verify: `tasklist | findstr adom-bridge-cli`. If ab's running, it's just hidden (per embedded mode). If not running, Hydrogen isn't either.+To verify: `tasklist | findstr adom-bridge`. If ab's running, it's just hidden (per embedded mode). If not running, Hydrogen isn't either. ### "I want ab standalone — how do I unembed?" @@ -134,8 +134,8 @@ Port discovery order: `%USERPROFILE%\.adom\direct-api-port` (single line `host:p ## Source-of-truth references -- ab's mode detection: `adom-bridge-cli/src-tauri/src/embedded.rs:detect_embedded_mode()`+- ab's mode detection: `adom-bridge/src-tauri/src/embedded.rs:detect_embedded_mode()` - Hydrogen's ab spawn: `hydrogen-desktop/src-tauri/crates/hydrogen-app/src/ad_supervisor.rs:spawn_ad_embedded()` - Hydrogen's tray menu: `hydrogen-desktop/src-tauri/crates/hydrogen-app/src/tray.rs:install_tray()` - Hydrogen's NSIS hook (embed-ab on install / offer-uninstall): `hydrogen-desktop/src-tauri/crates/hydrogen-app/installer/hydrogen-install.nsh.template`-- ab's release manifest (what Hydrogen reads at install time to find the latest ab): `wiki.adom.inc/api/v1/pages/adom-bridge-cli/files/version.json`+- ab's release manifest (what Hydrogen reads at install time to find the latest ab): `wiki.adom.inc/api/v1/pages/adom-bridge/files/version.json`
skills/hydrogen-file-transfer/SKILL.md+7−7@@ -5,7 +5,7 @@ description: > distro, where your code lives at /home/adom/project) and the user's Windows PC — including their Desktop, Downloads, and any folder. Three methods: (1) the auto-mounted C: drive at /mnt/c inside the distro, (2) the \\wsl$ network path- from Windows Explorer, and (3) the adom-bridge-cli relay (send_files / pull_file)+ from Windows Explorer, and (3) the adom-bridge relay (send_files / pull_file) relay. Use when the user asks "how do I get this file onto my desktop", "copy this out of the workspace", "get a file from my PC into the workspace", "move a file in/out", "where do my downloads@@ -52,22 +52,22 @@ From Windows, the distro is a network share. In Explorer's address bar: The user can **drag files in/out** of that folder to/from their Desktop. Tell them this path when they want to grab their code or drop a file in by hand. -## Method 3 — the adom-bridge-cli relay (works on ANY runtime)+## Method 3 — the adom-bridge relay (works on ANY runtime) Hydrogen embeds Adom Bridge, which bridges the workspace to the real OS. Use this when you want the AI to push/pull files programmatically, or when you need a specific-Save-As target directory on the PC. See **hydrogen-adom-bridge-cli**.+Save-As target directory on the PC. See **hydrogen-adom-bridge**. ```bash # Workspace → PC (lands in the user's Downloads by default; large files OK)-adom-bridge-cli send_files '{"filePaths":["/home/adom/project/out.zip"],"saveTo":"C:\\Users\\john\\Desktop"}'+adom-bridge send_files '{"filePaths":["/home/adom/project/out.zip"],"saveTo":"C:\\Users\\john\\Desktop"}' # PC → workspace-adom-bridge-cli pull_file '{"filePaths":["C:\\Users\\john\\Desktop\\photo.png"],"saveTo":"/home/adom/project"}'+adom-bridge pull_file '{"filePaths":["C:\\Users\\john\\Desktop\\photo.png"],"saveTo":"/home/adom/project"}' ``` Notes:-- Confirm the bridge first: `adom-bridge-cli ping` → `pong`. If not connected, the+- Confirm the bridge first: `adom-bridge ping` → `pong`. If not connected, the user must have Hydrogen running/foregrounded. - Files whose basename starts with `_` are silently dropped by the relay — use plain names.@@ -88,5 +88,5 @@ persistent-vs-ephemeral map. ## Related - **hydrogen-volume** — what persists, where files live, backing up before virgin reset-- **hydrogen-adom-bridge-cli** — the relay (send_files / pull_file) and OS reach+- **hydrogen-adom-bridge** — the relay (send_files / pull_file) and OS reach - **hydrogen-workspace-lifecycle** — distro import/export/unregister
skills/hydrogen-networking/SKILL.md+5−5@@ -54,7 +54,7 @@ native TCP listeners on Windows — not inside the distro. | Port | Service | Notes | |------|---------|-------| | 1420 | Dev file server | Dev mode only, serves `build/` |-| 8770 | adom-bridge-cli direct connect | Owned by Adom Bridge, NOT Hydrogen |+| 8770 | adom-bridge direct connect | Owned by Adom Bridge, NOT Hydrogen | | 47080 | Hydrogen discovery server | | | 47083 | Hydrogen reverse proxy | Proxies to code-server | | 47084 | Hydrogen control API | Health, setup, eval, CDP, `/wsl/status`, `/port-forward` |@@ -111,12 +111,12 @@ Direct connect → `http://127.0.0.1:8770/health` ## Relay Architecture -The relay (`adom-bridge-cli serve`) runs inside the distro on ports 8765+The relay (`adom-bridge serve`) runs inside the distro on ports 8765 (WebSocket) and 8766 (HTTP). It binds `0.0.0.0`, so it is reachable both via WSL2 auto-forward (`localhost:8765` / `localhost:8766` on Windows) and via the code-server proxy. The proxy path is preferred for connection stability: -1. **adom-bridge-cli on Windows** connects as a WS client via the+1. **adom-bridge on Windows** connects as a WS client via the code-server proxy: `ws://127.0.0.1:7380/proxy/8765/` 2. **Registration** happens via `server_add` on the direct connect API (port 8770):@@ -130,7 +130,7 @@ code-server proxy. The proxy path is preferred for connection stability: 3. **Health checks** use the proxy path: `http://127.0.0.1:7380/proxy/8766/health` -This matches cloud containers where adom-bridge-cli connects via+This matches cloud containers where adom-bridge connects via `wss://<slug>.adom.cloud/proxy/8765/`. ## VSCODE_PROXY_URI@@ -170,6 +170,6 @@ wsl -d Adom-Workspace -- su - adom -c '<cmd>' 5. **NEVER hardcode port numbers** in distro code. Read from env vars (`ADOM_CARBON_URL`, `ADOM_HYDROGEN_URL`) or discover via the direct connect API.-6. **NEVER assume adom-bridge-cli direct connect (8770) is owned by Hydrogen.**+6. **NEVER assume adom-bridge direct connect (8770) is owned by Hydrogen.** It's owned by Adom Bridge. Hydrogen's direct-api thread binds to 8770 as a fallback but Adom Bridge takes priority when both are running.
skills/hydrogen-notifications/SKILL.md+4−4@@ -6,7 +6,7 @@ description: > long job finished or that it needs them (great for hands-free / away-from-keyboard 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`.+ and how to fire one with the `notify` desktop command / `adom-bridge notify_user`. Also the in-app `/ui/toast` (a message INSIDE the Hydrogen window) and Pup's browser_alert_window attention nudge. The native OS-toast backend is platform-specific (see the platform companions [[hydrogen-notifications-windows]] /@@ -37,7 +37,7 @@ Source: `src-tauri/crates/hydrogen-app/src/notifications.rs` (`handle_notify` � 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"}'+adom-bridge notify_user '{"title":"Build complete","body":"hd_build_rust finished — exit 0","level":"info"}' ``` Payload shape (`NotifyPayload`):@@ -100,7 +100,7 @@ notice — see [hydrogen-recording](../hydrogen-recording/SKILL.md).) For AI-driven browser work, Pup has its own attention nudge: ```bash-adom-bridge-cli browser_alert_window '{"sessionId":"default"}'+adom-bridge browser_alert_window '{"sessionId":"default"}' ``` It **triggers the OS attention nudge** for that browser window (and brings the page@@ -117,7 +117,7 @@ to front within Chrome) **without stealing foreground focus** — a gentle "look glance-able toast and the spoken answer. Don't spam: one notification per meaningful event. Verify the bridge first-(`adom-bridge-cli ping`) before claiming you notified them.+(`adom-bridge ping`) before claiming you notified them. ## Related skills - [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
skills/hydrogen-open-url/SKILL.md+2−2@@ -111,12 +111,12 @@ 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 `hydrogen-browser-picker`. -**3. Pup** — open and then drive it with `adom-bridge-cli browser_*` verbs+**3. Pup** — open and then drive it with `adom-bridge browser_*` verbs (`browser_open_window`, `browser_navigate`, `browser_screenshot`, `browser_eval`, `browser_reload`, …). Either open the URL directly via Pup, or let the picker route to Pup. See the `pup` skill for the full verb set. ```bash-adom-bridge-cli browser_eval '{"sessionId":"default","js":"document.title"}'+adom-bridge browser_eval '{"sessionId":"default","js":"document.title"}' ``` **6. Headless content** — if you only need to *read* the page, skip the browser
skills/hydrogen-ports/SKILL.md+10−10@@ -131,9 +131,9 @@ Defaults (you can override via ports.json): | Reverse proxy (`proxy`) | 47083 | | Hydrogen control API (`control`) | 47084 | | WebView2 CDP (`cdp`) | 47085 |-| KiCad bridge | **dynamic** (adom-bridge-cli picks at bridge launch) |-| Fusion bridge | **dynamic** (adom-bridge-cli picks at bridge launch) |-| Puppeteer bridge | **dynamic** (adom-bridge-cli picks at bridge launch) |+| KiCad bridge | **dynamic** (adom-bridge picks at bridge launch) |+| Fusion bridge | **dynamic** (adom-bridge picks at bridge launch) |+| Puppeteer bridge | **dynamic** (adom-bridge picks at bridge launch) | **Conflict resolution is NOT "next sequential port."** On startup `PortConfig::resolve_available()` checks `proxy`, `control`, and `cdp`; if a@@ -238,22 +238,22 @@ rung zero, never an assumption): ## Bridge ports are dynamic KiCad, Fusion 360, Puppeteer, and any 3rd-party bridges no longer have known-fixed ports. When a bridge launches, **adom-bridge-cli picks an available port at+fixed ports. When a bridge launches, **adom-bridge picks an available port at runtime** and registers it. To find a running bridge's current port, query-adom-bridge-cli:+adom-bridge: ```bash-adom-bridge-cli status+adom-bridge status # Look at desktop.apps.<bridge>.bridgePort ``` -Or use the bridge directly via adom-bridge-cli CLI — you don't need the port at all:+Or use the bridge directly via adom-bridge CLI — you don't need the port at all: ```bash-adom-bridge-cli kicad_open_board '{"path":"..."}' # adom-bridge-cli routes to the right port-adom-bridge-cli browser_eval '{"js":"..."}'+adom-bridge kicad_open_board '{"path":"..."}' # adom-bridge routes to the right port+adom-bridge browser_eval '{"js":"..."}' ``` This means **old code or skill examples that hardcoded fixed bridge ports-(8771 / 8773 / 8851) are stale.** Use the adom-bridge-cli CLI or `status` lookup+(8771 / 8773 / 8851) are stale.** Use the adom-bridge CLI or `status` lookup instead.
skills/hydrogen-recording/SKILL.md+14−14@@ -39,12 +39,12 @@ recording — this is the single most important decision and a known footgun. **DEFAULT — drive it with `adom-cli hydrogen recording start` / `stop`.** That IS the Hydrogen native recorder (h264 mp4 → `~/project/recordings/`). Do **NOT** reach for-`adom-bridge-cli desktop_record_start` for an ordinary "record my screen / window / the+`adom-bridge desktop_record_start` for an ordinary "record my screen / window / the workspace" — that's the ab **host** fallback: it writes a `.webm` into ab's bridges-cache (`…/Adom Bridge/bridges-cache/…`), **not** your `~/project/recordings/`, and is only for when Hydrogen's native recorder is genuinely busy. "record my screen", "record the workspace", "record a demo", "record kicad" all → `adom-cli hydrogen-recording`. (Same trap as screenshots: don't fall through to `adom-bridge-cli` for+recording`. (Same trap as screenshots: don't fall through to `adom-bridge` for anything inside Hydrogen.) ## Which recorder? — the priority ladder (read first)@@ -65,13 +65,13 @@ do.** Default to Hydrogen-native. **Hydrogen-native exclusive** (neither adom-cli nor ab can scope a recording to one window). Resolve the title via `GET /recording/native/sources`. Same endpoint does `{source:"screen"}`, `{source:"screen:2"}`, codec, custom cap.-3. **The whole DESKTOP when Hydrogen's native recorder is already busy:** `adom-bridge-cli+3. **The whole DESKTOP when Hydrogen's native recorder is already busy:** `adom-bridge desktop_record_start {confirmDesktopNotTabRecording:true}`. **Whole-desktop ONLY (no per-window), via Chrome `getDisplayMedia` → it DOES hold the display wake-lock** (unlike Hydrogen native) and writes a **`.webm` into ab's cache** (not `~/project/recordings/`). ab's own help says "prefer Hydrogen's `recording start --share screen`" — this is for the parallel-with-an-Hydrogen-capture case, not the default.-4. **A single Chrome tab** (AI-driven Pup browser — a clean per-tab clip): `adom-bridge-cli+4. **A single Chrome tab** (AI-driven Pup browser — a clean per-tab clip): `adom-bridge browser_record_start {sessionId}` / `browser_record_stop`. CDP screencast, ~50fps, no HUD, no wake-lock, coexists with everything. 5. **Just audio — a voice / narration track, no video** ("record a narration", "record my@@ -256,8 +256,8 @@ thread and a screenshot requested by another routinely overlap. **Almost every c method coexists with a live recording — only the `adom-cli` SSE screenshot path does not.** - ✅ **Coexist with a recording** (use these while recording): CDP `POST /screenshot`- (Hydrogen-native, the default), `adom-bridge-cli desktop_screenshot_window` (ab per-window),- `adom-bridge-cli desktop_screenshot_screen` (ab host GDI), pup `browser_screenshot`.+ (Hydrogen-native, the default), `adom-bridge desktop_screenshot_window` (ab per-window),+ `adom-bridge desktop_screenshot_screen` (ab host GDI), pup `browser_screenshot`. - ⚠️ **The ONE exception** — `adom-cli hydrogen screenshot panel|workspace|screen` (the SSE path, `PATCH /current/screenshot`). The moment a native recording is active this returns **`{ok:false, error:"capture_busy", retry_after_ms, alternatives:[...], _hint}`** instead of@@ -367,21 +367,21 @@ and `stopCombinedRecordingAsBlob()` (raw blob) for programmatic capture. ## (c) ab host desktop recording (Windows-only) Served by the embedded **Adom Bridge** process (see-[hydrogen-adom-bridge-cli](../hydrogen-adom-bridge-cli/SKILL.md)), not by the Hydrogen frontend. These+[hydrogen-adom-bridge](../hydrogen-adom-bridge/SKILL.md)), not by the Hydrogen frontend. These record the **real OS desktop**, not Hydrogen's webview: ```bash-adom-bridge-cli desktop_record_start '{"reason":"Demo recording","confirmDesktopNotTabRecording":true}'-adom-bridge-cli desktop_record_stop-adom-bridge-cli desktop_record_status-adom-bridge-cli desktop_recorder_open # open the recorder UI on the host+adom-bridge desktop_record_start '{"reason":"Demo recording","confirmDesktopNotTabRecording":true}'+adom-bridge desktop_record_stop+adom-bridge desktop_record_status+adom-bridge desktop_recorder_open # open the recorder UI on the host ``` **Verify the capability first** — desktop recording is **Windows-only** and only present when ab advertises it: ```bash-adom-bridge-cli status # → .capabilities must include "record"+adom-bridge status # → .capabilities must include "record" ``` If `record` isn't listed, the host/runtime doesn't support it — fall back to the@@ -396,8 +396,8 @@ in-app recorder (for the workspace) or `browser_record_start` (for a tab). | **Record whole screen (ah)** | `adom-cli hydrogen recording start --share screen …` or `POST /recording/native/start {source:"screen"}` | **h264 mp4** → `~/project/recordings/` | | **Record a window (ah), e.g. "record kicad"** | `POST /recording/native/start {source:"window:KiCad"}` | **h264 mp4** → `~/project/recordings/` | | **Smaller archival recording (ah)** | `POST /recording/native/start {source:…, codec:"h265"}` | **h265 mp4** (not web-playable) |-| Record one AI browser tab | `adom-bridge-cli browser_record_start` (pup) | tab screencast |-| Record host desktop via ab (Hydrogen busy) | `adom-bridge-cli desktop_record_start '{"confirmDesktopNotTabRecording":true}'` | host recording |+| Record one AI browser tab | `adom-bridge browser_record_start` (pup) | tab screencast |+| Record host desktop via ab (Hydrogen busy) | `adom-bridge desktop_record_start '{"confirmDesktopNotTabRecording":true}'` | host recording | | Record the workspace (web-Hydrogen) | In-app Recording dropdown (or `promptRecording()`) | `.webm` → container `recordings/` | ## Related skills
skills/hydrogen-screen-lock/SKILL.md+1−1@@ -86,4 +86,4 @@ This is a *contention* guard, not a power-state one — full detail in - [hydrogen-recording](../hydrogen-recording/SKILL.md) — native WGC/DXGI recording, the max-duration cap + reason, the "● Recording" indicator - [hydrogen-self-screenshot](../hydrogen-self-screenshot/SKILL.md) — native CDP screenshots (no wake-lock) - [hydrogen-notifications](../hydrogen-notifications/SKILL.md) — OS toasts + the in-app `/ui/toast`-- the `screen-capture-wake-lock` skill (formerly a gallia skill; skills now ship via adom-wiki packages) — the **web-Hydrogen** side of this issue (where the leak actually happens)+- the `screen-capture-wake-lock` skill (ships in the adom-wiki packages) — the **web-Hydrogen** side of this issue (where the leak actually happens)
skills/hydrogen-setup-steps/SKILL.md+6−9@@ -1,6 +1,6 @@ --- name: hydrogen-setup-steps-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, ah setup, claude code extension install, gallia install, ah 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, ah setup, claude code extension install, the Adom CLIs install, ah workspace ready. --- # Hydrogen Setup Steps — what was done to prepare your workspace@@ -11,7 +11,7 @@ state-file name live in your platform bootstrap's version of this skill. 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+The heavy tooling (code-server, the Adom CLIs from the wiki registry package adom/hydrogen-windows-bootstrap, 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@@ -33,8 +33,8 @@ platform bootstrap's version of this skill. | set-env-vars | Set `ADOM_CARBON_URL`, `ADOM_HYDROGEN_URL`, `ADOM_HD_CONTROL_URL`, `VSCODE_PROXY_URI`, `ADOM_DESKTOP_MODE` | | inject-api-key | Write the Adom session token into the workspace so adom-cli works | | configure-vscode | settings.json / trusted-domains / activity-bar are BAKED; re-asserts theme + workbench backstops idempotently, and applies the per-session layout |-| ensure-adom-bridge-cli | Verify the Adom Bridge companion app is running (the relay's desktop bridge) |-| start-relay | Start the adom-bridge-cli relay inside the workspace |+| ensure-adom-bridge | Verify the Adom Bridge companion app is running (the relay's desktop bridge) |+| start-relay | Start the adom-bridge relay inside the workspace | | test-direct-connect | Prove the fast workspace→desktop command path | | test-relay | Register the relay with Adom Bridge for file streaming (file transfer + shell exec) | | test-adom-cli | GATE: carbon path + hydrogen-proxy reachability via adom-cli |@@ -46,16 +46,13 @@ platform bootstrap's version of this skill. ### 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-claude-cli`, `install-claude-ext`, `write-vscode-settings`,-`set-trusted-domains`, `clean-layout`. If a user asks "what installed gallia /+These ids no longer exist as steps: their work is baked into the golden image or folded into `update-packages` (wiki registry install of adom/hydrogen-windows-bootstrap) and `configure-vscode`: `install-the Adom CLIs`, `install-hd-skills`, `verify-adom-bridge`, `install-claude-ext`, `write-vscode-settings`, `set-trusted-domains`, `clean-layout`, `ensure-workspace`, `install-adom-vscode`. Do not list or "run" them. The live step list, in order, is `wait-codeserver`, `update-packages`, `activate-editor`, `set-env-vars`, `inject-api-key`, `configure-vscode`, `ensure-adom-bridge-cli`, `install-brand-fonts`, `start-relay`, `test-direct-connect`, `test-relay`, `test-adom-cli`, `install-claude-cli`, `claude-auth`, `ensure-sse`, `verify-workspace`, `welcome`, `verify-setup`, `open-welcome`. If a user asks "what installed the Adom CLIs / the Claude extension / my skills / VS Code settings", the answer is: **baked into the golden image at build time, not a setup step.** See `hydrogen-golden-image`. ## Common user questions -**"Why is X installed in my workspace?"** → If X is gallia, an Adom CLI, the+**"Why is X installed in my workspace?"** → If X is an Adom CLI, the 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
skills/hydrogen-setup/SKILL.md+3−6@@ -20,7 +20,7 @@ live in your platform bootstrap's version of this skill. 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+with code-server, the Adom CLIs (installed from the wiki registry package adom/hydrogen-windows-bootstrap by the update-packages step), 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, Hydrogen downloads it — never tell the@@ -59,10 +59,7 @@ Conceptually the steps fall into these phases: ### 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`,-`verify-adom-bridge-cli`, `install-claude-cli`, `install-claude-ext`,-`write-vscode-settings`, `set-trusted-domains`, `clean-layout`. gallia, the+These ids no longer exist as steps: their work is baked into the golden image or folded into `update-packages` (wiki registry install of adom/hydrogen-windows-bootstrap) and `configure-vscode`: `install-the Adom CLIs`, `install-hd-skills`, `verify-adom-bridge`, `install-claude-ext`, `write-vscode-settings`, `set-trusted-domains`, `clean-layout`, `ensure-workspace`, `install-adom-vscode`. Do not list or "run" them. The live step list, in order, is `wait-codeserver`, `update-packages`, `activate-editor`, `set-env-vars`, `inject-api-key`, `configure-vscode`, `ensure-adom-bridge-cli`, `install-brand-fonts`, `start-relay`, `test-direct-connect`, `test-relay`, `test-adom-cli`, `install-claude-cli`, `claude-auth`, `ensure-sse`, `verify-workspace`, `welcome`, `verify-setup`, `open-welcome`. The Adom CLIs (wiki registry), the Adom CLIs, the claude CLI + Code extension, code-server, settings, and all `hd-*` skills are baked into the golden image. See `hydrogen-golden-image`. @@ -181,7 +178,7 @@ a real layout; `welcome` opens Claude Code and sends the first prompt; the 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+> Note: the Adom CLIs (wiki registry package adom/hydrogen-windows-bootstrap), the claude CLI + Code extension, VS Code > settings, and `hd-*` skills are NOT setup steps — they are baked into the > golden image. See `hydrogen-golden-image`.
skills/hydrogen-topology/SKILL.md+18−18@@ -6,7 +6,7 @@ description: > and the Hydrogen local WSL2 workspace (the Adom-Workspace distro). Every command you run goes through the relay to Windows. You CANNOT directly access the WSL2 distro — you must shell through Windows. Trigger words — Hydrogen topology,- cloud vs local, wsl exec, where am I, which workspace, adom-bridge-cli+ cloud vs local, wsl exec, where am I, which workspace, adom-bridge relay, test from container, three tiers, architecture, windows machine. --- @@ -17,12 +17,12 @@ WSL2-runtime version (default). Legacy Docker container runtime (`HD_RUNTIME=doc ## You are NOT on the user's machine You (Claude) run inside an **Adom cloud Docker container**. The user's-Windows machine is a remote target you reach through the `adom-bridge-cli`+Windows machine is a remote target you reach through the `adom-bridge` CLI relay. There are THREE separate environments: ### 1. Cloud Docker (where you run) - Your shell, your filesystem, your git repos-- `adom-bridge-cli` CLI connects to Adom Bridge on Windows via relay+- `adom-bridge` CLI connects to Adom Bridge on Windows via relay - This container has NOTHING to do with Hydrogen's local WSL2 workspace - Restarting the WSL2 distro on Windows does NOT affect you - You can freely `git push`, edit code, run builds here@@ -31,41 +31,41 @@ CLI relay. There are THREE separate environments: - **Adom Bridge** — relay client app, listens on port 8770 (direct connect) - **Hydrogen** — the Tauri app you're building - **WSL2** — hosts the `Adom-Workspace` distro-- You reach this via `adom-bridge-cli shell_execute '{"command":"..."}'`+- You reach this via `adom-bridge shell_execute '{"command":"..."}'` - Commands run in `cmd.exe` on Windows ### 3. Hydrogen Local WSL2 Workspace (the `Adom-Workspace` distro) - Distro name: `Adom-Workspace` (fixed — no random suffix, no container name)-- Runs code-server, adom-bridge-cli CLI, relay server-- You reach this via: `adom-bridge-cli shell_execute '{"command":"wsl -d Adom-Workspace -u adom -- <cmd>"}'`+- Runs code-server, adom-bridge CLI, relay server+- You reach this via: `adom-bridge shell_execute '{"command":"wsl -d Adom-Workspace -u adom -- <cmd>"}'` - This is TWO hops: cloud → relay → Windows → wsl exec → distro ## Command Patterns ### Run something on Windows ```bash-adom-bridge-cli shell_execute '{"command":"dir C:\\Github"}'+adom-bridge shell_execute '{"command":"dir C:\\Github"}' ``` ### Run something in the Hydrogen local WSL2 workspace ```bash-adom-bridge-cli shell_execute '{"command":"wsl -d Adom-Workspace -u adom -- ls /home/adom"}'+adom-bridge shell_execute '{"command":"wsl -d Adom-Workspace -u adom -- ls /home/adom"}' ``` -### Test adom-bridge-cli CLI inside the WSL2 workspace+### Test adom-bridge CLI inside the WSL2 workspace ```bash-adom-bridge-cli shell_execute '{"command":"wsl -d Adom-Workspace -u adom -- adom-bridge-cli ping"}'+adom-bridge shell_execute '{"command":"wsl -d Adom-Workspace -u adom -- adom-bridge ping"}' ``` This tests the FULL chain: distro → local relay → Adom Bridge on Windows. ### Screenshot Hydrogen window ```bash-adom-bridge-cli desktop_screenshot_window '{"hwnd":HWND}'+adom-bridge desktop_screenshot_window '{"hwnd":HWND}' ``` ### Pull file from Windows to cloud ```bash-adom-bridge-cli pull_file '{"filePaths":["C:\\path\\file"],"saveTo":"/tmp"}'+adom-bridge pull_file '{"filePaths":["C:\\path\\file"],"saveTo":"/tmp"}' ``` ## The WSL2 distro ≠ Your Container@@ -81,7 +81,7 @@ adom-bridge-cli pull_file '{"filePaths":["C:\\path\\file"],"saveTo":"/tmp"}' ## The Relay Chain ```-Cloud adom-bridge-cli CLI+Cloud adom-bridge CLI → WS relay (cloud :8765) → internet → Adom Bridge on Windows (relay client)@@ -92,7 +92,7 @@ Cloud adom-bridge-cli CLI For the Hydrogen local WSL2 workspace, there's a SECOND relay: ```-Workspace's adom-bridge-cli CLI+Workspace's adom-bridge CLI → local relay (distro :8765) → code-server proxy (:7380/proxy/8765/) → Adom Bridge on Windows (connected as WS client)@@ -106,11 +106,11 @@ The Hydrogen install flow MUST verify this chain works: 1. **Verify Adom Bridge running on Windows** — probe port 8770 If not running: tell user to install from wiki and launch it-2. **Install adom-bridge-cli CLI into the workspace** — download binary-3. **Start relay inside the workspace** — `adom-bridge-cli serve`+2. **Install adom-bridge CLI into the workspace** — download binary+3. **Start relay inside the workspace** — `adom-bridge serve` 4. **Register relay with Adom Bridge** — `server_add` via direct connect URL: `ws://127.0.0.1:{code_server}/proxy/8765/`-5. **Test round-trip** — `wsl -d Adom-Workspace -u adom -- adom-bridge-cli ping`+5. **Test round-trip** — `wsl -d Adom-Workspace -u adom -- adom-bridge ping` Must return `pong` — proves the full chain works ## NEVER Do These@@ -123,7 +123,7 @@ The Hydrogen install flow MUST verify this chain works: They're completely independent. 4. **NEVER run a global `wsl --shutdown` or `wsl --unregister` of anything other than `Adom-Workspace`.** Those hit every distro on the user's machine.-5. **NEVER skip the adom-bridge-cli round-trip test.**+5. **NEVER skip the adom-bridge round-trip test.** The relay chain has many links — test end-to-end, not individual parts. ## Related skills
skills/hydrogen-ui/SKILL.md+2−2@@ -60,7 +60,7 @@ The main menu, opened by clicking the Adom logo at the top-left. Items are group - **API Explorer...** — opens the control-API endpoint explorer dialog **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`+- **Adom Bridge** — brings the embedded Adom Bridge window to the foreground (taskbar); bus id `adom-bridge.open` - **Zoom** — webview zoom controls (− % +) with persistence across launches - **Fullscreen** — toggle fullscreen - **Console** — show/hide the Hydrogen debug console window@@ -140,7 +140,7 @@ CTRL="$(cat ~/.adom/hydrogen-control-url)" Common ids (always `GET /ui/actions` for the live set): `adom-menu.open`/`.close`, **`profile-menu.open`/`.close`**, `ports.open`/`.close`, `settings.open`/`.close`, `api-explorer.open`/`.close`, `browser-picker.open`/`.close`, `about.open`/`.close`,-`adom-bridge-cli.open`, `setup-panel.show`, `virgin-reset.open`,+`adom-bridge.open`, `setup-panel.show`, `virgin-reset.open`, **`samples-menu.open`/`.close`** (the lightbulb sample-prompts menu), `fullscreen.toggle`, `console.toggle`, `devtools.open`, `container.start`/`.stop`/`.restart`. (`dashboard.go` and `dev-toolbar.toggle` were
skills/hydrogen-volume/SKILL.md+3−3@@ -71,13 +71,13 @@ cp /home/adom/project/myfile.txt /mnt/c/Users/john/Downloads/ cp /mnt/c/Users/john/Downloads/myfile.txt /home/adom/project/ ``` -### 3. `adom-bridge-cli send_files` / `pull_file` (from inside the workspace, via the relay)+### 3. `adom-bridge send_files` / `pull_file` (from inside the workspace, via the relay) ```bash # Send a workspace file to your Windows desktop's Downloads folder-adom-bridge-cli send_files '{"filePaths":["/home/adom/project/myfile.txt"],"targetApp":"general","destinationFolder":"."}'+adom-bridge send_files '{"filePaths":["/home/adom/project/myfile.txt"],"targetApp":"general","destinationFolder":"."}' # Pull a Windows file into the workspace's /tmp-adom-bridge-cli pull_file '{"filePaths":["C:\\Users\\john\\Downloads\\myfile.txt"],"saveTo":"/tmp"}'+adom-bridge pull_file '{"filePaths":["C:\\Users\\john\\Downloads\\myfile.txt"],"saveTo":"/tmp"}' ``` ### 4. Open the workspace's `/home/adom/project/` in VS Code's File Explorer