# Idea - DDD Effect Rust Providers CLI
## Rastreabilidade
- Orquestração: DDD Effect Rust Providers CLI
- Slug: ddd-effect-rust-providers-cli
- Stage: idea
- Estado atual: recorded
- Origem: pedido humano inicial e discovery local.
- Próximo artefato: PRD em `02-prd.md`.
## Problema
O `sdd-layer` já entrega um CLI Rust útil e surfaces para vários agentes, mas concentra muito comportamento em um único binário monolítico. Para evoluir para orquestração real com providers selecionáveis, aprendizado incremental e possível runtime TypeScript, o projeto precisa de fronteiras de domínio claras e de uma camada de efeitos que torne dependências, falhas, recursos e observabilidade explícitos.
Sem isso, cada nova integração tende a virar mais um `match` ou helper em `src/main.rs`, com risco de vazar tokens em logs/docs, duplicar lógica entre clientes, quebrar installers e dificultar testes de providers.
## Objetivo
Transformar o `sdd` em um harness mais poderoso e evolutivo: DDD no Rust core, runtime/abstração Effect-like para compor comandos e dependências, provider registry selecionável via CLI/config/env, memória incremental baseada em artefatos SDD e bridge Node+TypeScript com Effect.ts somente onde trouxer ganho real de orquestração.
## Usuários
- Mantenedor do `sdd-layer`, que precisa evoluir CLI, pacote e docs sem quebrar projetos instalados.
- Pessoa usando `sdd` em projetos reais, que quer escolher `codex`, `claude`, `gemini`, `opencode` ou outro provider sem trocar ferramenta.
- Agentes Codex/Claude/opencode/Cursor que precisam chamar o CLI como harness determinístico.
- Futuro integrador de provider customizado, que precisa implementar adapter sem reescrever o fluxo SDD.
## Critérios de sucesso
- O CLI aceita provider/modelo por flags, config e env com precedência documentada.
- Providers ficam atrás de ports/adapters testáveis, com capabilities declaradas e sem segredo em artefatos.
- O Rust core ganha módulos de domínio claros e reduz o acoplamento do `src/main.rs`.
- A memória incremental aprende com `docs/<slug>/`, schemas e resultados de uso sem inventar fonte de verdade paralela.
- A bridge Node+TypeScript é opcional, isolada e invocada pelo CLI quando habilitada.
- Fluxos existentes (`sdd init`, `update`, `doctor`, `clients`, stages, `artifact`, `ci`) continuam compatíveis e cobertos por testes.