Adom Hydrogen (Windows / WSL2)

← All Pull Requests

Windows companions for the base-layer boundary sweep + one host-arch fix #40

Diff

--- a/skills/hydrogen-container/SKILL.md+++ b/skills/hydrogen-container/SKILL.md@@ -1,132 +1,133 @@⋯ 15 unchanged lines ⋯ | Distro name | `Adom-Workspace` (fixed — there is no random container suffix) | | Imported from | golden image `adom-golden.tar.gz` (full pre-baked image) via `wsl --import` | | Base | Ubuntu 24.04 |-| Architecture | matches host (`dpkg --print-architecture`) — almost always `linux-x64` on Windows hosts, can be `linux-arm64` on Apple Silicon hosts |+| Architecture | matches host (`dpkg --print-architecture`) — almost always `linux-x64`; `linux-arm64` on Windows-on-ARM hosts | | code-server | 4.112.0 (pinned via setup step) | | code-server binary | `/usr/lib/code-server/bin/code-server` | | Extensions dir | `~/.local/share/code-server/extensions/` |⋯ 107 unchanged lines ⋯  - `hydrogen-topology` — the three-tier topology; tier 3 is this WSL2 distro - `hydrogen-volume` — where your files live, what persists, and how to back up / copy out the distro+--- a/skills/hydrogen-adom-desktop-windows/SKILL.md+++ b/skills/hydrogen-adom-desktop-windows/SKILL.md@@ -0,0 +1,70 @@+---+name: hydrogen-adom-desktop-windows+description: >+  Windows companion to hydrogen-adom-desktop: the Windows/WSL2-specific host+  behavior behind Adom Bridge (ab). Covers the run_script interpreter set+  (bash/cmd/powershell), the wsl_exec structured runner, the winget-based+  unattended installs (KiCad, Node.js), WSL2 loopback forwarding for the relay,+  the host port-discovery file, and the taskkill cautions. The generic+  Hydrogen/ab model, capability map, and CLI patterns live in+  hydrogen-adom-desktop. Trigger words: wsl_exec, winget install kicad,+  taskkill adom, windows host bridge, wsl loopback, windows run_script.+---++# Adom Bridge on a Windows host: the specifics++Read `hydrogen-adom-desktop` first for the Hydrogen/ab model and the generic verb+surface. This skill carries only what is Windows-specific.++## Structured runners on Windows++`run_script` accepts `interpreter: "bash" | "cmd" | "powershell"` on Windows+(`bash` resolves to WSL2 bash, not Git Bash). Base64 the script so no quoting+survives to be mangled:++```bash+adom-bridge-cli run_script '{"interpreter":"powershell","scriptB64":"<b64>"}'+```++Windows also has an extra structured runner for executing INSIDE a WSL2 distro:++```bash+adom-bridge-cli wsl_exec '{"distro":"<workspace-distro>","user":"adom","scriptB64":"<b64>"}'+```++`wsl_exec` is a Windows/WSL2-only path; on other platforms it returns a clean+"Windows-only" error.++## Unattended installs (winget)++If KiCad or Node.js is missing on the host, ab can install them unattended via+winget:++- `adom-bridge-cli desktop_install_kicad '{}'` when `kicad_list_versions`+  returns `errorCode:"kicad_not_installed"`+- `adom-bridge-cli desktop_install_node '{}'` when a `browser_*` call returns+  `errorCode:"node_not_found"` (Node.js unblocks the Pup bridge)++## Relay networking (WSL2 loopback)++The host-side clients (Hydrogen's built-in bridge and the embedded ab) reach the+in-workspace relay because WSL2 mirrored networking shares loopback between the+distro and the Windows host: the relay's `127.0.0.1:8765/8766` inside the+workspace is the same loopback the host dials. Hydrogen's control API port is+discovered from the host-side ports file (`%APPDATA%\hydrogen-desktop\ports.json`);+`hd_api` reads the discovered port for you (fallback 47084).++## Process-kill cautions (taskkill)++- Never `taskkill /F /IM adom-bridge.exe` (or the embedded ab process) from the+  workspace: the host ab IS your relay bridge, and killing it severs the control+  channel with no way to restore it from inside.+- Never broad-kill `node.exe` or `wsl.exe` from the host either; VS Code Server+  and the workspace itself ride on them.++## Related skills++- `hydrogen-adom-desktop` (base): the Hydrogen/ab model and capability map+- `hydrogen-networking`: the Windows port architecture+- `hydrogen-container`: the WSL2 workspace facts+--- a/skills/hydrogen-eda-discovery-windows/SKILL.md+++ b/skills/hydrogen-eda-discovery-windows/SKILL.md@@ -0,0 +1,54 @@+---+name: hydrogen-eda-discovery-windows+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+  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.+---++# EDA discovery on Windows: the no-bridge probe++The generic playbook is `hydrogen-eda-discovery`. KiCad and Fusion 360 are detected+through their bridge verbs on every platform; this skill is only the Windows probe+for tools with no bridge.++## Install-path + process probe (run from the workspace)++Scan the standard install roots and the process list via a PowerShell `run_script`+(base64 the script so no quoting gets mangled):++```bash+SCRIPT=$(cat <<'PS' | base64 -w0+$roots = @("C:\Program Files", "C:\Program Files (x86)")+$names = @("Altium", "OrCAD", "Cadence", "EAGLE", "DipTrace", "Eplan")+foreach ($r in $roots) {+  Get-ChildItem $r -Directory -ErrorAction SilentlyContinue |+    Where-Object { $n = $_.Name; $names | Where-Object { $n -like "*$_*" } } |+    ForEach-Object { "INSTALLED: $($_.FullName)" }+}+Get-Process -ErrorAction SilentlyContinue |+  Where-Object { $p = $_.ProcessName; $names | Where-Object { $p -like "*$_*" } } |+  ForEach-Object { "RUNNING: $($_.ProcessName)" } | Select-Object -Unique+PS+)+adom-bridge-cli run_script "{\"interpreter\":\"powershell\",\"scriptB64\":\"$SCRIPT\"}"+```++Notes:++- Treat EMPTY output as a timeout or probe failure, not a negative result+  (unknown is not "none"). Say so plainly and ask the user if unsure.+- Some vendors install under the user profile or a custom drive; a miss on+  `Program Files` is evidence, not proof. The RUNNING lines are the stronger+  signal when the user has the tool open.+- `run_script` interpreters on Windows: `bash`, `cmd`, `powershell`.++## Related skills++- `hydrogen-eda-discovery` (base): the full discovery and onboarding playbook+- `hydrogen-adom-desktop-windows`: Windows host specifics for run_script and installs+--- a/skills/hydrogen-naming-windows/SKILL.md+++ b/skills/hydrogen-naming-windows/SKILL.md@@ -0,0 +1,36 @@+---+name: hydrogen-naming-windows+description: >+  Windows companion to hydrogen-naming: the Windows-specific frozen identifiers+  and install-surface names for Adom Hydrogen and Adom Bridge. The naming+  doctrine itself (Formal Names, the installer rule, shorthands, dead names)+  lives in hydrogen-naming. Trigger words: appdata hydrogen-desktop, installer+  filename windows, hydrogen exe name, wsl distro name, add remove programs+  name, autostart registry name.+---++# Adom product naming: Windows frozen identifiers++The doctrine (Formal Names, THE INSTALLER RULE, shorthands, dead names) is in+`hydrogen-naming`. These are the Windows-specific identifiers and surfaces.++## Windows install surfaces that MUST say "Adom Hydrogen" / "Adom Bridge"++- Start Menu entry, desktop shortcut, taskbar pin, taskbar-search result+- Installer artifact filename: `Adom Hydrogen_x.y.z_x64-setup.exe`+- Add/Remove Programs entry+- Autostart registry value name++## Frozen Windows identifiers (do NOT "fix" these)++These deliberately keep old spellings because they are load-bearing state or+build identity; renaming them breaks installs:++- Windows state dir `%APPDATA%\hydrogen-desktop`+- The binary is `hydrogen.exe` (Cargo package `hydrogen-desktop`)+- WSL distro `Adom-Workspace`++## Related skills++- `hydrogen-naming` (base): the doctrine and the cross-platform frozen identifiers+

Comments

Log in to comment.