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/dotnet/AspNetCore.Docs 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
• 24+ active contributors
• Distributed ownership (top contributor 30% of recent commits)
• CC-BY-4.0 licensed
• CI configured
• Tests present
• ⚠ Non-standard license (CC-BY-4.0) — 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 dotnet/AspNetCore.Docs repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/dotnet/AspNetCore.Docs.

What it runs against: a local clone of dotnet/AspNetCore.Docs — 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 dotnet/AspNetCore.Docs | Confirms the artifact applies here, not a fork | | 2 | License is still CC-BY-4.0 | 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 ≤ 31 days ago | Catches sudden abandonment since generation |

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

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

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

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"
test -f ".openpublishing.publish.config.json" \\
  && ok ".openpublishing.publish.config.json" \\
  || miss "missing critical file: .openpublishing.publish.config.json"
test -f ".github/CODEOWNERS" \\
  && ok ".github/CODEOWNERS" \\
  || miss "missing critical file: .github/CODEOWNERS"
test -f ".markdownlint.json" \\
  && ok ".markdownlint.json" \\
  || miss "missing critical file: .markdownlint.json"

# 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/dotnet/AspNetCore.Docs"
  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).

The official ASP.NET Core documentation repository hosted on learn.microsoft.com, containing ~8.5M lines of C# code samples, ~3.8M lines of HTML markup, and comprehensive markdown documentation across 60+ top-level directories covering framework features from Blazor components to Entity Framework integration. It serves as the authoritative reference for building cloud-native .NET web applications. Monolithic markdown documentation tree: root aspnetcore/ directory branches into feature-specific subdirectories (blazor/, security/, data/, fundamentals/) each containing .md files and code samples; .github/ houses issue templates, CI workflows (GitHub Actions), and Copilot instructions for automated triage and content generation; configuration via .openpublishing.publish.config.json and .markdownlint.json enforces build and linting rules.

ASP.NET Core developers (beginner to advanced), who need accurate, up-to-date API references, tutorials, and best-practice examples; technical writers and community contributors who maintain and expand the documentation; and enterprise teams building production web applications who rely on this as the official Microsoft source of truth.

Highly mature and production-critical: this is the official Microsoft documentation site backing learn.microsoft.com, with active CI/CD pipelines (.github/workflows/), automated issue triage policies, Copilot-assisted authoring, and documented contribution workflows in CONTRIBUTING.md. The repository shows signs of active maintenance with multiple automated workflows (merge-live.yml, quest.yml, issue-triage workflows) and a structured CODEOWNERS file, indicating this is mission-critical infrastructure for the .NET ecosystem.

Low technical risk but high content-quality risk: the repo is a documentation-only project without code dependencies, but relies on manual human review and writing quality (GitHub policies manage untriaged issues, but content accuracy is not algorithmically verified). The breadth of coverage across Blazor, Entity Framework, Identity, and dozen other feature areas means content drift is a real concern; a single outdated code sample in aspnetcore/blazor/components/ could mislead thousands of developers.

The repository is actively maintained with automated workflows for issue triage (blazor-issue-processing.yml, blazor-hybrid-issue-processing.yml), pull request labeling based on file changes (pullRequestManagement-labelFiles.yml), and live deployment (merge-live.yml). GitHub Copilot skills are being leveraged for 'what's new' content generation (.github/skills/whats-new-include-content-rules/) and bulk issue processing (quest-bulk.yml), indicating a shift toward AI-assisted authoring and maintenance at scale.

Clone and browse locally: git clone https://github.com/dotnet/AspNetCore.Docs.git && cd AspNetCore.Docs. No build step needed for pure documentation; to validate locally, use npm install (if available) and markdownlint to check for lint violations against .markdownlint.json. To preview on learn.microsoft.com, open a PR; the merge-live.yml workflow auto-publishes on merge to main.

Daily commands: This is a documentation repository—there is no 'run' step. To edit: clone the repo, modify .md files in aspnetcore/ subdirectories, validate with markdownlint (configured in .markdownlint.json), commit, and open a PR. The CI pipeline (check-for-build-warnings.yml) validates the PR; merge to main triggers live publication via merge-live.yml.

• README.md — Entry point explaining the repository purpose, contribution guidelines, and how to report issues—essential context for all contributors.
• CONTRIBUTING.md — Defines contribution workflow, coding standards, and PR submission process that all contributors must follow.
• .openpublishing.publish.config.json — Build and publishing configuration that controls how documentation is compiled and deployed to learn.microsoft.com.
• .github/CODEOWNERS — Defines ownership and review responsibility for documentation areas, ensuring PRs reach the right reviewers.
• .markdownlint.json — Linting configuration that enforces consistent markdown style across all documentation files.
• .openpublishing.redirection.json — Maps deprecated documentation URLs to new locations, maintaining user navigation integrity across versions.
• .github/copilot-instructions.md — AI assistant guidelines for code generation and documentation editing in this specific repository context.

• Markdown Documentation Files — Source content defining all ASP.NET Core feature documentation; organized by

Add a New Blazor Component Documentation Article

1. Create a new markdown file in aspnetcore/blazor/components/ following naming convention: feature-name.md (aspnetcore/blazor/components/[new-feature].md)
2. Add markdown frontmatter with title, description, and topic metadata at the top of the file (aspnetcore/blazor/components/[new-feature].md)
3. Reference the new article in the parent index.md file to expose it in navigation (aspnetcore/blazor/components/index.md)
4. Include code examples in fenced blocks with language specification (csharp, html, etc.) (aspnetcore/blazor/components/[new-feature].md)
5. Run markdownlint validation to ensure compliance with style rules defined in .markdownlint.json (.markdownlint.json)

Update Component Lifecycle Documentation

1. Edit aspnetcore/blazor/components/lifecycle.md to describe new lifecycle hooks or changes (aspnetcore/blazor/components/lifecycle.md)
2. Add corresponding example code snippets in the lifecycle subdirectory if diagrams or assets are needed (aspnetcore/blazor/components/lifecycle/_static/lifecycle1.png)
3. Cross-reference related articles (e.g., component-disposal.md) using markdown link syntax (aspnetcore/blazor/components/lifecycle.md)
4. Update CONTRIBUTING.md if new documentation patterns or code sample conventions are introduced (CONTRIBUTING.md)

Add a New Form Validation Article

1. Create markdown file in aspnetcore/blazor/forms/ with clear naming (e.g., custom-validators.md) (aspnetcore/blazor/forms/[validation-topic].md)
2. Include working code examples showing validator implementation and usage patterns (aspnetcore/blazor/forms/[validation-topic].md)
3. Link to input-components.md and validation.md for context and related functionality (aspnetcore/blazor/forms/[validation-topic].md)
4. Update aspnetcore/blazor/forms/index.md to add navigation link to new article (aspnetcore/blazor/forms/index.md)

• Markdown — Simple, version-control-friendly format for documentation; widely supported by publishing pipeline
• Open Publishing (OPS) — Microsoft's internal system for building and deploying learn.microsoft.com documentation at scale
• GitHub — Community contribution hub; integrates with OPS for automated build/publish workflows and issue/PR management
• GitHub Actions — Enables automated issue triage, URL redirects validation, and build warnings detection without external CI

• Centralized single-branch main documentation

  • Why: Simplifies synchronization; all contributors work on current version
  • Consequence: Does not maintain versioned docs for older ASP.NET Core releases (versioning handled server-side by learn.microsoft.com)

• No custom runtime/backend code in this repository

  • Why: Documentation is static content; build and deploy logic centralized in Open Publishing service
  • Consequence: Contributors cannot test custom CI logic locally; relies on GitHub Actions and OPS infrastructure

• Markdown-only source format

  • Why: Lightweight, git-friendly, supports all needed features (code blocks, images, tables)
  • Consequence: Cannot include interactive components or server-side computation; rich interactivity deferred to linked samples

• Not a code repository—does not ship runnable applications or libraries
• Does not manage authentication or access control (GitHub CODEOWNERS is for review routing only)
• Does not include real-time feedback or comments on published articles (issue links direct to GitHub)
• Does not provide version branching for past ASP.NET Core releases (OPS handles that externally)

No local build required, but validation is strict: markdownlint must pass, and .openpublishing.publish.config.json expects specific metadata in each article frontmatter. GitHub issue templates (blank-issue.md, doc-issue.md) are enforced via config.yml policies—blank or malformed issues are auto-closed. The repo uses OpenPublishing-specific syntax (redirects in .openpublishing.redirection.json, snippet inclusion syntax); standard Markdown is not sufficient. PRs are auto-labeled by file path (pullRequestManagement-labelFiles.yml), so file location determines visibility; place docs in the wrong aspnetcore/ subdirectory and they may not reach the intended reviewer.

• OpenPublishing metadata and redirects — This repo uses Microsoft's OpenPublishing system (.openpublishing.publish.config.json, .openpublishing.redirection.json); understanding how metadata is injected into each article and how redirects are maintained is essential for avoiding broken doc links at scale
• Cascading values and parameters in Blazor — Core Blazor component communication pattern; heavily documented in aspnetcore/blazor/components/cascading-values-and-parameters.md and critical for developers building reusable component libraries
• Server-side rendering (SSR) vs. WebAssembly trade-offs — A central architectural decision in Blazor docs that branches the entire feature set; understanding when to use Blazor Server, Blazor WASM, or Blazor Hybrid is the first question new users ask
• Entity Framework Core query translation and limitations — EF Core's translation of LINQ to database-specific SQL has subtle limitations (e.g., client-side evaluation); docs in aspnetcore/data/ef-core/ must be precise because mistakes lead to runtime failures in production
• Dependency Injection (DI) service lifetime scope (Transient, Scoped, Singleton) — ASP.NET Core's DI container is fundamental; incorrect lifetime management (e.g., injecting Singleton into Scoped) is a common bug; docs must clearly explain when to use each pattern
• Minimal APIs vs. Controller-based routing — Modern ASP.NET Core supports both paradigms; docs must guide developers on when Minimal APIs (aspnetcore/fundamentals/minimal-apis/) are simpler and when traditional Controllers are necessary
• Markdown code snippet inclusion and validation — This repo embeds code samples in markdown using OpenPublishing syntax (e.g., :::code blocks); samples must be kept in sync with reality (C# version, API changes) or docs become misleading—contributor tooling enforces this

• dotnet/AspNetDocs — Official docs for ASP.NET 4.x (legacy); used by developers migrating from .NET Framework to .NET Core
• dotnet/runtime — Core .NET runtime implementation; AspNetCore.Docs frequently links to and documents runtime behavior
• dotnet/aspnetcore — The actual ASP.NET Core source code; documentation examples are extracted from or validated against this repo
• MicrosoftDocs/Feedback — Central issue tracker for learn.microsoft.com site design and UX concerns separate from doc content
• dotnet/samples — Sample applications demonstrating ASP.NET Core features in production-like scenarios; often referenced in docs

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.

Create comprehensive documentation for Blazor Hybrid on .NET on Web Workers

The file aspnetcore/blazor/blazor-with-dotnet-on-web-workers.md exists in the structure, but given the recent additions of web worker support, there's likely missing guidance on integration patterns, best practices, and troubleshooting. This would help developers understand this emerging capability and reduce support issues.

• [ ] Review existing aspnetcore/blazor/blazor-with-dotnet-on-web-workers.md content and identify gaps
• [ ] Add sections covering: worker initialization, message passing patterns, debugging web workers, performance considerations, and common pitfalls
• [ ] Include at least 2-3 working code examples for different scenarios (CPU-intensive tasks, API calls from workers)
• [ ] Add cross-references from related files like advanced-scenarios.md and call-web-api.md
• [ ] Submit PR with review from Blazor team based on .github/CODEOWNERS

Document Blazor class library RCL styling and asset bundling best practices

Two related files exist (aspnetcore/blazor/components/class-libraries.md and class-libraries-and-static-server-side-rendering.md) plus a class-libraries subdirectory with static assets (background.png, jeep-component.png). The documentation likely lacks clear guidance on how to properly package and distribute CSS isolation, static assets, and component styling in RCLs—a common pain point for library authors.

• [ ] Review both class-libraries documentation files for CSS isolation and asset handling coverage gaps
• [ ] Add detailed section on asset bundling strategies for RCLs, including CSS isolation file naming conventions
• [ ] Document the build process for RCLs with static assets (reference the ./_static/ directory structure)
• [ ] Create explicit examples showing proper wwwroot structure and how consumers reference assets
• [ ] Include troubleshooting section for common RCL styling issues (CSS not loading, asset path problems)

Expand HttpContext documentation for Blazor with practical server-side scenarios

The file aspnetcore/blazor/components/httpcontext.md exists but likely needs expansion for the common scenario where Blazor components need to access HttpContext on the server (authentication claims, request headers, locale info). This is a frequent question in community forums and represents a significant integration point.

• [ ] Review current httpcontext.md content and identify what scenarios are missing
• [ ] Add section on accessing HttpContext in Blazor Server components with code examples
• [ ] Document how to safely access HttpContext during prerendering in static SSR scenarios
• [ ] Add examples for common patterns: extracting auth claims, reading request headers, setting response headers
• [ ] Include a 'Common Pitfalls' section covering thread safety and cascading parameters as alternatives
• [ ] Cross-reference from advanced-scenarios.md and cascading-values-and-parameters.md

• Update aspnetcore/blazor/components/cascading-values-and-parameters.md with a complete, runnable code example demonstrating cascading generic parameters (currently sparse)—see the issue template in .github/ISSUE_TEMPLATE/doc-request.md for how to structure the contribution.
• Add missing TypeScript documentation for JavaScript interop in Blazor WebAssembly: aspnetcore/blazor/ has JavaScript samples but no dedicated TypeScript examples for type-safe JS/C# bridge calls; create aspnetcore/blazor/javascript-interop-typescript.md with sample projects.
• Audit and fix outdated Entity Framework Core examples in aspnetcore/data/ef-core/ against the latest stable release; many code samples likely predate .NET 8 breaking changes—run them against current SDK and update syntax.

This is a documentation repository (dotnet/AspNetCore.Docs) with a strong security posture. No critical vulnerabilities were identified in the static analysis. The codebase consists primarily of Markdown documentation files, configuration files, and GitHub workflow definitions. The repository follows security best practices with proper code ownership policies, contribution guidelines, and issue triage automation. Minor recommendations exist for configuration hardening and workflow security improvements.

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.