Merge branch 'main' of https://github.com/microsoft/vscode into osortega/steady-puma

.github/copilot-instructions.md

@@ -145,6 +145,7 @@ function f(x: number, y: string): void { }
 - You MUST NOT use storage keys of another component only to make changes to that component. You MUST come up with proper API to change another component.
 - Use `IEditorService` to open editors instead of `IEditorGroupsService.activeGroup.openEditor` to ensure that the editor opening logic is properly followed and to avoid bypassing important features such as `revealIfOpened` or `preserveFocus`.
 - Avoid using `bind()`, `call()` and `apply()` solely to control `this` or partially apply arguments; prefer arrow functions or closures to capture the necessary context, and use these methods only when required by an API or interoperability.
+- Avoid using events to drive control flow between components. Instead, prefer direct method calls or service interactions to ensure clearer dependencies and easier traceability of logic. Events should be reserved for broadcasting state changes or notifications rather than orchestrating behavior across components.
 
 ## Learnings
 - Minimize the amount of assertions in tests. Prefer one snapshot-style `assert.deepStrictEqual` over multiple precise assertions, as they are much more difficult to understand and to update.

.github/instructions/remoteAgentHost.instructions.md

@@ -0,0 +1,35 @@
+---
+description: Architecture documentation for remote agent host connections. Use when working in `src/vs/sessions/contrib/remoteAgentHost`
+applyTo: src/vs/sessions/contrib/remoteAgentHost/**
+---
+
+# Remote Agent Host
+
+The remote agent host feature connects the sessions app to agent host processes running on other machines over WebSocket.
+
+## Key Files
+
+- `ARCHITECTURE.md` - full architecture documentation (URI conventions, registration flow, data flow diagram)
+- `REMOTE_AGENT_HOST_RECONNECTION.md` - reconnection lifecycle spec (15 numbered requirements)
+- `browser/remoteAgentHost.contribution.ts` - central orchestrator
+- `browser/agentHostFileSystemProvider.ts` - read-only FS provider for remote browsing
+
+## Architecture Documentation
+
+When making changes to this feature area, **review and update `ARCHITECTURE.md`** if your changes affect:
+
+- Connection lifecycle (connect, disconnect, reconnect)
+- Agent registration flow
+- URI conventions or naming
+- Session creation flow
+- The data flow diagram
+
+The doc lives at `src/vs/sessions/contrib/remoteAgentHost/ARCHITECTURE.md`.
+
+## Related Code Outside This Folder
+
+- `src/vs/platform/agentHost/common/remoteAgentHostService.ts` - service interface (`IRemoteAgentHostService`)
+- `src/vs/platform/agentHost/electron-browser/remoteAgentHostServiceImpl.ts` - Electron implementation
+- `src/vs/platform/agentHost/electron-browser/remoteAgentHostProtocolClient.ts` - WebSocket protocol client
+- `src/vs/workbench/contrib/chat/browser/agentSessions/agentHost/agentHostSessionListController.ts` - session list sidebar
+- `src/vs/workbench/contrib/chat/browser/agentSessions/agentHost/agentHostSessionHandler.ts` - session content provider

.github/prompts/fix-error.prompt.md

@@ -23,16 +23,32 @@ After the fix is validated (compilation clean, tests pass):
 1. **Create a branch**: `git checkout -b <github-username>/<short-description>` (e.g., `bryanchen-d/fix-notebook-index-error`).
 2. **Commit**: Stage changed files and commit with a message like `fix: <brief description> (#<issue-number>)`.
 3. **Push**: `git push -u origin <branch-name>`.
-4. **Create a draft PR** with a description that includes:
-   - A summary of the change.
-   - `Fixes #<issue-number>` so GitHub auto-closes the issue when the PR merges.
-   - What scenarios may trigger the error.
-   - The code flow explaining why the error gets thrown and goes unhandled.
-   - Steps a user can follow to manually validate the fix.
-   - How the fix addresses the issue, with a brief note per changed file.
-5. **Monitor the PR** for Copilot review comments. Wait 1-2 minutes after each push for Copilot to leave its review, then check for new comments. Evaluate each comment:
-   - If valid, apply the fix in a new commit, push, and **resolve the comment thread** using the GitHub GraphQL API (`resolveReviewThread` mutation with the thread's node ID).
-   - If not applicable, leave a reply explaining why.
-   - After addressing comments, update the PR description if the changes affect the summary, code flow explanation, or per-file notes.
-6. **Repeat monitoring** after each push: wait 1-2 minutes, check for new Copilot comments, and address them. Continue this loop until no new comments appear.
-7. **Re-run tests** after addressing review comments to confirm nothing regressed.
+4. **Create a draft PR** with a description that includes these sections:
+   - **Summary**: A concise description of what was changed and why.
+   - **Issue link**: `Fixes #<issue-number>` so GitHub auto-closes the issue when the PR merges.
+   - **Trigger scenarios**: What user actions or system conditions cause this error to surface.
+   - **Code flow diagram**: A Mermaid swimlane/sequence diagram showing the call chain from trigger to error. Use participant labels for the key components (e.g., classes, modules, processes). Example:
+     ````
+     ```mermaid
+     sequenceDiagram
+         participant A as CallerComponent
+         participant B as MiddleLayer
+         participant C as LowLevelUtil
+         A->>B: someOperation(data)
+         B->>C: validate(data)
+         C-->>C: data is invalid
+         C->>B: throws "error message"
+         B->>A: unhandled error propagates
+     ```
+     ````
+   - **Manual validation steps**: Concrete, step-by-step instructions a reviewer can follow to reproduce the original error and verify the fix. Include specific setup requirements (e.g., file types to open, settings to change, actions to perform). If the error cannot be easily reproduced manually, explain why and describe what alternative validation was performed (e.g., unit tests, code inspection).
+   - **How the fix works**: A brief explanation of the fix approach, with a note per changed file.
+5. **Monitor the PR — BLOCKING**: You MUST NOT complete the task until the monitoring loop below is done.
+   - Wait 2 minutes after each push, then check for Copilot review comments using `gh pr view <number> --json reviews,comments` and `gh api repos/{owner}/{repo}/pulls/{number}/comments`.
+   - If there are review comments, evaluate each one:
+     - If valid, apply the fix in a new commit, push, and **resolve the comment thread** using the GitHub GraphQL API (`resolveReviewThread` mutation with the thread's node ID).
+     - If not applicable, leave a reply explaining why.
+     - After addressing comments, update the PR description if the changes affect the summary, diagram, or per-file notes.
+   - **Re-run tests** after addressing review comments to confirm nothing regressed.
+   - After each push, repeat the wait-and-check cycle. Continue until **two consecutive checks return zero new comments**.
+6. **Verify CI**: After the monitoring loop is done, check that CI checks are passing using `gh pr checks <number>`. If any required checks fail, investigate and fix. Do NOT complete the task with failing CI.

.github/skills/chat-customizations-editor/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: chat-customizations-editor
+description: Use when working on the Chat Customizations editor — the management UI for agents, skills, instructions, hooks, prompts, MCP servers, and plugins.
+---
+
+# Chat Customizations Editor
+
+Split-view management pane for AI customization items across workspace, user, extension, and plugin storage. Supports harness-based filtering (Local, Copilot CLI, Claude).
+
+## Spec
+
+**`src/vs/sessions/AI_CUSTOMIZATIONS.md`** — always read before making changes, always update after.
+
+## Key Folders
+
+| Folder | What |
+|--------|------|
+| `src/vs/workbench/contrib/chat/common/` | `ICustomizationHarnessService`, `ISectionOverride`, `IStorageSourceFilter` — shared interfaces and filter helpers |
+| `src/vs/workbench/contrib/chat/browser/aiCustomization/` | Management editor, list widgets (prompts, MCP, plugins), harness service registration |
+| `src/vs/sessions/contrib/chat/browser/` | Sessions-window overrides (harness service, workspace service) |
+| `src/vs/sessions/contrib/sessions/browser/` | Sessions tree view counts and toolbar |
+
+When changing harness descriptor interfaces or factory functions, verify both core and sessions registrations compile.
+
+## Key Interfaces
+
+- **`IHarnessDescriptor`** — drives all UI behavior declaratively (hidden sections, button overrides, file filters, agent gating). See spec for full field reference.
+- **`ISectionOverride`** — per-section button customization (command invocation, root file creation, type labels, file extensions).
+- **`IStorageSourceFilter`** — controls which storage sources and user roots are visible per harness/type.
+
+Principle: the UI widgets read everything from the descriptor — no harness-specific conditionals in widget code.
+
+## Testing
+
+Component explorer fixtures (see `component-fixtures` skill): `aiCustomizationListWidget.fixture.ts`, `aiCustomizationManagementEditor.fixture.ts` under `src/vs/workbench/test/browser/componentFixtures/`.
+
+```bash
+./scripts/test.sh --grep "applyStorageSourceFilter|customizationCounts"
+npm run compile-check-ts-native && npm run valid-layers-check
+```
+
+See the `sessions` skill for sessions-window specific guidance.

.github/skills/unit-tests/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: unit-tests
+description: Use when running unit tests in the VS Code repo. Covers the runTests tool, scripts/test.sh (macOS/Linux) and scripts/test.bat (Windows), and their supported arguments for filtering, globbing, and debugging tests.
+---
+
+# Running Unit Tests
+
+## Preferred: Use the `runTests` tool
+
+If the `runTests` tool is available, **prefer it** over running shell commands. It provides structured output with detailed pass/fail information and supports filtering by file and test name.
+
+- Pass absolute paths to test files via the `files` parameter.
+- Pass test names via the `testNames` parameter to filter which tests run.
+- Set `mode="coverage"` to collect coverage.
+
+Example (conceptual): run tests in `src/vs/editor/test/common/model.test.ts` with test name filter `"should split lines"`.
+
+## Fallback: Shell scripts
+
+When the `runTests` tool is not available (e.g. in CLI environments), use the platform-appropriate script from the repo root:
+
+- **macOS / Linux:** `./scripts/test.sh [options]`
+- **Windows:** `.\scripts\test.bat [options]`
+
+These scripts download Electron if needed and launch the Mocha test runner.
+
+### Commonly used options
+
+#### `--run <file>` - Run tests from a specific file
+
+Accepts a **source file path** (starting with `src/`). The runner strips the `src/` prefix and the `.ts`/`.js` extension automatically to resolve the compiled module.
+
+```bash
+./scripts/test.sh --run src/vs/editor/test/common/model.test.ts
+```
+
+Multiple files can be specified by repeating `--run`:
+
+```bash
+./scripts/test.sh --run src/vs/editor/test/common/model.test.ts --run src/vs/editor/test/common/range.test.ts
+```
+
+#### `--grep <pattern>` (aliases: `-g`, `-f`) - Filter tests by name
+
+Runs only tests whose full title matches the pattern (passed to Mocha's `--grep`).
+
+```bash
+./scripts/test.sh --grep "should split lines"
+```
+
+Combine with `--run` to filter tests within a specific file:
+
+```bash
+./scripts/test.sh --run src/vs/editor/test/common/model.test.ts --grep "should split lines"
+```
+
+#### `--runGlob <pattern>` (aliases: `--glob`, `--runGrep`) - Run tests matching a glob
+
+Runs all test files matching a glob pattern against the compiled output directory. Useful for running all tests under a feature area.
+
+```bash
+./scripts/test.sh --runGlob "**/editor/test/**/*.test.js"
+```
+
+Note: the glob runs against compiled `.js` files in the output directory, not source `.ts` files.
+
+#### `--coverage` - Generate a coverage report
+
+```bash
+./scripts/test.sh --run src/vs/editor/test/common/model.test.ts --coverage
+```
+
+#### `--timeout <ms>` - Set test timeout
+
+Override the default Mocha timeout for long-running tests.
+
+```bash
+./scripts/test.sh --run src/vs/editor/test/common/model.test.ts --timeout 10000
+```
+
+### Integration tests
+
+Integration tests (files ending in `.integrationTest.ts` or located in `extensions/`) are **not run** by `scripts/test.sh`. Use `scripts/test-integration.sh` (or `scripts/test-integration.bat`) instead.
+
+### Compilation requirement
+
+Tests run against compiled JavaScript output. Ensure the `VS Code - Build` watch task is running or that compilation has completed before running tests. Test failures caused by stale output are a common pitfall.