After a process crash or restart, tasks retain "specifying" status in the
database but no agent is actually running. These stale statuses consume
concurrency slots, blocking all new triage work. Added a startup sweep
that clears orphaned "specifying" statuses, mirroring the existing
merge status cleanup.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Tasks stuck in triage with status "specifying" had no recovery path when the
agent session crashed mid-specification (before producing an approved spec).
The stuck task detector only monitors tracked sessions, and
recoverApprovedTriageTasks only handles tasks with an approved spec — leaving
unapproved specifying tasks stranded indefinitely.
Add recoverOrphanedSpecifyingTasks to clear status back to null so the next
triage poll picks them up for a fresh specification attempt.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add /api/memory/backend endpoint returning current backend, capabilities, and available backends
- Create useMemoryBackendStatus hook with polling and frontend-friendly interface
- Add MemorySettingsSection to SettingsModal with backend selector dropdown
- Implement capability-aware UI: readonly backends disable save, fallback on unknown types
- Add comprehensive tests for API endpoints and hook behavior
- Update architecture docs with memory backend architecture section
- Add MemoryBackend interface with file and QMD backend implementations
- Implement QMD memory backend with async execution, atomic writes, and fallback to file backend
- Add ProjectMemory class with backend-aware read/bootstrap semantics and conflict resolution
- Wire dashboard memory routes to use backend abstraction instead of direct file I/O
- Add comprehensive tests for memory backend and project memory classes
- Update settings reference and architecture docs for new backend configuration
- Add QmdMemoryBackend class implementing MemoryBackend interface with async agent execution
- Backend executes QMD memory operations via subprocess spawn with configurable command/args
- Graceful fallback to readonly mode on write failures with error logging
- Add readWithoutFetch() and bootstrap() helpers to ProjectMemory for backend-aware read/bootstrap semantics
- Wire QMD backend into TaskStore.create() and memory initialization
- Export QmdMemoryBackend and BackendCapabilities from @fusion/core
- Add comprehensive tests for QMD backend and project memory helpers
- Fix global settings persistence to load from correct path and handle first-run state
- Expose global execution concurrency limit in settings UI and routes
- Harden mission-routes.ts utility-lane invariants with null checks
- Fix mission interview saturation tests with proper cleanup
- Add mission e2e tests covering interview and milestone flows
- Update SettingsModal to show scope indicators (global vs project)
- Update TaskForm model selection handling
- Add scope columns (global/project) to automations table with migration v32
- Implement scope-aware store query APIs in AutomationStore and RoutineStore
- Expose global concurrency limit in Settings UI with dedicated state
- Implement null-as-delete semantics for global settings to allow explicit clearing
- Add getActiveMergingTask cross-process guard to merger for safety
- Add stale status cleanup on startup sweep for crash recovery
- Update mock store in merger tests to include getActiveMergingTask method
- Reorder authentication providers: authenticated shown first, then alphabetically sorted
- Upgrade auth section to grouped/card-style hierarchy with section labels
- Update auth status badges to show '✓ Active' and '✗ Not connected'
- Add 'Authenticated' and 'Available' group labels in auth section
- Improve visual prominence of authenticated providers with subtle green accent
- Add section hint when no providers are authenticated
- Update CSS for new card-based layout with mobile-responsive styles
- Add tests for provider ordering behavior
Multiple engine processes (dashboard + serve) share the same SQLite database
but each has its own in-memory merge queue. Without a cross-process check,
two processes can start merging different tasks simultaneously.
Added store.getActiveMergingTask() as a DB-level check before any merge
starts. The drainMergeQueue defers with pollIntervalMs delay, and both
aiMergeTask and processPullRequestMergeTask have safety-net checks.
Also moved stale merge status cleanup to run regardless of autoMerge setting.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- 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>
