zkit, spire y conduit

Implementado. Los tres SDK viven en repositorios propios y Styx los consume en sus caminos de producción. La API de cada uno se genera de sus comentarios /// bajo referencia/zig/.

Tres bibliotecas, una reglaCopiar enlace

La regla es de dec-0103: lo genérico del data plane no se reimplementa en Styx. Si una primitiva es útil fuera de Styx, vive en una biblioteca, se fija por versión y se consume. Dos cosas lo hacen cumplir: check:zkit-no-reimpl falla si un fichero del daemon declara un símbolo con nombre de zkit que no es un alias o llama directamente a la libc que zkit envuelve, y los SDK no se copian ni se vendorizan.

Los primeros símbolos de zkit nacieron en un experimento de este mismo repositorio (el spike del byte runtime, ya retirado): Styx es origen de la extracción, no consumidor original.

Cómo se fijanCopiar enlace

• En Zig, por URL de un archivo de commit y hash de contenido en native/zig/build.zig.zon. Un cambio de versión es un cambio visible en esa tabla.
• En TypeScript, @spire/bus entra por una dependencia de commit en los package.json.
• La capa QUIC es un submódulo (docs/references/quic-zig, fork MKS2508/quic-zig, ruta de build.zig.zon), con su política de versiones en dec-0105. En un clon nuevo hay que inicializar el submódulo antes de compilar.
• El daemon importa a media-core sin QUIC: ficheros, entorno, relojes, aleatoriedad y locks vienen de zkit, y del fork sólo se usan los sockets.

zkitCopiar enlace

zkit.safety es la capa que impone los invariantes de seguridad del data plane:

• handles tipados con generación para que una referencia a un recurso liberado falle en lugar de apuntar a otro;
• un asignador con presupuesto anidable (daemon, actor, sesión);
• raíces de ficheros fd-relativas (Root), sin API que acepte una ruta absoluta;
• lectores acotados y aritmética comprobada para los parsers de entrada no confiable;
• utilidades de fuzz.

spireCopiar enlace

spire es el punto único de seguridad de las comunicaciones (dec-0119, dec-0120):

• el sobre v2 firmado, la identidad de servicio, la política deny-by-default por mensaje, el anti-replay, los límites por identidad y la auditoría;
• tres transportes con el mismo sobre y las mismas políticas: en proceso, socket Unix y NATS;
• el verificador de capacidades SCT (spire.cap en Zig, @spire/bus/sct en TS) con una sola implementación por lenguaje;
• generación de código: de los esquemas de @styx/api-contracts sale el espejo Zig del daemon, con vectores de conformidad y fuzz diferencial entre TS y Zig.

Detalle de cómo se usa en bus y contratos y de qué protege en comunicaciones entre procesos.

conduitCopiar enlace

conduit define el protocolo de subida (dec-0121). El servidor es independiente del transporte y exige autorización en cada petición, con cuotas, preparación fd-relativa y hash en streaming. En Styx:

• el daemon sirve el servidor sobre HTTP/1.1 detrás de un terminador TLS (IngestSink), apagado mientras no se configure una raíz de ingesta;
• el cliente es el CLI styx-upload (native/zig/cli/styx_upload.zig), que renueva la capacidad antes de que caduque y reanuda tras un corte;
• playback-svc decide quién sube y firma la capacidad SCT de alcance ingest; el alta en el catálogo viaja por el bus y es idempotente.

Lo que queda fueraCopiar enlace

El código de los SDK está fuera de la auditoría audit:safety de Styx (zig-pkg/ es código no de producción para el guard). Auditar las fuentes fijadas de los SDK con el mismo guard es un seguimiento declarado en dec-0121.