RFC: Typed transport/config ABI as a prerequisite for multi-language SDKs

[lanycrost]

Summary

The Python and TypeScript SDK RFCs are open, but the transport/config ABI they will inherit is still too map-shaped and implicit. Before we scale SDK support across languages, we should decide which transport/config structures need a typed shared contract and where those types live.

Why this needs a discussion

This is not a bubu-sdk-go-only cleanup. The same ABI currently crosses tractatus, core, bobravoz-grpc, and bubu-sdk-go, and it will become much harder to change once multiple SDKs ship.

Current evidence

• bubu-sdk-go/engram/transport.go still exposes transport config as map[string]any.
• bubu-sdk-go/runtime/context.go decodes transport descriptors from env as untyped JSON-shaped objects.
• bubu-sdk-go/transport_envelope.go mirrors the same flexible shape into the streaming envelope path.
• Related open work already exists in tractatus#13, tractatus#14, and tractatus#15, while the higher-level SDK expansion discussions are #50 and #51.

Questions to settle

1. What belongs in the typed shared ABI versus driver-specific extension points?
2. Should transport descriptors become typed proto/config objects, or do we keep a small typed core plus opaque extension payloads?
3. Which repository is the real contract authority: tractatus, core, or a split between the two?
4. How do we version this without freezing accidental Go-specific assumptions into future SDKs?
5. What is the minimum typed contract we need before Python/TypeScript SDK work becomes implementation instead of re-design?

Desired outcome

A concrete cross-repo plan for tightening the transport/config ABI so new language SDKs do not inherit an overly Go-shaped or map[string]any-heavy contract by accident.