Arquitectura del núcleo de BeeverForge
Visión general de la arquitectura
El núcleo de BeeverForge toma tickets de un tablero y conduce agentes de programación existentes a través de la planificación, la implementación, la validación, la revisión, el pull request, el merge y la observación del despliegue. Es un orquestador: no contiene un agente de programación propio.
Esta sección describe el núcleo tal como existe en el repositorio en el commit enlazado en las fuentes de cada página. Cuando un registro de diseño describe algo que el código todavía no hace, la página lo indica.
Modelo de control#
El README del proyecto enuncia el modelo como «Las políticas autorizan, las personas evalúan». El manifiesto del proyecto, .beeverforge/project.yaml, declara la política de merge, el piso de calidad y la cadena de promoción. Dentro de esas políticas, la fábrica actúa sin pedir aprobación en cada paso; las personas juzgan el resultado.
- Un proyecto que no declara un control
testno se considera aprobado. Antes de la pasada de implementación, después del dimensionamiento, el ejecutor comprueba el piso y rechaza el job, nombrando el control que falta y cómo declararlo. - La política de merge predeterminada es
human: una persona hace el merge del pull request. El merge automático ocurre solo cuando un proyecto definemerge_policy: autoy se cumplen todas sus condiciones. - La promoción a producción espera una aprobación humana. La aprobación llega al workflow como una respuesta sellada de un solo uso (véase La caja y el piso de calidad).
- Cuando un job no puede continuar, queda en espera en la tarjeta con las opciones que una persona puede tomar, en lugar de esperar en silencio.
Modelo de capas#
El documento de visión del núcleo representa el sistema como aplicaciones sobre una capa de acciones, un núcleo que decide, un motor que lo impulsa y proveedores a los que se llega mediante puertos. Las capacidades se representan como una frontera, no como una capa: el núcleo y el motor llegan a los proveedores mediante el mismo tipo de puerto.
| Capa | Dónde está en el código | Estado |
|---|---|---|
| Aplicaciones | beeverforge/product/, beeverforge/techlead/, beeverforge/api/ | Realizado. El panel, el tech-lead y el rol de producto opcional. |
| Capa de acciones | beeverforge/actions/ | Realizado. Un catálogo a través del cual ejecutan tanto la API del panel como la CLI. |
| Núcleo | beeverforge/contracts/, beeverforge/policy/, beeverforge/lifecycle/ | Realizado en parte. El ciclo de vida de la tarjeta se decide con tablas puras. El kernel de decisión puro para jobs propuesto en ADR-0033 no existe; las transiciones de los jobs todavía se deciden dentro del ejecutor y del workflow. |
| Motor | beeverforge/runtime/temporal/ | Realizado sobre Temporal. El motor no está detrás de un puerto propio. |
| Capacidades y proveedores | beeverforge/adapters/ | Realizado. Cada proveedor lo elige un registro a partir de la configuración. |
El propio documento de fronteras del núcleo describe orchestrator/machine.py como política del núcleo y ejecución del motor que actualmente están fusionadas. La visión de un núcleo que solo decide y un motor que solo ejecuta es la dirección de ADR-0033, que está registrado como propuesto.
Forma de despliegue#
- Las máquinas del propio operador. La instalación predeterminada es
docker composeen una sola máquina y no necesita ninguna cuenta en la nube (ADR-0040). A una nube solo se llega mediante paquetes complementarios. - Servicios. El archivo compose ejecuta una base de datos Postgres para el motor, un servidor Temporal, la interfaz web de Temporal, el worker y el panel. Los puertos publicados se vinculan a
127.0.0.1de forma predeterminada. - El motor. Temporal guarda el estado de los jobs. Cada job es un workflow durable: sus esperas y temporizadores sobreviven a un reinicio del worker, y un job cuyo worker se pierde durante la pasada del agente queda en espera para que una persona lo reanude u omita.
- La caja. El worker ejecuta cada job en una caja. El tipo predeterminado es
container: un contenedor Docker desechable que se lanza como hermano en el daemon del host, a través del socket de Docker que el archivo compose monta en el worker. - Un solo inquilino, varios proyectos. Una instalación sirve a un equipo con un registro de proyectos. El registro contiene cualquier cantidad de proyectos, cada uno con su propio repositorio, tablero y manifiesto (ADR-0001, D-14).
- Un job a la vez de forma predeterminada. La cantidad de jobs en curso es
BEEVERFORGE_MAX_CONCURRENT_JOBS, con valor predeterminado1.
127.0.0.1; la red de la caja se describe en La caja y el piso de calidad.El worker tiene el socket de Docker del host, lo que le da control del daemon de Docker del host. La caja predeterminada tiene acceso completo a la red saliente. Ambas cosas se describen con sus límites en La caja y el piso de calidad.
Fuera del núcleo#
- Los agentes de programación. El núcleo conduce herramientas de línea de comandos de agentes existentes a través de un único contrato de adaptador. Los tipos de harness del árbol son
claude_code(el predeterminado),codex,kimiyopencode. Cada uno llama al servicio de su fabricante; ese endpoint es un destino de red que toda instalación necesita. - Canales de chat. El núcleo está completo sin un conector de chat (ADR-0038). El único canal y notificador del árbol es el panel. Los adaptadores de Slack y Telegram se distribuyen en un paquete complementario aparte y se registran mediante el mismo mecanismo de extensión que cualquier otro adaptador.
- Ejecutores y almacenes en la nube. El núcleo no incluye ningún ejecutor de cajas remotas. El ejecutor de tareas remotas, la tabla de métricas en la nube, el almacén de sesiones remoto y el pool de tokens en la nube están declarados como tipos de complementos.