Adom Hydrogen (Windows / WSL2)

@@ -1,38 +1,77 @@ --- name: hydrogen-golden-image description: >-  Your Hydrogen workspace starts from a THIN golden WSL2 image (v24-thin and-  later): the image carries ONLY the OS baseline — Ubuntu, systemd, code-server,-  the folder contract, and the adom-wiki CLI. EVERYTHING Adom (the adom/core-  toolchain, the 8 CLIs, all hydrogen-* skills, the editor extensions including-  Claude Code) is installed LIVE by the setup cascade's first-  `adom-wiki pkg install adom/hydrogen-windows-bootstrap`, and kept current by-  the registry updater. READ THIS when a user asks "where did these skills/CLIs-  come from", "why did first-run setup take a few minutes", "how do I update-  the workspace", or "what's actually in the image". Trigger words — golden-  image, thin image, pre-baked, baked image, adom-golden, adom-golden.tar.gz,-  wsl --import, tarball version, adom-tarball-version, migrate tarball,-  install-hydrogen-skills, where did the CLIs come from, how do I update the-  workspace, re-run setup, lightweight image, install on demand, command not-  found, missing tool, apt-get install, is ffmpeg installed.+  Your Hydrogen workspace starts from a PRE-BAKED golden WSL2 image (v28-full):+  the tarball already carries the Adom toolchain — adom/core, the Adom CLIs, the+  hydrogen-* skills and the editor extensions including Claude Code — on top of+  Ubuntu, systemd, code-server and the folder contract. Setup does NOT install+  the ecosystem from scratch on a full image; its update-packages step converges+  what is baked in to the latest published versions. READ THIS when a user asks+  "where did these skills/CLIs come from", "why did first-run setup take a few+  minutes", "how do I update the workspace", or "what's actually in the image".+  Trigger words — golden image, full image, thin image, pre-baked, baked image,+  adom-golden, adom-golden.tar.gz, wsl --import, tarball version,+  adom-tarball-version, migrate tarball, install-hydrogen-skills, where did the+  CLIs come from, how do I update the workspace, re-run setup, install on+  demand, command not found, missing tool, apt-get install, is ffmpeg installed. --- -# Hydrogen Workspace = a thin golden image + a live first install+# Hydrogen Workspace = a pre-baked golden image, kept current at setup -Since image **v24-thin** (2026-08-13, John's call: "simple golden image, setup-steps configure everything") the golden image is deliberately MINIMAL. What the-tarball actually contains:+The shipped image is **v28-full** (~812 MB, rootfs ~2.3 GB). It is PRE-BAKED:+the Adom toolchain is already inside the tarball, so a fresh workspace has the+CLIs and skills the moment the import finishes.++**A new image every week or so, and no forced upgrade, ever (from v27 on).** Each+weekly image is the previous one with the current `adom-wiki pkg update` baked in:+exactly what every running workspace already installs on its own. So a fresh+install skips the multi-minute package walk (the toolchain step reads one version+and skips the walk when nothing is behind), and an install already on v27 or any+later image is current: no "workspace update available" card, no consent flow,+no re-image. The app enforces this as a floor (`NO_FORCED_MIGRATION_FROM = 27` in+`runtime/wsl.rs`); only a change below the package layer, which the package+channel cannot deliver, would ever raise it, and that would be said in the+changelog. The image a machine runs is on the fleet dashboard (the `image` field+of the ping).++> **The pin is the truth, this page is a snapshot.** The version actually+> shipped lives in three consts in `runtime/wsl.rs` (`TARBALL_VERSION`,+> `TARBALL_URL_PLACEHOLDER`, `TARBALL_SHA256_PLACEHOLDER`). If they disagree+> with this page, they win and this page is stale. An earlier era (v24-thin,+> 2026-08-13 to v26) shipped a MINIMAL image that installed everything live at+> setup; describing that as current tells a user their 695 MB image is empty.++What the tarball contains:  - Ubuntu base + systemd (PID 1), the adom user, the folder contract   (`~/project` is the workspace root) - **code-server** (the VS Code backend) + its systemd unit-- systemd units for the relay and shotlog, guarded by `ConditionPathExists` so-  they wait quietly until setup installs their binaries-- the **adom-wiki CLI seed** at `~/.local/bin/adom-wiki` — the installer that-  brings everything else+- systemd units for the relay and shotlog+- the **adom-wiki CLI** at `~/.local/bin/adom-wiki`+- **the Adom toolchain itself**: adom/core, the Adom CLIs, the hydrogen-*+  skills, and the editor extensions (adom-theme, adom-vscode,+  anthropic.claude-code) - a first-boot oneshot that mints the per-import `/etc/adom-distro-id` -**Everything else arrives at setup time.** The setup cascade's update-packages+## Why setup still takes a few minutes++An image is baked once and installed for months, so the cascade's+**update-packages** step converges the baked-in packages to the LATEST+published versions (`adom-wiki pkg update`) before anything depends on them.+That is an UPDATE, not a first install: it can still take minutes because it is+a sweep across ~22 packages against the registry, but nothing is being built+from nothing. `install-claude-cli` likewise finishes in ~0.0s on a full image,+as a presence check.++The step DOES have a from-scratch branch, and it announces itself: "first run+on a thin image: installing the full Adom toolchain now (~150 skills, 22+packages, all editor extensions)". That fires only when `~/adom_modules` is+ABSENT — a thin image or a hand-built distro. **Seeing it on a v27 box means+the import went wrong, not that the step is slow.**++### How the live install works (thin images and hand-built distros)++**On a THIN image everything arrives at setup time.** The setup cascade's update-packages step runs `adom-wiki pkg install adom/hydrogen-windows-bootstrap`, the leaf package whose dependency tree pulls hydrogen-bootstrap → adom/core and the whole ecosystem: ~150 skills, ~22 packages, the 8 Adom CLIs, and ALL editor