[FEATURE] Plan Manager — named, persistent plans with lifecycle - 1st-Class Plan System

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Plan mode currently treats plans as disposable temp files — one anonymous file per session, silently overwritten on every new planning cycle, lost on context clear.

This breaks multi-task sessions. When you plan task A, approve it, context clears, then you enter plan mode for task B — task A's plan is overwritten. No way to reference it. If context compresses mid-execution, you're forced back into plan mode with no memory of the approved plan. Concurrent sessions in the same project overwrite each other's plans.

The community has filed 9+ issues attacking individual symptoms of this: silent session splits (#26832), concurrent overwrites (#27311), state lost after compression (#26061), context clear breaking workflows (#18599), no lifecycle hooks (#14259), and no control over plan storage (#13395, #14866, #12619, #17473, #12838). These all point to one root cause: plans have no identity, no lifecycle, and no persistence beyond the current planning phase.

Proposed Solution

A Plan Manager that gives plans identity and a simple lifecycle:

• Named plans — derived from branch, task, or user label instead of random filenames
• Plan registry — lightweight index tracking plans per project with status (draft → approved → completed → superseded)
• Plan chaining — new plans can reference prior plans, so context clear doesn't erase decisions
• Lifecycle hooks — archive previous plan before creating a new one; persist approved plan before context clear
• Concurrency-safe — named plans with a registry avoid collision between parallel sessions

Plans should remain lightweight artifacts — this adds structure, not bureaucracy. A coherent Plan Manager would address the 9+ related issues in a unified way rather than patching them one by one.

Alternative Solutions

Currently I work around this by creating a master plan .md file, then constantly requesting Claude Code to keep it updated and reference it during each planning cycle. This is tedious and error-prone — the burden of plan continuity falls on the user to orchestrate instead of the tool managing it natively.

Why This Matters More Than Better Compaction

Context compression is inherently lossy — no AI summary perfectly preserves the intent, priorities, and strategic decisions a human invested in a plan. For plan-driven workflows, the answer isn't better compaction — it's making compaction irrelevant. If approved plans are persistent named artifacts tracked in a registry, clearing context or hitting the token limit stops being destructive. Claude re-reads the plan, picks up where it left off, and the human's strategic vision is preserved verbatim — not summarized, not approximated, not lost.

This is also why plan mode is fundamentally more powerful than compaction for long sessions: plans externalize decisions into human-curated documents that survive any context event. A Plan Manager would formalize this pattern and make it reliable.

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

1. Enter plan mode for task A → explore codebase, design approach, write plan
2. Approve plan → ExitPlanMode offers to clear context (recommended, since exploration artifacts consumed most of the window)
3. Execute task A with a clean context, commit
4. Enter plan mode for task B (which builds on decisions from task A)
5. Problem: Task A's plan file is overwritten by task B's new plan. No way to reference it. Planning starts from scratch with no memory of prior decisions.

Additional Context

The community has filed 9+ issues that individually tackle different friction points around plan mode — overwrites (#27311), context loss (#26061, #18599), session splits (#26832), missing hooks (#14259), storage inflexibility (#13395, #14866, #12619, #17473), and stale plan bleed (#12838). Each is valid on its own, but they all point to the same gap: Claude Code has no first-class plan management. A coherent Plan Manager would address these requests in a unified way rather than patching them one by one.