@daniel-da-silva-alves/sddk 2.0.0

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

@@ -0,0 +1,96 @@
+# Template: Convenções de Nomenclatura do Projeto
+
+Use este template para gerar `.specs/standards/naming-conventions.md`. Preencha com as respostas do onboarding.
+
+```markdown
+# Convenções de Nomenclatura
+
+**Projeto**: {nome do projeto}
+**Última atualização**: {data}
+
+---
+
+## 1. Banco de Dados
+
+| Elemento | Convenção | Exemplo | Anti-exemplo |
+|:---|:---|:---|:---|
+| Tabelas | {ex: snake_case, plural} | {ex: `auth_users`} | {ex: `User`, `authUser`} |
+| Colunas | {ex: snake_case, singular} | {ex: `first_name`} | {ex: `firstName`, `FirstName`} |
+| Primary Keys | {ex: `id` (UUID v4)} | {ex: `id`} | {ex: `user_id`, `ID`} |
+| Foreign Keys | {ex: `{tabela_singular}_id`} | {ex: `user_id`} | {ex: `fk_user`, `userId`} |
+| Índices | {ex: `idx_{tabela}_{colunas}`} | {ex: `idx_users_email`} | {ex: `index1`} |
+| Enums (valores) | {ex: UPPER_SNAKE_CASE} | {ex: `PENDING_PAYMENT`} | {ex: `pendingPayment`} |
+| Timestamps | {ex: `created_at`, `updated_at`} | — | {ex: `createdAt`, `date_created`} |
+| Soft delete | {ex: `deleted_at` nullable} | — | {ex: `is_deleted`} |
+| Booleanos | {ex: `is_` prefix} | {ex: `is_active`} | {ex: `active`, `status`} |
+
+### Prefixos de Módulo (se aplicável)
+| Módulo | Prefixo | Exemplo |
+|:---|:---|:---|
+| {ex: Autenticação} | {ex: `auth_`} | {ex: `auth_users`, `auth_sessions`} |
+| {ex: Pagamentos} | {ex: `pay_`} | {ex: `pay_transactions`} |
+
+---
+
+## 2. Código ({linguagem})
+
+### Variáveis
+
+| Tipo | Convenção | Exemplo | Anti-exemplo |
+|:---|:---|:---|:---|
+| Variáveis locais | {ex: camelCase} | {ex: `userName`} | {ex: `user_name`, `UserName`} |
+| Constantes | {ex: UPPER_SNAKE_CASE} | {ex: `MAX_RETRIES`} | {ex: `maxRetries`} |
+| Booleanos | {ex: prefixo is/has/can/should} | {ex: `isAuthenticated`} | {ex: `authenticated`, `auth`} |
+| Arrays/Coleções | {ex: plural} | {ex: `activeUsers`} | {ex: `userList`, `data`} |
+
+### Funções
+
+| Tipo | Convenção | Exemplo | Anti-exemplo |
+|:---|:---|:---|:---|
+| Funções gerais | {ex: verbo + substantivo, camelCase} | {ex: `calculateTotal`} | {ex: `calc`, `doStuff`} |
+| Handlers | {ex: handle + evento específico} | {ex: `handleLoginSubmit`} | {ex: `handleClick`} |
+| Getters | {ex: get + o quê} | {ex: `getUserOrders`} | {ex: `getData`} |
+| Validadores | {ex: is/validate + o quê} | {ex: `isValidEmail`} | {ex: `check`} |
+| Transformadores | {ex: formato + To + formato} | {ex: `dtoToEntity`} | {ex: `convert`} |
+
+### Classes e Types
+
+| Tipo | Convenção | Exemplo | Anti-exemplo |
+|:---|:---|:---|:---|
+| Classes | {ex: PascalCase, substantivo} | {ex: `UserService`} | {ex: `userService`} |
+| Interfaces | {ex: PascalCase, sem prefixo I} | {ex: `UserProfile`} | {ex: `IUserProfile`} |
+| Types | {ex: PascalCase} | {ex: `OrderStatus`} | {ex: `TOrderStatus`} |
+| Enums | {ex: PascalCase singular} | {ex: `PaymentMethod`} | {ex: `PaymentMethods`} |
+
+### Componentes (Frontend)
+
+| Tipo | Convenção | Exemplo | Anti-exemplo |
+|:---|:---|:---|:---|
+| Componentes | {ex: PascalCase, específico} | {ex: `ProductCard`} | {ex: `Card`} |
+| Hooks | {ex: use + contexto} | {ex: `useOrderData`} | {ex: `useData`} |
+| Context | {ex: PascalCase + Context} | {ex: `AuthContext`} | {ex: `ctx`} |
+
+---
+
+## 3. Arquivos e Diretórios
+
+| Tipo | Convenção | Exemplo |
+|:---|:---|:---|
+| Componentes | {ex: PascalCase.tsx} | {ex: `ProductCard.tsx`} |
+| Hooks | {ex: camelCase.ts} | {ex: `useAuth.ts`} |
+| Utils | {ex: camelCase.ts} | {ex: `formatCurrency.ts`} |
+| Types | {ex: camelCase.ts} | {ex: `userTypes.ts`} |
+| Services | {ex: camelCase.service.ts} | {ex: `auth.service.ts`} |
+| Repositories | {ex: camelCase.repository.ts} | {ex: `user.repository.ts`} |
+| Migrations | {ex: NNN_descricao.sql} | {ex: `001_create_users.sql`} |
+
+---
+
+## 4. Git
+
+| Tipo | Convenção | Exemplo |
+|:---|:---|:---|
+| Branches | {ex: tipo/descricao-curta} | {ex: `feat/user-auth`, `fix/login-redirect`} |
+| Commits | {ex: Conventional Commits} | {ex: `feat(auth): add login endpoint`} |
+| Tags | {ex: semver} | {ex: `v1.2.3`} |
+```

package/sddk/skills/system-design-document/references/standards-onboarding-guide.md

@@ -0,0 +1,119 @@
+# Guia de Onboarding de Padrões do Projeto
+
+## Propósito
+
+Este guia instrui o agente a conduzir uma entrevista de onboarding para definir os padrões do projeto. Os padrões são salvos em `.specs/standards/` e funcionam como **memória estática persistente** — consultados por TODAS as features do projeto.
+
+## Quando Executar
+
+O onboarding é acionado pela **Skill SDD (Skill 2)** nos seguintes cenários:
+
+| Cenário | Ação |
+|:---|:---|
+| `.specs/standards/` **não existe** | Conduzir onboarding completo |
+| `.specs/standards/` **existe mas incompleto** | Perguntar se quer completar |
+| `.specs/standards/` **existe e completo** | Ler e respeitar, propor adições se necessário |
+
+## Estrutura de Standards
+
+```
+.specs/
+└── standards/
+    ├── architecture.md           ← Padrões arquiteturais (DDD, CQRS, BFF, etc.)
+    ├── naming-conventions.md     ← Nomenclatura (funções, tabelas, variáveis)
+    ├── design-system.md          ← Tokens, paleta, tipografia, componentes
+    ├── api-conventions.md        ← Padrões de API (REST, GraphQL, error format)
+    └── coding-standards.md       ← Boas práticas e princípios (SSOT, DRY, etc.)
+```
+
+## Fluxo do Onboarding
+
+### Passo 1: Verificação
+
+Verificar se `.specs/standards/` existe no projeto:
+- Se NÃO existe → prosseguir para Passo 2
+- Se existe → ler todos os arquivos e prosseguir diretamente para a entrevista técnica do SDD
+
+### Passo 2: Anúncio
+
+Anunciar ao usuário:
+> "Este projeto ainda não tem padrões definidos em `.specs/standards/`. Vou conduzir uma entrevista rápida para definir os padrões do projeto. Esses padrões serão usados como referência em TODAS as features futuras."
+
+### Passo 3: Entrevista por Categoria
+
+Para cada categoria, conduzir uma mini-entrevista via `ask_question`:
+
+#### 3.1 Arquitetura
+Perguntas a fazer:
+1. "Qual padrão arquitetural o projeto segue?" (opções: MVC, Clean Architecture, DDD, Hexagonal, Feature-Based, ou descrever)
+2. "Usa algum padrão avançado?" (opções: Event Sourcing, CQRS, BFF, Microserviços, Monolito, ou descrever)
+3. "Qual a estrutura de camadas/módulos?"
+4. "Há regras de dependência entre camadas?" (ex: Domain nunca importa Infrastructure)
+
+Gerar: `.specs/standards/architecture.md` usando template `references/standards-architecture-template.md`
+
+#### 3.2 Nomenclatura
+Perguntas a fazer:
+1. "Convenção para tabelas de banco?" (snake_case plural, PascalCase singular, etc.)
+2. "Convenção para colunas?" (snake_case, camelCase)
+3. "Convenção para chaves estrangeiras?" ({tabela}_id, fk_{tabela}, etc.)
+4. "Convenção para variáveis/funções JS/TS?" (camelCase, verbo+substantivo para funções)
+5. "Convenção para componentes React/Vue?" (PascalCase, kebab-case)
+6. "Convenção para arquivos?" (PascalCase para componentes, camelCase para utils, etc.)
+
+Gerar: `.specs/standards/naming-conventions.md` usando template `references/standards-naming-template.md`
+
+#### 3.3 Design System (se o projeto tem frontend)
+Perguntas a fazer:
+1. "O projeto tem design system definido?" (se sim, quais tokens)
+2. "Paleta de cores?" (primária, secundária, surface, error, etc.)
+3. "Tipografia?" (fonte principal, headings, sizes)
+4. "Espaçamentos?" (escala de spacing)
+5. "Border radius e shadows?" (tokens de forma)
+6. "Componentes base?" (Card, Button, Input — quais tokens usam)
+
+Gerar: `.specs/standards/design-system.md` usando template `references/standards-design-system-template.md`
+
+Se não tem frontend, marcar como "N/A — projeto backend-only".
+
+#### 3.4 Convenções de API (se tem API)
+Perguntas a fazer:
+1. "Padrão de API?" (REST, GraphQL, tRPC, gRPC)
+2. "Formato de response?" (envelope `{data, error, meta}`, flat, etc.)
+3. "Versionamento de API?" (/v1/, header, query param)
+4. "Padrão de erro?" (HTTP status + body padronizado)
+5. "Paginação?" (cursor, offset, keyset)
+6. "Autenticação em API?" (Bearer token, cookie, API key)
+
+Gerar: `.specs/standards/api-conventions.md` usando template `references/standards-api-template.md`
+
+#### 3.5 Boas Práticas e Princípios
+Perguntas a fazer:
+1. "Quais princípios o projeto adota?" (SSOT, DRY, KISS, YAGNI, SOLID — selecionar os relevantes)
+2. "Há regras de abstração?" (quando extrair função, componente, hook)
+3. "Tratamento de erros?" (custom exceptions, error boundary, etc.)
+4. "Logging?" (structured logging, níveis, o que logar)
+5. "Testes?" (estratégia, cobertura mínima, tipos de teste)
+
+Gerar: `.specs/standards/coding-standards.md` usando template `references/standards-coding-template.md`
+
+### Passo 4: Apresentação
+
+1. Apresentar resumo de todos os padrões definidos
+2. Perguntar: "Os padrões estão corretos? Deseja ajustar algo?"
+3. Salvar todos os arquivos em `.specs/standards/`
+
+### Passo 5: Continuar para SDD
+
+Após o onboarding, prosseguir normalmente com a Fase 1 do SDD (Análise do Contexto).
+
+---
+
+## Evolução Incremental
+
+Durante SDDs de features futuras, o agente pode propor adições aos standards:
+
+1. Se uma decisão técnica nova não está coberta pelos standards existentes
+2. Perguntar: "Essa decisão deve virar um padrão do projeto para futuras features?"
+3. Se sim, atualizar o arquivo de standards relevante
+4. Se não, documentar apenas no SDD da feature

package/sddk/skills/system-design-document/references/tech-stack-analysis.md

@@ -0,0 +1,84 @@
+# Guia de Análise e Sugestão de Stack Tecnológica
+
+## Como Detectar a Stack Existente
+
+Antes de sugerir qualquer tecnologia, analise o projeto existente do usuário:
+
+### Arquivos Indicadores
+
+| Arquivo | Indica |
+|:---|:---|
+| `package.json` | Node.js / JavaScript / TypeScript |
+| `tsconfig.json` | TypeScript |
+| `requirements.txt` / `pyproject.toml` | Python |
+| `Cargo.toml` | Rust |
+| `go.mod` | Go |
+| `pom.xml` / `build.gradle` | Java/Kotlin |
+| `Gemfile` | Ruby |
+| `composer.json` | PHP |
+
+### Dentro do `package.json` — Detectar Framework
+
+| Dependência | Framework |
+|:---|:---|
+| `next` | Next.js |
+| `nuxt` | Nuxt.js |
+| `react` (sem next) | React SPA (provavelmente Vite) |
+| `vue` (sem nuxt) | Vue.js SPA |
+| `@angular/core` | Angular |
+| `express` | Express.js |
+| `@nestjs/core` | NestJS |
+| `fastify` | Fastify |
+
+### Dentro do `requirements.txt` / `pyproject.toml` — Detectar Framework Python
+
+| Dependência | Framework |
+|:---|:---|
+| `django` | Django |
+| `fastapi` | FastAPI |
+| `flask` | Flask |
+| `sqlalchemy` | ORM SQLAlchemy |
+
+---
+
+## Como Sugerir Stack (Quando Não Há Projeto)
+
+Se o usuário está começando do zero, use estas perguntas para guiar a sugestão:
+
+### Pergunta 1: Tipo de Aplicação
+
+| Tipo | Stack Sugerida |
+|:---|:---|
+| **Web fullstack (SSR)** | Next.js + TypeScript + Prisma + PostgreSQL |
+| **Web SPA + API separada** | Vite + React + TypeScript (front) + NestJS ou FastAPI (back) |
+| **API/Backend only** | NestJS (TS) ou FastAPI (Python) |
+| **Mobile** | React Native + Expo ou Flutter |
+| **CLI tool** | Node.js + Commander ou Python + Click |
+
+### Pergunta 2: Prioridades do Projeto
+
+| Prioridade | Influência na Stack |
+|:---|:---|
+| **Performance** | Considerar Rust, Go, ou otimizações específicas |
+| **Velocidade de desenvolvimento** | Frameworks com mais abstrações (Next.js, Django) |
+| **Escalabilidade** | Microserviços, filas, cache distribuído |
+| **Simplicidade** | Monolito, ORM, framework full-featured |
+
+### Pergunta 3: Equipe
+
+| Contexto | Influência |
+|:---|:---|
+| Dev solo | Menos abstrações, full-stack frameworks |
+| Equipe pequena (2-5) | Monorepo, TypeScript end-to-end |
+| Equipe grande (5+) | Módulos bem definidos, CI/CD robusto |
+
+---
+
+## Regras para Sugestão
+
+1. **NUNCA sugira uma stack sem justificativa** — sempre explique o "porquê"
+2. **Considere a experiência do usuário** — não sugira Rust se o usuário é iniciante
+3. **Apresente no máximo 3 opções** — excesso de escolha paralisa
+4. **Inclua prós e contras** de cada opção
+5. **Use `ask_question`** para que o usuário escolha formalmente
+6. **Registre a decisão** com justificativa no SDD