# ADR - Runtime adapters `rmcp` e Rig

## Rastreabilidade
- Orquestração: `implementar-no-projeto-o-rig-rmcp-rmcp-para-fortalecer-o-mcp-rust-nativo-rig-como-provider-tool-adapter-opcional`
- Stage: adr
- Origem principal: `06-execution.md`
- Artefatos relacionados: `README.md`, `templates/capability-catalog.yaml`, `src/runtime/mcp.rs`, `src/domain/providers.rs`

## Status
- Estado: Aceito
- Data da decisão: 2026-06-17
- Dono técnico: mantenedor do `sdd-layer`
- Escopo: MCP Rust nativo, provider registry e adapters opcionais de runtime.

## Contexto
O `sdd-layer` já expunha um MCP Rust nativo read-only por stdio, implementado manualmente sobre JSON-RPC, e já mantinha um registry determinístico de providers. A solicitação pediu fortalecer o MCP Rust com `rmcp` e adicionar Rig como provider/tool adapter opcional, preservando a portabilidade entre clients e providers.

## Problema
Trocar o servidor MCP atual diretamente para um SDK async poderia aumentar o risco de regressão e alterar o caminho padrão do CLI. Ao mesmo tempo, tratar Rig como provider obrigatório confundiria o contrato: Rig é uma camada de abstração para providers e tools, não uma credencial ou modelo único.

## Decisão
Adicionar `rmcp` e `rig-core` como dependências opcionais por feature:

- `mcp-rmcp` compila metadata tipada de servidor com `rmcp`, sem substituir o transporte stdio atual nesta fatia.
- `rig-adapter` registra a disponibilidade de `rig-core` como adapter opcional.
- O MCP passa a expor `sdd_runtime_adapters` e `sdd://runtime/adapters` para clientes descobrirem adapters e fallbacks.
- O registry embutido ganha o provider `rig` com `kind: rig-adapter`, capabilities `chat`, `tools`, `code` e `provider-routing`, e auth por env vars do provider real.

## Alternativas consideradas
- Reescrever imediatamente o servidor MCP para `rmcp`: rejeitada por aumentar escopo, runtime e risco de compatibilidade.
- Não adicionar dependências e apenas documentar a intenção: rejeitada porque não valida compilação com crates reais nem cria superfície de descoberta.
- Fazer Rig executar geração direta nesta fatia: rejeitada por misturar provider/tool runtime com registry e MCP discovery.

## Consequências
- O binário default continua leve e determinístico.
- Features opcionais compilam contra `rmcp` e `rig-core` atuais.
- Clients MCP ganham introspecção sobre runtime adapters.
- A execução direta via Rig permanece uma próxima fatia explícita, não comportamento implícito.

## Impactos e riscos
- Impacto positivo: clientes MCP podem descobrir adapters opcionais sem acoplamento a provider/modelo.
- Impacto positivo: `rig` passa a existir no catálogo sem ativar chamadas remotas por padrão.
- Risco residual: a execução direta por Rig ainda não existe; usuários devem continuar usando adapters atuais ou fallback local.
- Risco residual: uma migração futura para transporte `rmcp` completo pode exigir runtime async e nova rodada de compatibilidade.

## Plano de adoção
- Usar `sdd providers list` e `sdd providers doctor` para descobrir o provider `rig`.
- Ativar `rig` em projetos específicos apenas quando houver execução direta via Rig ou integração local planejada.
- Usar `sdd_runtime_adapters` para verificar se o binário foi compilado com `mcp-rmcp` e/ou `rig-adapter`.
- Manter o MCP stdio manual como fallback até a migração `rmcp` completa ser aprovada.

## Plano de reversão
- Remover as features `mcp-rmcp` e `rig-adapter` do Cargo.
- Remover `sdd_runtime_adapters` e `sdd://runtime/adapters` do MCP.
- Remover `rig` do registry embutido e dos YAMLs versionados.

## Evidências
- `cargo check`
- `cargo check --features mcp-rmcp,rig-adapter`
- `cargo test -q`
- `cargo test -q --features mcp-rmcp,rig-adapter builds_rmcp_server_info_when_feature_is_enabled`
- `cargo run -q -- clients doctor --strict`

## Histórico de revisão
- 2026-06-17: ADR criado após execução e validação local.
