feat: change set support in chat input and chat model

[planger]

What it does

• Add the concept of a change set to chat model and input UI
• Add an implementation of change set elements for files
• Add an agent for testing: @Changeset

Other fixes in Chat Input UI:

• The inProgress state of the chat input was actually unsafely managed. This change addresses the proper management of the inProgress state.
• The positioning, e.g. of the placeholder is now more adaptive.

As the change set feature directly relates to another feature (context, work in progress), this change also already prepares for those changes in the chat UI:

• Prepare chat input for adding context to requests
• Add context in the form of variables to chat model

Fixes #14749

How to test

To demonstrate the usage and simplify testing, this PR includes a test agent named @ChangeSet. This statically sets a somewhat random change set into the chat model, with one new, one modified, and one deleted file change set element.

change-set.mp4

Follow-ups

Next steps include:

• Hook up the Coder Agent to allow for testing this change set support in more breadth.
• Allow to clear a changeset (all changes a single changes)
• When using with the Coder agent, the progress could be shown in a better way. We should add the change earlier while the LLM is still streaming. We might also open the file and show some line animation there.

• The Coder Agent should be switched to use the monaco model, if it exists, to capture potentially dirty states -- otherwise the AI sees a different version than the user.
• Improve the diff editor we use here: currently there seems to be no simple way to show a diff between the workspace (editable) and a suggested modified version, while allowing to "accept" changes from the suggested version to the workspace version. Therefore, we take a somewhat ugly shortcut in this PR to show a diff between the suggested changes as readonly original version left and the editable workspace version on the right. This works, however, the colors are wrong (red for additions) and the labels are wrong (reject, even though it is actually an accept).
• Potentially optimize the ChangeSetFileElement how it applies and reverts changes, taking the monaco text model into account. I aimed at reusing the functionality to modify the monaco model if an editor is open without saving, and saving to disk directly if no editor is opened. But this should be tested for user experience and consistency.

Breaking changes

• This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Attribution

None

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[JonasHelming]

Very nice, looks really great. I believe this is a very powerful feature!

Couple of high level comments/questions:

• How do we combine this with the existing FileChangeSetService, as there is quite some overlap.

  • Do we keep both data structures? This is the biggest overlap. In particular it is:
    Coder: FileChangeSetService|ChangeSet|FileChange vs. this PR ChangeSet|ChangeSetElement|ChangeSetFileElement
  • Where are changes applied to the content (currently only in the FileChangeSetService)
  • Where are file created, deleted, written (currently in both)
  • How can the LLM check whether changes are applicable
  • How can the LLM look at the new state after the change would be applied before they are actually applied

• How do we hand the chatID around. We need it at least in functions for Coder to work in its current state

• What is our story to close a changeset or to clear it?

[JonasHelming]

Just a first highlevel look for now

[JonasHelming]

'reject' is rather 'undo' or 'discard', two comments:

• I would rename this action and only show it, if the change has already been applied
• I believe we need something to remove a change from a changeset without applying it.

[planger]

I see, so I would propose to add a remove action which is always visible and show a discard if the change has already been applied. WDYT?

[JonasHelming]

yes, that makes sense. I would also add a "clear" action next to accept to clear the complete changeset

[JonasHelming]

It is now integrated with Coder, two example prompts to get all three changes types:

@coder Move the readme file to a sub direcotry called /readme

@coder Implement the interface MCPServerManager in the same file (packages/ai-mcp/src/common/mcp-server-manager.ts). Don't ask me anything, jut do it.

[planger]

@JonasHelming @sdirix

I've addressed the review feedback and added delete functionality.

@sdirix I've reintroduce the latestRequest ref to have proper value in functions. Maybe there is a better solution latestRequest was always undefined when used in the function onDeleteChangeSet and onDeleteChangeSetElement.

[JonasHelming]

Looks great!

I found one additional issue, either to fix now or as a follow up:

• Discard does not work for me after applying a change (accept a change => discard => nothing happens)

Once we merge this, we should create a follow up epic with all the open topics => I can do this.