If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/microsoft/microsoft-ui-xaml shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1d ago
• 27+ active contributors
• Distributed ownership (top contributor 23% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live microsoft/microsoft-ui-xaml repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/microsoft/microsoft-ui-xaml.

What it runs against: a local clone of microsoft/microsoft-ui-xaml — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in microsoft/microsoft-ui-xaml | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of microsoft/microsoft-ui-xaml. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/microsoft/microsoft-ui-xaml.git
#   cd microsoft-ui-xaml
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of microsoft/microsoft-ui-xaml and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "microsoft/microsoft-ui-xaml(\\.git)?\\b" \\
  && ok "origin remote is microsoft/microsoft-ui-xaml" \\
  || miss "origin remote is not microsoft/microsoft-ui-xaml (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/microsoft/microsoft-ui-xaml"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

WinUI 3 is the modern UI framework powering Windows applications with a rich set of Fluent Design controls, styles, and components. It provides C++ and C# developers with a native Windows runtime (WinRT) abstraction layer built primarily in C++ (61.5M lines) with C# bindings (17.9M lines), enabling high-performance desktop and UWP apps on Windows 10 1809+ and Windows 11. It ships as part of the Windows App SDK and powers key Windows system experiences like Settings, Windows Terminal components, and first-party Microsoft apps. Monorepo structure: Core C++ implementation in unnamed root directories (inferred from file counts), C# bindings layer (17.9M lines), control definitions and styles, comprehensive specs/ folder with feature specifications (CalendarView/, AnimatedVisualPlayer, etc.), extensive docs/ for contribution workflows, debugging, and feature proposals. GitHub-driven workflow with .github/CODEOWNERS, automated issue triage, PR templates, and Fluent Design specification documentation throughout specs/.

Windows desktop application developers using C++ or C# who need modern, accessible, performant UI controls with Fluent Design semantics. Also internal Microsoft engineers building system-level Windows experiences. Contributors include Microsoft employees and open-source contributors improving controls, styles, theming, and accessibility across the framework.

Highly mature and production-ready. WinUI 3 is the official modern UI framework for Windows App SDK (released 2021, current generation in active use across Windows). The codebase shows significant complexity (61.5M lines C++), established CI/CD pipelines (.github/workflows/), comprehensive documentation (docs/, specs/), and active triage processes (docs/triage.md). This is a first-party Microsoft framework shipping in production systems.

Low risk for established features, moderate risk for newer controls still under development. The monolithic C++ codebase (61.5M lines) and tight coupling to Windows platform versions (requires Windows 10 1809+) mean breaking changes can impact many downstream applications. Community is secondary to internal Microsoft usage, so priorities may not always align with third-party developer needs. No visible dependency vulnerability reporting in the file structure.

Active development with established triage, contribution handling, and feature proposal processes (docs/contribution_handling.md, docs/feature_proposal_process.md, docs/feature_proposal_process_summary.png). Recent focus visible in specs/ folder shows work on controls like CalendarView with detailed visual specifications and corner radius customization. Automated workflows for similar-issues-bot and docs generation active. This is an ongoing, maintained project with clear governance.

git clone https://github.com/microsoft/microsoft-ui-xaml.git
cd microsoft-ui-xaml
# Review CONTRIBUTING.md for build prerequisites (Visual Studio, Windows SDK)
# Build process inferred to use standard Windows/C++ tooling; exact commands in docs/
# See docs/contribution_workflow.md for detailed onboarding

Daily commands: No traditional 'npm start' — this is a compiled framework library, not a runnable application. Build and test via Visual Studio solution files (inferred from C++ codebase). See docs/debugging_buildfailures.md and docs/debugging_crashes.md for build/test workflows. WinUI Gallery (https://aka.ms/winui-gallery) is the interactive sample; build instructions in CONTRIBUTING.md.

• CONTRIBUTING.md: Primary entry point for new contributors detailing setup, coding standards, PR process, and community guidelines
• .github/CODEOWNERS: Defines which team members own which components; critical for understanding code structure and review routing
• docs/contribution_workflow.md: Step-by-step guide for setting up development environment, branching strategy, and submission process specific to this project
• docs/feature_proposal_process.md: Documents how new features are designed and vetted; essential for understanding control development methodology
• specs/: Directory containing detailed specifications for controls (CalendarView, AnimatedVisualPlayer, etc.) showing expected behavior and design decisions
• docs/debugging_buildfailures.md: Troubleshooting guide for common C++ compilation and linking issues in the Windows SDK environment
• .github/workflows/: CI/CD pipeline definitions (docs.yml, similar-issues-bot.yml) showing automated checks and deployment processes

Start in specs/ for feature specifications and design (e.g., specs/CalendarView/ for control-specific work). For bug fixes: identify affected control folder (inferred from C++ structure), add tests, update corresponding C# bindings if needed. For new controls: follow feature proposal process (docs/feature_proposal_process.md), create spec, implement C++, add C# binding, test. Code review via GitHub PRs with CODEOWNERS routing (.github/CODEOWNERS). Use docs/contribution_workflow.md as guide.

Windows 10 1809+ SDK required (not cross-platform compatible). XAML compilation and C++ template code generation can cause cryptic build errors — see docs/debugging_buildfailures.md. Dependency property system (inherited from WPF/UWP) has non-obvious semantics around value coercion and change notifications. C++/C# marshaling boundaries require care with object lifetime and WinRT COM semantics. Build artifacts and binlog analysis needed for diagnostic traces (see docs/images/binlog-images/). Feature proposals require design review before implementation — fast rejection of out-of-scope changes is policy.

• XAML (eXtensible Application Markup Language) — WinUI controls are declared and composed via XAML syntax, so understanding declarative UI markup structure and binding semantics is fundamental to WinUI development
• WinRT (Windows Runtime) and COM Interop — WinUI is built atop WinRT, a binary interface standard enabling language projections (C++, C#, etc.) to call native Windows components; understanding COM reference counting and marshaling is critical for interop debugging
• Dependency Property System — WinUI controls inherit the WPF/UWP dependency property model for advanced features like data binding, animation, style inheritance, and change notification — core to control behavior but subtle in implementation
• Fluent Design System — WinUI embodies Microsoft's Fluent Design language (depth, motion, color, transparency); understanding design principles ensures contributions maintain visual and interaction consistency across the framework
• Template Specialization and Code Generation — Heavy use of C++ templates and generated XAML binding code; build failures often stem from template instantiation or IDL-to-C++ projection mismatches requiring understanding of the code generation pipeline
• RoutedEvents and Event Bubbling — WinUI events propagate through visual trees using routed event semantics (borrowed from WPF); understanding tunneling vs. bubbling and event handling order is essential for correct input handling and custom control implementation
• Visual Composition and DXInterop — Modern WinUI uses Windows.UI.Composition for advanced visual effects and animations; lower-level Direct2D/Direct3D interop enables custom rendering and high-performance graphics within WinUI containers

• microsoft/WindowsAppSDK — Parent project: WinUI 3 ships as a component within Windows App SDK; this is the integration point for deployment and platform APIs
• microsoft/terminal — High-profile consumer of WinUI controls and styles; demonstrates real-world usage patterns and serves as test bed for framework improvements
• microsoft/Win2D — Companion graphics library providing Direct2D/DirectX abstraction for WinUI; often used together for custom rendering in WinUI applications
• microsoft/XAML-Docs — Official Microsoft documentation and samples for XAML and Windows UI development; primary reference for WinUI 3 usage patterns and best practices
• microsoft/WinUI-Gallery — Interactive sample application showcasing all WinUI 3 controls and their capabilities; living documentation and dogfooding vehicle for the framework

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive spec documentation for NavigationView control patterns

The specs/ directory contains detailed specifications for CalendarView, ColorPicker, and CustomCondition, but NavigationView (a core WinUI control) lacks formal specification documentation. This would help contributors understand expected behavior, accessibility requirements, and visual state specifications for this commonly-used control.

• [ ] Create specs/NavigationView/ directory structure matching existing patterns (e.g., CalendarView/)
• [ ] Document NavigationView behavior spec including pane display modes, selection states, and keyboard navigation
• [ ] Add visual specification images for different NavigationView layouts (compact, minimal, expanded modes)
• [ ] Cross-reference spec in README or docs/feature_proposal_process.md to increase discoverability

Expand CONTRIBUTING.md with debugging WinUI-specific crashes and build failures

While docs/debugging_buildfailures.md and docs/debugging_crashes.md exist, they are not referenced in the main CONTRIBUTING.md file. New contributors starting with CONTRIBUTING.md won't discover these critical debugging guides. Additionally, WinUI-specific debugging (XAML rendering issues, dependency graph problems) could be better documented.

• [ ] Add 'Debugging' section to CONTRIBUTING.md with links to docs/debugging_buildfailures.md and docs/debugging_crashes.md
• [ ] Add WinUI-specific debugging scenarios (e.g., XAML binding failures, theme resource resolution) to docs/debugging_crashes.md
• [ ] Include steps for using binlog analysis (referenced in docs/images/binlog-images/) directly in debugging guide with screenshots
• [ ] Add troubleshooting section for common build failures specific to Windows/C++ XAML compilation

Create automated issue triage workflow GitHub Action based on triage.md guidelines

docs/triage.md exists documenting triage procedures, but there's no corresponding GitHub Action in .github/workflows/ to automate initial triage steps (label assignment, severity assessment). This would reduce manual work and ensure consistent issue classification.

• [ ] Create .github/workflows/auto-triage.yml that runs on new issues using similar-issues-bot.yml as a template reference
• [ ] Implement logic to add 'needs-triage' label automatically to new issues based on docs/triage.md criteria
• [ ] Add conditional labeling for common issue types (bug vs feature-proposal) by detecting ISSUE_TEMPLATE usage
• [ ] Document the workflow in docs/triage.md and CONTRIBUTING.md for contributor visibility

• Add comprehensive unit test coverage for CalendarView control's corner radius customization (specs/CalendarView/ shows feature is implemented but tests may be incomplete); review existing tests, write parametrized tests covering BlackoutStrikethroughBrush, today background, and custom radius values
• Expand Fluent Design documentation for developers migrating from UWP to Windows App SDK — docs/CONTRIBUTING_feedback_and_requests.md and README show gaps in visual design guidance; create reference document mapping UWP Fluent theme system to WinUI 3 equivalents
• Implement missing accessibility (a11y) specs for new controls — review specs/ folder for controls without corresponding accessibility testing requirements, write spec amendments following contribution_handling.md process

The WinUI repository demonstrates a generally secure baseline with proper disclosure channels (SECURITY.md), organized structure, and GitHub security features. However, there are opportunities for improvement: the SECURITY.md file is incomplete, security-specific contribution guidelines are missing, automated dependency vulnerability scanning is not evidenced, and lock files for reproducible builds are not visible in the provided structure. The codebase appears to be a well-maintained open-source UI framework with appropriate governance structures, but security documentation and automated scanning capabilities should be enhanced. No critical vulnerabilities were identified based on the available file structure analysis.

• Medium · Incomplete Security Reporting Documentation — SECURITY.md. The SECURITY.md file appears to be truncated at the Microsoft Security Response Center (MSRC) reporting URL. The complete security vulnerability reporting process is not fully documented, which could confuse contributors about proper vulnerability disclosure procedures. Fix: Complete the SECURITY.md file with the full MSRC reporting URL (https://msrc.microsoft.com/create-report) and comprehensive vulnerability disclosure guidelines. Ensure all security contact information and response procedures are clearly documented.
• Low · Missing CODEOWNERS Security Review Coverage — .github/CODEOWNERS. While a CODEOWNERS file exists in the .github directory, the analysis cannot verify if critical security-related components (dependency management, build pipelines, authentication/authorization code) have designated owners for security reviews. Fix: Ensure that CODEOWNERS file includes explicit security-focused code owners for sensitive areas such as: authentication mechanisms, cryptographic operations, dependency management files, and CI/CD pipeline configurations.
• Low · No Visible Dependency Lock Files — Repository root / package dependency management. The file structure shows no visible lock files (package-lock.json, yarn.lock, nuget.lock, etc.) which are important for reproducible builds and supply chain security. Fix: Implement and commit lock files for all package managers used in the project (NuGet, npm, yarn, etc.). This ensures reproducible builds and helps detect unauthorized dependency modifications.
• Low · Insufficient Security Policy Documentation — Repository documentation root. While a CONTRIBUTING.md exists, there is no visible CONTRIBUTING_SECURITY.md or dedicated security contribution guidelines for reporting vulnerabilities or contributing security fixes. Fix: Create a CONTRIBUTING_SECURITY.md file that includes: vulnerability reporting process, responsible disclosure timeline, security patch procedures, and how to contribute security-related improvements securely.
• Low · Missing Dependency Vulnerability Scanning Configuration — .github/workflows/. No visible configuration for automated dependency vulnerability scanning tools (Dependabot, WhiteSource, Snyk, or similar) in the GitHub workflows or configuration files. Fix: Implement automated dependency vulnerability scanning using GitHub Dependabot or similar tools. Configure automatic alerts for vulnerable dependencies and ensure regular updates are applied or alternatives are evaluated.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.