Feature: Plan/task affinity — tasks may have plans

Problem

Plan mode and task tracking teach complementary habits:

• Plans teach the user to think before acting, improving outcomes
• Tasks teach the user to structure work as dependencies, improving organization

It's natural to want both — a plan for every task. But plans and tasks are separate systems with no association between them. You can't say "show me the plan for task #3" or "enter plan mode to refine this task's approach." A plan is ephemeral context; a task is a tracked work item. They don't know about each other.

Related Features

• #26147 — Named plans: Multiple independent plans in a single conversation
• #26148 — Plan-to-task conversion: Create a task from a plan on ExitPlanMode

Why Plan/Task Affinity May Supersede Named Plans

Named plans (#26147) solve the immediate problem of plan overwriting, but introduce a parallel tracking system — plans with names living alongside tasks with IDs. Adopting plan-per-task may be the stronger design because it reinforces tasks as the single way to track work. When a user is discussing multiple streams of work, the system teaches them: create tasks first, then plan each one. This avoids a world where some work lives in named plans and other work lives in tasks, with no unified view.

Proposed Extension: Tasks May Have Plans

EnterPlanMode(task_id?: string)

| Call | Behavior |
|------|----------|
| EnterPlanMode() | Current behavior (standalone plan for immediate work) |
| EnterPlanMode(task_id: "3") | Edit the plan for task #3 |

Plan-to-task conversion preserves the association:

When ExitPlanMode(create_task: true) converts a plan to a task (#26148), the plan becomes associated with the task rather than rewritten into its description. The plan remains a first-class editable object; the task references it.

What This Enables

• Re-enter a task's plan: EnterPlanMode(task_id: "3") opens the plan for refinement at any time — before, during, or after implementation
• Plan visibility in task tracking: Task list can show which tasks have plans and their status (draft/approved/implementing)
• Separation of concerns: The task description says what needs to happen; the plan says how. These are different documents that evolve independently
• Iterative planning: Start a task, realize the plan needs adjustment, re-enter plan mode for that task, revise, continue
• Single tracking system: All work is visible through tasks. Plans are an attribute of tasks, not a separate system

Workflow Example

# Create tasks from a review
TaskCreate("Fix form validation")        → task #1
TaskCreate("Add payment error recovery") → task #2
TaskCreate("Live order summary updates") → task #3

# Plan each task
EnterPlanMode(task_id: "1")   # plan for validation fix
ExitPlanMode()                # plan associated with task #1

EnterPlanMode(task_id: "2")   # plan for error recovery
ExitPlanMode()                # plan associated with task #2

# Start implementing task #1, realize plan needs revision
EnterPlanMode(task_id: "1")   # re-open and refine
ExitPlanMode()                # updated plan, same task

# Tasks and plans are independently manageable
TaskUpdate(task_id: "3", addBlockedBy: ["1"])  # task dependency
EnterPlanMode(task_id: "3")                     # plan task #3 while blocked