Keyboard shortcuts

Press ← or → to navigate between chapters

Press ? to show this help

Press Esc to hide this help

SOP Fan-In: Cron

Conectado. Los activadores de cron se distribuyen mediante el ciclo periódico de mantenimiento de SOP, por lo que esto es un mecanismo de sondeo, no un temporizador para cada programación. Para que se activen se necesita ese ciclo, que inicia un zeroclaw daemon o el supervisor zeroclaw channel start (compilado con la funcionalidad agent-runtime, con sop.sops_dir establecido en un valor no vacío (no establecido de forma predeterminada, lo que mantiene desactivado el tiempo de ejecución de SOP; el valor documentado es shared/sops), y sop.maintenance_interval_secs distinto de cero, cuyo valor predeterminado es 60). El zeroclaw gateway start independiente no inicia el ciclo de mantenimiento, por lo que no activa los activadores de cron; una puerta de enlace alojada dentro del demonio sí lo hace, porque el demonio inicia el ciclo. Las programaciones se analizan una sola vez al iniciarse, por lo que un SOP añadido mientras el demonio está en ejecución necesita una recarga antes de que su activador de cron surta efecto.

Un desencadenador cron se activa en una ventana de tiempo descrita por una expresión cron. Las expresiones inválidas fallan de forma cerrada durante el análisis y la compilación de la caché.

Activador

Disparo basado en tiempo. En vivo: enviado por el tick de mantenimiento SOP (rutas daemon / channel-start).

campotipopredeterminadosignificado
expression*cadena—Expresión cron evaluada sobre la ventana de ejecución.

Cargar y verificar el SOP:

Definir

Autorice el SOP como se describe en Syntax, con un desencadenador cron. Los campos del desencadenador de arriba son las claves compatibles; la página recorre el archivo completo.

Validar

zeroclaw sop validate

Inspeccionar

zeroclaw sop list
zeroclaw sop show <name>

Ejecución

Una ejecución iniciada por cron se lleva a término sin un bucle de agente adjunto. El tick de mantenimiento entrega cada ExecuteStep iniciado al controlador de ejecución sin interfaz (headless), que ejecuta el cuerpo del paso como un turno de agente y avanza la ejecución; las acciones DeterministicStep se enrutan en su lugar a través del controlador determinista del motor. Una ejecución que llega a una puerta de aprobación o a un punto de control se detiene allí, exactamente como lo haría bajo un agente en vivo.

Dos restricciones se aplican al turno de paso, ambas de cierre por fallo (fail-closed):

  • El SOP debe indicar su agente propietario, y ese agente debe estar habilitado. Establezca agent en SOP.toml (o agent en un paso individual, que tiene prioridad sobre el valor general) con el alias de un agente configurado. Una ejecución por cron no tiene un turno de agente ambiental del que heredar una identidad, así que un procedimiento sin propietario se rechaza en el momento de su creación, y el driver se niega a ejecutar el paso en lugar de ejecutarlo como otro agente configurado. Un alias que no esté configurado, o que esté configurado con enabled = false, se rechaza de la misma manera: deshabilitar un agente lo retira también del trabajo desatendido. El paso se ejecuta con el proveedor, el espacio de trabajo, las herramientas y el perfil de riesgo de ese agente.
  • La restricción de herramientas del paso se aplica también en las ejecuciones secundarias. Las herramientas de control de SOP (sop_execute, sop_advance, sop_approve) siempre se eliminan de un turno del paso, de modo que una ejecución automática no puede dirigirse a sí misma. Cuando sop.step_scope_enforce está definido, el scope declarado del paso reduce aún más la superficie disponible. Un agente secundario que el paso genera hereda las mismas exclusiones, por lo que generar uno no es una forma de eludir el límite del paso.

Los drivers de cron en curso pertenecen a la generación del daemon que los inició. Al recargar, el daemon detiene el tick de mantenimiento, permite que los drivers en ejecución terminen con la configuración con la que se iniciaron (hasta 30 segundos), luego aborta los rezagados y espera hasta 5 segundos adicionales a que se detengan, de modo que, en el caso habitual, ningún paso abarca dos configuraciones.

La cancelación es cooperativa: una tarea se detiene en su siguiente await, y una que no llegue a ninguno dentro de ese período de gracia sigue ejecutándose. La recarga no espera a que termine: la siguiente generación arranca junto a ella, y el driver sigue usando la configuración y el motor anteriores hasta que cede el control. Un driver así se registra (still_running) y se transfiere a la siguiente generación en lugar de desvincularse, de modo que permanece rastreado y se vuelve a comprobar en cada recarga hasta que termina. Las entradas still_running repetidas indican que un paso está bloqueando sin ceder el control.

Ver también