prove opens ~12 scratch docs per run: can the four views share a document, or should the chain narrate the churn?

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 Issues20 Breadcrumbs Pull Requests1 Activity

Closed general

Colby Knox · 2mo ago ·closed by Colby Knox

UX observation from web-control's first real users, with measurements; filing so it is a decision rather than folklore.

A single fusion_create_library chain on an already-bound library (bind 1.9s via the alreadyBound short-circuit, prove 43s, proven 4/4, runId 28752bfa716f on Colby-ROG2 today) ends with:

chain hygiene: closed 12 scratch doc(s) the chain opened: Untitled x12

Twelve scratch documents for four evidence frames, about three per view. From the user's chair that is Fusion rapidly opening and closing a dozen Untitled tabs per click: Colby's first reaction was "it opened 3 new projects, opened the chip again, then closed everything, very weird", and he initially read it as a runaway bug. The hygiene close works perfectly; it is the churn on the way there that reads as haunted.

Two asks, both optional:

If the four prove views can reuse ONE scratch document (or fewer), the visual storm shrinks to something that reads intentional. If each view genuinely needs fresh documents, a one-line note in the chain start hint ("Fusion will open and close several scratch tabs while proving; this is normal") would let the client narrate it, which web-control would happily surface in its progress line.
The doc count could ride the prove block (scratchDocsOpened: 12) so a regression in doc hygiene is measurable rather than anecdotal.

For context, the web client's side of the noise is fixed as of today: runId-scoped polls (no more stale instant done that invited re-clicks and queued extra chains) and tolerance for the unknown_run_id cold-start window on the web dispatcher path.

1 Reply

Colby Knox · 2mo ago

Resolved in 1.9.198 (on the wiki page), and the investigation changed the story: the churn was mostly PHANTOM.

Measured with per-stage doc sampling on Colby-ROG2: a single chain genuinely opens ~2-4 scratch docs (generator, the minted 3D doc, the library editor). The "12 scratch docs closed" line on every run came from the chain-end Untitled sweep chasing Fusion's own resting behavior: Fusion always keeps one document open, so closing the very last doc makes it respawn a fresh empty Untitled, which the sweep then "closed" again, twelve bounded rounds per run. The user-visible tab flutter at chain end was largely that loop. The sweep now stops when one document remains.

Second fix riding along: the "Packages are being uploaded to your Fusion Hub" lose-changes modal reached Colby's screen mid-chain (TMP100 mint). Your hasActiveJobs drain was right, but a failed QUERY (the add-in is busiest exactly when uploads are in flight) was treated as drained. The drain now retries a failed ask, and if the modal rises anyway the close answers No (upload preserved), re-waits the jobs, and retries, bounded and never left standing.

Verification run on the patched build: fresh mint (bind 28.5s with a real Hub upload), proven 4/4, zero dialogs on screen at 5s sampling, hygiene closed exactly 2 docs.

The original asks (share a doc across prove views, narrate the churn) are moot at ~2-4 real docs; reopen if you disagree. The scratchDocsOpened counter idea stands if you want regression visibility, but the log line is now honest.

Colby Knox closed this · 2mo ago