Enhance LLM's Understanding of User Feedback for File Change Rejection in Workflow #7480
Description
What specific problem does this solve?
This problem affects users interacting with the LLM for file changes within the workflow. Currently, when the LLM proposes a file change, users have three main options:
- Accept: The change is applied (not ideal if improvements are needed).
- Reject: The change is explicitly rejected, but the LLM has to infer the reason.
- Send a new message with improvement details: This is the problematic scenario. When a user provides detailed feedback or suggests improvements via a new message, the LLM often fails to recognize this as an implicit rejection of the current file change proposal. Instead, it might interpret the new message as a request to revert the previous change, or simply not understand that the proposed change was not accepted.
Current Behavior: LLM proposes a file change -> User sends a new message with improvement details -> LLM misinterprets this as a request to revert the previous change, or does not understand the rejection, leading to redundant "revert" requests or incorrect subsequent actions.
Expected Behavior: LLM proposes a file change -> User sends a new message with improvement details -> LLM understands that the current proposal is implicitly rejected, processes the feedback, and generates a new, improved proposal.
Impact: This leads to an inefficient workflow, as users have to spend extra time clarifying or correcting the LLM's misunderstanding. It also hinders the LLM's ability to learn from implicit rejections, resulting in wasted cycles and user frustration.
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)
The system needs to be enhanced to differentiate between a new message providing constructive feedback/improvements (which implies a rejection of the current proposal) and a message explicitly asking to revert a change. A potential solution involves augmenting the LLM's prompt with a clear description of the current state, explicitly informing the LLM that the user has rejected the previous modification and has provided new instructions or feedback. This would guide the LLM to interpret detailed feedback as an implicit rejection of the current proposal and a clear request for a revised one, incorporating the provided suggestions.
How will we know it works? (Acceptance Criteria - REQUIRED if contributing, optional otherwise)
Given an LLM proposes a file change.
When the user sends a new message detailing improvements or reasons for not accepting the current change.
Then the LLM should understand that the current file change proposal is implicitly rejected.
And the LLM should use the user's feedback to generate a new, revised file change proposal.
But the LLM should not attempt to revert the previously proposed change.
Technical considerations (REQUIRED if contributing, optional otherwise)
No response
Trade-offs and risks (REQUIRED if contributing, optional otherwise)
No response