fix(cli): don't block the UI thread on catalog refresh

catalog/Testing/Official-DotNet-Test/agents/code-testing-generator/AGENT.md

@@ -157,7 +157,7 @@ Summarize tests created, report any failures or issues, suggest next steps if ne
 - Consider adding integration tests for database layer
 ```
 
-> **Language-specific examples**: For a complete end-to-end walkthrough including sample source code, research output, plan, generated tests, and fix cycles, call the `code-testing-extensions` skill and read `dotnet-examples.md` for .NET.
+> **Language-specific examples**: For a complete end-to-end walkthrough including sample source code, research output, plan, generated tests, and fix cycles, call the `code-testing-extensions` skill and read the matching `<language>-examples.md` file when one exists — `dotnet-examples.md`, `python-examples.md`, `typescript-examples.md`, `go-examples.md`, and `java-examples.md` are currently available. For other languages, follow the base extension file (e.g., `rust.md`, `kotlin.md`) and adapt the pipeline shape shown in the closest example.
 
 ## State Management
 

catalog/Testing/Official-DotNet-Test/agents/code-testing-implementer/AGENT.md

@@ -51,6 +51,15 @@ For each test file in your phase:
 - Include tests for: happy path, edge cases (empty, null, boundary), error conditions
 - Mock all external dependencies — never call external URLs, bind ports, or depend on timing
 
+#### Edit boundaries (cross-language invariants)
+
+These rules apply to every language and override any pattern an existing test file may suggest. They keep generated changes additive so reviewers, CI gates, and test-quality benchmarks treat your output as a clean test addition rather than a refactor:
+
+- **Existing test files are append-only.** When growing an existing test file, insert new test methods/cases at the end of the relevant class/describe-block/module. Do not reformat, reorder, rename, or remove any existing line — even whitespace-only churn counts as a destructive edit.
+- **Do not modify non-test source files.** If a class, method, or symbol is hard to test (sealed, internal, no seam, tightly coupled), record the gap in `.testagent/plan.md` as a follow-up. Do not edit production code to make it testable as part of test generation — that is the scope of the `testability-migration` agent, not this one.
+- **Prefer new test files over edits to existing ones** when both options are equally valid (e.g., a new feature, a separate concern, or any case where the existing file isn't strictly required). A new file is always purely additive.
+- **One exception**: build-system manifests (`.csproj`/`.sln`/`pom.xml`/`build.gradle`/`Cargo.toml`/`package.json`/etc.) may be edited when registering a new test project or adding a missing test dependency. Keep these edits minimal and limited to the registration/dependency change.
+
 ### 5. Verify with Build
 
 Call the `code-testing-builder` sub-agent to compile. Build only the specific test project, not the full solution.
@@ -90,7 +99,7 @@ ISSUES:
 - [Any unresolved issues]
 ```
 
-> **Concrete example**: For a complete generated test file and build-error fix cycle walkthrough, call the `code-testing-extensions` skill and read `dotnet-examples.md` ("Sample Generated Test File" and "Sample Fix Cycle" sections).
+> **Concrete example**: For a complete generated test file and build-error fix cycle walkthrough, call the `code-testing-extensions` skill and read the matching `<language>-examples.md` file when one exists — `dotnet-examples.md`, `python-examples.md`, `typescript-examples.md`, `go-examples.md`, `java-examples.md` ("Sample Generated Test File" and "Sample Fix Cycle" sections). For other languages, adapt the closest example to the project's framework.
 
 ## Rules
 
@@ -99,3 +108,4 @@ ISSUES:
 3. **Match patterns** — follow existing test style
 4. **Be thorough** — cover edge cases
 5. **Report clearly** — state what was done and any issues
+6. **Stay within edit boundaries** — existing test files are append-only; never modify non-test source files (see Step 4 for details)

catalog/Testing/Official-DotNet-Test/agents/code-testing-planner/AGENT.md

@@ -126,7 +126,7 @@ What this phase accomplishes and why it's first.
 ...
 ```
 
-> **Concrete example**: For a filled-in plan with real method names, specific test scenarios, and phase structure, call the `code-testing-extensions` skill and read `dotnet-examples.md` ("Sample Plan Output" section).
+> **Concrete example**: For a filled-in plan with real method names, specific test scenarios, and phase structure, call the `code-testing-extensions` skill and read the matching `<language>-examples.md` file when one exists — `dotnet-examples.md`, `python-examples.md`, `typescript-examples.md`, `go-examples.md`, `java-examples.md` ("Sample Plan Output" section). For other languages, adapt the closest example.
 
 ## Rules
 

catalog/Testing/Official-DotNet-Test/agents/code-testing-researcher/AGENT.md

@@ -25,22 +25,28 @@ Analyze a codebase and produce a comprehensive research document that will guide
 
 Search for key files:
 
-- Project files: `*.csproj`, `*.vcxproj`, `*.sln`, `package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`
+- Project files: `*.csproj`, `*.vcxproj`, `*.sln`, `package.json`, `pyproject.toml`, `setup.cfg`, `setup.py`, `requirements*.txt`, `tox.ini`, `noxfile.py`, `uv.lock`, `poetry.lock`, `pdm.lock`, `Pipfile`, `Pipfile.lock`, `go.mod`, `go.work`, `Cargo.toml`, `pom.xml`, `build.gradle`, `build.gradle.kts`, `settings.gradle*`, `Gemfile`, `Gemfile.lock`, `Package.swift`, `*.xcodeproj`, `CMakeLists.txt`, `BUILD.bazel`, `meson.build`, `Makefile`, `Taskfile.yml`
 - Property and Target files: `*.props`, `*.targets`
-- Source files: `*.cs`, `*.ts`, `*.py`, `*.go`, `*.rs`, `*.cpp`, `*.h`
-- Existing tests: `*test*`, `*Test*`, `*spec*`
-- Config files: `README*`, `Makefile`, `*.config`
+- Source files: `*.cs`, `*.ts`, `*.tsx`, `*.js`, `*.jsx`, `*.mts`, `*.cts`, `*.py`, `*.go`, `*.rs`, `*.cpp`, `*.cc`, `*.h`, `*.hpp`, `*.java`, `*.kt`, `*.kts`, `*.swift`, `*.rb`, `*.ps1`, `*.psm1`
+- Test runner config: `vitest.config.*`, `jest.config.*`, `mocha.config.*`, `pytest.ini`, `conftest.py`, `phpunit.xml`, `karma.conf.*`, `playwright.config.*`
+- Existing tests: `*test*`, `*Test*`, `*spec*`, `*_test.go`
+- Config files: `README*`, `Makefile`, `*.config`, `*.editorconfig`
 
 ### 2. Identify the Language and Framework
 
 Based on files found:
 
-- **C#/.NET**: `*.csproj` → check for MSTest/xUnit/NUnit references
-- **TypeScript/JavaScript**: `package.json` → check for Jest/Vitest/Mocha
-- **Python**: `pyproject.toml` or `pytest.ini` → check for pytest/unittest
-- **Go**: `go.mod` → tests use `*_test.go` pattern
-- **Rust**: `Cargo.toml` → tests go in same file or `tests/` directory
-- **C++**: `*.vcxproj` → check for GoogleTest (gtest) references
+- **C#/.NET**: `*.csproj` → check for MSTest/xUnit/NUnit/TUnit references
+- **TypeScript/JavaScript**: `package.json` → check `devDependencies` for Jest/Vitest/Mocha/`node:test`; check `scripts.test`; check for `vitest.config.*` / `jest.config.*`
+- **Python**: `pyproject.toml` / `setup.cfg` / `pytest.ini` / `tox.ini` / `noxfile.py` → check for pytest/unittest/custom runners; detect package manager via `poetry.lock` / `pdm.lock` / `uv.lock` / `Pipfile.lock`
+- **Go**: `go.mod` → tests use `*_test.go` pattern; `go.work` indicates a multi-module workspace
+- **Rust**: `Cargo.toml` → tests live in same file (`#[cfg(test)] mod tests`), in `tests/` (integration), or as doc tests
+- **C++**: `CMakeLists.txt` / `BUILD.bazel` / `meson.build` / `*.vcxproj` / `Makefile` → check for GoogleTest (`gtest`), Catch2, doctest, or Boost.Test
+- **Java**: `pom.xml` (Maven) or `build.gradle[.kts]` (Gradle) — check for JUnit Jupiter, JUnit 4, TestNG, Mockito; always prefer `./mvnw` / `./gradlew` wrappers
+- **Kotlin**: same build files as Java, plus `kotlin("jvm")` / `kotlin("multiplatform")` plugins — check for JUnit, Kotest, kotlin.test, MockK
+- **Ruby**: `Gemfile` / `Gemfile.lock` — check for RSpec (`spec/`) or Minitest (`test/`)
+- **Swift**: `Package.swift` (SPM) or `*.xcodeproj`/`*.xcworkspace` (Xcode) — distinguish XCTest vs Swift Testing
+- **PowerShell**: `*.ps1`/`*.psm1` files alongside `*.Tests.ps1` — Pester is the dominant framework
 
 ### 3. Identify the Scope of Testing
 
@@ -160,4 +166,4 @@ For each test project found, list:
 
 Write the research document to `.testagent/research.md` in the workspace root.
 
-> **Concrete example**: For a filled-in research document showing real file paths, detected frameworks, and prioritized file tables, call the `code-testing-extensions` skill and read `dotnet-examples.md` ("Sample Research Output" section).
+> **Concrete example**: For a filled-in research document showing real file paths, detected frameworks, and prioritized file tables, call the `code-testing-extensions` skill and read the matching `<language>-examples.md` file when one exists — `dotnet-examples.md`, `python-examples.md`, `typescript-examples.md`, `go-examples.md`, `java-examples.md` ("Sample Research Output" section). For other languages, adapt the closest example.

catalog/Testing/Official-DotNet-Test/agents/test-migration/AGENT.md

@@ -49,6 +49,7 @@ Classify the user's request and route to the appropriate skill or agent:
 | "Upgrade MSTest" / "latest MSTest" (v3 detected) | `migrate-mstest-v3-to-v4` skill |
 | "Upgrade MSTest" (v1/v2 detected, user wants v4) | `migrate-mstest-v1v2-to-v3` first, then `migrate-mstest-v3-to-v4` |
 | "Migrate to xUnit v3" / "upgrade xUnit" | `migrate-xunit-to-xunit-v3` skill |
+| "Convert xUnit to MSTest" / "switch from xUnit to MSTest" / "port xUnit tests to MSTest" (xUnit v2 or v3 detected) | `migrate-xunit-to-mstest` skill |
 | "Migrate to MTP" / "switch from VSTest" / "modern test runner" | `migrate-vstest-to-mtp` skill |
 | "Make code testable" / "remove static dependencies" | Hand off to `testability-migration` agent |
 | "Migrate my tests" (no specifics) | Run detection, then recommend and confirm the migration path |
@@ -106,6 +107,8 @@ Some migrations must happen in sequence:
 | MSTest v1/v2 | MSTest v3 + MTP | `migrate-mstest-v1v2-to-v3` → `migrate-vstest-to-mtp` |
 | MSTest v3 | MSTest v4 + MTP | `migrate-mstest-v3-to-v4` → `migrate-vstest-to-mtp` (order flexible) |
 | xUnit v2 | xUnit v3 | `migrate-xunit-to-xunit-v3` (single step; v3 has native MTP support) |
+| xUnit v2 or v3 | MSTest v4 | `migrate-xunit-to-mstest` (single step; preserves current test platform — VSTest stays VSTest, MTP stays MTP) |
+| xUnit v2 or v3 | MSTest v4 + MTP | `migrate-xunit-to-mstest` → `migrate-vstest-to-mtp` (only if the project was on VSTest before; commit between) |
 | Any framework | MTP only | `migrate-vstest-to-mtp` (single step) |
 
 **Always commit between migration steps.** Each step should leave the project in a buildable, test-passing state.