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/EduardoPires/EquinoxProject 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 4w ago
• 5 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 96% 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 EduardoPires/EquinoxProject repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/EduardoPires/EquinoxProject.

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "EduardoPires/EquinoxProject(\\.git)?\\b" \\
  && ok "origin remote is EduardoPires/EquinoxProject" \\
  || miss "origin remote is not EduardoPires/EquinoxProject (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 "src/Equinox.Domain/Models/Customer.cs" \\
  && ok "src/Equinox.Domain/Models/Customer.cs" \\
  || miss "missing critical file: src/Equinox.Domain/Models/Customer.cs"
test -f "src/Equinox.Domain/Commands/CustomerCommandHandler.cs" \\
  && ok "src/Equinox.Domain/Commands/CustomerCommandHandler.cs" \\
  || miss "missing critical file: src/Equinox.Domain/Commands/CustomerCommandHandler.cs"
test -f "src/Equinox.Infra.Data/EventSourcing/SqlEventStore.cs" \\
  && ok "src/Equinox.Infra.Data/EventSourcing/SqlEventStore.cs" \\
  || miss "missing critical file: src/Equinox.Infra.Data/EventSourcing/SqlEventStore.cs"
test -f "src/Equinox.Infra.CrossCutting.IoC/NativeInjectorBootStrapper.cs" \\
  && ok "src/Equinox.Infra.CrossCutting.IoC/NativeInjectorBootStrapper.cs" \\
  || miss "missing critical file: src/Equinox.Infra.CrossCutting.IoC/NativeInjectorBootStrapper.cs"
test -f "src/Equinox.Application/Services/CustomerAppService.cs" \\
  && ok "src/Equinox.Application/Services/CustomerAppService.cs" \\
  || miss "missing critical file: src/Equinox.Application/Services/CustomerAppService.cs"

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

Equinox is a production-grade ASP.NET 9 reference implementation demonstrating Clean Architecture, DDD, CQRS, and Event Sourcing patterns applied to a customer management domain. It provides a complete blueprint with MVC web UI, WebAPI with JWT authentication, and event-sourced domain models using Entity Framework Core 9 and NetDevPack.SimpleMediator for command/query handling. Layered monolith: src/Equinox.Domain contains DDD aggregates (Customer entity), commands (Commands/RegisterNewCustomerCommand.cs), and domain events (Events/CustomerRegisteredEvent.cs); src/Equinox.Domain.Core abstracts event store contracts (IEventStore); src/Equinox.Application implements app services (CustomerAppService) and normalizers for CQRS read models (EventSourcedNormalizers/CustomerHistory.cs); web/API projects consume these layers via dependency injection and SimpleMediator for CQRS dispatch.

.NET enterprise developers and architects learning how to structure scalable, maintainable applications using domain-driven design and event sourcing; teams building multi-layer applications needing a proven reference architecture with separation of concerns; educators teaching advanced C# patterns.

Production-ready and actively maintained. The project has been continuously updated (latest v1.10 released April 2025 migrating to .NET 9.0), includes proper CI/CD via GitHub Actions (.github/workflows/dotnet-core.yml), uses Docker support (.dockerignore, Dockerfile), and demonstrates professional practices (EditorConfig, issue templates). Single maintainer (EduardoPires) but well-established with historical versions back to .NET 5.

Low risk for learning/reference use; moderate risk for production dependency. Maintained by a single primary author (maintainer concentration). Dependencies are standard ecosystem libraries (EF Core, NetDevPack, FluentValidator) kept current, but any architectural changes to the core layers would require careful migration. No visible automated test suite in file listing despite claiming 'tests' in architecture, which could indicate gaps in coverage validation.

Active maintenance focused on keeping pace with .NET releases. Most recent work (v1.10, April 2025): migrated to .NET 9.0, replaced MediatR with lighter NetDevPack.SimpleMediator, removed AutoMapper for manual mapping extensions, added Architecture Tests with NetArchTest.Rules, and implemented built-in SQLite support with automatic EF Core migrations for zero-config startup.

Clone and open in Visual Studio 2022+ with .NET 9 SDK: git clone https://github.com/EduardoPires/EquinoxProject.git && cd EquinoxProject && dotnet build && dotnet run. No npm/yarn needed (pure C# project). Database migrations auto-run via EF Core; SQLite is default (no external DB required out-of-box).

Daily commands: dotnet build Equinox.sln && dotnet run --project src/[web|api project]. Default runs with SQLite (auto-created). For SQL Server: modify connection string in appsettings.json. Swagger UI available at /swagger when running WebAPI project. Frontend (MVC) accessible via standard ASP.NET routing.

• src/Equinox.Domain/Models/Customer.cs — Core domain entity implementing DDD principles; all business logic and invariants flow through this aggregate root.
• src/Equinox.Domain/Commands/CustomerCommandHandler.cs — Primary command handler orchestrating CQRS pattern; processes all customer mutations and triggers domain events.
• src/Equinox.Infra.Data/EventSourcing/SqlEventStore.cs — Event sourcing persistence layer storing all domain events; critical for audit trail and event replay.
• src/Equinox.Infra.CrossCutting.IoC/NativeInjectorBootStrapper.cs — Dependency injection container configuration; wires all layers and sets up CQRS/event bus infrastructure.
• src/Equinox.Application/Services/CustomerAppService.cs — Application service layer orchestrating use cases; bridges API controllers with domain and infrastructure.
• src/Equinox.Infra.Data/Context/EquinoxContext.cs — Main EF Core DbContext managing customer aggregate; handles ORM mapping and database operations.
• src/Equinox.Infra.CrossCutting.Bus/InMemoryBus.cs — In-memory CQRS command and event bus implementation; enables decoupled communication between layers.

Add a New Domain Command and Handler

1. Create a new command class inheriting from CustomerCommand in the Commands folder (src/Equinox.Domain/Commands/MyNewCommand.cs)
2. Add validation rules using FluentValidation (src/Equinox.Domain/Commands/Validations/MyNewCommandValidation.cs)
3. Add handler method in CustomerCommandHandler to process the command (src/Equinox.Domain/Commands/CustomerCommandHandler.cs)
4. Create corresponding domain event class (src/Equinox.Domain/Events/MyNewEvent.cs)
5. Register command validation in NativeInjectorBootStrapper (src/Equinox.Infra.CrossCutting.IoC/NativeInjectorBootStrapper.cs)

Add a New Application Service Method

1. Define the public method signature in the interface (src/Equinox.Application/Interfaces/ICustomerAppService.cs)
2. Implement the method in CustomerAppService orchestrating commands and queries (src/Equinox.Application/Services/CustomerAppService.cs)
3. Create or update the ViewModel to represent the response (src/Equinox.Application/ViewModels/CustomerViewModel.cs)
4. Wire the new method in the API controller by injecting ICustomerAppService

Implement Event Sourcing for a New Aggregate

1. Create domain events for state changes in the Events folder (src/Equinox.Domain/Events/MyAggregateEvent.cs)
2. Create an event handler to process events and update read models (src/Equinox.Domain/Events/MyAggregateEventHandler.cs)
3. Create a denormalizer to rebuild aggregate state from events (src/Equinox.Application/EventSourcedNormalizers/MyAggregateHistory.cs)
4. Register event handlers in the IoC container (src/Equinox.Infra.CrossCutting.IoC/NativeInjectorBootStrapper.cs)

Add Database Schema Mapping for New Entity

1. Create mapping configuration using EF Core Fluent API (src/Equinox.Infra.Data/Mappings/MyEntityMap.cs)
2. Add DbSet property to EquinoxContext (src/Equinox.Infra.Data/Context/EquinoxContext.cs)
3. Create a new migration via dotnet ef migrations add YourMigrationName (src/Equinox.Infra.Data/Migrations/[YourMigrationName].cs)
4. Apply migration using dotnet ef database update

• ASP.NET Core 9 — Modern, high-performance framework with built-in dependency injection and middleware pipeline supporting CQRS patterns
• Entity Framework Core with SQLite — ORM abstraction enabling clean separation of domain from persistence; SQLite for lightweight development/testing
• CQRS (Command Query Responsibility Segregation) — Separates read and write operations enabling independent scaling and cleaner command validation logic
• Event Sourcing with SQL Event Store — Provides complete audit trail of all domain changes; enables event replay for rebuilding aggregate state and debugging
• Domain-Driven Design (DDD) — Structures business logic around domain aggregates (Customer) with explicit domain events and invariant validation
• FluentValidation — Declarative command validation rules keeping cross-cutting concerns out of aggregate logic
• ASP.NET Core Identity with JWT — Standard authentication and authorization framework with token-based stateless API security
• In-Memory Message Bus — Lightweight CQRS implementation for command/event distribution without external message broker dependencies

• In-memory CQRS bus instead of distributed message broker (RabbitMQ, Azure Service Bus)
  • Why: Simplifies initial implementation and reduces infrastructure complexity for educational project
  • Consequence: Cannot scale horizontally across multiple servers without refactoring to external bus;

EF Core migrations must be applied manually (dotnet ef database update) unless auto-run is explicitly configured in startup—SQLite auto-creates but SQL Server requires schema. SimpleMediator requires command/query handlers to inherit specific base classes (not obvious from interfaces alone). Event sourcing requires careful serialization of events (JSON by default); breaking event structure causes deserialization failures on replay. Customer aggregate is the only sample domain entity; extending to multi-aggregate scenarios requires understanding bounded context isolation not fully shown in examples. JWT secret in appsettings must be changed for production.

• Domain-Driven Design (DDD) — Equinox organizes code around business domain (Customer aggregate) with explicit boundaries; understanding Ubiquitous Language, aggregates, and bounded contexts is essential to extend the system meaningfully.
• CQRS (Command Query Responsibility Segregation) — Equinox separates write commands (CustomerCommandHandler) from read queries via SimpleMediator; critical for understanding the async flow and scaling read models independently.
• Event Sourcing — Instead of storing current state, Equinox persists immutable domain events (CustomerRegisteredEvent, CustomerUpdatedEvent) and rebuilds state by replaying; enables audit trails and temporal queries.
• Domain Events — Events like CustomerRegisteredEvent are first-class domain concepts in Equinox, not just infrastructure artifacts; they trigger side effects, projections, and enable loosely coupled communication between aggregates.
• Repository Pattern — Equinox abstracts data access via IEventStore and Repository, decoupling domain logic from persistence; essential for unit testing and switching between SQL Server and SQLite.
• Unit of Work Pattern — Equinox (via NetDevPack) groups multiple domain operations into a transaction context before commit; ensures consistency when multiple aggregates are affected.
• Read Model Denormalization (CQRS Projection) — CustomerHistory normalizer subscribes to domain events and maintains a flat, query-optimized read table; separates the shape of domain model (normalized event stream) from UI query needs.

• jasontaylordev/CleanArchitecture — Similar .NET 8+ Clean Architecture reference with CQRS but using MediatR and different aggregate patterns; good comparison for architectural decisions.
• NetDevPack/NetDevPack — Official NetDevPack library providing DDD, CQRS, Event Sourcing abstractions and SimpleMediator that Equinox depends on; essential for understanding the foundation.
• ardalis/CleanArchitecture — C# version of Robert Martin's Clean Architecture; complementary reference with ASP.NET Core but less event sourcing emphasis.
• vkhorikov/CqrsInPractice — Vladimir Khorikov's CQRS + Event Sourcing demo; different implementation approach for comparison and deeper learning.
• Microsoft/eShopOnContainers — Microsoft's microservices reference implementation; shows how patterns from Equinox scale to distributed systems with multiple bounded contexts.

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 CustomerCommandHandler and command validations

The repo implements CQRS pattern with CustomerCommand handlers and multiple validation classes (RegisterNewCustomerCommandValidation, UpdateCustomerCommandValidation, RemoveCustomerCommandValidation) but there's no visible test project. Testing command handlers and their validations is critical for a Clean Architecture reference project to demonstrate proper testing practices.

• [ ] Create Equinox.Domain.Tests project alongside src/Equinox.Domain
• [ ] Add unit tests for src/Equinox.Domain/Commands/CustomerCommandHandler.cs covering success and failure scenarios
• [ ] Add unit tests for all validation classes in src/Equinox.Domain/Commands/Validations/ to verify validation rules
• [ ] Add integration tests for event sourcing in src/Equinox.Domain/Events/CustomerEventHandler.cs
• [ ] Update Equinox.sln to include the new test project and reference it in CI workflow

Add GitHub Actions workflow for automated database schema validation

The project has sql/GenerateDataBase.sql but the existing .github/workflows/dotnet-core.yml doesn't include database schema validation. This is important for a DDD/Event Sourcing project to ensure database migrations are tested and documented.

• [ ] Enhance .github/workflows/dotnet-core.yml to add a SQL Server service container for integration tests
• [ ] Create a new workflow step that runs sql/GenerateDataBase.sql against the test database
• [ ] Add validation that generated schema matches expected event store tables for Event Sourcing
• [ ] Document in a new docs/Database-Setup.md how database migrations are tested in CI

Create EventSourcingNormalizers projection tests and add missing repository pattern tests

The project demonstrates Event Sourcing with src/Equinox.Application/EventSourcedNormalizers (CustomerHistory.cs) but there are no visible tests for how events are projected into read models. Additionally, the ICustomerRepository interface has no visible test doubles or mock implementations documented.

• [ ] Create Equinox.Application.Tests project with unit tests for src/Equinox.Application/EventSourcedNormalizers/CustomerHistory.cs
• [ ] Add tests verifying that domain events (CustomerRegisteredEvent, CustomerUpdatedEvent, CustomerRemovedEvent) correctly project into CustomerHistoryData view models
• [ ] Create mock implementations of ICustomerRepository in test helpers for testing application services
• [ ] Add integration tests for src/Equinox.Application/Services/CustomerAppService.cs with both commands and queries
• [ ] Document patterns in docs/Testing-Strategy.md explaining how to test CQRS and Event Sourcing layers

• Add unit tests for domain validation rules: Create xUnit tests in a new src/Equinox.Tests project covering src/Equinox.Domain/Commands/Validations/RegisterNewCustomerCommandValidation.cs to ensure all FluentValidator rules are covered.
• Extend domain: Implement an Address aggregate with commands (CreateAddress, UpdateAddress) and events (AddressCreatedEvent, AddressUpdatedEvent) following the Customer pattern, including domain validations and app service methods.
• Document CQRS flow: Create a markdown file in docs/ explaining the path from HTTP POST → RegisterNewCustomerCommand → CustomerCommandHandler → CustomerRegisteredEvent → CustomerHistory normalizer with code examples.

• High · JWT Secret Management Not Visible in Analysis — src/Equinox.Infra.CrossCutting.Identity/API/AppJwtSettings.cs. The JWT settings file (AppJwtSettings.cs) is present but the actual secret key management strategy is not apparent. JWT secrets must be stored securely in environment variables or secure vaults, not hardcoded in configuration files or appsettings.json. Fix: Ensure JWT secrets are stored in Azure Key Vault, AWS Secrets Manager, or secure environment variables. Never commit secrets to version control. Implement IConfiguration to load from secure sources only.
• High · Custom Authorization Attribute Security — src/Equinox.Infra.CrossCutting.Identity/Authorization/CustomAuthorizeAttribute.cs. Custom authorization implementations (CustomAuthorizeAttribute.cs, CustomAuthorizationValidation.cs) may not properly validate all security contexts. Custom authorization code is prone to bypass vulnerabilities if not implementing standard ASP.NET Core authorization patterns correctly. Fix: Replace custom authorization with built-in ASP.NET Core authorization policies. Audit existing custom implementation for bypass vulnerabilities. Use [Authorize] with policy-based authorization instead of custom attributes.
• High · In-Memory Bus Without Persistence — src/Equinox.Infra.CrossCutting.Bus/InMemoryBus.cs. The InMemoryBus implementation does not persist messages. In case of application crash, all pending commands and events will be lost, potentially causing data inconsistency in an event-sourced system. Fix: Implement a persistent message bus (RabbitMQ, MassTransit, NServiceBus, or Azure Service Bus) for production environments. Use in-memory bus only for development/testing.
• Medium · SQL Injection Risk in Database Generation Script — sql/GenerateDataBase.sql. Raw SQL script file (GenerateDataBase.sql) is present in the repository. If this script accepts parameters from user input without proper parameterization, SQL injection vulnerabilities may exist. Fix: Use Entity Framework Core migrations instead of raw SQL scripts. If raw SQL is necessary, use parameterized queries exclusively. Never concatenate user input into SQL queries.
• Medium · Missing CORS Configuration Visibility — Configuration not visible in file structure. No CORS configuration file is visible in the analyzed structure. If CORS is not properly configured in the API setup, it could either be overly permissive or cause functionality issues. Fix: Explicitly configure CORS in Program.cs with specific allowed origins, methods, and headers. Never use '*' for origins in production. Use builder.Services.AddCors() with restrictive policies.
• Medium · No Visible Input Validation Framework — src/Equinox.Domain/Commands/Validations/. While validation classes exist (RegisterNewCustomerCommandValidation.cs, etc.), the enforcement mechanism across all API endpoints is not evident. Validation bypass is possible if not applied globally. Fix: Implement global validation middleware using FluentValidation behavior pipeline. Register validators in dependency injection container and enforce at the application service layer. Add API input model validation attributes.
• Medium · Event Store Access Control Not Evident — src/Equinox.Domain.Core/Events/IEventStore.cs. IEventStore interface is defined but authorization checks on event access are not visible. This could allow unauthorized users to read sensitive event history. Fix: Implement authorization checks before accessing event store. Ensure events contain no sensitive information or implement field-level encryption. Add audit logging for all event store accesses.
• Medium · Identity Database Using SQLite in Production — src/Equinox.Infra.CrossCutting.Identity/Migrations/20250408033115_SQLite.cs. Migration files reference SQLite (20250408033115_SQLite.cs). SQLite is not suitable for production multi-user applications and lacks enterprise security features. Fix: Use SQL Server, PostgreSQL, or other enterprise databases for production. Configure separate database providers for development and production environments using environment-specific connection strings.
• Low · Missing Security Headers Configuration — undefined. No visible middleware configuration for security headers (X-Content- 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.