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/react-native-windows 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 today
• 12 active contributors
• Distributed ownership (top contributor 23% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

_{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/react-native-windows repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/microsoft/react-native-windows.

What it runs against: a local clone of microsoft/react-native-windows — 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/react-native-windows | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of microsoft/react-native-windows. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/microsoft/react-native-windows.git
#   cd react-native-windows
#
# 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/react-native-windows and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other 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"

# 4. Critical files exist
test -f ".ado/ci-pipeline.yml" \\
  && ok ".ado/ci-pipeline.yml" \\
  || miss "missing critical file: .ado/ci-pipeline.yml"
test -f ".ado/release-pipeline.yml" \\
  && ok ".ado/release-pipeline.yml" \\
  || miss "missing critical file: .ado/release-pipeline.yml"
test -f "package.json" \\
  && ok "package.json" \\
  || miss "missing critical file: package.json"
test -f ".ado/templates/prepare-build-env.yml" \\
  && ok ".ado/templates/prepare-build-env.yml" \\
  || miss "missing critical file: .ado/templates/prepare-build-env.yml"
test -f ".github/CODEOWNERS" \\
  && ok ".github/CODEOWNERS" \\
  || miss "missing critical file: .github/CODEOWNERS"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
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/react-native-windows"
  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).

React Native for Windows (RNW) is a framework that enables developers to build native Windows applications using React and JavaScript, extending Meta's React Native to support Windows 10/11 devices including PCs, tablets, Xbox, and Mixed Reality devices. It bridges JavaScript/React code with native Windows APIs through C++ interop, allowing developers to write once and deploy to multiple Windows platforms. The project is transitioning from the Paper renderer (built on UWP XAML) to Fabric (targeting Windows Composition and WinAppSDK Win32 by default). Monorepo with yarn workspaces spanning packages/{@react-native-windows,@react-native,@office-iss,@rnw-scripts}/ for modular packages, vnext/ for next-gen Fabric implementation, and .ado/ for Azure Pipelines CI/CD. Core C++ native modules separate from TypeScript/JavaScript bindings. Build orchestrated through lage task runner with beachball for versioning. Test infrastructure split across desktop-single.yml, universal-single.yml, e2e-test.yml, and node-tests.yml jobs.

React developers who want to build cross-platform applications targeting Windows devices without learning C++ or XAML, and Microsoft teams maintaining the official React Native Windows implementation. Contributors typically include full-stack JavaScript engineers, C++ systems engineers, and Windows app developers familiar with XAML/WinUI.

Production-ready for Paper architecture; actively developed with heavy CI/CD infrastructure (.ado/ pipelines, multiple test jobs, e2e testing, security scanning). The codebase is substantial (5.7M lines C++, 3.2M JavaScript, 1.5M TypeScript) suggesting maturity, but the ongoing migration to Fabric indicates significant architectural changes still in progress. Regular releases evident from release-pipeline.yml and beachball versioning setup.

Complex C++/JavaScript interop surface with native Windows API bindings introduces compatibility risks across Windows SDK versions. The Fabric migration represents a major breaking change in rendering architecture still being implemented (pinned issue #12042). Dependency on Visual Studio toolchain, Windows SDK, and WinAppSDK versions creates environmental brittleness. Large monorepo with 60+ top-level .ado files suggests build complexity and potential CI fragility.

Active migration to Fabric renderer (tracked in pinned issue #12042) targeting Composition and WinAppSDK Win32. Multiple Azure Pipeline jobs running lint, node tests, e2e tests, playground builds, and WACK validation. Integration with nightly React Native builds (version 0.85.0-nightly-20260114) and synchronization with upstream via fork-sync scripts. Experimental WinUI3 and Fabric features being controlled via .ado/templates/enable-experimental-* files.

git clone git@github.com:microsoft/react-native-windows.git && cd react-native-windows && yarn install && yarn build (uses lage build orchestrator). Requires Node 18+ (per rnw-img-vs2022-node18.json) and Visual Studio 2022 with Windows SDK.

Daily commands: yarn build (rebuilds entire monorepo via lage), yarn lint (eslint + TypeScript checks), yarn test (runs lage test with passWithNoTests flag). Playground template available via .ado/jobs/playground.yml for testing RNW apps. Desktop and Universal app variants built separately (desktop-single.yml, universal-single.yml jobs).

• .ado/ci-pipeline.yml — Main CI/CD pipeline configuration that orchestrates all builds, tests, and packaging across Windows platforms—every contributor must understand the build flow.
• .ado/release-pipeline.yml — Release automation pipeline defining versioning, signing, and publishing to NuGet and npm—essential for understanding the release process.
• package.json — Root workspace configuration defining all npm scripts (build, lint, test) and the monorepo setup using lage—entry point for local development.
• .ado/templates/prepare-build-env.yml — Reusable template that sets up the build environment (SDKs, dependencies, paths)—used by most jobs and critical for reproducible builds.
• .github/CODEOWNERS — Defines code ownership and review requirements across the repository—guides PR review routing and responsibility assignments.
• .ado/variables/shared.yml — Shared variables (versions, paths, configurations) used across all ADO pipelines—single source of truth for build configuration.
• .cspell.json — Spell-check configuration enforced in CI—documents acceptable terminology and naming conventions used throughout the codebase.

Add a New Build Job for a Platform Variant

1. Create a new job YAML file in .ado/jobs/ following the naming pattern (e.g., mynew-platform-single.yml) with MSBuild, test, and artifact steps (.ado/jobs/desktop-single.yml)
2. Reference the new job in the appropriate pipeline (.ado/ci-pipeline.yml or .ado/pr-pipeline.yml) under the jobs section (.ado/ci-pipeline.yml)
3. Define platform-specific variables in .ado/variables/windows.yml if needed (e.g., platform names, SDK versions) (.ado/variables/windows.yml)
4. Add a VM image specification in .ado/image/ if the platform requires a unique agent image (.ado/image/rnw-img-vs2022.json)
5. Update .github/CODEOWNERS to assign review responsibility to the team owning the new platform (.github/CODEOWNERS)

Add a New Reusable Build Template Step

1. Create a new template YAML file in .ado/templates/ (e.g., mytask-step.yml) with parameters and script steps (.ado/templates/msbuild-sln.yml)
2. Reference shared variables from .ado/variables/shared.yml using ${{ variables.varName }} syntax (.ado/variables/shared.yml)
3. Use the new template in job YAML files by adding a steps: - template: .ado/templates/mytask-step.yml@self (.ado/jobs/desktop-single.yml)
4. Update the build-template.yml if this is a core step that should be part of all builds (.ado/build-template.yml)

Integrate a New Release Step or Signing Process

1. Define the new release step in .ado/release.yml or create a new template in .ado/templates/ (e.g., esrp-codesign-*.yml for signing) (.ado/release-pipeline.yml)
2. Add any new environment variables or secrets to .ado/variables/shared.yml and document them (.ado/variables/shared.yml)
3. Update .ado/publish.yml if the step affects package publishing to NuGet or npm (.ado/publish.yml)
4. Add exemptions or suppressions in .ado/config/ if security scanning needs to be bypassed (e.g., CredScanSuppressions.json) (.ado/config/CredScanSuppressions.json)

Update Development Scripts and Monorepo Configuration

1. Add new npm script commands or modify existing ones in the root package.json using lage for task orchestration (package.json)
2. Create or update JavaScript helper scripts in .ado/scripts/ if custom build logic is needed beyond standard lage tasks (.ado/scripts/build.js)
3. Update .cspell.json if new terminology or branded terms must be added to the spell-check dictionary (.cspell.json)
4. Ensure code formatting rules in .clang-format and .editorconfig are respected by new build tools (.clang-format)

• undefined — undefined

Windows SDK version pinning: .ado/image/ defines specific VS2022 + SDK combinations per build agent (breaking changes between SDK versions). Node version matters: separate images for node16, node18, node22 in .ado/image/. Nightly React Native dependencies (0.85.0-nightly-*) mean builds can break on RN upstream changes. Code signing via ESRP templates requires Azure credentials and specific certificate setup (.ado/templates/cleanup-certificate.yml). Fabric feature is behind experimental flags—Paper is still the default, enabling wrong flags breaks builds. WACK validation (TestWACK.ps1) only runs on Windows agents with specific tool setup.

• Paper Renderer (RNW) — Current default renderer in RNW built on UWP XAML; understanding its architecture is essential for contributing to existing Windows apps and deprecation migration
• Fabric Renderer — Next-generation RNW renderer targeting Windows Composition and WinAppSDK; the active migration path you'll encounter in open issues and code comments
• XAML Islands — Mechanism for hosting native XAML controls within Composition-based Fabric apps; enables interop between JavaScript and advanced Windows UI controls
• Windows Composition API — Low-level rendering API that Fabric uses instead of XAML; provides direct GPU-accelerated rendering and animation primitives for performance
• Monorepo with Lage Task Orchestration — RNW uses lage for parallel task execution across 60+ packages; understanding task graphs and dependency resolution is critical for debugging build failures
• Beachball Semantic Versioning — RNW uses beachball for automated versioning and changelog generation; contributors must understand change types (major/minor/patch) for proper release management
• Platform Override Pattern — RNW synchronizes with upstream React Native via fork-sync and react-native-platform-override; this pattern enables Windows-specific module implementations while staying synced

• facebook/react-native — Upstream React Native core; RNW implements the Paper and Fabric renderers for Windows, synchronized via fork-sync pattern
• microsoft/react-native-macos — Sibling project supporting macOS using same Paper architecture and Fabric migration roadmap as RNW
• microsoft/react-native-gallery — Official sample app showcasing RNW capabilities across Paper and Fabric renderers (used for demos and testing)
• microsoft/winui-3-controls — WinUI 3 component library that RNW can host via XAML islands for advanced native control integration
• microsoft/WindowsAppSDK — Target deployment SDK for Fabric renderer (Win32 + WinAppSDK); defines the native platform layer RNW compiles against

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 CI/CD documentation for .ado pipeline templates

The repo has an extensive Azure DevOps pipeline infrastructure (.ado/templates with 30+ YAML templates) but no documented guide explaining how to extend or debug these pipelines. New contributors struggle to understand the flow of templates like verdaccio-start.yml, esrp-codesign-binaries.yml, and msbuild-sln.yml. A contributor could create a .ado/PIPELINE_GUIDE.md documenting template dependencies, variable flows, and common extension patterns.

• [ ] Analyze .ado/templates/ to map template dependencies and data flows
• [ ] Document the shared variables from .ado/variables/shared.yml and windows.yml
• [ ] Create .ado/PIPELINE_GUIDE.md with sections: 'Template Architecture', 'Adding New Build Steps', 'Debugging Pipeline Failures', 'Template Dependencies Graph'
• [ ] Add examples showing how to extend msbuild-sln.yml or verdaccio workflows
• [ ] Link guide from main README or CONTRIBUTING.md

Create test coverage for .ado/scripts build utilities

The .ado/scripts/ directory contains critical build automation (build.js, npmAddUser.js, npmPack.js, setVersionEnvVars.js, waitForVerdaccio.js) but these appear to lack unit tests. These scripts directly impact release pipelines and version management. Adding Jest tests for these scripts would prevent regressions and make contributions safer.

• [ ] Analyze each script in .ado/scripts/ to understand inputs, outputs, and side effects
• [ ] Create .ado/scripts/tests/ directory
• [ ] Write Jest test suites for: setVersionEnvVars.js (env variable parsing), npmAddUser.js (authentication logic), npmPack.js (artifact packing), waitForVerdaccio.js (retry logic)
• [ ] Add mocking for file system operations and external commands
• [ ] Update .ado/scripts/package.json or root package.json to include test script for these utilities
• [ ] Document test execution in CONTRIBUTING.md

Add schema validation for .ado image JSON configuration files

The .ado/image/ directory contains 4 JSON files (rnw-img-*.json) that define build agent image configurations, but there's no validation that these configs are valid or complete. A contributor could create a JSON schema and validation script to ensure new image configs are correct before they cause build failures in CI/CD.

• [ ] Examine all .ado/image/*.json files to determine required fields and structure
• [ ] Create .ado/image/schema.json using JSON Schema standard
• [ ] Create .ado/scripts/validate-image-config.js that validates all .ado/image/*.json against the schema
• [ ] Add pre-commit hook (via husky) or lint task to validate image configs
• [ ] Update linting documentation to mention image config validation
• [ ] Add this validation to .ado/jobs/linting.yml if not already present

• Add missing unit tests for TypeScript modules in packages/@react-native-windows/ currently lacking test coverage (scan for .test.ts files missing alongside .ts implementations)
• Document the Fabric-to-Paper migration checklist in the repo README with links to .ado/templates/enable-fabric-experimental-feature.yml and pinned issue #12042 for new contributors confused by dual architecture
• Extract and publish separate E2E test documentation for the e2e-test.yml job setup—currently test infrastructure is scattered across .ado/jobs/ with no single source of truth for running E2E tests locally

• High · Outdated React Native Version — package.json - devDependencies.react-native. The repository uses react-native 0.85.0-nightly-20260114-f15985f4f, which is a nightly/pre-release version. Nightly builds may contain unpatched security vulnerabilities and are not recommended for production use. Production dependencies should use stable, vetted releases. Fix: Update to the latest stable release of react-native. Use semantic versioning (e.g., ^0.84.0) to ensure security patches are automatically included.
• High · Vulnerable Lodash Version — package.json - devDependencies.lodash. lodash version 4.17.15 contains multiple known security vulnerabilities including prototype pollution issues (CVE-2021-23337, CVE-2018-16487). This version is significantly outdated. Fix: Upgrade lodash to version ^4.17.21 or later to patch known prototype pollution vulnerabilities.
• Medium · Outdated TypeScript Version — package.json - devDependencies.typescript. typescript 5.0.4 is outdated. Current versions (5.3+) include important security fixes and improvements. Older versions may have known vulnerabilities in the compilation pipeline. Fix: Update typescript to the latest stable version (5.7+) to ensure security patches and type safety improvements are current.
• Medium · Outdated ESLint Version — package.json - devDependencies.eslint. eslint 8.19.0 is outdated (released June 2022). Current versions include security fixes and rule improvements. Outdated linting tools may miss security issues in code. Fix: Update eslint to version ^8.50.0 or later to benefit from recent security patches and enhanced rule detection.
• Medium · Fast-glob Version Not Pinned to Latest — package.json - devDependencies.fast-glob. fast-glob ^3.2.11 uses a caret range. While this allows patch updates, the version is from 2022. Ensure automatic updates are working correctly and no known vulnerabilities exist in the 3.2.x branch. Fix: Verify no CVEs exist for fast-glob 3.2.x. Consider updating to ^3.3.x or later. Run 'npm audit' to check current status.
• Medium · Unclear Verdaccio Configuration Security — .ado/verdaccio/config.yaml, .ado/templates/verdaccio-start.yml, .ado/templates/verdaccio-stop.yml. The build pipeline includes a local npm registry (Verdaccio) at .ado/verdaccio/config.yaml. If misconfigured, this could expose internal packages or credentials. The configuration file should be reviewed for security settings. Fix: Review verdaccio configuration for: 1) Authentication requirements, 2) Package access controls, 3) Credential handling, 4) Network exposure. Ensure uplinks don't expose internal packages. Run security audit on verdaccio setup.
• Medium · Credentials Management in CI/CD Scripts — .ado/scripts/npmAddUser.js, .ado/scripts/npmPack.js. Multiple npm-related scripts exist (.ado/scripts/npmAddUser.js, .ado/scripts/npmPack.js) that may handle credentials. These scripts need careful review to ensure credentials aren't logged, cached insecurely, or exposed in build artifacts. Fix: Review these scripts to ensure: 1) Credentials are never logged, 2) Sensitive output is masked, 3) No hardcoded secrets, 4) Use of secure credential management (e.g., Azure Key Vault). Enable secret scanning in CI/CD.
• Low · Postinstall Script Security Risk — package.json - scripts.postinstall. The package.json includes 'postinstall': 'yarn build' which automatically runs on installation. While useful, this increases attack surface if dependencies are compromised, as the build script would automatically execute. Fix: Consider requiring explicit build commands instead of postinstall. If keeping it, implement strict dependency verification and code signing. Document this risk in security guidelines.

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.