Sync copilot knowledge base

.github/KnowledgeBase/Learning.md

@@ -3,13 +3,14 @@
 # Orders
 
 - Process staged tasks one by one with verification [15]
+- Port fixes from imports to source repositories [7]
 - Crash early instead of adding error-tolerance fallbacks [6]
-- Port fixes from imports to source repositories [6]
 - Verify generated artifacts with downstream consumer checks [6]
 - Make `Stop()` drain asynchronous work before returning [5]
 - Use `WString::IndexOf` with `wchar_t` (not `const wchar_t*`) [4]
 - Use `collections::BinarySearchLambda` on contiguous buffers (guard empty) [4]
 - Proactively remove code made redundant by refactoring [3]
+- Use `vl::Exception` for expected semantic failures and `CHECK_ERROR` for invariants [3]
 - Capture dependent lambdas explicitly [2]
 - Don't assume observable changes are batched [2]
 - Do not assume async callback owners are heap allocated [2]
@@ -17,7 +18,6 @@
 - Use `ERROR_MESSAGE_PREFIX` for meaningful `CHECK_ERROR` / `CHECK_FAIL` messages [2]
 - Prefer simple calls before interface casts [2]
 - Validate expectations against implementation and existing tests [2]
-- Use `vl::Exception` for expected semantic failures and `CHECK_ERROR` for invariants [2]
 - Treat Debug memory leak dumps as required failures [2]
 - Prefer well-defined tests over ambiguous edge cases [1]
 - Prefer `operator<=> = default` for lexicographic key structs [1]
@@ -104,6 +104,8 @@ When validating GacUI remoting reveals a transport issue, keep the same source-o
 
 For dependency release syncs, copy generated files from the upstream `Release` folder into the downstream `Import` folder and exclude `IncludeOnly` unless the task explicitly requires it. Do not hand-edit the downstream import copy.
 
+If a Workflow task exposes a `VlppReflection` collection-wrapper issue, fix the wrapper behavior in `VlppReflection`, regenerate and verify its release output, then update the Workflow import from that release instead of patching Workflow's imported copy.
+
 ## Validate expectations against implementation and existing tests
 
 Before encoding expectations (especially for return value conventions and error semantics), read the relevant implementation and check existing tests for established patterns. This reduces churn from mismatched assumptions (e.g. public API returning a normalized error value even if internals use different sentinel codes).
@@ -206,6 +208,8 @@ When a C++ struct contains `vl::collections::List` fields, the struct's implicit
 
 When a failure is part of the public or script-visible semantics and tests are expected to catch it as a recoverable error, throw `vl::Exception`. Reserve `CHECK_ERROR` / `CHECK_FAIL` / `vl::Error` for internal invariant violations and states that indicate implementation corruption. For example, duplicate RPC registration can remain a catchable semantic exception when samples intentionally verify it, while impossible local type ids should fail as invariants.
 
+At script-visible reflection boundaries, translate recoverable collection operation failures into `vl::Exception` so Workflow `catch` blocks and RPC exception transport can observe them normally; do not expose `vl::Error` for expected user-data access failures.
+
 ## Compare type descriptors by pointer when descriptor identity is available
 
 `GetTypeDescriptor<T>()` and `GetTypeDescriptor(typeName)` guarantee one descriptor instance per type in a loaded type manager, so prefer direct `ITypeDescriptor*` pointer comparison over comparing type-name strings. Use `TypeInfo<T>::content.typeName` only where the type manager cannot be loaded yet; if a name lookup is unavoidable, resolve the descriptor once and compare pointers inside hot or repeated paths.

.github/prompts/investigate.prompt.md

@@ -45,7 +45,8 @@ I am starting a fresh new request.
   - At the moment, `Copilot_Investigate.md` may contain the last investigation. Even if it may look like the document is already finished for the current investigation, always clean it up.
 - After overriding, copy precisely my problem description in `# Repro` from the LATEST chat message under `# PROBLEM DESCRIPTION`.
   - If the problem description consists of multiple `## Task N` or `## Task TITLE`:
-    - You should strictly follow `## Git Commits and Multi-Task Request` to create git commit(s) for each task, you are required to push changes before starting the next task.
+    - You should strictly follow `## Git Commits and Multi-Task Request`.
+    - For each `## Task X`, perform the work, git commit and push, before starting the next `## Task X`.
 - Jump to `Step 2` directly.
 
 ### Continue Investigation (only when "# Continue" appears in the LATEST chat message)
@@ -177,10 +178,13 @@ Propose any solution you can think of and write them down in the document, you m
 ## Git Commits and Multi-Task Request
 
 - `git commit` and `git push` all local changes to the current branch, unless there are explicit instructions to override this.
-- When the request is separated by multiple tasks like `## Task N` or `## Task TITLE`, it is important to do task one by one strictly, by me designing tasks in this way, we can achieve:
+- When the request is separated by multiple tasks like `## Task X`, it is important to do task one by one strictly, by me designing tasks in this way, we can achieve:
   - Easy-to-understand commits for file changing that is easy to review.
   - Limit side effects so that you don't have to deal with massive of issues at the same time.
-  - `git commit` and `git push` should happen after every single task, and before the next task, unless there are explicit instructions to override this.
-  - When different tasks happens in different repos, you are going to change the `Copilot_Investigate.md` in that repo.
+  - `git commit` and `git push` should happen after every single `## Task X`, and before the next `## Task X`:
+    - Unless there are explicit instructions to override this.
+    - **DO NOT** wait until all `## Task X` are finished and the do git commit and push. Even when they are related.
+    - By doing this you are able to secure the result of the previous `## Task X`, and when you mess up the current one, you are able to easily revert to the last successful state of the source code.
+  - When different `## Task X` happens in different repos, you are going to change the `Copilot_Investigate.md` in that repo.
     - If multiple repos are involved, for all involved repos that has the `Copilot_Investigate.md` file, decide which repo is the main repo for the task and update that file in the main repo.
     - If the repo does not have such document, you are allowed not to create one, skip writing such file.