create-genia-os 1.0.0

package/template/.genia/development/workflows/spec-pipeline.md

@@ -0,0 +1,192 @@
+# Workflow: Spec Pipeline
+
+> Transforma requisitos brutos em especificações técnicas executáveis.
+> Ordem de execução: @analyst → @pm → @architect → @qa → @po
+
+---
+
+## Visão Geral
+
+O Spec Pipeline é o processo obrigatório que antecede qualquer desenvolvimento. Ele garante que o time nunca implementa com base em requisitos vagos, PRDs incompletos ou especificações técnicas ausentes. Projetos que pulam este pipeline invariavelmente sofrem com retrabalho, scope creep e dívida técnica.
+
+**Duração estimada:** 2-5 dias úteis (dependendo da complexidade)
+**Ativador:** `@analyst iniciar spec-pipeline [nome-do-projeto]`
+
+---
+
+## Fase 1 — Briefing (@analyst)
+
+**Responsável:** Ana (@analyst)
+**Input:** Requisitos brutos do cliente/stakeholder (pode ser uma conversa, email, documento informal)
+**Output:** `docs/[projeto]/BRIEFING.md`
+
+### O que acontece:
+1. @analyst conduz sessão de discovery com stakeholders
+2. Coleta requisitos, regras de negócio, restrições e objetivos
+3. Identifica personas de usuário
+4. Documenta o não-escopo explicitamente
+5. Mapeia integrações necessárias
+6. Identifica riscos de negócio
+
+### Critérios de saída:
+- [ ] BRIEFING.md criado e completo
+- [ ] Todas as ambiguidades identificadas e resolvidas
+- [ ] Requisitos validados com pelo menos um stakeholder
+- [ ] Não-escopo documentado
+- [ ] Riscos de negócio identificados
+
+**→ Passa para @pm**
+
+---
+
+## Fase 2 — PRD (@pm)
+
+**Responsável:** Marina (@pm)
+**Input:** `docs/[projeto]/BRIEFING.md`
+**Output:** `docs/[projeto]/PRD.md`
+
+### O que acontece:
+1. @pm revisa o briefing e levanta dúvidas com @analyst
+2. Define visão de produto e proposta de valor
+3. Organiza funcionalidades em Épicos
+4. Prioriza usando framework MoSCoW
+5. Define métricas de sucesso do produto
+6. Documenta roadmap e milestones
+
+### Critérios de saída:
+- [ ] PRD.md criado com todos os Épicos
+- [ ] Priorização MoSCoW aplicada
+- [ ] Métricas de sucesso definidas
+- [ ] Não-escopo atualizado
+- [ ] Stakeholders consultados
+
+**→ Passa para @architect**
+
+---
+
+## Fase 3 — Avaliação Técnica (@architect)
+
+**Responsável:** Arqui (@architect)
+**Input:** `docs/[projeto]/PRD.md`
+**Output:** Avaliação formal com riscos, viabilidade e recomendações de stack
+
+### O que acontece:
+1. @architect lê o PRD e identifica implicações técnicas
+2. Avalia viabilidade de cada épico
+3. Identifica riscos técnicos e dependências
+4. Propõe stack tecnológica inicial
+5. Sinaliza itens que precisam de mais esclarecimento
+6. Pode exercer veto técnico sobre funcionalidades inviáveis
+
+### Critérios de saída:
+- [ ] Avaliação de viabilidade documentada
+- [ ] Riscos técnicos mapeados
+- [ ] Stack proposta com justificativas
+- [ ] Vetos (se houver) formalizados com alternativas
+- [ ] @pm alinhado sobre qualquer mudança de escopo
+
+**→ Passa para criação do SPEC-TECNICO**
+
+---
+
+## Fase 4 — Especificação Técnica (@architect)
+
+**Responsável:** Arqui (@architect)
+**Input:** `docs/[projeto]/PRD.md` + avaliação técnica
+**Output:** `docs/[projeto]/SPEC-TECNICO.md` + ADRs iniciais
+
+### O que acontece:
+1. @architect cria o SPEC-TECNICO.md completo
+2. Define arquitetura de alto nível
+3. Documenta modelagem de dados
+4. Especifica APIs e contratos de integração
+5. Define estratégia de testes
+6. Registra decisões arquiteturais como ADRs
+7. Define padrões de código e estrutura de pastas
+
+### Critérios de saída:
+- [ ] SPEC-TECNICO.md completo
+- [ ] Arquitetura documentada com diagrama
+- [ ] Modelagem de dados definida
+- [ ] APIs e integrações especificadas
+- [ ] Estratégia de testes definida
+- [ ] ADRs iniciais registrados
+
+**→ Passa para @qa**
+
+---
+
+## Fase 5 — Revisão Crítica (@qa)
+
+**Responsável:** Quinn (@qa)
+**Input:** `docs/[projeto]/PRD.md` + `docs/[projeto]/SPEC-TECNICO.md`
+**Output:** Relatório crítico de revisão
+
+### O que acontece:
+1. @qa lê o PRD e o SPEC-TECNICO em busca de inconsistências
+2. Identifica requisitos não-testáveis
+3. Verifica se os acceptance criteria futuros serão verificáveis
+4. Questiona pontos de falha não cobertos
+5. Propõe estratégia de testes de alto nível
+
+### Critérios de saída:
+- [ ] Inconsistências entre PRD e SPEC-TECNICO identificadas
+- [ ] Requisitos não-testáveis sinalizado
+- [ ] Estratégia de testes de alto nível documentada
+- [ ] @architect respondeu a todos os pontos críticos
+
+**→ Passa para @po**
+
+---
+
+## Fase 6 — Aprovação Final (@po)
+
+**Responsável:** Pax (@po)
+**Input:** PRD.md + SPEC-TECNICO.md revisados
+**Output:** Aprovação formal para início do desenvolvimento
+
+### O que acontece:
+1. @po revisa o backlog de épicos e funcionalidades
+2. Confirma que é possível criar stories claras para cada item
+3. Alinha priorização com @pm
+4. Emite aprovação formal para start do desenvolvimento
+5. Solicita @sm para iniciar criação de stories do primeiro épico
+
+### Critérios de saída:
+- [ ] PRD.md aprovado por @po e @pm
+- [ ] SPEC-TECNICO.md aprovado por @architect
+- [ ] Zero ambiguidades pendentes
+- [ ] @sm acionado para criar stories do Sprint 1
+
+---
+
+## Critérios Globais de Saída do Spec Pipeline
+
+Para que o Spec Pipeline seja considerado concluído:
+
+- [ ] `docs/[projeto]/BRIEFING.md` — completo e validado
+- [ ] `docs/[projeto]/PRD.md` — aprovado por @pm e @po
+- [ ] `docs/[projeto]/SPEC-TECNICO.md` — aprovado por @architect
+- [ ] ADRs iniciais registrados em `docs/adr/`
+- [ ] Zero ambiguidades de negócio pendentes
+- [ ] Zero riscos técnicos não-mitigados documentados
+- [ ] Stack tecnológica definida e aprovada
+- [ ] Time alinhado sobre o que será construído
+
+---
+
+## Como Ativar
+
+```
+@analyst iniciar spec-pipeline [nome-do-projeto]
+```
+
+Ou retomar de uma fase específica:
+```
+@pm criar-prd a partir do briefing em docs/[projeto]/BRIEFING.md
+@architect criar spec-técnico a partir do PRD em docs/[projeto]/PRD.md
+```
+
+---
+
+*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*

package/template/.genia/development/workflows/story-development-cycle.md

@@ -0,0 +1,252 @@
+# Workflow: Story Development Cycle (SDC)
+
+> Ciclo completo de desenvolvimento de uma story, da criação ao merge.
+> Ordem: @sm → @po → @dev → @qa → @reviewer → @devops
+
+---
+
+## Visão Geral
+
+O Story Development Cycle (SDC) é o coração do GEN.IA OS. Cada story percorre um ciclo rigoroso de criação, validação, desenvolvimento, revisão e entrega. Nenhuma etapa pode ser pulada. O SDC garante rastreabilidade completa de cada funcionalidade entregue.
+
+**Duração típica:** 1-5 dias por story (dependendo do tamanho)
+**Pré-requisito:** Spec Pipeline concluído (PRD.md + SPEC-TECNICO.md aprovados)
+
+---
+
+## Estados da Story
+
+```
+Draft → Ready → InProgress → InQA → InReview → InPR → Done
+```
+
+| Estado | Responsável | Significado |
+|--------|-------------|-------------|
+| Draft | @sm | Story criada, aguardando validação |
+| Ready | @po | Story validada, pronta para sprint |
+| InProgress | @dev | Em desenvolvimento |
+| InQA | @qa | Em revisão de qualidade |
+| InReview | @reviewer | Em code review |
+| InPR | @devops | PR criado, aguardando merge |
+| Done | @po | Story aceita e entregue |
+
+---
+
+## Fase 1 — Draft (@sm)
+
+**Responsável:** Sami (@sm)
+**Input:** Épico do PRD + SPEC-TECNICO para contexto técnico
+**Output:** `docs/stories/STORY-XXX.md` em status Draft
+
+### O que acontece:
+1. @sm identifica próxima story a ser criada com base no backlog priorizado por @po
+2. Cria o arquivo STORY-XXX.md seguindo o template padrão
+3. Escreve a User Story no formato correto
+4. Define mínimo 3 Acceptance Criteria mensuráveis e testáveis
+5. Documenta o não-escopo explicitamente
+6. Adiciona notas técnicas relevantes do SPEC-TECNICO
+7. Estima esforço (P/M/G/XG)
+
+### Critérios de saída:
+- [ ] STORY-XXX.md criado com template completo
+- [ ] User Story no formato "Como... quero... para..."
+- [ ] Mínimo 3 ACs mensuráveis
+- [ ] Não-escopo documentado
+- [ ] Épico pai referenciado
+- [ ] Status: Draft
+
+**→ Passa para @po**
+
+---
+
+## Fase 2 — Validate (@po)
+
+**Responsável:** Pax (@po)
+**Input:** `docs/stories/STORY-XXX.md` em Draft
+**Output:** Story aprovada (Ready) ou devolvida para revisão
+
+### O que acontece:
+1. @po executa checklist de validação 10-point
+2. Se aprovada: altera status para Ready e define prioridade no sprint
+3. Se reprovada: devolve para @sm com feedback específico e items a corrigir
+4. @sm ajusta e resubmete (sem limite de tentativas nesta fase)
+
+### Critérios de aprovação (10-point checklist):
+- [ ] Formato correto: "Como [persona], quero [ação], para [benefício]"
+- [ ] Persona identificada e definida no PRD
+- [ ] Valor explícito e mensurável
+- [ ] Mínimo 3 ACs, todos testáveis
+- [ ] Independente ou dependências mapeadas
+- [ ] Tamanho adequado para uma sprint
+- [ ] Estimável com as informações disponíveis
+- [ ] Não-escopo explícito
+- [ ] Épico pai identificado
+- [ ] DoD aplicável à story
+
+**Score mínimo: 9/10**
+
+**→ Status muda para Ready**
+
+---
+
+## Fase 3 — Ready (@po + @sm)
+
+**Responsável:** @po (prioridade) + @sm (sprint)
+**Status:** Ready
+
+A story está validada e entra no sprint backlog. @sm inclui na sprint planning e atribui ao @dev. Nenhum desenvolvimento começa sem story em Ready.
+
+---
+
+## Fase 4 — Develop (@dev)
+
+**Responsável:** Dev (@dev)
+**Input:** `docs/stories/STORY-XXX.md` em Ready + SPEC-TECNICO.md
+**Output:** Código implementado, testes escritos, commits locais
+
+### O que acontece:
+1. @dev lê completamente a story e o SPEC-TECNICO
+2. Cria o branch: `git checkout -b feat/STORY-XXX-descricao`
+3. Implementa o código seguindo os padrões arquiteturais
+4. Escreve testes unitários (coverage >= 80%)
+5. Executa lint, typecheck e testes localmente
+6. Comita com mensagem formatada (nunca faz push — exclusivo de @devops)
+7. Atualiza status da story para InProgress
+8. Ao concluir, notifica @qa
+
+### Critérios de saída:
+- [ ] Todos os ACs implementados
+- [ ] Testes unitários escritos (coverage >= 80%)
+- [ ] Lint passando sem warnings
+- [ ] Typecheck passando
+- [ ] Commits atômicos e bem descritos
+- [ ] Status: InQA
+
+**→ Passa para @qa**
+
+---
+
+## Fase 5 — QA Review (@qa)
+
+**Responsável:** Quinn (@qa)
+**Input:** Branch com código implementado
+**Output:** Relatório QA — APROVADO ou REPROVADO com bugs
+
+### O que acontece:
+1. @qa verifica cada Acceptance Criterion da story
+2. Executa testes (unitários, integração se houver)
+3. Verifica casos de borda e cenários negativos
+4. Documenta bugs encontrados com severidade
+5. Emite veredicto: APROVADO ou REPROVADO
+
+**QA Loop (máximo 5 iterações):**
+```
+@qa revisa → REPROVADO → @dev corrige → @qa re-revisa → ...
+```
+
+Se após 5 iterações ainda reprovado: escalar para @architect + @pm
+
+### Critérios de aprovação:
+- [ ] Todos os ACs verificados e passando
+- [ ] Zero bugs CRÍTICOS
+- [ ] Máximo 2 bugs ALTOS (documentados para correção futura)
+- [ ] Testes passando (>= 80% coverage)
+- [ ] Lint sem warnings
+- [ ] Status: InReview
+
+**→ Passa para @reviewer**
+
+---
+
+## Fase 6 — Code Review (@reviewer)
+
+**Responsável:** Rev (@reviewer)
+**Input:** Branch aprovado pelo @qa
+**Output:** LGTM (aprovado) ou mudanças solicitadas
+
+### O que acontece:
+1. @reviewer lê o diff completo da story
+2. Verifica corretude, arquitetura, segurança, legibilidade
+3. Emite aprovação (LGTM) ou lista de mudanças bloqueantes
+4. @dev corrige mudanças bloqueantes e notifica @reviewer
+5. @reviewer re-aprova
+
+### Critérios de aprovação:
+- [ ] Sem issues de segurança
+- [ ] Arquitetura consistente com SPEC-TECNICO
+- [ ] Imports absolutos usados
+- [ ] Código legível e manutenível
+- [ ] Testes de qualidade (testam comportamento, não implementação)
+- [ ] Status: InPR
+
+**→ Passa para @devops**
+
+---
+
+## Fase 7 — Push e PR (@devops)
+
+**Responsável:** Gate (@devops)
+**Input:** Branch aprovado por @qa e @reviewer
+**Output:** PR criado no repositório remoto
+
+### O que acontece:
+1. @devops verifica checklist pré-push
+2. Faz `git push -u origin feat/STORY-XXX-descricao`
+3. Cria Pull Request com template completo
+4. Atribui reviewers para merge
+5. Monitora CI/CD pipeline
+6. Faz merge após aprovação do PR e CI verde
+
+### Critérios de saída:
+- [ ] Push realizado sem erros
+- [ ] PR criado com descrição completa
+- [ ] CI/CD pipeline verde
+- [ ] PR mergeado para main
+- [ ] Status: Done
+
+---
+
+## Fase 8 — Done (@po)
+
+**Responsável:** Pax (@po)
+**Output:** Story marcada como Done, backlog atualizado
+
+### O que acontece:
+1. @po verifica que todos os ACs foram entregues conforme especificado
+2. Aceita a story formalmente (marca como Done)
+3. Atualiza o backlog
+4. Informa @pm sobre o progresso do épico
+
+---
+
+## Diagrama do Fluxo
+
+```
+@sm cria story (Draft)
+       ↓
+@po valida (Ready) ←── @sm corrige ──← REPROVADO
+       ↓
+@dev implementa (InProgress)
+       ↓
+@qa revisa (InQA) ←── @dev corrige ──← REPROVADO (max 5x)
+       ↓
+@reviewer revisa (InReview) ←── @dev corrige ──← CHANGES
+       ↓
+@devops push + PR (InPR)
+       ↓
+@po aceita (Done)
+```
+
+---
+
+## Regras Invioláveis do SDC
+
+1. Nunca pular a validação de @po — story não-validada não pode ser desenvolvida
+2. @dev nunca faz push — exclusivo de @devops
+3. QA Loop tem máximo 5 iterações — após isso, escalar
+4. Code review é obrigatório antes do push — sem exceção
+5. Story só vai para Done quando @po aceitar formalmente
+
+---
+
+*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*

package/template/.genia/guidelines/clean-code.md

@@ -0,0 +1,98 @@
+# Guideline: Clean Code
+
+> Padroes de codigo pragmaticos - conciso, direto, sem over-engineering.
+
+## Principios Core
+
+| Principio | Regra |
+|-----------|-------|
+| **SRP** | Single Responsibility - cada funcao/classe faz UMA coisa |
+| **DRY** | Don't Repeat Yourself - extrair duplicatas, reusar |
+| **KISS** | Keep It Simple - solucao mais simples que funciona |
+| **YAGNI** | You Aren't Gonna Need It - nao construir features nao usadas |
+| **Boy Scout** | Deixar codigo mais limpo do que encontrou |
+
+## Regras de Naming
+
+| Elemento | Convencao |
+|----------|-----------|
+| **Variaveis** | Revelar intencao: `userCount` nao `n` |
+| **Funcoes** | Verbo + substantivo: `getUserById()` nao `user()` |
+| **Booleans** | Forma de pergunta: `isActive`, `hasPermission`, `canEdit` |
+| **Constantes** | SCREAMING_SNAKE: `MAX_RETRY_COUNT` |
+
+> **Regra:** Se voce precisa de um comentario para explicar o nome, renomeie.
+
+## Regras de Funcao
+
+| Regra | Descricao |
+|-------|-----------|
+| **Pequena** | Max 20 linhas, idealmente 5-10 |
+| **Uma Coisa** | Faz uma coisa, faz bem |
+| **Um Nivel** | Um nivel de abstracao por funcao |
+| **Poucos Args** | Max 3 argumentos, preferir 0-2 |
+| **Sem Side Effects** | Nao mutar inputs inesperadamente |
+
+## Estrutura de Codigo
+
+| Padrao | Aplicar |
+|--------|---------|
+| **Guard Clauses** | Early returns para edge cases |
+| **Flat > Nested** | Evitar nesting profundo (max 2 niveis) |
+| **Composicao** | Funcoes pequenas compostas |
+| **Colocacao** | Manter codigo relacionado proximo |
+
+## Estilo de Codigo AI
+
+| Situacao | Acao |
+|----------|------|
+| Usuario pede feature | Escrever diretamente |
+| Usuario reporta bug | Corrigir, nao explicar |
+| Requisito nao claro | Perguntar, nao assumir |
+
+## Anti-Patterns
+
+| NAO Fazer | Fazer |
+|-----------|-------|
+| Comentar cada linha | Deletar comentarios obvios |
+| Helper para one-liner | Inline o codigo |
+| Factory para 2 objetos | Instanciacao direta |
+| utils.ts com 1 funcao | Colocar onde usado |
+| "First we import..." | Apenas escrever codigo |
+| Deep nesting | Guard clauses |
+| Magic numbers | Named constants |
+| God functions | Dividir por responsabilidade |
+
+## Antes de Editar Qualquer Arquivo
+
+| Pergunta | Por que |
+|----------|---------|
+| **O que importa este arquivo?** | Pode quebrar |
+| **O que este arquivo importa?** | Mudanca de interface |
+| **Quais testes cobrem isso?** | Testes podem falhar |
+| **E um componente compartilhado?** | Multiplos lugares afetados |
+
+> **Regra:** Editar arquivo + todos dependentes na MESMA tarefa.
+
+## Self-Check Antes de Completar
+
+| Check | Pergunta |
+|-------|----------|
+| **Objetivo alcancado?** | Fiz exatamente o que usuario pediu? |
+| **Arquivos editados?** | Modifiquei todos arquivos necessarios? |
+| **Codigo funciona?** | Testei/verifiquei a mudanca? |
+| **Sem erros?** | Lint e TypeScript passam? |
+| **Nada esquecido?** | Algum edge case perdido? |
+
+## Resumo
+
+| Fazer | Nao Fazer |
+|-------|-----------|
+| Escrever codigo direto | Escrever tutoriais |
+| Deixar codigo se auto-documentar | Adicionar comentarios obvios |
+| Corrigir bugs imediatamente | Explicar o fix primeiro |
+| Inline coisas pequenas | Criar arquivos desnecessarios |
+| Nomear coisas claramente | Usar abreviacoes |
+| Manter funcoes pequenas | Escrever funcoes 100+ linhas |
+
+> **Lembrar: O usuario quer codigo funcionando, nao uma aula de programacao.**

package/template/.genia/guidelines/testing.md

@@ -0,0 +1,176 @@
+# Guideline: Testing Patterns
+
+> Principios para suites de teste confiaveis.
+
+## Piramide de Testes
+
+```
+        /\          E2E (Poucos)
+       /  \         Fluxos criticos
+      /----\
+     /      \       Integration (Alguns)
+    /--------\      API, DB queries
+   /          \
+  /------------\    Unit (Muitos)
+                    Funcoes, classes
+```
+
+## Padrao AAA
+
+| Etapa | Proposito |
+|-------|-----------|
+| **Arrange** | Configurar dados de teste |
+| **Act** | Executar codigo sob teste |
+| **Assert** | Verificar resultado |
+
+## Selecao de Tipo de Teste
+
+| Tipo | Melhor Para | Velocidade |
+|------|-------------|------------|
+| **Unit** | Funcoes puras, logica | Rapido (<50ms) |
+| **Integration** | API, DB, servicos | Medio |
+| **E2E** | Fluxos criticos do usuario | Lento |
+
+## Principios de Unit Test
+
+### Bons Unit Tests (FIRST)
+
+| Principio | Significado |
+|-----------|-------------|
+| Fast | < 100ms cada |
+| Isolated | Sem deps externos |
+| Repeatable | Mesmo resultado sempre |
+| Self-checking | Sem verificacao manual |
+| Timely | Escritos com o codigo |
+
+### O Que Testar
+
+| Testar | Nao Testar |
+|--------|------------|
+| Business logic | Codigo do framework |
+| Edge cases | Libs de terceiros |
+| Error handling | Getters simples |
+
+## Principios de Integration Test
+
+### O Que Testar
+
+| Area | Foco |
+|------|------|
+| API endpoints | Request/response |
+| Database | Queries, transactions |
+| External services | Contratos |
+
+### Setup/Teardown
+
+| Fase | Acao |
+|------|------|
+| Before All | Conectar recursos |
+| Before Each | Resetar estado |
+| After Each | Limpar |
+| After All | Desconectar |
+
+## Principios de Mocking
+
+### Quando Fazer Mock
+
+| Mock | Nao Mock |
+|------|----------|
+| External APIs | Codigo sob teste |
+| Database (unit) | Dependencias simples |
+| Time/random | Funcoes puras |
+| Network | Stores in-memory |
+
+### Tipos de Mock
+
+| Tipo | Uso |
+|------|-----|
+| Stub | Retornar valores fixos |
+| Spy | Rastrear chamadas |
+| Mock | Definir expectativas |
+| Fake | Implementacao simplificada |
+
+## Organizacao de Testes
+
+### Naming
+
+| Padrao | Exemplo |
+|--------|---------|
+| Should behavior | "should return error when..." |
+| When condition | "when user not found..." |
+| Given-when-then | "given X, when Y, then Z" |
+
+### Agrupamento
+
+| Nivel | Uso |
+|-------|-----|
+| describe | Agrupar testes relacionados |
+| it/test | Caso individual |
+| beforeEach | Setup comum |
+
+## Dados de Teste
+
+### Estrategias
+
+| Abordagem | Uso |
+|-----------|-----|
+| Factories | Gerar dados de teste |
+| Fixtures | Datasets predefinidos |
+| Builders | Criacao fluente de objetos |
+
+### Principios
+- Usar dados realistas
+- Randomizar valores nao essenciais (faker)
+- Compartilhar fixtures comuns
+- Manter dados minimos
+
+## Best Practices
+
+| Pratica | Por que |
+|---------|---------|
+| Um assert por teste | Razao clara de falha |
+| Testes independentes | Sem dependencia de ordem |
+| Testes rapidos | Rodar frequentemente |
+| Nomes descritivos | Auto-documentacao |
+| Limpar | Evitar side effects |
+
+## Anti-Patterns
+
+| NAO Fazer | Fazer |
+|-----------|-------|
+| Testar implementacao | Testar comportamento |
+| Duplicar codigo de teste | Usar factories |
+| Setup complexo | Simplificar ou dividir |
+| Ignorar testes flaky | Corrigir causa raiz |
+| Pular cleanup | Resetar estado |
+
+## Exemplo de Teste
+
+```typescript
+describe('UserService', () => {
+  describe('createUser', () => {
+    it('should create user with valid data', async () => {
+      // Arrange
+      const userData = { name: 'John', email: 'john@test.com' };
+
+      // Act
+      const user = await userService.createUser(userData);
+
+      // Assert
+      expect(user.id).toBeDefined();
+      expect(user.name).toBe('John');
+    });
+
+    it('should throw error when email is invalid', async () => {
+      // Arrange
+      const userData = { name: 'John', email: 'invalid' };
+
+      // Act & Assert
+      await expect(userService.createUser(userData))
+        .rejects.toThrow('Invalid email');
+    });
+  });
+});
+```
+
+> **Lembrar:** Testes sao documentacao. Se alguem nao consegue entender o que o codigo faz pelos testes, reescreva-os.