fix: reflect resume drops orchestrator @worker dispatch after restart

[PureWeen]

Summary

• Reflect resume path dropped the orchestrator's @worker dispatch after app restart — fixed by using SendPromptAndWaitAsync + ParseTaskAssignments in MonitorAndSynthesizeAsync
• availableWorkers in the reflect resume path included the orchestrator — fixed by filtering it out (matches both existing dispatch paths)
• session.idle with a stale background-task payload kept sessions stuck in IsProcessing indefinitely — fixed by detecting when backgroundTasksChanged already confirmed empty before the idle arrived

Observed failure

Orchestrator dispatched @worker:Copilot Cli-worker-1 at 21:19:56 UTC, but fire-and-forget synthesis never parsed the response. Worker never received the task. Session timed out 30 min later.

PROMPT session: backgroundTasksChanged shells=0 fired, then session.idle shells=2 arrived (stale CLI snapshot). Fresh 60-min zombie clock started, session stuck in IsProcessing=true.

Test plan

• MonitorAndSynthesize_ReflectResume_WaitsForOrchestratorResponse — verifies await + dispatch wiring
• SessionIdle_StalePayload_NotDeferredWhenBgTasksAlreadyConfirmedEmpty — verifies staleness guard
• Existing tests pass

[PureWeen]

🔍 Multi-Model Code Review — PR #528 (Re-review #3 — v3 sentinel fix)

PR: fix: reflect resume drops orchestrator @worker dispatch after restart
Branch: shneuvil/fix-reflect-resume-drops-worker-dispatch
Latest commit: 081399262 — fix: use string.Empty sentinel to distinguish confirmed-empty from never-seen in IDLE-DEFER
Tests: ✅ 122 targeted tests pass (local)
CI: ⚠️ No checks reported on the branch

---

Status of All Findings

#	Finding	Status
1	availableWorkers includes orchestrator — possible self-dispatch	✅ FIXED — .Where(m => m != pending.OrchestratorName) filter applied
2	Stale idle false-positive — null conflated "never seen" with "confirmed empty"	✅ FIXED — string.Empty sentinel in RefreshDeferredBackgroundTaskTracking; staleness check uses == string.Empty

---

v3 Sentinel Fix Verification

The fix correctly distinguishes three states of DeferredBackgroundTaskFingerprint:

• null → initial/reset state (no backgroundTasksChanged has fired yet, or turn boundary cleared it)
• string.Empty → backgroundTasksChanged explicitly confirmed zero tasks this turn
• non-empty string → backgroundTasksChanged reported active tasks with this fingerprint

ClearDeferredIdleTracking (called at turn boundaries, abort, reconnect, etc.) correctly resets to null, preserving the sentinel design. Only RefreshDeferredBackgroundTaskTracking sets string.Empty when tasks are confirmed gone.

The staleness check: preIdleFingerprint == string.Empty && preIdleTicks == 0 && tracking.Snapshot.HasAny now correctly fires only when backgroundTasksChanged has explicitly confirmed empty — NOT on the first idle with genuine tasks (where fingerprint is still null).

---

Minor Observation (🟢)

🟢 MINOR — Assert.DoesNotContain("= null", method) test is fragile

File: BackgroundTasksIdleTests.cs, RefreshDeferredBackgroundTaskTracking_SetsEmptyStringSentinel_WhenTasksConfirmedGone

The assertion Assert.DoesNotContain("= null", method) matches any = null substring in the method, not specifically DeferredBackgroundTaskFingerprint = null. If a future change adds a legitimate null assignment for a different field in the same method, this test would false-fail.

Suggested fix: Use Assert.DoesNotContain("DeferredBackgroundTaskFingerprint = null", method) for precision.

---

Recommendation

✅ Approve — All findings from all review rounds have been addressed. The reflect resume fix is correct, the orchestrator filter is in place, and the stale idle detection now properly distinguishes confirmed-empty from never-seen using the string.Empty sentinel. The one minor test fragility note is informational.