create-genia-os 1.0.0

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

@@ -0,0 +1,189 @@
+# 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}}*

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

@@ -0,0 +1,166 @@
+# Workflow: Greenfield
+
+> Para projetos que começam do zero. Constrói a fundação certa desde o primeiro dia.
+> Ordem: @analyst → @pm → @architect → @devops → @sm + @po → SDC
+
+---
+
+## Visão Geral
+
+O workflow Greenfield é usado quando o projeto não tem código existente, repositório configurado ou infraestrutura em funcionamento. Ele garante que a fundação técnica e de processo seja construída corretamente antes que qualquer funcionalidade seja desenvolvida.
+
+**Quando usar:** Projeto novo, sem código legado, sem infraestrutura existente
+**Duração típica:** 1-2 semanas para a fundação completa
+**Pré-requisito:** Aprovação formal do projeto por @pm
+
+---
+
+## Fase 1 — Discovery e Briefing (@analyst)
+
+**Responsável:** Ana (@analyst)
+**Output:** `docs/[projeto]/BRIEFING.md`
+
+### O que acontece:
+1. @analyst conduz sessões de discovery com todos os stakeholders relevantes
+2. Mapeia o problema de negócio, objetivos e métricas de sucesso
+3. Define personas de usuário com base em pesquisa
+4. Identifica todas as integrações necessárias (APIs, sistemas legados)
+5. Mapeia restrições regulatórias, de compliance ou tecnologia obrigatória
+6. Documenta riscos de negócio identificados
+
+### Entregáveis:
+- `docs/[projeto]/BRIEFING.md` validado com stakeholders
+- Lista de personas definidas
+- Mapa de integrações necessárias
+- Riscos de negócio documentados
+
+---
+
+## Fase 2 — Spec Pipeline Completo
+
+**Workflow:** Executa o [Spec Pipeline](./spec-pipeline.md) completo
+
+@analyst → @pm → @architect → @qa (critique) → @po
+
+Ao final desta fase:
+- `docs/[projeto]/BRIEFING.md` — completo
+- `docs/[projeto]/PRD.md` — aprovado
+- `docs/[projeto]/SPEC-TECNICO.md` — aprovado
+- ADRs iniciais registrados
+
+---
+
+## Fase 3 — Decisões Arquiteturais Finais (@architect)
+
+**Responsável:** Arqui (@architect)
+**Output:** ADRs de fundação + plano de estrutura do repositório
+
+### O que acontece:
+1. @architect define a estrutura completa de pastas do projeto
+2. Configura o `tsconfig.json` (imports absolutos `@/`)
+3. Define configurações de linting (ESLint, Prettier)
+4. Especifica as ferramentas de teste e configurações
+5. Define a estratégia de gerenciamento de estado
+6. Documenta padrões de nomenclatura e convenções
+7. Registra ADRs para cada decisão relevante
+
+### Entregáveis:
+- Estrutura de pastas documentada
+- Configurações de ferramentas especificadas
+- Padrões de código documentados
+- ADRs de fundação registrados
+
+---
+
+## Fase 4 — Setup da Fundação (@devops)
+
+**Responsável:** Gate (@devops)
+**Output:** Repositório configurado, CI/CD ativo, ambientes criados
+
+### O que acontece:
+1. @devops cria/configura o repositório no GitHub
+2. Configura branch protection rules para `main`
+3. Configura o pipeline CI/CD:
+   - GitHub Actions ou equivalente
+   - Stages: lint → test → build → deploy-staging
+4. Cria os ambientes:
+   - `development` (local)
+   - `staging` (homologação)
+   - `production` (produção)
+5. Configura secrets e variáveis de ambiente
+6. Configura MCP tools necessárias (@architect define quais)
+7. Inicializa o projeto com o boilerplate aprovado pelo @architect
+
+### Checklist de setup:
+- [ ] Repositório criado com README inicial
+- [ ] `.gitignore` configurado
+- [ ] Branch protection em `main` ativado
+- [ ] CI/CD pipeline configurado e testado
+- [ ] Ambientes de staging e production configurados
+- [ ] Secrets configurados (sem exposição em código)
+- [ ] `tsconfig.json` com paths absolutos (`@/`)
+- [ ] ESLint + Prettier configurados
+- [ ] Framework de testes configurado
+- [ ] Build inicial funcionando
+- [ ] Deploy de staging funcionando
+
+---
+
+## Fase 5 — Épicos e Stories do Sprint 1 (@sm + @po)
+
+**Responsáveis:** Sami (@sm) + Pax (@po)
+**Output:** Backlog inicial priorizado com stories do Sprint 1 validadas
+
+### O que acontece:
+1. @sm e @po fazem breakdown dos Épicos do PRD em stories
+2. @sm cria as stories do Sprint 1 (stories de setup/fundação primeiro)
+3. @po valida cada story com o checklist 10-point
+4. Backlog priorizado e Sprint 1 definido
+5. @sm conduz Sprint Planning com @dev
+
+### Ordem recomendada de stories para o primeiro sprint:
+1. Story de configuração de autenticação/autorização (se necessário)
+2. Story de estrutura de layout base (se front-end)
+3. Story de conexão com banco de dados (se back-end)
+4. Primeira funcionalidade de valor de negócio
+
+---
+
+## Fase 6 — Desenvolvimento (SDC por Story)
+
+**Workflow:** Executa o [Story Development Cycle](./story-development-cycle.md) para cada story
+
+Para cada story do Sprint 1:
+```
+@sm (Draft) → @po (Ready) → @dev (Develop) → @qa (QA) → @reviewer (Review) → @devops (PR) → @po (Done)
+```
+
+---
+
+## Marcos do Greenfield
+
+| Marco | Agente | Entregável |
+|-------|--------|-----------|
+| M1 | @analyst | BRIEFING.md validado |
+| M2 | @pm | PRD.md aprovado |
+| M3 | @architect | SPEC-TECNICO.md + ADRs |
+| M4 | @devops | Infra funcionando (CI verde em staging) |
+| M5 | @sm + @po | Sprint 1 planejado |
+| M6 | @dev + time | Primeira story Done |
+| M7 | @pm | MVP em staging para validação |
+
+---
+
+## Riscos Comuns em Projetos Greenfield
+
+| Risco | Prevenção |
+|-------|----------|
+| Escopo mal definido | Spec Pipeline completo obrigatório |
+| Setup técnico adiado | Fase 4 (Setup) acontece ANTES do desenvolvimento |
+| Stories mal escritas | Validação 10-point de @po obrigatória |
+| Infraestrutura ignorada | @devops tem fase própria com checklist |
+| Debt técnico desde o início | @architect define padrões antes do primeiro commit |
+
+---
+
+*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*

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

@@ -0,0 +1,167 @@
+# Workflow: Planning
+
+> Fase de planejamento de produto e sprint. Transforma visão em plano executável.
+> Ordem: @analyst → @pm → @architect → @po → @sm
+
+---
+
+## Visão Geral
+
+O workflow Planning engloba todas as atividades de planejamento que antecedem o desenvolvimento. Ele pode ser executado no início de um projeto (em conjunto com o Spec Pipeline) ou de forma recorrente para planejamento de novos épicos ou sprints.
+
+**Quando usar:**
+- Início de projeto (primeiro planejamento)
+- Planejamento de novo épico ou ciclo de produto
+- Sprint Planning recorrente
+- Revisão de roadmap
+
+**Duração típica:** 1-3 dias por ciclo de planejamento
+
+---
+
+## Fase 1 — Alinhamento de Contexto (@analyst)
+
+**Responsável:** Ana (@analyst)
+**Output:** Contexto atualizado para planejamento
+
+### O que acontece:
+1. @analyst garante que o briefing está atualizado com novos requisitos ou mudanças de contexto
+2. Pesquisa mudanças de mercado ou regulatórias relevantes
+3. Coleta feedback de usuários do ciclo anterior
+4. Documenta novos requisitos identificados
+5. Passa contexto atualizado para @pm
+
+### Não é necessário quando:
+- O planejamento é para um sprint dentro de um épico já definido
+- O briefing do projeto foi feito recentemente e não houve mudanças
+
+---
+
+## Fase 2 — Definição de Escopo e PRD (@pm)
+
+**Responsável:** Marina (@pm)
+**Output:** Escopo do ciclo definido, PRD atualizado
+
+### O que acontece:
+1. @pm revisa o roadmap atual e define foco do próximo ciclo
+2. Seleciona épicos e features para o período
+3. Atualiza o PRD com novos itens se necessário
+4. Define objetivos e métricas do ciclo
+5. Alinha com stakeholders sobre prioridades
+6. Comunica mudanças de escopo para o time
+
+### Entregáveis:
+- Escopo do ciclo documentado
+- PRD.md atualizado (se houver novos épicos)
+- Objetivos e métricas do ciclo definidos
+
+---
+
+## Fase 3 — Revisão Técnica e Capacidade (@architect)
+
+**Responsável:** Arqui (@architect)
+**Output:** Avaliação de viabilidade técnica + estimativas de complexidade
+
+### O que acontece:
+1. @architect revisa o escopo proposto por @pm
+2. Avalia viabilidade técnica de cada item
+3. Identifica riscos técnicos para o período
+4. Propõe soluções para itens complexos
+5. Estima complexidade técnica dos épicos
+6. Pode exercer veto técnico com alternativas
+
+### Importante:
+Planning não é o momento de definir a solução completa — é o momento de confirmar que é viável e entender a escala do trabalho. A especificação detalhada acontece no Spec Pipeline.
+
+---
+
+## Fase 4 — Refinamento e Priorização (@po)
+
+**Responsável:** Pax (@po)
+**Output:** Backlog priorizado para o ciclo
+
+### O que acontece:
+1. @po revisa o backlog atual com base no escopo definido por @pm
+2. Aplica priorização com base em:
+   - Valor de negócio (impacto nos objetivos do ciclo)
+   - Complexidade técnica (estimativas de @architect)
+   - Dependências entre stories
+   - Risco de negócio (o que acontece se não for entregue?)
+3. Define o que entra no Sprint 1 do ciclo
+4. Identifica stories que precisam de mais refinamento antes de entrar no sprint
+5. Documenta backlog priorizado
+
+### Ferramentas de priorização:
+- **MoSCoW:** Must/Should/Could/Won't
+- **RICE:** Reach × Impact × Confidence / Effort
+- **Value/Effort:** quadrante simples de priorização
+
+---
+
+## Fase 5 — Sprint Planning (@sm)
+
+**Responsável:** Sami (@sm)
+**Output:** Sprint planejado com stories commitadas
+
+### O que acontece:
+1. @sm facilita a sessão de sprint planning
+2. Apresenta o objetivo do sprint (definido com @po e @pm)
+3. Cria ou confirma stories necessárias para o sprint
+4. Garante que todas as stories estão validadas por @po (status: Ready)
+5. Calcula capacity do sprint baseado em velocity histórica
+6. Time commita com o volume de stories que cabe na capacity
+7. Define critérios de sucesso do sprint
+
+### Output do Sprint Planning:
+```markdown
+# Sprint XX — Planning
+
+## Objetivo do Sprint
+[Uma frase clara do que será entregue ao final do sprint]
+
+## Stories Comprometidas
+| Story | Título | Estimativa | Assignee |
+|-------|--------|-----------|----------|
+| STORY-001 | ... | M | @dev |
+| STORY-002 | ... | P | @dev |
+
+## Capacity
+Velocity histórica: XX pts | Capacity este sprint: XX pts | Total commitado: XX pts
+
+## Critérios de Sucesso do Sprint
+- [ ] [Critério mensurável 1]
+- [ ] [Critério mensurável 2]
+
+## Riscos Identificados
+- [Risco com plano de mitigação]
+```
+
+---
+
+## Cadência Recomendada
+
+| Cerimônia | Frequência | Duração | Facilitador |
+|-----------|-----------|---------|------------|
+| Sprint Planning | A cada sprint | 2-4 horas | @sm |
+| Sprint Review | Fim de sprint | 1-2 horas | @pm + @po |
+| Retrospectiva | Fim de sprint | 1 hora | @sm |
+| Backlog Refinement | Meio do sprint | 1 hora | @po + @sm |
+| Revisão de Roadmap | Mensal | 2 horas | @pm + @po |
+
+---
+
+## Critérios de Saída do Planning
+
+O planning está completo quando:
+
+- [ ] Objetivo do sprint definido e aprovado por @pm + @po
+- [ ] Stories do sprint com status Ready (validadas por @po)
+- [ ] Capacity calculada e respeitada
+- [ ] Riscos do sprint documentados
+- [ ] @dev tem clareza sobre o que fazer no Sprint 1
+- [ ] @devops está alinhado sobre necessidades de infraestrutura
+- [ ] @architect foi consultado sobre pontos de complexidade alta
+
+---
+
+*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*

package/template/.genia/development/workflows/qa-loop.md

@@ -0,0 +1,179 @@
+# Workflow: QA Loop
+
+> Ciclo iterativo de revisão de qualidade e correção de bugs.
+> Máximo de 5 iterações. Após o limite, escalar para @architect + @pm.
+
+---
+
+## Visão Geral
+
+O QA Loop é a fase de qualidade dentro do Story Development Cycle. Ele define um processo rigoroso e limitado de revisão-correção para garantir que o código entregue atende aos acceptance criteria sem criar ciclos infinitos de revisão.
+
+**Máximo de iterações:** 5
+**Responsáveis:** @qa (revisão) + @dev (correção)
+**Pré-requisito:** @dev declarou implementação concluída
+
+---
+
+## Fluxo do QA Loop
+
+```
+Iteração 1:
+  @qa revisa o código
+  → APROVADO → Fim do QA Loop → @reviewer
+  → REPROVADO → @dev corrige bugs críticos e altos
+
+Iteração 2:
+  @qa re-revisa
+  → APROVADO → Fim do QA Loop → @reviewer
+  → REPROVADO → @dev corrige
+
+Iteração 3:
+  @qa re-revisa
+  → APROVADO → Fim do QA Loop → @reviewer
+  → REPROVADO → @dev corrige
+
+Iteração 4:
+  @qa re-revisa
+  → APROVADO → Fim do QA Loop → @reviewer
+  → REPROVADO → @dev corrige
+
+Iteração 5 (ÚLTIMA):
+  @qa re-revisa
+  → APROVADO → Fim do QA Loop → @reviewer
+  → REPROVADO → ESCALAR para @architect + @pm
+               (decisão: refatorar, redefinir escopo ou cancelar story)
+```
+
+---
+
+## Fase de Revisão (@qa)
+
+### O que @qa verifica em cada iteração:
+
+**1. Acceptance Criteria (obrigatório):**
+- [ ] AC-01 verificado com evidência
+- [ ] AC-02 verificado com evidência
+- [ ] AC-03 verificado com evidência
+- [ ] [demais ACs da story]
+
+**2. Qualidade do código:**
+- [ ] `npm run lint` — zero warnings ou erros
+- [ ] `npm run typecheck` — zero erros TypeScript
+- [ ] `npm run test` — todos os testes passando
+- [ ] `npm run coverage` — cobertura >= 80%
+
+**3. Cenários adicionais:**
+- [ ] Cenários positivos funcionando
+- [ ] Cenários negativos (edge cases) tratados
+- [ ] Mensagens de erro claras e consistentes
+- [ ] Estados de loading/empty/error cobertos (se UI)
+
+**4. Segurança básica:**
+- [ ] Sem dados sensíveis expostos
+- [ ] Inputs validados
+- [ ] Autenticação/autorização conforme spec
+
+---
+
+## Documentação de Bugs
+
+Para cada bug encontrado, @qa documenta:
+
+```markdown
+### BUG-QA-XXX — [Título descritivo]
+
+**Iteração:** X de 5
+**Severidade:** CRÍTICO | ALTO | MÉDIO | BAIXO
+**AC relacionado:** AC-XX (ou "Fora dos ACs — problema encontrado")
+**Status:** Aberto | Em Correção | Resolvido
+
+#### Comportamento Esperado
+[Descrição precisa do que deveria acontecer]
+
+#### Comportamento Atual
+[Descrição precisa do que está acontecendo]
+
+#### Passos para Reproduzir
+1. [Passo 1]
+2. [Passo 2]
+3. [Passo 3]
+
+#### Evidência
+```
+[Log de erro, stack trace, ou descrição da tela]
+```
+
+#### Critério de Resolução
+[Como @qa saberá que o bug foi corrigido]
+```
+
+---
+
+## Critérios de Aprovação
+
+Para o QA Loop encerrar com APROVADO:
+
+| Critério | Obrigatório |
+|---------|------------|
+| Zero bugs CRÍTICOS | Sim |
+| Zero ou máximo 2 bugs ALTOS (documentados) | Sim |
+| Todos os ACs verificados | Sim |
+| Testes passando | Sim |
+| Coverage >= 80% | Sim |
+| Lint sem erros | Sim |
+| Typecheck passando | Sim |
+
+Bugs de severidade MÉDIO e BAIXO podem existir se documentados no backlog para correção futura.
+
+---
+
+## Escalada Após 5 Iterações
+
+Se após 5 iterações o QA Loop não encerrar com aprovação:
+
+1. **@qa documenta relatório completo** com todos os bugs e histórico de iterações
+2. **@qa notifica @architect e @pm** com o relatório
+3. **@architect analisa** se há problema arquitetural subjacente
+4. **@pm e @architect decidem:**
+   - Opção A: Aumentar esforço de dev (@dev faz refatoração completa — nova branch)
+   - Opção B: Reduzir escopo da story (remover AC problemático para nova story)
+   - Opção C: Cancelar story com documentação de impedimento técnico
+
+**A escalada NUNCA é vista como fracasso do @dev — é informação valiosa sobre subestimação de complexidade.**
+
+---
+
+## Relatório Final de QA
+
+Ao encerrar o QA Loop, @qa emite relatório:
+
+```markdown
+# Relatório QA — STORY-XXX
+Data: YYYY-MM-DD | QA: Quinn (@qa)
+Iterações: X/5 | Veredicto: APROVADO | REPROVADO
+
+## Acceptance Criteria
+- AC-01: ✅ VERIFICADO
+- AC-02: ✅ VERIFICADO
+- AC-03: ✅ VERIFICADO
+
+## Resultados de Testes
+- Unitários: XX/XX passando
+- Coverage: XX%
+- Lint: limpo
+- Typecheck: limpo
+
+## Bugs Encontrados
+| ID | Título | Severidade | Status |
+|----|--------|-----------|--------|
+| BUG-QA-001 | ... | MÉDIO | Documentado para backlog |
+
+## Conclusão
+[Story aprovada / reprovada] por Quinn (@qa) em YYYY-MM-DD.
+Próximo passo: [@reviewer para code review | escalar]
+```
+
+---
+
+*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*