← Commit history

Publish 0.5.24

John Lauer ·e781f56171 ·1mo ago ·parent a65a220
3 files changed +49−9
package.json+2−2
@@ -4,7 +4,7 @@   "type": "bootstrap",   "title": "Adom Hydrogen (platform base)",   "brief": "Layer Hydrogen's workspace onto a standard Adom workstation.",-  "version": "0.5.23",+  "version": "0.5.24",   "description": "Hydrogen's PLATFORM-GENERIC workspace layer on top of adom/core. Installs adom/core for the full Adom ecosystem, then adds everything common to running inside Hydrogen on ANY platform: the runtime-neutral hydrogen-* skills and the generic editor configuration (Claude Code CLI + extension, VS Code settings, trusted domains). Platform-specific layers depend on THIS: adom/hydrogen-windows-bootstrap (WSL2), adom/hydrogen-mac-bootstrap, adom/hydrogen-ubuntu-bootstrap. The reference design other orgs copy to build their own bootstrap on adom/core.",   "org": "adom",   "tags": [@@ -32,4 +32,4 @@     "hydrogen editor configuration",     "where do hydrogen skills come from"   ]-}+}\ No newline at end of file
page.json+1−1
@@ -4,7 +4,7 @@   "type": "bootstrap",   "title": "Adom Hydrogen (platform base)",   "brief": "Layer Hydrogen's workspace onto a standard Adom workstation.",-  "version": "0.5.23",+  "version": "0.5.24",   "description": "Hydrogen's PLATFORM-GENERIC workspace layer on top of adom/core. Installs adom/core for the full Adom ecosystem, then adds everything common to running inside Hydrogen on ANY platform: the runtime-neutral hydrogen-* skills and the generic editor configuration (Claude Code CLI + extension, VS Code settings, trusted domains). Platform-specific layers depend on THIS: adom/hydrogen-windows-bootstrap (WSL2), adom/hydrogen-mac-bootstrap, adom/hydrogen-ubuntu-bootstrap. The reference design other orgs copy to build their own bootstrap on adom/core.",   "org": "adom",   "tags": [
skills/hydrogen-dock/SKILL.md+46−6
@@ -103,8 +103,8 @@ Two contracts that ride with the rules (full detail in the Dock Bar guide): ## What a click does  ```-click ─▶ already open? ─▶ YES: bring that tab forward. Never a second webview.-          │ NO+click ─▶ already open? ─▶ YES: close that tab first (re-click = relaunch, below)+          │           placeholder webview opens instantly (theme bg + orbital animation, free)           ├─ steps run in order, transcript streaming into the placeholder console           ├─ await:"url" scrapes the app URL from stdout@@ -118,9 +118,15 @@ click ─▶ already open? ─▶ YES: bring that tab forward. Never a second we The `ai` block is its OWN branch, not an alternative to `on_ready`: an app can show its dashboard AND open a thread about it. -**Re-click reveals the existing tab.** The dock finds it by `webview.title`-against the live workspace layout, so it holds even after a Hydrogen reload.-Publishers must keep `webview.title` stable or users get duplicate tabs.+**Re-click relaunches (since 1.0.211).** A click on an app whose tab is open+closes that webview, recreates it and runs the manifest steps again in the+container, so what appears is always the current code. This is deliberate: an+AI iterating on a dashboard could never tell whether a click showed its latest+work or the tab from before its change. The dock finds the tab by+`webview.title` against the live workspace layout, so it holds even after a+Hydrogen reload; publishers must keep `webview.title` stable or the old tab+survives next to the new one. A serve step is expected to be idempotent for+this (the bridge's version-aware serve retires its old instance).  ## The ai block @@ -143,6 +149,40 @@ background and runs the Adom orbital animation until the app URL truly loads. Apps bundle nothing and opt into nothing. `launch.console: "hide"` mutes the command transcript (never the failures) when the output would be noise. +## Driving the dock from an AI thread (the ralph loop)++You do not click. ah's control API (see the hydrogen-api skill for the base URL and+`hd_api`) presses the dock for you and hands back what happened, so the loop is:+change the app in the container, launch it through the API, read the transcript, look+at the dashboard, repeat. Every response carries `_hints` saying what to do next.++| call | what it does |+|---|---|+| `GET /dock/apps` | every app: `id`, `wiki_repo`, `name`, `mode`, `running`, `launching`, `tab_open` (from the layout, the truth after a reload), `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 steps again. Waits for the launch to finish (default 240 s) and returns `ok`, `url`, `reason`, `status`, `elapsed_ms`, `tab_open` and `console`, the same transcript the user sees in the loading screen: every status phase, every command and its container stdout/stderr, the failing step verbatim |+| `POST /dock/close {id}` | removes the app's webview tab and forgets its running state. Does not stop the app's container process; the next launch's serve retires it, or stop it with `/workspace/exec` |+| `POST /dock/refresh {full?}` | re-reads the curated apps.json now (with `full:true` also every display, manifest path and hero); call it after publishing a new apps.json or dockbar.json instead of waiting for the 6-hour poll |++`id` is the dock id (`kicad`, `nb`, `codex`), the wiki repo (`adom/nb-bridge`) or its slug.++```bash+# the loop, from a thread+adom-bridge hd_api '{"method":"POST","path":"/dock/launch","body":{"id":"nb","timeoutSec":300}}'+#   -> ok, url, console[]   (ok:false -> reason + the failing step's output in console)+adom-bridge hd_api '{"method":"POST","path":"/screenshot","body":{"target":"tab","title":"Native Browser"}}'+#   ... change the app in the container, then launch again: relaunch is the default+adom-bridge hd_api '{"method":"GET","path":"/dock/apps"}'+```++What `ok:false` means, by `reason`: a step returned non-zero (its stderr is in `console`,+prefixed `stderr:`), the serve step printed no URL, the URL never answered within the+step's budget, or no webview tab could be opened. A `pending:true` answer means the+launch outran `timeoutSec`, not that it failed: `GET /dock/apps` shows it still+`launching`, and a first install of a bridge legitimately takes minutes.++The launch runs the same code path as a click, in the same shell webview, so a launch+that works through the API works for the user, and vice versa.+ ## Testing a draft  - **Per-app, instant:** Dock settings → Add app → `owner/slug` reads the live@@ -172,7 +212,7 @@ dock-wide one.  | Item | What it does | |---|---|-| **Open** | Same as a left click: reveal the tab, or launch it. |+| **Open** | Same as a left click: relaunch it (close the tab, run the steps again), or launch it. | | **Hard Refresh Open** | The from-scratch relaunch for ONE app. Closes that app's webview if open, forgets its running state and health reading, drops its cached manifest AND display entry (name, brief, hero), re-resolves both from the wiki, then launches with a forced `adom-wiki pkg update <owner/slug> \|\| pkg install <owner/slug>` step ahead of the manifest's own steps, streaming into the launch console like any other step. The app's version-aware serve retires the old instance. Use it when an app just published a fix, when a card shows a stale hero, or when an install looks wedged. | | **Pin to Dock / Unpin** | Pin the card to the top of the rail. | | *(empty rail)* **Refresh list from wiki** | Dock-wide: blanks every card, wipes the display and manifest caches, and reloads the curated list, all manifests and all heroes from scratch. |