Tasks are not syncronized with cli task tracker #7118

Before you start

• I searched existing issues and this is not a duplicate. 我已搜索过现有 issue。

What happened? 发生了什么？

In 0.10.3 again I see tasks that are not in sync with model tracking tasks

Steps to reproduce 复现步骤

MacOs 15.5
codew 0.10.2

For some reason after several turns (some of them were manually cancelled by user) I see a list of tasks in the tracker, but still model can find none and /task list shows none also

Codewhale version 版本

codew 0.10.2

Where did it happen? 在哪里出现？

CLI command (codewhale exec, codewhale doctor, ...)

Operating system 操作系统

macOS

How did you get Codewhale? 获取方式

Homebrew

Provider and model 提供商和模型

/google

Terminal and shell 终端

zch

codewhale doctor (optional)

its ok

Logs, screenshots, anything else (optional)

No response

Read-only list visibility investigation, 2026-10-28

/task list and model tasks list currently query owner-scoped durable TaskManager jobs; the visible To-do tracker is projected separately from Work Graph / the agent-owned To-do list. This explains a possible visibility mismatch, but has not reproduced the reporter's cancelled-turn case and does not establish the root cause. A separate investigator is tracing a possible cancellation/publish/checkpoint race.

Candidate design: present labeled durable tasks and the same authoritative session To-do view through both list surfaces, preserve unavailable/pending rather than claiming empty, and keep mutations with their existing owners. The existing TodoSource pointer-identity check is essential: child contexts can carry a parent's WorkRuntime while owning their own To-do list. Carry the actual engine-owned list into task-tool registration, and add an explicit non-rebinding session/generation fence before graph reads. WorkRuntime::capture(Some(id)) is not such a fence because graph_for_update rebinds its active session ID. UI try_work_state_snapshot is session-bound to App but needs truthful pending/error reporting. Distinct owner and cancellation-race review is required before implementation; no code changes or build were made for this investigation.

Work Graph persistence boundary, 2026-10-28

Owner: coordinator Engine worker. Planned exact Engine paths: crates/tui/src/work_graph/runtime.rs, crates/tui/src/tui/app.rs, crates/tui/src/tui/ui/{frame.rs,session_state.rs,event_loop.rs,apply.rs,tests.rs}, and crates/tui/src/commands/contract.rs, with existing relevant tests in those files. Source is read-only until the shared Engine build finishes. The initial slice will preserve session ownership and compare the captured graph at queue admission and projection; cached fallback, completion checkpoint clearing and asynchronous durability need explicit handling and independent review. No hosted CI or provider calls. Contributor PR #7122 owns its own signal-exit flush and remains a PR; do not rewrite or subsume it. Reporter’s cause remains unconfirmed and task-list visibility is a separate remaining issue.

Narrow first slice: fence publication against the actual queued/saved Work snapshot and its original session owner; keep retry pending if a newer graph is present. The actor’s single per-session acknowledged-checkpoint reply is shared with Engine SyncSession, so this slice must not add competing Work acknowledgements or claim disk durability. The already-taken CompletedCommit clear and direct-save ordering remain open. Additional existing fixture path if its helper needs updating: crates/tui/src/tui/ui/tests/plan_handoff.rs. Still read-only during the coordinated Engine source freeze.

Additional clean call-site claims: crates/tui/src/tui/ui/dispatch.rs and crates/tui/src/tui/ui/handlers.rs, needed to carry the original owner across the existing persistence boundary. Do not edit until the shared Engine freeze is released.

2026-10-28: /root/engine additionally claims existing crates/tui/src/tui/ui/tests/conversation_undo.rs to verify acknowledged rewind partial-success handling alongside tui/ui/apply.rs. No new test functions or comments; shared Engine build remains coordinated.

2026-10-28 coordinator continuation

The previous Engine worker stopped; the coordinator now owns its existing dirty Work Graph paths. The inherited patch is preserved at CW/backups/engine-workgraph-20261028/inherited.patch (codewhale-hq/codewhale-app#334 74f4520b8764ec8068d0a6ec42726b6959571956d98d2af0819eba8eb353c7b9, base 71bc853fe6). Independent source review identified a pre-existing restore-then-recapture race and possible partial-success/queued-write ambiguities in the candidate; these are under review, not reproduced or fixed yet. No Work Graph slice has been committed. The original task-list mismatch and reporter's cancellation path remain unconfirmed.

2026-10-28 coordinator update

Engine commit 4bd36c740d removes the fallible second Work Graph capture after the target session's graph and owner have already been committed; it reuses the validated snapshot from the atomic restore. The clean candidate passed three existing Linux session-restore checks, including the contended-restore and legacy cases; all 4,160 build inputs were unchanged. This fixes a source-traced partial-switch hazard, but the exact lock race was not reproduced and the reporter's cancellation/list-visibility mismatch remains open. The inherited uncommitted Work Graph patch is still preserved and not cleared to land: independent review found that queued or durable writes can report failure after acceptance, and cache fallback can acknowledge an older snapshot under contention. Do not treat this commit as resolving the issue.