type: arquitectura status: aceptado last-reviewed: 2026-08-20 relates-to:
- docs/book/src/foundations/fnd-002-documentation-standards.md
Registros de decisiones de arquitectura
Los Registros de Decisión de Arquitectura (ADRs) son el registro duradero de las decisiones de arquitectura que condicionan el trabajo futuro de ZeroClaw. Son más breves que los RFC: cada uno registra el contexto, la decisión, las consecuencias y las fuentes que justifican la decisión.
Los ADR aceptados son inmutables. Si la arquitectura cambia, escribe un nuevo ADR y marca el anterior como reemplazado en lugar de reescribir la historia.
ADRs actuales
| ADR | Estado | Decisión |
|---|---|---|
| ADR-001 | aceptado | ZeroClaw’s runtime and first-party crates are implemented in Rust. |
| ADR-002 | aceptado | Las superficies de extensiones de primera parte usan contratos de rasgo explícitos. |
| ADR-003 | sustituido por ADR-009 | Los plugins de WASM usaban inicialmente Extism como puente de ejecución. |
| ADR-004 | aceptado | El estado compartido mantenido por la herramienta sigue las reglas de identidad, propiedad del handle, aislamiento y recarga propiedad del daemon. |
| ADR-005 | aceptado | El almacenamiento en memoria utiliza un contrato independiente del backend con SQLite como opción predeterminada. |
| ADR-006 | propuesto | Los plugins en tiempo de ejecución son el objetivo de los canales opcionales, con excepciones nativas explícitas basadas en capacidades durante la migración. |
| ADR-007 | propuesto | La puerta de enlace se convierte en un proceso opcional independiente sobre un contrato IPC local compatible. |
| ADR-008 | aceptado | El modo objetivo usa el plano de control de tareas duraderas y el libro de uso canónico. |
| ADR-009 | aceptado | Los componentes WIT y wasmtime directo reemplazan el puente de plugins de Extism. |
| ADR-010 | propuesto | El historial de sesión, la memoria seleccionada y el enriquecimiento tienen límites de autoridad separados. |
| ADR-011 | aceptado | Los agentes configurados tienen límites de tiempo de ejecución explícitos bajo un único demonio. |
| ADR-012 | propuesto | La aplicación de configuración en tiempo real utiliza generaciones canónicas y resultados específicos del destino. |
| ADR-013 | propuesto | La adquisición de la clave maestra utiliza una única autoridad de origen de claves configurada. |
| ADR-014 | propuesto | El acceso de red de los plugins está gestionado por una única autoridad de salida (egress) controlada por el host. |
| ADR-015 | propuesto | El catálogo unificado de capacidades es una proyección de solo lectura sobre los propietarios de paquetes, capacidades, implementaciones, configuración y tiempo de ejecución. |
| ADR-016 | propuesto | La extracción es el comportamiento predeterminado para los subsistemas del crate de tipo holding; las excepciones acotadas se registran, se delimitan y las concede el Core Team. |
| ADR-017 | propuesto | La autenticación entrante resuelve las credenciales en principales canónicos y concesiones de perfiles de permisos antes de que actúen las superficies de ejecución privilegiadas. |
| ADR-018 | propuesto | Las funciones de seguridad y procedencia en tiempo de ejecución utilizan límites de decisión propios del runtime para las acciones protegidas, la admisión de modelos, los turnos internos y la evidencia canónica. |
ADR-006 y ADR-007 son decisiones de hoja de ruta condicionadas a la implementación de FND-002. Sus direcciones objetivo están registradas, pero permanecen en estado propuesto hasta que los límites de aceptación definidos en cada registro sean entregados.
ADR-010 sigue en estado propuesto hasta que se cumplan las condiciones de aceptación indicadas en el registro.
ADR-012 permanece propuesto hasta que la publicación de la configuración canónica, los resultados con alcance de generación y los consumidores acotados de aplicación en vivo de seguridad y de canal cumplan los criterios de aceptación del registro.
ADR-013 sigue en estado propuesto hasta que el límite canónico de la fuente de claves, la compatibilidad segura con archivos, la selección configurada con cierre ante fallos y una fuente no basada en archivos compatible cumplan los criterios de aceptación del registro.
ADR-014 permanece en estado propuesto hasta que el límite de transporte de plugins aplicado, la declaración del manifiesto cubierta por firma, la ceremonia de concesión por parte del operador y el despliegue en la flota cumplan los criterios de aceptación definidos en el registro.
ADR-015 permanece propuesto hasta que las proyecciones de catálogos unificados preserven la evidencia de la fuente de verdad, la procedencia de los artefactos, los puentes de compatibilidad y la regla de que la visibilidad no puede otorgar autoridad de invocación.
ADR-016 sigue en estado propuesto hasta que el contrato de holding-crate establezca la regla de excepción y contenga una tabla de excepciones activas, y al menos una excepción haya sido concedida o denegada mediante el proceso.
ADR-017 permanece como propuesto hasta que la resolución canónica de identidad y concesiones, la compatibilidad nativa y de credenciales de par, la aplicación de RPC/WSS, la integración con OIDC y gateway, el almacenamiento de sesiones y memoria privada propiedad del principal, la documentación de migración/recuperación y las reglas de propiedad de origen interno cumplan los criterios de aceptación del registro.
ADR-018 permanece como “propuesto” hasta que la canalización de acciones en tiempo de ejecución, el sobre de ingreso/procedencia, la vinculación de conversaciones con principales internos, la procedencia de las respuestas de pares, los resultados separados, la ruta de auditoría duradera y los mecanismos de control de la implementación cumplan los criterios de aceptación definidos en el registro.