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/dotnetcore/BootstrapBlazor 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.

WAIT — Single-maintainer risk — review before adopting

• Last commit 1d ago
• 4 active contributors
• Apache-2.0 licensed
• CI configured
• ⚠ Small team — 4 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 95% 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 dotnetcore/BootstrapBlazor repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/dotnetcore/BootstrapBlazor.

What it runs against: a local clone of dotnetcore/BootstrapBlazor — 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 dotnetcore/BootstrapBlazor | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | 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 dotnetcore/BootstrapBlazor. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/dotnetcore/BootstrapBlazor.git
#   cd BootstrapBlazor
#
# 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 dotnetcore/BootstrapBlazor and re-run."
  exit 2
fi

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

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

Bootstrap Blazor is an enterprise-grade UI component library that bundles 100+ pre-built Bootstrap-styled components (Button, Table, Modal, Form, DatePicker, etc.) for .NET Blazor applications. It eliminates the need to write Bootstrap markup and JavaScript interop by hand—developers reference C# component classes with typed parameters instead, getting production-ready, accessible UI instantly. Monolithic codebase structured by technology: src/ contains C# component implementations (organized by component type: Button, Table, etc.), src/BootstrapBlazor/ is the core NuGet package, docs/ and examples/ hold demos and integration guides, and a top-level BootstrapBlazor.slnx Visual Studio solution ties it together. JavaScript (JavaScript: 481KB) and CSS/SCSS (493KB total) are bundled as _content assets served to Blazor apps at runtime.

.NET developers (C# backend engineers transitioning to full-stack, enterprise teams building internal tools) who want to ship Bootstrap-styled web UIs quickly without learning JavaScript frameworks. Particularly targets teams building data-rich dashboards, admin panels, and line-of-business apps where Bootstrap conventions match their design expectations.

Production-ready and actively maintained. The repo shows 8.1M lines of C# across a monolithic codebase, robust CI/CD (build.yml, pack.yml, publish.yml workflows), comprehensive GitHub issue templates, CHANGELOG entries, and regular NuGet package releases. The .NET Foundation endorsement and online demo site at https://www.blazor.zone reinforce stability, though commit frequency should be verified to assess ongoing investment level.

Low-to-medium risk for enterprise use. Single language ecosystem (Blazor-only, ties you to .NET platform), but no obvious single-maintainer dependency bottleneck given .NET Foundation backing. Watch for: breaking changes across .NET versions (Blazor evolves yearly), JavaScript interop complexity in js/ folder (481KB suggests non-trivial JS layer that must stay in sync), and the monolithic structure making selective upgrades harder. Check GitHub Actions status and recent merged PRs in the main branch before adoption.

Active development indicated by CHANGELOG.md and CHANGELOG.zh-CN.md tracking version history, multiple GitHub workflows (auto-pull-request-checks.yml), and Docker support (.github/workflows/docker.yml). The .gitee/ folder suggests dual GitHub/Gitee (Chinese platform) mirroring. Recent work likely includes component refinements, localization updates (11 language files in localization/), and CI/CD stability; check GitHub Actions tab and recent commit history for exact current sprint focus.

Clone and build: git clone https://github.com/dotnetcore/BootstrapBlazor.git && cd BootstrapBlazor && dotnet restore && dotnet build. The .NET SDK is required (see README's Environment section). Use Visual Studio (latest) or VS Code + C# extension for IDE support. Run dotnet watch run in an example project directory to start the dev server locally.

Daily commands: No traditional 'npm start' pattern (not Node.js). Instead: open BootstrapBlazor.slnx in Visual Studio and run the startup project (usually an example app like Sample.Client or Sample.Server), or use dotnet watch run in the example directory. Hot reload via Blazor's built-in watch mode. The bundled CSS/JS are already compiled; rebuild C# project to see changes.

• BootstrapBlazor.slnx: Solution file that aggregates all projects; entry point for developers opening the repo in Visual Studio.
• src/BootstrapBlazor/Components/: Core directory containing all 100+ reusable Blazor component implementations (Button, Table, Modal, Form, etc.) that form the library's API surface.
• [Directory.Build.props and Framework.props](https://github.com/dotnetcore/BootstrapBlazor/blob/main/Directory.Build.props and Framework.props): Centralized .NET SDK version, compiler flags, and NuGet package metadata applied to all projects in the monorepo.
• NuGet.Config: Configures NuGet package feed sources; critical for resolving dependencies and publishing the component library to nuget.org.
• .github/workflows/: GitHub Actions CI/CD definitions for build, test, pack, publish, and Docker image generation; ensures quality gates before release.
• localization/: Contains 11 JSON files for multi-language UI strings (Chinese, German, Spanish, Russian, Thai, etc.); essential for i18n support.
• src/BootstrapBlazor/Styles/: SCSS stylesheets that extend Bootstrap and define component-specific theming; compiled into bootstrap.blazor.bundle.min.css.
• src/BootstrapBlazor/Scripts/: JavaScript modules providing DOM interop, event handling, and Bootstrap plugin initialization for components like modals and toasts.
• [CHANGELOG.md and CHANGELOG.zh-CN.md](https://github.com/dotnetcore/BootstrapBlazor/blob/main/CHANGELOG.md and CHANGELOG.zh-CN.md): Tracks all version releases, breaking changes, and feature additions; mandatory reading before upgrading projects that depend on this library.

New component contributions start in src/BootstrapBlazor/Components/[ComponentName]/[ComponentName].razor and [ComponentName].razor.cs. Styling belongs in src/BootstrapBlazor/Styles/ (SCSS files). JavaScript interop (if needed) goes in src/BootstrapBlazor/Scripts/. Look at src/BootstrapBlazor/Components/Button/ or src/BootstrapBlazor/Components/Table/ as reference implementations. Run tests via dotnet test after changes. Update localization files in localization/*.json if adding user-facing strings.

1. Monolithic rebuild: Changing one component may trigger recompilation of the entire BootstrapBlazor package due to .NET project structure; incremental builds can be slow. 2. JavaScript bundle coupling: CSS and JS are bundled together (bootstrap.blazor.bundle.min.js); you cannot easily use a subset—all-or-nothing loading model. 3. Blazor hosting model choice: Components work with both WebAssembly (client-side) and Server (server-side) Blazor, but some interactive features (form handling, event debouncing) have different semantics; test in your target hosting model. 4. Bootstrap version lock: The library targets a specific Bootstrap major version (likely 5.x based on CSS file naming); upgrading Bootstrap globally in your project may conflict. 5. Localization JSON structure: Adding a new language requires extending all 11 JSON files with matching keys; incomplete keys will fall back to default language silently.

• Blazor Component Lifecycle — Every UI element in Bootstrap Blazor is a Blazor component with OnInitializedAsync, OnParametersSetAsync, and OnAfterRenderAsync hooks; understanding lifecycle prevents race conditions in data binding and JavaScript interop.
• Two-way Data Binding (@bind) — Bootstrap Blazor components heavily use @bind for form inputs and state synchronization; misconfiguring bind syntax or binding to non-observable properties causes stale UI updates.
• JavaScript Interop (IJSRuntime) — Bootstrap Blazor's 481KB JavaScript layer is invoked via IJSRuntime.InvokeAsync() calls; understanding interop boundaries and memory leaks (JS objects held by C# delegates) is critical for component reliability.
• Cascading Parameters — Complex components like Table, Form, and Modal use cascading parameters to pass context (e.g., ValidationContext) down the component tree; forgetting to declare [CascadingParameter] breaks nested component communication.
• RenderFragment and Template Rendering — Bootstrap Blazor components accept RenderFragment parameters for customizable templates (e.g., Table column templates, Modal footer); mastering this pattern lets you extend components without forking.
• Service Localization (i18n via DI) — The 11 localization JSON files are loaded into a service injected into components; understanding how to inject IStringLocalizer<T> and select culture at app startup is essential for multi-language deployments.
• Event Callbacks and Parameter Change Detection — Bootstrap Blazor components expose EventCallback<T> parameters for parent-child communication; understanding when Blazor re-renders (on parameter change vs. event callback) prevents infinite loops and stale state.

• telerik/blazor-ui — Commercial alternative UI component library for Blazor with similar scope (data grids, forms, modals); directly competes on component breadth and enterprise support.
• radzen/radzen-blazor — Open-source Blazor component library with Bootstrap styling and drag-and-drop designer; similar feature set and enterprise positioning but different architecture.
• dotnetcore/DotnetCore.MVVM — Complementary .NET Foundation project often used alongside Bootstrap Blazor for state management and MVVM patterns in Blazor apps.
• dotnet/aspnetcore — Upstream Blazor framework repository; Bootstrap Blazor depends on this; track breaking changes and new Blazor features here.
• twbs/bootstrap — Upstream Bootstrap CSS framework; Bootstrap Blazor wraps Bootstrap components—new Bootstrap versions may require compatibility updates here.

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 localization system across all supported languages

The repo contains 10 localization files (de.json, es.json, it.json, km-KH.json, pt-BR.json, pt.json, ru-RU.json, th-TH.json, uk-UA.json, zh-TW.json) but there's no evidence of unit tests validating: (1) all files have matching keys, (2) no missing translations, (3) proper JSON structure, (4) language-specific character encoding. This prevents regressions when contributors add new translations.

• [ ] Create tests/BootstrapBlazor.Tests/LocalizationTests.cs
• [ ] Add test to verify all localization/*.json files have identical keys
• [ ] Add test to validate JSON schema and UTF-8 encoding for each locale
• [ ] Add test to ensure required UI component strings exist in each language file
• [ ] Integrate test into .github/workflows/build.yml

Create GitHub Actions workflow to validate Docker image builds across architectures

The repo has .github/workflows/docker.yml and a .dockerignore file, indicating Docker support, but no evidence of multi-architecture (linux/amd64, linux/arm64) build validation in CI. This is critical for enterprise users deploying to ARM-based systems (Raspberry Pi, Apple Silicon, cloud ARM instances).

• [ ] Review existing .github/workflows/docker.yml for architecture coverage
• [ ] Add buildx configuration to build and test linux/amd64 and linux/arm64 images
• [ ] Create matrix test job in workflow to verify image functionality on both architectures
• [ ] Document Docker build instructions in docs/repro.md for contributors

Add E2E component interaction tests for critical Bootstrap Blazor UI components

With 50+ enterprise UI components (implied by 'component library' description), there's likely no automated E2E testing for component interactions like form validation, dropdown selection, table sorting, modal dialogs, etc. The .github/workflows/build.yml likely only runs unit tests. Adding E2E tests (Playwright/Selenium) ensures component behavior consistency across versions.

• [ ] Create tests/BootstrapBlazor.E2E/ directory structure
• [ ] Add Playwright configuration and first E2E test for a core component (e.g., Form, Table, Modal)
• [ ] Create .github/workflows/e2e-tests.yml to run E2E tests on each PR
• [ ] Document E2E test setup in CONTRIBUTING.md with local test execution instructions

• Add unit test coverage for the Table component's sorting and pagination logic—src/BootstrapBlazor/Components/Table/ exists but likely has low test coverage; write XUnit tests in a parallel test project to verify column sort order, page size changes, and event callbacks.
• Expand the German (localization/de.json), Spanish (localization/es.json), and Thai (localization/th-TH.json) translations by reviewing untranslated UI strings in component markup and submitting pull requests to complete those language packs for full i18n coverage.
• Document the JavaScript interop API: src/BootstrapBlazor/Scripts/ contains ~481KB of interop code, but no clear API reference in docs/. Extract function signatures from .ts/.js files and create a markdown guide showing how custom components can reuse these utilities (e.g., event delegation, DOM queries).

The BootstrapBlazor repository demonstrates reasonable security practices with a dedicated SECURITY.md policy and GitHub security workflows. However, several concerns were identified: (1) Hardcoded private keys in the repository pose the highest risk and should be removed immediately, (2) Lack of visible dependency vulnerability scanning, (3) Infrastructure configurations (Docker, Nginx) require security hardening review, (4) The UI component library nature means XSS prevention is critical and requires careful code review of component implementations. The project should implement automated dependency scanning, remove sensitive files from history, and conduct security audits of deployment configurations.

• Medium · Hardcoded Security Credentials in Repository — scripts/linux/cert/blazor.zone.key, scripts/linux/cert/www.blazor.zone.key. The repository contains hardcoded SSL/TLS certificates and private keys in the scripts/linux/cert directory (blazor.zone.key, www.blazor.zone.key). These appear to be test/example certificates, but storing private keys in version control is a significant security risk as they may be exposed in repository history. Fix: 1. Remove all private keys from version control immediately. 2. Rotate the certificates if they were ever used in production. 3. Implement git-secrets or similar hooks to prevent future key commits. 4. Use environment-based certificate management for deployment. 5. Add *.key and sensitive cert files to .gitignore.
• Low · Security Policy Contact Information Exposed — SECURITY.md. The SECURITY.md file contains a plaintext email address (argo@live.ca) for security vulnerability reporting. While this is intentional for security disclosures, it may attract automated spam or reconnaissance attempts. Fix: 1. Consider using a dedicated security.txt file following RFC 9116 at /.well-known/security.txt. 2. Monitor the email address for spam and phishing attempts. 3. Consider using a security disclosure platform (e.g., HackerOne, Bugcrowd) for larger projects. 4. Implement rate limiting on security contact channels.
• Low · Missing Dependency Information for Analysis — Package.csproj files, NuGet.Config. The package dependencies file content was not provided, making it impossible to perform a comprehensive security analysis of third-party dependencies for known vulnerabilities (CVEs, insecure versions). Fix: 1. Regularly run 'dotnet list package --vulnerable' to identify vulnerable dependencies. 2. Use OWASP Dependency-Check or Snyk for continuous dependency scanning. 3. Configure GitHub Dependabot or similar tools for automated vulnerability alerts. 4. Implement a policy for prompt dependency updates.
• Low · Potential Information Disclosure in Docker Configuration — .dockerignore, .github/workflows/docker.yml. The presence of .dockerignore and docker.yml workflow suggests containerized deployment. Without reviewing the Dockerfile and Docker configurations, potential issues could exist around base image vulnerabilities, exposed ports, or insecure layer caching. Fix: 1. Use minimal base images (alpine, distroless). 2. Scan Docker images with tools like Trivy or Anchore. 3. Implement multi-stage builds to minimize final image size. 4. Document exposed ports and ensure only necessary services are exposed. 5. Use non-root user in Docker containers.
• Low · Nginx Configuration Exposure Risk — scripts/linux/nginx.conf. The presence of nginx.conf in scripts/linux/ suggests a production deployment configuration. Without review, it may contain security misconfigurations such as missing security headers, weak SSL/TLS settings, or directory traversal vulnerabilities. Fix: 1. Ensure security headers (X-Content-Type-Options, X-Frame-Options, CSP, etc.) are configured. 2. Use modern TLS versions (1.2+, prefer 1.3). 3. Disable unnecessary HTTP methods. 4. Implement rate limiting and DDoS protection. 5. Use security-focused nginx modules. 6. Conduct security audit of the configuration.

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.