npm - create-genia-os - Versions diffs - 2.4.1 → 3.0.0 - Mend

create-genia-os 2.4.1 → 3.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (724) hide show

package/template/.genia/development/checklists/architecture-review.md DELETED Viewed

@@ -1,189 +0,0 @@
-# Checklist: Architecture Review
-> Verificações que @architect executa ao revisar decisões técnicas.
-> Aplicável em: SPEC-TECNICO, novos módulos, mudanças arquiteturais.
----
-## Objetivo
-Garantir que as decisões técnicas do projeto seguem princípios sólidos de arquitetura de software, são sustentáveis a longo prazo e não introduzem dívida técnica não-planejada. Este checklist é usado por @architect ao revisar especificações técnicas, propor arquitetura de novos componentes ou ao exercer veto técnico.
----
-## Seção 1 — Fundamentos Arquiteturais
-### 1.1 Clareza de Responsabilidades
-- [ ] Cada componente/módulo tem uma responsabilidade única e claramente definida?
-- [ ] Os boundaries de domínio estão bem delimitados?
-- [ ] Não há lógica de negócio misturada com lógica de apresentação?
-- [ ] Não há lógica de apresentação misturada com acesso a dados?
-- [ ] A separação de camadas é clara e respeitada?
-### 1.2 Simplicidade
-- [ ] A solução proposta é a mais simples que resolve o problema?
-- [ ] Não há over-engineering para problemas que não existem ainda?
-- [ ] A complexidade adicional (se houver) está justificada com dados ou requisitos reais?
-- [ ] Seria possível implementar uma versão mais simples que atende 90% dos casos?
-### 1.3 Consistência
-- [ ] As convenções seguem o padrão já estabelecido no SPEC-TECNICO.md?
-- [ ] Nomes de arquivos, variáveis e funções seguem as convenções definidas?
-- [ ] O estilo de código é consistente com o restante do codebase?
-- [ ] Padrões de comunicação (REST, eventos, etc.) são usados de forma consistente?
----
-## Seção 2 — Decisões de Tecnologia
-### 2.1 Adequação da Stack
-- [ ] As tecnologias escolhidas são adequadas para os requisitos do problema?
-- [ ] Há consenso técnico no time sobre as escolhas?
-- [ ] As versões de dependências são LTS ou estáveis?
-- [ ] Há risco de as tecnologias se tornarem obsoletas no prazo do projeto?
-### 2.2 Dependências Externas
-- [ ] Cada dependência nova é realmente necessária?
-- [ ] A licença da dependência é compatível com o projeto?
-- [ ] A dependência tem manutenção ativa e comunidade relevante?
-- [ ] Há alternativa nativa do framework/linguagem que poderia ser usada?
-- [ ] O tamanho da dependência no bundle é aceitável (para frontend)?
-### 2.3 ADR (Architecture Decision Records)
-- [ ] Cada decisão arquitetural significativa tem um ADR correspondente?
-- [ ] O ADR documenta: contexto, decisão, alternativas consideradas, consequências?
-- [ ] ADRs de decisões obsoletas estão marcados como superseded?
-- [ ] O time foi informado sobre novos ADRs?
----
-## Seção 3 — Qualidade e Testabilidade
-### 3.1 Testabilidade
-- [ ] Os componentes são testáveis de forma isolada (sem dependências externas difíceis de mockar)?
-- [ ] A lógica de negócio pode ser testada sem precisar de banco de dados real?
-- [ ] Há separação clara entre código puro (testável) e efeitos colaterais (IO)?
-- [ ] A arquitetura permite testes unitários sem configuração complexa de ambiente?
-### 3.2 Observabilidade
-- [ ] Há logging adequado para diagnosticar problemas em produção?
-- [ ] Os logs não incluem dados sensíveis (PII, senhas, tokens)?
-- [ ] Há métricas relevantes sendo coletadas?
-- [ ] Erros são tratados de forma que facilitem o diagnóstico?
-### 3.3 Manutenibilidade
-- [ ] Um desenvolvedor novo conseguiria entender o módulo em < 30 minutos?
-- [ ] Há documentação suficiente (inline ou em docs) para módulos complexos?
-- [ ] O código pode ser modificado em uma área sem causar efeitos inesperados em outra?
----
-## Seção 4 — Segurança
-### 4.1 Princípios de Segurança
-- [ ] Segurança foi considerada como parte do design (não como afterthought)?
-- [ ] Principle of Least Privilege: componentes têm apenas as permissões necessárias?
-- [ ] Dados sensíveis são criptografados em repouso e em trânsito?
-- [ ] Autenticação e autorização estão na camada correta?
-### 4.2 Vulnerabilidades Conhecidas
-- [ ] A arquitetura não expõe pontos de SQL/NoSQL injection?
-- [ ] Não há exposição desnecessária de endpoints internos?
-- [ ] Dados de usuário são validados e sanitizados na entrada?
-- [ ] CORS está configurado de forma restritiva?
-### 4.3 Gestão de Secrets
-- [ ] Secrets são gerenciados por variáveis de ambiente ou sistema de vault?
-- [ ] Não há paths de código que poderiam expor secrets em logs ou respostas?
-- [ ] Rotação de secrets é possível sem downtime?
----
-## Seção 5 — Escalabilidade e Performance
-### 5.1 Escalabilidade
-- [ ] A arquitetura suporta o crescimento esperado de usuários/dados?
-- [ ] Bottlenecks potenciais foram identificados e há plano de mitigação?
-- [ ] O sistema pode ser escalado horizontalmente se necessário?
-- [ ] Há estado compartilhado que impediria escalabilidade horizontal?
-### 5.2 Performance
-- [ ] Operações custosas (IO, cálculos pesados) são tratadas adequadamente (async, cache, queue)?
-- [ ] Não há N+1 queries no design do acesso a dados?
-- [ ] Caching foi considerado onde benéfico?
-- [ ] Assets e dados são carregados sob demanda quando possível?
----
-## Seção 6 — Evolução e Backward Compatibility
-### 6.1 Contratos de API
-- [ ] Mudanças em APIs públicas são backward-compatible?
-- [ ] Se breaking changes são necessários: estratégia de versionamento definida?
-- [ ] Contratos de integração com sistemas externos estão documentados?
-### 6.2 Dívida Técnica
-- [ ] Dívida técnica aceita está documentada com plano de resolução?
-- [ ] Decisões temporárias têm prazo de revisão definido?
-- [ ] Não há dívida técnica sendo criada sem consciência do time?
----
-## Sumário de Avaliação
-Após revisar todas as seções:
-| Seção | Itens com Problema | Severidade | Ação |
-|-------|-------------------|-----------|------|
-| 1. Fundamentos | X | ... | ... |
-| 2. Tecnologia | X | ... | ... |
-| 3. Qualidade | X | ... | ... |
-| 4. Segurança | X | ... | ... |
-| 5. Performance | X | ... | ... |
-| 6. Evolução | X | ... | ... |
----
-## Veredicto de @architect
-```markdown
-## Architecture Review — [Componente/Spec]
-Data: YYYY-MM-DD | Arquiteta: Arqui (@architect)
-### Veredicto: APROVADO | APROVADO COM CONDIÇÕES | VETADO
-### Pontos Fortes
-- [O que foi bem pensado]
-### Problemas Identificados
-- CRÍTICO: [problema crítico — veto técnico se não resolvido]
-- ALTO: [problema que deve ser resolvido antes de implementar]
-- MÉDIO: [problema que deve ser resolvido neste sprint]
-- SUGESTÃO: [melhoria opcional para próxima iteração]
-### Decisões Arquiteturais para ADR
-- [Decisão que merece ser documentada como ADR]
-### Próximos Passos
-[O que precisa acontecer antes de prosseguir]
-```
----
-*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*

package/template/.genia/development/checklists/pre-commit.md DELETED Viewed

@@ -1,205 +0,0 @@
-# Checklist: Pré-Commit
-> Verificações obrigatórias antes de qualquer commit.
-> Executado por @dev. Automatizável via git hooks.
----
-## Objetivo
-Garantir que nenhum commit "sujo" entre no histórico do repositório. Um commit deve ser uma unidade de mudança coesa, funcional e segura. Esta checklist previne problemas que são muito mais custosos de corrigir depois do commit.
----
-## Checklist Completo
-### Bloco 1 — Qualidade de Código (Obrigatório)
-```bash
-npm run lint
-```
-- [ ] Zero erros de lint
-- [ ] Zero warnings de lint (warnings são erros em potencial)
-- [ ] Nenhuma regra do ESLint desabilitada com `// eslint-disable` sem comentário explicativo
-```bash
-npm run typecheck
-```
-- [ ] Zero erros TypeScript
-- [ ] Nenhum `@ts-ignore` ou `@ts-expect-error` sem explicação no comentário
-- [ ] Sem `any` usado como atalho — tipagem explícita ou `unknown`
----
-### Bloco 2 — Testes (Obrigatório)
-```bash
-npm run test
-```
-- [ ] Todos os testes passando
-- [ ] Nenhum teste em `skip` ou `xtest` que foi esquecido
-- [ ] Nenhum `test.only` esquecido (faria outros testes serem ignorados no CI)
-```bash
-npm run coverage
-```
-- [ ] Coverage >= 80% nas linhas modificadas
-- [ ] Se coverage caiu abaixo de 80%: adicionar testes antes de commitar
----
-### Bloco 3 — Segurança (Obrigatório)
-Antes de executar `git add`, verifique todos os arquivos no diff:
-```bash
-git diff --staged
-```
-- [ ] Sem passwords, tokens, API keys ou secrets hardcodados
-- [ ] Sem credenciais de banco de dados no código
-- [ ] Sem URLs de ambiente hardcodadas (usar variáveis de ambiente)
-- [ ] Arquivo `.env` ou `.env.local` NÃO está sendo commitado
-- [ ] Sem chaves privadas (`.pem`, `.key`) no staged
-- [ ] Sem tokens de autenticação em nenhum arquivo
-**Se encontrar qualquer desses:** remova ANTES de commitar. Secrets no histórico git são permanentes e comprometem a segurança do projeto.
----
-### Bloco 4 — Limpeza de Código (Obrigatório)
-Leia o diff uma vez como se fosse o reviewer:
-- [ ] Sem `console.log`, `console.debug`, `console.warn` de debug esquecidos
-- [ ] Sem código comentado desnecessariamente (use `git stash` se quiser salvar)
-- [ ] Sem imports não utilizados
-- [ ] Sem variáveis declaradas e não utilizadas
-- [ ] Sem arquivos de teste manual esquecidos (`test.html`, `debug.js`, etc.)
----
-### Bloco 5 — Conformidade com Padrões (Obrigatório)
-- [ ] Todos os imports novos usam paths absolutos com `@/`
-- [ ] Nenhum import relativo com `../../` em arquivos novos
-- [ ] Nomenclatura seguindo os padrões do SPEC-TECNICO (camelCase, PascalCase)
-- [ ] Arquivos criados nas pastas corretas conforme estrutura definida
----
-### Bloco 6 — Formato do Commit (Obrigatório)
-A mensagem de commit deve seguir o formato:
-```
-tipo(escopo): descrição em imperativo presente
-[corpo opcional com contexto adicional]
-Story: STORY-XXX
-Co-Authored-By: GEN.IA OS <genia@bedata.com.br>
-```
-- [ ] Tipo válido: `feat`, `fix`, `refactor`, `test`, `docs`, `style`, `chore`
-- [ ] Escopo relevante ao módulo modificado
-- [ ] Descrição em imperativo: "adicionar", "corrigir", "implementar" (não "adicionado", "foi corrigido")
-- [ ] Descrição em até 72 caracteres na primeira linha
-- [ ] Story ID incluído quando aplicável
-- [ ] Co-authored-by incluído
-**Exemplos corretos:**
-```
-feat(auth): implementar formulário de login com validação de email
-fix(api): corrigir erro 500 ao criar usuário sem telefone
-test(payment): adicionar casos de teste para falha de pagamento
-```
-**Exemplos incorretos:**
-```
-update stuff
-fixing bug
-WIP
-feat: fiz várias coisas no componente de login e também corrigi um bug
-```
----
-### Bloco 7 — Atomicidade (Boas Práticas)
-- [ ] Este commit representa UMA mudança coesa e descritível em uma frase?
-- [ ] Se o commit precisaria de "e também" na descrição, considere dividir em 2 commits
-- [ ] Arquivos não relacionados a esta mudança NÃO estão em stage
-- [ ] Arquivos de configuração pessoal (`.vscode/settings.json` pessoal, etc.) não incluídos
----
-## Verificação Rápida Final
-Execute a sequência completa antes de `git commit`:
-```bash
-npm run lint && npm run typecheck && npm run test && echo "PRÉ-COMMIT OK ✓"
-```
-Se este comando terminar com `PRÉ-COMMIT OK ✓`, o commit pode ser feito.
-Se falhar: corrija o problema identificado antes de commitar.
----
-## Automatização com Git Hooks
-Para automatizar parte desta checklist, adicione o hook em `.git/hooks/pre-commit`:
-```bash
-#!/bin/sh
-echo "Executando verificações pré-commit..."
-npm run lint
-if [ $? -ne 0 ]; then
-  echo "BLOQUEADO: Lint falhou. Corrija os erros antes de commitar."
-  exit 1
-fi
-npm run typecheck
-if [ $? -ne 0 ]; then
-  echo "BLOQUEADO: TypeScript com erros. Corrija antes de commitar."
-  exit 1
-fi
-npm run test
-if [ $? -ne 0 ]; then
-  echo "BLOQUEADO: Testes falhando. Corrija antes de commitar."
-  exit 1
-fi
-echo "Verificações pré-commit concluídas. ✓"
-exit 0
-```
-Tornar executável:
-```bash
-chmod +x .git/hooks/pre-commit
-```
-**Nota:** @devops é responsável por configurar hooks em nível de projeto (usando Husky ou similar) para que se apliquem a todo o time.
----
-## Exceções
-Em situações excepcionais, @architect pode autorizar um commit que não passa em todas as verificações, com:
-- Registro documentado da exceção
-- Justificativa técnica
-- Issue criada para resolução imediata (no mesmo sprint)
-**Exceções nunca são a norma.** Se você se pega precisando de exceções frequentemente, o problema é no código ou no processo.
----
-*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*

package/template/.genia/development/checklists/pre-deploy.md DELETED Viewed

@@ -1,230 +0,0 @@
-# Checklist: Pré-Deploy
-> Verificações obrigatórias antes de qualquer deploy em produção.
-> Executado por @devops. Nenhum deploy acontece sem este checklist completo.
----
-## Objetivo
-Garantir que um deploy em produção seja seguro, reversível e comunicado adequadamente. Deploys sem checklist são causa comum de incidentes. Este checklist é o contrato de @devops com a estabilidade do sistema.
----
-## Regra de Ouro
-**Production nunca recebe código que não passou por staging.**
-Se staging não está estável, o deploy não acontece. Sem exceção.
----
-## Checklist Completo
-### Bloco 1 — Pré-Requisitos (Verificar ANTES de qualquer ação)
-- [ ] @pm aprovou formalmente a release (decisão de delivery documentada)
-- [ ] Todas as stories da release têm status `Done` (aprovadas por @po)
-- [ ] PRs de todas as stories estão mergeados em `main`
-- [ ] Branch `main` está sem conflitos pendentes
-- [ ] Não há incidentes abertos em produção no momento
----
-### Bloco 2 — Validação de Staging
-```bash
-# Verificar status do pipeline de staging
-gh run list --branch main --limit 5
-```
-- [ ] Pipeline CI/CD de staging: **verde** nos últimos 48h
-- [ ] Ambiente de staging está respondendo (health check passa)
-- [ ] Testes de integração em staging: passando
-- [ ] Funcionalidades da release verificadas em staging por @qa
-- [ ] Sem erros críticos nos logs de staging nas últimas 24h
----
-### Bloco 3 — Segurança
-- [ ] Security scan executado no código da release (sem vulnerabilidades CRÍTICAS)
-- [ ] Secrets e variáveis de ambiente de produção estão configurados
-- [ ] Nenhum secret de staging sendo usado em produção
-- [ ] Dependências verificadas por vulnerabilidades conhecidas (`npm audit`)
-- [ ] Certificados SSL/TLS válidos e não próximos do vencimento
-```bash
-npm audit --audit-level=critical
-```
-- [ ] Zero vulnerabilidades críticas em dependências
----
-### Bloco 4 — Banco de Dados (se aplicável)
-- [ ] Backup completo do banco de dados de produção realizado ANTES do deploy
-- [ ] Migrações de banco testadas em staging sem erros
-- [ ] Migrações são backward-compatible (se sistema precisa ser zero-downtime)
-- [ ] Script de rollback de migração existe e foi testado
-- [ ] Não há migrações destrutivas sem confirmação de @architect e @pm
-- [ ] Tempo estimado de migração documentado (se > 5 min: avisar usuários)
----
-### Bloco 5 — Variáveis de Ambiente e Configuração
-- [ ] Todas as variáveis de ambiente necessárias estão configuradas em produção
-- [ ] Nenhuma variável com valor de staging sendo usada em produção
-- [ ] Arquivo `.env.example` atualizado com novas variáveis necessárias
-- [ ] Configurações de feature flags (se usadas) verificadas
-```bash
-# Verificar variáveis críticas (sem expor valores)
-env | grep -E "(API_URL|DATABASE|AUTH)" | cut -d= -f1
-```
----
-### Bloco 6 — Performance e Capacidade
-- [ ] Build de produção gerado com sucesso (`npm run build`)
-- [ ] Tamanho do bundle verificado (sem regressão de performance inesperada)
-- [ ] Capacidade da infraestrutura verificada para o volume esperado
-- [ ] Cache invalidado/renovado conforme necessário
-```bash
-npm run build
-npm run build:analyze  # se disponível
-```
----
-### Bloco 7 — Plano de Rollback
-**Pré-requisito:** Plano de rollback DEVE existir ANTES de iniciar o deploy.
-- [ ] Versão anterior identificada: `v[X.X.X]`
-- [ ] Comando de rollback documentado e testado:
-  ```bash
-  # Exemplo para Vercel
-  vercel rollback [deployment-id]
-  # Exemplo para Railway
-  railway rollback
-  ```
-- [ ] Rollback de migração de banco documentado (se houver migração)
-- [ ] Tempo estimado para rollback: < 10 minutos
-- [ ] @architect e @pm notificados sobre plano de rollback
----
-### Bloco 8 — Comunicação e Janela de Deploy
-- [ ] Time notificado sobre a janela de deploy (com pelo menos 2h de antecedência)
-- [ ] Deploy agendado em horário de baixo tráfego (evitar horário de pico)
-- [ ] Evitar deploys em sexta-feira após 14h ou véspera de feriado
-- [ ] Suporte de plantão identificado para primeiras 2h após deploy
-- [ ] Canal de comunicação de incidentes configurado e verificado
-- [ ] Stakeholders que precisam ser notificados identificados
-**Janelas ideais de deploy:**
-- Segunda a quinta: 10h-12h ou 14h-16h
-- Evitar: sextas à tarde, vésperas de datas importantes, horário de pico de usuários
----
-### Bloco 9 — Monitoramento Pós-Deploy
-Configure alertas ANTES de iniciar o deploy:
-- [ ] Alertas de erro (5xx) configurados com threshold e notificação imediata
-- [ ] Dashboard de métricas aberto para monitoramento em tempo real
-- [ ] Health check endpoint identificado para verificação contínua
-- [ ] Plano de monitoramento por pelo menos 30 minutos após o deploy
----
-### Bloco 10 — Release Notes e Documentação
-- [ ] Release notes geradas e revisadas
-- [ ] CHANGELOG.md atualizado com as mudanças desta release
-- [ ] Documentação de APIs atualizada (se houve mudança de contrato)
-- [ ] Tag de versão criada: `git tag -a v[X.X.X] -m "Release v[X.X.X]"`
----
-## Execução do Deploy
-Após checklist completo, a sequência de deploy:
-```bash
-# 1. Tag a versão
-git tag -a v1.2.0 -m "Release v1.2.0: [descrição resumida]"
-git push origin v1.2.0
-# 2. Deploy (específico para cada plataforma)
-# Vercel: vercel --prod
-# Railway: railway up
-# AWS: [comando específico]
-# 3. Verificação imediata pós-deploy
-curl https://[url-producao]/health
-```
----
-## Protocolo de Incidente Durante Deploy
-Se algo der errado durante ou após o deploy:
-```
-NÍVEL 1 (degradação leve):
-→ Monitorar por 15 minutos
-→ Se não melhorar: NÍVEL 2
-NÍVEL 2 (funcionalidade impactada):
-→ Notificar @architect imediatamente
-→ Decidir: aguardar fix hotfix ou rollback
-→ Timeout de decisão: 30 minutos
-NÍVEL 3 (sistema fora do ar / dados em risco):
-→ ROLLBACK IMEDIATO
-→ Notificar @pm e @architect simultaneamente
-→ Comunicar usuários via [canal definido]
-→ Post-mortem obrigatório nas próximas 24h
-```
----
-## Verificação Pós-Deploy (Executar imediatamente após)
-- [ ] Health check em produção: passando
-- [ ] Testes de fumaça (smoke tests) em produção: passando
-- [ ] Logs de produção: sem erros críticos nos primeiros 5 minutos
-- [ ] Métricas de performance: normais (sem degradação)
-- [ ] @qa executou smoke tests em produção e confirmou estabilidade
-- [ ] @pm comunicado sobre sucesso do deploy
----
-## Confirmação de Conclusão
-```markdown
-## Deploy Concluído — v[X.X.X]
-Data/Hora: YYYY-MM-DD HH:MM
-Ambiente: Production
-Deploy executado por: Gate (@devops)
-Checklist: ✅ Completo
-Smoke tests: ✅ Passando
-Monitoramento: ✅ Ativo (30 min)
-Status: ✅ DEPLOY BEM-SUCEDIDO
-Próximo passo: @pm comunica stakeholders
-```
----
-*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*