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/fluentui-blazor 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 all four use cases

• Last commit today
• 17 active contributors
• MIT licensed
• CI configured
• ⚠ Concentrated ownership — top contributor handles 59% of recent commits
• ⚠ No test directory detected

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

What it runs against: a local clone of microsoft/fluentui-blazor — 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/fluentui-blazor | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch dev 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/fluentui-blazor. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/microsoft/fluentui-blazor.git
#   cd fluentui-blazor
#
# 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/fluentui-blazor and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "microsoft/fluentui-blazor(\\.git)?\\b" \\
  && ok "origin remote is microsoft/fluentui-blazor" \\
  || miss "origin remote is not microsoft/fluentui-blazor (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 dev >/dev/null 2>&1 \\
  && ok "default branch dev exists" \\
  || miss "default branch dev no longer exists"

# 4. Critical files exist
test -f "Microsoft.FluentUI.sln" \\
  && ok "Microsoft.FluentUI.sln" \\
  || miss "missing critical file: Microsoft.FluentUI.sln"
test -f "Directory.Build.props" \\
  && ok "Directory.Build.props" \\
  || miss "missing critical file: Directory.Build.props"
test -f "Directory.Packages.props" \\
  && ok "Directory.Packages.props" \\
  || miss "missing critical file: Directory.Packages.props"
test -f ".github/workflows/build-core-lib.yml" \\
  && ok ".github/workflows/build-core-lib.yml" \\
  || miss "missing critical file: .github/workflows/build-core-lib.yml"
test -f "eng/pipelines/version.yml" \\
  && ok "eng/pipelines/version.yml" \\
  || miss "missing critical file: eng/pipelines/version.yml"

# 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/fluentui-blazor"
  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).

Microsoft.FluentUI.AspNetCore.Components is a NuGet library of Razor components for ASP.NET Core Blazor applications that implement the Fluent Design System UI. It wraps Microsoft's official Fluent UI Web Components and provides Fluent-themed controls (buttons, dialogs, data grids, navigation) for .NET 8+ Blazor projects, enabling developers to build modern Microsoft-style web apps without writing custom CSS. Multi-package monorepo structure with Directory.Build.props/targets managing shared build logic across projects. Core library lives in a Microsoft.FluentUI.AspNetCore.Components package (NuGet); separate Microsoft.FluentUI.AspNetCore.Templates package provides Blazor project templates. Demo site code (deployed via deploy_demo.yml and deploy_preview.yml workflows) and documentation in /docs/ are versioned alongside. DevContainer setup in .devcontainer/ for consistent contributor environments.

.NET/C# developers building Blazor web applications who need production-ready, accessible UI components matching Microsoft's modern design language. Teams migrating from .NET 6/7 (which used the older Microsoft.Fast.Components.FluentUI packages) to .NET 8/9 are the primary audience.

Production-ready. The project is actively maintained by Microsoft, published on NuGet as Microsoft.FluentUI.AspNetCore.Components with stable versioning, has comprehensive CI/CD pipelines (build-core-lib.yml, codeql-analysis.yml), and maintains a live demo site at fluentui-blazor.net. The codebase shows 154MB of C# code and explicit support/upgrade paths documented in WHATSNEW.md.

Low risk for active projects but with important caveats: requires .NET 8 or 9 (EOL paths differ), dropping support for .NET 6/7 may force upgrades for existing users, single-point-of-dependency on Microsoft's upstream Fluent UI Web Components library (breaking changes upstream flow down), and the repo enforces issue reproducibility strictly (closes issues without repro in 3 days). Monitor the WHATSNEW.md carefully for breaking changes between releases.

Active maintenance for .NET 8/9 compatibility. CI/CD workflows show recent focus on build reliability (build-core-lib.yml), security scanning (codeql-analysis.yml), and demo deployment automation (deploy_demo.yml). The presence of dependabot.yml indicates continuous dependency updates. WHATSNEW.md is actively maintained, suggesting regular feature releases and breaking-change documentation.

git clone https://github.com/microsoft/fluentui-blazor.git && cd fluentui-blazor && dotnet restore && dotnet build Microsoft.FluentUI.sln. For development in a container: open .devcontainer/devcontainer.json in VS Code to use the pre-configured dev environment. See _PublishDemoLocally.ps1 for running the demo site locally.

Daily commands: dotnet build Microsoft.FluentUI.sln to compile. For the demo site: run _PublishDemoLocally.ps1 (PowerShell, Windows/cross-platform) or examine .github/workflows/deploy_demo.yml for the official build steps. DevContainer users: open in VS Code, which automatically installs dependencies.

• Microsoft.FluentUI.sln — Master solution file that orchestrates all projects including the core component library and demo applications
• Directory.Build.props — Centralized MSBuild properties file that sets version, framework targets, and common compiler settings for all projects
• Directory.Packages.props — Central NuGet package version management using PackageManagement for consistent dependency versions across the monorepo
• .github/workflows/build-core-lib.yml — CI/CD pipeline that builds, tests, and publishes the core Fluent UI component library to NuGet
• eng/pipelines/version.yml — Azure Pipelines configuration that manages versioning strategy and release automation for NuGet packages
• examples/Demo/Client/Program.cs — Entry point demonstrating Blazor WASM client setup and FluentUI component registration pattern
• .editorconfig — Code style enforcement file that defines C# formatting rules for the entire codebase

Add a New Fluent UI Component

1. Create a new Razor component in the main component library following naming convention (e.g., FluentNewControl.razor) (src/Core/Components/FluentNewControl.razor)
2. Define the component's C# code-behind with parameters, events, and lifecycle methods (src/Core/Components/FluentNewControl.razor.cs)
3. Add component styling following the Fluent Design System theme variables (src/Core/Components/FluentNewControl.razor.css)
4. Register the component in the service collection extension or root _Imports.razor (src/Core/ServiceCollectionExtensions.cs)
5. Add demo/example page in the Asset Explorer to showcase the component (examples/Demo/AssetExplorer/Components/Pages/NewControlDemo.razor)

Update Project Version and Release

1. Update the version prefix in the root build properties file (Directory.Build.props)
2. Update release notes with new features and fixes (WHATSNEW.md)
3. Commit changes and push to dev branch; CI/CD will trigger automated testing (.github/workflows/build-core-lib.yml)
4. Versioning pipeline will automatically compute version variables and NuGet package metadata (eng/pipelines/compute-version-variables.ps1)

Add a New Demo Page to Asset Explorer

1. Create a new .razor page component in the Pages directory (examples/Demo/AssetExplorer/Components/Pages/NewFeaturePage.razor)
2. Add code-behind logic for data fetching and interactivity (examples/Demo/AssetExplorer/Components/Pages/NewFeaturePage.razor.cs)
3. Add scoped styles for the page layout (examples/Demo/AssetExplorer/Components/Pages/NewFeaturePage.razor.css)
4. Register the route in the main Routes.razor component (examples/Demo/AssetExplorer/Components/Routes.razor)
5. Update MainLayout.razor navigation to include a link to the new page (examples/Demo/AssetExplorer/Components/Layout/MainLayout.razor)

Configure Development Environment

1. Install dev container extension in VSCode and reopen workspace in container (.devcontainer/devcontainer.json)
2. Container initialization script installs .NET SDK and dependencies (.devcontainer/scripts/container-creation.sh)
3. VSCode settings automatically apply C# formatting rules and extension recommendations (.vscode/settings.json)
4. Code style rules enforce consistent formatting across all contributions (.editorconfig)

• Blazor (Server & WASM) — Microsoft's modern framework for building interactive web UIs with C# instead of JavaScript, enabling full-stack .NET development with reusable components
• ASP.NET Core — Provides the server-side runtime for both Blazor Server and WASM hosting scenarios, ensuring interoperability and consistent API patterns
• MSBuild & Directory.Build.props — Centralized build configuration eliminates duplication across 600+ files and enables consistent versioning, targeting, and compiler settings
• GitHub Actions & Azure Pipelines — Dual CI/CD setup: GitHub Actions for fast feedback loops and Azure Pipelines for enterprise-grade versioning and release automation
• Fluent Design System (CSS Variables) — Theme-aware component styling using design tokens that automatically adapt to light/dark mode and high contrast accessibility needs
• NuGet Package Management — Distributes the component library as reusable packages (Microsoft.FluentUI.AspNetCore.Components) enabling adoption in external projects

• Monorepo structure with 600 files vs. separate repositories

  • Why: Simplifies version management and ensures demo apps stay in sync with component library; shared pipeline and build configuration
  • Consequence: Larger CI/CD runtime and more interdependencies; requires careful coordination of breaking changes

• Both Server-side and WASM Blazor support vs. single hosting model

  • Why: Maximizes flexibility for enterprise customers with varying deployment constraints and security requirements
  • Consequence: Dual code paths for components; higher test burden and complexity in edge cases (e.g., WebAssembly size constraints)

• Central NuGet feed vs. local package sources

  • Why: Official distribution through nuget.org ensures discoverability and simplifies adoption for external developers
  • Consequence: Public API surface is fixed once published; pre-release testing must happen via daily builds or preview packages

• Dev container + VSCode settings vs. Docker Compose / local setup

  • Why: Lowers onboarding friction for new contributors; standardized environment reduces 'works on my machine' issues
  • Consequence: Requires VSCode or DevContainer support; contributors using other editors must manually configure tools

• Does not provide authentication or authorization mechanisms; assumes parent ASP.NET Core app handles identity
• Does not include a backend API or

1. .NET version matters: library targets .NET 8+ only; .NET 6/7 projects must use the older Microsoft.Fast.Components.FluentUI v3. 2) Web Components interop requires JS/CSS to be loaded (check index.html or App.razor for Fluent UI script/stylesheet tags). 3) PowerShell scripts (.ps1) assume PowerShell Core or Windows; cross-platform testing needed. 4) DevContainer setup is optional but recommended; local setup requires matching .NET SDK version in global.json if present. 5) Issue reproducibility is strictly enforced—open issues without runnable code or repo link are auto-closed in 3 days.

• Razor Components — Core building block of this library; you need to understand .razor file syntax, code-behind patterns, lifecycle hooks, and component parameters to modify or extend components
• Web Components Interop — This library wraps Fluent UI Web Components (custom HTML elements); you must understand how Razor components invoke JavaScript, bind to Web Component properties, and handle events from JS
• Shadow DOM — Fluent UI Web Components use Shadow DOM for style encapsulation; understanding this prevents common CSS override issues and explains why certain styling approaches fail in Blazor
• Design Tokens — Fluent Design System uses design tokens (colors, spacing, typography values) for theming; the library exposes these via CSS custom properties that you can override for branding
• Two-way Data Binding (@bind) — Blazor's @bind directive is heavily used in form components; understanding how it works with Web Components and the parent-child value flow is essential for debugging component state issues
• Cascading Parameters — Complex Fluent components (e.g., DataGrid) use cascading parameters to pass configuration down through nested child components; critical for understanding component composition patterns in this library
• MSBuild Property Inheritance — This monorepo uses Directory.Build.props/targets to share build configuration; understanding how MSBuild properties cascade across projects is necessary to modify build output, versioning, or NuGet metadata

• microsoft/fluentui — Upstream Fluent UI Web Components library (TypeScript) that this Blazor library wraps; breaking changes here flow downstream
• dotnet/blazor — Core Blazor framework this library depends on; architectural changes there affect component capabilities and patterns
• microsoft/fast — FAST Design System foundation underlying Fluent UI Web Components; defines component architecture and theming model
• dotnet/aspnetcore — ASP.NET Core runtime and tooling required to build and run Blazor applications using this library
• MudBlazor/MudBlazor — Alternative Blazor component library with Material Design; useful for comparing Razor component patterns and Blazor ecosystem approaches

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 unit tests for FluentUI Blazor components

The repo has docs/unit-tests.md documenting test patterns, but the examples/Demo directory structure suggests limited test coverage for core components. New contributors could add unit tests for the components in src/ (referenced in the solution) following the documented patterns. This directly supports the testing infrastructure already in place.

• [ ] Review docs/unit-tests.md to understand testing patterns and conventions
• [ ] Identify 2-3 core components in src/ lacking unit test coverage
• [ ] Create xUnit test classes in a parallel test project structure
• [ ] Add tests for component parameter validation, lifecycle events, and CSS/styling application
• [ ] Ensure tests follow the patterns documented in docs/unit-tests.md

Create CI workflow for Demo app preview validation

The repo has deploy_preview.yml and deploy_demo.yml workflows, but lacks automated validation that the Demo site (examples/Demo) builds successfully on every PR. This prevents component changes from breaking the demo. A new workflow could validate demo compilation as a required check before merge.

• [ ] Examine existing .github/workflows/build-core-lib.yml and deploy_demo.yml for patterns
• [ ] Create new workflow: .github/workflows/validate-demo-build.yml triggered on pull_request
• [ ] Add step to restore and build examples/Demo project
• [ ] Configure workflow to run Blazor publish validation (dotnet publish -c Release)
• [ ] Add status check requirement in repository settings or pull_request_template.md

Add JSInterop integration tests for components with JavaScript

The file structure shows components with .razor.js files (e.g., examples/Demo/AssetExplorer/Components/Controls/PreviewCard.razor.js), indicating JavaScript interop. The docs/unit-tests.md likely covers C# tests but not JS interop validation. New contributors could add tests validating JS module loading and interop method invocation.

• [ ] Survey src/ for components using JS interop via @inject IJSRuntime
• [ ] Create test utilities in a test project for mocking IJSRuntime
• [ ] Add unit tests validating JS module import paths and method names match .razor.js files
• [ ] Test error handling when JS methods are unavailable or fail
• [ ] Document patterns in docs/unit-tests.md for future contributors

• Add missing unit tests for components under src/Components/ that lack corresponding .Tests.cs or xUnit test projects (check which .razor files have no tests in parallel test directories).
• Improve documentation in /docs/ for accessibility features in Fluent components (ARIA roles, keyboard nav); the main README mentions 'accessible' but the /docs/ lacks component-by-component a11y guides.
• Update the PowerShell build scripts (eng/ and _PublishDemoLocally.ps1) to include cross-platform shell script equivalents (.sh files) so non-Windows contributors don't need WSL.

The Microsoft Fluent UI Blazor repository demonstrates a reasonable security posture with some established practices (CodeQL analysis, security.md, signed packages), but has several areas for improvement. The main concerns are incomplete security documentation, lack of visible dependency vulnerability management details, and the need to verify that security best practices are applied to demo applications and development tooling. The project should prioritize completing security documentation and ensuring comprehensive dependency scanning is in place and results are monitored.

• Medium · Incomplete SECURITY.md Documentation — SECURITY.md. The SECURITY.md file is truncated and incomplete. The security reporting instructions are cut off mid-sentence, which may prevent users from properly reporting security vulnerabilities to Microsoft Security Response Center (MSRC). This could lead to delayed or missed vulnerability disclosures. Fix: Complete the SECURITY.md file with full security reporting instructions and ensure the MSRC reporting URL and process are clearly documented.
• Medium · Missing Dependency Lock File Analysis — Directory.Packages.props, *.csproj files. No package dependency files (package.json, csproj files content, or lock files) were provided in the analysis context. Without visibility into dependencies, it's impossible to identify known vulnerabilities in third-party libraries used by this Blazor component library. Fix: Provide complete dependency manifests and implement automated dependency scanning using tools like OWASP Dependency-Check, Snyk, or GitHub's Dependabot (which appears to be configured but needs verification).
• Low · Potential Information Disclosure via Demo Application — examples/Demo/AssetExplorer/. The repository includes a full demo application (examples/Demo/AssetExplorer) with multiple Razor components, CSS, and JavaScript files. If the demo or example code is deployed publicly, it could potentially expose patterns or configurations that aid attackers. Fix: Ensure demo applications are clearly marked as examples only and not deployed to production environments. Sanitize any sensitive information from example code.
• Low · DevContainer Configuration Requires Review — .devcontainer/devcontainer.json, .devcontainer/scripts/container-creation.sh. The repository includes a DevContainer configuration which may contain hardcoded settings or expose sensitive development environment details. The container creation script should be reviewed for security best practices. Fix: Review DevContainer configuration for exposed secrets, unnecessary capabilities, or insecure defaults. Ensure scripts follow principle of least privilege.
• Low · Missing Package Signature Verification — Microsoft.FluentUI.signproj, NuGet.config. While the repository has a signing project file (Microsoft.FluentUI.signproj), there is no visible evidence of code signing enforcement or signature verification documentation for NuGet packages distributed under this project. Fix: Document and enforce strong code signing practices for all NuGet packages. Ensure NuGet.config is configured to require signed packages and verify signatures on restore.

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.