create-genia-os 2.4.0 → 3.0.0

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

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

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

package/template/.genia/development/workflows/spec-pipeline.md

@@ -1,192 +0,0 @@
-# Workflow: Spec Pipeline
-
-> Transforma requisitos brutos em especificações técnicas executáveis.
-> Ordem de execução: @analyst → @pm → @architect → @qa → @po
-
----
-
-## Visão Geral
-
-O Spec Pipeline é o processo obrigatório que antecede qualquer desenvolvimento. Ele garante que o time nunca implementa com base em requisitos vagos, PRDs incompletos ou especificações técnicas ausentes. Projetos que pulam este pipeline invariavelmente sofrem com retrabalho, scope creep e dívida técnica.
-
-**Duração estimada:** 2-5 dias úteis (dependendo da complexidade)
-**Ativador:** `@analyst iniciar spec-pipeline [nome-do-projeto]`
-
----
-
-## Fase 1 — Briefing (@analyst)
-
-**Responsável:** Ana (@analyst)
-**Input:** Requisitos brutos do cliente/stakeholder (pode ser uma conversa, email, documento informal)
-**Output:** `docs/[projeto]/BRIEFING.md`
-
-### O que acontece:
-1. @analyst conduz sessão de discovery com stakeholders
-2. Coleta requisitos, regras de negócio, restrições e objetivos
-3. Identifica personas de usuário
-4. Documenta o não-escopo explicitamente
-5. Mapeia integrações necessárias
-6. Identifica riscos de negócio
-
-### Critérios de saída:
-- [ ] BRIEFING.md criado e completo
-- [ ] Todas as ambiguidades identificadas e resolvidas
-- [ ] Requisitos validados com pelo menos um stakeholder
-- [ ] Não-escopo documentado
-- [ ] Riscos de negócio identificados
-
-**→ Passa para @pm**
-
----
-
-## Fase 2 — PRD (@pm)
-
-**Responsável:** Marina (@pm)
-**Input:** `docs/[projeto]/BRIEFING.md`
-**Output:** `docs/[projeto]/PRD.md`
-
-### O que acontece:
-1. @pm revisa o briefing e levanta dúvidas com @analyst
-2. Define visão de produto e proposta de valor
-3. Organiza funcionalidades em Épicos
-4. Prioriza usando framework MoSCoW
-5. Define métricas de sucesso do produto
-6. Documenta roadmap e milestones
-
-### Critérios de saída:
-- [ ] PRD.md criado com todos os Épicos
-- [ ] Priorização MoSCoW aplicada
-- [ ] Métricas de sucesso definidas
-- [ ] Não-escopo atualizado
-- [ ] Stakeholders consultados
-
-**→ Passa para @architect**
-
----
-
-## Fase 3 — Avaliação Técnica (@architect)
-
-**Responsável:** Arqui (@architect)
-**Input:** `docs/[projeto]/PRD.md`
-**Output:** Avaliação formal com riscos, viabilidade e recomendações de stack
-
-### O que acontece:
-1. @architect lê o PRD e identifica implicações técnicas
-2. Avalia viabilidade de cada épico
-3. Identifica riscos técnicos e dependências
-4. Propõe stack tecnológica inicial
-5. Sinaliza itens que precisam de mais esclarecimento
-6. Pode exercer veto técnico sobre funcionalidades inviáveis
-
-### Critérios de saída:
-- [ ] Avaliação de viabilidade documentada
-- [ ] Riscos técnicos mapeados
-- [ ] Stack proposta com justificativas
-- [ ] Vetos (se houver) formalizados com alternativas
-- [ ] @pm alinhado sobre qualquer mudança de escopo
-
-**→ Passa para criação do SPEC-TECNICO**
-
----
-
-## Fase 4 — Especificação Técnica (@architect)
-
-**Responsável:** Arqui (@architect)
-**Input:** `docs/[projeto]/PRD.md` + avaliação técnica
-**Output:** `docs/[projeto]/SPEC-TECNICO.md` + ADRs iniciais
-
-### O que acontece:
-1. @architect cria o SPEC-TECNICO.md completo
-2. Define arquitetura de alto nível
-3. Documenta modelagem de dados
-4. Especifica APIs e contratos de integração
-5. Define estratégia de testes
-6. Registra decisões arquiteturais como ADRs
-7. Define padrões de código e estrutura de pastas
-
-### Critérios de saída:
-- [ ] SPEC-TECNICO.md completo
-- [ ] Arquitetura documentada com diagrama
-- [ ] Modelagem de dados definida
-- [ ] APIs e integrações especificadas
-- [ ] Estratégia de testes definida
-- [ ] ADRs iniciais registrados
-
-**→ Passa para @qa**
-
----
-
-## Fase 5 — Revisão Crítica (@qa)
-
-**Responsável:** Quinn (@qa)
-**Input:** `docs/[projeto]/PRD.md` + `docs/[projeto]/SPEC-TECNICO.md`
-**Output:** Relatório crítico de revisão
-
-### O que acontece:
-1. @qa lê o PRD e o SPEC-TECNICO em busca de inconsistências
-2. Identifica requisitos não-testáveis
-3. Verifica se os acceptance criteria futuros serão verificáveis
-4. Questiona pontos de falha não cobertos
-5. Propõe estratégia de testes de alto nível
-
-### Critérios de saída:
-- [ ] Inconsistências entre PRD e SPEC-TECNICO identificadas
-- [ ] Requisitos não-testáveis sinalizado
-- [ ] Estratégia de testes de alto nível documentada
-- [ ] @architect respondeu a todos os pontos críticos
-
-**→ Passa para @po**
-
----
-
-## Fase 6 — Aprovação Final (@po)
-
-**Responsável:** Pax (@po)
-**Input:** PRD.md + SPEC-TECNICO.md revisados
-**Output:** Aprovação formal para início do desenvolvimento
-
-### O que acontece:
-1. @po revisa o backlog de épicos e funcionalidades
-2. Confirma que é possível criar stories claras para cada item
-3. Alinha priorização com @pm
-4. Emite aprovação formal para start do desenvolvimento
-5. Solicita @sm para iniciar criação de stories do primeiro épico
-
-### Critérios de saída:
-- [ ] PRD.md aprovado por @po e @pm
-- [ ] SPEC-TECNICO.md aprovado por @architect
-- [ ] Zero ambiguidades pendentes
-- [ ] @sm acionado para criar stories do Sprint 1
-
----
-
-## Critérios Globais de Saída do Spec Pipeline
-
-Para que o Spec Pipeline seja considerado concluído:
-
-- [ ] `docs/[projeto]/BRIEFING.md` — completo e validado
-- [ ] `docs/[projeto]/PRD.md` — aprovado por @pm e @po
-- [ ] `docs/[projeto]/SPEC-TECNICO.md` — aprovado por @architect
-- [ ] ADRs iniciais registrados em `docs/adr/`
-- [ ] Zero ambiguidades de negócio pendentes
-- [ ] Zero riscos técnicos não-mitigados documentados
-- [ ] Stack tecnológica definida e aprovada
-- [ ] Time alinhado sobre o que será construído
-
----
-
-## Como Ativar
-
-```
-@analyst iniciar spec-pipeline [nome-do-projeto]
-```
-
-Ou retomar de uma fase específica:
-```
-@pm criar-prd a partir do briefing em docs/[projeto]/BRIEFING.md
-@architect criar spec-técnico a partir do PRD em docs/[projeto]/PRD.md
-```
-
----
-
-*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*