sdd-layer 0.24.1

Spec-Driven Development CLI and agent harness
---
description: Etapa 6 - Execution do fluxo SDD
argument-hint: "\"<task aprovada ou contexto>\""
agent: sdd-orchestrator
---

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`.

Nesta superfície OpenCode, propague o provider real para o harness com `SDD_PROVIDER=opencode`. Se a sessão estiver usando um modelo específico fora do roteamento, exporte também `SDD_MODEL=<modelo>` e, se aplicável, `SDD_EFFORT=<medium|high|xhigh>`.

Rode `SDD_PROVIDER=opencode 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.
- Task é fix de bug ou regressão de performance: use `diagnosing-bugs` (loop de feedback apertado antes de qualquer hipótese, 3-5 hipóteses ranqueadas, instrumentação tagueada, regressão pós-fix) em vez de patchar por tentativa.
- Task cria ou altera módulo/interface: use `codebase-design` (deep module — pequena interface, seam limpo, testável por ele).
- 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_PROVIDER=opencode sdd adr` quando houver decisão arquitetural criada, confirmada ou alterada.

Após rodar os testes e concluir, indique o próximo passo (próxima task pendente, ou `/review` se todas as tasks estiverem concluídas) sem esperar o usuário perguntar.

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`.