---
description: Fluxo SDD canônico para Cursor Agent
globs:
alwaysApply: true
---

Use o fluxo Spec-Driven Development deste projeto.

- Nome canônico: `orchestration`.
- Alias legado: `orchestrator`, somente para retrocompatibilidade.
- Preparação: `sdd discover`, `sdd risk`, `sdd doctor`.
- Fluxo completo: `sdd orchestration "<ideia>"`.
- Loop agentic: `sdd workflow run agentic-sdd-loop --input "<demanda>" --max-iterations 3 --json`.
- ADR: após Execution, rode `sdd adr` quando houver decisão arquitetural criada, confirmada ou alterada.
- Persistência: antes de criar artefatos de etapa, rode `sdd init "<nome-da-orquestracao>"` para criar `docs/<slug-da-orquestracao>/` e `traceability-map.yaml`.
- Salve cada etapa com `sdd artifact save`; use `approved` somente depois do checkpoint humano e `recorded` para etapas informativas.
- Checkpoints humanos obrigatórios: PRD, Tech Spec, Refinement quando risco exigir, Review/merge e Deploy quando aplicável.
- Ao trabalhar em uma tecnologia específica, consulte o Project Discovery e as recomendações de skills/rules geradas em `00-project-discovery.md`.

## Contrato de persistência no Cursor

- Use o binário `sdd` instalado no `PATH` para conduzir orquestrações; não troque por `cargo run` quando a tarefa for operar um projeto SDD já instalado.
- Defina um nome curto de ciclo e rode `sdd init "<nome-da-orquestracao>"` antes de sintetizar PRD, Tech Spec, Tasks ou qualquer artefato longo.
- Em seguida rode `sdd orchestration --name "<nome-da-orquestracao>" "<ideia>"` para registrar README e risco inicial em `docs/<slug-da-orquestracao>/`.
- Materialize cada etapa no arquivo esperado em `docs/<slug-da-orquestracao>/<NN>-<stage>.md` antes de mostrar o conteúdo final no chat.
- Depois de materializar, registre o estado com `sdd artifact save "<nome-da-orquestracao>" <stage> --file docs/<slug-da-orquestracao>/<NN>-<stage>.md --state recorded` para etapas informativas, ou `--state approved` somente após checkpoint humano explícito.
- Se o terminal, hook ou permissão do cliente bloquear `sdd` ou escrita em `docs/`, pare e informe o comando/path bloqueado; não entregue o artefato final apenas na sessão do chat.

## Formato de saída por etapa

Use o mesmo contrato de saída dos subagents `.codex/agents` e `.claude/agents` em qualquer cliente:

- `idea`: visão geral da ideia, problema, público-alvo, proposta de valor, jornada principal, MVP, fora do MVP, hipóteses, riscos, perguntas em aberto e `Diagramas` opcional quando o visual melhorar entendimento.
- `prd`: resumo executivo, contexto, objetivos, não objetivos, personas, casos de uso, fluxos, requisitos funcionais e não funcionais, regras de negócio, estados, critérios de aceite, métricas, riscos, dependências, escopo do MVP e `Diagramas` com Mermaid/Excalidraw ou justificativa de `Não aplicável`; companion `diagram-design` entra como referência `assets/diagrams/*.html|*.svg`.
- `techspec`: visão técnica, arquitetura, stack, estrutura de pastas, modelagem de dados, contratos de API, fluxos técnicos, estados/eventos, autenticação/autorização, validação, erros, observabilidade, segurança, performance, testes, riscos, decisões arquiteturais, plano de implementação e `Diagramas` técnicos com Mermaid/Excalidraw ou justificativa de `Não aplicável`; companion `diagram-design` entra como derivado visual.
- `tasks`: épicos, histórias técnicas, tarefas atômicas em formato executável (`T-01` ou `TSK-01`), ordem sugerida, dependências, critérios de aceite em Gherkin, DoD, estratégia de testes, arquivos prováveis e `Prompts Agent` standalone por tarefa.
- `refinement`: documento único e enxuto com `Resumo`, `Solução proposta`, `Pontos de observação`, `Checklist macro`, `Subtasks` com estimativas em múltiplos de 0.5h, `Definition of Done` e `Flags, Remote Configs e Configurações`.
- `execution`: resumo do implementado, arquivos criados/alterados, decisões técnicas, como testar, impactos e pendências.
- `adr`: rastreabilidade, status, contexto, problema, decisão, alternativas, consequências, impactos/riscos, plano de adoção, plano de reversão, evidências e histórico de revisão.
- `review`: veredito `Aprovado | Aprovado com ressalvas | Reprovado`, pontos positivos, problemas, severidade, sugestões, testes recomendados e checklist de qualidade.
- `memory`: estado atual, funcionalidades implementadas, arquitetura atual, decisões, padrões, comandos úteis, variáveis de ambiente, testes, pendências, próximos passos e contexto resumido.

Todo artefato materializado deve ter `Rastreabilidade`, apontar para o artefato anterior e ser salvo em `docs/<slug-da-orquestracao>/` com `sdd artifact save`. Use `recorded` para etapas informativas e `approved` somente depois de checkpoint humano.
