---
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
## Pesquisa e grill técnico
Antes de rascunhar, explore o codebase real (CodeGraph/grep) para embasar arquitetura e stack em evidência concreta, não suposição. Leia PRD, ADRs e Context Pack, confirme contratos, dependências e seams. Use `codebase-design` para qualquer módulo novo ou alterado.
Depois da exploração, use `grill-with-docs` para travar decisões técnicas não resolvidas; `grill-me` é o fallback de etapa isolada. Faça uma pergunta por vez, com recomendação, e aguarde a resposta. Cubra stack, modelagem, integração, segurança, performance e compatibilidade até fechar os ramos de alto impacto. Não repita decisões já registradas.
Se houver bypass explícito ou `--unattended` autorizado, registre assumptions, riscos, fontes ausentes e perguntas em aberto; sem autorização, pause. Decisões com trade-off real usam `adr` em `docs/<slug-da-orquestracao>/adrs/adr-NN.md` antes de seguir.
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.
- Análise de impacto: tabela componente/tipo de impacto (novo/modificado/deprecado)/risco/ação necessária.
- Riscos.
- Decisões arquiteturais (decisão, racional, trade-offs, alternativas rejeitadas).
- 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`.
Após aprovação e save, indique o próximo passo (`/tasks` usando este Tech Spec como entrada) 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`.