Work tools pane: TASKS list stops applying status transitions mid-session (0/21 complete shown vs 16/21 real)

[arul28]

Symptom (observed live, 2026-07-22 ~19:45 ET)

The Work tools pane's TASKS section (subagents drawer) showed "0/21 complete · 9 active" with 7 tasks spinning "IN PROGRESS" and 5 "PENDING" — while the chat's SDK-side task state (ground truth, verified via the agent harness TaskList at the same moment) had 16/21 completed, 1 in_progress, 4 pending. The 7 "in progress" rows shown were tasks completed hours earlier.

Ground truth vs pane at capture time

	pane showed	SDK truth
completed	0	16
in progress	7 (incl. 6 research tasks done hours before)	1
pending	5 (incl. 5 tasks that had ALSO gone in_progress→completed)	4
total	21 ✅ (matches)	21

Key signal: creations all arrived (count matches); early pending→in_progress transitions for SOME tasks arrived; zero completions ever applied. The pane received a prefix of the event stream and stopped applying updates mid-session.

Session context (for locating logs/rows)

• Chat session id: 5e5081dd-34a8-4910-8ac8-7413d87c0cb7 (Work chat, project ADE, lane c0c51671-7aab-46bc-bcdb-cf199f96bd26).
• The session is a Claude Agent SDK chat that created 21 tasks via TaskCreate and updated them via TaskUpdate across ~6 hours.
• The machine had a power-loss restart mid-session (~17:30 ET) — brain restarted, chat resumed. Task Codex/ade phase 4 5 #1-6 were created BEFORE the restart; their in_progress updates AFTER the restart did render. Later completions (post-restart) did not. So simple "pane died at restart" doesn't fully fit — but restart-related subscription/watermark damage is still suspect Codex/ade phase 4 5 #1.
• The session was continuously busy (long agent turns) all day — relevant to the busy-chat deferral hypothesis.

Where to look (verified pointers, branch ade/github-pingdotgg-t3code-start-skill-c0c51671 / main)

• Ingestion: apps/desktop/src/main/services/chat/agentChatService.ts:15727 — handler filtering subtypes task_started | task_progress | task_updated | task_notification; also :17728 (system:task_progress snapshot path). Trace where TaskCreate/TaskUpdate SDK events become persisted task rows / chat-info snapshots.
• Fold logic: apps/desktop/src/main/services/chat/claudeWorkflowProgress.ts — last-write-wins fold keyed by fold identity; a changed identity mid-stream = brand-new row (known trap from the workflow_progress work, see memory 'SDK bump + workflow rows': fold-identity trap). If task status transitions arrive with a different fold key than creation, updates would orphan instead of applying.
• Rendering: apps/desktop/src/renderer/components/chat/ChatSubagentsPanel.tsx (TASKS_CAP import ~:26, STATUS_LABEL ~:465) — the pane in the screenshot.
• Transport: the chat_event push vs changeset-pump row split (see docs/features/sync-and-multi-device + prior fix 'Mobile chat streaming freshness') — if the pane derives from pushed chat events rather than DB rows, a dropped subscription loses everything after the drop.

How to verify / repro for whoever picks this up

1. Open the chat 5e5081dd-... in the desktop app; compare the TASKS pane against the DB: query the task rows for that session (kvDb / chat-info snapshot) — if the DB rows are correct and the pane is wrong → renderer subscription/hydration bug; if the DB rows are also stale → main-process ingestion bug (much more likely given the pane matches what it was ever sent).
2. Grep brain/daemon logs for that session id around task-update timestamps (updates continued 19:00-23:30 ET on 2026-07-22) for the task_progress/task_updated subtypes at agentChatService.ts:15727 — were they received and dropped, or never received?
3. Repro attempt: long-running Work chat, create N tasks, keep the chat busy with long turns, restart the brain mid-session, then complete tasks — watch whether completions render.

Ranked hypotheses

1. Ingestion watermark / snapshot state damaged by the mid-session brain restart (partial prefix applied, later events dropped as stale/duplicate).
2. Fold-identity mismatch: completions carry a different identity than creations, so last-write-wins never matches the existing row.
3. Busy-chat deferral starving task-row snapshot writes indefinitely (transcript-cap / deferral class, cf. the 512KB chat-active deferral starvation).

Notes

• NOT related to the Work-tab Orchestrator overhaul (PR Orchestration: idempotent delegation, transactional outbox, event-driven completion (ADE-124), light-plan lifecycle, evidence UI #878) — that hardened orchestration manifest delegation events; this pane renders SDK chat tasks, a separate pipeline.
• Screenshot of the stale pane exists in the chat thread for session 5e5081dd-... (user message ~19:45 ET 2026-07-22).

[linear-code]

ADE-130