Clarify that desktop CLI launches with the local AI engine by default.\n\n- Document fn desktop as engine-on by default, matching dashboard startup behavior.\n- Clarify --paused keeps the engine process running with automation disabled.\n- Note that desktop has no --no-engine mode and update desktop README launch steps.\n\nFiles changed:\n docs/cli-reference.md | 12 ++++++++++--\n packages/desktop/README.md | 15 +++++++++++----\n 2 files changed, 21 insertions(+), 6 deletions(-)
Fusion-Task-Id: FN-6852
Fusion-Task-Lineage: 3ae2ea10-ede1-4cc5-a3b5-71f692b2a9ac
electron-builder's default @electron/rebuild step walked the desktop app's
whole dependency tree and tried to source-build @homebridge/node-pty-prebuilt-multiarch
(Node-ABI prebuilds only, none for Electron) via node-gyp, which fails on the
Windows runner with "Could not find any Visual Studio installation". The app
bundles no native addon needing an Electron-ABI rebuild (it uses node:sqlite;
keytar/node-pty aren't in the files list and are loaded optionally), so the
rebuild was pointless. Set npmRebuild: false to skip it on all platforms.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
electron-builder's fpm target requires author 'email' in package.json;
without it the arm64/x64 .deb build failed (`Please specify author 'email'`).
Surfaced once the electron-builder --x64 --arm64 flags actually parsed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Second pass after the cache/arch fix unblocked `pnpm build` and surfaced
later-stage failures:
- Desktop packaging called `pnpm --filter @fusion/desktop dist:mac -- <args>`,
but pnpm leaks the `--` separator into the script args. electron-builder
stops parsing at `--`, so `--publish never` was ignored — it auto-published
to api.github.com/repos/gsxdsm/fusion/releases and 404'd. The same leak
dropped Linux's `--x64 --arm64`. Switch all four desktop packaging steps to
`pnpm --filter @fusion/desktop exec electron-builder ...`, which forwards
args cleanly (verified locally).
- Windows CLI signing now skips when WINDOWS_CERTIFICATE_BASE64 is absent,
mirroring the macOS guard (was hard-failing the bun-windows-x64 job).
- Desktop build spawns workspace .cmd bins with shell:true on Windows; Node
rejects .cmd/.bat spawns without a shell (EINVAL) since CVE-2024-27980,
which broke `@fusion/desktop build` on the Windows runner.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Adds macOS code signing and notarization infrastructure (FN-5609), introducing hardened runtime entitlements, electron-builder config for signed builds, and signing-enabled release workflows, with tests validating the configuration and docs covering the signing flow.
Fusion-Task-Id: FN-5609
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Fusion-Task-Id: FN-5609
Adds Linux ARM64 as a target architecture to the desktop release pipeline, including dual-arch release and test-release workflows, electron-builder configuration updates, and corresponding tests and documentation.
Fusion-Task-Id: FN-5608
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Fusion-Task-Id: FN-5608
Add multi-platform updater feed configuration for the desktop app, including Windows, Mac, and Linux feed files with a collector, wired into the release and test-release workflows, plus corresponding tests and documentation.
Fusion-Task-Id: FN-5607
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Fusion-Task-Id: FN-5607
Implements Linux GPG signing for the release pipeline by adding a `sign-linux.sh` helper, wiring it into the release and test-release workflows, including `.asc` signature files in release collectors, and documenting the full signing workflow in CODE_SIGNING.md with a note in the desktop README.
Fusion-Task-Id: FN-5605
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Fusion-Task-Id: FN-5605
Added GitHub Actions workflows for macOS and Linux desktop release artifacts (`release.yml` and `test-release.yml`), wired in new `dist` scripts across platforms, and extended test coverage for electron-builder config and release workflow logic, with updated documentation for the new artifacts.
Fusion-Task-Id: FN-5603
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Fusion-Task-Id: FN-5603
Added Windows ARM64 support to the desktop build pipeline, introducing separate target architecture arrays for x64 and ARM64, configuring electron-builder to produce artifacts for both platforms, and adding tests to assert the correct architecture names.
Fusion-Task-Id: FN-5594
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Fusion-Task-Id: FN-5594
Adds a Windows desktop build job to the release pipeline, wires the desktop artifacts into both release and test-release workflows, includes workflow shape assertions in tests, and documents the Windows release artifacts in the desktop README.
Fusion-Task-Id: FN-5593
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Fusion-Task-Id: FN-5593
Adds Windows desktop packaging support for Fusion, including a new GitHub Actions workflow for building Windows desktop targets, matching build scripts in the root and desktop package, a test for electron-builder configuration, and documentation of the packaging path.
Fusion-Task-Id: FN-5587
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Fusion-Task-Id: FN-5587
The console.log breadcrumbs added while diagnosing the menu also
caused an uncaught "write EPIPE" when the parent terminal pipe was
already closed by the time the user clicked Change Launch Mode.
Now that the flow is verified working, remove the chatter and keep
only the actual error-path logging.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
esbuild was emitting preload.js as ESM (format:"esm"), but Electron
loads preload scripts via its sandboxed Node context, which is CJS.
With an ESM preload, the contextBridge.exposeInMainWorld calls
silently no-op, leaving window.fusionShell / window.fusionAPI
undefined in the renderer — which is why the dashboard always fell
through to "Can't reach the Fusion backend" and DesktopLaunchGate
always logged "window.fusionShell unavailable; bypassing".
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The recently added "Change Launch Mode…" menu wiring made main.ts pass
an extra onChangeLaunchMode callback to buildAppMenu(). The
main-integration test still asserted the old exact-shape {mainWindow,
appName} payload, so it failed once concurrent test load made
ordering matter. Switched to expect.objectContaining so future
buildAppMenu props don't break this test.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replace the renderer-event approach (which silently failed when the
renderer-side listener wasn't yet registered) with an onChangeLaunchMode
callback wired through AppMenuOptions. The callback runs
resetLaunchModeAndReload in main: writes shell settings to clear the
chosen mode, stops the embedded runtime, then navigates the window
directly to the renderer entrypoint with no cached query params so the
launch gate re-prompts.
Also surface the same flow from the dashboard's BackendConnectionErrorPage:
when running inside the desktop shell, the "Can't reach the Fusion backend"
page now offers a "Change Launch Mode…" button alongside Retry, so a user
who chose a broken backend isn't stuck without the Electron menubar.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The close handler hides the BrowserWindow instead of destroying it, so
once closed, subsequent dock or Finder activations were no-ops because
the activate handler only created a new window when mainWindow === null.
Show + focus the existing window if it's hidden so relaunch behaves as
expected. Also add console.log breadcrumbs in DesktopLaunchGate so we
can diagnose why the chooser sometimes appears not to render.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds a "Connection" submenu with a "Change Launch Mode…" item that lets
users switch between Run Locally and Connect to Remote after the initial
chooser. The menu sends shell:reset-desktop-mode-request to the renderer;
the dashboard's DesktopLaunchGate listens, calls the new
shell:resetDesktopMode IPC (clears hasCompletedModeSelection, stops the
embedded runtime), strips the cached serverBaseUrl/shellMode query params,
and reloads so the gate re-prompts.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
In packaged Electron builds, `process.argv[1]` is undefined (Electron loads
the main script via package.json `main`, not via argv), so the bottom-of-file
guard never invoked `run()` and the app started without creating a window.
Also build the dashboard client with `--base ./` so its `file://`-loaded
index.html resolves `./assets/*` from inside the asar instead of the
filesystem root, which was producing a blank white window.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
