@vodailoc/kilo-kit-mcp 1.1.0 → 1.1.1

package/skills/engineering/aspnet-core/references/ui-blazor.md

@@ -1,53 +1,53 @@
-# Blazor
-
-Primary docs:
-- https://learn.microsoft.com/aspnet/core/blazor/
-- https://learn.microsoft.com/aspnet/core/blazor/fundamentals/
-- https://learn.microsoft.com/aspnet/core/blazor/security/
-
-## Choose Blazor Deliberately
-
-Prefer Blazor when the UI itself should be built as reusable .NET components and the team wants a full-stack .NET model.
-
-Current guidance centers on the Blazor Web App model, which can combine:
-
-- static SSR for fast first render
-- interactive server rendering
-- interactive WebAssembly rendering
-- per-component render mode choices
-
-Use standalone Blazor WebAssembly only when the app is intentionally client-heavy or must run as static files without a server-rendered host.
-
-## Render Mode Heuristics
-
-- Start with static SSR when the page is mostly read-only and fast first paint matters
-- Use interactive server rendering when you want rich interactivity without shipping the full .NET runtime to the browser
-- Use interactive WebAssembly when offline capability, client-side execution, or browser-local compute is the point
-- Mix render modes only when the split is clear and justified
-
-## Component Patterns
-
-- Keep components focused and composable
-- Move data access and business rules into injected services
-- Pass data through parameters, not hidden global state
-- Use forms and validation with Blazor's built-in editing and validation components
-- Prefer shared Razor Class Libraries for reusable component sets
-
-## Data And Interactivity
-
-- Use DI in components with restraint; avoid turning components into service locators
-- Treat JS interop as an edge mechanism for browser APIs or third-party libraries, not the primary application model
-- Keep long-running work off the UI event path
-- Be deliberate about prerendering, streaming rendering, and enhanced navigation when they improve perceived performance
-
-## Security Notes
-
-- Follow the general ASP.NET Core security guidance first, then load the Blazor-specific docs for details that supersede it
-- Remember that client-side code and browser state are not trusted
-- Keep secrets and privileged operations on the server
-- Use authorization-aware UI only as a convenience layer; enforce rules on the server as well
-
-## When Not To Use Blazor
-
-- Do not force Blazor onto a mostly conventional server-rendered app that already fits Razor Pages or MVC well
-- Do not choose WebAssembly by default for small interaction needs that SSR or interactive server rendering handles more simply
+# Blazor
+
+Primary docs:
+- https://learn.microsoft.com/aspnet/core/blazor/
+- https://learn.microsoft.com/aspnet/core/blazor/fundamentals/
+- https://learn.microsoft.com/aspnet/core/blazor/security/
+
+## Choose Blazor Deliberately
+
+Prefer Blazor when the UI itself should be built as reusable .NET components and the team wants a full-stack .NET model.
+
+Current guidance centers on the Blazor Web App model, which can combine:
+
+- static SSR for fast first render
+- interactive server rendering
+- interactive WebAssembly rendering
+- per-component render mode choices
+
+Use standalone Blazor WebAssembly only when the app is intentionally client-heavy or must run as static files without a server-rendered host.
+
+## Render Mode Heuristics
+
+- Start with static SSR when the page is mostly read-only and fast first paint matters
+- Use interactive server rendering when you want rich interactivity without shipping the full .NET runtime to the browser
+- Use interactive WebAssembly when offline capability, client-side execution, or browser-local compute is the point
+- Mix render modes only when the split is clear and justified
+
+## Component Patterns
+
+- Keep components focused and composable
+- Move data access and business rules into injected services
+- Pass data through parameters, not hidden global state
+- Use forms and validation with Blazor's built-in editing and validation components
+- Prefer shared Razor Class Libraries for reusable component sets
+
+## Data And Interactivity
+
+- Use DI in components with restraint; avoid turning components into service locators
+- Treat JS interop as an edge mechanism for browser APIs or third-party libraries, not the primary application model
+- Keep long-running work off the UI event path
+- Be deliberate about prerendering, streaming rendering, and enhanced navigation when they improve perceived performance
+
+## Security Notes
+
+- Follow the general ASP.NET Core security guidance first, then load the Blazor-specific docs for details that supersede it
+- Remember that client-side code and browser state are not trusted
+- Keep secrets and privileged operations on the server
+- Use authorization-aware UI only as a convenience layer; enforce rules on the server as well
+
+## When Not To Use Blazor
+
+- Do not force Blazor onto a mostly conventional server-rendered app that already fits Razor Pages or MVC well
+- Do not choose WebAssembly by default for small interaction needs that SSR or interactive server rendering handles more simply

package/skills/engineering/aspnet-core/references/ui-mvc.md

@@ -1,56 +1,56 @@
-# MVC
-
-Primary docs:
-- https://learn.microsoft.com/aspnet/core/mvc/overview
-- https://learn.microsoft.com/aspnet/core/mvc/controllers/
-- https://learn.microsoft.com/aspnet/core/mvc/views/
-
-## Choose MVC When Actions And Views Matter
-
-Prefer MVC when the application benefits from explicit controllers, action-based routing, filters, view models, and a strong separation between orchestration and presentation.
-
-This is often the right fit for:
-
-- large server-rendered sites
-- applications with many cross-cutting filters or action conventions
-- applications that mix views and APIs in the same controller layer
-- teams already organized around controllers and views
-
-## Core Shape
-
-Enable MVC with views using:
-
-- `builder.Services.AddControllersWithViews();`
-- `app.MapControllerRoute(...)`
-
-Keep views focused on presentation. Keep controllers focused on HTTP orchestration. Put business rules in services.
-
-## Controller Guidance
-
-- Derive from `Controller` when the controller returns views
-- Keep actions small and explicit
-- Use model binding and validation instead of manual request parsing
-- Return view models, not EF entities, to views
-- Use POST-Redirect-GET for form submissions
-
-## View Guidance
-
-- Use layouts, partial views, and Tag Helpers to keep markup consistent
-- Keep complex display logic out of Razor markup when it becomes hard to follow
-- Use strongly typed view models
-- Avoid coupling views directly to persistence models
-
-## Structure And Scale
-
-- Use areas for large bounded sections such as Admin or BackOffice
-- Keep route conventions explicit
-- Apply filters when behavior truly belongs at the MVC layer
-- Avoid giant god controllers; split by cohesive feature or resource
-
-## Choosing MVC Over Razor Pages
-
-Prefer MVC over Razor Pages when:
-
-- multiple related actions share controller-level behavior
-- handler-level authorization or action filters matter
-- URL and action design are more natural than page-file routing
+# MVC
+
+Primary docs:
+- https://learn.microsoft.com/aspnet/core/mvc/overview
+- https://learn.microsoft.com/aspnet/core/mvc/controllers/
+- https://learn.microsoft.com/aspnet/core/mvc/views/
+
+## Choose MVC When Actions And Views Matter
+
+Prefer MVC when the application benefits from explicit controllers, action-based routing, filters, view models, and a strong separation between orchestration and presentation.
+
+This is often the right fit for:
+
+- large server-rendered sites
+- applications with many cross-cutting filters or action conventions
+- applications that mix views and APIs in the same controller layer
+- teams already organized around controllers and views
+
+## Core Shape
+
+Enable MVC with views using:
+
+- `builder.Services.AddControllersWithViews();`
+- `app.MapControllerRoute(...)`
+
+Keep views focused on presentation. Keep controllers focused on HTTP orchestration. Put business rules in services.
+
+## Controller Guidance
+
+- Derive from `Controller` when the controller returns views
+- Keep actions small and explicit
+- Use model binding and validation instead of manual request parsing
+- Return view models, not EF entities, to views
+- Use POST-Redirect-GET for form submissions
+
+## View Guidance
+
+- Use layouts, partial views, and Tag Helpers to keep markup consistent
+- Keep complex display logic out of Razor markup when it becomes hard to follow
+- Use strongly typed view models
+- Avoid coupling views directly to persistence models
+
+## Structure And Scale
+
+- Use areas for large bounded sections such as Admin or BackOffice
+- Keep route conventions explicit
+- Apply filters when behavior truly belongs at the MVC layer
+- Avoid giant god controllers; split by cohesive feature or resource
+
+## Choosing MVC Over Razor Pages
+
+Prefer MVC over Razor Pages when:
+
+- multiple related actions share controller-level behavior
+- handler-level authorization or action filters matter
+- URL and action design are more natural than page-file routing

package/skills/engineering/aspnet-core/references/ui-razor-pages.md

@@ -1,55 +1,55 @@
-# Razor Pages
-
-Primary docs:
-- https://learn.microsoft.com/aspnet/core/razor-pages/
-- https://learn.microsoft.com/aspnet/core/tutorials/razor-pages/
-
-## Choose Razor Pages For Page-Centered Apps
-
-Prefer Razor Pages when requests naturally map to pages, forms, and page-level handlers. This is a strong default for internal tools, CRUD apps, account flows, and admin surfaces.
-
-## Core Shape
-
-Enable Razor Pages with:
-
-- `builder.Services.AddRazorPages();`
-- `app.MapRazorPages();`
-
-Use the `@page` directive to turn a `.cshtml` file into an endpoint. Keep request logic in the paired `PageModel` class when the page is more than trivial.
-
-## Routing Model
-
-- File system location defines the route by default
-- `Pages/Index.cshtml` maps to `/`
-- `Pages/Store/Index.cshtml` maps to `/Store`
-- Keep folder structure meaningful because it becomes the URL structure
-
-## PageModel Guidance
-
-- Use `OnGet`, `OnPost`, and named handlers for request processing
-- Use bindable properties and model validation for forms
-- Keep page models thin; move business logic into injected services
-- Use Tag Helpers and model binding instead of manual request parsing
-
-## Good Fits
-
-- form-heavy workflows
-- dashboards and back-office applications
-- simple content with server-side validation
-- applications where a page is the primary navigation unit
-
-## Key Limitation
-
-Do not rely on per-handler authorization with Razor Pages. Microsoft explicitly recommends using MVC controllers when different handlers on the same logical surface need different authorization behavior.
-
-Preferred responses to that limitation:
-
-- split the handlers into separate pages
-- move the surface to MVC if action-level authorization is a better fit
-
-## Organizational Guidance
-
-- Group related pages into folders
-- Use partial views for repeated fragments
-- Use areas only when the application has clear bounded sections
-- Keep shared layout and page conventions centralized
+# Razor Pages
+
+Primary docs:
+- https://learn.microsoft.com/aspnet/core/razor-pages/
+- https://learn.microsoft.com/aspnet/core/tutorials/razor-pages/
+
+## Choose Razor Pages For Page-Centered Apps
+
+Prefer Razor Pages when requests naturally map to pages, forms, and page-level handlers. This is a strong default for internal tools, CRUD apps, account flows, and admin surfaces.
+
+## Core Shape
+
+Enable Razor Pages with:
+
+- `builder.Services.AddRazorPages();`
+- `app.MapRazorPages();`
+
+Use the `@page` directive to turn a `.cshtml` file into an endpoint. Keep request logic in the paired `PageModel` class when the page is more than trivial.
+
+## Routing Model
+
+- File system location defines the route by default
+- `Pages/Index.cshtml` maps to `/`
+- `Pages/Store/Index.cshtml` maps to `/Store`
+- Keep folder structure meaningful because it becomes the URL structure
+
+## PageModel Guidance
+
+- Use `OnGet`, `OnPost`, and named handlers for request processing
+- Use bindable properties and model validation for forms
+- Keep page models thin; move business logic into injected services
+- Use Tag Helpers and model binding instead of manual request parsing
+
+## Good Fits
+
+- form-heavy workflows
+- dashboards and back-office applications
+- simple content with server-side validation
+- applications where a page is the primary navigation unit
+
+## Key Limitation
+
+Do not rely on per-handler authorization with Razor Pages. Microsoft explicitly recommends using MVC controllers when different handlers on the same logical surface need different authorization behavior.
+
+Preferred responses to that limitation:
+
+- split the handlers into separate pages
+- move the surface to MVC if action-level authorization is a better fit
+
+## Organizational Guidance
+
+- Group related pages into folders
+- Use partial views for repeated fragments
+- Use areas only when the application has clear bounded sections
+- Keep shared layout and page conventions centralized

package/skills/engineering/aspnet-core/references/versioning-and-upgrades.md

@@ -1,51 +1,51 @@
-# Versioning And Upgrades
-
-Primary docs:
-- https://learn.microsoft.com/aspnet/core/release-notes/
-- https://learn.microsoft.com/aspnet/core/release-notes/aspnetcore-10.0
-- https://learn.microsoft.com/aspnet/core/release-notes/aspnetcore-9.0
-- https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/breaking-changes
-
-## Versioning Default
-
-- For new production apps in March 2026, prefer `net10.0`
-- For existing apps, match the repository's target framework unless the task is explicitly an upgrade
-- Before using a new API, confirm it exists in the target framework
-
-## Upgrade Workflow
-
-1. Identify the current target framework and SDK
-2. Read the "What's new" and breaking-changes pages for each version hop
-3. Compile and resolve obsoletions intentionally
-4. Re-run integration tests and auth flows
-5. Re-test deployment-specific behavior such as proxies, cookies, and static assets
-
-## High-Value Breaking-Change Checks
-
-When moving to ASP.NET Core 10, watch for:
-
-- cookie login redirects disabled for known API endpoints
-- `WithOpenApi` deprecation
-- `WebHostBuilder`, `IWebHost`, and `WebHost` obsolescence
-- Razor runtime compilation obsolescence
-
-When moving to ASP.NET Core 9, watch for:
-
-- `ValidateOnBuild` and `ValidateScopes` enabled in development when using `HostBuilder`
-- middleware constructor expectations and DI validation changes
-
-When moving to ASP.NET Core 8, watch for:
-
-- Minimal API `IFormFile` antiforgery requirements
-- `AddRateLimiter()` and `AddHttpLogging()` requirements when corresponding middleware is used
-
-## Migration Principles
-
-- Prefer migration to the modern hosting model when touching startup extensively
-- Remove compatibility shims only after tests confirm behavior
-- Avoid mixing new framework idioms with old startup architecture in a half-migrated state
-- Keep one authoritative target framework in project files unless multi-targeting is deliberate
-
-## Preview Feature Rule
-
-Do not introduce preview-only APIs or docs guidance unless the user explicitly asks for preview adoption or the repository is already on preview SDKs.
+# Versioning And Upgrades
+
+Primary docs:
+- https://learn.microsoft.com/aspnet/core/release-notes/
+- https://learn.microsoft.com/aspnet/core/release-notes/aspnetcore-10.0
+- https://learn.microsoft.com/aspnet/core/release-notes/aspnetcore-9.0
+- https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/breaking-changes
+
+## Versioning Default
+
+- For new production apps in March 2026, prefer `net10.0`
+- For existing apps, match the repository's target framework unless the task is explicitly an upgrade
+- Before using a new API, confirm it exists in the target framework
+
+## Upgrade Workflow
+
+1. Identify the current target framework and SDK
+2. Read the "What's new" and breaking-changes pages for each version hop
+3. Compile and resolve obsoletions intentionally
+4. Re-run integration tests and auth flows
+5. Re-test deployment-specific behavior such as proxies, cookies, and static assets
+
+## High-Value Breaking-Change Checks
+
+When moving to ASP.NET Core 10, watch for:
+
+- cookie login redirects disabled for known API endpoints
+- `WithOpenApi` deprecation
+- `WebHostBuilder`, `IWebHost`, and `WebHost` obsolescence
+- Razor runtime compilation obsolescence
+
+When moving to ASP.NET Core 9, watch for:
+
+- `ValidateOnBuild` and `ValidateScopes` enabled in development when using `HostBuilder`
+- middleware constructor expectations and DI validation changes
+
+When moving to ASP.NET Core 8, watch for:
+
+- Minimal API `IFormFile` antiforgery requirements
+- `AddRateLimiter()` and `AddHttpLogging()` requirements when corresponding middleware is used
+
+## Migration Principles
+
+- Prefer migration to the modern hosting model when touching startup extensively
+- Remove compatibility shims only after tests confirm behavior
+- Avoid mixing new framework idioms with old startup architecture in a half-migrated state
+- Keep one authoritative target framework in project files unless multi-targeting is deliberate
+
+## Preview Feature Rule
+
+Do not introduce preview-only APIs or docs guidance unless the user explicitly asks for preview adoption or the repository is already on preview SDKs.

package/skills/engineering/backend-development/SKILL.md

@@ -1,95 +1,95 @@
----
-name: backend-development
-description: Build robust backend systems with modern technologies (Node.js, Python, Go, Rust), frameworks (NestJS, FastAPI, Django), databases (PostgreSQL, MongoDB, Redis), APIs (REST, GraphQL, gRPC), authentication (OAuth 2.1, JWT), testing strategies, security best practices (OWASP Top 10), performance optimization, scalability patterns (microservices, caching, sharding), DevOps practices (Docker, Kubernetes, CI/CD), and monitoring. Use when designing APIs, implementing authentication, optimizing database queries, setting up CI/CD pipelines, handling security vulnerabilities, building microservices, or developing production-ready backend systems.
-license: MIT
-version: 1.0.0
----
-
-# Backend Development Skill
-
-Production-ready backend development with modern technologies, best practices, and proven patterns.
-
-## When to Use
-
-- Designing RESTful, GraphQL, or gRPC APIs
-- Building authentication/authorization systems
-- Optimizing database queries and schemas
-- Implementing caching and performance optimization
-- OWASP Top 10 security mitigation
-- Designing scalable microservices
-- Testing strategies (unit, integration, E2E)
-- CI/CD pipelines and deployment
-- Monitoring and debugging production systems
-
-## Technology Selection Guide
-
-**Languages:** Node.js/TypeScript (full-stack), Python (data/ML), Go (concurrency), Rust (performance)
-**Frameworks:** NestJS, FastAPI, Django, Express, Gin
-**Databases:** PostgreSQL (ACID), MongoDB (flexible schema), Redis (caching)
-**APIs:** REST (simple), GraphQL (flexible), gRPC (performance)
-
-See: `references/backend-technologies.md` for detailed comparisons
-
-## Reference Navigation
-
-**Core Technologies:**
-- `backend-technologies.md` - Languages, frameworks, databases, message queues, ORMs
-- `backend-api-design.md` - REST, GraphQL, gRPC patterns and best practices
-
-**Security & Authentication:**
-- `backend-security.md` - OWASP Top 10 2025, security best practices, input validation
-- `backend-authentication.md` - OAuth 2.1, JWT, RBAC, MFA, session management
-
-**Performance & Architecture:**
-- `backend-performance.md` - Caching, query optimization, load balancing, scaling
-- `backend-architecture.md` - Microservices, event-driven, CQRS, saga patterns
-
-**Quality & Operations:**
-- `backend-testing.md` - Testing strategies, frameworks, tools, CI/CD testing
-- `backend-code-quality.md` - SOLID principles, design patterns, clean code
-- `backend-devops.md` - Docker, Kubernetes, deployment strategies, monitoring
-- `backend-debugging.md` - Debugging strategies, profiling, logging, production debugging
-- `backend-mindset.md` - Problem-solving, architectural thinking, collaboration
-
-## Key Best Practices (2025)
-
-**Security:** Argon2id passwords, parameterized queries (98% SQL injection reduction), OAuth 2.1 + PKCE, rate limiting, security headers
-
-**Performance:** Redis caching (90% DB load reduction), database indexing (30% I/O reduction), CDN (50%+ latency cut), connection pooling
-
-**Testing:** 70-20-10 pyramid (unit-integration-E2E), Vitest 50% faster than Jest, contract testing for microservices, 83% migrations fail without tests
-
-**DevOps:** Blue-green/canary deployments, feature flags (90% fewer failures), Kubernetes 84% adoption, Prometheus/Grafana monitoring, OpenTelemetry tracing
-
-## Quick Decision Matrix
-
-| Need | Choose |
-|------|--------|
-| Fast development | Node.js + NestJS |
-| Data/ML integration | Python + FastAPI |
-| High concurrency | Go + Gin |
-| Max performance | Rust + Axum |
-| ACID transactions | PostgreSQL |
-| Flexible schema | MongoDB |
-| Caching | Redis |
-| Internal services | gRPC |
-| Public APIs | GraphQL/REST |
-| Real-time events | Kafka |
-
-## Implementation Checklist
-
-**API:** Choose style → Design schema → Validate input → Add auth → Rate limiting → Documentation → Error handling
-
-**Database:** Choose DB → Design schema → Create indexes → Connection pooling → Migration strategy → Backup/restore → Test performance
-
-**Security:** OWASP Top 10 → Parameterized queries → OAuth 2.1 + JWT → Security headers → Rate limiting → Input validation → Argon2id passwords
-
-**Testing:** Unit 70% → Integration 20% → E2E 10% → Load tests → Migration tests → Contract tests (microservices)
-
-**Deployment:** Docker → CI/CD → Blue-green/canary → Feature flags → Monitoring → Logging → Health checks
-
-## Resources
-
-- OWASP Top 10: https://owasp.org/www-project-top-ten/
-- OAuth 2.1: https://oauth.net/2.1/
-- OpenTelemetry: https://opentelemetry.io/
+---
+name: backend-development
+description: Build robust backend systems with modern technologies (Node.js, Python, Go, Rust), frameworks (NestJS, FastAPI, Django), databases (PostgreSQL, MongoDB, Redis), APIs (REST, GraphQL, gRPC), authentication (OAuth 2.1, JWT), testing strategies, security best practices (OWASP Top 10), performance optimization, scalability patterns (microservices, caching, sharding), DevOps practices (Docker, Kubernetes, CI/CD), and monitoring. Use when designing APIs, implementing authentication, optimizing database queries, setting up CI/CD pipelines, handling security vulnerabilities, building microservices, or developing production-ready backend systems.
+license: MIT
+version: 1.0.0
+---
+
+# Backend Development Skill
+
+Production-ready backend development with modern technologies, best practices, and proven patterns.
+
+## When to Use
+
+- Designing RESTful, GraphQL, or gRPC APIs
+- Building authentication/authorization systems
+- Optimizing database queries and schemas
+- Implementing caching and performance optimization
+- OWASP Top 10 security mitigation
+- Designing scalable microservices
+- Testing strategies (unit, integration, E2E)
+- CI/CD pipelines and deployment
+- Monitoring and debugging production systems
+
+## Technology Selection Guide
+
+**Languages:** Node.js/TypeScript (full-stack), Python (data/ML), Go (concurrency), Rust (performance)
+**Frameworks:** NestJS, FastAPI, Django, Express, Gin
+**Databases:** PostgreSQL (ACID), MongoDB (flexible schema), Redis (caching)
+**APIs:** REST (simple), GraphQL (flexible), gRPC (performance)
+
+See: `references/backend-technologies.md` for detailed comparisons
+
+## Reference Navigation
+
+**Core Technologies:**
+- `backend-technologies.md` - Languages, frameworks, databases, message queues, ORMs
+- `backend-api-design.md` - REST, GraphQL, gRPC patterns and best practices
+
+**Security & Authentication:**
+- `backend-security.md` - OWASP Top 10 2025, security best practices, input validation
+- `backend-authentication.md` - OAuth 2.1, JWT, RBAC, MFA, session management
+
+**Performance & Architecture:**
+- `backend-performance.md` - Caching, query optimization, load balancing, scaling
+- `backend-architecture.md` - Microservices, event-driven, CQRS, saga patterns
+
+**Quality & Operations:**
+- `backend-testing.md` - Testing strategies, frameworks, tools, CI/CD testing
+- `backend-code-quality.md` - SOLID principles, design patterns, clean code
+- `backend-devops.md` - Docker, Kubernetes, deployment strategies, monitoring
+- `backend-debugging.md` - Debugging strategies, profiling, logging, production debugging
+- `backend-mindset.md` - Problem-solving, architectural thinking, collaboration
+
+## Key Best Practices (2025)
+
+**Security:** Argon2id passwords, parameterized queries (98% SQL injection reduction), OAuth 2.1 + PKCE, rate limiting, security headers
+
+**Performance:** Redis caching (90% DB load reduction), database indexing (30% I/O reduction), CDN (50%+ latency cut), connection pooling
+
+**Testing:** 70-20-10 pyramid (unit-integration-E2E), Vitest 50% faster than Jest, contract testing for microservices, 83% migrations fail without tests
+
+**DevOps:** Blue-green/canary deployments, feature flags (90% fewer failures), Kubernetes 84% adoption, Prometheus/Grafana monitoring, OpenTelemetry tracing
+
+## Quick Decision Matrix
+
+| Need | Choose |
+|------|--------|
+| Fast development | Node.js + NestJS |
+| Data/ML integration | Python + FastAPI |
+| High concurrency | Go + Gin |
+| Max performance | Rust + Axum |
+| ACID transactions | PostgreSQL |
+| Flexible schema | MongoDB |
+| Caching | Redis |
+| Internal services | gRPC |
+| Public APIs | GraphQL/REST |
+| Real-time events | Kafka |
+
+## Implementation Checklist
+
+**API:** Choose style → Design schema → Validate input → Add auth → Rate limiting → Documentation → Error handling
+
+**Database:** Choose DB → Design schema → Create indexes → Connection pooling → Migration strategy → Backup/restore → Test performance
+
+**Security:** OWASP Top 10 → Parameterized queries → OAuth 2.1 + JWT → Security headers → Rate limiting → Input validation → Argon2id passwords
+
+**Testing:** Unit 70% → Integration 20% → E2E 10% → Load tests → Migration tests → Contract tests (microservices)
+
+**Deployment:** Docker → CI/CD → Blue-green/canary → Feature flags → Monitoring → Logging → Health checks
+
+## Resources
+
+- OWASP Top 10: https://owasp.org/www-project-top-ten/
+- OAuth 2.1: https://oauth.net/2.1/
+- OpenTelemetry: https://opentelemetry.io/