create-genia-os 2.1.1 → 2.3.0

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

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

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