create-genia-os 2.4.0 → 3.0.0

package/template/.genia/development/checklists/qa-gate.md

@@ -1,216 +0,0 @@
-# Checklist: QA Gate
-
-> Verificações que @qa executa para emitir veredicto de qualidade.
-> 7 verificações principais. Todas obrigatórias para aprovação.
-
----
-
-## O que é o QA Gate?
-
-O QA Gate é o checkpoint de qualidade que determina se o código pode avançar para code review e, posteriormente, para produção. @qa é a autoridade exclusiva para abrir ou fechar este gate. Um veredicto APROVADO pelo QA Gate é pré-requisito obrigatório para o code review por @reviewer.
-
----
-
-## Verificação 1 — Acceptance Criteria (Funcional)
-
-**Propósito:** Garantir que o código implementa exatamente o que foi prometido na story.
-
-Para cada AC da story:
-
-| AC | Cenário testado | Resultado |
-|----|----------------|---------|
-| AC-01 | [descrever como foi testado] | ✅ / ❌ |
-| AC-02 | [descrever como foi testado] | ✅ / ❌ |
-| AC-03 | [descrever como foi testado] | ✅ / ❌ |
-
-**Critério de passagem:** Todos os ACs com resultado ✅
-
-- [ ] Todos os ACs verificados manualmente
-- [ ] Happy path de cada AC funciona conforme descrito
-- [ ] Nenhum AC implementado parcialmente ou com workaround oculto
-- [ ] Comportamentos descritos nos ACs correspondem ao comportamento real
-
-**BLOQUEANTE se falhar.**
-
----
-
-## Verificação 2 — Testes Automáticos
-
-**Propósito:** Garantir que a suite de testes está saudável e cobrindo o código.
-
-```bash
-npm run test
-```
-
-- [ ] Todos os testes passando (zero falhas)
-- [ ] Nenhum teste em `skip` ou `xtest` sem justificativa documentada
-- [ ] Sem `test.only` que silencia outros testes
-
-```bash
-npm run coverage
-```
-
-- [ ] Coverage >= 80% nas linhas novas/modificadas
-- [ ] Relatório de coverage gerado e verificado
-
-**Resultados esperados:**
-```
-Test Suites: X passed, X total
-Tests:       X passed, X total
-Coverage:    XX% (>= 80%)
-```
-
-**BLOQUEANTE se falhar.**
-
----
-
-## Verificação 3 — Qualidade Estática
-
-**Propósito:** Garantir que o código segue os padrões de qualidade definidos.
-
-```bash
-npm run lint
-```
-
-- [ ] Zero erros de lint
-- [ ] Zero warnings de lint
-- [ ] Nenhuma regra desabilitada sem comentário explicativo
-
-```bash
-npm run typecheck
-```
-
-- [ ] Zero erros TypeScript
-- [ ] Sem `@ts-ignore` injustificado
-- [ ] Sem `any` como atalho para evitar tipagem
-
-**BLOQUEANTE se falhar.**
-
----
-
-## Verificação 4 — Cenários de Borda (Edge Cases)
-
-**Propósito:** Garantir que o código é robusto além dos cenários principais.
-
-Testar:
-
-- [ ] Campos obrigatórios vazios: o sistema se comporta corretamente?
-- [ ] Caracteres especiais em inputs de texto: sem injeção ou quebra?
-- [ ] Valores extremos (muito longos, muito curtos, zero, negativos): tratados?
-- [ ] Ações repetidas rapidamente (double-click em botões): sem efeito duplo?
-- [ ] Sem conexão ou timeout de API: mensagem de erro adequada?
-- [ ] Dados nulos/undefined vindos da API: sem crash?
-
-Documente cada cenário testado e o resultado.
-
-**ALTO se falhar em cenário relevante. BLOQUEANTE se causar crash ou corrupção de dados.**
-
----
-
-## Verificação 5 — Regressão
-
-**Propósito:** Garantir que as mudanças desta story não quebraram funcionalidades existentes.
-
-Testar as funcionalidades RELACIONADAS ao módulo modificado:
-
-- [ ] Funcionalidades adjacentes ainda funcionam corretamente
-- [ ] Navegação entre páginas relacionadas funciona
-- [ ] Integrações com outros módulos não foram quebradas
-- [ ] Dados persistidos anteriormente ainda são lidos corretamente
-
-Em projetos brownfield, a verificação de regressão é expandida e inclui teste dos fluxos críticos de produção.
-
-**CRÍTICO se houver regressão em funcionalidade existente.**
-
----
-
-## Verificação 6 — Segurança Básica
-
-**Propósito:** Identificar vulnerabilidades de segurança óbvias antes que cheguem ao code review.
-
-- [ ] Sem dados sensíveis expostos em respostas de API desnecessariamente
-- [ ] Endpoints protegidos retornam 401/403 sem autenticação válida
-- [ ] Inputs com caracteres especiais não quebram o sistema
-- [ ] Sem informações de stack trace expostas em respostas de erro para o usuário
-- [ ] Sem secrets visíveis em logs ou respostas de API
-- [ ] Rate limiting funcionando se implementado
-
-**CRÍTICO se encontrar vulnerabilidade de segurança.**
-
----
-
-## Verificação 7 — Experiência do Usuário Básica
-
-**Propósito:** Garantir que a entrega é usável e não causa frustração desnecessária.
-
-Para funcionalidades com interface:
-
-- [ ] Estados de loading presentes durante operações assíncronas?
-- [ ] Estado vazio (lista sem itens) tem tratamento visual adequado?
-- [ ] Mensagens de erro são compreensíveis para o usuário (não stack traces)?
-- [ ] Formulários fornecem feedback claro sobre campos inválidos?
-- [ ] Interface não quebra visualmente em resoluções comuns (desktop 1280px+, mobile 375px)?
-- [ ] Botões não ficam habilitados após ação que deveria desabilitá-los?
-
-Para funcionalidades de API:
-
-- [ ] Respostas de sucesso têm estrutura consistente?
-- [ ] Respostas de erro têm mensagem clara e código HTTP correto?
-- [ ] Documentação da API atualizada se necessário?
-
-**MÉDIO se falhar (não bloqueia, mas deve ser documentado).**
-
----
-
-## Sumário de Verificações
-
-| # | Verificação | Criticidade | Resultado |
-|---|-------------|------------|---------|
-| 1 | Acceptance Criteria atendidos | BLOQUEANTE | ✅ / ❌ |
-| 2 | Testes automáticos passando | BLOQUEANTE | ✅ / ❌ |
-| 3 | Lint + TypeScript limpos | BLOQUEANTE | ✅ / ❌ |
-| 4 | Edge cases tratados | ALTO | ✅ / ❌ |
-| 5 | Sem regressão | CRÍTICO | ✅ / ❌ |
-| 6 | Segurança básica | CRÍTICO | ✅ / ❌ |
-| 7 | UX básica adequada | MÉDIO | ✅ / ❌ |
-
----
-
-## Veredicto
-
-**APROVADO** quando:
-- Verificações 1, 2, 3 passam (obrigatórias)
-- Verificações 5, 6 passam (zero críticos)
-- Verificação 4 sem bugs ALTO ou com máx 2 documentados
-- Verificação 7 com issues documentados para backlog
-
-**REPROVADO** quando:
-- Qualquer verificação BLOQUEANTE falha
-- Verificação 5 ou 6 identificam bug CRÍTICO
-- Verificação 4 tem mais de 2 bugs ALTO
-
----
-
-## Registro do Veredicto
-
-```markdown
-## QA Gate — STORY-XXX — [APROVADO | REPROVADO]
-Data: YYYY-MM-DD | QA: Quinn (@qa) | Iteração: X/5
-
-| Verificação | Status |
-|-------------|--------|
-| 1. ACs | ✅ PASS |
-| 2. Testes | ✅ PASS |
-| 3. Estática | ✅ PASS |
-| 4. Edge cases | ⚠️ 1 bug MÉDIO documentado |
-| 5. Regressão | ✅ PASS |
-| 6. Segurança | ✅ PASS |
-| 7. UX | ✅ PASS |
-
-Veredicto: ✅ APROVADO
-Próximo passo: @reviewer para code review
-```
-
----
-
-*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*

package/template/.genia/development/checklists/story-dod.md

@@ -1,155 +0,0 @@
-# Checklist: Definition of Done (DoD) — Story
-
-> Critérios obrigatórios para uma story ser considerada Done.
-> Verificado por @po (negócio) + @qa (técnica) + @reviewer (código).
-
----
-
-## O que é o Definition of Done?
-
-O Definition of Done (DoD) é o conjunto de critérios acordados pelo time que define quando uma story está genuinamente pronta — não "tecnicamente funcionando", mas entregável com qualidade para o usuário final. Uma story que não atende ao DoD não é Done, independente de o código estar escrito.
-
----
-
-## Checklist Completo (10 Critérios)
-
-### Critério 1 — Acceptance Criteria Atendidos
-- [ ] Todos os ACs da story foram implementados
-- [ ] Todos os ACs foram verificados manualmente por @qa
-- [ ] @po confirmou que o comportamento atende à intenção de negócio
-- [ ] Não há ACs parcialmente implementados ou com workaround
-
-**Responsável de verificar:** @qa + @po
-
----
-
-### Critério 2 — Testes Passando
-- [ ] Todos os testes unitários passam: `npm run test`
-- [ ] Nenhum teste ignorado (`skip`, `xtest`, `.only`) sem justificativa documentada
-- [ ] Testes de regressão de funcionalidades existentes passando (se brownfield)
-
-**Responsável de verificar:** @qa
-
----
-
-### Critério 3 — Cobertura de Testes
-- [ ] Cobertura de testes >= 80% nas linhas novas/modificadas
-- [ ] Verificado com: `npm run coverage`
-- [ ] Linhas não cobertas têm justificativa (ex: código de fallback impossível de testar)
-
-**Responsável de verificar:** @qa
-
----
-
-### Critério 4 — Qualidade de Código (Lint + Types)
-- [ ] `npm run lint` — zero erros e zero warnings
-- [ ] `npm run typecheck` — zero erros TypeScript
-- [ ] Sem `any` injustificado
-- [ ] Imports absolutos com `@/` em todos os arquivos novos
-
-**Responsável de verificar:** @reviewer
-
----
-
-### Critério 5 — Sem Bugs Críticos
-- [ ] Zero bugs de severidade CRÍTICO pendentes
-- [ ] Máximo 2 bugs de severidade ALTO (documentados no backlog para sprint futuro)
-- [ ] Bugs de severidade MÉDIO e BAIXO documentados no backlog
-
-**Responsável de verificar:** @qa
-
----
-
-### Critério 6 — Code Review Aprovado
-- [ ] @reviewer realizou code review formal
-- [ ] Todos os itens BLOQUEANTES foram corrigidos
-- [ ] Aprovação (LGTM) emitida por @reviewer
-- [ ] Relatório de code review disponível em `docs/reviews/`
-
-**Responsável de verificar:** @reviewer
-
----
-
-### Critério 7 — Arquitetura Respeitada
-- [ ] Código segue os padrões do SPEC-TECNICO.md
-- [ ] Estrutura de pastas correta
-- [ ] Separação de responsabilidades respeitada
-- [ ] Nenhuma decisão arquitetural tomada sem aprovação de @architect
-
-**Responsável de verificar:** @reviewer (+ @architect se houver dúvida)
-
----
-
-### Critério 8 — PR Criado por @devops
-- [ ] Branch feito push para o remoto por @devops (nunca diretamente por @dev)
-- [ ] Pull Request criado com template completo
-- [ ] PR associado à story (referência no título ou body)
-- [ ] CI/CD pipeline verde no PR
-- [ ] PR mergeado para `main`
-
-**Responsável de verificar:** @devops
-
----
-
-### Critério 9 — Segurança Básica
-- [ ] Sem hardcoded secrets, tokens ou URLs de ambiente
-- [ ] Inputs validados e sanitizados onde necessário
-- [ ] Dados sensíveis não expostos em logs
-- [ ] Autenticação/autorização corretas nos endpoints protegidos
-
-**Responsável de verificar:** @reviewer + @qa
-
----
-
-### Critério 10 — Validação Final por @po
-- [ ] @po revisou o entregue e confirmou que atende à User Story
-- [ ] @po atualizou o status da story para `Done` no arquivo
-- [ ] @po atualizou o backlog para refletir a story entregue
-- [ ] Velocity do sprint atualizado
-
-**Responsável de verificar:** @po
-
----
-
-## Resumo Visual
-
-| # | Critério | Responsável | Bloqueante |
-|---|---------|------------|-----------|
-| 1 | Acceptance Criteria atendidos | @qa + @po | Sim |
-| 2 | Testes passando | @qa | Sim |
-| 3 | Coverage >= 80% | @qa | Sim |
-| 4 | Lint + Typecheck limpos | @reviewer | Sim |
-| 5 | Sem bugs críticos | @qa | Sim |
-| 6 | Code review aprovado | @reviewer | Sim |
-| 7 | Arquitetura respeitada | @reviewer | Sim |
-| 8 | PR criado e mergeado | @devops | Sim |
-| 9 | Segurança básica | @reviewer + @qa | Sim |
-| 10 | Validação final de @po | @po | Sim |
-
-**Todos os 10 critérios são obrigatórios.** Uma story com 9/10 critérios não é Done.
-
----
-
-## Processo de Verificação do DoD
-
-1. @qa verifica critérios 1, 2, 3, 5, 9 (parcial)
-2. @reviewer verifica critérios 4, 6, 7, 9 (parcial)
-3. @devops executa critério 8
-4. @po verifica critério 10 e confirma o Done
-
-Qualquer critério não atendido bloqueia a story de ir para Done.
-
----
-
-## DoD vs. Acceptance Criteria
-
-| | DoD | Acceptance Criteria |
-|-|-----|-------------------|
-| **Escopo** | Toda story | Específico por story |
-| **Quem define** | Time (imutável no sprint) | @sm + @po (por story) |
-| **O que avalia** | Qualidade do processo de entrega | Comportamento funcional |
-| **Pode variar** | Não (é padrão do time) | Sim (por story) |
-
----
-
-*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*

package/template/.genia/development/tasks/code-review.md

@@ -1,197 +0,0 @@
-# Task: Code Review
-
-> Tarefa executada por @reviewer. Revisão formal de código antes do merge.
-> Pré-requisito: @qa aprovou o código (story em InReview).
-
----
-
-## Objetivo
-
-Realizar revisão técnica completa do código implementado por @dev, verificando corretude, arquitetura, segurança, legibilidade e manutenibilidade. Emitir aprovação (LGTM) ou solicitar mudanças bloqueantes com feedback construtivo.
-
----
-
-## Pré-requisitos
-
-Antes de iniciar, confirme:
-
-- [ ] Story tem status `InReview`
-- [ ] @qa aprovou formalmente (relatório de QA disponível)
-- [ ] Branch está disponível para checkout/análise
-- [ ] @reviewer leu a story e os ACs
-
----
-
-## Passos de Execução
-
-### Passo 1 — Contexto e Preparação
-
-1. Leia a story completa (User Story, ACs, não-escopo)
-2. Leia o relatório de QA de @qa
-3. Revise as seções relevantes do SPEC-TECNICO.md
-4. Analise o diff completo:
-   ```bash
-   git diff main...feat/STORY-XXX-descricao
-   ```
-5. Liste mentalmente o que espera ver antes de começar a revisar
-
-### Passo 2 — Revisão de Corretude
-
-**O código faz o que deveria fazer?**
-
-- [ ] A lógica implementa corretamente cada AC?
-- [ ] Edge cases relevantes são tratados?
-- [ ] Erros são capturados e tratados adequadamente?
-- [ ] Mensagens de erro são úteis e claras?
-- [ ] Não há bugs óbvios de lógica (condições invertidas, off-by-one, etc.)?
-- [ ] Fluxos assíncronos são tratados corretamente (loading, error, success)?
-
-### Passo 3 — Revisão Arquitetural
-
-**O código está na estrutura correta?**
-
-- [ ] Segue os padrões do SPEC-TECNICO.md?
-- [ ] Imports absolutos com `@/` em todos os arquivos?
-- [ ] Componentes/funções estão nas pastas corretas conforme a estrutura definida?
-- [ ] Não viola separação de responsabilidades?
-- [ ] Não há código de lógica de negócio em componentes de UI (e vice-versa)?
-- [ ] Não há código duplicado que poderia ser extraído?
-- [ ] Dependências entre módulos respeitam os boundaries definidos?
-
-### Passo 4 — Revisão de Segurança
-
-**O código é seguro?**
-
-- [ ] Sem hardcoded secrets, tokens, passwords ou URLs de ambiente?
-- [ ] Input validation presente onde dados externos são consumidos?
-- [ ] Sem vulnerabilidades de XSS (dados de usuário inseridos no DOM sem sanitização)?
-- [ ] Autenticação e autorização corretas nos endpoints/páginas protegidas?
-- [ ] Dados sensíveis não aparecem em logs?
-- [ ] Sem SQL injection ou query injection possível?
-- [ ] Dependências externas verificadas (nenhuma suspeita adicionada)?
-
-### Passo 5 — Revisão de Qualidade de Código
-
-**O código é legível e manutenível?**
-
-- [ ] Nomes de variáveis, funções e componentes são descritivos?
-- [ ] Funções têm responsabilidade única (fazem uma coisa bem)?
-- [ ] Complexidade cognitiva é aceitável? (se você precisar de >30 segundos para entender uma função, é complexa demais)
-- [ ] Comentários existentes agregam valor (explicam o "por quê", não o "o quê")?
-- [ ] Não há código morto (código comentado, imports não usados, variáveis não usadas)?
-- [ ] TypeScript usado de forma efetiva (sem `any` injustificado, tipos bem definidos)?
-
-### Passo 6 — Revisão de Testes
-
-**Os testes são de qualidade?**
-
-- [ ] Testes existem para a funcionalidade implementada?
-- [ ] Os testes testam comportamento (o que o código faz), não implementação (como faz)?
-- [ ] Testes cobrem happy path, edge cases e cenários de erro?
-- [ ] Testes são legíveis? (outro dev entende o que está sendo testado sem precisar ler o código fonte)
-- [ ] Não há testes que testam a implementação de terceiros (React, bibliotecas)?
-- [ ] Coverage >= 80% conforme verificado por @qa?
-
-### Passo 7 — Revisão de Performance
-
-**O código tem problemas de performance óbvios?**
-
-- [ ] Sem N+1 queries (buscar dados dentro de um loop)?
-- [ ] Sem re-renders desnecessários (React — memoização faltando quando necessário)?
-- [ ] Operações custosas fora de loops quando possível?
-- [ ] Assets (imagens, fontes) otimizados se aplicável?
-- [ ] Sem chamadas de API desnecessárias?
-
-### Passo 8 — Categorização de Issues
-
-Para cada problema encontrado, classifique:
-
-| Categoria | Bloqueia merge? | Quando usar |
-|-----------|----------------|------------|
-| CRÍTICO | Sim | Segurança, dados corrompidos, crash |
-| BLOQUEANTE | Sim | Violação arquitetural, lógica incorreta, AC não implementado |
-| SUGESTÃO | Não | Nome melhor, refatoração opcional, documentação |
-| COSMÉTICO | Não | Formatação (já coberta por linter automático) |
-
-**Regra:** Não invente razões para reprovar. Se o código funciona, é seguro e está na arquitetura correta, aprove — mesmo que você tivesse feito diferente.
-
-### Passo 9 — Emissão do Veredicto
-
-**APROVADO (LGTM):**
-
-```markdown
-## ✅ Code Review — APROVADO
-Story: STORY-XXX | Branch: feat/STORY-XXX-descricao
-Revisor: Rev (@reviewer) | Data: YYYY-MM-DD
-
-### Pontos Positivos
-- [Algo bem feito que merece reconhecimento]
-- [Boa prática identificada]
-
-### Sugestões (Não-Bloqueantes)
-- [arquivo:linha] [sugestão para o futuro]
-- [arquivo:linha] [alternativa a considerar]
-
-LGTM. @devops pode fazer push e criar o PR.
-```
-
-**MUDANÇAS SOLICITADAS:**
-
-```markdown
-## ❌ Code Review — MUDANÇAS SOLICITADAS
-Story: STORY-XXX | Branch: feat/STORY-XXX-descricao
-Revisor: Rev (@reviewer) | Data: YYYY-MM-DD
-
-### Issues BLOQUEANTES (devem ser corrigidos antes do merge)
-
-1. **[CRÍTICO]** `src/components/Login/index.tsx:45`
-   Token da API hardcodado na linha 45.
-   **Correção:** mover para variável de ambiente `NEXT_PUBLIC_API_TOKEN`
-
-2. **[BLOQUEANTE]** `src/services/auth.ts:23`
-   Import relativo `../../lib/api` viola o padrão de imports absolutos.
-   **Correção:** mudar para `@/lib/api`
-
-### Sugestões (Não-Bloqueantes)
-1. `src/hooks/useAuth.ts:12` — considerar usar `useCallback` para o handler
-
-@dev por favor corrija os itens BLOQUEANTES e sinalize quando pronto para re-review.
-```
-
-### Passo 10 — Comunicação
-
-**Se APROVADO:**
-- Atualize status da story para `InPR`
-- Notifique @devops com: branch name, story ID, "aprovado para push e PR"
-
-**Se MUDANÇAS SOLICITADAS:**
-- Mantenha status como `InReview`
-- Notifique @dev com o relatório de mudanças
-- Aguarde @dev corrigir e sinalizar para re-review
-
----
-
-## Re-review
-
-Quando @dev notifica que corrigiu:
-
-1. Verifique APENAS os itens que foram sinalizados como BLOQUEANTES
-2. Se todos corrigidos: APROVAR
-3. Se algum não foi corrigido adequadamente: solicitar mudança novamente com mais clareza
-
----
-
-## Critérios de Saída
-
-O code review está concluído quando:
-
-- [ ] Diff completo lido e analisado
-- [ ] Todos os itens do checklist verificados
-- [ ] Issues categorizados (BLOQUEANTE vs. SUGESTÃO)
-- [ ] Veredicto emitido formalmente (APROVADO ou MUDANÇAS SOLICITADAS)
-- [ ] Relatório salvo em `docs/reviews/REVIEW-STORY-XXX.md`
-- [ ] Agente correto notificado (@devops ou @dev)
-
----
-
-*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*