Tighten the executor agent guidance and the fn_run_verification tool guidance so
verification stays scoped to changed files instead of running the full workspace
test suite, which (for a foundational-package edit) reverse-expands across the
whole workspace and stalls the task.
- agent-prompts.ts: remove the "during final integration" blanket permission to
run workspace-wide suites; name the forbidden full-run commands explicitly.
- run-verification-tool.ts: strengthen BOUNDED_VERIFICATION_GUIDANCE to forbid
`pnpm test:full` / `pnpm verify:workspace` / whole-package runs as verification.
Engine + core typecheck pass; run-verification-command and executor-review-verdicts
prompt-assertion suites stay green (93 tests).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The per-test `createTaskStoreTestHarness` recreated a TaskStore from scratch
every test — mkdtemp ×2 + new store + recursive rm with retry backoff — which
dominated wall-clock across these high-test-count files. Switch the files that
tolerate a shared store to `createSharedTaskStoreTestHarness`, which builds the
store once and resets state between tests via full table truncation + FTS
rebuild + filesystem reset, preserving isolation.
Measured on store-create.test.ts (53 tests): 4.44s → 1.78s wall
(test execution 3.59s → 0.93s, ~3.9x). Full @fusion/core suite stays green
(346 files, 6236 tests) and typecheck passes.
19 files that test disk persistence / migration / workflow-definition state are
incompatible with a shared in-memory store and were intentionally left on the
per-test harness.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Read hasResumableProgress from latestTask (the store snapshot fetched
at ~9226), not the frozen dispatch-time task param, so a freshly
dispatched task that commits step progress mid-session is preserved on
a hard-cancel teardown — not just the re-dispatch case (greptile P1)
- Add companion regression test for the fresh-task-with-in-session-progress
case, which fails against the stale-task snapshot (greptile P1)
- Reformat the requirement comment block to the canonical FNXC heading
(FNXC:WorkflowLifecycle yyyy-MM-dd-hh:mm:) convention (CodeRabbit)
Fusion-Task-Id: FN-6722
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
When the engine aborted in-flight work mid-execution and bounced the task
back to `todo`, the single-session teardown cleared the task `branch` and
re-queued without `preserveResumeState` — resetting every step to `pending`
(store.moveTaskInternal resetAllStepsToPending) and dropping the pointer to
the commits already on the task branch. The next dispatch then re-planned
from Step 0 and the committed work was stranded, observed as FN-6722 losing
all its progress and getting stuck in todo.
The teardown now keeps the branch and moves with `preserveResumeState`
whenever the task has resumable step progress, matching the sibling
step-session (executor ~8065) and pause-park (executor ~1826) paths, so
execute() resumes onto the existing branch from the first incomplete step.
The worktree is still removed to free its concurrency slot (FN-6782) — only
the durable pointers (branch + step state) are kept.
Adds a regression test driving the exact single-session catch teardown.
Fusion-Task-Id: FN-6722
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Many loading states rendered bare "Loading…" text with no spinner
element, and a couple rendered an unstyled `loading-spinner` div with no
matching CSS (invisible). The global spin animation was never broken —
it rotates in Chromium and WebKit — so prior transform-box edits chased
a non-bug, validated only by a string-matching CSS test.
Add a shared <LoadingSpinner> (self-contained animated SVG, no
lucide-react import so it survives partial test mocks) and adopt it
across ~47 loading placeholders so every loading state shows a
consistent animated spinner. Includes a component test that asserts the
svg carries the animate-spin utility.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
discoverDroidModels ran `droid models`/`droid model list`, which aren't real
droid commands — they parse as a prompt and launch a persistent
`droid exec --stream-jsonrpc` agent session that never exits, leaking a process
per call. The dashboard reloads the droid extension on every chat-send, so these
piled into dozens of orphaned `droid` processes.
Switch discovery to parse `droid exec --help` (lists Available + Custom models,
exits cleanly) via new parseDroidModelsFromHelp, and add a SIGKILL-on-timeout
guard so a wedged spawn can never leak. Verified against the real binary: 46
models, 0 leaked processes.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Move the left sidebar collapse control into the footer so it sits above Settings with row-style behavior.
- Replace the floating border collapse button with a footer row button that keeps accessible expanded/collapsed labels.
- Retokenize collapse toggle CSS around shared sidebar item styling and remove the obsolete floating modifier.
- Extend sidebar tests and dashboard guide coverage for the footer placement and collapsed rail behavior.
Files changed:
docs/dashboard-guide.md | 4 +-
.../dashboard/app/components/LeftSidebarNav.css | 24 ++--------
.../dashboard/app/components/LeftSidebarNav.tsx | 32 ++++++-------
.../components/__tests__/LeftSidebarNav.test.tsx | 54 ++++++++++++++++++++--
4 files changed, 72 insertions(+), 42 deletions(-)
Fusion-Task-Id: FN-6847
Fusion-Task-Lineage: 5d7781a1-afc9-4e5c-bf7b-0648bb874285
Refine the desktop list split pane so narrower sidebars still show readable task titles.
- Lower the list-view sidebar minimum width from 280px to 200px across resize and keyboard handling.
- Clamp desktop list task titles to two wrapped lines with overflow protection.
- Update ListView coverage for the smaller persisted/keyboard minimum and title-clamp CSS.
Files changed:
packages/dashboard/app/components/ListView.css | 10 +++++++++-
packages/dashboard/app/components/ListView.tsx | 2 +-
.../app/components/__tests__/ListView.test.tsx | 22 +++++++++++++++++-----
3 files changed, 27 insertions(+), 7 deletions(-)
Fusion-Task-Id: FN-6831
Fusion-Task-Lineage: ac3e455d-8cb0-4f42-ac5c-d735e56d2b89
Ensure the Command Center theme selector renders above neighboring views while preserving mobile in-flow behavior.
- Add an open state class to the theme dropdown root for local stacking control.
- Raise the open dropdown and popover above Command Center sibling cards without exceeding app chrome layers.
- Cover desktop elevation and mobile static popover behavior in ThemeDropdown tests.
Files changed:
.../dashboard/app/components/ThemeDropdown.css | 15 +++++++-
.../dashboard/app/components/ThemeDropdown.tsx | 2 +-
.../components/__tests__/ThemeDropdown.test.tsx | 40 ++++++++++++++++++++++
3 files changed, 55 insertions(+), 2 deletions(-)
Fusion-Task-Id: FN-6826
Fusion-Task-Lineage: ff43c06e-f3a7-4b4c-8e29-46deb66e9145
Move externalEngines.delete(projectId) to immediately after acquiring the
singleton lock instead of after engine.start() succeeds. If a project was
marked external, the holder exits, acquire succeeds, but start() then throws,
the success-path delete never ran and hasRunningEngine() reported a phantom
engine forever. Added a regression test for the failed-takeover path.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Stop reconciliation/startAll/onProjectAccessed from warning every tick for
externally-owned engines: swallow EngineAlreadyRunningError in the outer
catches (it's expected and already logged once in createAndStart)
- Add FNXC:DashboardHealth requirement-trace comments on the externalEngines
field and the dashboard hasRunningEngine health check
- Add regression test: reconciliation stays quiet across ticks for an
externally-owned engine (inner refusal logged once, outer failure suppressed)
- Add regression test: hasDashboardEngine legacy fallback to getAllEngines when
hasRunningEngine is unavailable on the manager
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Document the false "engine not running" banner root cause and fix as a
docs/solutions learning, and add an "Engine Singleton Lock" entry to
CONCEPTS.md: a failed per-machine lock acquisition is proof an engine is
running elsewhere, not "no engine."
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- FNXC requirement-trace comments on the stepwise workflow-step seam,
the flowToIr v2-signal/byte-identity contract, and TaskForm's
optional-steps create-mode behavior
The dashboard's engine-availability health check only counted engines
this process started. A second launch (e.g. `pnpm dev dashboard`
alongside an already-running `fusion`) is correctly refused the
per-machine engine singleton lock, so its engine map stays empty and
the dashboard showed a false "engine not running" banner even though an
engine was live on the machine.
ProjectEngineManager now records projects whose singleton lock is held
by another process (via EngineAlreadyRunningError) and exposes
hasRunningEngine(), which the health endpoint consults so the banner
reflects machine-level truth. Reconciliation still retries so this
process takes over if the other exits, and the "refusing to start" log
fires once per project instead of on every 30s reconciliation tick.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Dropdown: aria-multiselectable, drop dead aria-labelledby, ArrowUp opens panel
- Dirty-state: NewTaskModal tracks enabledWorkflowSteps so toggles trigger discard prompt
- TaskForm: reset optionalStepsLoading on the no-workflow early return
- Node editor: pass plugin step templates into the optional-steps panel (both layouts)
- FNXC requirement comments on the new optional-steps components
- Plugin skills now respect project-settings enable/disable toggles
(discoverSkills consults getSkillSettingState, falling back to the
plugin's declared default) so toggleExecutionSkill writes persist
- readSkillContent returns synthesized content for plugin-contributed
skills (name + description + provenance) instead of a silent blank
panel, since their path is a virtual runtime-materialized path
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Selecting a gated deep lane explicitly (`vitest run --project dashboard-app`
or `--project dashboard-api`) without FUSION_DASHBOARD_DEEP=1 matches zero
files and exits green in milliseconds — a silent no-op that reads as a passing
run. Emit a loud console.warn so a manual invocation isn't mistaken for
coverage. Exact token match avoids firing on the curated `dashboard-app-*`
shard projects; the deep scripts set the flag, so it never fires through the
intended entry points.
Argv parser validated against space/equals forms, both lanes, every curated
shard, and the default no-`--project` run (10/10).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
