feat(FN-4000): add task state reconciliation script to fix stuck or inconsi

Added a task state reconciliation script (`scripts/reconcile-task-state-consistency.mjs`) with tests to detect and resolve inconsistencies between the task database and git worktree status, with support for explicit project directories and documented usage in the task management docs.

Fusion-Task-Id: FN-4000
This commit is contained in:
Fusion
2026-05-11 05:56:17 -07:00
committed by gsxdsm
parent e59a740d0f
commit 119ba88a3f
3 changed files with 208 additions and 0 deletions

View File

@@ -145,6 +145,18 @@ Completion gating treats dependencies as resolved only when the dependency task
Auto-merge recovery follow-up creation is deduplicated: Fusion creates at most one active (`not done/archived`) recovery task per unresolved parent failure, and merge-conflict recovery also deduplicates by active branch ownership to prevent parallel duplicate follow-ups on the same conflict branch.
### Landed-task state reconciliation (maintenance)
If a task already shipped (`column: done`) but still carries transient failure metadata (`status: failed`, `error`, `worktree`, `blockedBy`, recovery retry fields), reconcile through supported TaskStore/API paths so SQLite and task JSON stay in sync.
Recommended pattern:
- Audit first (dry-run) for contradictory `done` + transient-failure state.
- Apply reconciliation with TaskStore-backed mutations (for example `moveTask(id, "done")` for done-normalization cleanup).
- Add one durable reconciliation log entry explaining why stale transient fields were cleared (avoid duplicating historical failure logs).
- Re-audit after apply and resolve or explicitly disposition any related stale follow-up tasks.
Do **not** patch `.fusion/fusion.db` directly without synchronizing `.fusion/tasks/*/task.json` through a supported store-backed path.
## Task Execution Modes
Each task has an execution mode that controls how the executor agent approaches the task: