---
description: Etapa 3 - Tech Spec do fluxo SDD
argument-hint: "\"<PRD aprovado 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 techspec "$ARGUMENTS"` e use o subagent `techspec` para criar a arquitetura aterrada no código atual.
Entrada:
$ARGUMENTS
Saída obrigatória:
- 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.
- Diagramas técnicos Mermaid/Excalidraw em `## Diagramas`, ou `Não aplicável` com justificativa. Quando houver companion visual do `diagram-design`, referencie `assets/diagrams/*.html|*.svg` como derivado revisável.
- Rastreabilidade para PRD.
Pare para checkpoint humano antes de marcar como `approved`. Depois salve em `docs/<slug-da-orquestracao>/03-techspec.md` via `sdd artifact save "<nome-da-orquestracao>" techspec --file <arquivo> --state approved`.
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`.