What specific problem does this solve?

I often use a subtask for research, and the results of the subtask will be feedback into the orchestration of the main task, then continue with the next content.

If the subsequent content doesn't meet my expectations, I can only rollback to the checkpoint where the subtask returns results, but this will lose all existing messages.

Therefore, what I expect is that based on this message, a new conversation can be created to avoid losing the current conversation.

Additional context (optional)

No response

Roo Code Task Links (Optional)

No response

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear impact and context

Interested in implementing this?

• Yes, I'd like to help implement this feature

Implementation requirements

• I understand this needs approval before implementation begins

How should this be solved? (REQUIRED if contributing, optional otherwise)

• UI Enhancement:
  Add a "Start New Task from Here" option to the context menu of each chat message.

• Backend Communication:
  When the user selects this option, the frontend will send a forkTaskFromMessage message with the messageIndex to the VS Code extension backend.

• Core Logic Implementation:
  The backend will implement the forkTaskFromMessage method in ClineProvider.
  This method will locate the original task based on the messageIndex and copy all conversation history up to that message point.
  It will then create a brand-new Task instance using this copied history.
  The new task will be pushed into the task stack (clineStack) and become the active task, displayed in the UI. The original task remains unchanged, and the user can switch back to it at any time.

How will we know it works? (Acceptance Criteria - REQUIRED if contributing, optional otherwise)

• UI Verification:
  The "Start New Task from Here" option should appear in the context menu of chat messages.
  Upon clicking this option, a new conversation window or tab should appear, containing the conversation history starting from the fork point.

• Functional Verification:
  The newly created conversation should include all messages from the original conversation up to the fork point.
  The original conversation should remain intact, with no messages deleted.
  Users should be able to freely switch between the new and old conversations without losing any context.

• Data Consistency:
  The newly forked task should have the exact same state as the original task at the fork point, including file changes, environment variables, etc.

Technical considerations (REQUIRED if contributing, optional otherwise)

• State Management:
  Task forking requires precise management of clineStack to ensure correct task addition, switching, and persistence.
• History Replication:
  It is essential to ensure both clineMessages and apiConversationHistory are properly deep-copied to avoid state contamination between old and new tasks.
• Performance:
  For extremely long conversation histories, history replication operations may have performance impacts. The replication process should be evaluated and potentially optimized.

Trade-offs and risks (REQUIRED if contributing, optional otherwise)

• Complexity:
  Introducing task forks increases the complexity of state management. If not handled properly, it may introduce hard-to-debug bugs.

• Resource Consumption:
  Each forked task creates a new Task instance in memory. If users create a large number of forks, memory usage may increase. It’s necessary to consider whether to limit the number of forks or implement more efficient memory management strategies.

• User Experience:
  The UI/UX for task switching must be clear and intuitive; otherwise, users may feel confused across multiple conversation branches.