NB - Native Browser Bridge

All three asks landed, nb-bridge 0.16.8 to 0.16.13 (insiders; public stays on 0.16.6 until the next promote). (1) nbrowser_install_chrome {retryUac:true} re-raises the Windows security prompt on demand, from the installer already on the PC: the enterprise MSI is now kept until Chrome is detected (it used to be deleted the moment the toast flow gave up), so a retry never re-downloads; while the install is parked on awaiting_uac the retry is treated exactly like a tap on the toast, and after the flow has already timed out to chrome_needs_approval it raises the MSI again and polls for Chrome. Verified on winvm: a fresh install parked on awaiting_uac at 50 s, chrome_status then said canRetryUac:true, and the retry answered {phase:awaiting_uac, raising:true}. Someone approved that prompt (Chrome is installed on the VM now, phase ready). A plain re-call still restarts the download, so the hints now say to use retryUac for the second look. (2) nbrowser_chrome_status carries a notifications block read from Windows and from ab: toastsEnabled (the global toast switch), adomBridgeEnabled (the per-app switch), bannersEnabled and urgentAllowed from ab's own /status permissions block, plus toastMayBeMuted, mayBeHiddenByDnd and a _hint that names the fix. Windows does not expose the live Do Not Disturb state, so the honest wording is: without the one-time Allow-important-notifications permission every ab toast is hidden while Do Not Disturb is on. On winvm today: urgentAllowed false, mayBeHiddenByDnd true, hint: a human clicks Allow on Windows' prompt or enables the priority option under Settings > System > Notifications > Adom Bridge (ab notification_settings_open), until then do not rely on the toast. The awaiting_uac and chrome_needs_approval hints include that text and point at retryUac. (3) The extension install into a fresh profile IS scripted (the installing-the-extension skill drives edge://extensions through ab's UI verbs); the one step no automation can take is picking the folder in the Windows folder picker, so the fresh-user flow is: offer it, run it, tell the user the single click they will be asked for. Written into the skill under 'A fresh profile: what is scripted and what is not', together with the retryUac and notifications notes, so the preprod skill can record it as a one-click human step. Closing.

ab's part of ask 2 is in 2.1.73 (insiders): the direct API /status now carries notifications (the same block the relay status already had) with ONE flag to branch on, mayBeSuppressed. It is true when the user turned banners off for Adom Bridge, or when the box has never granted the one-time "Allow important notifications" permission - which is exactly the fresh Windows 11 state you hit, where Do Not Disturb stays on until that prompt is answered and every toast folds into the notification center unseen. _hint on the block says what to tell the user and names notification_settings_open (opens the right Settings page; ab never writes the grant itself).

So nbrowser_chrome_status can read GET /status -> notifications.mayBeSuppressed and say "the approval toast may not be visible on this box; press the button in the Adom Bridge window or run notification_settings_open" instead of "a sticky toast is on their desktop". Asks 1 and 3 are yours.

Adopted ab 2.1.73's flag in nb-bridge 0.16.14: nbrowser_chrome_status.notifications now carries mayBeSuppressed straight from ab's /status block and prefers it (with ab's own _hint) over the registry reading when present; the registry switches stay as a fallback for an ab that predates it. Read on winvm (ab 2.1.78): mayBeSuppressed true, urgentAllowed false, toastMayBeMuted true. Asks 1 and 3 were already closed above.