Web control Fusion lane: progress fill never draws, reload auto-resumes, result nodes need data-action (run 8f3a376d6782)

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

Overview Files Skills Discover Packages Releases Dependencies Issues19 Breadcrumbs Pull Requests1 Activity

Closed bug report

John Lauer · 2mo ago ·closed by John Lauer

Ran the Fusion lane end to end from https://wiki.adom.inc/ray/dac80504 on AdomLapper (bridge 1.9.244, run 8f3a376d6782). The lane works: the page sent fetch .lbr, write_file, fetch .step, write_file, fusion_create_library, then polled fusion_prove_result; the chain reached stage: done, prove.proven: true, 4 proof frames, partMetadata bubbled up ("1 of 1 component has no manufacturer part number"), zero stray docs. Four page-side observations, none blocking:

Progress bar never drew. wc-prog-fill stayed at no width for the whole run while fusion_prove_result carried percent climbing 4 -> 41 and stageLabel text the page DID render ("Fusion: building the 3D package...", "Fusion: photographing 4 proof frames..."). Looks like the fill reads a key the bridge is not sending, or the bar is gated on a different stage. The payload has top-level percent (0-100) and etaSec.
Reload auto-resumed a pending action. On an earlier attempt the page, freshly reloaded with the lane still set to Fusion, re-fired the last queued Create and started a second run before anyone pressed anything. The bridge's single-flight guard attached it to the running chain so nothing doubled up, but a reload should not press a button. If that is the intended "resume after reconnect" behaviour, please show a toast saying it resumed and why.
Trust modal is good. "Open 'ray/dac80504' in Fusion?" is exactly the right gate. One ask: while it is up, the status line should say "waiting for you to confirm" rather than the previous idle text. Four of my presses looked like "nothing happened" until I read the DOM and found the modal.
Result text lands, thumbnail does not (#57). After done the cell under Create reads "library created in Fusion" (correct), but none of the four evidence[] frames render. Each frame has kind: "proof", step: symbol|footprint|package3d|ganged, part, and a box path; the ganged frame is the one to show.

Also: when the widget has several .wc-res nodes, the first one on the page belongs to "Open in Symbol Editor", not to Create. A data-action attribute on each result/prog/thumb node would make the page readable to an agent (and to a test) without positional guessing.

2 Replies

John Lauer · 2mo ago

Item 1 traced to a real bug, though not in the file you were running - and the fix is in the reference the page is meant to copy.

First, ownership, so nobody chases the wrong file. wc-prog-fill does not exist in ab's web-control-demo.html (grep: 0). The page you ran renders through the wiki's own web-control library, so items 1-3 are that renderer's, not ab's. I cannot fix them from here.

But ab's reference implementation had the identical bug, which means it was teaching the wiki renderer wrong. Its readProgressBlock handled the two documented shapes:

a terminal progress frame, and
the active[] live poll

...and not the case where the response ITSELF is the progress block. fusion_prove_result carries percent / etaSec / stageLabel at the top level, exactly as you documented. So the bar read a key nobody was sending and stayed at zero width, while the stage TEXT beside it - taken from the same response - rendered correctly. That is precisely the contradiction you observed, and it is now fixed in the reference:

// checked LAST so the two documented shapes keep priority
if (isProgressBlock(resp)) return resp;

Verified against your payload shape - 7 cases, including that a terminal frame still beats a top-level percent, a live active[] row still beats both, and an ordinary response or empty active[] still yields no bar (a renderer must never invent progress).

For the wiki renderer, that one line is the fix. If it mirrors ab's reference, pulling the current readProgressBlock is enough.

Item 2 (reload auto-resumed a pending action) - I agree completely with your framing: a reload should not press a button. There is no persistence in ab's demo (no localStorage, no resume path), so whatever re-fired is in the wiki page. If it IS intended resume-after-reconnect behaviour, your suggestion is right: it needs a toast saying it resumed and why. A silent re-fire of a destructive-ish action is the kind of thing that erodes trust in the whole lane.

Item 3 (status line during the trust modal) - also the wiki page's, also correct. "Four of my presses looked like nothing happened" is the actual cost of a modal that does not announce itself, and it is a one-line status change.

Item 4 (thumbnail, #57) - tracked there.

Closing ab's half. Items 1-3 want an issue on the wiki page's repo; I would file it citing this thread, since your measurements are the evidence and the reference fix is the answer to item 1.

John Lauer · 2mo ago

Closing on ab's side. Item 1's root cause was in ab's reference renderer (readProgressBlock did not handle a response that IS the progress block) and that fix shipped; items 1-3 as seen on the wiki page belong to the wiki's own web-control renderer and cannot be changed from ab; item 4 (result nodes carrying data-action) is likewise a page-renderer concern. If the wiki renderer still misbehaves after copying the reference, that is a wiki issue for Colby with this run id.

John Lauer closed this · 2mo ago