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 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
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>
- 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>
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>
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>
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>
When a merge completes but auto-recovery moves the task back to
in-review, the retry gating (mergeRetries >= 3) blocked re-processing.
Now canMergeTask always accepts mergeConfirmed tasks and drainMergeQueue
fast-paths them directly to done without re-running the merge agent.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add spec-staleness evaluator to check task specification age before execution
- Guard executor startup and resume to prevent running tasks with stale specs
- Guard scheduler dispatch to skip stale tasks and move them back to triage
- Add comprehensive tests for spec staleness detection (7d/14d thresholds)
- Add getFusionDir mock for executor staleness check tests
- Replace blocking execSync calls with async execAsync in executor.ts for user-configured commands
- Convert self-healing.ts worktree status checks to async to avoid blocking the event loop
- Update step-session-executor.ts to use async worktree operations
- Refactor worktree-pool.ts for fully async worktree creation, cleanup, and listing
- Convert pi.ts agent session handling to async execution
- Update all corresponding tests with async/await patterns
- Add changeset for @gsxdsm/fusion patch release
- Add context-overflow detection and recovery in step-session executor with same parity as single-session
- Implement step resumption from overflow checkpoints with accumulated context replay
- Add overflow state tracking and recovery logging for diagnostics
- Harden single-session executor overflow recovery with improved state management
- Update appendAgentLog parameter signatures across executors
- Add comprehensive tests for context overflow scenarios in both execution modes
- Add memory entry documenting the unified context-limit recovery approach
- Add eslint-disable comments for unused parameters in truncateVerificationOutput and summarizeVerificationOutput
- Preserve functions that may be useful for future diagnostics while silencing no-unused-vars warnings
- Add summarizeVerificationOutput helper function to condense test output
- Update runVerificationCommand to use summarization for cleaner merge reports
- Improve readability of test failure summaries in the dashboard
- Convert hasRecoverableGitWork from sync execSync to async execAsync
- Update recoverNoProgressNoTaskDoneFailures caller to await the method
- Update self-healing tests to work with async method and execAsync mock
- Add exec and promisify imports to self-healing.ts
- Fix mock to include exec export for promisify compatibility
The FN-1598 merger.ts async conversion introduced an escalation strategy where
attempt 3 uses -X theirs and succeeds when AI fails. The tests were expecting
the merge to fail after 3 AI attempts, but now attempt 3 succeeds via the
theirs strategy.
This commit fixes the test mocks to make the -X theirs merge fail so all
3 attempts exhaust and the function throws as expected.
