# SDD Execution

Antes de rodar comandos `sdd`, resolva o CLI uma vez: use `sdd` quando `command -v sdd` encontrar o binário; no checkout fonte `sdd-layer`, use `cargo run --bin sdd --`; se ambos falharem, reporte instalação/PATH ausente com o comando exato que precisa ser reexecutado.

Use a skill ou subagent desta etapa se o client a expuser. Se a skill/subagent não existir ou não carregar, este adapter é o fallback executável: siga as instruções abaixo e delegue estado, persistência e validação ao CLI `sdd`.

Rode `sdd execution "$ARGUMENTS"` e use o subagent `execution` para implementar uma tarefa por vez.

Entrada:

$ARGUMENTS

Antes de editar:

- Gere ou leia `sdd context build --name "<orquestracao>" --stage execution --write` quando houver artifact store.
- Use `code-intelligence` se CodeGraph/Lexa estiverem disponíveis; caso contrário, use `rg --files`, `rg` e leitura focada.
- Use `execution-discipline`: tracer bullet vertical, teste falhando quando houver seam correto, loop reproduzível para bug/performance e verificação fresca antes de conclusão.
- Preserve mudanças locais, não reverta trabalho externo e limite o escopo a task indicada.

Saída obrigatória:

- Resumo do implementado.
- Arquivos criados/alterados.
- Decisões técnicas.
- Como testar.
- Impactos.
- Pendências.
- Rastreabilidade para Tasks/Refinement.
- Code intelligence/fallback usado.
- Teste ou loop de diagnóstico criado, ou justificativa quando não houver seam adequado.
- Comandos de verificação frescos com resultado.

Salve evidências em `docs/<slug-da-orquestracao>/06-execution.md` via `sdd artifact save "<nome-da-orquestracao>" execution --file <arquivo> --state recorded`. Após Execution, rode `sdd adr` quando houver decisão arquitetural criada, confirmada ou alterada.

Antes de persistir qualquer artefato, garanta que o artifact store exista com `sdd init "<nome-da-orquestracao>"` quando ainda não houver `docs/<slug-da-orquestracao>/traceability-map.yaml`.
