## Problem
- we want a chat mode where agents are served by the local extension
while the regular "Chat" is served by flare

## Solution
- register mynah ui webview providers depending on lsp/normal
implementation
- temporarily disable the lsp (explain, fix, etc) commands, since they
are also registered in the normal "agent" flow
- redirect agent messages to the correct chat handler on the UI side
- redirect UI messages meant for agents to the extension side
- refactor main.ts so that it can be used by both the regular
implementation and the lsp one ~(I'll open a seperate PR to merge this
into master, since it's going to be a pain to maintain)~
    - aws#7033
- pass in references to mynah handlers so that mynah ref injection can
happen after in flare
    - aws#7046


Depends on ~aws#7033,
aws#7046

Related to aws/language-servers#962

---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

## Problem
currently tabs get added to the tabs storage when the onTabAdd handler
gets called.

In hybrid chat, the onTabAdd handler will never get called, because it
first needs to be in the tabsStorage, which doesn't happen because the
onTabAdd handler hasn't been called

## Solution
in hybrid chat mode just add new tabs directly to the tabs storage


---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

## Problem
When switching between different manifests, a newly downloaded version
might chronologically be older than all previously downloaded versions,
even though it's marked as the latest version in its own manifest. This
is why we are getting the EPIPE error when trying out the alpha
manifest. The cleanup deletes the language server right after it was
downloaded

## Solution
In such cases, we skip the cleanup process to preserve this version.
Otherwise we will get an EPIPE error. At this point the version that was
downloaded shouldn't be delisted, so we don't want to make sure its not
removed

---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

…ressed

## Problem
- developer profiles are only synced to our local agents (/dev, /doc,
etc). Now that the main chat panel is served by flare we need to update
the profile information when it becomes available so that flare is using
the correct profile for the request

## Solution
- send profile information to flare on the initial request + subsequent
changes to the active profile
- refresh the webview if the profile changes 

---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

## Problem
We did not utilize server side compute to help improve the quality of
inline completion, chat, etc.

## Solution
1. Add server side project context support.

---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

## Problem

LSP cannot run in AL2 due to glibc compatibility.

## Solution

Do not start LSP in AL2. 


---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

…dev mode

## Problem
when the flare chat panel refreshes on log in/log out, the message
listener never gets disposed of, causing the next webview instantiation
to have two message listeners that are forwarding messages to the ui

## Solution
dispose of the message listener when the webview gets disposed

---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

## Problem

We heard from users that auto scans are sometimes causing highlight
linting issues where entire IDE is now yellow-underlined with warnings
that may sometimes be irrelevant

## Solution

We will disable auto scans by default, and user can re-enable in the
menu.

---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

Add changelog for the agentic chat release



---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

feat(agentic chat): Agentic coding experience: Amazon Q can now write code and run shell commands on your behalf

## Problem
We currently point to the alpha manifest and Flare deployment is ready
for us to point to prod.

## Solution
- switch the config to point to prod. 
- supported version `1.*.*` will force us to explicitly support new
major versions, but automatically pull new minor versions. Following the
LSP toolkit spec.

---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

## Problem
LSP depends on node 18 which depends on GLIBC >=2.28. 
Amzn al2 instances do not have GLIBC >=2.28. 

## Solution
Use the patch of glibc if it is available.

---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.

…#7205)

## Problem
Some processes use significantly more cpu/memory than others, so we
shouldn't hold them to the same static threshold.
As an example, the language servers are consistently using more memory
than the 100 MB threshold.

Based on some experimentation with different sized workspaces, I've
noticed that the process running agentic chat uses roughly 80MB-150MB of
memory, and the workspace indexing uses 550 - 700 MB memory.

## Solution
- Allow each child process to set a warning threshold, with a default of
100MB of memory.
- Set the Q LSP threshold to 200 MB, and workspace indexing to 800 MB. 
- This should help to allow these logs to point to real concerns, rather
than be noise.

---

- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.