create-genia-os 2.4.0 → 3.0.0

package/template/.genia/development/tasks/criar-prd.md

@@ -1,170 +0,0 @@
-# Task: Criar PRD
-
-> Tarefa executada por @pm após receber o BRIEFING.md de @analyst.
-> Output: `docs/[projeto]/PRD.md`
-
----
-
-## Objetivo
-
-Transformar o briefing de negócios em um Product Requirements Document (PRD) completo, priorizado e aprovado por stakeholders. O PRD é o documento de referência que guia todo o desenvolvimento — ele deve ser suficientemente claro para que qualquer agente entenda o que está sendo construído e por quê.
-
----
-
-## Pré-requisitos
-
-Antes de iniciar, confirme:
-
-- [ ] `docs/[projeto]/BRIEFING.md` existe e está completo
-- [ ] @analyst confirmou que o briefing foi validado com stakeholders
-- [ ] Todas as ambiguidades do briefing foram resolvidas
-- [ ] @pm tem acesso a qualquer material adicional do cliente
-
----
-
-## Passos de Execução
-
-### Passo 1 — Revisão do Briefing
-1. Leia o BRIEFING.md completamente
-2. Identifique e anote quaisquer pontos que precisam de esclarecimento
-3. Se necessário, solicite esclarecimento a @analyst antes de prosseguir
-4. Nunca assuma — dúvidas são resolvidas antes de escrever o PRD
-
-### Passo 2 — Definição da Visão de Produto
-1. Articule o problema central que o produto resolve (em 1-2 parágrafos)
-2. Defina a proposta de valor única (o que diferencia este produto)
-3. Descreva o estado futuro desejado: como fica o mundo com este produto?
-4. Identifique as restrições não-negociáveis (tecnologia, prazo, regulatório)
-
-### Passo 3 — Definição de Personas
-1. Liste as personas identificadas no briefing
-2. Para cada persona, defina:
-   - Nome e perfil
-   - Objetivos principais ao usar o sistema
-   - Dores e frustrações atuais
-   - Nível de expertise técnica
-3. Priorize as personas (primária, secundária)
-
-### Passo 4 — Estruturação em Épicos
-1. Agrupe as funcionalidades em Épicos coesos:
-   - Cada épico é um conjunto de funcionalidades relacionadas
-   - Épicos devem ser independentes entre si quando possível
-   - Épicos têm uma "promessa de valor" clara
-2. Nomeie os épicos com IDs: E-01, E-02, E-03...
-3. Escreva uma frase de valor para cada épico
-
-### Passo 5 — Priorização MoSCoW
-Para cada funcionalidade/épico, aplique:
-- **Must Have (M):** crítico para o produto funcionar. Sem isso, não há produto
-- **Should Have (S):** importante mas há workaround possível
-- **Could Have (C):** desejável se houver tempo e budget
-- **Won't Have (W):** explicitamente fora do escopo desta versão
-
-### Passo 6 — Definição de Métricas de Sucesso
-1. Defina 3-5 métricas de produto que indicam sucesso
-2. Para cada métrica:
-   - Nome claro
-   - Como é medida
-   - Baseline atual (se disponível)
-   - Meta após lançamento
-3. Evite métricas de vaidade — prefira métricas de comportamento do usuário
-
-### Passo 7 — Validação com @architect
-1. Compartilhe o PRD rascunho com @architect
-2. Aguarde avaliação de viabilidade técnica
-3. Incorpore feedback técnico (ajustes de escopo, riscos identificados)
-4. Se @architect vetar algum item, documente a decisão
-
-### Passo 8 — Aprovação com @po
-1. Compartilhe o PRD atualizado com @po
-2. @po valida que é possível criar stories claras para cada item
-3. Incorpore ajustes de @po
-4. Obtenha aprovação formal de @po
-
-### Passo 9 — Publicação
-1. Salve o documento final em `docs/[projeto]/PRD.md`
-2. Versione o documento (v1.0)
-3. Notifique o time sobre a disponibilidade do PRD
-4. Acione @sm para iniciar criação de stories
-
----
-
-## Critérios de Saída
-
-O PRD está pronto quando:
-
-- [ ] Todos os épicos estão definidos com proposta de valor
-- [ ] Priorização MoSCoW aplicada a todas as funcionalidades
-- [ ] Personas definidas e priorizadas
-- [ ] Métricas de sucesso definidas (mínimo 3)
-- [ ] Não-escopo documentado explicitamente
-- [ ] @architect validou viabilidade técnica
-- [ ] @po aprovou formalmente
-- [ ] Documento salvo em `docs/[projeto]/PRD.md`
-
----
-
-## Output — Estrutura do PRD.md
-
-```markdown
-# PRD — [Nome do Produto]
-Versão: 1.0 | PM: Marina (@pm) | Data: YYYY-MM-DD
-Status: Rascunho | Em Revisão | Aprovado
-
-## 1. Visão e Proposta de Valor
-### Problema Central
-### Proposta de Valor Única
-### Estado Futuro Desejado
-
-## 2. Personas
-### Persona Primária: [Nome]
-### Persona Secundária: [Nome]
-
-## 3. Objetivos de Produto
-| Objetivo | Métrica | Baseline | Meta |
-|---------|--------|---------|------|
-
-## 4. Épicos e Funcionalidades
-
-### E-01 — [Nome do Épico]
-**Promessa de valor:** [Uma frase]
-**Prioridade:** Must Have
-
-#### Funcionalidades
-- [Feature 1] — Must Have
-- [Feature 2] — Should Have
-- [Feature 3] — Could Have
-
-### E-02 — [Nome do Épico]
-...
-
-## 5. Não-Escopo (Explícito)
-O que NÃO será construído nesta versão:
-- [Item 1]
-- [Item 2]
-
-## 6. Restrições
-- Prazo: [data]
-- Budget: [informação se disponível]
-- Tecnologia obrigatória: [se houver]
-- Regulatório: [compliance, LGPD, etc]
-
-## 7. Roadmap e Milestones
-| Milestone | O que inclui | Data estimada |
-|----------|------------|--------------|
-
-## 8. Riscos de Produto
-| Risco | Probabilidade | Impacto | Mitigação |
-|-------|--------------|--------|----------|
-
-## 9. Glossário
-[Termos de negócio específicos do domínio]
-
-## 10. Histórico de Versões
-| Versão | Data | Autor | Mudança |
-|--------|------|-------|--------|
-```
-
----
-
-*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*

package/template/.genia/development/tasks/criar-spec.md

@@ -1,188 +0,0 @@
-# Task: Criar SPEC-TECNICO
-
-> Tarefa executada por @architect após PRD aprovado por @pm e @po.
-> Output: `docs/[projeto]/SPEC-TECNICO.md` + ADRs iniciais
-
----
-
-## Objetivo
-
-Criar a especificação técnica completa que traduz os requisitos de negócio do PRD em decisões de arquitetura, tecnologia, estrutura de código e padrões de desenvolvimento. O SPEC-TECNICO é o guia técnico definitivo — qualquer decisão de implementação que não esteja aqui deve ser escalada para @architect antes de ser tomada.
-
----
-
-## Pré-requisitos
-
-Antes de iniciar, confirme:
-
-- [ ] `docs/[projeto]/PRD.md` existe e está aprovado por @pm e @po
-- [ ] @architect leu o PRD completamente
-- [ ] Acesso ao repositório (se brownfield) ou liberdade para definir stack (se greenfield)
-- [ ] Clareza sobre restrições de tecnologia (se houver imposições do cliente)
-
----
-
-## Passos de Execução
-
-### Passo 1 — Análise do PRD
-1. Leia o PRD completamente e anote:
-   - Requisitos funcionais por épico
-   - Requisitos não-funcionais (desempenho, segurança, disponibilidade)
-   - Integrações necessárias com sistemas externos
-   - Restrições tecnológicas declaradas
-2. Identifique perguntas técnicas abertas e resolva com @pm antes de continuar
-
-### Passo 2 — Definição de Stack
-1. Para cada camada da stack, avalie opções e registre decisão:
-   - **Frontend:** React, Next.js, Vue, etc.
-   - **Backend:** Node.js, Python, Go, etc.
-   - **Banco de dados:** PostgreSQL, MongoDB, Supabase, etc.
-   - **Autenticação:** NextAuth, Clerk, Auth0, etc.
-   - **Infraestrutura:** Vercel, Railway, AWS, etc.
-   - **Cache:** Redis, memória, etc. (se necessário)
-2. Para cada escolha, justifique explicitamente (não apenas "é popular")
-3. Registre alternativas consideradas e por que foram descartadas
-4. Crie ADRs para as decisões mais relevantes
-
-### Passo 3 — Arquitetura de Alto Nível
-1. Defina os componentes principais do sistema
-2. Descreva como cada componente se comunica (REST, GraphQL, WebSocket, etc.)
-3. Identifique boundaries de domínio (onde uma responsabilidade termina e outra começa)
-4. Documente o fluxo dos dados principais
-5. Escreva um diagrama textual (ou ASCII) da arquitetura
-
-### Passo 4 — Estrutura de Pastas
-1. Defina a estrutura completa de pastas do projeto:
-   ```
-   src/
-   ├── app/           # pages e rotas (Next.js)
-   ├── components/    # componentes reutilizáveis
-   │   ├── ui/        # componentes base (Button, Input, etc.)
-   │   └── [domain]/  # componentes de domínio
-   ├── lib/           # utilitários e helpers
-   ├── hooks/         # React hooks customizados
-   ├── services/      # chamadas a APIs externas
-   ├── types/         # tipagens TypeScript
-   ├── contexts/      # React Contexts
-   └── schemas/       # validação com Zod
-   ```
-2. Justifique escolhas não-óbvias
-3. Configure `tsconfig.json` com paths absolutos (`@/`)
-
-### Passo 5 — Modelagem de Dados
-1. Defina as entidades principais do domínio
-2. Para cada entidade: campos, tipos, relacionamentos, constraints
-3. Defina estratégia de migração de banco (ferramentas, convenções)
-4. Documente índices importantes para performance
-5. Identifique dados sensíveis e como serão protegidos (LGPD/GDPR)
-
-### Passo 6 — APIs e Contratos
-1. Para cada endpoint/operação relevante, defina:
-   - Método HTTP e path
-   - Request body (campos, tipos, validações)
-   - Response body (campos, tipos)
-   - Códigos de status e cenários de erro
-2. Defina convenções de nomenclatura de API
-3. Documente integrações com APIs externas (webhook, polling, SDK)
-
-### Passo 7 — Autenticação e Autorização
-1. Defina o mecanismo de autenticação escolhido
-2. Mapeie os perfis/roles de usuário
-3. Defina regras de autorização por role
-4. Documente estratégia de sessão (JWT, cookie, etc.)
-
-### Passo 8 — Estratégia de Testes
-1. Defina a pirâmide de testes:
-   - Unitários: ferramentas, o que testar, cobertura mínima
-   - Integração: quais fluxos, ferramentas
-   - E2E: ferramentas (Cypress, Playwright), fluxos críticos
-2. Configure as ferramentas de teste no projeto
-3. Defina cobertura mínima aceitável (GEN.IA OS default: 80%)
-
-### Passo 9 — Segurança e Boas Práticas
-1. Defina como secrets são gerenciados (variáveis de ambiente, Vault)
-2. Liste as vulnerabilidades OWASP Top 10 relevantes e como serão mitigadas
-3. Defina política de rate limiting se aplicável
-4. Documente estratégia de logging (sem dados sensíveis nos logs)
-
-### Passo 10 — ADRs de Fundação
-Para cada decisão arquitetural importante, crie um ADR:
-- `docs/adr/ADR-001-escolha-de-stack.md`
-- `docs/adr/ADR-002-estrategia-autenticacao.md`
-- `docs/adr/ADR-003-modelagem-de-dados.md`
-- [etc.]
-
----
-
-## Critérios de Saída
-
-O SPEC-TECNICO está pronto quando:
-
-- [ ] Stack definida e justificada para cada camada
-- [ ] Arquitetura de alto nível documentada
-- [ ] Estrutura de pastas definida
-- [ ] `tsconfig.json` com paths absolutos configurado
-- [ ] Modelagem de dados completa
-- [ ] APIs e contratos documentados (ao menos os principais)
-- [ ] Autenticação e autorização especificadas
-- [ ] Estratégia de testes definida com cobertura mínima
-- [ ] Considerações de segurança documentadas
-- [ ] ADRs iniciais criados (mínimo 3)
-- [ ] @qa revisou criticamente o spec (Fase 5 do Spec Pipeline)
-- [ ] Documento salvo em `docs/[projeto]/SPEC-TECNICO.md`
-
----
-
-## Output — Estrutura do SPEC-TECNICO.md
-
-```markdown
-# Especificação Técnica — [Nome do Projeto]
-Versão: 1.0 | Arquiteta: Arqui (@architect) | Data: YYYY-MM-DD
-Status: Rascunho | Em Revisão | Aprovado
-
-## 1. Visão Técnica
-### Objetivos Técnicos
-### Princípios Guias de Arquitetura
-
-## 2. Stack Tecnológica
-| Camada | Tecnologia | Versão | Justificativa |
-|--------|-----------|--------|--------------|
-
-## 3. Arquitetura de Alto Nível
-[Diagrama textual/ASCII]
-[Descrição dos componentes e comunicações]
-
-## 4. Estrutura de Pastas
-[Árvore de pastas comentada]
-
-## 5. Modelagem de Dados
-[Entidades, campos e relacionamentos]
-
-## 6. APIs e Contratos
-[Endpoints, request/response, erros]
-
-## 7. Autenticação e Autorização
-[Mecanismo, roles, regras]
-
-## 8. Integrações Externas
-[APIs de terceiros, webhooks, SDKs]
-
-## 9. Estratégia de Testes
-[Pirâmide, ferramentas, cobertura]
-
-## 10. Segurança
-[Gestão de secrets, OWASP, logging]
-
-## 11. Requisitos Não-Funcionais
-| RNF | Requisito | Como Medir |
-|-----|----------|-----------|
-
-## 12. ADRs
-[Links para os ADRs criados]
-
-## 13. Histórico de Versões
-```
-
----
-
-*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*

package/template/.genia/development/tasks/criar-story.md

@@ -1,185 +0,0 @@
-# Task: Criar Story
-
-> Tarefa executada por @sm. Somente @sm cria stories formais.
-> Output: `docs/stories/STORY-XXX.md`
-
----
-
-## Objetivo
-
-Criar uma story bem definida, no formato INVEST, com acceptance criteria mensuráveis, pronta para ser validada por @po e desenvolvida por @dev. Uma story mal escrita é a causa mais comum de retrabalho e confusão durante o desenvolvimento.
-
----
-
-## Pré-requisitos
-
-Antes de iniciar, confirme:
-
-- [ ] PRD.md aprovado existe (`docs/[projeto]/PRD.md`)
-- [ ] SPEC-TECNICO.md aprovado existe (`docs/[projeto]/SPEC-TECNICO.md`)
-- [ ] O épico pai da story está definido no PRD
-- [ ] Há backlog room para esta story (capacity do sprint permite)
-- [ ] @sm tem clareza sobre o que a story deve entregar
-
----
-
-## Como Determinar o Próximo Story ID
-
-1. Liste os arquivos em `docs/stories/`
-2. Identifique o maior número existente (ex: STORY-007)
-3. A próxima story será STORY-008
-4. Se não há stories existentes, começar em STORY-001
-
----
-
-## Passos de Execução
-
-### Passo 1 — Contexto
-1. Leia o épico pai no PRD para entender o contexto de valor
-2. Leia as seções relevantes do SPEC-TECNICO para entender implicações técnicas
-3. Verifique se há stories anteriores relacionadas que estabelecem contexto
-
-### Passo 2 — Definição da User Story
-1. Identifique a persona correta (do PRD)
-2. Defina a ação/funcionalidade específica (o mais granular possível)
-3. Defina o benefício de negócio (mensurável quando possível)
-4. Escreva no formato: "Como [persona], quero [ação], para [benefício]"
-
-**Teste de qualidade da User Story:**
-- A persona é real e definida no PRD? (não "como usuário genérico")
-- A ação é específica o suficiente para implementar? (não "melhorar a experiência")
-- O benefício é de negócio real? (não "para ter acesso a isso")
-
-### Passo 3 — Acceptance Criteria
-1. Para cada AC, pense: "Como @qa vai verificar isso?"
-2. Use o formato: "[Dado X], quando [ação Y], então [resultado Z]"
-   - Ou: "[Funcionalidade] deve [comportamento mensurável]"
-3. Cubra:
-   - Happy path (fluxo principal de sucesso)
-   - Edge cases relevantes (dados inválidos, estados vazios)
-   - Cenários negativos (o que deve ser impedido)
-4. Mínimo 3 ACs, máximo 8
-
-**Teste de qualidade dos ACs:**
-- @qa consegue verificar este AC sem ambiguidade?
-- O AC descreve o comportamento, não a implementação?
-- O AC é específico o suficiente? ("rápido" não é mensurável)
-
-### Passo 4 — Não-Escopo
-1. Liste explicitamente o que esta story NÃO inclui
-2. Seja específico sobre funcionalidades adjacentes que podem causar confusão
-3. Exemplo: "Esta story NÃO inclui a tela de edição — apenas criação"
-
-### Passo 5 — Dependências
-1. Identifique se esta story depende de outra estar concluída
-2. Se há dependências: referenciar os IDs das stories
-3. Se há bloqueadores técnicos: documentar e escalar para @architect
-
-### Passo 6 — Notas Técnicas
-1. Do SPEC-TECNICO, extraia informações relevantes para o @dev:
-   - Arquivos/módulos que devem ser criados ou modificados
-   - Padrões a seguir
-   - APIs externas envolvidas
-   - Considerações de segurança específicas
-2. Não tente especificar o "como" em detalhes — isso é papel do @dev e @architect
-
-### Passo 7 — Estimativa
-1. Estime o esforço em pontos usando a escala Fibonacci simplificada:
-   - **P (1-3 pts):** Story pequena, sem ambiguidade, menos de 1 dia
-   - **M (5 pts):** Story média, algumas decisões, 1-2 dias
-   - **G (8 pts):** Story grande, complexidade moderada, 2-3 dias
-   - **XG (13 pts):** Story muito grande — considere quebrar em 2 stories
-2. Se estimativa é XG ou maior: quebrar antes de validar com @po
-
-### Passo 8 — Self-Review
-Antes de enviar para @po, aplique o checklist INVEST:
-- [ ] **I**ndependente: pode ser desenvolvida sem dependência não-mapeada?
-- [ ] **N**egociável: os detalhes podem ser ajustados se necessário?
-- [ ] **V**aliosa: tem valor claro de negócio?
-- [ ] **E**stimável: conseguimos estimar o esforço?
-- [ ] **S**mall (pequena): cabe em uma sprint?
-- [ ] **T**estável: @qa consegue verificar todos os ACs?
-
-### Passo 9 — Criação do Arquivo
-1. Crie o arquivo em `docs/stories/STORY-XXX.md` seguindo o template
-2. Defina status inicial como `Draft`
-3. Envie para @po para validação
-
----
-
-## Template Completo
-
-```markdown
----
-id: STORY-XXX
-título: [Título descritivo em até 60 caracteres]
-épico: E-XX — [Nome do Épico]
-sprint: Sprint-XX
-estimativa: P | M | G | XG
-assignee: null
-status: Draft
-prioridade: CRÍTICO | ALTO | MÉDIO | BAIXO
-criada_por: "@sm"
-criada_em: YYYY-MM-DD
-aprovada_por: null
-aprovada_em: null
----
-
-# STORY-XXX — [Título]
-
-## User Story
-Como [persona definida no PRD],
-quero [ação/funcionalidade específica],
-para [benefício de negócio mensurável].
-
-## Contexto
-[1-3 parágrafos de contexto para @dev entender o porquê e o entorno da story]
-
-## Acceptance Criteria
-
-- [ ] AC-01: Dado [contexto], quando [ação], então [resultado esperado]
-- [ ] AC-02: Dado [contexto], quando [ação], então [resultado esperado]
-- [ ] AC-03: Dado [contexto], quando [ação], então [resultado esperado]
-
-## Não-Escopo (Explícito)
-Esta story NÃO inclui:
-- [Item 1 fora do escopo]
-- [Item 2 fora do escopo]
-
-## Dependências
-- Depende de: [STORY-XXX se houver | "nenhuma"]
-- Bloqueada por: ["nenhum bloqueador" | descrição]
-
-## Notas Técnicas
-[Extraídas do SPEC-TECNICO — orientações de implementação relevantes]
-- Arquivos/módulos afetados: [lista]
-- Padrões a seguir: [referência ao SPEC-TECNICO]
-- APIs envolvidas: [se houver]
-
-## Definition of Done
-- [ ] Código implementado e funcionando localmente
-- [ ] Testes unitários escritos (coverage >= 80%)
-- [ ] Lint e typecheck passando sem erros
-- [ ] QA aprovado por @qa (todos os ACs verificados)
-- [ ] Code review aprovado por @reviewer
-- [ ] PR criado por @devops
-- [ ] @po confirmou que a story atende aos critérios de negócio
-```
-
----
-
-## Critérios de Saída
-
-A task criar-story está concluída quando:
-
-- [ ] Arquivo `docs/stories/STORY-XXX.md` criado com template completo
-- [ ] User Story no formato correto
-- [ ] Mínimo 3 ACs mensuráveis e testáveis
-- [ ] Não-escopo documentado
-- [ ] Estimativa definida (P/M/G/XG)
-- [ ] Status: Draft
-- [ ] @po acionado para validação
-
----
-
-*GEN.IA OS v1.0 — {{TEAM_NAME}} — {{CREATOR_NAME}}*