app
Adom Bridge (macOS)
Public Made by Adomby adom
Adom Bridge is a small operating system for AI on your Mac: it gives an AI real hands on your native desktop, including your signed-in browser, KiCad, Fusion 360, the shell, files, windows and screenshots. It provisions its own Node and Python so bridges run without touching your setup, and it talks straight to your machine. It ships with Adom Hydrogen and installs standalone too, so if you drive your Mac with Claude Desktop or another AI, this is what gives that AI hands.
← Commit history
Publish 1.9.200
7 files changed
+63−63
package.json+1−1@@ -1,6 +1,6 @@ { "slug": "adom-bridge-macos",- "version": "1.9.199",+ "version": "1.9.200", "type": "app", "brief": "Adom Bridge is a small operating system for AI on your Mac: it gives an AI real hands on your native desktop, including your signed-in browser, KiCad, Fusion 360, the shell, files, windows and screenshots. It provisions its own Node and Python so bridges run without touching your setup, and it talks straight to your machine. It ships with Adom Hydrogen and installs standalone too, so if you drive your Mac with Claude Desktop or another AI, this is what gives that AI hands.", "description": "Install this package in a cloud or Adom Hydrogen container, not on the Mac. It delivers the Claude skill set that teaches an AI every desktop verb (shell, files, screenshots, windows, notifications, KiCad, Fusion 360, browser automation), plus the Linux adom-bridge CLI when one is staged (publishes from the mac release flow are skills-only; the install degrades gracefully and keeps any CLI already on PATH). The CLI drives the Adom Bridge app running on your Mac over the relay; the macOS app itself is the separate DMG in the Download box, not part of this package. Run adom-wiki pkg update to keep the skills current.",
page.json+1−1@@ -1,6 +1,6 @@ { "name": "adom-desktop-macos",- "version": "1.9.199",+ "version": "1.9.200", "type": "app", "description": "Install this package in a cloud or Adom Hydrogen container, not on the Mac. It delivers the Claude skill set that teaches an AI every desktop verb (shell, files, screenshots, windows, notifications, KiCad, Fusion 360, browser automation), plus the Linux adom-bridge CLI when one is staged (publishes from the mac release flow are skills-only; the install degrades gracefully and keeps any CLI already on PATH). The CLI drives the Adom Bridge app running on your Mac over the relay; the macOS app itself is the separate DMG in the Download box, not part of this package. Run adom-wiki pkg update to keep the skills current.", "dependencies": {},
skills/adom-bridge-bridges-guide/SKILL.md+3−3@@ -121,9 +121,9 @@ adom-bridge bridge_list adom-bridge bridge_info '{"name":"puppeteer"}' # Cursor-streaming remote tail -f of the bridge console. The tail also appends the app's-# own append-only lifecycle log (under an "===== AD bridge lifecycle =====" header) which-# SURVIVES respawns and records why a bridge started/stopped: an "[AD] REAPED ... as-# duplicates" line means the app killed it; an "[AD] spawned" line with NO preceding reap+# own append-only lifecycle log (under an "===== Adom Bridge bridge lifecycle =====" header) which+# SURVIVES respawns and records why a bridge started/stopped: an "[Adom Bridge] REAPED ... as+# duplicates" line means the app killed it; an "[Adom Bridge] spawned" line with NO preceding reap # means the process exited on its own (a bridge-side crash). adom-bridge bridge_log_read '{"name":"kicad"}' adom-bridge bridge_log_read '{"name":"kicad","sinceOffset":41230}'
skills/adom-bridge-embedded/SKILL.md+1−1@@ -154,6 +154,6 @@ refuses (`is_hd_managed` guard plus `HD_MANAGED_REFUSAL`) on `disconnect_server`, `remove_server`, `update_server`, the upsert branch of `add_server`, and the relay `server_add` / `server_remove` handlers, because any of those would break the embedded session. The UI shows it as a "Managed-by HD" row with a locked note instead of editable fields. Do not try to work+by Hydrogen" row with a locked note instead of editable fields. Do not try to work around the refusal; the entry is torn down automatically when Bridge reverts to standalone.
skills/adom-bridge-installer/SKILL.md+47−47@@ -1,11 +1,11 @@ --- name: adom-bridge-installer-description: How to invoke the Adom Bridge NSIS installer from a parent installer (especially Adom Hydrogen's setup steps) — silent install, /NOLAUNCH switch for HD-managed bundling, live progress via the structured log file at %TEMP%\adom-bridge-install.log. Use when bundling AD inside another Windows installer, writing an install supervisor / setup-step UI, detecting AD's installed version, or upgrading an existing AD install programmatically.+description: How to invoke the Adom Bridge NSIS installer from a parent installer (especially Adom Hydrogen's setup steps) — silent install, /NOLAUNCH switch for Hydrogen-managed bundling, live progress via the structured log file at %TEMP%\adom-bridge-install.log. Use when bundling Adom Bridge inside another Windows installer, writing an install supervisor / setup-step UI, detecting Adom Bridge's installed version, or upgrading an existing Adom Bridge install programmatically. --- # Adom Bridge installer integration -Adom Bridge (AD) ships as a single NSIS installer:+Adom Bridge (Adom Bridge) ships as a single NSIS installer: ``` Adom Bridge_<version>_x64-setup.exe (~4.8 MB on v1.8.45)@@ -19,13 +19,13 @@ It installs to `%LOCALAPPDATA%\Adom Bridge\` — no UAC prompt, no admin needed. |---|---| | (none) | Installs silently, auto-launches `adom-bridge.exe` after install | | `/S` | Standard NSIS silent flag — same behavior since the top-level `SilentInstall silent` directive already suppresses UI |-| `/NOLAUNCH` | **v1.8.45+** — install silently, do NOT auto-launch after install. Caller is responsible for spawning AD with the desired flags |+| `/NOLAUNCH` | **v1.8.45+** — install silently, do NOT auto-launch after install. Caller is responsible for spawning Adom Bridge with the desired flags | | `/D=<path>` | Install destination override. Default is `$LOCALAPPDATA\Adom Bridge`. Rarely needed | | `<uninstall.exe> /S` | Silent uninstall. The uninstaller lives at `%LOCALAPPDATA%\Adom Bridge\uninstall.exe` | **UI behavior**: zero UI in all cases. `SilentInstall silent` is set at the top of the NSIS script, so even `setup.exe` invoked from Explorer runs without a window. No Welcome page, no progress bar, no Finish page. -**Auto-launch**: by default the installer calls `ExecShell "" "$INSTDIR\adom-bridge.exe"` at the end of POSTINSTALL. Pass `/NOLAUNCH` to suppress this. Used by HD when bundling AD because HD wants to spawn AD with `--embedded --start-hidden --relay-url ... --session-token ...` itself, not let AD launch standalone first and get respawned via single-instance.+**Auto-launch**: by default the installer calls `ExecShell "" "$INSTDIR\adom-bridge.exe"` at the end of POSTINSTALL. Pass `/NOLAUNCH` to suppress this. Used by Hydrogen when bundling Adom Bridge because Hydrogen wants to spawn Adom Bridge with `--embedded --start-hidden --relay-url ... --session-token ...` itself, not let Adom Bridge launch standalone first and get respawned via single-instance. ## Live progress log @@ -50,11 +50,11 @@ Stage tags currently emitted: The uninstaller writes the same log with `[PREUNINSTALL]` / `[POSTUNINSTALL]` stages. -## Recipe: HD's setup-step UI tails the log+## Recipe: Hydrogen's setup-step UI tails the log -Spawn the installer with `/NOLAUNCH`, poll the log file on a 200 ms timer, surface each new line to HD's UI. When `[DONE]` shows up OR the process exits, the install is complete.+Spawn the installer with `/NOLAUNCH`, poll the log file on a 200 ms timer, surface each new line to Hydrogen's UI. When `[DONE]` shows up OR the process exits, the install is complete. -### Rust (HD's installer driver)+### Rust (Hydrogen's installer driver) ```rust use std::{env, fs, path::PathBuf, process::Command, time::Duration};@@ -136,11 +136,11 @@ wait echo "Installer exited" ``` -## Recipe: detect if AD is already installed (and at what version)+## Recipe: detect if Adom Bridge is already installed (and at what version) -The signed NSIS installer (`installMode: "currentUser"`) writes AD's uninstall info to `HKCU` — no admin needed. **⚠ The key name is the product name `Adom Bridge` (WITH a space), NOT `AdomBridge`** (verified live 2026-07-03). Two history notes so you don't chase the wrong key:+The signed NSIS installer (`installMode: "currentUser"`) writes Adom Bridge's uninstall info to `HKCU` — no admin needed. **⚠ The key name is the product name `Adom Bridge` (WITH a space), NOT `AdomBridge`** (verified live 2026-07-03). Two history notes so you don't chase the wrong key: - The NSIS uninstall key = the product name → `…\Uninstall\Adom Bridge` (space).-- AD's OWN launch-time code used to ALSO write an `AdomBridge` (no-space) key to **HKLM** — that write was **DELETED in v1.9.68** (the no-UAC fix). So `AdomBridge` no longer exists anywhere; read `Adom Bridge`.+- Adom Bridge's OWN launch-time code used to ALSO write an `AdomBridge` (no-space) key to **HKLM** — that write was **DELETED in v1.9.68** (the no-UAC fix). So `AdomBridge` no longer exists anywhere; read `Adom Bridge`. ``` HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall\Adom Bridge@@ -167,33 +167,33 @@ fn adom_bridge_installed_version() -> Option<String> { Compare with `semver::Version::parse` to decide whether to skip / upgrade / leave-alone. -## Recipe: HD's setup-step ladder for embedding AD+## Recipe: Hydrogen's setup-step ladder for embedding Adom Bridge -The full pattern HD's setup-step UI runs when embedding AD:+The full pattern Hydrogen's setup-step UI runs when embedding Adom Bridge: ``` 1. Check installed version → registry read above 2. Decide:- no install → install bundled AD- older than bundled → install bundled AD (upgrade)+ no install → install bundled Adom Bridge+ older than bundled → install bundled Adom Bridge (upgrade) same or newer → skip install entirely 3. Run installer (silent + /NOLAUNCH) → tail log, surface to UI 4. Write embedded marker file → %LOCALAPPDATA%\Adom Bridge\embedded.json-5. Delete AD's user-facing shortcuts → Start Menu, Desktop, Startup folder+5. Delete Adom Bridge's user-facing shortcuts → Start Menu, Desktop, Startup folder (so user can't double-launch standalone)-6. Spawn AD with embedded flags → adom-bridge.exe --embedded+6. Spawn Adom Bridge with embedded flags → adom-bridge.exe --embedded --start-hidden --relay-url ws://127.0.0.1:8765 --relay-name adom-hydrogen --session-token <hd's token>-7. Poll AD's direct API for liveness → GET http://127.0.0.1:47200/health+7. Poll Adom Bridge's direct API for liveness → GET http://127.0.0.1:47200/health ``` -Steps 4 and 5 are also covered by AD's installer if you pass `--embedded` at AD's first launch (the embedded-mode detection writes the marker and AD's autostart-upgrade routine handles its own shortcuts). Doing them in HD's installer is belt-and-suspenders.+Steps 4 and 5 are also covered by Adom Bridge's installer if you pass `--embedded` at Adom Bridge's first launch (the embedded-mode detection writes the marker and Adom Bridge's autostart-upgrade routine handles its own shortcuts). Doing them in Hydrogen's installer is belt-and-suspenders. ## Bundle-resource pattern -HD's `tauri.conf.json` should include the AD installer as a bundle resource so it ships inside HD's NSIS installer:+Hydrogen's `tauri.conf.json` should include the Adom Bridge installer as a bundle resource so it ships inside Hydrogen's NSIS installer: ```json "bundle": {@@ -203,18 +203,18 @@ HD's `tauri.conf.json` should include the AD installer as a bundle resource so i } ``` -At runtime HD finds it under its install dir at `$INSTDIR\resources\Adom Bridge_<ver>_x64-setup.exe` — pass that path to the install function above.+At runtime Hydrogen finds it under its install dir at `$INSTDIR\resources\Adom Bridge_<ver>_x64-setup.exe` — pass that path to the install function above. ## Versioning + upgrade strategy -| Scenario | What HD's installer should do |+| Scenario | What Hydrogen's installer should do | |---|---|-| No AD installed | Install bundled version |-| AD older than bundled | Install bundled version (upgrade) |-| AD same as bundled | Skip install step; still spawn with embedded flags |-| AD newer than bundled | Skip install step; spawn with embedded flags. Don't downgrade — embedded mode works for any AD ≥ v1.8.42 |+| No Adom Bridge installed | Install bundled version |+| Adom Bridge older than bundled | Install bundled version (upgrade) |+| Adom Bridge same as bundled | Skip install step; still spawn with embedded flags |+| Adom Bridge newer than bundled | Skip install step; spawn with embedded flags. Don't downgrade — embedded mode works for any Adom Bridge ≥ v1.8.42 | -The bundled AD installer is the minimum supported version for the HD release. HD can spawn newer ADs without modification.+The bundled Adom Bridge installer is the minimum supported version for the Hydrogen release. Hydrogen can spawn newer ADs without modification. ## Exit codes @@ -231,7 +231,7 @@ Treat anything non-zero as a hard failure and surface the log file's last 20 lin GitHub repo is private; GH release URLs 404 for anonymous downloads). Two discovery surfaces, both anonymous: -**Preferred for parent installers (HD setup): the packages API.** Resolve+**Preferred for parent installers (Hydrogen setup): the packages API.** Resolve the latest registered version and its assets in one or two GETs — note `?org=adom` is REQUIRED (the slug exists in multiple orgs; bare URLs 400): @@ -263,7 +263,7 @@ expect 206), never bare HEAD. Asset filenames are dot-form everywhere (`Adom.Bridge_<ver>_windows_x64-setup.exe`); V1 dot-normalized since v1.8.72. The wiki page's `metadata.install.windows_installer` field points at the-canonical filename for the current published version. HD's release build+canonical filename for the current published version. Hydrogen's release build should fetch the latest via the V2-first pattern: ```bash@@ -290,23 +290,23 @@ DOWNLOAD_SHA=$(sha256sum resources/ad-setup.exe | awk '{print $1}') [ "$DOWNLOAD_SHA" = "$INSTALLER_SHA" ] || { echo "SHA mismatch"; exit 1; } ``` -The desktop AD's built-in auto-updater (`src-tauri/src/updater.rs`) walks an+The desktop Adom Bridge's built-in auto-updater (`src-tauri/src/updater.rs`) walks an ordered `MANIFEST_URLS` list — V2 first, V1 fallback — and uses whichever responds first. Once V2 has been the source of truth for a release cycle without incident, V1 will be retired from the pipeline. -`version.json` also carries the SHA256 hash of the installer so HD's build+`version.json` also carries the SHA256 hash of the installer so Hydrogen's build pipeline can verify the download before bundling. ## Asset naming convention (v1.8.113+) The Adom Bridge wiki page hosts TWO distinct types of artifacts per release: -1. **Full AD GUI installer** — the actual desktop app (Tauri window, bundled+1. **Full Adom Bridge GUI installer** — the actual desktop app (Tauri window, bundled bridges, relauncher). One per OS / architecture.-2. **CLI companion binary** — a separate executable that talks to AD over- the relay. Used by HD's WSL2 container, cloud builds, sibling-app- installers, cron jobs. Does NOT contain AD itself.+2. **CLI companion binary** — a separate executable that talks to Adom Bridge over+ the relay. Used by Hydrogen's WSL2 container, cloud builds, sibling-app+ installers, cron jobs. Does NOT contain Adom Bridge itself. Both ship together at the same version (single `python scripts/bump-version.py patch` bumps both, single `cargo tauri build` + `cargo build --release` in@@ -316,9 +316,9 @@ patch` bumps both, single `cargo tauri build` + `cargo build --release` in | Artifact | Wiki asset name pattern | Example (v1.8.113) | |---|---|---|-| Full AD GUI — Windows | `Adom.Bridge_<ver>_windows_x64-setup.exe` | `Adom.Bridge_1.8.113_windows_x64-setup.exe` |-| Full AD GUI — macOS | `Adom.Bridge_<ver>_macos_<arch>.dmg` | `Adom.Bridge_1.8.113_macos_aarch64.dmg` (future) |-| Full AD GUI — Linux | `Adom.Bridge_<ver>_linux_<arch>.AppImage` | `Adom.Bridge_1.8.113_linux_x86_64.AppImage` (future) |+| Full Adom Bridge GUI — Windows | `Adom.Bridge_<ver>_windows_x64-setup.exe` | `Adom.Bridge_1.8.113_windows_x64-setup.exe` |+| Full Adom Bridge GUI — macOS | `Adom.Bridge_<ver>_macos_<arch>.dmg` | `Adom.Bridge_1.8.113_macos_aarch64.dmg` (future) |+| Full Adom Bridge GUI — Linux | `Adom.Bridge_<ver>_linux_<arch>.AppImage` | `Adom.Bridge_1.8.113_linux_x86_64.AppImage` (future) | | CLI companion — Linux | `adom-bridge-cli_<ver>_linux_<arch>` | `adom-bridge-cli_1.8.113_linux_x86_64` | | CLI companion — macOS | `adom-bridge-cli_<ver>_macos_<arch>` | `adom-bridge-cli_1.8.113_macos_aarch64` (future) | | CLI companion — Windows | `adom-bridge-cli_<ver>_windows_<arch>.exe` | `adom-bridge-cli_1.8.113_windows_x64.exe` (future) |@@ -365,11 +365,11 @@ for the CLI binaries: ``` Pre-v1.8.113 readers ignore `.cli` entirely (additive schema; no-`manifest_version` bump required). The desktop AD's own auto-updater only+`manifest_version` bump required). The desktop Adom Bridge's own auto-updater only reads `.windows / .macos / .linux` for its GUI installer URL — it doesn't touch `.cli`. -For HD / cloud / Docker-side fetchers, prefer the typed lookup:+For Hydrogen / cloud / Docker-side fetchers, prefer the typed lookup: ```bash # Best: read the URL out of the manifest (so the filename can evolve)@@ -383,7 +383,7 @@ sudo install -m 755 /tmp/ad /usr/local/bin/adom-bridge ### Windows CLI is shipped with the NSIS (v1.8.114+) -Installing AD on Windows now drops the CLI companion next to the GUI exe+Installing Adom Bridge on Windows now drops the CLI companion next to the GUI exe and adds the install dir to the user's PATH so PowerShell / Claude Desktop / cmd find it without configuration: @@ -407,24 +407,24 @@ adom-bridge-cli status adom-bridge-cli screenshot_window '{"title-contains":"VS Code"}' ``` -The CLI auto-discovers the local AD via direct-API probe at-`127.0.0.1:47200` — no relay needed when AD is on the same box. ~5ms RTT-for compatible verbs; verbs in AD's `cliRequired` list still flow through-a relay if one's running (HD's WSL2 distro typically owns the relay).+The CLI auto-discovers the local Adom Bridge via direct-API probe at+`127.0.0.1:47200` — no relay needed when Adom Bridge is on the same box. ~5ms RTT+for compatible verbs; verbs in Adom Bridge's `cliRequired` list still flow through+a relay if one's running (Hydrogen's WSL2 distro typically owns the relay). **Relay self-detect (v1.8.114+):** `adom-bridge-cli serve` checks for another adom-bridge relay on `127.0.0.1:8766/health` before binding. If one already answers, it prints a friendly note and exits cleanly without-starting a second relay (which would just sit idle — AD's WS client only+starting a second relay (which would just sit idle — Adom Bridge's WS client only attaches to the first one it finds). Pass `--force-bind` to override. PREUNINSTALL strips the PATH entry back out and rebroadcasts so an-uninstall of AD also gets PATH cleanup.+uninstall of Adom Bridge also gets PATH cleanup. ### Legacy alias migration window Releases prior to v1.8.113 published the Linux CLI as `adom-bridge-linux`-(no version, no architecture). HD's WSL2 setup and a few cron-based+(no version, no architecture). Hydrogen's WSL2 setup and a few cron-based installers have that literal filename baked in. To keep them working through the rename, v1.8.113 publishes BOTH names:
skills/adom-bridge-recording/SKILL.md+2−2@@ -5,7 +5,7 @@ description: Record the user's screen with Adom Bridge's consent-gated desktop r # Adom Bridge: Screen Recording -Adom Bridge (AD) records the whole desktop to a `.webm` file through a+Adom Bridge (Adom Bridge) records the whole desktop to a `.webm` file through a **visible, consent-gated recorder HUD**. This skill covers that desktop recorder. Recording a single browser tab is a different feature owned by the Puppeteer bridge (see "Tab recording is NOT this" at the bottom).@@ -115,7 +115,7 @@ stops manually, treat the clip as complete and react accordingly. adom-bridge pull_file '{"filePaths":["C:\\...\\rec-desktop-....webm"], "saveTo":"/tmp"}' ``` -- AD's disk janitor auto-prunes its recordings directory+- Adom Bridge's disk janitor auto-prunes its recordings directory (`%TEMP%\adom-bridge-recordings`) with generous caps: 2 days age, 40 files, 3 GB total. Pruning is oldest-first, so the newest files (including an in-progress recording) always survive. Still: pull anything
skills/adom-bridge-window-identity/SKILL.md+8−8@@ -5,7 +5,7 @@ description: Make a window an AI drives present itself as YOUR app on Windows � # Window identity and the taskbar — Adom Bridge's AUMID verbs -This is an advanced corner of the Windows shell that few APIs expose cleanly. Adom Bridge (AD) wraps it in a small, **generic** verb family: you pass a name + icon + (optionally) a command, and AD makes any window — even one owned by another process — present itself as *your* app across every shell surface. AD knows nothing about which app you are; it applies what you pass.+This is an advanced corner of the Windows shell that few APIs expose cleanly. Adom Bridge (Adom Bridge) wraps it in a small, **generic** verb family: you pass a name + icon + (optionally) a command, and Adom Bridge makes any window — even one owned by another process — present itself as *your* app across every shell surface. Adom Bridge knows nothing about which app you are; it applies what you pass. The motivating case: a bridge drives a **Chrome for Testing** window, which otherwise reads *"Test"* with Chrome's icon in the taskbar and Alt-Tab — two brands and a confusing word. These verbs make it read as your bridge instead. @@ -46,24 +46,24 @@ Registry-only registration gives Alt-Tab + taskbar hover the right name + icon w ## Jump lists — the right-click menu + its header -`desktop_set_window_jumplist {appId, tasks, hwnd?, headerIcon?, headerCommand?, headerName?}` attaches a custom right-click menu to the AUMID. Each task: `{title, target?, args?, iconPath?, description?}` (target defaults to AD's bundled CLI, so a task can just be a verb + JSON). `tasks:[]` clears the list.+`desktop_set_window_jumplist {appId, tasks, hwnd?, headerIcon?, headerCommand?, headerName?}` attaches a custom right-click menu to the AUMID. Each task: `{title, target?, args?, iconPath?, description?}` (target defaults to Adom Bridge's bundled CLI, so a task can just be a verb + JSON). `tasks:[]` clears the list. - Tasks appear on the taskbar right-click menu of **every** window stamped with that AUMID, so a per-session appId gives a per-window menu.-- **The header row** (the app tile above Pin/Close) is a *separate* surface. It is painted from the **window's Relaunch trio**, not the AUMID registry icon — so a `shortcut:false` AUMID shows a generic icon there unless you brand it. Pass `hwnd` + `headerIcon` (and optionally `headerCommand`/`headerName`) and AD stamps the window's Relaunch trio so the header renders your icon **without** a Start Menu shortcut. `headerBranded:true` in the response confirms it stuck.+- **The header row** (the app tile above Pin/Close) is a *separate* surface. It is painted from the **window's Relaunch trio**, not the AUMID registry icon — so a `shortcut:false` AUMID shows a generic icon there unless you brand it. Pass `hwnd` + `headerIcon` (and optionally `headerCommand`/`headerName`) and Adom Bridge stamps the window's Relaunch trio so the header renders your icon **without** a Start Menu shortcut. `headerBranded:true` in the response confirms it stuck. ## Taskbar status — progress + overlay badge `desktop_taskbar {hwnd, progress?, overlay?, flash?}` paints **glanceable status** on any window's taskbar button (works cross-process), so you can show what the AI is doing on the real app window it drives: - `progress:{state:"normal"|"paused"|"error"|"indeterminate"|"none", value?}` — a colored bar (green / yellow = human-in-the-loop like a captcha / red / marquee).-- `overlay:{badge:"adom"|"none", icon?:<.png/.ico path or base64>, avatar?, tooltip?}` — a small badge in the button corner. For Chrome/Edge, that overlay slot holds the **profile avatar**; pass `avatar` and AD composites your mark onto it so the user keeps work-vs-personal.+- `overlay:{badge:"adom"|"none", icon?:<.png/.ico path or base64>, avatar?, tooltip?}` — a small badge in the button corner. For Chrome/Edge, that overlay slot holds the **profile avatar**; pass `avatar` and Adom Bridge composites your mark onto it so the user keeps work-vs-personal. - `flash:"until_focused"|"count"|"stop"` — flash the button for attention. `desktop_flash_window` is the lightweight flash-only cousin. ## Toasts -`notify_user` raises a native Windows toast under AD's own identity (AUMID `inc.adom.bridge`, the Adom logo). See the `adom-bridge-notify` skill for the full toast catalog (progress, sticky reminders, buttons that round-trip a click).+`notify_user` raises a native Windows toast under Adom Bridge's own identity (AUMID `inc.adom.bridge`, the Adom logo). See the `adom-bridge-notify` skill for the full toast catalog (progress, sticky reminders, buttons that round-trip a click). ## Icon formats — why an icon renders as a generic white document @@ -71,10 +71,10 @@ This is the #1 source of "my icon doesn't show." The identity verbs return an ** - **Give a multi-size `.ico`** (16 / 24 / 32 / 48 / 256). A single-size icon looks bad where the shell wants a different size. - **The 256×256 size MUST be PNG-compressed.** Since Windows Vista, a 256px `.ico` entry stored as an uncompressed BMP/DIB renders as the **generic white-document icon** on the jump-list header and taskbar. This is subtle: the icon looks fine in an image viewer but wrong in the shell. Re-export the `.ico` with the 256px size PNG-compressed (most icon tools do this; if unsure, drop the 256px size). `iconCheck` flags this specifically.-- **A per-window `RelaunchIconResource` (the jump-list header) for a `.ico` uses a BARE path** — AD handles this; you just pass the `.ico`. A stray `path,0` (the PE-resource form) breaks a `.ico`, because the shell then looks for "resource index 0 of a PE module," which a `.ico` is not → generic icon. (This was a real bug, fixed AD 1.9.151.)-- **A PE module (`.exe`/`.dll`) is referenced as `<path>,<index>`.** AD uses `,0`; pass your own index if your icon isn't resource 0. A standalone `.ico` is simpler.+- **A per-window `RelaunchIconResource` (the jump-list header) for a `.ico` uses a BARE path** — Adom Bridge handles this; you just pass the `.ico`. A stray `path,0` (the PE-resource form) breaks a `.ico`, because the shell then looks for "resource index 0 of a PE module," which a `.ico` is not → generic icon. (This was a real bug, fixed Adom Bridge 1.9.151.)+- **A PE module (`.exe`/`.dll`) is referenced as `<path>,<index>`.** Adom Bridge uses `,0`; pass your own index if your icon isn't resource 0. A standalone `.ico` is simpler. - **SVG does not work** — the Win32 shell can't load it. Convert to `.ico`/`.png`.-- **The AUMID registry icon (taskbar/Alt-Tab) accepts `.ico` or `.png`; an `.exe` path there renders the blank-doc icon.** A taskbar **overlay** wants a small (~16px) image; a `.png` is ideal (AD converts it to `.ico` internally).+- **The AUMID registry icon (taskbar/Alt-Tab) accepts `.ico` or `.png`; an `.exe` path there renders the blank-doc icon.** A taskbar **overlay** wants a small (~16px) image; a `.png` is ideal (Adom Bridge converts it to `.ico` internally). If `iconCheck.ok` is false, fix the file per `iconCheck.issues` and re-stamp — don't ship the broken icon.