- Add global max concurrent agent limit to settings UI (Scheduling section)
- Add null-as-delete semantics for global settings persistence
- Add fetchGlobalConcurrency and updateGlobalConcurrency API integrations
- Update SettingsModal tests with comprehensive coverage for new features
- Fix lint issues in modified files
SQLite was immediately returning SQLITE_BUSY when concurrent writes
collided (e.g., recordActivity firing from a timer during another write).
Adding a 5-second busy_timeout lets SQLite retry internally before failing.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add skills discovery API (GET /api/skills/discovered) to list available skills with enabled state
- Add skills execution toggle API (PATCH /api/skills/execution) for enabling/disabling skills with project-scoped persistence
- Add skills catalog API (GET /api/skills/catalog) with resilient fallback to fetch skills.sh catalog
- Skills are stored in project settings (.fusion/settings.json) with support for both top-level and package-scoped skills
- Add SkillsAdapter runtime class for skills discovery, catalog fetching, and execution toggle
- Add comprehensive tests for all skills API endpoints
- Update dashboard, serve, and provider-settings commands with skills adapter integration
- Skip flaky streamChatResponse test (matches main branch behavior)
- ProjectEngineManager.startReconciliation() polls for newly registered
projects every 30s and starts their engines without requiring UI access
- Expose global concurrency limit in dashboard settings
- Fix SettingsModal test cleanup
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
An AI review agent (FN-1506) killed the running dashboard by finding
the process on port 4040 via lsof and running kill -9, causing exit
code 137 (SIGKILL) with no logs. This adds multi-layer guardrails:
- AGENTS.md: project-level rule reserving port 4040
- Executor/reviewer system prompts: explicit prohibition on killing
port 4040 processes, with instruction to use --port 0 instead
- Core agent-prompts.ts: same guardrails in all prompt variants
- Reviewer told to issue REVISE if executor violates the rule
- SIGHUP handlers in dashboard.ts and serve.ts for resilience
- Background engine reconciliation in dashboard/serve startup
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add Frontend UX Design template for verifying UI/UX design implementation
- Include WCAG 2.1 compliance checks, design system adherence, and user flow validation
- Add template to WorkflowStepManager with category-based organization
- Update documentation with new template description
- Add tests for template API endpoints and workflow step manager
Root cause: if a merge crashed or the process restarted mid-merge, the
"merging" status was never cleared. On next startup the stale task kept
its "merging" status while the queue moved on to the next task, resulting
in two tasks appearing to merge at once.
Two fixes:
1. Add "merging"/"merging-pr" to BLOCKING_TASK_STATUSES so tasks with
active merge status are not re-enqueued by the retry sweep.
2. Clear stale "merging" statuses during startup merge sweep — no merge
is actually running at engine start, so any such status is a leftover.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The onMerge() path (dashboard "merge now" button) bypassed the
drainMergeQueue serialization, allowing two tasks to enter "merging"
status simultaneously within the same project. Route manual merges
through the same queue so only one merge runs at a time per project.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The triage processor was only checking the global semaphore, not the
per-project maxConcurrent setting. Now it counts all active agents
(in-progress + specifying) and respects Math.min(perProjectAvailable,
semaphoreAvailable) before starting new triage tasks. This matches the
scheduler's concurrency enforcement and prevents triage from consuming
all available slots on startup.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The triage processor was kicking off all eligible tasks simultaneously,
queuing them all on the semaphore regardless of available slots. Now it
checks semaphore.availableCount first and only starts as many triage
tasks as there are free slots. Remaining tasks get picked up on the
next poll cycle (default 10-15s) as slots free up.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Both SettingsModal test files were missing mocks for fetchGlobalConcurrency
and updateGlobalConcurrency, causing the component to throw on mount.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
ProjectEngineManager now creates a single AgentSemaphore and injects it
into all engines via config.globalSemaphore. Previously each engine created
its own semaphore, so the globalMaxConcurrent limit was not enforced across
projects. The semaphore dynamically reads the limit and listens for
concurrency:changed events for live updates.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add PUT /api/global-concurrency endpoint to update globalMaxConcurrent
via CentralCore (validated 1-50 range)
- Make InProcessRuntime semaphore react to live concurrency changes via
CentralCore "concurrency:changed" event — no restart needed
- Add Global Max Concurrent input to Settings modal Scheduling section
with fetch-on-mount and save-alongside-project-settings behavior
- Add updateGlobalConcurrency API client function
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Exclude test files from tsconfig.app.json (matches tsconfig.json pattern)
Test files use loose mocks that don't satisfy strict type checks —
they're validated by vitest at runtime, not by tsc
- Fix highlightDiff.test.ts React 19 type errors (props typed as unknown)
- Remove duplicate fetchTasks import in api.test.ts
- Add Task[] cast in ActivityLogModal.test.tsx mock data
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Remove the anti-pattern where the cwd project was treated as "primary" with a
special engine, and other projects got "secondary" engines through a separate
code path. Every project now gets an identical ProjectEngine created through
ProjectEngineManager.
Key changes:
- Add ProjectEngineManager class to @fusion/engine for uniform engine lifecycle
- Replace manual engine maps in dashboard.ts and serve.ts with engineManager
- Add engineManager to ServerOptions for per-project engine resolution
- Add getProjectContext() helper in routes.ts (replaces 199 getScopedStore calls)
- Merge and automation routes now resolve engine subsystems per-request
- SSE endpoint uses engine's store when available (same EventEmitter)
- Fix tsx not found in dev-with-memory.mjs startup script
- Add invalidateAllGlobalSettingsCaches for cross-project settings sync
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- docs(FN-1626): document PWA home bar gap token and updated bottom-layout contract
- fix(pre-existing): add missing invalidateAllGlobalSettingsCaches export to unblock build
- feat(FN-1626): update regression tests for standalone spacing and PWA home bar gap
- feat(FN-1626): add PWA home bar gap token and update bottom-layout CSS contract
Background stale spec checks now skip tasks that are already in an
active work state (in-progress, in-review, done, merging, merging-pr)
to avoid interrupting work that is underway or complete.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Same bug as MissionInterviewModal: handleSubmitResponse was calling the
API without first reconnecting to the SSE stream. The stream's complete
event closes the connection after each question delivery, so after the
user submits an answer, a fresh connection is needed to receive the
next question or summary.
Also cleans up the stream on API error, matching MissionInterviewModal.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
After handleSubmitResponse posted an answer, the stream connection was
never re-established, so the next question from the server was never
received. The modal would stay on the loading spinner until the user
closed and reopened it (which triggered the resume-session reconnect).
Fix: call connectToMissionInterviewStream(sessionId) before the API
call, matching the pattern used by handleRetryFromError. Also close
the stream on API error to match the error-recovery path, and add
connectToMissionInterviewStream to the useCallback dependency array.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- hasApiKey now only returns true for stored api_key credentials; previously
it fell back to hasAuth() which includes env vars, causing Clear to appear
to do nothing and Save to never appear
- Save button now shows when user types into the key input even if already
authenticated, allowing key updates without clearing first
- Remove unused importFile state variable (TS 6133 lint error)
- Update GitManagerModal tests to pass undefined as projectId argument to
all API mocks, matching the component's project-aware API signatures
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
GitManagerModal was not receiving projectId from AppModals, causing all
git operations to run against the default repo instead of the active
project's repo. Threads projectId through all git API calls.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
