Support deferred plan implementation in draft threads

[TaylorJonesTRT]

• Create implementation drafts from proposed plans instead of sending immediately
• Persist deferred plan metadata in composer drafts
• Add browser coverage for selecting provider/model and dispatching the deferred turn

What Changed

• Changed "Implement in a new thread" to create a local implementation draft instead of immediately dispatching thread.create and thread.turn.start.
• Seeded the destination draft with the generated implementation prompt, current provider/model/model options/runtime mode, and deferred proposed-plan linkage metadata.
• Kept the provider/model picker unlocked on that draft so the first send can switch adapters before the new thread starts.
• Rendered implementation-mode composer UI on deferred drafts, including the plan follow-up banner and a single Implement CTA.
• Extended the local-draft first-send path to include sourceProposedPlan when starting the deferred implementation turn.
• Persisted deferred implementation metadata in the composer draft store, including hydration, migration, and cleanup behavior.
• Added browser coverage for the deferred draft handoff, unlocked provider/model selection, and dispatching the deferred first turn with the selected adapter/model.

Why

The previous flow started a new server thread immediately, which locked in the source thread’s adapter choice before the user could review or change it, which made sense when only one adapter was available. That made "Implement in a new thread" inconsistent with the draft-thread model used elsewhere and prevented switching to another provider, including Claude, before sending which some users may prefer (Planning in Opus / Implementing in Gpt 5.4, or vice versa).

This change moves the action into the existing local-draft flow so the implementation prompt is still prefilled, but the user keeps control over the first-send configuration. It also preserves the original proposed-plan linkage by deferring sourceProposedPlan until the implementation turn actually starts.

UI Changes

• "Implement in a new thread" now navigates to a draft-thread route with the implementation prompt prefilled instead of starting work immediately.
• The destination composer shows implementation-mode UI with an Implement button.
• The provider/model picker remains unlocked until the first turn starts.

Images and Gif Video

Gif video due to my FFmpeg install being broken

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Note

Defer plan implementation into a draft thread until the user clicks 'Implement'

• Clicking 'Implement in a new thread' now navigates to a local draft thread pre-seeded with the plan implementation prompt instead of immediately dispatching server commands.
• The draft stores the selected provider/model and deferredPlanImplementation metadata (source thread ID, plan ID, plan markdown); when the user clicks 'Implement', the app dispatches thread.create then thread.turn.start with sourceProposedPlan attached.
• composerDraftStore gains createProjectDraftThread and setDeferredPlanImplementation APIs, bumps its storage version to 3, and persists/hydrates deferred metadata; drafts containing only deferred metadata are preserved instead of pruned.
• The composer shows a ComposerPlanFollowUpBanner and an 'Implement' submit button during deferred state, and allows sending even when the text field is otherwise empty (prompt is seeded from the plan).
• Behavioral Change: onImplementPlanInNewThread no longer creates a server thread immediately; server work is deferred until the user explicitly submits the draft.

^{Macroscope summarized 0d67869.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 42ed68eb-9c72-49ef-a4da-34ec8ade6ab6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Tip

CodeRabbit can suggest fixes for GitHub Check annotations.

Configure the reviews.tools.github-checks setting to adjust the time to wait for GitHub Checks to complete.