`/clear` leaks the previous session swarm Plan into the fresh session

[jetersen]

Summary

/clear creates a fresh session and clears the transcript, side panel, and diagram registry, but the TUI keeps the previous session's swarm_plan_items, swarm_plan_version, and swarm_plan_swarm_id. The new session therefore shows the old swarm plan as its todo list, often as a permanently blocked Plan 0/N panel.

The server also migrates the cleared session's swarm member and plan participant to the new session ID, so the stale plan can remain associated with the fresh session beyond the immediate client-side leak.

Live reproduction

Observed repeatedly, most recently on Jcode v0.68.0 in /home/joseph/git/work/devops-k8s-apps:

1. Session session_lion_1785967431956_42df39dbb0476edf had a deep swarm plan.
2. Run /clear.
3. Server creates session_horse_1785968588509_87dbde0c4153d4ec (SESSION_LIFECYCLE phase=clear_done, swarm_id_updated=true).
4. The fresh horse session still renders Plan 0/68, with all 68 nodes queued or blocked.
5. Persisted workspace swarm state confirms the plan is version 19 with 68 queued items, while its coordinator remains the old lion session.

This has been observed at least twice.

Root cause

Client-side full-discard paths clear the transcript but intentionally leave swarm plan snapshot fields intact:

• crates/jcode-tui/src/tui/app/commands_review.rs::reset_current_session
• crates/jcode-tui/src/tui/app/remote/key_handling.rs /clear branch

info_widget_data() substitutes swarm_plan_items for session todos whenever the vector is non-empty, so the old plan becomes the new session's Plan panel.

Existing tests explicitly pin the buggy behavior:

• test_local_clear_command_clears_active_diagrams_but_keeps_swarm_plan_state
• test_remote_clear_command_clears_active_diagrams_but_keeps_swarm_plan_state

Server-side, handle_clear_session() moves the old member to the new ID and calls rename_plan_participant(), which can prolong the association with the plan.

Expected behavior

A full /clear must not make the fresh session inherit or render the prior session's Plan panel. Full-discard paths should reset all client swarm-plan snapshot fields. Server lifecycle behavior should avoid reattaching an abandoned plan solely because the cleared session ID was replaced, while preserving genuinely live swarm work where required.

Acceptance criteria

• Local and remote /clear clear swarm_plan_items, swarm_plan_version, and swarm_plan_swarm_id.
• The fresh session's info widget falls back to its own todo state and does not show the old Plan 0/N.
• A regression test covers a real clear transition with an existing swarm plan.
• The server cannot immediately reintroduce an abandoned plan solely because it migrated the cleared session ID.
• Existing active-swarm continuity semantics are documented and tested.

[jetersen]

Additional live verification found one more compatibility case: the currently running older server had already migrated the dormant 68-item Plan to the fresh session, so participant scoping alone could not distinguish it from a legitimate current-session Plan.

I expanded the fix so a successful current-session todo update supersedes a dormant swarm snapshot, while preserving any Plan that has assigned or active work. I then built the amended TUI, attached it to this same live session without clearing state, and reproduced Plan 0/68. After issuing the current todo update, the fixed client immediately switched to the current five-item todo plan. No /clear or persisted-state mutation was used.

Final branch, rebased onto current master: master...jetersen:fix/816-clear-stale-swarm-plan

[mclaughlinmichael08]

GPU 显存不够时有量化方案吗 💡

[mclaughlinmichael08]

😄🙌🤝 有没有对应的最佳实践文章