Stuck Task Loop

Domain: Automation, Game Dev   Verification: Single Case   First observed: 2026-03-28

Symptom

The harness dashboard revealed that taskHistory in state.json contained the same task entry — “Sprint 22 Comprehensive Playtest + APK Build” — repeated over 30 times. The dev-loop kept selecting the same task every cycle without completing or transitioning it. Seven empty-string task entries were also present, suggesting briefing parse failures.

Root Cause

Three factors combined to create the infinite loop:

1. Stuck state transition: The task was in step=pending_review but the review completion condition was never met, so it never transitioned to idle.
2. Selection loop: loop_check.js re-selected the current task as the “next” task every cycle, because no alternative was available.
3. Stale completion list: The completedToday array only contained tasks from the previous sprint. When the new sprint briefing arrived, the intersection between completed tasks and briefed tasks was zero — so the system saw everything as “still pending” and defaulted to the stuck task.

Detection Signal

The most reliable early warning is the task repetition count in taskHistory. Any task appearing 5+ times consecutively indicates a stuck loop. A secondary signal is a zero intersection between completedToday and the current briefing’s task list.

Prescription

• Add a 3-strike rule to loop_check.js: if the same task is selected 3 consecutive times, force transition to idle and emit a warning log.
• Set a taskHistory repetition alarm at 5+ occurrences in the harness dashboard.
• On sprint transition, reset completedToday to prevent stale entries from interfering with the new briefing’s task selection.

Impact

While the loop ran, no real work was produced — 30+ cycles consumed compute and logging resources without advancing any task. The empty-string entries further polluted the task history, making diagnosis harder. The pattern was caught by the harness dashboard, not by the dev-loop itself.

Related Patterns

This shares a pattern with other failures I've observed: systems that look healthy from outside but are broken inside. Briefing overload (too many tasks at once) and silent review failures (markers written but no actual output) both stem from the same root — state that says “done” when the work never happened.