Show triage task cards when Plan Review is actively running.
- Render the existing progress affordance for triage cards only when unified progress has an active item.
- Keep enabled-but-idle workflow steps hidden to avoid false active indicators and empty progress shells.
- Cover running, idle, and empty triage progress states in TaskCard tests.
- Add a patch changeset for the published Fusion package.
Files changed:
.../FN-7492-task-card-plan-review-progress.md | 7 +++
packages/dashboard/app/components/TaskCard.tsx | 7 ++-
.../app/components/__tests__/TaskCard.test.tsx | 73 ++++++++++++++++++++++
3 files changed, 86 insertions(+), 1 deletion(-)
Fusion-Task-Id: FN-7492
Fusion-Task-Lineage: 582aea40-8a14-4571-9a7c-e770bc2ab1fb
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Follow-up to #1883 (merged). The Windows Terminal "Help"/version dialogs
on Windows were **not** caused by the embedded terminal (already
guarded) — the real trigger is the **worktrunk integration**.
## Root cause
Worktrunk's CLI is named `wt` (`WORKTRUNK_BINARY_NAME = "wt"`), which
collides with **Windows Terminal** (`wt.exe`, an App Execution Alias
under `%LOCALAPPDATA%\Microsoft\WindowsApps`, on PATH by default on
Windows 11). Worktrunk resolution runs `where wt` → finds Windows
Terminal → runs `"wt.exe" --version` to probe it → **launches Windows
Terminal**, popping the native "Windows Terminal 1.24.11321.0" dialog.
This fired automatically because the Settings UI fetched
`/api/worktrunk/status` on mount even when worktrunk wasn't in use.
## Fix
1. **Don't probe worktrunk automatically** — `useWorktrunkInstallStatus`
only auto-fetches status when the integration is **enabled** (user
opt-in). A plain Settings/dashboard mount no longer probes.
2. **Engine invariant guard** — `probeWorktrunk` refuses to `exec` a
resolved `wt` that is the Windows Terminal alias, covering every
resolution surface (cached/override/PATH/install/settings-route).
Basename is computed host-independently so the guard holds on POSIX CI
hosts too.
3. The #1883 frontend terminal-auto-create guard is retained as
defense-in-depth.
## Tests
- `worktrunk-installer.test.ts` — `probeWorktrunk` returns `{ok:false}`
for a `WindowsApps\wt.exe` path **without** calling exec; still probes a
genuine `wt` elsewhere; `resolveWorktrunkBinary` never execs `--version`
against a Windows Terminal PATH hit.
- `useWorktrunkInstallStatus.test.ts` — no fetch on mount unless
`enabled`.
Report updated with corrected root cause + Symptom Verification +
Surface Enumeration.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Resolved an issue where Windows Terminal “Help” dialogs could appear
when opening the dashboard or Settings on Windows.
* Worktrunk status checks are now gated behind integration enablement
and re-verified on save when turning it on.
* Added an engine safeguard to prevent probing/launching the Windows
Terminal alias during version checks.
* **Tests**
* Expanded coverage for Windows Terminal collision detection and for
opt-in behavior (including enablement toggles) in the status hook.
* **Documentation**
* Updated desktop release notes with the corrected root cause,
mitigations, and verification details.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Two failures surfaced in the full-suite run on main (28697507894):
1. dashboard session-reconnect.test.ts — real bug. The planning
"replays buffered events" test hung at the 15s timeout because
FN-7444 (planning summary deepening checkpoint) now holds the
completed summary behind a mandatory checkpoint question instead
of finalizing on the agent's "complete" payload. The stream route
never observed session.summary and subscribed forever. Fix: respond
to the deepening checkpoint with the reserved proceed option so
finalizePendingSummary runs, session.summary is set, and the
summary/complete events are buffered for SSE replay. Reproduced
locally (15s hang) and verified green (4/4).
2. cli extension.test.ts — loaded-lane CI flake. The built-dist-barrel
fn_task_list test timed out at 5000ms under 4-shard contention while
passing locally (~1.2s body) and in 3 of the 4 surrounding runs.
Root cause is in-test dist-barrel recompilation inside the default
5s timeout (vi.resetModules + vi.importActual of the full core dist
+ fresh dynamic import), the same signature rescued in
FN-6483/FN-6705/FN-6795/FN-6839. Quarantined on sight per the
flaky-test rule (ledger + matching vitest exclude) rather than
widening the timeout or loosening assertions; the sibling
source-@fusion/core test covers the identical truncation invariant.
- probeWorktrunk: also refuse a bare wt/wt.exe override on Windows (resolves to
Windows Terminal via PATH), and tighten the package-dir match from a broad
'windowsterminal' substring to 'microsoft.windowsterminal' so a genuine
worktrunk under an unrelated *windowsterminal* folder is still probed.
- Fix worktrunk enable deadlock/save-race: probe status when the user views the
Worktrees section (not gated on 'enabled', which deadlocked since the toggle is
disabled until status==installed), and re-verify on Save so a fast enable+save
can't silently persist enabled:false. Hook 'refresh' now returns the fetched
status and is exposed.
- Tests: bare-wt refusal, forward-slash Windows Terminal path, unrelated
windowsterminal-folder is probed, and a rerender enabled false->true probe-once
transition; update SettingsModal mocks for the new refresh().
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The 1882/1883 terminal-auto-create guard fixed the wrong subsystem; the
embedded terminal was already guarded. The actual trigger: worktrunk's CLI is
named 'wt', colliding with Windows Terminal (wt.exe) on PATH, so probing it with
'wt --version' launched Windows Terminal and popped its native version dialog —
fired automatically by the Settings worktrunk-status fetch on mount.
- useWorktrunkInstallStatus: only auto-fetch /api/worktrunk/status when the
integration is enabled (user opt-in), never on a plain Settings/dashboard mount.
- probeWorktrunk: refuse to exec a resolved 'wt' that is the Windows Terminal
alias (WindowsApps / WindowsTerminal package dir), covering every resolution
surface (cached/override/PATH/install/settings-route). Basename computed
host-independently so the guard holds when the build host is POSIX.
- Tests for both guards; report updated with corrected root cause + Symptom
Verification + Surface Enumeration.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Three root causes behind CI run 28695362549 failures:
1. droid-cli: 8 tests fail with 'Failed to resolve entry for
@fusion-plugin-examples/droid-runtime'. The droid-cli vitest config
had no source alias for the droid-runtime plugin, so Vite tried to
resolve non-existent dist/ exports.
2. CLI: multiple tests fail with 'Failed to resolve entry for
@fusion-plugin-examples/roadmap'. The CLI vitest config was missing
source aliases for the roadmap plugin (., /server, /roadmap-suggestions).
3. CLI: 73 bin.test.ts tests fail with 'No runTaskImportFromGitLab export
is defined on the ../commands/task.js mock'. The GitLab import command
was added to bin.ts and task.ts but the bin.test.ts mock was not
updated to include the new export.
Keep the task-detail Activity view picker usable during mobile iOS opening taps.
- Add a short visualViewport opening guard for the root-portaled Activity views menu while preserving normal close behavior afterward.
- Reset menu position and guard state consistently on outside click, Escape, selection, task changes, and tab toggles.
- Cover the iOS visualViewport echo, portal/CSS contract, and documentation plus a patch changeset.
Files changed:
.changeset/activity-menu-ios.md | 7 +
docs/dashboard-guide.md | 3 +-
.../dashboard/app/components/TaskDetailModal.tsx | 68 +++++++---
.../__tests__/TaskDetailModal.css.test.ts | 9 +-
.../TaskDetailModal.task-activity-chat.test.tsx | 141 ++++++++++++++++++++-
5 files changed, 210 insertions(+), 18 deletions(-)
Fusion-Task-Id: FN-7485
Fusion-Task-Lineage: 291331c4-453c-481b-b991-41f57db23e3b
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Treat desktop embedded engine managers as automation-capable during startup so the dashboard avoids false remediation.
- Report process-level engine availability when a modern manager can lazily start or is starting project engines.\n- Keep project-scoped status details on /api/engine/status while hiding the dashboard-only unavailable banner in desktop mode.\n- Add dashboard health polling, banner, server health, and changeset coverage for the desktop false-banner regression.\n\nFiles changed:\n .changeset/fn-7476-desktop-engine-banner.md | 7 +++++++\n .../dashboard/__tests__/DashboardBanners.test.tsx | 18 ++++++++++++++++\n .../app/hooks/__tests__/useDashboardHealth.test.ts | 24 +++++++++++++++++++++-\n packages/dashboard/src/__tests__/server.test.ts | 24 ++++++++++++++++++----\n packages/dashboard/src/server.ts | 9 +++++---\n 5 files changed, 74 insertions(+), 8 deletions(-)
Fusion-Task-Id: FN-7476
Fusion-Task-Lineage: d54a9872-252b-44c5-9c6d-6168b65118c7
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Use packaged runtime metadata so desktop update checks do not compare npm releases against an unresolved current version.
- Resolve @fusion/desktop package metadata as a fallback when dashboard code runs from a desktop deployment.
- Fail closed when the current version is the 0.0.0 sentinel in both update-check paths.
- Cover CLI, desktop, and unresolved-version update-check behavior with regression tests.
- Add a patch changeset for the published Fusion CLI package.
Files changed:
.changeset/fn-7471-desktop-update-version.md | 7 ++
.../src/__tests__/cli-package-version.test.ts | 59 +++++++++++++++-
.../src/__tests__/update-check-route.test.ts | 78 +++++++++++++++++++++-
.../dashboard/src/__tests__/update-check.test.ts | 15 +++++
packages/dashboard/src/cli-package-version.ts | 37 +++++++++-
packages/dashboard/src/server.ts | 12 +++-
packages/dashboard/src/update-check.ts | 15 +++++
7 files changed, 216 insertions(+), 7 deletions(-)
Fusion-Task-Id: FN-7471
Fusion-Task-Lineage: ee633b8c-766b-43f3-855d-3ce7abd41550
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
runtime-provider-probes.ts imports probeCursorBinary from
@fusion-plugin-examples/cursor-runtime, but neither the dashboard nor CLI
vitest configs had source aliases for this package. Without the aliases,
Vite tried to resolve the package's dist/ exports which don't exist in a
source checkout, causing every dashboard test that transitively imports
the runtime provider to fail with 'Failed to resolve entry for package'.
This broke 48 dashboard test files in CI run 28561416741 after the cursor
runtime plugin was added without updating the vitest configs.
First-run project setup surfaced a blocking "Agent with this name already exists" error when creating
the default CEO. The default first agent can be created from more than one first-run surface (the
unified ModelOnboarding agent step and the project-setup SetupWizard sub-flow), and agent names are
unique per store, so the second create returned 409. The step's goal — a first agent exists — was
already satisfied, so both onboarding surfaces now treat a name collision as success and advance
instead of blocking. The user still creates the agent; they just aren't punished for the flow offering
it twice.
Separately, the desktop header "Desktop local mode / Switch server" button did nothing: main relays
the click as a `shell:open-connection-manager` IPC (webContents.send), but the preload never forwarded
it to the `window` DOM event ShellContext listens for, so the signal was dropped. Add the preload
bridge so the button opens NativeShellConnectionManager (Local/Remote toggle + remote-server profiles),
letting operators switch between running locally, connecting to a remote server, or a different remote.
Regression tests: SetupWizard advances on an already-exists agent; preload dispatches the window event
on the IPC.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Replace real-timer waits with a deterministic bounded microtask flush for
the fire-and-forget task lifecycle hook chain (FN-5048: no slow tests).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Follow-up to #1878 (merged). While building the Windows desktop
installer locally, `pnpm deploy`'s final temp-dir rename hits `EPERM` on
the orca-managed Windows workspace mount and litters deeply-nested
`deploy_tmp_*` dirs that are painful to remove.
This lets local Windows installer builds redirect the staged production
closure to an external, plain-NTFS path via a new
`FUSION_DESKTOP_DEPLOY_DIR` env var. **CI and the default in-tree
`packages/desktop/deploy` path are unchanged** — the override is opt-in.
Verified locally: with
`FUSION_DESKTOP_DEPLOY_DIR=C:\Users\...\fusion-build\deploy`, `pnpm
--filter @fusion/desktop build` stages the full closure externally
without the EPERM race, and `electron-builder --projectDir <that dir>
--win nsis --x64` produces a signed installer.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Desktop deployment staging can now be configured with an environment
variable, making it easier to customize where build files are prepared.
* **Documentation**
* Added notes about updated desktop deployment behavior on Windows,
including common rename and cleanup issues.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
- Add a one-time copy of the previous default Electron profile into
~/.fusion/desktop-user-data (user-data-migration.ts) so upgrading operators
keep window geometry/session instead of starting fresh (report Issue 8).
- Verify main.js/preload.js/client assets in scripts/build.ts (pre-package
staging) and in the packaged app.asar via desktop-windows.yml, so an
incomplete package fails the build/CI instead of dead-ending at runtime with
a silent missing preload (report Issue 5, recommendation #2).
- Fix two pre-existing stale workflow-assertion tests that expected a bare
'electron-builder --win' after the scripts moved to '--projectDir deploy'.
- Update the field report with a per-issue resolution matrix.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Regenerate pnpm-lock.yaml for the new electron@^33.4.11 CLI dependency so
--frozen-lockfile stops failing every PR-check job.
- Gate the GPU/sandbox-disabling Electron flags (--no-sandbox, --disable-gpu,
etc.) to Windows only via os.platform(); applying them on macOS/Linux was a
security and rendering regression. This also resolves the unused os import
that failed lint.
- Add FNXC comments for the Windows GPU flags, desktop user-data isolation, and
CLI dashboard-server reuse per project comment convention.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
pnpm deploy's final temp-dir rename hits EPERM on the orca-managed Windows workspace mount and litters
deeply-nested deploy_tmp_* dirs. Let local Windows installer builds redirect the staged closure to an
external plain-NTFS path via FUSION_DESKTOP_DEPLOY_DIR; CI and the default in-tree path are unchanged.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Mobile direct-chat dropdowns now identify sessions by conversation title instead of model-name text.
- Render the mobile session trigger with the conversation title or Untitled while preserving the provider logo.
- Remove mobile trigger model-tag styling and assert the model badge stays out of the compact header.
- Document the mobile Chat dropdown behavior and add a patch changeset for the published CLI package.
Files changed:
.changeset/fn-7462-mobile-chat-dropdown-title.md | 7 ++++
docs/dashboard-guide.md | 2 +-
packages/dashboard/app/components/ChatView.css | 8 -----
packages/dashboard/app/components/ChatView.tsx | 8 +++--
.../__tests__/ChatView.core-contracts.test.tsx | 25 +++++++++++---
.../components/__tests__/ChatView.mobile.test.tsx | 39 +++++++++++++++++++++-
6 files changed, 72 insertions(+), 17 deletions(-)
Fusion-Task-Id: FN-7462
Fusion-Task-Lineage: 6a6e2ac3-ecca-4076-81c5-b4e4a65eb286
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Add reports/desktop-release-issues-2026-07-03.md documenting the
regressions observed in the Fusion 0.52.0 Windows desktop release,
including:
- fusion desktop fails to launch because electron is a devDependency
- native launcher walks ancestor dirs and fails on unrelated workspace JSON
- Manage Projects opens Settings instead of overview
- Windows Terminal Help version dialogs on dashboard load
- packaged preload.cjs missing in unpacked release layout
- port collisions and dashboard/gateway drift on Windows
- GPU/sandbox rendering instability on Windows Electron
- isolated user-data path needed
- CLI desktop command not reusing an already-running dashboard server
Also include the two experimental mitigations we applied locally:
- disable GPU/sandbox Electron flags in desktop.ts
- skip embedded local runtime when FUSION_SERVER_PORT is already set
These changes are intended as supporting evidence and starting points
for the Fusion team, not as a final fix.
## Windows: local runtime hung at "Starting local Fusion runtime…"
### Root cause
Desktop startup had two independent persisted sources of truth that
could disagree:
- `desktop-launch-mode.json` — decides whether **main** *starts* the
embedded local runtime
- `shell-connections.json` (`desktopMode`) — decides whether the
renderer **launch gate** *waits* for it
`shell:setDesktopMode` persists shell settings **before** the fallible
`startLocalRuntimeOnce()` / `saveDesktopLaunchMode()`. So a first
"local" selection whose runtime start threw or was interrupted left
`shell=local` / `launch-mode=choose` **permanently**. Every later launch
then sat at "Starting local Fusion runtime…" polling a runtime nobody
started → 30s timeout.
### Fix (defense in depth) — `78f0bc31`
- `initializeApp` reconciles: a completed shell `local` selection is
authoritative → heals the launch-mode file and starts the runtime.
- `onDesktopModeChange` / `onDesktopLaunchModeChange` persist
launch-mode **before** the fallible start so it can't re-desync.
- `DesktopLaunchGate` no longer assumes main started the runtime — if
it's not running/starting it actively `setDesktopMode("local")` before
polling.
- Env-gated startup trace (`FUSION_STARTUP_TRACE`) so packaged builds
(which log nothing) are diagnosable.
- Regression tests: split-brain → runtime starts + file heals;
agreement-on-choose → no start.
**Verified end-to-end under real Electron 35 / Node 22.16**: from the
exact split-brain state the runtime now reaches `RUNNING` and the
launch-mode file heals.
### Also: Windows root-build breakages — `bd24bd4c8`
- `scripts/build-workspace.mjs` "run as main" guard compared
`import.meta.url` to `` `file://${process.argv[1]}` ``, which never
matches on Windows → root `pnpm build` silently no-opped (exit 0, no
dist). Now uses `pathToFileURL(process.argv[1]).href`.
- `spawn('pnpm', …)` without `shell:true` (ENOENT on Windows) in
`build-workspace.mjs` and `packages/cli/tsup.config.ts` → pass `shell`
on win32.
### Notes
- `@fusion/desktop` and `@fusion/dashboard` are private → no changeset.
- Build the Windows installer via the `desktop-windows` workflow
(`electron-builder --projectDir deploy`); local `pnpm deploy` staging
hits an unrelated directory-rename race on managed-workspace
filesystems.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added optional desktop runtime startup tracing (enabled via
environment variable).
* **Bug Fixes**
* Improved local desktop handoff to prevent reload loops and navigate
directly to the embedded local runtime.
* Added “split-brain” healing between persisted launch mode and shell
settings.
* Prevented auto-registration of runtime root/CWD during
desktop/dashboard startup.
* Improved Windows compatibility for CLI/workspace command spawning and
npm install process handling.
* **Tests**
* Expanded local/Electron integration, navigation, and onboarding
regression coverage; improved async flushing for more reliable
initialization.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Two user-facing bugs on Windows:
1. Windows Terminal version dialogs on dashboard load/settings
- The embedded terminal auto-create flow was spawning a PTY on Windows,
which could invoke wt.exe and trigger its native "Help" version
message boxes (Windows Terminal 1.24.11321.0).
- Fix: skip auto-creation of the first terminal tab on Windows. Users
can still create a terminal explicitly; the failure no longer recurs
automatically on every dashboard session.
2. Manage Projects opens Settings instead of project overview
- handleViewAllProjects only reset viewMode; if the previous taskView was
"settings", MainContent rendered the Settings page before the overview
branch because the settings check precedes the overview branch.
- Fix: also reset taskView to "command-center" when leaving a project so
the overview surface (ProjectOverview) renders.
- Thread setTaskView through useProjectActions so the action has access to
the view router.
Tested on Windows 11 with Fusion 0.52.0 dashboard.
- Right dock now defaults to HIDDEN when the operator has no stored preference (readStoredRightDockOpen),
so first-run/onboarding lands on an uncluttered board; users opt in via the Header toggle (persists
"true"). Combined with the existing taskView="board" default and viewMode->"project" transition, first
run lands on the board. Updated the design comments and controller Harness tests (seed the open flag)
and added a focused default-closed assertion.
- useDeepLink deferred the "Project 'X' not found" toast behind a 3s grace window. A project selected
during onboarding is deep-linked via ?project=<id> before the projects list revalidates to include it,
so the eager toast fired even though the project loads a beat later. The deferred toast is cancelled as
soon as the project appears in the list; only a genuinely-absent project past the window still errors.
Added symptom-verification coverage (project appears within window -> no toast) and updated the
StrictMode/unknown-project/App-level tests to advance fake timers.
- Removed the stale ModelOnboardingModal test asserting the research-runs note that was intentionally
removed from onboarding earlier.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Stale SWR hydration entries (per-chat-session/per-room message caches up to
500KB each) were never garbage-collected — readCache returned null for stale
entries but left the bytes on disk, and nothing swept abandoned caches. This
caused localStorage quota exhaustion for users with many projects and chat
sessions.
Three fixes:
- readCache now lazily deletes stale entries (behavior-preserving; every
reader already treats stale as a miss and re-fetches)
- Boot sweep pruneStaleCacheEntries() in DashboardLoader removes any
kb-dashboard-* entry older than 24h before hydration hooks read caches
- Settings > General "Browser Data" panel with a Clear local data button
that wipes all Fusion-owned browser data while preserving the auth token
Also completes the vitest localStorage mock (was missing length/key).
Two false-positive first-run banners:
1. "Select Default Model" recommendation appeared even after choosing a model in onboarding.
The picked model lived only in local state until completeOnboarding ran on the final step, so
selecting a model then exiting/skipping before the last step lost the choice — and
defaultProvider/defaultModelId stayed unset, tripping the recommendation. Now the pick is persisted
immediately in handleModelSelect, and completeOnboarding falls back to the first available model
when the operator connected a provider but never opened the dropdown. Either path leaves a durable
global default so the recommendation no longer misfires.
2. "Install the Fusion CLI" banner showed immediately on first run. Added a 3-day grace period keyed
off the first time the banner becomes eligible; Settings -> General -> CLI Binary still installs on
demand meanwhile, so this only defers the passive nudge.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
