Feature: iterate on a proposed plan, reject/delete it, and attach a todo checklist (Cursor/Claude Code CLI parity) #11344

Summary

Compared to Cursor and Claude Code CLI, T3 Code's proposed-plan flow (ProposedPlanCard / proposedPlans) is missing three things: a real iterate-until-right loop, a way to reject/delete a plan, and a todo checklist attached to the plan itself.

Current behavior

The composer's plan follow-up prompt (ChatComposer.tsx, shouldShowPlanFollowUpPrompt in ChatView.logic.ts) only supports two outcomes once a plan is proposed:

if (showPlanFollowUpPrompt) {
  return prompt.trim().length > 0 ? "plan:refine" : "plan:implement";
}

• Typing feedback + send → plan:refine, which sends another turn and replaces the card content. There's no diff or history across revisions, so you can't easily see what changed between iterations or roll back to an earlier version.
• Leaving it blank + send → plan:implement, which spawns a new thread via onImplementPlanInNewThread with PLEASE IMPLEMENT THIS PLAN:\n<plan>.
• There is no third path. ComposerPlanFollowUpBanner.tsx is a static "Plan ready: <title>" label with no dismiss/reject affordance, and ProposedPlanCard's own menu only has Copy / Download / Save to workspace (ProposedPlanCard.tsx). hasActionableProposedPlan (session-logic.ts) only ever flips to false via implementation (implementedAt being set) — there's no reject path that sets it false without implementing.
• Separately, ACP already has a task-checklist concept (sessionUpdate: "plan", publishTaskPlan / taskStateToPlanEntries in claude-agent-acp/src/acp-agent.ts) surfaced via activeTasksProgress / activeTaskSteps, but that's a live execution checklist for a running turn — it isn't attached to proposedPlans at the proposal stage.

Expected (Cursor / Claude Code CLI parity)

• Iterate: refining a plan should feel like a real conversation about the plan — visible history/diff of revisions, not a silent full replace, so you can converge on the right plan before committing.
• Reject/delete: an explicit action to discard a proposed plan without implementing it (distinct from just not responding), setting hasActionableProposedPlan back to false and clearing the card/banner.
• Attached todo list: the plan itself should carry a checklist (like Cursor's plan+todo breakdown or Claude Code CLI's TodoWrite), generated alongside the plan and visible in ProposedPlanCard, not only as a transient execution-time checklist.

Notes

This is a UX/state-machine gap in the plan feature itself, independent of provider. Mapping additional providers' native plan RPCs (e.g. Cursor's cursor/create_plan) into proposedPlans is only useful once this loop actually supports iterate/reject/todos — otherwise those providers inherit the same limited two-branch flow.