Restore the stable extension suite by quarantining only the dist-barrel recompilation case.
- Move the built @fusion/core dist-barrel extension test into its own file.
- Re-admit extension.test.ts while keeping the isolated dist-barrel file quarantined.
- Update the quarantine ledger and velocity baseline to reflect the narrowed quarantine.
Files changed:
docs/test-velocity-baseline.md | 10 +-
.../src/__tests__/extension-dist-barrel.test.ts | 230 +++++++++++++++++++++
packages/cli/src/__tests__/extension.test.ts | 103 +--------
packages/cli/vitest.config.ts | 5 +-
scripts/lib/test-quarantine.json | 4 +-
5 files changed, 247 insertions(+), 105 deletions(-)
Fusion-Task-Id: FN-7530
Fusion-Task-Lineage: 7b07540f-689b-4133-b590-a39427095397
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Update the App test to assert the open desktop search panel state after rerender.\n\n- Avoid re-clicking the desktop search toggle after the non-mobile panel stays open across rerender.\n- Assert the branch-filter selects directly while the search panel remains rendered.\n\nFiles changed:\n packages/dashboard/app/components/__tests__/App.test.tsx | 9 +++++++--\n 1 file changed, 7 insertions(+), 2 deletions(-)
Fusion-Task-Id: FN-7529
Fusion-Task-Lineage: 1495f872-d262-4ea4-83f2-5a53ecf7a202
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Require generated task specs to summarize the requested before-to-after transformation near the top.
- Add a Before → After Transformation section to standard and fast planning prompt templates.\n- Document the new task definition section and cover it with prompt regression tests.\n- Add a patch changeset for the published Fusion package.\n\nFiles changed:\n .changeset/fn-7499-before-after-transformation.md | 7 +++++++\n docs/task-management.md | 1 +\n packages/core/src/__tests__/agent-prompts.test.ts | 17 +++++++++++++++\n packages/core/src/agent-prompts.ts | 25 +++++++++++++++++++----\n packages/engine/src/__tests__/triage.test.ts | 20 ++++++++++++++++++\n 5 files changed, 66 insertions(+), 4 deletions(-)
Fusion-Task-Id: FN-7499
Fusion-Task-Lineage: d049b5d6-a4bc-40dd-831d-04a11f9dc2cf
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
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 -->
## Summary
Resolves the two failures from the full-suite run on `main` ([run
28697507894](https://github.com/Runfusion/Fusion/actions/runs/28697507894)).
### 1. dashboard `session-reconnect.test.ts` — real bug (deterministic)
The planning *"replays buffered events and supports reconnect catch-up"*
test hung at the 15s timeout.
**Root cause:** FN-7444 (planning summary deepening checkpoint) now
holds the completed planning summary behind a mandatory *"Would you like
to go deeper?"* checkpoint question instead of finalizing when the agent
returns a `"complete"` payload. `continueAgentConversation` calls
`setPendingSummaryCheckpoint`, which sets `session.pendingSummary` + a
checkpoint question and leaves `session.summary` undefined. The SSE
stream route's summary-emit path is therefore never reached, so it
subscribes waiting for a `"complete"` event that never arrives → 15s
hang.
**Fix:** respond to the deepening checkpoint with the reserved proceed
option (`PLANNING_DEEPEN_PROCEED_OPTION_ID`) so `finalizePendingSummary`
runs, `session.summary` is set, and the summary/complete events are
buffered for SSE replay.
- Reproduced locally: 15s timeout before, 4/4 green after.
- `routes-planning.test.ts`, `session-persistence-roundtrip.test.ts`,
`session-reconnect.test.ts` → 116/116 green.
### 2. cli `extension.test.ts` — loaded-lane CI flake (quarantined on
sight)
The built-dist-barrel `fn_task_list` test timed out at 5000ms in shard
4/4 while passing locally (~1.2s body) and in 3 of the 4 surrounding CI
runs.
**Root cause:** in-test dist-barrel recompilation (`vi.resetModules` +
`vi.importActual` of the full `@fusion/core` dist barrel + a fresh
dynamic `import("../extension.js")`) inside the default 5s test timeout.
That work is CPU-bound and degrades non-linearly under 4-shard CI
contention — the same loaded-lane signature rescued in FN-6483 / FN-6705
/ FN-6795 / FN-6839.
**Action:** quarantined on sight per the *Flaky Tests Are Quarantined on
Sight* rule — ledger entry in `scripts/lib/test-quarantine.json` plus
the matching `exclude` in `packages/cli/vitest.config.ts`, in the same
commit. No widened timeout, no retries, no loosened assertions (all
forbidden by the rule). The sibling source-`@fusion/core` test *"bounds
large column-filtered listings"* covers the identical truncation
invariant through source, so the dist-barrel slice's marginal coverage
is dist-resolution, which has been stable.
⚠️ **Collateral:** the file-granular exclude also drops the ~68
otherwise-stable tests in `extension.test.ts` until a rescue before the
2026-07-18 deletion deadline. This matches the project's quarantine
ratchet; the file has been rescued 4× before.
## Verification
- `packages/dashboard` `session-reconnect.test.ts` → 4/4 ✅
- `packages/dashboard` `routes-planning` +
`session-persistence-roundtrip` + `session-reconnect` → 116/116 ✅
- `pnpm test:gate` (engine-core 321 + ci-shape 63) → ✅
- `pnpm test:gate` appeasement-check + changeset-format-check → ✅ (no
changeset needed: test-only changes to a private package)
- cli `extension.test.ts` confirmed excluded post-quarantine.
## Notes
- No changeset: both changes are test-only and don't affect published
`@runfusion/fusion` behavior.
- No production code changed.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved test reliability by keeping a known flaky CLI test out of the
main run, reducing CI timeout-related failures.
* Updated reconnect behavior coverage to better match event replay
expectations after planning updates.
* **Tests**
* Adjusted dashboard session reconnect tests to validate the full
reconnect-and-replay flow more accurately.
<!-- 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.
## Summary
Fixes three root causes behind CI run
[28695362549](https://github.com/Runfusion/Fusion/actions/runs/28695362549)
failures on main.
### 1. droid-cli: missing `@fusion-plugin-examples/droid-runtime` alias
(8 tests)
The droid-cli `index.test.ts` imports
`@fusion-plugin-examples/droid-runtime`, but the droid-cli vitest config
had no source alias. Without the alias, Vite tries to resolve the
package's dist/ exports which don't exist in a source checkout, causing
every droid-cli test that touches the droid runtime to fail.
**Fix:** Added `resolve.alias` entries for
`@fusion-plugin-examples/droid-runtime` and `/probe` subpath to
`packages/droid-cli/vitest.config.ts`.
### 2. CLI: missing `@fusion-plugin-examples/roadmap` aliases
The CLI imports the roadmap plugin (`roadmap-routes.ts`,
`roadmap-suggestions.ts`), but the CLI vitest config was missing source
aliases for `@fusion-plugin-examples/roadmap` and its `/server` and
`/roadmap-suggestions` subpaths.
**Fix:** Added three regex aliases to `packages/cli/vitest.config.ts`.
### 3. CLI: missing `runTaskImportFromGitLab` mock export (73 tests)
The GitLab task import command was added to `bin.ts` and
`commands/task.ts` but `bin.test.ts`'s `vi.mock("../commands/task.js")`
factory was not updated to include the new export, causing 73 tests to
fail with `No "runTaskImportFromGitLab" export is defined on the
"../commands/task.js" mock`.
**Fix:** Added `runTaskImportFromGitLab: vi.fn()` to the hoisted
`commandMocks` and the mock factory in
`packages/cli/src/__tests__/bin.test.ts`.
## Verification
- droid-cli: 232 passed
- CLI bin.test.ts: 74 passed
- CLI broader tests (11 files): 146 passed, 90 skipped
- CLI dashboard-tui tests: 72 passed
- Gate suite (`pnpm test:gate`): 319 engine-core + 63 CI-shape passed
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved test environment module resolution so local source packages
load correctly during CLI and Droid CLI test runs.
* Added support for additional command routing in test coverage, helping
import-related flows dispatch to the right handler.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
- 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>
