create-genia-os 2.4.0 → 3.0.0

package/template/.genia/development/workflows/brownfield.md

@@ -1,178 +0,0 @@
-# Workflow: Brownfield
-
-> Para evoluir sistemas já em produção. Primeiro entender, depois mudar.
-> Ordem: @architect → @qa → @architect + @dev → @pm → @sm → SDC
-
----
-
-## Visão Geral
-
-O workflow Brownfield é usado quando o projeto já tem código em produção, usuários ativos e histórico de decisões técnicas. Diferente do Greenfield, qualquer mudança pode ter impacto direto em funcionalidades existentes. A palavra de ordem é cautela e investigação antes de ação.
-
-**Quando usar:** Sistema existente em produção, adição de features a produto ativo, migração tecnológica gradual
-**Duração da fase de discovery:** 3-7 dias (dependendo da complexidade do sistema)
-**Pré-requisito:** Acesso ao repositório existente e documentação disponível
-
----
-
-## Fase 1 — Discovery (@architect)
-
-**Responsável:** Arqui (@architect)
-**Output:** Mapa arquitetural do sistema atual (`docs/discovery/ARQUITETURA-ATUAL.md`)
-
-### O que acontece:
-1. @architect mergulha no código existente:
-   - Lê os principais arquivos de configuração
-   - Mapeia a estrutura de pastas e módulos
-   - Identifica padrões (ou ausência deles) no código
-2. Documenta a arquitetura atual:
-   - Linguagens e frameworks em uso
-   - Banco de dados e estratégia de dados
-   - Integrações externas ativas
-   - Sistemas de autenticação/autorização
-   - Pipelines CI/CD existentes (se houver)
-3. Identifica decisões arquiteturais implícitas (sem ADR documentado)
-4. Mapeia pontos de acoplamento alto e riscos de mudança
-5. Avalia a saúde geral do codebase
-
-### Entregáveis:
-- `docs/discovery/ARQUITETURA-ATUAL.md`
-- Diagrama de componentes e fluxos principais
-- Lista de tecnologias e versões em uso
-- Pontos críticos de risco documentados
-
----
-
-## Fase 2 — Auditoria de Qualidade (@qa)
-
-**Responsável:** Quinn (@qa)
-**Output:** `docs/discovery/AUDITORIA-QA.md`
-
-### O que acontece:
-1. @qa analisa a cobertura de testes existente (ou ausência)
-2. Executa ferramentas de análise estática se disponíveis
-3. Identifica:
-   - Áreas sem cobertura de teste (risk zones)
-   - Padrões de código inconsistentes
-   - Dívida técnica acumulada
-   - Bugs conhecidos não resolvidos
-4. Cria mapa de risco: quais áreas têm mais chance de quebrar com mudanças?
-5. Define estratégia de testes para o projeto de evolução
-
-### Entregáveis:
-- `docs/discovery/AUDITORIA-QA.md`
-- Mapa de risco de mudanças por módulo
-- Estratégia de testes proposta
-- Lista de dívida técnica priorizada
-
----
-
-## Fase 3 — Análise de Impacto (@architect + @dev)
-
-**Responsáveis:** Arqui (@architect) + Dev (@dev)
-**Input:** ARQUITETURA-ATUAL.md + AUDITORIA-QA.md + requisitos das mudanças desejadas
-**Output:** `docs/discovery/ANALISE-IMPACTO.md`
-
-### O que acontece:
-1. @architect e @dev mapeiam juntos o impacto de cada mudança proposta:
-   - Quais módulos serão afetados?
-   - Há risco de breaking changes?
-   - Quais integrações podem ser impactadas?
-2. Definem estratégia de migração (big bang vs. gradual vs. strangler fig)
-3. Identificam testes de regressão necessários
-4. Estimam esforço de cada mudança considerando o estado atual do código
-5. @architect documenta ADRs para decisões de evolução
-
-### Entregáveis:
-- `docs/discovery/ANALISE-IMPACTO.md`
-- ADRs de evolução arquitetural
-- Estratégia de migração definida
-- Estimativas de esforço ajustadas para o contexto brownfield
-
----
-
-## Fase 4 — Épico de Evolução (@pm)
-
-**Responsável:** Marina (@pm)
-**Input:** ANALISE-IMPACTO.md + requisitos do cliente
-**Output:** PRD atualizado com épico de evolução + `docs/[projeto]/PRD-EVOLUCAO.md`
-
-### O que acontece:
-1. @pm revisa os impactos e ajusta escopo se necessário
-2. Cria épico de evolução no backlog com base real nas estimativas
-3. Define o que é refatoração necessária vs. nova funcionalidade
-4. Alinha expectativas com stakeholders sobre complexidade adicional do brownfield
-5. Define critérios de sucesso para a evolução
-
-### Importante:
-Em brownfield, @pm frequentemente precisa negociar prazo adicional para lidar com:
-- Testes de regressão
-- Compatibilidade retroativa
-- Migração gradual de dados
-- Rollback planejado
-
----
-
-## Fase 5 — Stories com Consciência Brownfield (@sm)
-
-**Responsável:** Sami (@sm) em colaboração com @architect
-**Output:** Stories com notas técnicas específicas de compatibilidade
-
-### O que acontece:
-1. @sm cria stories considerando o contexto brownfield
-2. Cada story inclui:
-   - **Notas de compatibilidade:** o que não pode quebrar
-   - **Testes de regressão:** cenários existentes que devem ser mantidos
-   - **Plano de rollback:** como desfazer se necessário
-3. Stories de brownfield tendem a ser menores que greenfield para reduzir risco
-
-### Adições ao template padrão de story:
-```markdown
-## Compatibilidade Brownfield
-- Funcionalidades existentes NÃO devem ser afetadas: [lista]
-- Testes de regressão obrigatórios: [lista de cenários]
-- Plano de rollback: [como desfazer esta mudança]
-- Áreas de risco identificadas por @architect: [referência à ANALISE-IMPACTO]
-```
-
----
-
-## Fase 6 — Desenvolvimento com Cautela (SDC adaptado)
-
-**Workflow:** [Story Development Cycle](./story-development-cycle.md) com adições brownfield
-
-O SDC é executado normalmente com estas adições:
-
-- **@dev:** sempre roda testes de regressão completos antes de declarar pronto
-- **@qa:** verifica explicitamente que funcionalidades existentes não foram quebradas
-- **@qa:** executa cenários de regressão além dos ACs da nova story
-- **@devops:** valida staging completamente antes de qualquer deploy em produção
-- **@devops:** mantém plano de rollback ativo
-
----
-
-## Estratégias de Migração Disponíveis
-
-| Estratégia | Quando usar | Risco |
-|-----------|-------------|-------|
-| Big Bang | Sistema pequeno, pode ter downtime | Alto |
-| Gradual | Sistemas grandes, sem downtime | Médio |
-| Strangler Fig | Substituição incremental de módulos | Baixo |
-| Blue/Green | Alta disponibilidade necessária | Baixo (custo maior) |
-| Feature Flags | Lançamento controlado | Baixíssimo |
-
-@architect define a estratégia na Fase 3.
-
----
-
-## Regras Específicas do Brownfield
-
-1. **Nunca refatorar e adicionar feature no mesmo commit** — separar em stories distintas
-2. **Testes de regressão são obrigatórios** — sem exceção, mesmo que não existissem antes
-3. **Staging é espelho de produção** — qualquer divergência de ambiente deve ser resolvida antes do deploy
-4. **Rollback planejado** — @devops tem plano de rollback para cada deploy significativo
-5. **Comunicação com usuários** — mudanças que afetam UX devem ser comunicadas antecipadamente
-
----
-
-*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*

package/template/.genia/development/workflows/delivery.md

@@ -1,208 +0,0 @@
-# Workflow: Delivery
-
-> Fase de entrega. Transforma código aprovado em produto em produção.
-> Ordem: @pm → @devops → @qa (validação) → @pm (comunicação)
-
----
-
-## Visão Geral
-
-O workflow Delivery é a fase final do ciclo de desenvolvimento. Ele abrange todo o processo desde a decisão de fazer uma release até o produto estar em produção, monitorado e com os stakeholders informados. Delivery não é apenas `git push` — é um processo gerenciado de entrega de valor.
-
-**Quando usar:** Ao final de um sprint ou conjunto de sprints com stories Done suficientes para uma release
-**Pré-requisito:** Stories aprovadas por @po, código mergeado em main por @devops, staging validado
-
----
-
-## Fase 1 — Decisão de Release (@pm)
-
-**Responsável:** Marina (@pm)
-**Output:** Decisão formal de release com escopo definido
-
-### O que acontece:
-1. @pm avalia o conjunto de stories prontas e decide se há valor suficiente para uma release
-2. Define o escopo da release:
-   - O que está incluído (features prontas)
-   - O que NÃO está incluído (features parciais ou não concluídas)
-3. Define a versão semântica (Major.Minor.Patch):
-   - **Major:** mudanças breaking, redesign significativo
-   - **Minor:** novas funcionalidades, expansões
-   - **Patch:** bug fixes, melhorias menores
-4. Alinha expectativas com stakeholders sobre o que será entregue
-5. Define data e hora de release (evitar deploy em sexta-feira à tarde)
-6. Aprova formalmente a release
-
-### Critérios para autorizar release:
-- [ ] Mínimo de stories Done que justifiquem o deploy
-- [ ] Nenhum bug crítico pendente
-- [ ] Staging estável há pelo menos 48h
-- [ ] Plano de rollback documentado
-- [ ] Stakeholders informados
-
----
-
-## Fase 2 — Preparação de Release (@devops)
-
-**Responsável:** Gate (@devops)
-**Output:** Ambiente de produção pronto, release notes preparadas
-
-### O que acontece:
-1. @devops confirma que o pipeline CI/CD está verde em staging
-2. Gera as release notes a partir dos commits e stories:
-   ```markdown
-   # Release v1.2.0 — YYYY-MM-DD
-
-   ## Novidades
-   - [STORY-001] Funcionalidade X implementada
-   - [STORY-003] Melhoria Y aplicada
-
-   ## Correções
-   - [STORY-005] Bug Z corrigido
-
-   ## Notas Técnicas
-   - Migração de banco de dados necessária: [sim/não]
-   - Configurações de ambiente alteradas: [lista]
-   - Breaking changes: [sim/não]
-   ```
-3. Executa checklist completo de pré-deploy
-4. Prepara o plano de rollback documentado
-5. Cria a tag de release: `git tag -a v1.2.0 -m "Release v1.2.0"`
-6. Comunica janela de deploy para o time
-
-### Checklist pré-produção de @devops:
-- [ ] Pipeline CI em staging: verde
-- [ ] Testes de integração em staging: passando
-- [ ] Security scan: sem vulnerabilidades críticas
-- [ ] Performance check: dentro dos SLAs
-- [ ] Variáveis de ambiente de produção: configuradas
-- [ ] Backup de banco de dados: realizado
-- [ ] Plano de rollback: documentado e testado
-- [ ] Time avisado sobre a janela de deploy
-- [ ] Escalação de suporte configurada (se necessário)
-
----
-
-## Fase 3 — Deploy em Produção (@devops)
-
-**Responsável:** Gate (@devops)
-**Output:** Sistema em produção com nova versão
-
-### O que acontece:
-1. @devops executa o pipeline de produção
-2. Monitora cada etapa do deploy:
-   - Build de produção
-   - Testes pré-deploy (smoke tests)
-   - Deploy incremental (canary ou blue/green se configurado)
-   - Verificações pós-deploy
-3. Confirma que a aplicação está saudável em produção:
-   - Health checks respondem
-   - Logs sem erros críticos
-   - Métricas de performance normais
-4. Publica a release no GitHub: `gh release create v1.2.0`
-
-### Se algo der errado durante o deploy:
-```
-1. @devops para o deploy imediatamente
-2. Avalia a severidade do problema
-3. Se crítico: executa rollback imediatamente
-4. Documenta o incidente
-5. Notifica @pm e @architect
-6. Abre post-mortem se necessário
-```
-
----
-
-## Fase 4 — Validação Pós-Deploy (@qa)
-
-**Responsável:** Quinn (@qa)
-**Output:** Validação formal em produção
-
-### O que acontece:
-1. @qa executa smoke tests em produção (não os unitários — testes de comportamento)
-2. Verifica os principais fluxos de usuário afetados pela release
-3. Confirma que funcionalidades existentes não foram impactadas
-4. Monitora métricas por 30-60 minutos após o deploy
-5. Emite veredicto de saúde da release:
-   - **SAUDÁVEL:** release aprovada, ambiente estável
-   - **ALERTA:** problemas não-críticos identificados, monitorar
-   - **CRÍTICO:** problema grave detectado → @devops executa rollback imediatamente
-
-### Smoke tests típicos:
-- Login/autenticação funcionando
-- Principais fluxos de negócio acessíveis
-- APIs respondendo com status corretos
-- Integrações externas ativas
-- Performance aceitável (sem degradação significativa)
-
----
-
-## Fase 5 — Comunicação e Documentação (@pm)
-
-**Responsável:** Marina (@pm)
-**Output:** Stakeholders informados, documentação atualizada
-
-### O que acontece:
-1. @pm redige e envia comunicado de release para stakeholders:
-   ```
-   Assunto: GEN.IA OS v1.2.0 — Nova versão disponível
-
-   Olá,
-
-   Acabamos de disponibilizar a versão 1.2.0 do [produto] em produção.
-
-   O que há de novo:
-   - [Feature X]: [descrição em linguagem de negócio]
-   - [Correção Y]: [impacto positivo para o usuário]
-
-   Próximos passos:
-   - [O que vem a seguir]
-   ```
-2. Atualiza o CHANGELOG.md do projeto
-3. Arquiva o sprint no histórico
-4. Agenda retrospectiva com @sm
-5. Inicia planejamento do próximo ciclo
-
----
-
-## Processo de Rollback
-
-Se a release precisar ser revertida:
-
-1. **@devops decide ou é acionado** por @qa (veredicto CRÍTICO)
-2. **@devops executa rollback:**
-   - Deploy da versão anterior (blue/green switch ou redeploy)
-   - Ou reverte migrações de banco se necessário
-3. **@devops confirma** que versão anterior está estável
-4. **@pm comunica** stakeholders sobre o rollback com transparência
-5. **@architect investiga** a causa raiz
-6. **Post-mortem** documentado e ações de prevenção definidas
-
----
-
-## Critérios de Conclusão do Delivery
-
-A release está concluída quando:
-
-- [ ] Nova versão em produção e estável
-- [ ] @qa validou em produção (veredicto SAUDÁVEL ou ALERTA monitorado)
-- [ ] Release notes publicadas no GitHub
-- [ ] Stakeholders comunicados por @pm
-- [ ] CHANGELOG.md atualizado
-- [ ] Tag de release criada e publicada
-- [ ] Nenhum incidente crítico ativo
-
----
-
-## Governança de Deploy
-
-| Ambiente | Autoridade | Requer aprovação de |
-|---------|-----------|-------------------|
-| Development | @dev (local) | Ninguém |
-| Staging | @devops | @qa (implícita — pipeline) |
-| Production | @devops | @pm (formal) + @qa (pós-deploy) |
-
-**Regra de ouro:** Production nunca recebe código que não passou por staging. Sem exceção.
-
----
-
-*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*

package/template/.genia/development/workflows/development.md

@@ -1,189 +0,0 @@
-# Workflow: Development
-
-> Fase de execução do desenvolvimento. Transforma stories validadas em código entregue.
-> Ordem: @sm → @dev → @qa → @reviewer → @devops
-
----
-
-## Visão Geral
-
-O workflow Development é a fase de execução, onde stories validadas se tornam código funcional. Ele opera em paralelo com o planejamento do próximo sprint e segue rigorosamente o Story Development Cycle (SDC) para cada story.
-
-**Quando usar:** Sprint ativo com stories em status Ready
-**Pré-requisito:** Sprint planejado com stories validadas por @po
-**Duração:** Contínuo durante o sprint (1-2 semanas típicas)
-
----
-
-## Responsabilidades por Agente
-
-### @sm — Facilitação e Acompanhamento
-- Facilita daily stand-ups (assíncrono ou síncrono)
-- Remove impedimentos que bloqueiam @dev
-- Monitora velocity e saúde do sprint
-- Atualiza status das stories no backlog
-- Comunica riscos de prazo para @pm
-
-### @dev — Execução
-- Implementa uma story por vez (evitar WIP alto)
-- Segue o SDC rigorosamente para cada story
-- Comunica blockers imediatamente
-- Atualiza status da story quando muda de fase
-- Não começa nova story sem a anterior estar In QA
-
-### @qa — Qualidade Contínua
-- Disponível para revisão assim que @dev declara pronto
-- Executa o QA Loop (máx 5 iterações)
-- Não acumula stories — revisa uma por vez
-- Pode revisar spec de stories futuras enquanto aguarda dev
-
-### @reviewer — Code Review Ágil
-- Revisa código assim que @qa aprova
-- Objetivo: máximo 24h de tempo de review
-- Não bloqueia por questões menores sem impacto real
-- Aprova com confiança ou solicita mudanças bloqueantes
-
-### @devops — Delivery Contínuo
-- Mantém CI/CD pipeline funcionando
-- Faz push e cria PR assim que @reviewer aprova
-- Monitora ambiente de staging
-- Alerta time sobre problemas de infraestrutura
-
----
-
-## Fluxo Visual do Desenvolvimento
-
-```
-STORIES READY (backlog do sprint)
-         │
-         ▼
-   @dev pega story → InProgress
-         │
-         ▼
-   @dev conclui → notifica @qa
-         │
-         ▼
-   @qa revisa (QA Loop máx 5x)
-         │
-    ┌────┴────┐
-REPROVADO   APROVADO
-    │           │
-@dev corrige  @reviewer revisa
-    │           │
-    └───────┐  ┌────┴────┐
-         (loop) CHANGES  LGTM
-                │          │
-            @dev corrige  @devops
-                │          │
-            @reviewer   git push + PR
-            re-aprova      │
-                │          ▼
-                └──────→  DONE
-```
-
----
-
-## Daily Stand-up (Assíncrono)
-
-Cada agente reporta diariamente:
-
-```markdown
-## Daily — YYYY-MM-DD
-
-### @dev
-- Ontem: [o que foi feito]
-- Hoje: [o que será feito]
-- Blocker: [impedimento ou "sem blocker"]
-- Story atual: STORY-XXX (status: InProgress | InQA | etc.)
-
-### @qa
-- Ontem: [revisões concluídas]
-- Hoje: [o que será revisado]
-- Blocker: [impedimento ou "sem blocker"]
-
-### @devops
-- Status do pipeline: [verde | amarelo | vermelho]
-- PRs pendentes: [X PRs aguardando merge]
-- Alertas: [qualquer problema de infraestrutura]
-```
-
----
-
-## Gestão de WIP (Work In Progress)
-
-Para garantir fluxo, o GEN.IA OS recomenda limites de WIP:
-
-| Agente | WIP Máximo | Por quê |
-|--------|-----------|---------|
-| @dev | 1 story por vez | Foco garante qualidade |
-| @qa | 1 story em revisão ativa | Profundidade na revisão |
-| @reviewer | 2 reviews simultâneos | Viabilidade de resposta rápida |
-| @devops | Sem limite | Operacional, menos cognitivo |
-
----
-
-## Gestão de Blockers
-
-Quando um blocker é identificado:
-
-1. **@dev identifica** — declara o blocker imediatamente no daily
-2. **@sm registra** — cria registro formal do blocker
-3. **@sm tenta remover** — em até 2 horas na maioria dos casos
-4. **Se não resolvível:**
-   - Blocker técnico → @architect
-   - Blocker de requisito → @po → @pm
-   - Blocker de infraestrutura → @devops
-5. **@sm comunica impacto** — informa @pm se o blocker ameaça o sprint
-
-```markdown
-## Blocker #XXX — [Título]
-Data: YYYY-MM-DD
-Story afetada: STORY-XXX
-Agente bloqueado: @dev
-Descrição: [o que está impedindo o progresso]
-Responsável por remover: [@architect | @po | @devops]
-Status: Aberto | Em Resolução | Resolvido
-```
-
----
-
-## Métricas de Saúde do Sprint
-
-@sm monitora e reporta semanalmente:
-
-| Métrica | Fórmula | Meta |
-|---------|---------|------|
-| Velocity | Pontos entregues / sprint | Histórico + 10% |
-| Lead Time | Draft → Done (dias) | < 5 dias por story |
-| Cycle Time | InProgress → Done (dias) | < 3 dias por story |
-| Bug Rate | Bugs críticos em QA / story | < 1 por sprint |
-| Rework Rate | Stories que voltaram de QA | < 30% |
-
----
-
-## Critérios de Encerramento do Sprint
-
-O sprint é encerrado quando:
-
-- [ ] Todas as stories comprometidas estão em Done ou formalmente movidas para o próximo sprint
-- [ ] Todas as histórias em Done têm PR mergeado
-- [ ] Nenhum bug crítico pendente
-- [ ] @po validou todas as stories como Done
-- [ ] Sprint Review preparado por @pm
-- [ ] Retrospectiva agendada por @sm
-
----
-
-## Sprint Review (Fim de Sprint)
-
-Facilitado por @pm e @po:
-
-1. @pm apresenta o objetivo do sprint e se foi atingido
-2. @dev demonstra as stories entregues
-3. @po valida formalmente as stories (se não validou durante o sprint)
-4. Stakeholders dão feedback sobre o entregue
-5. @pm atualiza o roadmap com base no que foi entregue e no feedback
-
----
-
-*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*