@vodailoc/kilo-kit-mcp 1.1.0 → 1.1.1

package/skills/engineering/aspnet-core/references/apis-minimal-and-controllers.md

@@ -1,81 +1,81 @@
-# APIs: Minimal And Controllers
-
-Primary docs:
-- https://learn.microsoft.com/aspnet/core/fundamentals/minimal-apis
-- https://learn.microsoft.com/aspnet/core/web-api/
-- https://learn.microsoft.com/aspnet/core/fundamentals/error-handling-api
-
-## First Decision
-
-Choose between:
-
-- Minimal APIs for focused, low-ceremony HTTP endpoints
-- controller-based APIs for richer MVC conventions and attribute-driven behavior
-
-Do not mix both styles in the same feature unless that split is genuinely useful.
-
-## Minimal API Guidance
-
-Prefer Minimal APIs when the surface is small to medium and you want concise endpoint definitions.
-
-Good defaults:
-
-- organize endpoints with route groups
-- keep route handlers thin
-- move business logic into services
-- prefer `TypedResults` over untyped results
-- use endpoint filters when cross-cutting behavior belongs at the endpoint layer
-- use built-in validation support on supported target frameworks
-
-Minimal API reminders:
-
-- handler parameters can be bound from route, query, headers, body, form, or DI
-- authorization can be applied with `RequireAuthorization`
-- return `IResult` or `TypedResults` when response shape matters
-- use OpenAPI support for discoverable contracts
-
-On .NET 10, Minimal APIs support built-in validation with `AddValidation()`. Use that instead of inventing parallel validation infrastructure when the target framework supports it.
-
-## Controller API Guidance
-
-Prefer controllers when the API needs:
-
-- `[ApiController]` behaviors
-- attribute routing and conventions
-- filters
-- custom formatters
-- mature controller organization in an existing codebase
-
-Controller defaults:
-
-- derive API controllers from `ControllerBase`
-- annotate with `[ApiController]`
-- use attribute routing
-- return ProblemDetails-compatible failures
-- let automatic model validation handle invalid requests unless there is a concrete override requirement
-
-Key `[ApiController]` behaviors:
-
-- attribute routing is required
-- invalid model state automatically becomes HTTP 400
-- binding source inference applies
-- error responses use ProblemDetails patterns
-
-## Shared API Practices
-
-- Keep request and response DTOs separate from persistence models
-- Use version-stable route and payload contracts
-- Use `CreatedAt...` patterns for resource creation
-- Prefer explicit status codes and typed results over implicit behavior
-- Apply authorization at the endpoint or controller boundary, not only inside service methods
-- Use `ProblemDetails` for errors instead of ad hoc JSON shapes
-
-## Browser-Facing Notes
-
-- Be careful with cookie-authenticated API endpoints and CORS
-- For browser-based form or file upload endpoints, account for antiforgery requirements
-- In ASP.NET Core 10, known API endpoints no longer use cookie-login redirects by default; rely on API-appropriate unauthorized responses instead
-
-## Native AOT
-
-Use `dotnet new webapiaot` only when native AOT is an explicit deployment requirement. Treat it as a constraint that affects library choice, reflection, JSON patterns, and compatibility.
+# APIs: Minimal And Controllers
+
+Primary docs:
+- https://learn.microsoft.com/aspnet/core/fundamentals/minimal-apis
+- https://learn.microsoft.com/aspnet/core/web-api/
+- https://learn.microsoft.com/aspnet/core/fundamentals/error-handling-api
+
+## First Decision
+
+Choose between:
+
+- Minimal APIs for focused, low-ceremony HTTP endpoints
+- controller-based APIs for richer MVC conventions and attribute-driven behavior
+
+Do not mix both styles in the same feature unless that split is genuinely useful.
+
+## Minimal API Guidance
+
+Prefer Minimal APIs when the surface is small to medium and you want concise endpoint definitions.
+
+Good defaults:
+
+- organize endpoints with route groups
+- keep route handlers thin
+- move business logic into services
+- prefer `TypedResults` over untyped results
+- use endpoint filters when cross-cutting behavior belongs at the endpoint layer
+- use built-in validation support on supported target frameworks
+
+Minimal API reminders:
+
+- handler parameters can be bound from route, query, headers, body, form, or DI
+- authorization can be applied with `RequireAuthorization`
+- return `IResult` or `TypedResults` when response shape matters
+- use OpenAPI support for discoverable contracts
+
+On .NET 10, Minimal APIs support built-in validation with `AddValidation()`. Use that instead of inventing parallel validation infrastructure when the target framework supports it.
+
+## Controller API Guidance
+
+Prefer controllers when the API needs:
+
+- `[ApiController]` behaviors
+- attribute routing and conventions
+- filters
+- custom formatters
+- mature controller organization in an existing codebase
+
+Controller defaults:
+
+- derive API controllers from `ControllerBase`
+- annotate with `[ApiController]`
+- use attribute routing
+- return ProblemDetails-compatible failures
+- let automatic model validation handle invalid requests unless there is a concrete override requirement
+
+Key `[ApiController]` behaviors:
+
+- attribute routing is required
+- invalid model state automatically becomes HTTP 400
+- binding source inference applies
+- error responses use ProblemDetails patterns
+
+## Shared API Practices
+
+- Keep request and response DTOs separate from persistence models
+- Use version-stable route and payload contracts
+- Use `CreatedAt...` patterns for resource creation
+- Prefer explicit status codes and typed results over implicit behavior
+- Apply authorization at the endpoint or controller boundary, not only inside service methods
+- Use `ProblemDetails` for errors instead of ad hoc JSON shapes
+
+## Browser-Facing Notes
+
+- Be careful with cookie-authenticated API endpoints and CORS
+- For browser-based form or file upload endpoints, account for antiforgery requirements
+- In ASP.NET Core 10, known API endpoints no longer use cookie-login redirects by default; rely on API-appropriate unauthorized responses instead
+
+## Native AOT
+
+Use `dotnet new webapiaot` only when native AOT is an explicit deployment requirement. Treat it as a constraint that affects library choice, reflection, JSON patterns, and compatibility.

package/skills/engineering/aspnet-core/references/data-state-and-services.md

@@ -1,69 +1,69 @@
-# Data, State, And Services
-
-Primary docs:
-- https://learn.microsoft.com/aspnet/core/data/
-- https://learn.microsoft.com/aspnet/core/fundamentals/dependency-injection
-- https://learn.microsoft.com/aspnet/core/fundamentals/http-requests
-- https://learn.microsoft.com/aspnet/core/fundamentals/app-state
-
-## Dependency Injection Defaults
-
-- Register infrastructure and business services in `Program.cs`
-- Inject dependencies through constructors by default
-- Keep scoped services request-bound
-- Avoid resolving scoped services from singletons
-- Use keyed or named patterns only when there is a real need for multiple implementations
-
-## EF Core And DbContext
-
-Use EF Core for common relational data access patterns unless the repository already uses another data layer.
-
-Default guidance:
-
-- register `DbContext` with `AddDbContext`
-- treat `DbContext` as scoped
-- keep queries and transactions in services, not UI code
-- use migrations intentionally
-- keep entities out of public API contracts and UI view models
-
-Use `IDbContextFactory<TContext>` when the execution model is not request-scoped, such as:
-
-- Blazor components with longer-lived scopes
-- background services
-- explicit factory-driven data work
-
-## Options And Configuration
-
-- Bind structured configuration into options classes
-- validate options early when bad configuration should fail fast
-- keep configuration access close to the service that owns it
-- avoid scattering raw configuration keys across the codebase
-
-## Outbound HTTP
-
-Use `IHttpClientFactory` for outbound HTTP calls.
-
-Prefer:
-
-- named clients for distinct external systems
-- typed clients for richer integrations
-- delegating handlers for retries, headers, or telemetry concerns
-
-Avoid manual `new HttpClient()` patterns scattered through request handlers.
-
-## App State
-
-Use the smallest state mechanism that fits:
-
-- query string or route values for transparent request state
-- form posts for user input
-- TempData for short-lived redirect-friendly messages
-- session only when necessary and with an understanding of its server-side and scaling implications
-
-Do not treat session as the primary application data store.
-
-## Caching And State Boundaries
-
-- Keep cached data derivable from a durable source
-- Separate cache shape from persistence shape when it improves safety or performance
-- Revisit session, in-memory cache, and singleton state when the app scales to multiple instances
+# Data, State, And Services
+
+Primary docs:
+- https://learn.microsoft.com/aspnet/core/data/
+- https://learn.microsoft.com/aspnet/core/fundamentals/dependency-injection
+- https://learn.microsoft.com/aspnet/core/fundamentals/http-requests
+- https://learn.microsoft.com/aspnet/core/fundamentals/app-state
+
+## Dependency Injection Defaults
+
+- Register infrastructure and business services in `Program.cs`
+- Inject dependencies through constructors by default
+- Keep scoped services request-bound
+- Avoid resolving scoped services from singletons
+- Use keyed or named patterns only when there is a real need for multiple implementations
+
+## EF Core And DbContext
+
+Use EF Core for common relational data access patterns unless the repository already uses another data layer.
+
+Default guidance:
+
+- register `DbContext` with `AddDbContext`
+- treat `DbContext` as scoped
+- keep queries and transactions in services, not UI code
+- use migrations intentionally
+- keep entities out of public API contracts and UI view models
+
+Use `IDbContextFactory<TContext>` when the execution model is not request-scoped, such as:
+
+- Blazor components with longer-lived scopes
+- background services
+- explicit factory-driven data work
+
+## Options And Configuration
+
+- Bind structured configuration into options classes
+- validate options early when bad configuration should fail fast
+- keep configuration access close to the service that owns it
+- avoid scattering raw configuration keys across the codebase
+
+## Outbound HTTP
+
+Use `IHttpClientFactory` for outbound HTTP calls.
+
+Prefer:
+
+- named clients for distinct external systems
+- typed clients for richer integrations
+- delegating handlers for retries, headers, or telemetry concerns
+
+Avoid manual `new HttpClient()` patterns scattered through request handlers.
+
+## App State
+
+Use the smallest state mechanism that fits:
+
+- query string or route values for transparent request state
+- form posts for user input
+- TempData for short-lived redirect-friendly messages
+- session only when necessary and with an understanding of its server-side and scaling implications
+
+Do not treat session as the primary application data store.
+
+## Caching And State Boundaries
+
+- Keep cached data derivable from a durable source
+- Separate cache shape from persistence shape when it improves safety or performance
+- Revisit session, in-memory cache, and singleton state when the app scales to multiple instances

package/skills/engineering/aspnet-core/references/program-and-pipeline.md

@@ -1,103 +1,103 @@
-# Program And Pipeline
-
-Primary docs:
-- https://learn.microsoft.com/aspnet/core/fundamentals/
-- https://learn.microsoft.com/aspnet/core/fundamentals/minimal-apis/webapplication
-- https://learn.microsoft.com/aspnet/core/fundamentals/middleware/
-- https://learn.microsoft.com/aspnet/core/fundamentals/configuration/
-
-## Startup Shape
-
-Prefer the modern hosting model:
-
-1. Create `var builder = WebApplication.CreateBuilder(args);`
-2. Register services on `builder.Services`
-3. Build `var app = builder.Build();`
-4. Configure middleware in the correct order
-5. Map endpoints
-6. Call `app.Run();`
-
-Use older `Startup` patterns only when the repository already uses them or the task is migration.
-
-## Service Registration
-
-- Register framework services explicitly: Razor Pages, controllers, Razor components, authentication, authorization, health checks, rate limiting, response compression, output caching, EF Core, and `IHttpClientFactory`
-- Keep business logic in services instead of controllers, page models, or route handlers
-- Use constructor injection as the default
-- Use options classes for structured configuration
-- Choose lifetimes intentionally:
-  - singleton: stateless or shared infrastructure
-  - scoped: request-bound work such as `DbContext`
-  - transient: lightweight stateless services
-
-## Configuration Defaults
-
-`WebApplication.CreateBuilder` already loads configuration from common providers such as:
-
-- `appsettings.json`
-- environment-specific `appsettings.{Environment}.json`
-- environment variables
-- command-line arguments
-
-For secrets:
-
-- use Secret Manager in development
-- use a secure external store in production
-- do not commit secrets to source control
-
-## Middleware Order
-
-Middleware order is a frequent source of broken behavior. Favor this shape and adjust only with a concrete reason:
-
-1. Forwarded headers if behind a proxy or load balancer
-2. Exception handling and HSTS for non-development environments
-3. HTTPS redirection
-4. Static files
-5. Routing when explicit routing middleware is needed
-6. CORS when endpoints require it
-7. Authentication
-8. Authorization
-9. Endpoint-specific middleware such as rate limiting or session as required
-10. Endpoint mapping with `MapRazorPages`, `MapControllers`, `MapGet`, `MapHub`, or `MapGrpcService`
-
-Important ordering rules:
-
-- Call `UseAuthentication()` before `UseAuthorization()`
-- Keep proxy/header processing before auth, redirects, and link generation
-- Do not insert custom middleware randomly between auth and authorization without a reason
-- In Minimal API apps, explicit `UseRouting()` is usually unnecessary unless you need to control order
-
-## Routing And Endpoints
-
-- Prefer endpoint routing everywhere
-- Use route groups for larger Minimal API surfaces
-- Keep MVC and API routes explicit and predictable
-- Use areas only when the application is large enough to benefit from bounded sections
-- Keep endpoint names stable when generating links or integrating with clients
-
-## Error Handling
-
-- Use centralized exception handling instead of scattered `try/catch` blocks for ordinary request failures
-- Prefer ProblemDetails-style responses for APIs
-- Keep the developer exception page limited to development
-- Separate user-facing failures from internal exception details
-
-## Logging And Diagnostics
-
-- Use `ILogger<T>` from DI
-- Log structured values, not concatenated strings
-- Put correlation and request diagnostics in middleware or infrastructure, not business logic
-- Enable HTTP logging only when the scenario warrants it and avoid leaking sensitive data
-
-## Static Assets And Web Root
-
-- Keep public assets in `wwwroot`
-- Treat the web root as publicly readable content
-- Prevent publishing local-only static content through project file rules when needed
-- Use Razor Class Libraries for reusable UI assets across apps
-
-## Architectural Defaults
-
-- Keep `Program.cs` readable; extract feature registration to extension methods when it starts accumulating unrelated concerns
-- Prefer vertical slices or feature folders over giant "Controllers", "Services", and "Repositories" buckets with weak boundaries
-- Keep framework configuration close to the host and business logic out of it
+# Program And Pipeline
+
+Primary docs:
+- https://learn.microsoft.com/aspnet/core/fundamentals/
+- https://learn.microsoft.com/aspnet/core/fundamentals/minimal-apis/webapplication
+- https://learn.microsoft.com/aspnet/core/fundamentals/middleware/
+- https://learn.microsoft.com/aspnet/core/fundamentals/configuration/
+
+## Startup Shape
+
+Prefer the modern hosting model:
+
+1. Create `var builder = WebApplication.CreateBuilder(args);`
+2. Register services on `builder.Services`
+3. Build `var app = builder.Build();`
+4. Configure middleware in the correct order
+5. Map endpoints
+6. Call `app.Run();`
+
+Use older `Startup` patterns only when the repository already uses them or the task is migration.
+
+## Service Registration
+
+- Register framework services explicitly: Razor Pages, controllers, Razor components, authentication, authorization, health checks, rate limiting, response compression, output caching, EF Core, and `IHttpClientFactory`
+- Keep business logic in services instead of controllers, page models, or route handlers
+- Use constructor injection as the default
+- Use options classes for structured configuration
+- Choose lifetimes intentionally:
+  - singleton: stateless or shared infrastructure
+  - scoped: request-bound work such as `DbContext`
+  - transient: lightweight stateless services
+
+## Configuration Defaults
+
+`WebApplication.CreateBuilder` already loads configuration from common providers such as:
+
+- `appsettings.json`
+- environment-specific `appsettings.{Environment}.json`
+- environment variables
+- command-line arguments
+
+For secrets:
+
+- use Secret Manager in development
+- use a secure external store in production
+- do not commit secrets to source control
+
+## Middleware Order
+
+Middleware order is a frequent source of broken behavior. Favor this shape and adjust only with a concrete reason:
+
+1. Forwarded headers if behind a proxy or load balancer
+2. Exception handling and HSTS for non-development environments
+3. HTTPS redirection
+4. Static files
+5. Routing when explicit routing middleware is needed
+6. CORS when endpoints require it
+7. Authentication
+8. Authorization
+9. Endpoint-specific middleware such as rate limiting or session as required
+10. Endpoint mapping with `MapRazorPages`, `MapControllers`, `MapGet`, `MapHub`, or `MapGrpcService`
+
+Important ordering rules:
+
+- Call `UseAuthentication()` before `UseAuthorization()`
+- Keep proxy/header processing before auth, redirects, and link generation
+- Do not insert custom middleware randomly between auth and authorization without a reason
+- In Minimal API apps, explicit `UseRouting()` is usually unnecessary unless you need to control order
+
+## Routing And Endpoints
+
+- Prefer endpoint routing everywhere
+- Use route groups for larger Minimal API surfaces
+- Keep MVC and API routes explicit and predictable
+- Use areas only when the application is large enough to benefit from bounded sections
+- Keep endpoint names stable when generating links or integrating with clients
+
+## Error Handling
+
+- Use centralized exception handling instead of scattered `try/catch` blocks for ordinary request failures
+- Prefer ProblemDetails-style responses for APIs
+- Keep the developer exception page limited to development
+- Separate user-facing failures from internal exception details
+
+## Logging And Diagnostics
+
+- Use `ILogger<T>` from DI
+- Log structured values, not concatenated strings
+- Put correlation and request diagnostics in middleware or infrastructure, not business logic
+- Enable HTTP logging only when the scenario warrants it and avoid leaking sensitive data
+
+## Static Assets And Web Root
+
+- Keep public assets in `wwwroot`
+- Treat the web root as publicly readable content
+- Prevent publishing local-only static content through project file rules when needed
+- Use Razor Class Libraries for reusable UI assets across apps
+
+## Architectural Defaults
+
+- Keep `Program.cs` readable; extract feature registration to extension methods when it starts accumulating unrelated concerns
+- Prefer vertical slices or feature folders over giant "Controllers", "Services", and "Repositories" buckets with weak boundaries
+- Keep framework configuration close to the host and business logic out of it

package/skills/engineering/aspnet-core/references/realtime-grpc-and-background-work.md

@@ -1,58 +1,58 @@
-# Realtime, gRPC, And Background Work
-
-Primary docs:
-- https://learn.microsoft.com/aspnet/core/signalr/introduction
-- https://learn.microsoft.com/aspnet/core/grpc/
-- https://learn.microsoft.com/aspnet/core/fundamentals/host/hosted-services
-
-## SignalR
-
-Use SignalR when the server must push updates to connected clients in near real time.
-
-Good fits:
-
-- chat
-- dashboards
-- notifications
-- collaborative editing
-- live status streams
-
-Guidance:
-
-- model the hub as a communication boundary, not the home of business logic
-- use groups and user targeting deliberately
-- authenticate connections when data is user-specific
-- plan for scale-out if the app may run on multiple instances
-
-Remember that Blazor interactive server rendering already relies on a real-time connection. Do not add a second realtime channel unless the feature truly needs one.
-
-## gRPC
-
-Use gRPC for efficient service-to-service communication, strongly typed contracts, and streaming over HTTP/2.
-
-Prefer gRPC when:
-
-- both ends are under your control
-- performance and contract fidelity matter
-- streaming is a first-class requirement
-
-Guidance:
-
-- keep `.proto` contracts versioned and stable
-- generate client and server types from contracts
-- keep auth, logging, and DI integrated with the host
-- account for browser interoperability differences before choosing gRPC for public browser clients
-
-## Background Work
-
-Use `IHostedService` or `BackgroundService` for in-process background tasks tied to the application host.
-
-Defaults:
-
-- keep background services small and observable
-- create scopes for scoped dependencies
-- do not capture scoped services directly in singleton hosted services
-- respect cancellation tokens
-- avoid long blocking startup paths
-
-If the work is durable, high-volume, or business-critical, consider whether it belongs in an out-of-process queue or worker instead of only inside the web host.
+# Realtime, gRPC, And Background Work
+
+Primary docs:
+- https://learn.microsoft.com/aspnet/core/signalr/introduction
+- https://learn.microsoft.com/aspnet/core/grpc/
+- https://learn.microsoft.com/aspnet/core/fundamentals/host/hosted-services
+
+## SignalR
+
+Use SignalR when the server must push updates to connected clients in near real time.
+
+Good fits:
+
+- chat
+- dashboards
+- notifications
+- collaborative editing
+- live status streams
+
+Guidance:
+
+- model the hub as a communication boundary, not the home of business logic
+- use groups and user targeting deliberately
+- authenticate connections when data is user-specific
+- plan for scale-out if the app may run on multiple instances
+
+Remember that Blazor interactive server rendering already relies on a real-time connection. Do not add a second realtime channel unless the feature truly needs one.
+
+## gRPC
+
+Use gRPC for efficient service-to-service communication, strongly typed contracts, and streaming over HTTP/2.
+
+Prefer gRPC when:
+
+- both ends are under your control
+- performance and contract fidelity matter
+- streaming is a first-class requirement
+
+Guidance:
+
+- keep `.proto` contracts versioned and stable
+- generate client and server types from contracts
+- keep auth, logging, and DI integrated with the host
+- account for browser interoperability differences before choosing gRPC for public browser clients
+
+## Background Work
+
+Use `IHostedService` or `BackgroundService` for in-process background tasks tied to the application host.
+
+Defaults:
+
+- keep background services small and observable
+- create scopes for scoped dependencies
+- do not capture scoped services directly in singleton hosted services
+- respect cancellation tokens
+- avoid long blocking startup paths
+
+If the work is durable, high-volume, or business-critical, consider whether it belongs in an out-of-process queue or worker instead of only inside the web host.