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/radzenhq/radzen-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 2d ago
• 7 active contributors
• MIT licensed
• CI configured
• ⚠ Concentrated ownership — top contributor handles 78% 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 radzenhq/radzen-blazor repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/radzenhq/radzen-blazor.

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

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

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

# 4. Critical files exist
test -f "Radzen.Blazor/Radzen.Blazor.csproj" \\
  && ok "Radzen.Blazor/Radzen.Blazor.csproj" \\
  || miss "missing critical file: Radzen.Blazor/Radzen.Blazor.csproj"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"
test -f "Directory.Build.props" \\
  && ok "Directory.Build.props" \\
  || miss "missing critical file: Directory.Build.props"
test -f "Radzen.Blazor.Tests/Radzen.Blazor.Tests.csproj" \\
  && ok "Radzen.Blazor.Tests/Radzen.Blazor.Tests.csproj" \\
  || miss "missing critical file: Radzen.Blazor.Tests/Radzen.Blazor.Tests.csproj"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"

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

Radzen Blazor is a comprehensive UI component library for .NET Blazor (both Server and WebAssembly) containing 110+ native components including DataGrid, Scheduler, Charts, and advanced theming. It provides Material Design and Fluent UI support out-of-the-box, solving the problem of building enterprise-grade, themeable web applications without hand-rolling complex interactive components. Monorepo structure: core Radzen.Blazor (C# .razor components) provides all UI components, Radzen.Blazor.Tests/ contains 50+ test files for each component type, Radzen.Blazor.Api/ is the interactive documentation site, and Radzen.Blazor.Api.Generator/ auto-generates API docs. Styling uses SCSS (1M+ LOC) with JavaScript (140K LOC) for interactive behaviors.

.NET/C# developers building Blazor applications who need production-ready data visualization, form controls, and layout components without external JavaScript dependencies. Specifically targets teams at companies like Microsoft, NASA, Porsche, and DHL who require sophisticated UI without licensing costs.

Highly mature and production-ready: 5.5M+ lines of C#, active GitHub community, comprehensive test suite in Radzen.Blazor.Tests/, established CI/CD pipelines (ci.yml, deploy.yml, nuget.yml), and used at scale by major enterprises. The project maintains frequent releases and supports the latest .NET 10.

Low risk for standard usage: single maintainer (Radzen team) could be a concern for critical features, but the library is battle-tested across Fortune 500 companies. No major red flags visible in file structure, though customization needs may require deep component knowledge. Breaking changes are managed through semantic versioning on NuGet.

Active development with recent GitHub workflow configurations (ci.yml, deploy.yml, nuget.yml) and ongoing component testing. The test suite shows comprehensive coverage of DataGrid, Charts, Forms, and Dialog components. API documentation generation is automated, indicating continuous documentation updates.

Clone the repository: git clone https://github.com/radzenhq/radzen-blazor.git && cd radzen-blazor. Restore .NET packages: dotnet restore. The solution uses .NET 10+; check Directory.Build.props for target framework. No npm install needed; component library is pure C#.

Daily commands: Open Radzen.Blazor.sln in Visual Studio 2022 or run dotnet build. To run demo site: navigate to RadzenBlazorDemos project and dotnet run. Tests: dotnet test Radzen.Blazor.Tests/Radzen.Blazor.Tests.csproj. No npm/yarn scripts; all tooling is .NET-based.

• Radzen.Blazor/Radzen.Blazor.csproj — Root project file defining the entire component library's dependencies, versioning, and build configuration for 110+ Blazor components.
• .github/workflows/ci.yml — CI/CD pipeline orchestrating builds, tests, and deployments across all 600+ files; critical for understanding the build and release process.
• Directory.Build.props — Central MSBuild configuration shared across all projects, controlling compilation flags, versioning, and assembly metadata.
• Radzen.Blazor.Tests/Radzen.Blazor.Tests.csproj — Test suite project encompassing 100+ unit tests for components; essential for understanding testing patterns and component validation.
• README.md — Primary documentation and entry point describing the library's scope, features, supported platforms, and how developers should use it.
• Radzen.Blazor.Api/Radzen.Blazor.Api.csproj — API documentation and demo site project; shows how components are documented and exposed to end-users.

• DataGrid Component (Blazor, C#, HTML/CSS, JavaScript interop) — High-performance table rendering with sorting, filtering, paging, and column customization
  • Failure mode: Large datasets cause memory exhaustion; poor filter performance on 10k+ rows
• Scheduler Component (Blazor, C#, HTML/CSS, JavaScript interop for drag-drop) — Event scheduling and calendar rendering with drag-drop support
  • Failure mode: Timezone conversion errors; conflicts with browser DST handling
• Charts Component (Blazor, C#, JavaScript charting library (likely Plotly or Chart.js)) — Data visualization (bar, line, pie, etc.) with interactive legends and tooltips
  • Failure mode: Large datasets exceed canvas memory limits; performance degrades beyond 1k data points
• Dialog/Modal Service (Blazor Services, C#, HTML/CSS positioning) — Manages overlay modals and notifications; coordinates lifecycle and event flow
  • Failure mode: Multiple dialogs cause z-index conflicts; focus management issues on mobile

Add a New Blazor Component

1. Create component .razor file in Radzen.Blazor with standard Blazor syntax (parameters, event callbacks, lifecycle methods) (Radzen.Blazor/*.razor)
2. Create corresponding unit test file following naming convention in test suite (Radzen.Blazor.Tests/[ComponentName]Tests.cs)
3. Add component export to the main project's public API and Razor imports (Radzen.Blazor/_Imports.razor)
4. Create demo page in Radzen.Blazor.Api for documentation and examples (Radzen.Blazor.Api/[ComponentName].razor)
5. Update Directory.Build.props if new component requires special build metadata or versioning (Directory.Build.props)

Add Component Tests

1. Create test class inheriting from test base in Radzen.Blazor.Tests folder following naming convention (Radzen.Blazor.Tests/[ComponentName]Tests.cs)
2. Write unit tests covering parameter validation, rendering, event callbacks, and state changes (Radzen.Blazor.Tests/[ComponentName]Tests.cs)
3. Reference test in the Radzen.Blazor.Tests.csproj and run through CI pipeline (.github/workflows/ci.yml)

Publish Release to NuGet

1. Update version in Directory.Build.props shared MSBuild configuration (Directory.Build.props)
2. Ensure all tests pass by running CI workflow that builds and validates all components (.github/workflows/ci.yml)
3. Trigger NuGet publish workflow which packages library and uploads to NuGet.org (.github/workflows/nuget.yml)
4. Verify deployment and redeploy documentation site (.github/workflows/deploy.yml)

• Blazor (WebAssembly & Server) — Native C# UI framework enabling component reuse across .NET applications; supports both server and client rendering modes.
• .NET 10 / .NET MAUI Blazor — Enables cross-platform desktop/mobile Blazor apps; aligns with latest Microsoft platform targets.
• Material Design & Fluent UI Themes — Provides enterprise-grade design systems; reduces design effort for consumers.
• GitHub Actions CI/CD — Native GitHub integration for automated testing, building, and publishing to NuGet without external services.
• MSBuild & Directory.Build.props — Centralized build configuration for 600+ files; enables consistent versioning and metadata across all projects.

• 110+ components in single library vs. modular sub-packages

  • Why: Simplifies developer experience and version management; single NuGet package install.
  • Consequence: Larger overall package size; developers cannot opt-out of unused components.

• MIT licensed free tier vs. commercial enterprise features

  • Why: Maximizes adoption and community contributions; balances open-source accessibility.
  • Consequence: Revenue model must rely on commercial licensing or paid support; free tier may not support all enterprise needs.

• Comprehensive test suite (100+ test files) vs. faster development

  • Why: Ensures high reliability for widely-used library; reduces regression bugs.
  • Consequence: Longer CI pipeline execution time (~30+ seconds); requires discipline in test coverage.

• Single master branch with CI/CD automation vs. complex branching

  • Why: Simplifies release cadence; rapid iteration on features.
  • Consequence: Breaking changes may surface in release; requires semantic versioning discipline.

• Real-time collaboration features (not mentioned in features)
• Backend API/database persistence (client-side component library only)
• Server-side state management beyond Blazor lifecycle
• Native mobile apps (Blazor MAUI provides web-based mobile UI, not native APIs)
• Cross-browser compatibility beyond modern standards (assumes modern browser APIs)

Component interop: Some advanced features (drag-drop, date pickers, charts) use JavaScript interop via Radzen.Blazor.js; ensure script is registered in App.razor or components won't initialize. Services must be registered in Program.cs (AddRadzenComponents()) or services like DialogService won't be injectable. SCSS compilation happens at build time, not runtime; custom theme modifications require rebuilding. Blazor render modes (InteractiveServer vs InteractiveWebAssembly) affect component lifecycle; some features may behave differently depending on mode.

• Blazor Component Lifecycle — Understanding OnInitialized, OnParametersSet, and StateHasChanged is critical for debugging component rendering issues and parameter updates in Radzen components
• JavaScript Interop (JSInterop) — Radzen uses JS interop extensively for advanced features (date pickers, drag-drop, charts); understanding DotNetObjectReference and invokeMethodAsync is essential for extending components
• Cascading Parameters — Complex components like DataGrid, Form, and Dialog use cascading parameters for parent-child communication; critical for understanding how sub-components inherit configuration
• SCSS Variables and CSS Custom Properties (CSS Variables) — Theming system relies on SCSS compilation to CSS custom properties for Material Design and Fluent UI variants; necessary for customizing component appearance
• Blazor Render Modes (InteractiveServer vs InteractiveWebAssembly) — Radzen supports both server and client-side rendering; understanding per-component render modes affects performance, component initialization, and feature availability
• EventCallback Pattern — All Radzen components expose behavior via EventCallback<T> (OnClick, OnChange, etc.); understanding async event handling and parameter passing is fundamental to using components
• Template Rendering (@RenderFragment) — DataGrid, Dialog, Card, and other container components use RenderFragment for content slots; essential for composing complex layouts and custom templates

• telerik/blazor-ui — Direct competitor UI component library for Blazor with similar DataGrid, Charts, and Form controls but commercial licensing
• MudBlazor/MudBlazor — Open-source Material Design component library for Blazor; similar scope but lighter-weight and community-driven alternative
• radzenhq/radzen — Companion repo: Radzen Visual Studio Code extension and UI designer that generates Radzen Blazor component markup
• dotnet/aspnetcore — Core Blazor framework and rendering engine that this library depends on; necessary for understanding component lifecycle and interop
• dotnet/samples — Official .NET/Blazor samples and patterns; useful for reference architecture and best practices when extending Radzen components

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 Radzen.Blazor.Api.Generator

The Radzen.Blazor.Api.Generator project (Radzen.Blazor.Api.Generator/Program.cs) lacks corresponding test coverage. This generator is critical for maintaining API documentation consistency across 110+ components. Adding tests would ensure generated APIs remain valid when components are added/modified, preventing documentation drift.

• [ ] Create Radzen.Blazor.Tests/ApiGeneratorTests.cs to test Program.cs logic
• [ ] Add tests for API parsing and code generation output validation
• [ ] Test edge cases: components with no parameters, deprecated properties, generic components
• [ ] Verify generated output matches expected API structure before documentation builds

Expand DataGrid and Scheduler component test suites with integration tests

DataGridTests.cs and the absence of a SchedulerTests.cs indicate these flagship components (mentioned in repo description as most sophisticated) need deeper test coverage. DataGrid and Scheduler are complex components with many interactive features, data binding scenarios, and edge cases that could benefit from integration tests covering real-world usage patterns.

• [ ] Create Radzen.Blazor.Tests/SchedulerTests.cs with tests for recurring events, timezone handling, and drag-drop
• [ ] Expand DataGridTests.cs with tests for: sorting/filtering combinations, virtualization, grouping, inline editing
• [ ] Add tests for data-bound scenarios with IQueryable, dynamic columns, and custom templates
• [ ] Test accessibility features (keyboard navigation, ARIA attributes) for both components

Add validation tests for form components and DataAnnotationValidator integration

DataAnnotationValidatorTests.cs exists but is isolated. Form-heavy applications rely on seamless validation across FormField, DatePicker, DropDown, AutoComplete, and other input components. Adding integration tests would verify validator propagation, error message display, and cascading validation across complex forms.

• [ ] Create Radzen.Blazor.Tests/FormValidationIntegrationTests.cs
• [ ] Test DataAnnotationValidator with FormField wrappers around various input components
• [ ] Add tests for: custom validation messages, async validators, conditional validation, form submission with errors
• [ ] Test validation error display in DatePickerTests.cs, DropDownTests.cs, AutoCompleteTests.cs (currently missing validator scenarios)

• Add missing test coverage for lesser-used components: e.g., Radzen.Blazor.Tests/ lacks dedicated tests for Timeline, Gantt, and GaugeCharts visible in component list but no test files exist (TimelineTests.cs, GanttTests.cs, GaugeChartTests.cs).
• Enhance form validation documentation: FormFieldTests.cs and DataAnnotationValidatorTests.cs are minimal; add example pages showing validation error message handling and custom validator integration to Radzen.Blazor.Api/ documentation site.
• Improve accessibility attributes: Review all .razor component files for missing ARIA labels (role, aria-label, aria-describedby) on interactive elements like buttons, dropdowns, and form inputs; particularly needed in CardGroup, Carousel, and PickList components.

• Medium · Docker Build Stage Uses Latest .NET SDK Without Version Pinning — Dockerfile, line 3. The Dockerfile uses 'mcr.microsoft.com/dotnet/sdk:10.0' without a specific patch version. While a major version is specified, using floating versions can lead to unexpected updates with potential breaking changes or unvetted dependency updates during rebuilds. Fix: Pin to a specific patch version: 'mcr.microsoft.com/dotnet/sdk:10.0.x' where x is the latest stable patch version. Document the specific version used in production.
• Low · Missing HEALTHCHECK in Dockerfile — Dockerfile. The Dockerfile lacks a HEALTHCHECK instruction, which is important for container orchestration systems to determine container health status and take remedial actions. Fix: Add a HEALTHCHECK instruction to the final stage to enable health monitoring of the containerized application.
• Low · No Non-Root User Specified in Dockerfile — Dockerfile. The Dockerfile does not explicitly specify a non-root user for running the application. Applications running as root can pose a security risk if the container is compromised. Fix: Create and use a non-root user in the Dockerfile. Add 'RUN useradd -m -u 1000 appuser' and 'USER appuser' before the ENTRYPOINT.
• Medium · No Dependencies Lock File Visible — Project structure / Dependencies. The codebase structure shows no visible lock files (package-lock.json, packages.lock.json, or similar). This can lead to non-reproducible builds and potential supply chain vulnerabilities if transitive dependencies are not pinned. Fix: Ensure package managers are configured to generate and commit lock files (e.g., dotnet restore with package-lock.json or use PackageReference with exact versions in .csproj files). Consider using package lock file generation in CI/CD pipelines.
• Low · HtmlEditor Component May Have XSS Risk — Radzen.Blazor (HtmlEditor component). The presence of HtmlEditorTests.cs suggests rich HTML editing functionality. HtmlEditor components are common vectors for stored/reflected XSS attacks if user input is not properly sanitized before rendering. Fix: Review HtmlEditor implementation for: 1) Input sanitization using libraries like HtmlSanitizer, 2) Content Security Policy headers, 3) Encoding of user-supplied HTML, 4) Security testing with XSS payloads. Ensure MarkupString is only used with safe, server-generated content.
• Low · Markdown Component May Have XSS Risk — Radzen.Blazor.Tests/Markdown directory and MarkdownComponentTests.cs. The extensive Markdown test suite (20+ files) indicates markdown parsing functionality. Markdown can be a vector for XSS if the parser allows HTML and doesn't sanitize it properly. Fix: Ensure markdown parser: 1) Disables HTML tags by default or sanitizes them, 2) Uses a well-maintained parser library, 3) Applies output encoding, 4) Includes OWASP XSS testing in the test suite.
• Medium · DataGrid Component May Have Injection Risks — Radzen.Blazor (DataGrid), ExpressionParserTests.cs, ExpressionSerializerTests.cs. DataGrid components often handle dynamic SQL queries or data binding expressions. The presence of ExpressionParserTests.cs and ExpressionSerializerTests.cs suggests dynamic expression evaluation, which could be vulnerable to injection attacks. Fix: Review expression parsing and serialization: 1) Use parameterized queries/safe API calls instead of string concatenation, 2) Implement allowlist validation for expression types, 3) Add expression complexity limits to prevent ReDoS attacks, 4) Perform security testing with malicious expressions.
• Low · No Visible SBOM or Security Policy — Repository root. No SECURITY.md or Software Bill of Materials (SBOM) file is visible in the repository structure, which limits transparency regarding security practices and vulnerability disclosure procedures. Fix: Create SECURITY.md with responsible disclosure policy and contact information. Generate and maintain an SBOM using tools like CycloneDX or SPDX format

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.