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 Discover Packages Releases Dependencies Issues20 Breadcrumbs Pull Requests Activity
Closed general

Dock API: adom-cli hydrogen dock refresh/pin/unpin/list, and dedup pinned cards out of the featured strip

John Lauer · 1mo ago ·closed by John Lauer

Ask: a dock API in ah (adom-cli hydrogen dock ...) for refresh + pin, and pinned/featured dedup

Today the dock has no programmatic surface at all — adom-cli hydrogen covers workspace/webview/screenshot/notify, but Refresh list from wiki and Pin to Dock / Unpin are right-click-only gestures on the rail. Two real cases hit this today while shipping adom/altium-bridge:

  1. A newly curated app is invisible for up to 6 hours. We added the altium card to hydrogen-bootstrap/dock/apps.json; with poll_seconds: 21600 the user's rail won't show it until the next poll, and the only accelerator is telling the user to right-click empty rail space. An AI that just published the card should be able to complete the job: adom-cli hydrogen dock refresh (dock-wide, honoring the existing manual_refresh_cooldown_seconds).
  2. "Pin yourself to my dock" is not automatable. The user asked the AI to pin the new card; there is no verb. Ask: adom-cli hydrogen dock pin <id> / unpin <id>, plus dock list (cards with pinned / featured / running / order state so an AI can see the rail before touching it). A per-app dock hard-refresh <id> (the existing Hard Refresh Open) would round it out for the "app just published a fix" flow.

Design point while you're in there — pinned cards currently render twice. A card that is pinned ALSO still shows in the featured section of the rail, so pinning a featured app duplicates it. Suggested semantics: pinned wins — a pinned card renders once in the pinned strip at the top and is deduped out of the featured/ordered list below (unpinning returns it to its curated slot). If the duplication is intentional, the dock API's list output should at least mark both instances so automation doesn't double-count.

Scope note: this is rail chrome, so it's compiled into ah (per the dockbar guide's three-layer table) — hence an ah issue rather than a bootstrap/app-side change. The CLI already has the SSE session to the browser (hydrogen probe/reload), so dock refresh|pin|unpin|list should be able to ride the same channel.

Filed from the altium-bridge thread (John's ask, 2026-08-31).

3 Replies

John Lauer · 1mo ago

One more verb for the same family, from the next question John hit: dock show|hide|toggle — programmatic open/collapse of the rail itself. Today the rail's visibility is UI-only (auto-shows at startup, auto-collapses after a launch, plus the "Start with the dock collapsed" preference in Dock settings); adom-cli hydrogen nav controls the navigation bar, not the dock. Use case: an AI that just added or refreshed a card wants to open the rail so the user can see it, then collapse it again — same SSE channel as the rest of the proposed dock family.

John Lauer · 1mo ago

Shipped in Hydrogen 1.0.211 (insiders, 2026-09-05): the dock is drivable from a thread through ah's control API, no mouse, no cursor overlay.

call what it does
GET /dock/apps every app with id, wiki_repo, name, mode, running/launching, tab_open (from the layout), url, health, last_launch summary
POST /dock/launch {id, relaunch?, timeoutSec?} presses the button; relaunch defaults to true (close the tab, recreate it, run the manifest steps again); waits and returns ok, url, reason, status, elapsed_ms, tab_open and the full console transcript (every phase, every command with its container output)
POST /dock/close {id} removes the tab, forgets the running state
POST /dock/refresh {full?} re-reads the curated apps.json now (full: displays, heroes and manifests too)

Every answer carries _hints saying what happened and what to do next. The wire: the route emits a dock-command event into the shell webview, the dock store runs the exact code a click runs, and posts the result to POST /dock/result. Documented in the hydrogen-dock skill ("Driving the dock from an AI thread"), published as hydrogen-bootstrap 0.5.24; the routes are in the hydrogen-api skill's index (hydrogen-windows-bootstrap 0.3.20).

Re-click now relaunches (same release): a click on an open app closes its webview, recreates it and runs the steps again, so an iterating thread always sees its current code.

Verified on AdomLapper by driving it myself: /dock/refresh picked up the new curated list (nb, grok, codex added at 55/60/65 in hydrogen-bootstrap 0.5.23), then /dock/launch for nb (2.1 s, install skipped, serve printed its URL, health UP, tab open), grok (2.0 s) and codex (0.3 s), each answer carrying the transcript. The run also found four gaps, fixed in 1.0.212 (building): a plain-webview launch answered before its completion timer, a card whose dockbar.json had not resolved yet launched as its wiki page instead of resolving on demand, /dock/refresh answered before the manifests resolved, and a user-added app duplicated its curated twin.

John Lauer · 1mo ago

Closing. Shipped in 1.0.211 together with #54: refresh, pin, unpin, list and show/hide are all on the control API and in adom-cli.

Log in to reply.