design: make plan-to-execute model transition a carryover session handoff
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 152
- Forks
- 16
- Avg merge
- 14h 48m
- Merged PRs (30d)
- 536
Description
$## Problem\n\nPlan approval is the one normal path that can change a session\x27s resolved model identity while retaining the same session ID: a plan-mode run completes, approval flips Session.Mode, and the next run-entry rebuilds the same session\x27s engine for the execute model.\n\nNormal /models model changes instead create/rebind a new session with carryover history. Keeping plan\xE2\x86\x92execute as the exception increases lifecycle complexity: UI model synchronization, mode-aware engine rebuilding, provider-private replay compatibility, session identity semantics, and audit/history handling all have a special case.\n\n## Proposed design investigation\n\nEvaluate making a successful plan approval complete the plan session permanently, then create/fork an execution session with explicit carryover history and bind the client to it. The execution session would use the ordinary execute model selection path; model identity would remain immutable for each session.\n\nThis is a design investigation, not an implementation request. It must decide:\n\n- exact carryover history and placement of the harness proceed prompt;\n- whether to record plan\xE2\x86\x92execution lineage;\n- audit/event-log semantics across the two sessions;\n- failure behavior if execution-session creation fails after approval;\n- atomic TUI/client rebind (ID, history, capabilities, workspace, model, live feed, title);\n- provider-private reasoning/replay state compatibility and stripping policy (related #698);\n- effects on ApprovePlan, interactive mecatui approval, headless auto-approval, restart, and cloud-native rehydration.\n\n## Rationale\n\nA session boundary may be more consistent with existing /models carryover behavior and avoids plan mode being the sole intentional same-session model-identity transition.\n\n## Out of scope\n\nDo not fold this into the approval-surface PR #739.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the existing /models carryover behavior and the ApprovePlan flow, then trace interactive mecatui approval, headless auto-approval, restart, and cloud-native rehydration. Review related issue #698 and keep the approval-surface PR #739 out of scope. Done means documenting decisions for carryover history, lineage, audit events, failure handling, client rebind, and provider-private replay compatibility.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100