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/CAP 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 2w ago
• 23+ active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 62% of recent commits

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

What it runs against: a local clone of dotnetcore/CAP — 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/CAP | 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 ≤ 43 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "dotnetcore/CAP(\\.git)?\\b" \\
  && ok "origin remote is dotnetcore/CAP" \\
  || miss "origin remote is not dotnetcore/CAP (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 "CAP.sln" \\
  && ok "CAP.sln" \\
  || miss "missing critical file: CAP.sln"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "build/BuildScript.cs" \\
  && ok "build/BuildScript.cs" \\
  || miss "missing critical file: build/BuildScript.cs"
test -f "docs/content/user-guide/en/cap/transactions.md" \\
  && ok "docs/content/user-guide/en/cap/transactions.md" \\
  || miss "missing critical file: docs/content/user-guide/en/cap/transactions.md"
test -f "docs/content/user-guide/en/cap/messaging.md" \\
  && ok "docs/content/user-guide/en/cap/messaging.md" \\
  || miss "missing critical file: docs/content/user-guide/en/cap/messaging.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 43 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~13d)"
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/CAP"
  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).

CAP is a .NET library implementing the Outbox Pattern for distributed transactions and event bus functionality in microservices. It uses a local message table integrated with your database to guarantee message delivery and eventual consistency, ensuring events are never lost even during network or service failures. Monorepo structured around CAP.sln (main solution) with separate build tooling (build/ directory handles versioning via BuildScript.cs), a Vue 2 + Vite dashboard (cap-dashboard package with bootstrap-vue), documentation site (docs/content/ with user guides), and domain-specific modules for transactions, messaging, and monitoring.

.NET microservice architects and backend developers building SOA systems who need guaranteed message delivery across services without losing transaction integrity; also used by teams wanting a lightweight event bus without the complexity of full saga orchestration frameworks.

Production-ready and actively maintained. The project has GitHub Actions CI/CD (deploy-docs-and-dashboard.yml, AppVeyor builds), semantic versioning via NuGet (8.0.0 in package.json), comprehensive documentation in docs/content/user-guide/, and appears to be a mature community project (member of .NET Core Community). Latest activity visible through GitHub workflows and build infrastructure.

Low-to-moderate risk for adoption: monolithic codebase (~1M lines C#) means changes propagate broadly; single language ecosystem (.NET only) limits contributor pool; dependency on specific database implementations (evidenced by transaction-heavy code) means database upgrades require testing. However, established NuGet package with semantic versioning and active CI/CD pipeline reduce risk.

Active development on dashboard and documentation deployment (deploy-docs-and-dashboard.yml workflow in .github/workflows/). Recent focus on monitoring features (docs reference OpenTelemetry, Consul integration, dotnet-counters). Package versioned at 8.0.0 with release notes tracked in docs/content/about/release-notes.md.

git clone https://github.com/dotnetcore/CAP.git
cd CAP
dotnet restore CAP.sln
dotnet build CAP.sln

For dashboard development: cd src/DotNetCore.CAP.Dashboard && npm install && npm run dev (using Vite).

Daily commands: Backend: dotnet build CAP.sln && dotnet run in relevant project directory. Dashboard: From dashboard directory: npm install && npm run dev (Vite dev server on port 5173 by default) or npm run build for production.

• CAP.sln — Solution file defining the entire project structure and all dependent libraries for the distributed transaction and event bus system
• README.md — Primary documentation explaining CAP's purpose as an eventually-consistent distributed transaction solution with event bus and Outbox pattern support
• build/BuildScript.cs — Core build automation script that compiles, tests, and packages the CAP library and all transport/storage providers
• docs/content/user-guide/en/cap/transactions.md — Essential guide on implementing distributed transactions and the Outbox pattern, the library's primary use case
• docs/content/user-guide/en/cap/messaging.md — Core documentation on message publishing, subscription, and event bus routing mechanisms
• build/version.props — Version management file controlling versioning across all NuGet packages and dashboard releases
• .github/workflows/deploy-docs-and-dashboard.yml — CI/CD pipeline automating documentation and dashboard builds, essential for understanding release and deployment process

Add a New Transport Provider

1. Create new transport documentation in docs/content/user-guide/en/transport/{provider-name}.md following the pattern used in kafka.md and rabbitmq.md (docs/content/user-guide/en/transport/general.md)
2. Include configuration examples, broker setup instructions, and performance characteristics in the new transport guide (docs/content/user-guide/en/transport/{provider-name}.md)
3. Add transport-specific screenshots to docs/content/img/ (e.g., dashboards showing message flow) (docs/content/img)
4. Reference new transport in the general transport overview documentation (docs/content/user-guide/en/transport/general.md)

Add a New Storage Backend

1. Create storage provider documentation in docs/content/user-guide/en/storage/{database-name}.md mirroring the structure of postgresql.md (docs/content/user-guide/en/storage/{database-name}.md)
2. Document schema requirements, connection string configuration, and migration procedures for the new storage backend (docs/content/user-guide/en/storage/{database-name}.md)
3. Reference the new storage option in docs/content/user-guide/en/storage/general.md for selection guidance (docs/content/user-guide/en/storage/general.md)
4. Add version-specific compatibility notes and performance tuning recommendations (docs/content/user-guide/en/storage/{database-name}.md)

Document a New Feature or Configuration Option

1. Add feature documentation to docs/content/user-guide/en/cap/{feature-name}.md or extend existing docs like configuration.md (docs/content/user-guide/en/cap/configuration.md)
2. Include code examples, configuration snippets, and use case scenarios (docs/content/user-guide/en/cap/{feature-name}.md)
3. Update docs/content/user-guide/en/getting-started/quick-start.md if feature is essential for new users (docs/content/user-guide/en/getting-started/quick-start.md)
4. Reference in README.md if it's a major feature or breaking change (README.md)

Release a New Version

1. Update version number in build/version.props and build/BuildVersion.cs (build/version.props)
2. Document release notes and breaking changes in docs/content/about/release-notes.md (docs/content/about/release-notes.md)
3. Update package.json version field for the dashboard component to match NuGet package version (package.json)
4. Run BuildScript.cs to automatically handle version propagation across all NuGet packages and generate changelog (build/BuildScript.cs)

• .NET / C# — Core runtime for the CAP library, enabling tight integration with ASP.NET Core and Entity Framework for transaction management and data persistence
• Outbox Pattern — Ensures exactly-once message delivery semantics in distributed transactions by storing events locally before publishing, solving the dual-write problem
• Multiple Storage Backends (SQL Server, PostgreSQL, MySQL, MongoDB) — Allows users to integrate CAP with their existing database infrastructure without migration, supporting heterogeneous microservice architectures
• Multiple Transport Providers (RabbitMQ, Kafka, AWS SQS, Redis Streams, NATS, Pulsar) — Provides flexibility in message broker selection, enabling adoption across different cloud providers and on-premise deployments
• Vue.js + Bootstrap Dashboard — Modern web-based monitoring UI for real-time message tracking, retry management, and system health visualization without requiring external tools
• OpenTelemetry Integration — Standards-based distributed tracing support for observability across microservices, enabling correlation of events across system boundaries

• Rely on local transaction + eventual consistency instead of distributed 2PC

  • Why: Distributed two-phase commit is complex and brittle; eventual consistency scales better and aligns with microservice best practices
  • Consequence: Requires idempotent message handlers and careful ordering semantics; eventual consistency means temporary inconsistency windows

• Support multiple storage and transport backends through pluggable providers

  • Why: Avoids vendor lock-
  • Consequence: undefined

Database dependency: CAP requires a specific database (SQL Server, PostgreSQL, MySQL inferred) to store the local message table; missing database or incorrect connection string will silently fail. Message queue adapters: Different transport layers (RabbitMQ, Kafka, AWS) require separate NuGet packages not listed — you must select and install the correct transport adapter. Dashboard security: No authentication visible in dashboard config — deploying to production requires adding auth middleware. Version lock: build/version.props controls all versioning; changing it in one place isn't enough — BuildScript.cs also references it. Outbox table schema: Must be created/migrated manually or via EF Core migrations — not auto-created on first run.

• Outbox Pattern — CAP's core feature for solving distributed transaction consistency — understanding this pattern is essential to using CAP correctly and knowing when it applies to your problem
• Eventual Consistency — CAP trades immediate consistency for availability and partition tolerance in distributed systems — you must understand the consistency guarantees and retry semantics to design robust microservices
• Idempotent Consumer — CAP's message retry mechanism (docs/content/user-guide/en/cap/idempotence.md) requires consumers to be idempotent — failed messages may be retried multiple times, and your handlers must handle duplicate executions safely
• Message Deduplication — Related to idempotency — CAP's Outbox table tracks published messages and prevents duplicate processing, requiring understanding of how deduplication keys are managed
• Saga Pattern — CAP implements eventual consistency via local message tables (Outbox), which is simpler than choreography-based sagas but has different failure modes and consistency guarantees
• Topic Wildcards and Fan-Out Messaging — CAP documentation mentions wildcard subscriptions (*, #) — these require understanding AMQP/Kafka topic patterns to correctly subscribe to message streams
• Backpressure Mechanism — CAP's backpressure feature prevents OOM under high message load — understanding how consumer groups throttle processing is critical for production deployments with traffic spikes

• MassTransit/MassTransit — Comparable .NET distributed application framework with bus abstraction and saga support; primary alternative for microservice messaging
• NServiceBus/NServiceBus — Enterprise .NET service bus with guaranteed delivery and saga patterns; direct competitor for distributed transaction scenarios
• dotnetcore/Util — Companion project in .NET Core Community providing utility libraries that CAP may depend on or share infrastructure with
• dotnetcore/FreeSql — ORM from same .NET Core Community ecosystem; CAP integrates with database layers like those FreeSql provides
• Shopify/sarama — Kafka client library (Go-based) — useful for understanding Kafka transport adapter patterns that CAP implements for Kafka messaging

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 integration tests for AWS SQS and Azure Service Bus transports

The repo has documentation for AWS SQS and Azure Service Bus transports (docs/content/user-guide/en/transport/aws-sqs.md and azure-service-bus.md), but there are no visible integration tests in the file structure for these transports. This is critical for a distributed messaging library to ensure reliability across different cloud providers. New contributors can add test projects that validate message publishing, consuming, and failure scenarios.

• [ ] Create test/DotNetCore.CAP.Tests.Transport.AwsSqs project with integration tests for publish/subscribe scenarios
• [ ] Create test/DotNetCore.CAP.Tests.Transport.AzureServiceBus project mirroring AWS SQS test structure
• [ ] Add GitHub Actions workflow step in .github/workflows to run these integration tests against cloud emulators or test accounts
• [ ] Document test setup in docs/content/user-guide/en/getting-started/contributing.md with cloud provider credentials setup

Add comprehensive unit tests for cap-dashboard Vue components

The dashboard package.json shows a Vue 2.7 + Vite setup with multiple components handling critical UI concerns (routing, state management with Vuex, i18n), but there are no visible test files (.spec.js/.spec.ts) in the file structure. This is a high-value contribution for ensuring dashboard stability across releases.

• [ ] Set up Vitest and Vue Test Utils in the dashboard dev dependencies (package.json)
• [ ] Create unit tests for main Vuex store modules (mutations, actions, getters)
• [ ] Add component tests for critical dashboard pages (metrics display, message details, topology visualization)
• [ ] Add tests for vue-i18n configuration to ensure translation keys are properly resolved
• [ ] Integrate test coverage reporting into GitHub Actions workflow

Add OpenTelemetry instrumentation tests and documentation for different storage backends

The repo has docs/content/user-guide/en/monitoring/opentelemetry.md and supports multiple storage backends (MySQL, PostgreSQL, SQL Server, MongoDB, In-Memory), but there are no visible tests validating that OpenTelemetry metrics/traces work correctly with each storage backend. This is important for production observability.

• [ ] Create test/DotNetCore.CAP.Tests.OpenTelemetry project with test fixtures for each storage backend (MySQL, PostgreSQL, SqlServer, MongoDB)
• [ ] Add tests validating that message publish/consume operations emit correct OpenTelemetry spans and metrics for each backend
• [ ] Add test cases for failure scenarios (dead-letter messages, retries) to ensure tracing captures these states
• [ ] Update docs/content/user-guide/en/monitoring/opentelemetry.md with backend-specific examples and troubleshooting section

• Add unit tests for cap-dashboard Vue components in cap-dashboard/tests/ — currently no test directory visible, and frontend components (likely in src/ of dashboard) lack test coverage
• Expand docs/content/user-guide/en/cap/idempotence.md with concrete code examples showing how to implement idempotent consumer handlers — current docs reference the concept but lack runnable samples
• Create a missing docs/content/user-guide/en/cap/troubleshooting.md file documenting common issues (database connection failures, message stuck in outbox, consumer lag) with diagnostic steps and solutions

• High · Outdated axios Dependency with Known Vulnerabilities — package.json - dependencies.axios. The project uses axios ^0.28.1, which is outdated and contains known security vulnerabilities. Axios 0.28.1 and earlier versions have issues with request/response interceptors and potential data exposure in error handling. Current recommended versions are 1.4.0 or later. Fix: Update axios to the latest stable version (^1.6.0 or higher). Run 'npm update axios' and test compatibility with the dashboard application.
• High · Outdated Bootstrap Dependency — package.json - dependencies.bootstrap. Bootstrap 4.6.2 is an older major version with potential security and compatibility issues. Bootstrap 5.x and later versions include security patches and improved component security. Fix: Consider upgrading to Bootstrap 5.x (^5.3.0) or later. This requires testing the dashboard UI components for compatibility.
• Medium · Outdated Vue.js Version — package.json - dependencies.vue. Vue 2.7.16 is in extended long-term support but the codebase should consider migration to Vue 3.x. Vue 2 will eventually reach end-of-life, and Vue 3 provides better security patches and performance. Additionally, the vue-i18n dependency is pinned to 8.x which is the Vue 2 version. Fix: Plan migration to Vue 3.x and upgrade related packages (vue-i18n ^9.x, vue-router ^4.x). This is a medium-priority upgrade path.
• Medium · Missing Dependency Version Pinning — package.json - dependencies section. Several critical dependencies use caret (^) versioning which allows minor and patch updates automatically. This could introduce breaking changes or security regressions without explicit testing. Dependencies like axios, bootstrap, and vite fall into this category. Fix: Implement lock file verification (package-lock.json or yarn.lock) in CI/CD pipelines. Consider using npm ci instead of npm install in production deployments. Review and lock critical transitive dependencies.
• Medium · Potential XSS Risk with vue-json-pretty — package.json - dependencies.vue-json-pretty. The vue-json-pretty library (^1.9.5) renders JSON in the UI. If the source data is not properly sanitized, especially from API responses, there could be XSS vulnerabilities when displaying untrusted JSON structures. Fix: Ensure all API responses are validated and sanitized before passing to vue-json-pretty. Implement Content Security Policy (CSP) headers. Update to the latest version and review the library's security advisories.
• Medium · Outdated json-bigint Library — package.json - dependencies.json-bigint. json-bigint ^1.0.0 is an older library with limited maintenance. It's used to handle large numbers in JSON parsing, which could have parsing edge cases or security implications if not properly validated. Fix: Review if this library is still necessary. Consider alternatives like native BigInt support (Node 10.4.0+) or more actively maintained libraries. Update to the latest available version.
• Low · Development Dependency Security — package.json - devDependencies. Several dev dependencies like eslint and prettier are pinned to specific versions but lack explicit security patching. The @rushstack/eslint-patch suggests working around ESLint vulnerabilities rather than updating. Fix: Regularly update dev dependencies. Ensure npm audit is run as part of CI/CD pipeline. Review why eslint-patch is needed and consider upgrading core eslint version.
• Low · Missing Security Headers Configuration — Vite configuration and deployment setup. No evidence of security headers configuration (CSP, X-Frame-Options, X-Content-Type-Options, etc.) in the dashboard build configuration or documentation provided. Fix: Implement security headers in the web server configuration. Add CSP headers with strict policies for the dashboard. Document security header requirements in deployment documentation.
• Low · No HTTPS Enforcement Visible — undefined. The file structure and configuration snippets do not show explicit HTTPS enforcement or HSTS headers configuration Fix: undefined

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.