@daniel-da-silva-alves/sddk 2.0.0 → 2.1.0

package/sddk/skills/system-design-document/references/standards-api-template.md

@@ -1,26 +1,26 @@
-# Template: Convenções de API do Projeto
+# Template: Project API Conventions
 
-Use este template para gerar `.specs/standards/api-conventions.md`. Preencha com as respostas do onboarding. Se o projeto não tem API, criar com "N/A — projeto sem API".
+Use this template to generate `.specs/standards/api-conventions.md`. Fill in with the onboarding interview answers. If the project has no API, create with "N/A — project without API".
 
 ```markdown
-# Convenções de API
+# API Conventions
 
-**Projeto**: {nome do projeto}
-**Última atualização**: {data}
+**Project**: {project name}
+**Last updated**: {date}
 
 ---
 
-## 1. Padrão de API
+## 1. API Pattern
 
-**Tipo**: {REST | GraphQL | tRPC | gRPC}
-**Versionamento**: {ex: URL path /api/v1/, header, nenhum}
-**Base URL**: {ex: /api/v1}
+**Type**: {REST | GraphQL | tRPC | gRPC}
+**Versioning**: {e.g.: URL path /api/v1/, header, none}
+**Base URL**: {e.g.: /api/v1}
 
 ---
 
-## 2. Formato de Response
+## 2. Response Format
 
-### Response de Sucesso
+### Success Response
 ```json
 {
   "data": { ... },
@@ -32,12 +32,12 @@ Use este template para gerar `.specs/standards/api-conventions.md`. Preencha com
 }
 ```
 
-### Response de Erro
+### Error Response
 ```json
 {
   "error": {
     "code": "{ERROR_CODE}",
-    "message": "{mensagem legível}",
+    "message": "{human-readable message}",
     "details": [ ... ]
   }
 }
@@ -45,44 +45,44 @@ Use este template para gerar `.specs/standards/api-conventions.md`. Preencha com
 
 ### HTTP Status Codes
 
-| Status | Quando usar |
+| Status | When to use |
 |:---|:---|
-| 200 | Sucesso (GET, PUT, PATCH) |
-| 201 | Recurso criado (POST) |
-| 204 | Sucesso sem body (DELETE) |
-| 400 | Validação / input inválido |
-| 401 | Não autenticado |
-| 403 | Não autorizado (sem permissão) |
-| 404 | Recurso não encontrado |
-| 409 | Conflito (ex: email já existe) |
-| 422 | Entidade não processável |
-| 429 | Rate limit excedido |
-| 500 | Erro interno do servidor |
+| 200 | Success (GET, PUT, PATCH) |
+| 201 | Resource created (POST) |
+| 204 | Success with no body (DELETE) |
+| 400 | Validation / invalid input |
+| 401 | Not authenticated |
+| 403 | Not authorized (no permission) |
+| 404 | Resource not found |
+| 409 | Conflict (e.g.: email already exists) |
+| 422 | Unprocessable entity |
+| 429 | Rate limit exceeded |
+| 500 | Internal server error |
 
 ---
 
-## 3. Naming de Endpoints
+## 3. Endpoint Naming
 
-| Regra | Exemplo correto | Exemplo errado |
+| Rule | Correct example | Wrong example |
 |:---|:---|:---|
-| Substantivos no plural | `/api/v1/users` | `/api/v1/user` |
-| Sem verbos na URL | `GET /users` | `GET /getUsers` |
-| Kebab-case para multi-palavras | `/order-items` | `/orderItems` |
-| Recursos aninhados | `/users/:id/orders` | `/getUserOrders` |
+| Plural nouns | `/api/v1/users` | `/api/v1/user` |
+| No verbs in URL | `GET /users` | `GET /getUsers` |
+| Kebab-case for multi-word | `/order-items` | `/orderItems` |
+| Nested resources | `/users/:id/orders` | `/getUserOrders` |
 
 ---
 
-## 4. Paginação
+## 4. Pagination
 
-**Tipo**: {cursor | offset | keyset}
+**Type**: {cursor | offset | keyset}
 
-### Formato de Request
-{ex para offset:}
+### Request Format
+{e.g. for offset:}
 ```
 GET /api/v1/users?page=2&per_page=20
 ```
 
-### Formato de Response (meta)
+### Response Format (meta)
 ```json
 {
   "meta": {
@@ -96,33 +96,33 @@ GET /api/v1/users?page=2&per_page=20
 
 ---
 
-## 5. Filtros e Ordenação
+## 5. Filters and Sorting
 
-### Filtros
+### Filters
 ```
 GET /api/v1/users?status=active&role=admin
 ```
 
-### Ordenação
+### Sorting
 ```
 GET /api/v1/users?sort=created_at&order=desc
 ```
 
 ---
 
-## 6. Autenticação
+## 6. Authentication
 
-**Método**: {ex: Bearer Token (JWT) via header Authorization}
+**Method**: {e.g.: Bearer Token (JWT) via Authorization header}
 **Header**: `Authorization: Bearer {token}`
-**Refresh**: {ex: via POST /api/v1/auth/refresh com refresh token em httpOnly cookie}
+**Refresh**: {e.g.: via POST /api/v1/auth/refresh with refresh token in httpOnly cookie}
 
 ---
 
-## 7. Validação
+## 7. Validation
 
-| Regra | Descrição |
+| Rule | Description |
 |:---|:---|
-| Validação no backend | TODA input é validada no servidor, independente do frontend |
-| Mensagens de erro | Retornar campo + mensagem específica |
-| Formato de erro de validação | `{"error": {"code": "VALIDATION_ERROR", "details": [{"field": "email", "message": "Email inválido"}]}}` |
+| Backend validation | ALL input is validated on the server, regardless of frontend |
+| Error messages | Return field + specific message |
+| Validation error format | `{"error": {"code": "VALIDATION_ERROR", "details": [{"field": "email", "message": "Invalid email"}]}}` |
 ```

package/sddk/skills/system-design-document/references/standards-architecture-template.md

@@ -1,76 +1,76 @@
-# Template: Padrões Arquiteturais do Projeto
+# Template: Project Architectural Standards
 
-Use este template para gerar `.specs/standards/architecture.md`. Preencha com as respostas do onboarding.
+Use this template to generate `.specs/standards/architecture.md`. Fill in with the onboarding interview answers.
 
 ```markdown
-# Padrões Arquiteturais do Projeto
+# Project Architectural Standards
 
-**Projeto**: {nome do projeto}
-**Última atualização**: {data}
+**Project**: {project name}
+**Last updated**: {date}
 
 ---
 
-## 1. Padrão Arquitetural Base
+## 1. Base Architectural Pattern
 
-**Padrão**: {ex: Domain-Driven Design (DDD)}
-**Justificativa**: {por que este padrão}
+**Pattern**: {e.g.: Domain-Driven Design (DDD)}
+**Justification**: {why this pattern}
 
-### Camadas e Responsabilidades
+### Layers and Responsibilities
 
-| Camada | Responsabilidade | Pode importar de | NÃO pode importar de |
+| Layer | Responsibility | Can import from | CANNOT import from |
 |:---|:---|:---|:---|
-| {ex: Domain} | {ex: Entidades, Value Objects, regras de negócio} | {nenhuma} | {Application, Infrastructure, Presentation} |
-| {ex: Application} | {ex: Use Cases, DTOs, Ports} | {Domain} | {Infrastructure, Presentation} |
-| {ex: Infrastructure} | {ex: Repositories, API clients, DB} | {Domain, Application} | {Presentation} |
-| {ex: Presentation} | {ex: Controllers, Views, Components} | {Application} | {Domain, Infrastructure} |
+| {e.g.: Domain} | {e.g.: Entities, Value Objects, business rules} | {none} | {Application, Infrastructure, Presentation} |
+| {e.g.: Application} | {e.g.: Use Cases, DTOs, Ports} | {Domain} | {Infrastructure, Presentation} |
+| {e.g.: Infrastructure} | {e.g.: Repositories, API clients, DB} | {Domain, Application} | {Presentation} |
+| {e.g.: Presentation} | {e.g.: Controllers, Views, Components} | {Application} | {Domain, Infrastructure} |
 
-### Estrutura de Diretórios Padrão
+### Default Directory Structure
 
 ```
 src/
-├── {camada1}/
-├── {camada2}/
-├── {camada3}/
-└── {camada4}/
+├── {layer1}/
+├── {layer2}/
+├── {layer3}/
+└── {layer4}/
 ```
 
 ---
 
-## 2. Padrões Avançados
+## 2. Advanced Patterns
 
-### {ex: Event Sourcing}
-- **Usado em**: {módulos/contextos onde se aplica}
-- **NÃO usado em**: {módulos onde NÃO se aplica}
-- **Implementação**: {detalhes técnicos}
+### {e.g.: Event Sourcing}
+- **Used in**: {modules/contexts where it applies}
+- **NOT used in**: {modules where it does NOT apply}
+- **Implementation**: {technical details}
 
-### {ex: BFF (Backend for Frontend)}
-- **Escopo**: {cada frontend tem seu BFF? ou BFF único?}
-- **Regra**: {BFF contém lógica de negócio? Ou apenas orquestra?}
+### {e.g.: BFF (Backend for Frontend)}
+- **Scope**: {does each frontend have its own BFF? or a single BFF?}
+- **Rule**: {does BFF contain business logic? Or only orchestrates?}
 
-### {ex: CQRS (Command Query Responsibility Segregation)}
-- **Usado em**: {onde se aplica}
-- **Command**: {como são os commands}
-- **Query**: {como são as queries}
+### {e.g.: CQRS (Command Query Responsibility Segregation)}
+- **Used in**: {where it applies}
+- **Command**: {what commands look like}
+- **Query**: {what queries look like}
 
 ---
 
-## 3. Regras de Dependência
+## 3. Dependency Rules
 
 > [!IMPORTANT]
-> Estas regras NUNCA devem ser violadas. Violação é classificada como 🔴 Crítica no Code Review.
+> These rules must NEVER be violated. Violations are classified as 🔴 Critical in Code Review.
 
-1. {ex: Domain NUNCA importa de Infrastructure}
-2. {ex: Use Cases orquestram, NUNCA contêm lógica de domínio pura}
-3. {ex: Cada Aggregate tem seu próprio Repository}
-4. {ex: Repositories retornam Domain Entities, não DTOs}
+1. {e.g.: Domain NEVER imports from Infrastructure}
+2. {e.g.: Use Cases orchestrate, NEVER contain pure domain logic}
+3. {e.g.: Each Aggregate has its own Repository}
+4. {e.g.: Repositories return Domain Entities, not DTOs}
 
 ---
 
-## 4. Princípios de Design
+## 4. Design Principles
 
-| Princípio | Como aplicamos |
+| Principle | How we apply it |
 |:---|:---|
-| {ex: SSOT} | {ex: Estado vive no banco. Cache é derivado, nunca fonte primária} |
-| {ex: Separation of Concerns} | {ex: Cada módulo tem responsabilidade única} |
-| {ex: Fail Fast} | {ex: Validar inputs na borda do sistema} |
+| {e.g.: SSOT} | {e.g.: State lives in the database. Cache is derived, never the primary source} |
+| {e.g.: Separation of Concerns} | {e.g.: Each module has a single responsibility} |
+| {e.g.: Fail Fast} | {e.g.: Validate inputs at the system boundary} |
 ```

package/sddk/skills/system-design-document/references/standards-coding-template.md

@@ -1,63 +1,63 @@
-# Template: Boas Práticas e Padrões de Código
+# Template: Coding Best Practices and Standards
 
-Use este template para gerar `.specs/standards/coding-standards.md`. Preencha com as respostas do onboarding.
+Use this template to generate `.specs/standards/coding-standards.md`. Fill in with the onboarding interview answers.
 
 ```markdown
-# Boas Práticas e Padrões de Código
+# Coding Best Practices and Standards
 
-**Projeto**: {nome do projeto}
-**Última atualização**: {data}
+**Project**: {project name}
+**Last updated**: {date}
 
 ---
 
-## 1. Princípios Adotados
+## 1. Adopted Principles
 
-| Princípio | O que significa NESTE projeto | Exemplo |
+| Principle | What it means IN THIS project | Example |
 |:---|:---|:---|
-| **SSOT** (Single Source of Truth) | {ex: Estado vive no banco. Cache é derivado.} | {ex: Não manter contadores em 2 tabelas} |
-| **DRY** (Don't Repeat Yourself) | {ex: Extrair quando repetir ≥ 2 vezes} | {ex: apiClient centralizado, não fetch repetido} |
-| **KISS** (Keep It Simple) | {ex: Preferir solução simples à elegante} | {ex: Usar map/filter ao invés de reduce complexo} |
-| **YAGNI** (You Aren't Gonna Need It) | {ex: Não implementar features "por garantia"} | {ex: Não criar abstração genérica para 1 uso} |
-| **SOLID** | {quais princípios do SOLID o projeto segue explicitamente} | — |
+| **SSOT** (Single Source of Truth) | {e.g.: State lives in the database. Cache is derived.} | {e.g.: Don't maintain counters in 2 tables} |
+| **DRY** (Don't Repeat Yourself) | {e.g.: Extract when repeating ≥ 2 times} | {e.g.: Centralized apiClient, not repeated fetch} |
+| **KISS** (Keep It Simple) | {e.g.: Prefer simple solution over elegant} | {e.g.: Use map/filter instead of complex reduce} |
+| **YAGNI** (You Aren't Gonna Need It) | {e.g.: Don't implement features "just in case"} | {e.g.: Don't create generic abstraction for 1 use} |
+| **SOLID** | {which SOLID principles the project explicitly follows} | — |
 
 ---
 
-## 2. Regras de Abstração
+## 2. Abstraction Rules
 
-### Quando Extrair uma Função
-- {ex: Quando o bloco é usado ≥ 2 vezes}
-- {ex: Quando o bloco tem mais de 10 linhas e pode ter nome descritivo}
-- {ex: Quando o bloco faz algo semanticamente independente}
+### When to Extract a Function
+- {e.g.: When the block is used ≥ 2 times}
+- {e.g.: When the block has more than 10 lines and can have a descriptive name}
+- {e.g.: When the block does something semantically independent}
 
-### Quando Criar um Componente
-- {ex: Quando a UI é reutilizada em ≥ 2 lugares}
-- {ex: Quando o componente tem mais de ~100 linhas}
-- {ex: Quando tem estado ou lógica própria}
+### When to Create a Component
+- {e.g.: When the UI is reused in ≥ 2 places}
+- {e.g.: When the component has more than ~100 lines}
+- {e.g.: When it has its own state or logic}
 
-### Quando Criar um Hook (React)
-- {ex: Quando lógica stateful é usada em ≥ 2 componentes}
-- {ex: Quando o componente fica mais limpo separando a lógica}
+### When to Create a Hook (React)
+- {e.g.: When stateful logic is used in ≥ 2 components}
+- {e.g.: When the component becomes cleaner by separating the logic}
 
-### Quando Criar um Service
-- {ex: Quando a lógica de negócio não pertence ao componente/controller}
-- {ex: Quando a mesma operação é usada em múltiplos endpoints/páginas}
+### When to Create a Service
+- {e.g.: When business logic doesn't belong to the component/controller}
+- {e.g.: When the same operation is used across multiple endpoints/pages}
 
 ---
 
-## 3. Tratamento de Erros
+## 3. Error Handling
 
-### Estratégia por Camada
+### Strategy by Layer
 
-| Camada | Estratégia |
+| Layer | Strategy |
 |:---|:---|
-| **Domain** | {ex: Lançar custom exceptions (DomainError, ValidationError)} |
-| **Application/Service** | {ex: Capturar domain errors, traduzir para DTOs de erro} |
-| **API/Controller** | {ex: Error handler global, mapear exceptions para HTTP status} |
-| **Frontend** | {ex: Error Boundary para crashes, toast para erros de ação} |
+| **Domain** | {e.g.: Throw custom exceptions (DomainError, ValidationError)} |
+| **Application/Service** | {e.g.: Catch domain errors, translate to error DTOs} |
+| **API/Controller** | {e.g.: Global error handler, map exceptions to HTTP status} |
+| **Frontend** | {e.g.: Error Boundary for crashes, toast for action errors} |
 
-### Custom Exceptions (se aplicável)
+### Custom Exceptions (if applicable)
 ```typescript
-// Hierarquia de erros do projeto
+// Project error hierarchy
 class AppError extends Error { code: string; statusCode: number; }
 class ValidationError extends AppError { fields: FieldError[]; }
 class NotFoundError extends AppError { }
@@ -65,50 +65,50 @@ class UnauthorizedError extends AppError { }
 class ConflictError extends AppError { }
 ```
 
-### Mensagens de Erro
-- {ex: Mensagens voltadas ao usuário, nunca stack traces}
-- {ex: Logging do erro completo no servidor, mensagem limpa no client}
-- {ex: Códigos de erro padronizados (ERROR_CODE) para o frontend mapear}
+### Error Messages
+- {e.g.: User-facing messages, never stack traces}
+- {e.g.: Full error logging on the server, clean message on the client}
+- {e.g.: Standardized error codes (ERROR_CODE) for the frontend to map}
 
 ---
 
 ## 4. Logging
 
-### Estratégia
-- **Formato**: {ex: Structured logging (JSON)}
-- **Níveis**: {ex: error, warn, info, debug}
-- **Ferramenta**: {ex: pino, winston, console estruturado}
+### Strategy
+- **Format**: {e.g.: Structured logging (JSON)}
+- **Levels**: {e.g.: error, warn, info, debug}
+- **Tool**: {e.g.: pino, winston, structured console}
 
-### O que Logar
+### What to Log
 
-| Nível | Quando usar | Exemplo |
+| Level | When to use | Example |
 |:---|:---|:---|
-| `error` | Falhas que impedem a operação | Erro de conexão DB, exception não tratada |
-| `warn` | Situações anormais mas recuperáveis | Rate limit próximo, fallback ativado |
-| `info` | Eventos de negócio importantes | Usuário criado, pagamento processado |
-| `debug` | Detalhes para debugging | Query SQL executada, payload recebido |
+| `error` | Failures that prevent the operation | DB connection error, unhandled exception |
+| `warn` | Abnormal but recoverable situations | Rate limit approaching, fallback activated |
+| `info` | Important business events | User created, payment processed |
+| `debug` | Details for debugging | SQL query executed, received payload |
 
-### O que NUNCA Logar
-- Senhas, tokens, chaves de API
-- Dados pessoais sensíveis (CPF, cartão de crédito)
-- Payloads completos de request em produção
+### What to NEVER Log
+- Passwords, tokens, API keys
+- Sensitive personal data (SSN, credit card)
+- Full request payloads in production
 
 ---
 
-## 5. Testes (se aplicável)
+## 5. Testing (if applicable)
 
-### Estratégia
-- **Tipo principal**: {ex: Testes manuais via manual-tests.md}
-- **Cobertura mínima**: {ex: N/A — foco em testes manuais}
-- **Quando automatizar**: {ex: Lógica de domínio crítica (cálculos, validações)}
+### Strategy
+- **Primary type**: {e.g.: Manual tests via manual-tests.md}
+- **Minimum coverage**: {e.g.: N/A — focus on manual tests}
+- **When to automate**: {e.g.: Critical domain logic (calculations, validations)}
 
 ---
 
 ## 6. Performance
 
-### Regras Gerais
-- {ex: Queries de listagem DEVEM ter paginação (máximo 100 por página)}
-- {ex: N+1 queries são proibidas — usar eager loading / join}
-- {ex: Imagens devem ser otimizadas (WebP, lazy loading)}
-- {ex: Bundle splitting para rotas de frontend}
+### General Rules
+- {e.g.: Listing queries MUST have pagination (maximum 100 per page)}
+- {e.g.: N+1 queries are prohibited — use eager loading / join}
+- {e.g.: Images must be optimized (WebP, lazy loading)}
+- {e.g.: Bundle splitting for frontend routes}
 ```