Keyboard shortcuts

Press ← or → to navigate between chapters

Press ? to show this help

Press Esc to hide this help

id: ADR-008 title: Anclar el modo de objetivo en el plano de control de tareas duraderas date: 2026-06-25 status: accepted relates-to:

  • https://github.com/zeroclaw-labs/zeroclaw/issues/8303
  • https://github.com/zeroclaw-labs/zeroclaw/issues/7929
  • https://github.com/zeroclaw-labs/zeroclaw/pull/8217
  • crates/zeroclaw-runtime
  • crates/zeroclaw-config
  • crates/zeroclaw-tools

ADR-008: Modo de objetivo de anclaje en el plano de control de tareas duraderas

Contexto

El modo de objetivo cambia una interacción de agente de una única respuesta a trabajo autónomo orientado a un objetivo del usuario. Un objetivo puede persistir más allá del mensaje entrante que lo inició, pausarse mientras espera entrada o una dependencia externa, recuperarse tras el reinicio del daemon y consumir uso del modelo en varias llamadas de trabajador, verificador o delegadas.

Ese tipo de trabajo necesita una autoridad duradera para su ciclo de vida. El sistema debe ser capaz de responder qué trabajo está activo, qué trabajo es elegible para ejecutar otro turno, qué trabajo está en pausa, qué trabajo es terminal y qué actor o ruta tiene permitido reanudarlo o cancelarlo. Una convención de prompts o un registro paralelo haría que esas respuestas dependieran de un estado duplicado.

La contabilidad del presupuesto añade otra restricción sobre la fuente de verdad. Los tokens y el costo son hechos producidos por las llamadas al proveedor de modelos. El presupuesto restante se deriva de un límite y del uso consumido; almacenarlo como su propio contador mutable crearía un segundo sistema de contabilidad.

El modo de objetivos también atraviesa un límite de confianza. Tanto un comando de barra como una solicitud generada por el modelo pueden expresar que se debe iniciar un objetivo, pero ninguno debería poder autorizar por sí mismo datos fiables del entorno de ejecución, como la identidad del llamador, la ruta, el canal o la elegibilidad del agente.

Las principales opciones consideradas fueron el chat multiturn ordinario con orientación mediante prompts, un subsistema de objetivos independiente, o anclar el modo de objetivo en el plano de control de tareas duraderas existente con estado de extensión específico para objetivos.

Decisión

Anclaremos el modo de objetivo en el plano de control de tareas duraderas en lugar de construir un sistema paralelo de tareas de objetivo.

El plano de control de tareas es la fuente de verdad para el ciclo de vida de los objetivos, la propiedad, la ruta, el principal, la relación padre-hijo y la elegibilidad de recuperación. El estado específico del objetivo puede extender los registros de tareas, pero no debe duplicar hechos de ciclo de vida, identidad, ruta, marca de tiempo, entrega o estado terminal que sean propiedad del registro de tareas.

El uso del modelo consumido permanece bajo la titularidad del libro de contabilidad de uso canónico. Los presupuestos de objetivo son límites interpretados contra los registros de uso; el presupuesto restante siempre se deriva, nunca se almacena como un segundo total mutable.

La pausa, reanudación, cancelación, recuperación ante reinicios y la finalización son decisiones de política del plano de control. El texto del prompt puede explicar o solicitar esas transiciones, pero no las autoriza.

Todas las rutas de entrada de objetivos utilizan una única puerta de admisión de confianza en el lado de Rust. El contexto en tiempo de ejecución proporciona hechos de confianza como la superficie, el canal, el principal, la ruta y la elegibilidad del agente; los argumentos suministrados por el modelo no pueden declarar esos hechos.

La finalización de objetivos requiere una decisión de finalización explícita por parte del controlador de objetivos. El silencio, la ausencia de más llamadas a herramientas o un mensaje de asistente con apariencia final no son suficientes para marcar como completado el trabajo autónomo duradero.

Consecuencias

El modo objetivo hereda el ciclo de vida de tareas supervisadas existente en lugar de añadir un segundo registro de tareas. Esto mantiene la recuperación tras reinicios, la cancelación y las futuras mejoras de supervisión vinculadas a un único contrato del plano de control.

El plano de control se hace responsable de distinguir el trabajo de objetivos pausado pero reanudable del trabajo terminal, perdido o que aún está en ejecución. Esto aumenta la importancia de las transiciones precisas de estado de tarea y la política de recuperación ante reinicios.

La aplicación del presupuesto se vuelve auditable porque el uso consumido se deriva de registros de uso canónicos. También significa que el modo de objetivos no puede ser correcto hasta que cada llamada al modelo que pueda gastar contra un objetivo reporte el uso con atribución de objetivos.

La delegación y el trabajo en segundo plano deben respetar los mismos límites de ciclo de vida y de uso. El trabajo que no puede informar de su finalización y uso al objetivo propietario no puede participar de forma segura en el modo objetivo.

Una única puerta de admisión confiable evita que las vías de entrada iniciadas por comandos y modelos se conviertan en sistemas de autorización independientes. El coste es que cada superficie compatible debe encaminar la entrada de objetivos a través de los mecanismos compartidos de comandos/admisión.

Las decisiones detalladas de implementación, incluida la sintaxis de comandos, el inventario de motivos de pausa, las estructuras de las cargas útiles, la configuración del verificador y las etapas de despliegue, se dejan a los planes de implementación y a las PRs de seguimiento. Deben seguir siendo coherentes con los límites de fuente de verdad de este ADR.

Referencias