Update prompts

.github/KnowledgeBase/manual/gacui/components/controls/editor/home.md

@@ -76,6 +76,8 @@ The**CaretBegin**and**CaretEnd**properties represent the range of the selection.
 
 **SetCaret**changes**CaretBegin**and**CaretEnd**at the same time. To cancel the selection and move the caret, just set these two properties to the same value.
 
+**EnsureCaretVisible**scrolls the text box to the**CaretEnd**.
+
 **CalculateCaretFromPoint**returns the nearest caret at a position. The coordinate origin is the left-top corner of the document.
 
 **GetCaretBounds**returns the position of a caret. It is a rectangle with**zero**width, the**y1**and**y2**components represent the position of the vertical caret line.

.github/KnowledgeBase/manual/gacui/kb/application.md

@@ -6,9 +6,8 @@ A GacUI application requires a user defined function**void GuiMain(void)**. In o
   - SetupHostedWindowsDirect2DRenderer
   - SetupWindowsGDIRenderer
   - SetupHostedWindowsGDIRendererThey initialize necessary objects and call**GuiMain**with different rendering techniques.
-- For macOS,**SetupOSXCoreGraphicsRenderer**must be called in**main**.
-- For Linux Wayland,**SetupWGacRenderer**must be called in**main**.
-- For Linux XWindow,**SetupGGacRenderer**must be called in**main**.
+- For macOS,**SetupOSXCoreGraphicsRenderer**or**SetupOSXHostedCoreGraphicsRenderer**must be called in**main**.
+- For Linux with Wayland,**vl::presentation::elements::wgac::SetupWGacRenderer or SetupWGacHostedRenderer**must be called in**main**.
 
 When**GuiMain**is called, the**GuiApplication**object is ready, which can be accessed by the**GetApplication**function. A typical**GuiMain**function looks like:
 ```

.github/Scripts/copilotExecute.ps1

@@ -16,10 +16,10 @@ if (($Mode -ne "CLI") -and ($Mode -ne "UnitTest")) {
     throw "Invalid mode: $Mode. Allowed values are CLI or UnitTest."
 }
 
-if (($Configuration -ne $null) -ne ($Platform -ne $null)) {
+if (([string]::IsNullOrEmpty($Configuration)) -ne ([string]::IsNullOrEmpty($Platform))) {
     throw "Configuration and Platform parameters should be set or unset at the same time."
 }
-if ($Configuration -ne $null) {
+if (-not [string]::IsNullOrEmpty($Configuration)) {
     if (($Configuration -ne "Debug") -and ($Configuration -ne "Release")) {
         throw "Invalid configuration: $Configuration. Allowed values are Debug or Release."
     }

.github/prompts/4-execution.prompt.md

@@ -73,7 +73,8 @@ I am going to propose some change to the source code.
 
 ### Code Generation
 
-- Check out `## Projects for Verification` in `REPO-ROOT/Project.md`.
+- Check out `## Projects for Verification` in `REPO-ROOT/Project.md`
+  - Pay attention to the `### Code Generation Projects` section, `code generation projects` below references this section.
 - Check out `# AFFECTED PROJECTS` in `Copilot_Execution.md`.
 - Find out if any code generation is necessary.
   - If there is no need to run any code generation, you can skip this step.

.github/prompts/5-verifying.prompt.md

@@ -50,6 +50,7 @@
 ### Code Generation
 
 - Check out `## Projects for Verification` in `REPO-ROOT/Project.md`.
+  - Pay attention to the `### Code Generation Projects` section, `code generation projects` below references this section.
 - Check out `# AFFECTED PROJECTS` in `Copilot_Execution.md`.
 - Find out if any code generation is necessary.
   - If there is no need to run any code generation, you can skip this step.
@@ -59,8 +60,6 @@
     - It is possible that a project needs to be executed multiple times in different configuration.
     - It is possible that building is required between two runs of code generation projects.
       - The building and future code generation project execution should be handled by the next sub agent.
-- If a unit test project is also a code generation project, execute it accordingly.
-- If a unit test project is not a code generation project, DO NOT execute it. Pure unit test projects will be executed in the future.
 
 ### Finishing Code Change
 
@@ -102,6 +101,7 @@
   - You must stop the debugger after you finish debugging.
 - When you have made a few guesses but did not progress, you are recommended to debug the unit test directly.
   - Break-points are very useful to ensure the expected code path is executed, and you can inspect variable values.
+- Even when a failure is not related to your change, you should take care of it.
 
 #### Fix Failed Test Cases
 

.github/prompts/code.prompt.md

@@ -26,6 +26,8 @@
 #### Build the Solution
 
 - Check out `REPO-ROOT/Project.md` to find out what solutions you need to build.
+  - Pay attention to the `Code Generation Projects` section.
+  - Projects you need to run may dynamically changing according to what you have done.
 - Find out if there is any warning or error.
   - `External Tools Environment and Context` in `REPO-ROOT/.github/copilot-instructions.md` has the instruction about how to check compile result.
 
@@ -39,6 +41,7 @@
 ### Code Generation
 
 - Check out `## Projects for Verification` in `REPO-ROOT/Project.md`.
+  - Pay attention to the `### Code Generation Projects` section, `code generation projects` below references this section.
 - Find out if any code generation is necessary.
   - If there is no need to run any code generation, you can skip this step.
   - Otherwise, pay attention to:
@@ -47,8 +50,6 @@
     - It is possible that a project needs to be executed multiple times in different configuration.
     - It is possible that building is required between two runs of code generation projects.
       - The building and future code generation project execution should be handled by the next sub agent.
-- If a unit test project is also a code generation project, execute it accordingly.
-- If a unit test project is not a code generation project, DO NOT execute it. Pure unit test projects will be executed in the future.
 
 ### Finishing Code Change
 
@@ -89,6 +90,7 @@
   - You must stop the debugger after you finish debugging.
 - When you have made a few guesses but did not progress, you are recommended to debug the unit test directly.
   - Break-points are very useful to ensure the expected code path is executed, and you can inspect variable values.
+- Even when a failure is not related to your change, you should take care of it.
 
 #### Fix Failed Test Cases
 

.github/prompts/investigate.prompt.md

@@ -1,4 +1,4 @@
-# Scrum
+# Investigate
 
 - Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md` and `*.ps1` files.
 - Check out `External Tools Environment and Context` in `REPO-ROOT/.github/copilot-instructions.md` for accessing scripts for testing and debugging.

AGENTS.md

@@ -1,7 +1,8 @@
 - Read through `REPO-ROOT/.github/copilot-instructions.md` before performing any work.
-- `copilot-instructions.md` is the guideline you should follow.
+  - `copilot-instructions.md` is the guideline you should follow.
   - MUST READ `Coding Guidelines and Tools` before touching the source code.
   - MUST READ `Leveraging the Knowledge Base` and find knowledge you may need before making any decision.
+- Read through `REPO-ROOT/Project.md` before performing any work.
 - Interpret the request (in the latest chat message, not including conversation history) following the steps:
 
 ## Step 1

CLAUDE.md

@@ -1,7 +1,8 @@
 - Read through `REPO-ROOT/.github/copilot-instructions.md` before performing any work.
-- `copilot-instructions.md` is the guideline you should follow.
+  - `copilot-instructions.md` is the guideline you should follow.
   - MUST READ `Coding Guidelines and Tools` before touching the source code.
   - MUST READ `Leveraging the Knowledge Base` and find knowledge you may need before making any decision.
+- Read through `REPO-ROOT/Project.md` before performing any work.
 - Interpret the request (in the latest chat message, not including conversation history) following the steps:
 
 ## Step 1