O Project transforma o Brief aprovado em uma definição operacional do produto. Ele é o documento de referência para produto, engenharia e planejamento durante toda a execução.
Fase: 1 — Definição
Pré-requisito: Docs/brief.md aprovado
Template: Templates/Full/project.md ou Templates/Quick/project.md
Artefato oficial: Docs/project.md
Próximos artefatos: Docs/stack.md · Docs/user-stories.md
Quando criar ou revisar
- Após aprovação do
Docs/brief.md - Mudança relevante de escopo, objetivo ou público
- Discovery que revelou premissas incorretas
- Mudança de estratégia de entrega
Full vs Quick
| Situação | Template |
|---|---|
| Projeto novo com múltiplos perfis, integrações e fases | Templates/Full/project.md |
| Feature com contexto já definido e escopo pequeno | Templates/Quick/project.md |
| Ambiguidade surgiu durante o Quick | Migrar para Full na mesma task |
Estrutura — Project Full
O template Full tem 18 seções.
1. Identificação
Nome do projeto:
Slug / identificador interno:
Versão do documento:
Status: [planejamento | em andamento | pausado | concluído | cancelado]
Responsável principal:
Stakeholders:
Data de criação:
Última atualização:2. Definição do Projeto
- Resumo executivo: o que está sendo construído em uma síntese objetiva
- Descrição oficial: o que está sendo construído, para quem, com qual propósito e em qual contexto
- Origem da demanda: briefing, necessidade interna, oportunidade, problema operacional, solicitação de cliente
- Documento de origem: referência ao
Docs/brief.md
3. Objetivo do Projeto
Objetivo principal: [resultado central esperado]
Objetivos secundários:
- [objetivo 1]
- [objetivo 2]
Transformação esperada: [como o cenário muda após a implantação]4. Problema que o Projeto Resolve
Problema central:
Dores identificadas:
- [dor 1]
- [dor 2]
Impacto atual do problema: [operacional / financeiro / estratégico / experiência]
Consequência de não resolver:5. Público-alvo e Perfis Impactados
Perfis principais de usuário:
- [perfil 1]: [necessidade]
- [perfil 2]: [necessidade]
Perfil operacional / técnico dos usuários:
[nível técnico, contexto de uso, frequência, dispositivo]
Quem usa diretamente:
Quem é impactado indiretamente:6. Escopo do Projeto
Escopo principal:
- [entrega 1]
- [entrega 2]
Obrigatório nesta fase:
- [item obrigatório]
Desejável, mas não obrigatório agora:
- [item desejável]
Fora de escopo:
- [item fora]
Limites explícitos:
[o que o projeto não tentará resolver neste momento]7. Entregáveis Esperados
Entregáveis documentais (artefatos de Docs/ que nascem deste projeto):
- Docs/project.md
- Docs/stack.md
- Docs/user-stories.md
- Docs/pages.md
- Docs/flow.md
- Docs/design-system.md
- Docs/tokens.json
- Docs/entities.md
- Docs/architecture.md
- Docs/contract.yaml
- Docs/structure.md
- Docs/deploy.md
- Docs/plan.md
- Docs/tasks.md
- Docs/control.mdEntregáveis operacionais: deploy funcional, ambiente configurado, fluxo validado, testes mínimos definidos.
8. Regras de Negócio Conhecidas
- Regras confirmadas até o momento
- Restrições por perfil, permissão ou papel
- Condicionais, aprovações ou exceções já conhecidas
9. Critérios de Sucesso
O que define sucesso: [objetivo em linguagem objetiva]
Critérios principais:
- [critério mensurável 1]
- [critério mensurável 2]
Indicadores ou métricas:
- [métrica 1]
Resultado mínimo aceitável:10. Premissas do Projeto
Condições assumidas como verdadeiras para que o plano atual seja válido. Se uma premissa mudar, o project deve ser revisado.
11. Restrições do Projeto
Técnicas: [ex.: não pode mudar banco de dados]
Negócio: [ex.: sem aumento de custo de infra]
Operacionais: [ex.: precisa funcionar offline]
Legais: [ex.: LGPD, PCI-DSS]
Prazo: [ex.: entrega até Q3]
Orçamento: [ex.: sem contratação nova]12. Riscos Iniciais
- Riscos conhecidos no início do projeto
- Impacto potencial de cada risco
- Mitigações iniciais imaginadas
13. Dependências Conhecidas
Técnicas: [bibliotecas, serviços, versões]
Externas: [serviço, fornecedor, cliente, time externo]
Internas: [time, pessoa, sistema, processo]14. Contexto de Mercado / Produto
- Nicho ou mercado
- Contexto competitivo ou de referência
- Referências relevantes com observações
- Diferencial esperado do projeto
15. Estratégia Inicial de Entrega
Estratégia: [MVP | incremental | por módulos | por fluxo crítico | por release]
Prioridade inicial de construção:
- [prioridade 1]
- [prioridade 2]
O que deve ser construído primeiro:
O que pode ficar para fases posteriores:16. Diretrizes para os Próximos Documentos
Orientações objetivas de como este project deve ser interpretado por cada artefato seguinte:
Docs/stack.md — restrições e preferências que orientam a stack
Docs/user-stories.md — perfis, fluxos e problemas que devem ser cobertos
Docs/pages.md — áreas, telas ou módulos já esperados
Docs/flow.md — jornadas principais que precisam existir
Docs/design-system.md — expectativas de consistência visual e acessibilidade
Docs/tokens.json — necessidades de tokenização visual e temas
Docs/contract.yaml — capacidades de API e contratos externos esperados
Docs/plan.md — prioridades e marcos que devem guiar a execução17. Síntese Operacional para Dev e AI
O que este projeto é:
[linguagem direta]
O que precisa ser entregue:
- [entrega 1]
- [entrega 2]
O que é prioridade máxima:
- [prioridade 1]
O que não deve acontecer:
- [erro a evitar]
O que ainda está indefinido:
- [ponto indefinido]
Como os próximos documentos devem interpretar este projeto:
[orientação para quem vai escrever Stack, Stories, Pages, Fluxo, Contratos e Planejamento]18. Aprovação e Controle
Status: [pendente | aprovado | revisando]
Aprovado por:
Data de aprovação:
Observações finais:Estrutura — Project Quick
Para escopo pequeno com contexto já compartilhado:
## Nome do projeto
[preencher]
## Resumo executivo
[o que é o projeto de forma objetiva]
## Objetivo principal
[resultado principal esperado]
## Problema que resolve
[problema central sendo atacado]
## Público-alvo
- [perfil 1]
- [perfil 2]
## Escopo inicial
- [item 1]
- [item 2]
## Obrigatório nesta fase
- [item]
## Fora de escopo
- [item]
## Regras de negócio conhecidas
- [regra]
## Critérios de sucesso
- [critério mensurável]
## Restrições
- [restrição]
## Riscos iniciais
- [risco]
## Dependências conhecidas
- [dependência]
## Estratégia inicial de entrega
[MVP | incremental | por módulos]
## Direção para os próximos documentos
Docs/stack.md: [orientação]
Docs/user-stories.md: [orientação]
Docs/pages.md / flow.md:[orientação]
Docs/contract.yaml: [orientação]
Docs/plan.md / tasks.md:[orientação]
## Síntese para Dev e AI
O que estamos construindo: [preencher]
O que é prioridade: [item]
O que está indefinido: [ponto]Prompt para gerar com agente
Atue como ScopeAgent.
Objetivo: criar Docs/project.md com base em Docs/brief.md
Carregue contexto base:
- GUIDE.md
- Skills/user-stories.md
- Templates/Full/project.md
- Docs/brief.md
Preencha as 18 seções do template Full.
Não repita o Brief literalmente — aprofunde a visão do produto.
Seção 16 (Diretrizes para próximos documentos) deve ter orientação objetiva por artefato.
Seção 17 (Síntese para Dev e AI) em linguagem direta, sem marketing.
Marque [indefinido] onde houver lacuna.Definição de pronto
O project está pronto quando:
- Objetivo principal sem ambiguidade — diferente da descrição do Brief
- Público-alvo com necessidade por perfil
- Escopo e não escopo acionáveis — independentes de interpretação
- Restrições relevantes registradas
- Critérios de sucesso com métricas observáveis
- Seção 16 preenchida — cada artefato seguinte sabe como interpretar este project
- Seção 17 preenchida com síntese objetiva para Dev e AI
- Aprovação registrada na seção 18
Atenção
O Project não é um segundo Brief. O Brief responde "qual problema?". O Project responde "o que construímos para resolver esse problema?". Repetir o Brief em project.md é o erro mais comum neste artefato.
Erros comuns
| Erro | Correção |
|---|---|
| Repetir o Brief sem aprofundar | Focalizar no produto — o que está sendo construído e como |
| Público-alvo vago ("usuários finais") | Nomear perfis com contexto de uso e necessidade real |
| Backlog detalhado dentro do Project | Backlog vai em Docs/tasks.md, não aqui |
| Não escopo ausente | Deixar o não escopo vago cria deriva de escopo durante a execução |
| Seção 16 em branco | Cada artefato seguinte perde o fio condutor do projeto |
Documentos que nascem do Project
Docs/project.md (aprovado)
↓
Docs/stack.md — escolhas tecnológicas orientadas pelo projeto
Docs/user-stories.md — comportamentos esperados por perfil
Docs/pages.md — telas e módulos derivados do escopo
Docs/plan.md — estratégia macro de implementação