# Idea - SDD Runtime-Agnostic Engines e Adapters

## Rastreabilidade
- Orquestração: a-jogada-mais-limpa-sdd-continua-runtime-agnostic-o-core-segue-dono-do-contrato-sdl-8ee3bafff01a
- Slug: a-jogada-mais-limpa-sdd-continua-runtime-agnostic-o-core-segue-dono-do-contrato-sdl-8ee3bafff01a
- Stage: idea
- Estado atual: recorded
- Origem: `00-project-discovery.md` e `00-risk-classification.md`
- Entrada original: "A jogada mais limpa: SDD continua runtime-agnostic. O core segue dono do contrato SDLC; Rig/Flue/LangGraph/Agno viram engines/adapters. Isso preserva exatamente a direção que o projeto já vem seguindo: .agents como contrato canônico, MCP/trace como observabilidade e client adapters gerados."

## Problema
O `sdd-layer` já caminha para portabilidade entre clients, providers e superfícies geradas, mas a introdução de runtimes como Rig, Flue, LangGraph e Agno pode criar uma ambiguidade arquitetural: eles são o motor do SDLC ou apenas adaptadores opcionais de execução?

Se essa fronteira não ficar explícita, o projeto corre o risco de espalhar regras de etapa, checkpoint, artifact store, traceability e validação dentro de frameworks de runtime. Isso enfraquece o contrato canônico `.agents`, dificulta compatibilidade entre Codex, Claude, Cursor, opencode, Devin, Trae e futuros clients, e transforma observabilidade MCP/trace em dependência operacional em vez de superfície de leitura.

## Objetivo
Consolidar a decisão de produto e arquitetura: o SDD permanece runtime-agnostic. O core do `sdd-layer` continua dono do contrato SDLC, enquanto Rig, Flue, LangGraph, Agno e runtimes futuros entram como engines/adapters opcionais, descobertos por capability catalog, expostos por MCP/trace quando disponível e sempre acompanhados de fallback local determinístico.

## Usuários
- Mantenedor do `sdd-layer`, que precisa evoluir o core sem amarrá-lo a um runtime específico.
- Agentes e clients que consomem `.agents`, `.codex`, `.claude`, `.cursor`, `.opencode`, `.devin`, `.trae` e Antigravity.
- Times que instalam SDD em projetos brownfield e precisam do mesmo contrato em ambientes online, offline, com MCP ou sem MCP.
- Implementadores de adapters que querem integrar engines externas sem reescrever o pipeline SDLC.

## Critérios de sucesso
- O core continua responsável por estágios, schemas, artifact store, traceability map, checkpoints, validação, providers e comandos determinísticos.
- `.agents` permanece a fonte canônica de skills e regras; superfícies de client continuam geradas ou sincronizadas a partir dela.
- Rig, Flue, LangGraph, Agno e similares são descritos como adapters opcionais, não como fonte de verdade do pipeline.
- MCP e trace são observabilidade e integração read-only/derivada; `.sdd/*.jsonl` e `docs/<slug>/` seguem como fontes locais auditáveis.
- Todo adapter novo declara capacidades, limites, fallback e evidências em contratos provider-neutral.
- A experiência funciona sem tool calling, sem MCP, sem browser, sem subagents e sem rede, desde que o harness consiga ler Markdown, produzir texto e persistir arquivos.
