app

Adom Hydrogen

Public Made by Adom

by adom

The whole Adom experience as one signed native app: your editor, your AI agent, and the full electronics design toolchain, running locally on your own machine.

Overview Files Skills Packages Releases Dependencies Issues11 Breadcrumbs Pull Requests1 Activity
Closed bug report

Setup step 3 'Update Adom packages' wedges forever on pre-existing installs — gate wants skills-deployed but skips-only converge never lands them

Drew Owens · 20d ago ·closed by John Lauer
hd-feedback

Type: Bug · [hd-feedback] · setup step 3 "Update Adom packages" wedges permanently on pre-existing installs

Reported by Kale in gchat ("Cannot get an install success, likely because I already had it installed… errors at step 3… uninstalling the app didn't work either") — reproduced and root-caused from a container with the same stale manifest shape.

Symptom

Setup stops at step 3 of 20 with the red banner: "Setup stopped at 'Update Adom packages': Updating Adom packages to the latest published versions (adom-wiki pkg update)…". Retry fails identically, forever. Uninstalling/reinstalling the HD app does not help.

Root cause — the gate demands an artifact its own converge path can't produce

Per the step definition (setup_steps_wsl.rs / hd-setup-steps): step 3 "gates on the ARTIFACT (hd-bootstrap == registry latest + skills deployed), not the raw exit code; re-runs bootstrap postinstalls when an update lands."

On a machine that already had HD installed:

  1. The workspace manifest still holds pre-June-consolidation slugs. adom-wiki pkg update (1.0.55) emits 7× STALE_INSTALL "no longer resolves — skipped" for adom/mouser, adom/digikey, adom/jlcpcb, adom/parts-search, adom/pup, adom/screenshot-paste, adom/adom-desktop-puppeteer-bridge and exits 0. Verified: the first four now live at adom/adom-{mouser,digikey,jlcpcb,parts-search} (old slugs 404).
  2. Because stale entries are skipped, no hd-bootstrap update "lands" → the postinstall never re-runs → the bundled hd-* skills are never (re)deployed.
  3. The gate's artifact check ("skills deployed") fails → step hard-stops. Retry re-runs the exact same no-op converge → permanent wedge.

The wedge lives in the WSL workspace manifest, so uninstalling the desktop app can't clear it — matching the reporter's experience.

Fix suggestions

  • Gate fallback (main fix): when the artifact check fails after pkg update, force the converge instead of only hoping an update lands: adom-wiki pkg install adom/hd-bootstrap (plain install re-runs postinstall even at the same version; pkg ci is the stronger clean-reinstall). Retry then succeeds.
  • Manifest self-heal: migrate/prune June-renamed slugs (adom/mouser→adom/adom-mouser, etc.) during step 3 so old manifests converge instead of accumulating skips.
  • CLI (secondary, adom-wiki-cli 1.0.55):
    • False positive: adom/adom-desktop-puppeteer-bridge is flagged STALE_INSTALL but resolves fine (1.9.69).
    • Dead-end hints: pup and screenshot-paste 404 under every adom/ slug, so "reinstall under its current name" is unactionable — they need a resolvable name or an explicit fold-in note.

Workaround for affected users (now)

In the workspace distro: adom-wiki pkg install adom/hd-bootstrap → then hit Retry on step 3. (Or virgin reset, which wipes the distro.)

Environment

HD v0.1.173 · release · AD 1.9.154 (reporter) / repro on adom-wiki 1.0.55, hd-bootstrap 0.2.23 · gchat thread: spaces/AAAAfD3U2BY (Kale's report, 2026-07-21)

2 Replies

John Lauer · 10d ago

TRIAGE (Fable 5, 2026-07-31): this reads as the legacy-image class. The step still exists (update-packages, setup_steps_wsl.rs) and still gates on 'hd-bootstrap installed == registry latest AND bundled skills deployed'. The wedge this reports was on PRE-EXISTING installs — old golden images that never had the skills-deployed marker. The current image (v21) + adom-wiki 1.0.79 (which runs bootstrap postinstalls) converge cleanly on a fresh install. Keeping open ONLY to confirm the gate can't wedge an OLDER-image employee container that upgrades in place; the fresh-install path appears resolved. If we decide not to support in-place upgrade of pre-v21 images (reinstall instead), this closes.

John Lauer · 7d ago

Closing as fixed in current builds. The exact fallback this issue proposed is implemented in the update-packages step: when the post-update artifact check finds hd-bootstrap != registry latest, the step retries with a targeted adom-wiki pkg update adom/hd-bootstrap || adom-wiki pkg install adom/hd-bootstrap (the plain install re-runs the postinstall and deploys the bundled skills even at the same version), and the gate verifies the skills actually landed rather than trusting exit codes. Fresh installs on current images (v22, adom-wiki 1.0.79+) converge cleanly.

The stale-slug manifests from pre-consolidation images remain skipped-with-warnings rather than migrated; if we ever commit to in-place upgrades of pre-v21 employee images, that pruning deserves its own small issue. For affected legacy machines the documented workaround (targeted install, then Retry) still applies and is now also what the step itself does.

Log in to reply.