{"owner":"microsoft","repo":"winget-cli","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md",".github/copilot-instructions.md"],"files":{"AGENTS.md":"# Agent instructions\n\nFollow `.github/copilot-instructions.md` for repository-specific development guidance.\n\n## Issues\n\nBefore filing a GitHub issue in this repository:\n\n1. Search existing open and closed issues for duplicates.\n2. Use the GitHub issue forms in `.github/ISSUE_TEMPLATE/`; do not file a blank issue unless a maintainer explicitly asks for one.\n3. For bugs, include the same information requested by the Bug Report form: relevant area, command if applicable, brief description, steps to reproduce, expected behavior, actual behavior, and environment.\n4. For feature requests, include the same information requested by the Feature Request form: relevant area, description of the new feature or enhancement, and proposed technical implementation details when known.\n5. Keep issue bodies concise and evidence-based. Do not paste large speculative patches into issue bodies; open a pull request or link a branch when code is available.\n\n## Pull requests\n\nBefore opening a pull request:\n\n1. Review `CONTRIBUTING.md` and follow the repository PR template.\n2. Keep each PR focused on one logical change.\n3. Include or update tests and documentation when the change affects behavior, command output, user guidance, or public APIs.\n4. Summarize validation performed, or explain why validation was not run.\n",".github/copilot-instructions.md":"# WinGet CLI Development Guide\n\n## Project Overview\n\nThis is the Windows Package Manager (WinGet) CLI client - a native Windows application for discovering and installing packages. The codebase consists of:\n\n- **C++/WinRT client** (`src/AppInstallerCLI*`) - The main CLI and core logic\n- **COM API** (`src/Microsoft.Management.Deployment`) - Public Windows Runtime API for programmatic access\n- **PowerShell modules** (`src/PowerShell`) - Microsoft.WinGet.Client and Microsoft.WinGet.Configuration cmdlets\n- **Configuration system** - DSC-based system configuration using WinGet\n\n## Building, Testing, and Running\n\n### Initial Setup\n\nUse a configuration file in `.config` as in `winget configure .config/configuration.winget` (alternatives provided for other VS SKUs).\n\nManual steps:\n\n1. Install Visual Studio 2022 with required workloads (see `.vsconfig`)\n2. Install Windows SDK 10.0.26100: `winget install Microsoft.WindowsSDK.10.0.26100`\n3. Enable developer mode in Windows\n4. Run `vcpkg integrate install` from Developer Command Prompt\n\n### Building\n\nOpen `src\\AppInstallerCLI.sln` in Visual Studio and build the solution (Ctrl+Shift+B) or use msbuild.exe to build from the command line.\n\nThe solution uses:\n- MSBuild\n- vcpkg for C++ dependencies\n- NuGet for C++ and .NET dependencies\n\n### Running/Debugging\n\n1. Deploy solution: Build > Deploy Solution\n2. Run from command line: `wingetdev`\n3. For debugging:\n   - Right-click `AppInstallerCLIPackage` > Properties > Debug tab\n   - Set Debugger type to \"Native Only\" for both Application and Background task processes\n   - Select \"Do not launch, but debug my code when it starts\"\n   - Press F5 and run `wingetdev` in a separate terminal\n\nEntry point: `src/AppInstallerCLI/main.cpp`\n\n### Testing\n\n#### C++ Unit Tests (Catch2)\nLocated in `AppInstallerCLITests` project. After building:\n\n```powershell\n# Run all tests\nsrc\\<ARCH>\\<Debug|Release>\\AppInstallerCLITests\\AppInstallerCLITests.exe\n\n# Run specific test\nsrc\\<ARCH>\\<Debug|Release>\\AppInstallerCLITests\\AppInstallerCLITests.exe TestName\n\n# Available options\nAppInstallerCLITests.exe --help\n```\n\n#### .NET Tests\n- `Microsoft.WinGet.UnitTests` - PowerShell module tests\n- `Microsoft.Management.Configuration.UnitTests` - Configuration system tests\n- `WinGetUtilInterop.UnitTests` - Interop layer tests\n\n#### E2E Tests\n`AppInstallerCLIE2ETests` project contains end-to-end integration tests.\n\n## Architecture\n\n### Core Components\n\n**AppInstallerCLICore** - Core CLI logic organized around:\n- **ExecutionContext**: State container that flows through workflows. Contains arguments, reporter, flags, and data (ExecutionContextData.h)\n- **Workflows**: Composable functions that take ExecutionContext and perform operations (e.g., InstallFlow, UpdateFlow, SearchFlow)\n- **Commands**: Parse arguments and orchestrate workflows\n- **Reporter**: Handles all user output (ExecutionReporter.h)\n\n**AppInstallerRepositoryCore** - Package source abstraction:\n- Interfaces for different source types (REST, SQLite index, Microsoft Store, composite)\n- Search, match, and correlation logic\n- Package version selection and dependencies\n\n**AppInstallerCommonCore** - Shared utilities:\n- Manifest parsing (YAML/JSON)\n- Settings and group policy\n- Telemetry and logging\n- HTTP client, downloader, archive handling\n\n**Microsoft.Management.Deployment** - COM API surface:\n- IDL definitions in `PackageManager.idl`\n- WinRT projections for external consumption\n- Used by PowerShell modules and third-party integrations\n\n**AppInstallerCLIPackage** - Dev MSIX package definition:\n- Models the release package definition as closely as possible.\n- Contains localized string resources at src\\AppInstallerCLIPackage\\Shared\\Strings\\en-us\\winget.resw\n\n### Key Patterns\n\n**Workflow Pattern**: Functions that operate on ExecutionContext:\n```cpp\nvoid WorkflowTask(Execution::Context& context)\n{\n    // Check if already terminated\n    AICLI_RETURN_IF_TERMINATED(context);\n    \n    // Access data\n    auto& data = context.Get<Data::Installer>();\n    \n    // Report to user\n    context.Reporter.Info() << \"Doing something\";\n    \n    // Store data for next workflow\n    context.Add<Data::SomeResult>(result);\n    \n    // Terminate on error\n    if (failed)\n    {\n        AICLI_TERMINATE_CONTEXT(HRESULT);\n    }\n}\n```\n\n**Source Composition**: Multiple package sources can be composed:\n- CompositeSource combines multiple sources with conflict resolution\n- Installed source tracks locally installed packages\n- Available sources provide packages to install\n\n**Manifest Schema**: Package manifests use versioned YAML schemas:\n- Schema definitions in `schemas/JSON/manifests/`\n- Parsing in `AppInstallerCommonCore/Manifest/`\n- Multi-file manifests: installer, locale, version, defaultLocale\n\n## Naming Conventions\n\n- **Namespace structure**: `AppInstaller::<Area>[::<Subarea>]`\n  - `AppInstaller::CLI::Execution` - CLI execution context\n  - `AppInstaller::CLI::Workflow` - Workflow functions\n  - `AppInstaller::Repository` - Repository/source logic\n  - `AppInstaller::Manifest` - Manifest types\n  - `AppInstaller::Settings` - User/admin settings\n\n- **Macros**: Prefixed with `AICLI_` for CLI, `WINGET_` for general\n- **Data keys**: ExecutionContextData uses enum keys to type-safely store/retrieve data\n\n## Windows-Specific Considerations\n\n- Use Windows-style paths with backslashes (`\\`)\n- Leverage WinRT APIs via C++/WinRT projections\n- COM threading models matter - client uses multi-threaded apartment (MTA)\n- Package deployment uses Windows App SDK / MSIX infrastructure\n- Requires Windows 10 1809+ (build 17763)\n\n## Contributing\n\n- Review `CONTRIBUTING.md` for workflow\n- File/discuss issues before starting work\n- Specs required for features (stored in `doc/specs/`); see `.github/instructions/specs.instructions.md` for detailed guidance\n- Follow existing code style (see `stylecop.json`)\n- CI runs on Azure Pipelines (`azure-pipelines.yml`)\n\n## Issues and Pull Requests\n\n- Before filing an issue, search existing open and closed issues for duplicates.\n- Use the GitHub issue forms in `.github/ISSUE_TEMPLATE/`; do not file a blank issue unless a maintainer explicitly asks for one.\n- Bug reports should include the form fields for relevant area, command if applicable, brief description, steps to reproduce, expected behavior, actual behavior, and environment.\n- Feature requests should include the form fields for relevant area, feature or enhancement description, and proposed technical implementation details when known.\n- Keep issue bodies concise and evidence-based. Do not paste large speculative patches into issue bodies; open a pull request or link a branch when code is available.\n- Before opening a pull request, review `CONTRIBUTING.md`, follow the PR template, keep the change focused, and summarize validation performed.\n\n## Useful Commands\n\n```powershell\n# Get WinGet client info\nwingetdev --info\n\n# Show experimental features\nwingetdev features\n\n# Check sources\nwingetdev source list\n```\n\n## Localization\n\n### Source of truth\n\nThe English resource file `src\\AppInstallerCLIPackage\\Shared\\Strings\\en-us\\winget.resw` is the only file contributors should edit for string changes. It feeds the Microsoft localization pipeline.\n\nThe files under `Localization\\Resources\\<locale>\\` are **automatically synced from Microsoft's internal localization system and must not be edited**. Any manual edits will be overwritten on the next sync.\n\nEvery string that could be misunderstood without context should have a `<comment>`.\n\n### Triggering retranslation\n\n- **Changing a string's `<value>`** automatically queues it for retranslation on the next localization sync.\n- **Changing only a `<comment>`** does NOT trigger retranslation. Comments improve future translations but do not fix existing ones.\n\nTo fix an existing bad translation, a bug has to be filed internally with the localization team.\n"}}