# Tasks - DDD Effect Rust Providers CLI
## Rastreabilidade
- Orquestração: DDD Effect Rust Providers CLI
- Slug: ddd-effect-rust-providers-cli
- Stage: tasks
- Estado atual: recorded
- Origem: Tech Spec aprovada em `03-techspec.md`.
- Próximo artefato: Refinement obrigatório em `05-refinement.md`.
## Backlog
### SDD-DDD-001 - Preparar módulos de domínio sem alterar comportamento
- Objetivo: criar estrutura `src/domain`, `src/application`, `src/runtime`, `src/infrastructure` e mover tipos puros de stages/artifacts/risk gradualmente.
- Escopo: tipos `ArtifactStage`, `ArtifactState`, `RiskResult`, `RiskFactor`, helpers de slug/stage file quando possível.
- Fora de escopo: workspace multi-crate e provider HTTP real.
- Estimativa: 5 SP.
- Critérios:
```gherkin
Cenário: comandos existentes preservados após a separação inicial
Dado o CLI atual do `sdd-layer`
Quando eu executo `cargo test`
Então todos os testes existentes continuam passando
E os comandos públicos documentados continuam disponíveis
```
### SDD-DDD-002 - Introduzir runtime/error/redaction base
- Objetivo: adicionar `SddError`, `SddResult`, `Secret<T>`, `RedactedDisplay` e scrubber central.
- Escopo: runtime base síncrono, sem provider remoto.
- Fora de escopo: async HTTP e Node bridge.
- Estimativa: 5 SP.
- Critérios:
```gherkin
Cenário: segredo não aparece em saída formatada
Dado um valor secreto carregado em `Secret<String>`
Quando o valor é usado em erro, debug seguro ou evento estruturado
Então a saída contém apenas marcador redigido
E não contém o valor original
```
### SDD-DDD-003 - Criar schema e parser de provider config
- Objetivo: adicionar bloco `providers` backward-compatible em config/presets e parser interno.
- Escopo: structs, defaults, precedência flags/env/config/default, schema `schemas/provider-config.schema.json`.
- Fora de escopo: chamada real de providers.
- Estimativa: 8 SP.
- Critérios:
```gherkin
Cenário: flags sobrescrevem config
Dado um `sdd.config.yaml` com provider default `codex`
Quando eu executo `sdd orchestration --provider claude --model test-model --dry-run "x"`
Então o provider resolvido é `claude`
E o modelo resolvido é `test-model`
```
### SDD-DDD-004 - Implementar `sdd providers list` e `sdd providers doctor`
- Objetivo: expor introspecção de providers sem rede por padrão.
- Escopo: subcomando `providers`, output humano e `--json`, validação de env var presente/ausente sem imprimir valor.
- Fora de escopo: validar credenciais remotamente.
- Estimativa: 5 SP.
- Critérios:
```gherkin
Cenário: doctor mostra env presente sem vazar segredo
Dado a variável `OPENAI_API_KEY` definida com um valor sensível sintético
Quando eu executo `sdd providers doctor --json`
Então o JSON contém `present: true`
E não contém o valor original
```
### SDD-DDD-005 - Conectar provider/model aos stages em modo seguro
- Objetivo: permitir flags `--provider`, `--model`, `--offline` nos comandos de orchestration/stages.
- Escopo: resolução e registro redigido no artefato/traceability; sem chamada remota por padrão.
- Fora de escopo: geração de conteúdo via LLM.
- Estimativa: 8 SP.
- Critérios:
```gherkin
Cenário: artifact registra provider e modelo sem token
Dado um comando `sdd prd --provider custom --model local-test --name ciclo "entrada"`
Quando o artefato é gerado
Então a seção de rastreabilidade contém provider `custom` e modelo `local-test`
E não contém valores de variáveis de ambiente sensíveis
```
### SDD-DDD-006 - Melhorar risk classifier para provider/secrets
- Objetivo: corrigir subestimação de risco identificada nesta orquestração.
- Escopo: termos `token`, `tokens`, `provider`, `api key`, `secret`, `segredo`, `credencial`; testes unitários.
- Fora de escopo: modelo probabilístico.
- Estimativa: 3 SP.
- Critérios:
```gherkin
Cenário: feature com tokens e provider é classificada como risco alto
Dado a descrição "usar provider externo com tokens"
Quando eu executo `sdd risk`
Então a classificação inclui fatores de segurança ou dependência externa
E exige Refinement
```
### SDD-DDD-007 - Implementar memory index derivado
- Objetivo: criar `.sdd/memory/learnings.jsonl` reconstruível a partir de artefatos aprovados/registrados.
- Escopo: `sdd memory status`, `sdd memory learn --name`, hash de fonte, ponteiros de evidência, redaction.
- Fora de escopo: banco remoto e embeddings.
- Estimativa: 8 SP.
- Critérios:
```gherkin
Cenário: learning aponta para fonte auditável
Dado uma orquestração com PRD aprovado e Review registrada
Quando eu executo `sdd memory learn --name "<ciclo>"`
Então cada learning gerado contém `source_artifact` e `source_hash`
E pode ser reconstruído a partir de `docs/<slug>/`
```
### SDD-DDD-008 - Preservar config nova em install/update
- Objetivo: garantir que `sdd update` não destrói providers, runtime bridge e memory config.
- Escopo: merge/preservação de YAML como no comportamento atual de `sdd.config.yaml`.
- Fora de escopo: migração complexa entre versões ainda não existentes.
- Estimativa: 5 SP.
- Critérios:
```gherkin
Cenário: update preserva provider customizado
Dado um projeto instalado com provider `custom` em `sdd.config.yaml`
Quando eu executo `sdd update`
Então o bloco do provider customizado permanece no arquivo
E os arquivos gerenciados pelo pacote são atualizados
```
### SDD-DDD-009 - Documentar providers, segurança e memória
- Objetivo: atualizar README, docs, presets e clients com provider selection e aprendizado incremental.
- Escopo: `README.md`, `docs/USAGE.md`, `docs/CLIENTS.md`, `docs/PROJECT-ONBOARDING.md`, presets, example.
- Fora de escopo: documentação de adapters remotos não implementados.
- Estimativa: 3 SP.
- Critérios:
```gherkin
Cenário: usuário encontra a precedência de configuração
Dado a documentação do projeto
Quando eu procuro por provider selection
Então encontro a ordem flags, env, config e defaults
E encontro a política de não registrar secrets
```
### SDD-DDD-010 - Spike controlado da bridge Node+Effect.ts
- Objetivo: decidir se a bridge entra no MVP ou fica postergada.
- Escopo: envelope JSON, detecção de runtime, teste feature-gated, ADR de decisão.
- Fora de escopo: mover orquestração principal para Node.
- Estimativa: 3 SP.
- Critérios:
```gherkin
Cenário: CLI não depende de Node quando bridge está desligada
Dado que `runtime.node_effect_bridge.enabled` é `false`
Quando eu executo `sdd doctor` e `sdd orchestration --dry-run`
Então nenhum comando exige `node`, `pnpm` ou `Effect.ts`
```
## Dependências
- SDD-DDD-002 depende parcialmente de SDD-DDD-001 para localização de runtime/errors.
- SDD-DDD-003 depende de SDD-DDD-002 para redaction segura.
- SDD-DDD-004 depende de SDD-DDD-003.
- SDD-DDD-005 depende de SDD-DDD-003 e SDD-DDD-004.
- SDD-DDD-007 depende de redaction de SDD-DDD-002.
- SDD-DDD-008 depende do schema/config de SDD-DDD-003.
- SDD-DDD-010 só deve iniciar depois do MVP Rust offline estar estável.
## Critérios de aceite
- Todos os cenários Gherkin listados no backlog têm teste automatizado ou justificativa objetiva no Refinement.
- Nenhuma task pode gravar token/API key em artifact, memory, stdout, stderr, JSON de doctor ou eventos.
- Comandos determinísticos continuam sem rede e sem Node.
- O MVP precisa entregar provider registry offline e redaction antes de qualquer chamada real a provider remoto.
## Ordem sugerida
1. SDD-DDD-006 - melhorar risk classifier cedo, pequeno e reduz risco de novos artefatos.
2. SDD-DDD-001 - separar módulos mínimos.
3. SDD-DDD-002 - runtime/error/redaction base.
4. SDD-DDD-003 - provider config/schema.
5. SDD-DDD-004 - providers list/doctor.
6. SDD-DDD-005 - flags provider/model nos stages.
7. SDD-DDD-008 - preservar config em update.
8. SDD-DDD-007 - memory index derivado.
9. SDD-DDD-009 - documentação.
10. SDD-DDD-010 - spike Node+Effect.ts, com decisão explícita antes de implementar bridge real.