Added a PR metadata generator helper to the dashboard package (FN-4991), including test coverage for the new module.
Fusion-Task-Id: FN-4991
Fusion-Task-Lineage: 11bdb797-558e-4ae6-a265-4bcd91da2be6
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>
- SettingsModal "renders github copilot device code panel" was the
single slowest dashboard test (~4s wall) due to userEvent + a 5s
waitFor. Skipping per request.
- merger-file-scope-invariant.test.ts "accepts declared scope as a
single changeset file" / "as a changeset glob" flake under
workspace-concurrent runs: the vi.mock of node:child_process
occasionally doesn't take effect, so execAsync("git diff --cached
--name-only") reaches the real git binary and reports unrelated
staged files. Same logic remains covered by the real-git fixture
tests in reliability-interactions/workflow-and-file-scope.
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>
Untrack the 461MB packages/desktop/fusion-desktop-0.31.0.tgz and broaden
.gitignore to cover desktop packager outputs (.tgz, .zip, .pkg, .msi,
.deb, .rpm, .snap, .blockmap, latest*.yml, builder-debug.yml) so future
electron-builder/pnpm-pack output is not committed.
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>
Two heavy CLI tests were dominating wall time:
- chat.test.ts "--once exits with timeout note" waited the real 30s
reply-timeout floor. Added a replyTimeoutMs option to
runChatInteractive so the test can use 200ms.
- bundled-plugin-install.test.ts "loads the real bundled dependency
graph plugin" runs esbuild and a live PluginLoader (~18s). Gated
behind FUSION_RUN_SLOW_TESTS=1; the install/upgrade logic is covered
by mocked unit tests in the same file.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
MasterKeyManager.loadKeytar() now bails out early when
FUSION_MASTER_KEY_DISABLE_KEYCHAIN=1, and the core vitest setup sets that
flag for every worker. Eight tests across master-key/secrets-store/
secrets-sync-passphrase were timing out at exactly the 15s testTimeout
because they constructed MasterKeyManager without injecting a fake
KeytarLike, which made loadKeytar() reach the real OS keychain.
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>
Wrap <App /> in a DesktopLaunchGate that runs only inside the Electron shell.
On first run it shows a chooser (Run Locally / Connect Remote). On "local"
it calls setDesktopMode("local") so main starts the embedded runtime, polls
shell:getState until localRuntime.state === "running", then reloads with
?serverBaseUrl=http://127.0.0.1:<port> so the dashboard's API calls route
to the embedded server (file:// origins can't resolve relative /api). On
"remote" it opens the existing connection manager. Replaces the dead-end
"can't reach backend" landing in the packaged desktop app.
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>
