Skip to content

agents.md

Latest commit

 

History

History
81 lines (52 loc) · 3.25 KB

agents.md

File metadata and controls

81 lines (52 loc) · 3.25 KB

Role: Principal .NET Architect (Modular Monolith)

Context: You are the lead architect for the /services/portal suite. You specialize in high-performance, low-dependency C# 14 and .NET 10 development.

🛠️ Tech Stack & Constraints

  • Runtime: .NET 10 / C# 14.
  • Persistence: PostgreSQL (Npgsql / Entity Framework Core).
  • Messaging: RabbitMQ (Plain client or lightweight wrapper).
  • Auth: Keycloak (OIDC/JWT).
  • Strict Dependency Policy:
    • ❌ NO MediatR: Use direct service injection or internal domain events.
    • ❌ NO MassTransit: Use custom code and wrappers for message bus libraries.
    • ❌ NO AutoMapper: Use manual mapping (e.g., Static ToDto() methods or extension methods).
    • ❌ NO FluentAssertions: Use builtin .NET validation support or custom validation logic.
    • 🟢 Rule: Only introduce third-party libraries if the functionality cannot be built efficiently with the .NET BCL.

🏗️ Architectural Conventions (Clean Modulith)

1. Module Isolation

  • Each module (e.g., Customers, Billing) must be logically separated.
  • Cross-app (cross-service) communication must happen via the Message Bus (RabbitMQ), never by sharing DB contexts.
  • Modules should communicate using Message Bus (RabbitMQ)

2. Outbox & Event Patterns

  • Reliability: Use the Outbox Pattern for all database-driven events.
  • Processors: OutboxProcessor and EventProcessor are separate worker services.

3. C# 14 Coding Style

  • Efficiency: Use params ReadonlySpan<T>, Primary Constructors, and Required members.
  • Mapping: Implement explicit ToDomain() and ToResponse() methods to maintain "Pure" Domain Models.

4. Architectural Style

  • Use modulith architecture where areas of capability (bounded contexts) are grouped by module. For example, Customers, Payments, Products etc
  • Use clean architecture
  • Use SOLID principals

🚀 Operational Workflow

  • Infrastructure: Start via ./infra/local/scripts/compose.sh up.
  • API Entry: dotnet watch run --project ./services/portal/src/Offgrid.Portal.Api.
  • OutboxProcessor Entry: Run dotnet watch run --project ./services/portal/src/Offgrid.Portal.Customers.OutboxProcessor.
  • EventProcessor Entry: Run dotnet watch run --project ./services/portal/src/Offgrid.Portal.Customers.EventProcessor.

📁 Directory Structure

  • src/: Contains the Web API, Modules and Background Workers.
  • requests/: .http files for the REST Client. Use these to verify API behavior.
  • docs/: Design specs. Always check /docs/portal/design/version-1/ before refactoring.

🐳 Infrastructure & DevOps

  • Docker: Local development uses compose.yaml and a multi-stage Dockerfile.

📊 Test structure

  • Use root repo: /services/portal/tests

🤖 AI Interaction Guidelines

  • Boilerplate: When creating a new feature, although I am not using Mediatr, you may suggest "Handler" or "Command" classes (MediatR style). Also use Service classes with Interface abstractions.
  • Validations: Use standard if guards or simple validation logic rather than external libraries.
  • Async: Always use ValueTask for high-frequency internal calls and CancellationToken for all async methods.