The bridge now TELLS you Fusion needs a restart, with the numbers to ask the user (1.9.222)

What happened to Adonis, and why it was our fault. He installed ab, already had Fusion open, and drove this bridge from the wiki through web-control. On start the bridge wrote a fresh add-in into Fusion's add-in dirs. Fusion loads add-ins only at launch, so his running Fusion could not see it — and the bridge said nothing. It printed the sync to a console nobody reads and returned a bare fusion_addin_not_responding. So every verb failed, with no way for him to know the product was fine and merely needed a relaunch. John and Colby had to tell him by hand. Once he restarted, the library import worked perfectly first time.

Everything needed to warn him was already known at that moment. The old hint even read "Fix it YOURSELF - never ask the user" — correct for an agent driving headlessly, and exactly wrong when a human is sitting in front of Fusion with documents open.

What web-control now gets back

The failure carries what you need to ask him, instead of a dead end:

{ "success": false,
  "errorCode": "addin_restart_required",
  "restartRequired": true,
  "userMessage": "Fusion needs a quick restart to finish setting up the Adom add-in.
                  We can save your open documents first.",
  "documentsKnown": true, "openDocuments": 3, "unsavedDocuments": 2,
  "documentNames": ["AL8843SP", "Untitled", "bracket"],
  "remedyVerb": "fusion_restart_for_addin",
  "toast": { "delivered": true } }

So the wiki can say exactly what John described: "we need to restart Fusion. You have 3 documents open, 2 unsaved. Can we restart it? We'll save everything for you."

On documentsKnown — the counts come from the add-in, which by definition is not answering in this state. When we cannot reach it, documentsKnown is false and the counts are null. A count we cannot take is never invented, so please branch on documentsKnown rather than assuming a number is present. When an older add-in is still serving we can and do count.

An ab toast fires too

The human is told even if a caller drops the payload — that is the belt to the payload's braces, and it is what Adonis had nothing of. Rate-limited to one per 15 minutes: a dozen failing verbs must not mean a dozen toasts, which would be its own bad experience.

The remedy verb, and the promise it keeps

fusion_restart_for_addin {save: true} saves the open documents, restarts Fusion, waits for the add-in, and reports per-step. Please ask before calling it when a human is present — the payload is built for that conversation.

It keeps the promise the message makes. If a document has never been saved, Fusion has nowhere to write it and would raise its Save box, so the verb refuses:

{ "success": false, "errorCode": "unsaved_named_document",
  "error": "Cannot restart safely: 'tja1042' has never been saved..." }

Discarding someone's work to complete our own restart would have been a worse bug than the silence we started with.

Verified

Four cases: add-in silent (Adonis's exact situation) gives documentsKnown:false with the toast delivered; an older add-in still answering yields 3 open / 2 unsaved with names; a second call within the window suppresses the toast; and a restart with a never-saved document refuses rather than discarding it.

Not yet run end to end on a fresh machine with a pre-running Fusion — that is precisely Adonis's setup and the one I cannot fabricate here. If someone can reproduce his starting conditions, that is the test I want.

One thing I would like your read on, Colby

Right now the bridge asks rather than restarting on its own, because John's standing rule is that restarting Fusion under someone mid-work is rude. If the wiki lane would rather have a autoRestart: true for the unattended case (no human at the keyboard), say so and I will add it — but I did not want to assume that a silent restart is ever acceptable when a person might be looking at the screen.