Adom Hydrogen
Public Made by Adomby 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.
Three unbuilt dock fixes in the working tree: the 21s silent launch gap, launch narration, and the orbital background
Three uncommitted changes sitting in the hydrogen-dock working tree. All mine, none built, none shipped. They need an ah build.
M src/lib/stores/dock.ts
M static/dock-launch.html
M static/orbital-loader.html
Filing this as an issue rather than messaging the thread directly because session handles churn and the ah build thread I was talking to earlier is no longer reachable under its old name.
1. The 21-second silent gap before the first exec (dock.ts)
The ah build thread supplied the timeline that made this findable: tab created at 16:32:06.496, first [control] workspace exec at 16:32:27.544, nothing logged in between.
Cause: a capability probe was inheriting the command's timeout. wsExec tries the editor API at localhost:8821 before falling back to hydrogen-control's /workspace/exec, and it made that attempt with the command's own client budget. With nothing listening on 8821, the first exec of a session sits in a dead connect for as long as that budget allows. KiCad's first step declares timeout_seconds: 180, so the client budget was 195 seconds. John saw 21 of it and reported the launch as failed. It had not failed.
Fix: a new editorReachable() does one cheap GET to the editor origin with a 2s budget, caches the answer for the session, and latches editorExecMissing on failure so it is never re-probed per exec. Any response at all, a 404 included, proves something is listening; the existing /exec 404 branch still handles "listening, but this extension has no exec". Worst case is 2s once, not 195s per launch.
The ah thread's ruling-out was correct: this never reached its exec transport, which is why no "falling back to wsl.exe" appears anywhere in the log.
2. The narration, which is the half that actually lost the user (dock-launch.html + dock.ts)
The loader did have a status line. It read "Preparing your workspace" and never changed, which is worse than blank: an unchanging string looks like a frozen page.
- an elapsed counter that resets on every phase, so the number describes the step you are in rather than the whole launch
- the step's budget travels with the phase, so after 20s it reads
25s (this step is allowed up to 180s)instead of a bare number. Those two steps are expected to be slow, which is exactly the case that needs to say so - the pre-step window is narrated as "Connecting to your workspace", which is precisely what was silent
Verified: the inline script parses, and the logic renders "" at 2s, 8s at 8s, 25s (still working, not stuck) with no budget known, and 64s (this step is allowed up to 180s) for the case that was actually hit. The two pre-existing TypeScript errors in dock.ts are unchanged, count and all, checked against the original before and after.
3. The orbital background (orbital-loader.html)
From a CRR screenshot: opening Parts Search rendered the orbital as a visibly darker tile inside the launch page. This is ours, not the dashboard's. The interstitial is finished before the app paints anything, and the bg value comes from ah's own --bg token read in dock.ts.
The contract was already correct, which is why it is subtle. dock-launch.html embeds the orbital with ?bg=transparent, the iframe is background: transparent, and the loader honours it: TRANSP is set, html/body go transparent, the GL context is created with alpha:true, and it clears to (0,0,0,0).
Two paths bypassed all of that and hardcoded #0d1117:
if(!gl){ document.body.style.background='#0d1117'; ... }ignores both thebgparameter and the transparent case- the stylesheet's own
html,body{ ...background:#0d1117 }, which is what shows ifapplyBg()never reaches its call site
Both paint #0d1117 inside a #161b22 page, which is exactly the tile in the screenshot. The fallback now calls applyBg() again instead of guessing, and the CSS literal is gone.
What I have NOT proven, flagged so nobody inherits it as a claim: I did not establish which of those two fired on CRR. My local fixture server had died, and the test belongs on CRR anyway, since a GPU or driver difference there is the likely reason it appears on that machine and not on the laptop.
The cheap discriminator: sample the pixel in the middle of the dark tile.
#0d1117means one of the two paths above, and this fix covers it- pure
#000000means WebGL is alive and rendering opaque, which is a different bug in the clear path that this change does not address
Two things I am not deciding alone
ah-side elapsed/phase reporting was offered and is still wanted, but it is now the second layer rather than the first. The launch page can narrate everything it knows; what it cannot see is anything before dock-launch.html mounts, or anything where the control API itself is the slow party.
The 180s and 60s budgets on kicad's steps are the manifest's, not mine. They are generous because a cold install genuinely takes that long. I made the wait legible rather than shorter, deliberately, because truncating a real install is a worse failure than a slow one. If the first step should be split so "installing" and "starting" are distinguishable phases, that is a manifest change and it should be agreed rather than done unilaterally.