Merge branch 'main' into merogge/bring-back-voice

Author: meganrogge

.github/chatmodes/learn.chatmode.md

@@ -1,57 +1,116 @@
-# Coding Guidelines
-
-## Introduction
-
-These are VS Code coding guidelines. Please also review our [Source Code Organisation](https://github.com/microsoft/vscode/wiki/Source-Code-Organization) page.
-
-## Indentation
+# VS Code Copilot Instructions
+
+## Project Overview
+
+Visual Studio Code is built with a layered architecture using TypeScript, web APIs and Electron, combining web technologies with native app capabilities. The codebase is organized into key architectural layers:
+
+### Root Folders
+- `src/`: Main TypeScript source code with unit tests in `src/vs/*/test/` folders
+- `build/`: Build scripts and CI/CD tools
+- `extensions/`: Built-in extensions that ship with VS Code
+- `test/`: Integration tests and test infrastructure
+- `scripts/`: Development and build scripts
+- `resources/`: Static resources (icons, themes, etc.)
+- `out/`: Compiled JavaScript output (generated during build)
+
+### Core Architecture (`src/` folder)
+- `src/vs/base/` - Foundation utilities and cross-platform abstractions
+- `src/vs/platform/` - Platform services and dependency injection infrastructure
+- `src/vs/editor/` - Text editor implementation with language services, syntax highlighting, and editing features
+- `src/vs/workbench/` - Main application workbench for web and desktop
+  - `workbench/browser/` - Core workbench UI components (parts, layout, actions)
+  - `workbench/services/` - Service implementations
+  - `workbench/contrib/` - Feature contributions (git, debug, search, terminal, etc.)
+  - `workbench/api/` - Extension host and VS Code API implementation
+- `src/vs/code/` - Electron main process specific implementation
+- `src/vs/server/` - Server specific implementation
+
+The core architecture follows these principles:
+- **Layered architecture** - from `base`, `platform`, `editor`, to `workbench`
+- **Dependency injection** - Services are injected through constructor parameters
+- **Contribution model** - Features contribute to registries and extension points
+- **Cross-platform compatibility** - Abstractions separate platform-specific code
+
+### Built-in Extensions (`extensions/` folder)
+The `extensions/` directory contains first-party extensions that ship with VS Code:
+- **Language support** - `typescript-language-features/`, `html-language-features/`, `css-language-features/`, etc.
+- **Core features** - `git/`, `debug-auto-launch/`, `emmet/`, `markdown-language-features/`
+- **Themes** - `theme-*` folders for default color themes
+- **Development tools** - `extension-editing/`, `vscode-api-tests/`
+
+Each extension follows the standard VS Code extension structure with `package.json`, TypeScript sources, and contribution points to extend the workbench through the Extension API.
+
+### Finding Related Code
+1. **Semantic search first**: Use file search for general concepts
+2. **Grep for exact strings**: Use grep for error messages or specific function names
+3. **Follow imports**: Check what files import the problematic module
+4. **Check test files**: Often reveal usage patterns and expected behavior
+
+## Coding Guidelines
+
+### Indentation
 
 We use tabs, not spaces.
 
-## Naming Conventions
+### Naming Conventions
+
+- Use PascalCase for `type` names
+- Use PascalCase for `enum` values
+- Use camelCase for `function` and `method` names
+- Use camelCase for `property` names and `local variables`
+- Use whole words in names when possible
 
-* Use PascalCase for `type` names
-* Use PascalCase for `enum` values
-* Use camelCase for `function` and `method` names
-* Use camelCase for `property` names and `local variables`
-* Use whole words in names when possible
+### Types
 
-## Types
+- Do not export `types` or `functions` unless you need to share it across multiple components
+- Do not introduce new `types` or `values` to the global namespace
 
-* Do not export `types` or `functions` unless you need to share it across multiple components
-* Do not introduce new `types` or `values` to the global namespace
+### Comments
 
-## Comments
+- Use JSDoc style comments for `functions`, `interfaces`, `enums`, and `classes`
 
-* When there are comments for `functions`, `interfaces`, `enums`, and `classes` use JSDoc style comments
+### Strings
 
-## Strings
+- Use "double quotes" for strings shown to the user that need to be externalized (localized)
+- Use 'single quotes' otherwise
+- All strings visible to the user need to be externalized
 
-* Use "double quotes" for strings shown to the user that need to be externalized (localized)
-* Use 'single quotes' otherwise
-* All strings visible to the user need to be externalized
+### UI labels
+- Use title-style capitalization for command labels, buttons and menu items (each word is capitalized).
+- Don't capitalize prepositions of four or fewer letters unless it's the first or last word (e.g. "in", "with", "for").
 
-## Style
+### Style
 
-* Use arrow functions `=>` over anonymous function expressions
-* Only surround arrow function parameters when necessary. For example, `(x) => x + x` is wrong but the following are correct:
+- Use arrow functions `=>` over anonymous function expressions
+- Only surround arrow function parameters when necessary. For example, `(x) => x + x` is wrong but the following are correct:
 
-```javascript
+```typescript
 x => x + x
 (x, y) => x + y
 <T>(x: T, y: T) => x === y
 ```
 
-* Always surround loop and conditional bodies with curly braces
-* Open curly braces always go on the same line as whatever necessitates them
-* Parenthesized constructs should have no surrounding whitespace. A single space follows commas, colons, and semicolons in those constructs. For example:
+- Always surround loop and conditional bodies with curly braces
+- Open curly braces always go on the same line as whatever necessitates them
+- Parenthesized constructs should have no surrounding whitespace. A single space follows commas, colons, and semicolons in those constructs. For example:
 
-```javascript
+```typescript
 for (let i = 0, n = str.length; i < 10; i++) {
     if (x < 10) {
         foo();
     }
 }
-
 function f(x: number, y: string): void { }
 ```
+
+- Whenever possible, use in top-level scopes `export function x(…) {…}` instead of `export const x = (…) => {…}`. One advantage of using the `function` keyword is that the stack-trace shows a good name when debugging.
+
+### Code Quality
+
+- All files must include Microsoft copyright header
+- Prefer `async` and `await` over `Promise` and `then` calls
+- All user facing messages must be localized using the applicable localization framework (for example `nls.localize()` method)
+- Don't add tests to the wrong test suite (e.g., adding to end of file instead of inside relevant suite)
+- Look for existing test patterns before creating new structures
+- Use `describe` and `test` consistently with existing patterns
+- If you create any temporary new files, scripts, or helper files for iteration, clean up these files by removing them at the end of the task

.github/chatmodes/plan.chatmode.md

@@ -0,0 +1,27 @@
+---
+applyTo: '**/*.ts'
+---
+
+# VS Code Copilot Development Instructions for TypeScript
+
+You MUST check compilation output before running ANY script or declaring work complete!
+
+1. **ALWAYS** check the "Core - Build" task output for compilation errors
+2. **ALWAYS** check the "Ext - Build" task output for compilation errors
+3. **NEVER** run tests if there are compilation errors
+4. **FIX** all compilation errors before moving forward
+
+## TypeScript compilation steps
+
+Typescript compilation errors can be found by running the "Core - Build" and "Ext - Build" tasks:
+- **Core - Build**: Compiles the main VS Code TypeScript sources
+- **Ext - Build**: Compiles the built-in extensions
+- These background tasks may already be running from previous development sessions
+- If not already running, start them to get real-time compilation feedback
+- The tasks provide incremental compilation, so they will automatically recompile when files change
+
+## TypeScript validation steps
+- Use `scripts/test.sh` (or `scripts\test.bat` on Windows) for unit tests (add `--grep <pattern>` to filter tests)
+- Use `scripts/test-integration.sh` (or `scripts\test-integration.bat` on Windows) for integration tests
+- Use `npm run valid-layers-check` to check for layering issues
+

.github/copilot-instructions.md

@@ -0,0 +1,10 @@
+---
+mode: agent
+description: 'Implement the solution for a problem.'
+tools: ['changes', 'codebase', 'editFiles', 'fetch', 'findTestFiles', 'openSimpleBrowser', 'problems', 'readNotebookCellOutput', 'runCommands', 'runNotebooks', 'runTasks', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
+---
+Please write a high quality, general purpose solution. Implement a solution that works correctly for all valid inputs, not just the test cases. Do not hard-code values or create solutions that only work for specific test inputs. Instead, implement the actual logic that solves the problem generally.
+
+Focus on understanding the problem requirements and implementing the correct algorithm. Tests are there to verify correctness, not to define the solution. Provide a principled implementation that follows best practices and software design principles.
+
+If the task is unreasonable or infeasible, or if any of the tests are incorrect, please tell me. The solution should be robust, maintainable, and extendable.

.github/instructions/typescript.instructions.md

@@ -0,0 +1,19 @@
+---
+mode: agent
+description: 'Plan the solution for a problem.'
+tools: ['codebase', 'fetch', 'findTestFiles', 'githubRepo', 'get_issue', 'get_issue_comments', 'get_me', 'search', 'searchResults', 'usages', 'vscodeAPI']
+---
+Your goal is to prepare a detailed plan to fix the bug or add the new feature, for this you first need to:
+* Understand the context of the bug or feature by reading the issue description and comments.
+* Understand the codebase by reading the relevant instruction files.
+* If its a bug, then identify the root cause of the bug, and explain this to the user.
+
+Based on your above understanding generate a plan to fix the bug or add the new feature.
+Ensure the plan consists of a Markdown document that has the following sections:
+
+* Overview: A brief description of the bug/feature.
+* Root Cause: A detailed explanation of the root cause of the bug, including any relevant code snippets or references to the codebase. (only if it's a bug)
+* Requirements: A list of requirements to resolve the bug or add the new feature.
+* Implementation Steps: A detailed list of steps to implement the bug fix or new feature.
+
+Remember, do not make any code edits, just generate a plan. Use thinking and reasoning skills to outline the steps needed to achieve the desired outcome.

.github/prompts/implement.prompt.md

@@ -93,6 +93,7 @@ jobs:
         id: cache-builtin-extensions
         uses: actions/cache/restore@v4
         with:
+          enableCrossOsArchive: true
           path: .build/builtInExtensions
           key: "builtin-extensions-${{ hashFiles('.build/builtindepshash') }}"
 

.github/prompts/plan.prompt.md

@@ -121,6 +121,7 @@ jobs:
         id: cache-builtin-extensions
         uses: actions/cache/restore@v4
         with:
+          enableCrossOsArchive: true
           path: .build/builtInExtensions
           key: "builtin-extensions-${{ hashFiles('.build/builtindepshash') }}"
 

.github/workflows/pr-darwin-test.yml

@@ -72,6 +72,7 @@ jobs:
         id: cache-builtin-extensions
         uses: actions/cache@v4
         with:
+          enableCrossOsArchive: true
           path: .build/builtInExtensions
           key: "builtin-extensions-${{ hashFiles('.build/builtindepshash') }}"
 

.github/workflows/pr-linux-test.yml

@@ -102,6 +102,7 @@ jobs:
         id: cache-builtin-extensions
         uses: actions/cache/restore@v4
         with:
+          enableCrossOsArchive: true
           path: .build/builtInExtensions
           key: "builtin-extensions-${{ hashFiles('.build/builtindepshash') }}"