feat: improve LLM understanding of implicit file change rejections

[roomote]

Summary

This PR addresses Issue #7480 by improving how the LLM understands user feedback on proposed file changes. When users provide feedback without explicitly accepting a file change, the system now correctly interprets this as an implicit rejection and guides the LLM to create a new proposal incorporating the feedback.

Problem

Previously, when the LLM proposed a file change and users provided feedback via a new message (without clicking accept/reject), the LLM would:

• Misinterpret this as a request to revert the previous change
• Not understand that the current proposal was implicitly rejected
• Lead to inefficient workflows and user frustration

Solution

This implementation:

1. Detects implicit rejections: When users send feedback (messageResponse) for file change tools without explicitly accepting
2. Provides clear guidance: New response format explicitly tells the LLM that:
   • The proposed change was NOT applied
   • They should NOT attempt to revert anything
   • They should read the current file and create a NEW proposal with the feedback
3. Updates system rules: Added clear documentation in the prompt about file change feedback handling
4. Includes tests: Unit tests verify the new response formatting behavior

Changes

• Added response formatter
• Updated logic in to detect implicit rejections
• Added system prompt rule clarifying file change feedback handling
• Added unit tests for the new response format

Testing

• ✅ Unit tests pass
• ✅ Linting passes
• ✅ Type checking passes
• ✅ Code review confidence: 95% (High)

Impact

This change is backward compatible and only affects the specific scenario where users provide feedback without explicitly accepting/rejecting file changes. It should significantly improve the user experience when iterating on file changes with the LLM.

Fixes #7480

---

Important

Improves LLM's handling of implicit file change rejections by detecting feedback without explicit acceptance and guiding new proposal creation.

• Behavior:
  • Detects implicit rejections in presentAssistantMessage.ts when users provide feedback without explicit acceptance.
  • Guides LLM to create new proposals based on feedback, avoiding unnecessary reverts.
• Response Formatting:
  • Adds toolImplicitlyRejectedWithFeedback() in responses.ts to format implicit rejection messages.
• Testing:
  • Adds responses.implicitRejection.spec.ts to test implicit rejection message formatting.
• Documentation:
  • Updates rules in rules.ts to clarify file change feedback handling.

^{This description was created by for cf90414. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Reviewing my own code is like debugging in a mirror - everything looks backwards but the bugs are still mine.

[roomote]

I notice the implicit rejection detection logic is duplicated here and in the inline approval handling below (lines 288-310). Could we extract this into a shared helper function to avoid duplication and ensure consistency?

Suggested change

	].includes(block.name)
	const isImplicitFileChangeRejection = (response: string, text: string | undefined, toolName: string): boolean => {
	const fileChangeTools = ["write_to_file", "apply_diff", "insert_content", "search_and_replace"];
	return response === "messageResponse" && !!text && fileChangeTools.includes(toolName);
	};

[roomote]

The hardcoded array of file change tools appears twice in this file. Would it be better to define this as a constant at the module level or in a configuration file for easier maintenance? Also, should we consider tools like browser_action that might save files?

[roomote]

Great test coverage for the main scenarios! Could we add a few edge case tests?

• What happens when feedback is empty/null?
• Behavior with non-file-change tools receiving messageResponse
• An integration test showing the full flow from user feedback to LLM response

[roomote]

The explanation is clear, but could benefit from a concrete example of what NOT to do. Something like:

Suggested change

	* The user's feedback is meant to guide you toward a better solution, not to trigger a revert operation
	* The user's feedback is meant to guide you toward a better solution, not to trigger a revert operation
	* DON'T: attempt to use apply_diff to 'undo' changes that were never applied
	* DO: read the file's current state and create a new proposal based on the feedback

[roomote]

This implicit rejection message is quite dense. Could we consider breaking it into clearer sections with formatting to help the LLM parse the key points more easily? Perhaps using numbered steps or clearer section headers?

[daniel-lxs]

Not enough info on the issue