{"owner":"ardalis","repo":"CleanArchitecture","hasSkills":true,"totalSkillsCount":2,"totalTokensCount":2036,"categories":["copilot-instructions"],"hasMcp":false,"mcpConfig":null,"found":["sample/.github/copilot-instructions.md",".github/copilot-instructions.md"],"skills":{"sample/.github/copilot-instructions.md":"# Solution Development Practices & Conventions\n\nThis document provides guidance for contributing to this solution, which is based on the Clean Architecture template for .NET 9. Follow these practices to ensure consistency, maintainability, and adherence to architectural principles.\n\n---\n\n## Table of Contents\n\n- [Architecture Overview](#architecture-overview)\n- [Project Structure](#project-structure)\n- [Development Patterns](#development-patterns)\n- [Use Case Guidelines](#use-case-guidelines)\n- [API Endpoint Conventions](#api-endpoint-conventions)\n- [Validation Strategy](#validation-strategy)\n- [Testing](#testing)\n- [File & Naming Conventions](#file--naming-conventions)\n- [Common Gotchas](#common-gotchas)\n- [Essential Commands](#essential-commands)\n\n---\n\n## Architecture Overview\n\n- Follows Clean Architecture and Domain-Driven Design (DDD) principles.\n- **Core** project contains domain models, value objects, and repository interfaces.\n- **UseCases** project contains application logic, commands, queries, and handlers.\n- **Infrastructure** project implements data access and external services.\n- **Web** project exposes API endpoints using FastEndpoints.\n\n**Dependency Flow:**  \n`Core` ← `UseCases` ← `Infrastructure`  \n`Core` ← `UseCases` ← `Web`  \n_Core must never depend on outer layers._\n\n---\n\n## Project Structure\n\n- **Core**: Domain entities, aggregates, value objects, domain events, repository interfaces.\n- **UseCases**: CQRS handlers (commands/queries), Mediator, application logic.\n- **Infrastructure**: EF Core, external services, repository implementations.\n- **Web**: FastEndpoints API, request/response/validator classes, REPR pattern.\n\n---\n\n## Development Patterns\n\n- **CQRS**: Use commands for mutations and queries for reads.\n- **Mediator**: All use case handlers implement Mediator interfaces.\n- **Repository Pattern**: Use repository interfaces from Core, implemented in Infrastructure.\n- **Value Objects**: Use for domain concepts (e.g., `ProjectName`, `ContributorId`).\n- **Domain Events**: Use for cross-aggregate communication.\n\n---\n\n## Use Case Guidelines\n\n- **Inputs/Outputs**: Use Value Objects (`ProjectName`, `ContributorId`) for use case command/query parameters and return types. Use value objects internally within the domain. Translate from primitives in the endpoints.\n- **Validation**: Validate at API and use case boundaries; enforce business invariants in the domain.\n- **Error Handling**: Use `Ardalis.Result<T>` for use case results and error propagation.\n- **Defensive Coding**: Validate commands/queries in handlers; assume pre-validated input in domain. Use `Ardalis.GuardClauses` to defend against invalid states in the domain.\n\n---\n\n## API Endpoint Conventions\n\n- One endpoint per file (e.g., `Create.cs`, `Update.cs`).\n- Separate files for request, response, and validator (e.g., `Create.CreateRequest.cs`, `Create.CreateResponse.cs`, `Create.CreateValidator.cs`).\n- Endpoints inherit from `Endpoint<TRequest, TResponse>`.\n- Use REPR (Request/Endpoint/Processor/Response) pattern.\n\n---\n\n## Validation Strategy\n\n- **API Level**: Use FluentValidation for request DTOs.\n- **Use Case Level**: Validate commands/queries in handlers or behaviors.\n- **Domain Level**: Throw exceptions for business rule violations using guard clauses (e.g., `Ardalis.GuardClauses`).)\n\n---\n\n## Testing\n\n- **UnitTests**: Test domain logic and use cases.\n- **IntegrationTests**: Test infrastructure and database interactions.\n- **FunctionalTests**: Test API endpoints using subcutaneous testing.\n\n---\n\n## File & Naming Conventions\n\n- Use PascalCase for files, classes, and methods.\n- Organize files by feature (e.g., `Contributors/Create.cs`, `Projects/Create.cs`).\n- Place request, response, and validator files alongside their endpoint.\n- Do not use hyphens in project or file names.\n- Test classes are named for the class and method being tested. Examples: `ProjectAddItem` or `CreateContributorHandlerHandle`.\n- Test methods are named such that the class name and method name form a sentence describing the test. (e.g. `ReturnsItemGivenValidInputs()` or `ThrowsExceptionGivenNegativeInput()`)\n\n---\n\n## Common Gotchas\n\n- Do not allow Core to reference UseCases, Infrastructure, or Web.\n- Use absolute paths for EF Core migration commands.\n",".github/copilot-instructions.md":"# GitHub Copilot Instructions for Clean Architecture Template\n\n## Project Overview\nThis is a **Clean Architecture template** for .NET 9 that demonstrates Domain-Driven Design (DDD) patterns. It's a starter template, not a reference application - delete sample code once you understand the patterns.\n\n## Architecture & Project Structure\n\n### C# Conventions\n- Use standard Microsoft naming conventions\n- Use `PascalCase` for types and methods, `camelCase` for parameters and private fields\n- Use `I` prefix for interfaces (e.g., `IRepository`)\n- Use `Async` suffix for async methods (e.g., `GetByIdAsync`)\n- Prefix private fields with `_` (e.g., `_repository`)\n- Always use {} for blocks except single-line exits (e.g. `return`, `throw`)\n- Always keep single line blocks on one line (e.g., `if (x) return y;`)\n- Prefer primary constructors for required dependencies\n- Never use primary constructor parameters directly - always assign to private fields for clarity and testability\n\n### Core Dependencies Flow\n- **Core** ← UseCases ← Infrastructure \n- **Core** ← UseCases ← Web\n- Never allow Core to depend on outer layers\n\n### Key Projects\n- **Core**: Domain entities, aggregates, value objects, specifications, interfaces\n- **UseCases**: Commands/queries (CQRS), Mediator handlers, application logic  \n- **Infrastructure**: EF Core, external services, email, file access\n- **Web**: FastEndpoints API, REPR pattern, validation\n\n## Development Patterns\n\n### API Endpoints (FastEndpoints + REPR)\n- One endpoint per file: `Create.cs`, `Update.cs`, `Delete.cs`, `GetById.cs`\n- Separate request/response/validator files: `Create.CreateRequest.cs`, `Create.CreateValidator.cs`\n- Use `Endpoint<TRequest, TResponse>` base class\n- Example: `src/Clean.Architecture.Web/Contributors/Create.cs`\n\n### Domain Model (Core)\n- Entities use encapsulation - minimize public setters\n- Group related entities into Aggregates\n- Use Value Objects (e.g., `ContributorName.From()`)\n- Domain Events for cross-aggregate communication\n- Repository interfaces defined in Core, implemented in Infrastructure\n\n### Use Cases (CQRS)\n- Commands for mutations, Queries for reads\n- Queries can bypass repository pattern for performance\n- Use Mediator (source generator) for command/query handling\n- Chain of responsibility for cross-cutting concerns (logging, validation)\n\n### Validation Strategy\n- **API Level**: FluentValidation on request DTOs (FastEndpoints integration)\n- **Use Case Level**: Validate commands/queries (defensive coding)\n- **Domain Level**: Business invariants throw exceptions, assume pre-validated input\n\n## Essential Commands\n\n### Build & Test\n```bash\ndotnet build Clean.Architecture.slnx\ndotnet test Clean.Architecture.slnx\n```\n\n### Entity Framework Migrations\n```bash\n# From Web project directory\ndotnet ef migrations add MigrationName -c AppDbContext -p ../Clean.Architecture.Infrastructure/Clean.Architecture.Infrastructure.csproj -s Clean.Architecture.Web.csproj -o Data/Migrations\n\ndotnet ef database update -c AppDbContext -p ../Clean.Architecture.Infrastructure/Clean.Architecture.Infrastructure.csproj -s Clean.Architecture.Web.csproj\n```\n\n### Template Installation & Usage\n```bash\ndotnet new install Ardalis.CleanArchitecture.Template\ndotnet new clean-arch -o Your.ProjectName\n```\n\n## Key Dependencies & Patterns\n\n### Primary Libraries\n- **FastEndpoints**: API endpoints (replaced Controllers/Minimal APIs)\n- **Mediator**: Command/query handling in UseCases\n- **EF Core**: Data access (SQLite default, easily changed to SQL Server)\n- **Ardalis.Specification**: Repository query specifications\n- **Ardalis.Result**: Error handling pattern\n- **Serilog**: Structured logging\n\n### Central Package Management\n- All package versions in `Directory.Packages.props`\n- Use `<PackageReference Include=\"...\" />` without Version attribute\n\n### Test Organization\n- **UnitTests**: Core business logic, use cases\n- **IntegrationTests**: Database, infrastructure components  \n- **FunctionalTests**: API endpoints (subcutaneous testing)\n- Use `Microsoft.AspNetCore.Mvc.Testing` for API tests\n\n## File Organization Conventions\n\n### Web Project Structure\n```\nContributors/\n  Create.cs                    # Endpoint\n  Create.CreateRequest.cs      # Request DTO\n  Create.CreateResponse.cs     # Response DTO  \n  Create.CreateValidator.cs    # FluentValidation\n  Update.cs, Delete.cs, etc.\n```\n\n### Sample vs Template\n- `/sample` folder: Complete working example (NimblePros.SampleToDo)\n- `/src` folder: Clean template ready for your project\n- Study sample for patterns, use src for new projects\n\n## Common Gotchas\n\n- Don't include hyphens in project names (template limitation)\n- Replace `Ardalis.SharedKernel` with your own shared kernel\n- Database path in `appsettings.json` for SQLite\n- Use absolute paths in EF migration commands\n- FastEndpoints uses different validation approach than Controller-based APIs\n\n## VS Code Tasks\nUse the predefined tasks: `build`, `publish`, `watch` instead of manual `dotnet` commands when possible.\n"},"files":{"sample/.github/copilot-instructions.md":"# Solution Development Practices & Conventions\n\nThis document provides guidance for contributing to this solution, which is based on the Clean Architecture template for .NET 9. Follow these practices to ensure consistency, maintainability, and adherence to architectural principles.\n\n---\n\n## Table of Contents\n\n- [Architecture Overview](#architecture-overview)\n- [Project Structure](#project-structure)\n- [Development Patterns](#development-patterns)\n- [Use Case Guidelines](#use-case-guidelines)\n- [API Endpoint Conventions](#api-endpoint-conventions)\n- [Validation Strategy](#validation-strategy)\n- [Testing](#testing)\n- [File & Naming Conventions](#file--naming-conventions)\n- [Common Gotchas](#common-gotchas)\n- [Essential Commands](#essential-commands)\n\n---\n\n## Architecture Overview\n\n- Follows Clean Architecture and Domain-Driven Design (DDD) principles.\n- **Core** project contains domain models, value objects, and repository interfaces.\n- **UseCases** project contains application logic, commands, queries, and handlers.\n- **Infrastructure** project implements data access and external services.\n- **Web** project exposes API endpoints using FastEndpoints.\n\n**Dependency Flow:**  \n`Core` ← `UseCases` ← `Infrastructure`  \n`Core` ← `UseCases` ← `Web`  \n_Core must never depend on outer layers._\n\n---\n\n## Project Structure\n\n- **Core**: Domain entities, aggregates, value objects, domain events, repository interfaces.\n- **UseCases**: CQRS handlers (commands/queries), Mediator, application logic.\n- **Infrastructure**: EF Core, external services, repository implementations.\n- **Web**: FastEndpoints API, request/response/validator classes, REPR pattern.\n\n---\n\n## Development Patterns\n\n- **CQRS**: Use commands for mutations and queries for reads.\n- **Mediator**: All use case handlers implement Mediator interfaces.\n- **Repository Pattern**: Use repository interfaces from Core, implemented in Infrastructure.\n- **Value Objects**: Use for domain concepts (e.g., `ProjectName`, `ContributorId`).\n- **Domain Events**: Use for cross-aggregate communication.\n\n---\n\n## Use Case Guidelines\n\n- **Inputs/Outputs**: Use Value Objects (`ProjectName`, `ContributorId`) for use case command/query parameters and return types. Use value objects internally within the domain. Translate from primitives in the endpoints.\n- **Validation**: Validate at API and use case boundaries; enforce business invariants in the domain.\n- **Error Handling**: Use `Ardalis.Result<T>` for use case results and error propagation.\n- **Defensive Coding**: Validate commands/queries in handlers; assume pre-validated input in domain. Use `Ardalis.GuardClauses` to defend against invalid states in the domain.\n\n---\n\n## API Endpoint Conventions\n\n- One endpoint per file (e.g., `Create.cs`, `Update.cs`).\n- Separate files for request, response, and validator (e.g., `Create.CreateRequest.cs`, `Create.CreateResponse.cs`, `Create.CreateValidator.cs`).\n- Endpoints inherit from `Endpoint<TRequest, TResponse>`.\n- Use REPR (Request/Endpoint/Processor/Response) pattern.\n\n---\n\n## Validation Strategy\n\n- **API Level**: Use FluentValidation for request DTOs.\n- **Use Case Level**: Validate commands/queries in handlers or behaviors.\n- **Domain Level**: Throw exceptions for business rule violations using guard clauses (e.g., `Ardalis.GuardClauses`).)\n\n---\n\n## Testing\n\n- **UnitTests**: Test domain logic and use cases.\n- **IntegrationTests**: Test infrastructure and database interactions.\n- **FunctionalTests**: Test API endpoints using subcutaneous testing.\n\n---\n\n## File & Naming Conventions\n\n- Use PascalCase for files, classes, and methods.\n- Organize files by feature (e.g., `Contributors/Create.cs`, `Projects/Create.cs`).\n- Place request, response, and validator files alongside their endpoint.\n- Do not use hyphens in project or file names.\n- Test classes are named for the class and method being tested. Examples: `ProjectAddItem` or `CreateContributorHandlerHandle`.\n- Test methods are named such that the class name and method name form a sentence describing the test. (e.g. `ReturnsItemGivenValidInputs()` or `ThrowsExceptionGivenNegativeInput()`)\n\n---\n\n## Common Gotchas\n\n- Do not allow Core to reference UseCases, Infrastructure, or Web.\n- Use absolute paths for EF Core migration commands.\n",".github/copilot-instructions.md":"# GitHub Copilot Instructions for Clean Architecture Template\n\n## Project Overview\nThis is a **Clean Architecture template** for .NET 9 that demonstrates Domain-Driven Design (DDD) patterns. It's a starter template, not a reference application - delete sample code once you understand the patterns.\n\n## Architecture & Project Structure\n\n### C# Conventions\n- Use standard Microsoft naming conventions\n- Use `PascalCase` for types and methods, `camelCase` for parameters and private fields\n- Use `I` prefix for interfaces (e.g., `IRepository`)\n- Use `Async` suffix for async methods (e.g., `GetByIdAsync`)\n- Prefix private fields with `_` (e.g., `_repository`)\n- Always use {} for blocks except single-line exits (e.g. `return`, `throw`)\n- Always keep single line blocks on one line (e.g., `if (x) return y;`)\n- Prefer primary constructors for required dependencies\n- Never use primary constructor parameters directly - always assign to private fields for clarity and testability\n\n### Core Dependencies Flow\n- **Core** ← UseCases ← Infrastructure \n- **Core** ← UseCases ← Web\n- Never allow Core to depend on outer layers\n\n### Key Projects\n- **Core**: Domain entities, aggregates, value objects, specifications, interfaces\n- **UseCases**: Commands/queries (CQRS), Mediator handlers, application logic  \n- **Infrastructure**: EF Core, external services, email, file access\n- **Web**: FastEndpoints API, REPR pattern, validation\n\n## Development Patterns\n\n### API Endpoints (FastEndpoints + REPR)\n- One endpoint per file: `Create.cs`, `Update.cs`, `Delete.cs`, `GetById.cs`\n- Separate request/response/validator files: `Create.CreateRequest.cs`, `Create.CreateValidator.cs`\n- Use `Endpoint<TRequest, TResponse>` base class\n- Example: `src/Clean.Architecture.Web/Contributors/Create.cs`\n\n### Domain Model (Core)\n- Entities use encapsulation - minimize public setters\n- Group related entities into Aggregates\n- Use Value Objects (e.g., `ContributorName.From()`)\n- Domain Events for cross-aggregate communication\n- Repository interfaces defined in Core, implemented in Infrastructure\n\n### Use Cases (CQRS)\n- Commands for mutations, Queries for reads\n- Queries can bypass repository pattern for performance\n- Use Mediator (source generator) for command/query handling\n- Chain of responsibility for cross-cutting concerns (logging, validation)\n\n### Validation Strategy\n- **API Level**: FluentValidation on request DTOs (FastEndpoints integration)\n- **Use Case Level**: Validate commands/queries (defensive coding)\n- **Domain Level**: Business invariants throw exceptions, assume pre-validated input\n\n## Essential Commands\n\n### Build & Test\n```bash\ndotnet build Clean.Architecture.slnx\ndotnet test Clean.Architecture.slnx\n```\n\n### Entity Framework Migrations\n```bash\n# From Web project directory\ndotnet ef migrations add MigrationName -c AppDbContext -p ../Clean.Architecture.Infrastructure/Clean.Architecture.Infrastructure.csproj -s Clean.Architecture.Web.csproj -o Data/Migrations\n\ndotnet ef database update -c AppDbContext -p ../Clean.Architecture.Infrastructure/Clean.Architecture.Infrastructure.csproj -s Clean.Architecture.Web.csproj\n```\n\n### Template Installation & Usage\n```bash\ndotnet new install Ardalis.CleanArchitecture.Template\ndotnet new clean-arch -o Your.ProjectName\n```\n\n## Key Dependencies & Patterns\n\n### Primary Libraries\n- **FastEndpoints**: API endpoints (replaced Controllers/Minimal APIs)\n- **Mediator**: Command/query handling in UseCases\n- **EF Core**: Data access (SQLite default, easily changed to SQL Server)\n- **Ardalis.Specification**: Repository query specifications\n- **Ardalis.Result**: Error handling pattern\n- **Serilog**: Structured logging\n\n### Central Package Management\n- All package versions in `Directory.Packages.props`\n- Use `<PackageReference Include=\"...\" />` without Version attribute\n\n### Test Organization\n- **UnitTests**: Core business logic, use cases\n- **IntegrationTests**: Database, infrastructure components  \n- **FunctionalTests**: API endpoints (subcutaneous testing)\n- Use `Microsoft.AspNetCore.Mvc.Testing` for API tests\n\n## File Organization Conventions\n\n### Web Project Structure\n```\nContributors/\n  Create.cs                    # Endpoint\n  Create.CreateRequest.cs      # Request DTO\n  Create.CreateResponse.cs     # Response DTO  \n  Create.CreateValidator.cs    # FluentValidation\n  Update.cs, Delete.cs, etc.\n```\n\n### Sample vs Template\n- `/sample` folder: Complete working example (NimblePros.SampleToDo)\n- `/src` folder: Clean template ready for your project\n- Study sample for patterns, use src for new projects\n\n## Common Gotchas\n\n- Don't include hyphens in project names (template limitation)\n- Replace `Ardalis.SharedKernel` with your own shared kernel\n- Database path in `appsettings.json` for SQLite\n- Use absolute paths in EF migration commands\n- FastEndpoints uses different validation approach than Controller-based APIs\n\n## VS Code Tasks\nUse the predefined tasks: `build`, `publish`, `watch` instead of manual `dotnet` commands when possible.\n"},"items":[{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/ardalis/CleanArchitecture/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"# GitHub Copilot Instructions for Clean Architecture Template\n\n## Project Overview\nThis is a **Clean Architecture template** for .NET 9 that demonstrates Domain-Driven Design (DDD) patterns. It's a starter template, not a reference application - delete sample code once you understand the patterns.\n\n## Architecture & Project Structure\n\n### C# Conventions\n- Use standard Microsoft naming conventions\n- Use `PascalCase` for types and methods, `camelCase` for parameters and private fields\n- Use `I` prefix for interfaces (e.g., `IRepository`)\n- Use `Async` suffix for async methods (e.g., `GetByIdAsync`)\n- Prefix private fields with `_` (e.g., `_repository`)\n- Always use {} for blocks except single-line exits (e.g. `return`, `throw`)\n- Always keep single line blocks on one line (e.g., `if (x) return y;`)\n- Prefer primary constructors for required dependencies\n- Never use primary constructor parameters directly - always assign to private fields for clarity and testability\n\n### Core Dependencies Flow\n- **Core** ← UseCases ← Infrastructure \n- **Core** ← UseCases ← Web\n- Never allow Core to depend on outer layers\n\n### Key Projects\n- **Core**: Domain entities, aggregates, value objects, specifications, interfaces\n- **UseCases**: Commands/queries (CQRS), Mediator handlers, application logic  \n- **Infrastructure**: EF Core, external services, email, file access\n- **Web**: FastEndpoints API, REPR pattern, validation\n\n## Development Patterns\n\n### API Endpoints (FastEndpoints + REPR)\n- One endpoint per file: `Create.cs`, `Update.cs`, `Delete.cs`, `GetById.cs`\n- Separate request/response/validator files: `Create.CreateRequest.cs`, `Create.CreateValidator.cs`\n- Use `Endpoint<TRequest, TResponse>` base class\n- Example: `src/Clean.Architecture.Web/Contributors/Create.cs`\n\n### Domain Model (Core)\n- Entities use encapsulation - minimize public setters\n- Group related entities into Aggregates\n- Use Value Objects (e.g., `ContributorName.From()`)\n- Domain Events for cross-aggregate communication\n- Repository interfaces defined in Core, implemented in Infrastructure\n\n### Use Cases (CQRS)\n- Commands for mutations, Queries for reads\n- Queries can bypass repository pattern for performance\n- Use Mediator (source generator) for command/query handling\n- Chain of responsibility for cross-cutting concerns (logging, validation)\n\n### Validation Strategy\n- **API Level**: FluentValidation on request DTOs (FastEndpoints integration)\n- **Use Case Level**: Validate commands/queries (defensive coding)\n- **Domain Level**: Business invariants throw exceptions, assume pre-validated input\n\n## Essential Commands\n\n### Build & Test\n```bash\ndotnet build Clean.Architecture.slnx\ndotnet test Clean.Architecture.slnx\n```\n\n### Entity Framework Migrations\n```bash\n# From Web project directory\ndotnet ef migrations add MigrationName -c AppDbContext -p ../Clean.Architecture.Infrastructure/Clean.Architecture.Infrastructure.csproj -s Clean.Architecture.Web.csproj -o Data/Migrations\n\ndotnet ef database update -c AppDbContext -p ../Clean.Architecture.Infrastructure/Clean.Architecture.Infrastructure.csproj -s Clean.Architecture.Web.csproj\n```\n\n### Template Installation & Usage\n```bash\ndotnet new install Ardalis.CleanArchitecture.Template\ndotnet new clean-arch -o Your.ProjectName\n```\n\n## Key Dependencies & Patterns\n\n### Primary Libraries\n- **FastEndpoints**: API endpoints (replaced Controllers/Minimal APIs)\n- **Mediator**: Command/query handling in UseCases\n- **EF Core**: Data access (SQLite default, easily changed to SQL Server)\n- **Ardalis.Specification**: Repository query specifications\n- **Ardalis.Result**: Error handling pattern\n- **Serilog**: Structured logging\n\n### Central Package Management\n- All package versions in `Directory.Packages.props`\n- Use `<PackageReference Include=\"...\" />` without Version attribute\n\n### Test Organization\n- **UnitTests**: Core business logic, use cases\n- **IntegrationTests**: Database, infrastructure components  \n- **FunctionalTests**: API endpoints (subcutaneous testing)\n- Use `Microsoft.AspNetCore.Mvc.Testing` for API tests\n\n## File Organization Conventions\n\n### Web Project Structure\n```\nContributors/\n  Create.cs                    # Endpoint\n  Create.CreateRequest.cs      # Request DTO\n  Create.CreateResponse.cs     # Response DTO  \n  Create.CreateValidator.cs    # FluentValidation\n  Update.cs, Delete.cs, etc.\n```\n\n### Sample vs Template\n- `/sample` folder: Complete working example (NimblePros.SampleToDo)\n- `/src` folder: Clean template ready for your project\n- Study sample for patterns, use src for new projects\n\n## Common Gotchas\n\n- Don't include hyphens in project names (template limitation)\n- Replace `Ardalis.SharedKernel` with your own shared kernel\n- Database path in `appsettings.json` for SQLite\n- Use absolute paths in EF migration commands\n- FastEndpoints uses different validation approach than Controller-based APIs\n\n## VS Code Tasks\nUse the predefined tasks: `build`, `publish`, `watch` instead of manual `dotnet` commands when possible.\n","isInternal":false,"tokens":1111,"sizeBytes":5016},{"name":"copilot-instructions.md","path":"sample/.github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/ardalis/CleanArchitecture/HEAD/sample/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"# Solution Development Practices & Conventions\n\nThis document provides guidance for contributing to this solution, which is based on the Clean Architecture template for .NET 9. Follow these practices to ensure consistency, maintainability, and adherence to architectural principles.\n\n---\n\n## Table of Contents\n\n- [Architecture Overview](#architecture-overview)\n- [Project Structure](#project-structure)\n- [Development Patterns](#development-patterns)\n- [Use Case Guidelines](#use-case-guidelines)\n- [API Endpoint Conventions](#api-endpoint-conventions)\n- [Validation Strategy](#validation-strategy)\n- [Testing](#testing)\n- [File & Naming Conventions](#file--naming-conventions)\n- [Common Gotchas](#common-gotchas)\n- [Essential Commands](#essential-commands)\n\n---\n\n## Architecture Overview\n\n- Follows Clean Architecture and Domain-Driven Design (DDD) principles.\n- **Core** project contains domain models, value objects, and repository interfaces.\n- **UseCases** project contains application logic, commands, queries, and handlers.\n- **Infrastructure** project implements data access and external services.\n- **Web** project exposes API endpoints using FastEndpoints.\n\n**Dependency Flow:**  \n`Core` ← `UseCases` ← `Infrastructure`  \n`Core` ← `UseCases` ← `Web`  \n_Core must never depend on outer layers._\n\n---\n\n## Project Structure\n\n- **Core**: Domain entities, aggregates, value objects, domain events, repository interfaces.\n- **UseCases**: CQRS handlers (commands/queries), Mediator, application logic.\n- **Infrastructure**: EF Core, external services, repository implementations.\n- **Web**: FastEndpoints API, request/response/validator classes, REPR pattern.\n\n---\n\n## Development Patterns\n\n- **CQRS**: Use commands for mutations and queries for reads.\n- **Mediator**: All use case handlers implement Mediator interfaces.\n- **Repository Pattern**: Use repository interfaces from Core, implemented in Infrastructure.\n- **Value Objects**: Use for domain concepts (e.g., `ProjectName`, `ContributorId`).\n- **Domain Events**: Use for cross-aggregate communication.\n\n---\n\n## Use Case Guidelines\n\n- **Inputs/Outputs**: Use Value Objects (`ProjectName`, `ContributorId`) for use case command/query parameters and return types. Use value objects internally within the domain. Translate from primitives in the endpoints.\n- **Validation**: Validate at API and use case boundaries; enforce business invariants in the domain.\n- **Error Handling**: Use `Ardalis.Result<T>` for use case results and error propagation.\n- **Defensive Coding**: Validate commands/queries in handlers; assume pre-validated input in domain. Use `Ardalis.GuardClauses` to defend against invalid states in the domain.\n\n---\n\n## API Endpoint Conventions\n\n- One endpoint per file (e.g., `Create.cs`, `Update.cs`).\n- Separate files for request, response, and validator (e.g., `Create.CreateRequest.cs`, `Create.CreateResponse.cs`, `Create.CreateValidator.cs`).\n- Endpoints inherit from `Endpoint<TRequest, TResponse>`.\n- Use REPR (Request/Endpoint/Processor/Response) pattern.\n\n---\n\n## Validation Strategy\n\n- **API Level**: Use FluentValidation for request DTOs.\n- **Use Case Level**: Validate commands/queries in handlers or behaviors.\n- **Domain Level**: Throw exceptions for business rule violations using guard clauses (e.g., `Ardalis.GuardClauses`).)\n\n---\n\n## Testing\n\n- **UnitTests**: Test domain logic and use cases.\n- **IntegrationTests**: Test infrastructure and database interactions.\n- **FunctionalTests**: Test API endpoints using subcutaneous testing.\n\n---\n\n## File & Naming Conventions\n\n- Use PascalCase for files, classes, and methods.\n- Organize files by feature (e.g., `Contributors/Create.cs`, `Projects/Create.cs`).\n- Place request, response, and validator files alongside their endpoint.\n- Do not use hyphens in project or file names.\n- Test classes are named for the class and method being tested. Examples: `ProjectAddItem` or `CreateContributorHandlerHandle`.\n- Test methods are named such that the class name and method name form a sentence describing the test. (e.g. `ReturnsItemGivenValidInputs()` or `ThrowsExceptionGivenNegativeInput()`)\n\n---\n\n## Common Gotchas\n\n- Do not allow Core to reference UseCases, Infrastructure, or Web.\n- Use absolute paths for EF Core migration commands.\n","isInternal":false,"tokens":925,"sizeBytes":4283}],"systemPromptSnippet":"<yakaai_skills repo=\"ardalis/CleanArchitecture\">\n<!-- File: .github/copilot-instructions.md (Tokens: ~1111 | Category: copilot-instructions) -->\n# GitHub Copilot Instructions for Clean Architecture Template\n\n## Project Overview\nThis is a **Clean Architecture template** for .NET 9 that demonstrates Domain-Driven Design (DDD) patterns. It's a starter template, not a reference application - delete sample code once you understand the patterns.\n\n## Architecture & Project Structure\n\n### C# Conventions\n- Use standard Microsoft naming conventions\n- Use `PascalCase` for types and methods, `camelCase` for parameters and private fields\n- Use `I` prefix for interfaces (e.g., `IRepository`)\n- Use `Async` suffix for async methods (e.g., `GetByIdAsync`)\n- Prefix private fields with `_` (e.g., `_repository`)\n- Always use {} for blocks except single-line exits (e.g. `return`, `throw`)\n- Always keep single line blocks on one line (e.g., `if (x) return y;`)\n- Prefer primary constructors for required dependencies\n- Never use primary constructor parameters directly - always assign to private fields for clarity and testability\n\n### Core Dependencies Flow\n- **Core** ← UseCases ← Infrastructure \n- **Core** ← UseCases ← Web\n- Never allow Core to depend on outer layers\n\n### Key Projects\n- **Core**: Domain entities, aggregates, value objects, specifications, interfaces\n- **UseCases**: Commands/queries (CQRS), Mediator handlers, application logic  \n- **Infrastructure**: EF Core, external services, email, file access\n- **Web**: FastEndpoints API, REPR pattern, validation\n\n## Development Patterns\n\n### API Endpoints (FastEndpoints + REPR)\n- One endpoint per file: `Create.cs`, `Update.cs`, `Delete.cs`, `GetById.cs`\n- Separate request/response/validator files: `Create.CreateRequest.cs`, `Create.CreateValidator.cs`\n- Use `Endpoint<TRequest, TResponse>` base class\n- Example: `src/Clean.Architecture.Web/Contributors/Create.cs`\n\n### Domain Model (Core)\n- Entities use encapsulation - minimize public setters\n- Group related entities into Aggregates\n- Use Value Objects (e.g., `ContributorName.From()`)\n- Domain Events for cross-aggregate communication\n- Repository interfaces defined in Core, implemented in Infrastructure\n\n### Use Cases (CQRS)\n- Commands for mutations, Queries for reads\n- Queries can bypass repository pattern for performance\n- Use Mediator (source generator) for command/query handling\n- Chain of responsibility for cross-cutting concerns (logging, validation)\n\n### Validation Strategy\n- **API Level**: FluentValidation on request DTOs (FastEndpoints integration)\n- **Use Case Level**: Validate commands/queries (defensive coding)\n- **Domain Level**: Business invariants throw exceptions, assume pre-validated input\n\n## Essential Commands\n\n### Build & Test\n```bash\ndotnet build Clean.Architecture.slnx\ndotnet test Clean.Architecture.slnx\n```\n\n### Entity Framework Migrations\n```bash\n# From Web project directory\ndotnet ef migrations add MigrationName -c AppDbContext -p ../Clean.Architecture.Infrastructure/Clean.Architecture.Infrastructure.csproj -s Clean.Architecture.Web.csproj -o Data/Migrations\n\ndotnet ef database update -c AppDbContext -p ../Clean.Architecture.Infrastructure/Clean.Architecture.Infrastructure.csproj -s Clean.Architecture.Web.csproj\n```\n\n### Template Installation & Usage\n```bash\ndotnet new install Ardalis.CleanArchitecture.Template\ndotnet new clean-arch -o Your.ProjectName\n```\n\n## Key Dependencies & Patterns\n\n### Primary Libraries\n- **FastEndpoints**: API endpoints (replaced Controllers/Minimal APIs)\n- **Mediator**: Command/query handling in UseCases\n- **EF Core**: Data access (SQLite default, easily changed to SQL Server)\n- **Ardalis.Specification**: Repository query specifications\n- **Ardalis.Result**: Error handling pattern\n- **Serilog**: Structured logging\n\n### Central Package Management\n- All package versions in `Directory.Packages.props`\n- Use `<PackageReference Include=\"...\" />` without Version attribute\n\n### Test Organization\n- **UnitTests**: Core business logic, use cases\n- **IntegrationTests**: Database, infrastructure components  \n- **FunctionalTests**: API endpoints (subcutaneous testing)\n- Use `Microsoft.AspNetCore.Mvc.Testing` for API tests\n\n## File Organization Conventions\n\n### Web Project Structure\n```\nContributors/\n  Create.cs                    # Endpoint\n  Create.CreateRequest.cs      # Request DTO\n  Create.CreateResponse.cs     # Response DTO  \n  Create.CreateValidator.cs    # FluentValidation\n  Update.cs, Delete.cs, etc.\n```\n\n### Sample vs Template\n- `/sample` folder: Complete working example (NimblePros.SampleToDo)\n- `/src` folder: Clean template ready for your project\n- Study sample for patterns, use src for new projects\n\n## Common Gotchas\n\n- Don't include hyphens in project names (template limitation)\n- Replace `Ardalis.SharedKernel` with your own shared kernel\n- Database path in `appsettings.json` for SQLite\n- Use absolute paths in EF migration commands\n- FastEndpoints uses different validation approach than Controller-based APIs\n\n## VS Code Tasks\nUse the predefined tasks: `build`, `publish`, `watch` instead of manual `dotnet` commands when possible.\n\n<!-- File: sample/.github/copilot-instructions.md (Tokens: ~925 | Category: copilot-instructions) -->\n# Solution Development Practices & Conventions\n\nThis document provides guidance for contributing to this solution, which is based on the Clean Architecture template for .NET 9. Follow these practices to ensure consistency, maintainability, and adherence to architectural principles.\n\n---\n\n## Table of Contents\n\n- [Architecture Overview](#architecture-overview)\n- [Project Structure](#project-structure)\n- [Development Patterns](#development-patterns)\n- [Use Case Guidelines](#use-case-guidelines)\n- [API Endpoint Conventions](#api-endpoint-conventions)\n- [Validation Strategy](#validation-strategy)\n- [Testing](#testing)\n- [File & Naming Conventions](#file--naming-conventions)\n- [Common Gotchas](#common-gotchas)\n- [Essential Commands](#essential-commands)\n\n---\n\n## Architecture Overview\n\n- Follows Clean Architecture and Domain-Driven Design (DDD) principles.\n- **Core** project contains domain models, value objects, and repository interfaces.\n- **UseCases** project contains application logic, commands, queries, and handlers.\n- **Infrastructure** project implements data access and external services.\n- **Web** project exposes API endpoints using FastEndpoints.\n\n**Dependency Flow:**  \n`Core` ← `UseCases` ← `Infrastructure`  \n`Core` ← `UseCases` ← `Web`  \n_Core must never depend on outer layers._\n\n---\n\n## Project Structure\n\n- **Core**: Domain entities, aggregates, value objects, domain events, repository interfaces.\n- **UseCases**: CQRS handlers (commands/queries), Mediator, application logic.\n- **Infrastructure**: EF Core, external services, repository implementations.\n- **Web**: FastEndpoints API, request/response/validator classes, REPR pattern.\n\n---\n\n## Development Patterns\n\n- **CQRS**: Use commands for mutations and queries for reads.\n- **Mediator**: All use case handlers implement Mediator interfaces.\n- **Repository Pattern**: Use repository interfaces from Core, implemented in Infrastructure.\n- **Value Objects**: Use for domain concepts (e.g., `ProjectName`, `ContributorId`).\n- **Domain Events**: Use for cross-aggregate communication.\n\n---\n\n## Use Case Guidelines\n\n- **Inputs/Outputs**: Use Value Objects (`ProjectName`, `ContributorId`) for use case command/query parameters and return types. Use value objects internally within the domain. Translate from primitives in the endpoints.\n- **Validation**: Validate at API and use case boundaries; enforce business invariants in the domain.\n- **Error Handling**: Use `Ardalis.Result<T>` for use case results and error propagation.\n- **Defensive Coding**: Validate commands/queries in handlers; assume pre-validated input in domain. Use `Ardalis.GuardClauses` to defend against invalid states in the domain.\n\n---\n\n## API Endpoint Conventions\n\n- One endpoint per file (e.g., `Create.cs`, `Update.cs`).\n- Separate files for request, response, and validator (e.g., `Create.CreateRequest.cs`, `Create.CreateResponse.cs`, `Create.CreateValidator.cs`).\n- Endpoints inherit from `Endpoint<TRequest, TResponse>`.\n- Use REPR (Request/Endpoint/Processor/Response) pattern.\n\n---\n\n## Validation Strategy\n\n- **API Level**: Use FluentValidation for request DTOs.\n- **Use Case Level**: Validate commands/queries in handlers or behaviors.\n- **Domain Level**: Throw exceptions for business rule violations using guard clauses (e.g., `Ardalis.GuardClauses`).)\n\n---\n\n## Testing\n\n- **UnitTests**: Test domain logic and use cases.\n- **IntegrationTests**: Test infrastructure and database interactions.\n- **FunctionalTests**: Test API endpoints using subcutaneous testing.\n\n---\n\n## File & Naming Conventions\n\n- Use PascalCase for files, classes, and methods.\n- Organize files by feature (e.g., `Contributors/Create.cs`, `Projects/Create.cs`).\n- Place request, response, and validator files alongside their endpoint.\n- Do not use hyphens in project or file names.\n- Test classes are named for the class and method being tested. Examples: `ProjectAddItem` or `CreateContributorHandlerHandle`.\n- Test methods are named such that the class name and method name form a sentence describing the test. (e.g. `ReturnsItemGivenValidInputs()` or `ThrowsExceptionGivenNegativeInput()`)\n\n---\n\n## Common Gotchas\n\n- Do not allow Core to reference UseCases, Infrastructure, or Web.\n- Use absolute paths for EF Core migration commands.\n</yakaai_skills>"}