@vodailoc/kilo-kit-mcp 1.1.0 → 1.1.1

package/skills/engineering/aspnet-core/references/security-and-identity.md

@@ -1,75 +1,75 @@
-# Security And Identity
-
-Primary docs:
-- https://learn.microsoft.com/aspnet/core/security/
-- https://learn.microsoft.com/aspnet/core/security/authentication/identity
-- https://learn.microsoft.com/aspnet/core/security/authorization/introduction
-
-## Security Defaults
-
-- Use the most secure authentication flow available
-- Keep secrets out of source code and plain configuration files
-- Use Secret Manager in development
-- Use a secure production secret store
-- Enforce HTTPS
-- Apply least privilege to users, services, and data access
-
-## Authentication And Authorization
-
-Authentication answers who the user or caller is. Authorization answers what they can do.
-
-Default pipeline order:
-
-1. `UseAuthentication()`
-2. `UseAuthorization()`
-
-Apply authorization at boundaries:
-
-- `[Authorize]` on controllers, actions, page models, or hubs
-- `RequireAuthorization()` on endpoints and route groups
-- policies for reusable rules
-- roles only when role-based checks are actually the right abstraction
-
-Use `AllowAnonymous` sparingly and intentionally.
-
-## Identity
-
-Use ASP.NET Core Identity when the app needs first-party user accounts, login flows, password management, email confirmation, MFA, or related account management.
-
-Useful starting points:
-
-- `dotnet new webapp -au Individual`
-- `dotnet new mvc -au Individual`
-
-Identity guidance:
-
-- scaffold only the pages you truly need to customize
-- keep Identity UI updates maintainable; full scaffolding increases merge and upgrade cost
-- use policies and claims for authorization rather than encoding all decisions in page logic
-- persist data-protection keys appropriately in multi-instance deployments
-
-On ASP.NET Core 10, Identity metrics are available for observing auth-related behavior. Use them when the app has meaningful authentication traffic or security monitoring requirements.
-
-## CSRF, CORS, And Browser Security
-
-- Use antiforgery protection for cookie-based interactive apps and form posts
-- Do not confuse CORS with authentication or authorization
-- Avoid permissive `AllowAnyOrigin` plus credentials combinations
-- Treat browser-side state as untrusted
-
-## HTTPS, HSTS, And Forwarded Headers
-
-- redirect HTTP to HTTPS
-- enable HSTS outside development when appropriate
-- configure forwarded headers correctly when behind proxies or load balancers
-- do not generate links or evaluate scheme-sensitive behavior before proxy headers are processed
-
-## Data Protection And Secrets
-
-- persist data-protection keys outside ephemeral local storage when the app runs on multiple instances
-- do not use environment variables as the preferred long-term home for production secrets when a stronger secret store is available
-- never check production credentials into source control
-
-## Blazor Note
-
-For Blazor apps, read the general ASP.NET Core security guidance first and then the Blazor-specific security docs. Some Blazor security guidance adds to or supersedes the general guidance.
+# Security And Identity
+
+Primary docs:
+- https://learn.microsoft.com/aspnet/core/security/
+- https://learn.microsoft.com/aspnet/core/security/authentication/identity
+- https://learn.microsoft.com/aspnet/core/security/authorization/introduction
+
+## Security Defaults
+
+- Use the most secure authentication flow available
+- Keep secrets out of source code and plain configuration files
+- Use Secret Manager in development
+- Use a secure production secret store
+- Enforce HTTPS
+- Apply least privilege to users, services, and data access
+
+## Authentication And Authorization
+
+Authentication answers who the user or caller is. Authorization answers what they can do.
+
+Default pipeline order:
+
+1. `UseAuthentication()`
+2. `UseAuthorization()`
+
+Apply authorization at boundaries:
+
+- `[Authorize]` on controllers, actions, page models, or hubs
+- `RequireAuthorization()` on endpoints and route groups
+- policies for reusable rules
+- roles only when role-based checks are actually the right abstraction
+
+Use `AllowAnonymous` sparingly and intentionally.
+
+## Identity
+
+Use ASP.NET Core Identity when the app needs first-party user accounts, login flows, password management, email confirmation, MFA, or related account management.
+
+Useful starting points:
+
+- `dotnet new webapp -au Individual`
+- `dotnet new mvc -au Individual`
+
+Identity guidance:
+
+- scaffold only the pages you truly need to customize
+- keep Identity UI updates maintainable; full scaffolding increases merge and upgrade cost
+- use policies and claims for authorization rather than encoding all decisions in page logic
+- persist data-protection keys appropriately in multi-instance deployments
+
+On ASP.NET Core 10, Identity metrics are available for observing auth-related behavior. Use them when the app has meaningful authentication traffic or security monitoring requirements.
+
+## CSRF, CORS, And Browser Security
+
+- Use antiforgery protection for cookie-based interactive apps and form posts
+- Do not confuse CORS with authentication or authorization
+- Avoid permissive `AllowAnyOrigin` plus credentials combinations
+- Treat browser-side state as untrusted
+
+## HTTPS, HSTS, And Forwarded Headers
+
+- redirect HTTP to HTTPS
+- enable HSTS outside development when appropriate
+- configure forwarded headers correctly when behind proxies or load balancers
+- do not generate links or evaluate scheme-sensitive behavior before proxy headers are processed
+
+## Data Protection And Secrets
+
+- persist data-protection keys outside ephemeral local storage when the app runs on multiple instances
+- do not use environment variables as the preferred long-term home for production secrets when a stronger secret store is available
+- never check production credentials into source control
+
+## Blazor Note
+
+For Blazor apps, read the general ASP.NET Core security guidance first and then the Blazor-specific security docs. Some Blazor security guidance adds to or supersedes the general guidance.

package/skills/engineering/aspnet-core/references/source-map.md

@@ -1,43 +1,43 @@
-# ASP.NET Core Source Map
-
-This skill is synthesized from the official ASP.NET Core documentation tree and overview pages. Use this file to map a task to the corresponding Microsoft Learn area before opening deeper docs.
-
-Core sources:
-
-- https://learn.microsoft.com/aspnet/core/
-- https://raw.githubusercontent.com/dotnet/AspNetCore.Docs/main/aspnetcore/toc.yml
-- https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore
-
-## Documentation Tree Mapping
-
-| ASP.NET Core docs area | Use this skill reference first |
-| --- | --- |
-| Overview, Get started, What's new | `stack-selection.md`, `versioning-and-upgrades.md` |
-| Fundamentals | `program-and-pipeline.md` |
-| Web apps | `ui-blazor.md`, `ui-razor-pages.md`, `ui-mvc.md` |
-| APIs | `apis-minimal-and-controllers.md` |
-| Real-time apps | `realtime-grpc-and-background-work.md` |
-| Remote Procedure Call apps | `realtime-grpc-and-background-work.md` |
-| Servers, Host and deploy | `testing-performance-and-operations.md` |
-| Test, Debug, Troubleshoot | `testing-performance-and-operations.md` |
-| Data access | `data-state-and-services.md` |
-| Security and Identity | `security-and-identity.md` |
-| Performance | `testing-performance-and-operations.md` |
-| Migration and updates | `versioning-and-upgrades.md` |
-
-## Areas To Consult Directly On Microsoft Learn
-
-The following topics are part of the ASP.NET Core documentation tree but are not expanded into their own dedicated reference file here:
-
-- globalization and localization
-- advanced hosting and YARP details
-- debugger and diagnostics tooling specifics
-- narrow API-reference pages for individual types
-
-When a task is dominated by one of those areas, go straight to the matching Microsoft Learn section after checking the reference files in this skill.
-
-## Practical Deep-Dive Rule
-
-- Start with the focused reference in this skill
-- If the task depends on a narrow platform detail, open the matching Learn article
-- If the task depends on version-specific behavior, confirm the correct moniker or breaking-changes page
+# ASP.NET Core Source Map
+
+This skill is synthesized from the official ASP.NET Core documentation tree and overview pages. Use this file to map a task to the corresponding Microsoft Learn area before opening deeper docs.
+
+Core sources:
+
+- https://learn.microsoft.com/aspnet/core/
+- https://raw.githubusercontent.com/dotnet/AspNetCore.Docs/main/aspnetcore/toc.yml
+- https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore
+
+## Documentation Tree Mapping
+
+| ASP.NET Core docs area | Use this skill reference first |
+| --- | --- |
+| Overview, Get started, What's new | `stack-selection.md`, `versioning-and-upgrades.md` |
+| Fundamentals | `program-and-pipeline.md` |
+| Web apps | `ui-blazor.md`, `ui-razor-pages.md`, `ui-mvc.md` |
+| APIs | `apis-minimal-and-controllers.md` |
+| Real-time apps | `realtime-grpc-and-background-work.md` |
+| Remote Procedure Call apps | `realtime-grpc-and-background-work.md` |
+| Servers, Host and deploy | `testing-performance-and-operations.md` |
+| Test, Debug, Troubleshoot | `testing-performance-and-operations.md` |
+| Data access | `data-state-and-services.md` |
+| Security and Identity | `security-and-identity.md` |
+| Performance | `testing-performance-and-operations.md` |
+| Migration and updates | `versioning-and-upgrades.md` |
+
+## Areas To Consult Directly On Microsoft Learn
+
+The following topics are part of the ASP.NET Core documentation tree but are not expanded into their own dedicated reference file here:
+
+- globalization and localization
+- advanced hosting and YARP details
+- debugger and diagnostics tooling specifics
+- narrow API-reference pages for individual types
+
+When a task is dominated by one of those areas, go straight to the matching Microsoft Learn section after checking the reference files in this skill.
+
+## Practical Deep-Dive Rule
+
+- Start with the focused reference in this skill
+- If the task depends on a narrow platform detail, open the matching Learn article
+- If the task depends on version-specific behavior, confirm the correct moniker or breaking-changes page

package/skills/engineering/aspnet-core/references/stack-selection.md

@@ -1,63 +1,63 @@
-# Stack Selection
-
-Primary docs:
-- https://learn.microsoft.com/aspnet/core/
-- https://learn.microsoft.com/aspnet/core/blazor/
-- https://learn.microsoft.com/aspnet/core/razor-pages/
-- https://learn.microsoft.com/aspnet/core/mvc/overview
-- https://learn.microsoft.com/aspnet/core/web-api/
-- https://learn.microsoft.com/aspnet/core/fundamentals/minimal-apis
-
-## Default Version Choice
-
-- Prefer the latest stable .NET and ASP.NET Core for new production work.
-- As of March 2026, that means `net10.0` unless the repository or user request says otherwise.
-- Treat ASP.NET Core 11 as preview. Do not adopt preview APIs by default.
-- If the repository already targets `net8.0`, `net9.0`, or another framework, stay within that target unless the task is explicitly an upgrade.
-
-## Template Short Names
-
-The current .NET 10 SDK templates include:
-
-- `dotnet new blazor`
-- `dotnet new webapp`
-- `dotnet new mvc`
-- `dotnet new webapi`
-- `dotnet new webapiaot`
-- `dotnet new grpc`
-- `dotnet new web`
-- `dotnet new razorclasslib`
-
-Verify template names with `dotnet new list` if the environment differs.
-
-## Application Model Matrix
-
-| Model | Prefer when | Watch out for | Typical starting point |
-| --- | --- | --- | --- |
-| Blazor Web App | Build full-stack .NET UI with SSR plus optional interactivity | Interactive server needs a live connection; WebAssembly increases payload size | `dotnet new blazor` |
-| Razor Pages | Build page-focused CRUD, forms, dashboards, and line-of-business apps | Authorization cannot be applied per page handler; use MVC if handler-level control matters | `dotnet new webapp` |
-| MVC | Build large server-rendered apps with clear controller/view separation, filters, and action-based patterns | More ceremony than Razor Pages for simple page flows | `dotnet new mvc` |
-| Minimal APIs | Build focused HTTP APIs, internal services, lightweight backends, and small surface areas | Route handlers can become hard to manage if business logic or metadata grows without structure | `dotnet new webapi` or `dotnet new web` |
-| Controller-based Web API | Build APIs that benefit from `[ApiController]`, content negotiation, filters, formatters, and mature controller conventions | More ceremony than Minimal APIs for small endpoints | `dotnet new webapi` |
-| SignalR | Add server push, live updates, chat, collaborative UI, or notifications | Requires connection lifecycle management and scale-out planning | Add to an existing ASP.NET Core app |
-| gRPC | Build service-to-service or streaming RPC over HTTP/2 | Browser support is different from ordinary JSON APIs; use gRPC-Web only when needed | `dotnet new grpc` |
-
-## Fast Heuristics
-
-- Choose Blazor Web App when the UI itself should be a .NET component model.
-- Choose Razor Pages when the app is mostly page and form oriented.
-- Choose MVC when actions, views, filters, and controller conventions are the center of the design.
-- Choose Minimal APIs first for small to medium HTTP services.
-- Switch to controllers when the API needs richer attribute-driven behavior, custom formatters, or strong alignment with existing MVC/Web API conventions.
-- Keep the current app model in an existing codebase unless the mismatch is causing real complexity.
-
-## Mixed-Model Guidance
-
-ASP.NET Core can mix models in one host. Common combinations:
-
-- Razor Pages or MVC for server-rendered UI plus Minimal APIs for AJAX or mobile endpoints
-- Blazor Web App plus Minimal APIs for external integration endpoints
-- MVC or Razor Pages plus SignalR for live updates
-- Web API plus gRPC for internal service-to-service calls
-
-Mix models only when it simplifies the public surface. Do not add a second app model just because ASP.NET Core allows it.
+# Stack Selection
+
+Primary docs:
+- https://learn.microsoft.com/aspnet/core/
+- https://learn.microsoft.com/aspnet/core/blazor/
+- https://learn.microsoft.com/aspnet/core/razor-pages/
+- https://learn.microsoft.com/aspnet/core/mvc/overview
+- https://learn.microsoft.com/aspnet/core/web-api/
+- https://learn.microsoft.com/aspnet/core/fundamentals/minimal-apis
+
+## Default Version Choice
+
+- Prefer the latest stable .NET and ASP.NET Core for new production work.
+- As of March 2026, that means `net10.0` unless the repository or user request says otherwise.
+- Treat ASP.NET Core 11 as preview. Do not adopt preview APIs by default.
+- If the repository already targets `net8.0`, `net9.0`, or another framework, stay within that target unless the task is explicitly an upgrade.
+
+## Template Short Names
+
+The current .NET 10 SDK templates include:
+
+- `dotnet new blazor`
+- `dotnet new webapp`
+- `dotnet new mvc`
+- `dotnet new webapi`
+- `dotnet new webapiaot`
+- `dotnet new grpc`
+- `dotnet new web`
+- `dotnet new razorclasslib`
+
+Verify template names with `dotnet new list` if the environment differs.
+
+## Application Model Matrix
+
+| Model | Prefer when | Watch out for | Typical starting point |
+| --- | --- | --- | --- |
+| Blazor Web App | Build full-stack .NET UI with SSR plus optional interactivity | Interactive server needs a live connection; WebAssembly increases payload size | `dotnet new blazor` |
+| Razor Pages | Build page-focused CRUD, forms, dashboards, and line-of-business apps | Authorization cannot be applied per page handler; use MVC if handler-level control matters | `dotnet new webapp` |
+| MVC | Build large server-rendered apps with clear controller/view separation, filters, and action-based patterns | More ceremony than Razor Pages for simple page flows | `dotnet new mvc` |
+| Minimal APIs | Build focused HTTP APIs, internal services, lightweight backends, and small surface areas | Route handlers can become hard to manage if business logic or metadata grows without structure | `dotnet new webapi` or `dotnet new web` |
+| Controller-based Web API | Build APIs that benefit from `[ApiController]`, content negotiation, filters, formatters, and mature controller conventions | More ceremony than Minimal APIs for small endpoints | `dotnet new webapi` |
+| SignalR | Add server push, live updates, chat, collaborative UI, or notifications | Requires connection lifecycle management and scale-out planning | Add to an existing ASP.NET Core app |
+| gRPC | Build service-to-service or streaming RPC over HTTP/2 | Browser support is different from ordinary JSON APIs; use gRPC-Web only when needed | `dotnet new grpc` |
+
+## Fast Heuristics
+
+- Choose Blazor Web App when the UI itself should be a .NET component model.
+- Choose Razor Pages when the app is mostly page and form oriented.
+- Choose MVC when actions, views, filters, and controller conventions are the center of the design.
+- Choose Minimal APIs first for small to medium HTTP services.
+- Switch to controllers when the API needs richer attribute-driven behavior, custom formatters, or strong alignment with existing MVC/Web API conventions.
+- Keep the current app model in an existing codebase unless the mismatch is causing real complexity.
+
+## Mixed-Model Guidance
+
+ASP.NET Core can mix models in one host. Common combinations:
+
+- Razor Pages or MVC for server-rendered UI plus Minimal APIs for AJAX or mobile endpoints
+- Blazor Web App plus Minimal APIs for external integration endpoints
+- MVC or Razor Pages plus SignalR for live updates
+- Web API plus gRPC for internal service-to-service calls
+
+Mix models only when it simplifies the public surface. Do not add a second app model just because ASP.NET Core allows it.

package/skills/engineering/aspnet-core/references/testing-performance-and-operations.md

@@ -1,92 +1,92 @@
-# Testing, Performance, And Operations
-
-Primary docs:
-- https://learn.microsoft.com/aspnet/core/test/integration-tests
-- https://learn.microsoft.com/aspnet/core/host-and-deploy/
-- https://learn.microsoft.com/aspnet/core/host-and-deploy/health-checks
-- https://learn.microsoft.com/aspnet/core/performance/
-
-## Testing Strategy
-
-Use layered testing instead of relying on one style:
-
-- unit tests for pure services and business logic
-- integration tests for request pipeline, DI, database, auth, and framework wiring
-- browser tests for end-to-end user flows
-
-## Integration Tests
-
-Use `Microsoft.AspNetCore.Mvc.Testing` and `WebApplicationFactory<Program>` for integration tests.
-
-Guidance from the official docs:
-
-- use a test host and `HttpClient`
-- replace services with test doubles when needed
-- control redirects when asserting auth behavior
-- handle antiforgery correctly for form posts
-- prefer SQLite in-memory over the EF Core in-memory provider for more realistic database tests
-
-For SPA or browser-driven scenarios, Microsoft recommends browser automation such as Playwright for .NET.
-
-## Performance Defaults
-
-Reach for built-in features before custom optimization layers:
-
-- output caching
-- response caching where appropriate
-- response compression
-- HTTP request timeouts
-- rate limiting
-- static file handling
-
-General performance guidance:
-
-- measure first
-- keep database and network round trips visible
-- reduce payload size
-- use streaming or pagination when data is large
-- keep synchronous blocking out of hot paths
-
-## Health Checks And Observability
-
-Add health checks for dependencies that matter operationally.
-
-Use separate checks or tags when you need:
-
-- liveness
-- readiness
-- dependency-specific health surfaces
-
-Also ensure:
-
-- structured logs
-- request tracing where applicable
-- metrics for critical paths such as auth, API latency, and background work
-
-## Hosting And Deployment
-
-Typical deployment flow:
-
-1. `dotnet publish`
-2. deploy the publish output
-3. run behind a process manager
-4. place a reverse proxy in front when the environment requires it
-
-Know the deployment environment:
-
-- IIS or Windows Service on Windows
-- Kestrel plus Nginx or another reverse proxy on Linux
-- container hosting when the platform expects it
-
-Behind proxies or load balancers:
-
-- configure forwarded headers
-- validate scheme, host, and remote IP behavior
-- test auth redirects and callback URLs in the deployed topology
-
-## Operational Safeguards
-
-- add health checks for databases and critical external services
-- fail fast on invalid configuration where possible
-- keep secrets out of publish artifacts
-- verify data-protection key persistence in multi-instance deployments
+# Testing, Performance, And Operations
+
+Primary docs:
+- https://learn.microsoft.com/aspnet/core/test/integration-tests
+- https://learn.microsoft.com/aspnet/core/host-and-deploy/
+- https://learn.microsoft.com/aspnet/core/host-and-deploy/health-checks
+- https://learn.microsoft.com/aspnet/core/performance/
+
+## Testing Strategy
+
+Use layered testing instead of relying on one style:
+
+- unit tests for pure services and business logic
+- integration tests for request pipeline, DI, database, auth, and framework wiring
+- browser tests for end-to-end user flows
+
+## Integration Tests
+
+Use `Microsoft.AspNetCore.Mvc.Testing` and `WebApplicationFactory<Program>` for integration tests.
+
+Guidance from the official docs:
+
+- use a test host and `HttpClient`
+- replace services with test doubles when needed
+- control redirects when asserting auth behavior
+- handle antiforgery correctly for form posts
+- prefer SQLite in-memory over the EF Core in-memory provider for more realistic database tests
+
+For SPA or browser-driven scenarios, Microsoft recommends browser automation such as Playwright for .NET.
+
+## Performance Defaults
+
+Reach for built-in features before custom optimization layers:
+
+- output caching
+- response caching where appropriate
+- response compression
+- HTTP request timeouts
+- rate limiting
+- static file handling
+
+General performance guidance:
+
+- measure first
+- keep database and network round trips visible
+- reduce payload size
+- use streaming or pagination when data is large
+- keep synchronous blocking out of hot paths
+
+## Health Checks And Observability
+
+Add health checks for dependencies that matter operationally.
+
+Use separate checks or tags when you need:
+
+- liveness
+- readiness
+- dependency-specific health surfaces
+
+Also ensure:
+
+- structured logs
+- request tracing where applicable
+- metrics for critical paths such as auth, API latency, and background work
+
+## Hosting And Deployment
+
+Typical deployment flow:
+
+1. `dotnet publish`
+2. deploy the publish output
+3. run behind a process manager
+4. place a reverse proxy in front when the environment requires it
+
+Know the deployment environment:
+
+- IIS or Windows Service on Windows
+- Kestrel plus Nginx or another reverse proxy on Linux
+- container hosting when the platform expects it
+
+Behind proxies or load balancers:
+
+- configure forwarded headers
+- validate scheme, host, and remote IP behavior
+- test auth redirects and callback URLs in the deployed topology
+
+## Operational Safeguards
+
+- add health checks for databases and critical external services
+- fail fast on invalid configuration where possible
+- keep secrets out of publish artifacts
+- verify data-protection key persistence in multi-instance deployments