Los contratos binarios entre el control plane, el daemon y los plugins nativos, qué debe definir cada uno y dónde está su especificación.
Implementado. Cada protocolo tiene su especificación humana en
protocols/<nombre>/. La referencia generada (referencia/protocolos/) copia esas especificaciones sin reescribirlas y enlaza sus vectores de conformidad.
protocols/ contiene los contratos binarios entre Bun y Zig, y entre plugins nativos y el
runtime. No contiene el bus entre servicios: sus contratos viven en
packages/api-contracts/src/bus y el sobre firmado en spire. Tampoco modela los bytes de vídeo
como protocolo, porque el daemon los sirve directamente.
Es una regla de repositorio, no una sugerencia:
schemaVersion;Un protocolo no importa el runtime de las aplicaciones.
| Protocolo | Qué fija | Documentos |
|---|---|---|
session-ipc | Control Bun ↔ daemon sobre socket Unix. Desde la versión 2 es spire: sobre firmado, handshake, política deny-by-default | SESSION_PROTOCOL.md, messages/, version-history.md |
capability-token | Formato binario de la SCT que emite playback-svc y verifica el daemon, con vectores de conformidad TS↔Zig | SCT_SPEC.md, vectors.json |
media-object | Unidades de media abstractas (MediaObject, MediaUnit) y la frontera de delivery, independientes del transporte | MEDIA_OBJECT_SPEC.md, DELIVERY_TRANSPORT.md, version-history.md |
schema-versioning | Reglas de evolución de esquemas para el bus, el IPC y la serialización de media | README.md, BINDINGS.md, FIXTURES.md |
plugin-abi | ABI C versionada para plugins nativos. Objetivo, no implementado: falta definir el modelo de confianza y el ciclo de vida | README.md |
El bus y el socket de control comparten el sobre v2 de spire; su primer byte es la versión del
sobre. Cada contrato declara además su propia version, independiente del sobre. Un cambio
incompatible de un contrato es una versión nueva del contrato; un cambio del formato del sobre es
una versión nueva del sobre, nunca una extensión.
Reglas de compatibilidad: un esquema nuevo debe poder leer mensajes del viejo, así que los campos nuevos son opcionales y no se cambia el tipo de un campo existente.
El paso de la versión 1 a la 2 del socket de control fue una ruptura deliberada y sin modo de compatibilidad: Styx es el único cliente, y mantener la versión 1 habría dejado el socket abierto sin autenticar.
Dos protocolos viven en los repositorios de los SDK y Styx los consume fijados por hash:
spec/ENVELOPE_V2.md en el repositorio de spire);Ambos se describen en zkit, spire y conduit.
El nivel de plugins nativos por C ABI es un objetivo (decisión r13) y no se implementa hasta definir el modelo de confianza. El punto de extensión vivo hoy es TypeScript: plugins y fuentes.