Orquestación de ejecución Argus

¿Qué hace Orquestación de ejecución Argus?

Úselo cuando una tarea se beneficie de estado duradero, artefactos, experimentos, ejecución en segundo plano, revisión independiente, pausa/reanudación o continuación más allá de un turno de modelo. No lo use para una respuesta rápida, inspección simple de solo lectura o una operación pequeña que el host actual pueda finalizar y verificar directamente de manera segura.

Limitaciones conocidas

• Argus no proporciona un push/callback universalmente portátil desde Necesita de ti hacia cada operador externo. El operador externo debe inspeccionar activamente el estado/salida compacto de Argus en límites significativos. La detección de intervención puede no ser en tiempo real cuando el host no puede mantener una monitorización duradera, y esta habilidad prohíbe afirmar supervisión desatendida en ese caso.
• Los adaptadores del Agente Hermes y Claude Code están actualmente validados por documentación, no probados mediante ejecución local en este host.
• Algunos comandos de la habilidad Copilot CLI en la documentación actual están ausentes en la compilación 1.0.39 probada localmente, por lo que se requiere detección de características.

Modelo operativo de dos partes y configuración

Hay exactamente dos partes operativas:

1. El operador externo: OpenClaw, Hermes Agent, Claude Code, Codex CLI, Copilot CLI u otro agente con capacidad de shell que siga esta habilidad. Prepara la misión, lanza y observa Argus, maneja las preguntas del operador dentro de la autoridad delegada, verifica artefactos e informa de forma compacta.
2. Argus: el sistema supervisado duradero que planifica, ejecuta, revisa, persiste estado, plantea preguntas y produce evidencia y artefactos.

Cualquier modelo/CLI de proveedor que Argus use internamente, como codex, copilot, claude, pi, opencode o grok, es configuración de Argus y un detalle de implementación, no un tercer rol, actor par o parte separada en este procedimiento. El operador externo puede seleccionar o verificar el modelo/proveedor interno configurado de Argus durante la preparación cuando sea operativamente necesario y esté autorizado; de lo contrario, trata a Argus como un sistema supervisado duradero. No infiera la configuración de Argus a partir de la identidad del operador externo, incluso cuando los nombres coincidan.

Resuelva el ejecutable explícitamente; no asuma una ruta de instalación universal. Shell POSIX:

if [ -n "${ARGUS_BIN:-}" ]; then
  : # el operador proporcionó una ruta de ejecutable
elif command -v argus >/dev/null 2>&1; then
  ARGUS_BIN="$(command -v argus)"
elif [ -n "${ARGUS_INSTALL:-}" ]; then
  ARGUS_BIN="$ARGUS_INSTALL/.venv/bin/argus"
else
  echo "Establezca ARGUS_BIN o ARGUS_INSTALL" >&2; exit 2
fi

PowerShell nativo:

if ($env:ARGUS_BIN) {
  $ArgusBin = $env:ARGUS_BIN
} elseif (Get-Command argus -ErrorAction SilentlyContinue) {
  $ArgusBin = (Get-Command argus).Source
} elseif ($env:ARGUS_INSTALL) {
  $ArgusBin = Join-Path $env:ARGUS_INSTALL ".venv\Scripts\argus.exe"
} else {
  throw "Establezca ARGUS_BIN o ARGUS_INSTALL"
}

Los ejemplos de comandos a continuación usan la sintaxis POSIX "$ARGUS_BIN" .... En PowerShell, invoque la ruta resuelta como & $ArgusBin ....

Para un checkout de código fuente, ARGUS_INSTALL="$HOME/src/Argus" es solo un ejemplo, no un valor predeterminado portátil. Registre la ruta absoluta del ejecutable resuelto. Nunca descargue, reinstale, altere la configuración interna del modelo/proveedor de Argus ni amplíe permisos en silencio.

Procedimiento operativo central

1. Elija un directorio de trabajo propio y una frontera de seguridad real. Use un directorio absoluto dedicado por proyecto Argus. Nunca superponga la jerarquía de directorios de otro proyecto Argus activo. No mueva, elimine ni comparta escritura mientras su demonio esté activo. El trabajo paralelo real obtiene proyectos separados. El directorio de trabajo es un límite de propiedad, no una caja de arena. ARGUS_SKILL_SAFE_MODE=1 añade protecciones pero no es en sí mismo aislamiento para cada backend. Antes de preparar entradas sensibles, requiera una caja de arena verificada para el backend seleccionado o ejecute Argus en un límite de SO/contenedor apropiadamente aislado. El modo desatendido predeterminado puede conceder acceso a agentes internos más allá del directorio de trabajo.
2. Prepare entradas acotadas. Copie solo las entradas relevantes para la tarea y seguras de divulgación en inputs/. Escriba OBJECTIVE.md con el resultado, no objetivos, rutas de salida, criterios de aceptación, límites de autoridad y requisitos de revisión/citas. No prepare historial de conversación ambiental, credenciales ni datos privados no relacionados.
3. Prepare desde el directorio de trabajo exacto. Ejecute "$ARGUS_BIN" doctor, luego pruebe "$ARGUS_BIN" --status. Use doctor --deep solo cuando deba verificarse la autenticación del backend; no añada esa latencia de red/auth a cada preparación rutinaria. Deep Doctor no es una prueba universal de autenticación viva: cuando informa de un token no verificado, capacidad fuera de línea o ruta inalcanzable, use la sonda de preparación viva no mutante documentada de ese backend antes del envío. Continúe solo si las comprobaciones requeridas pasan, el proyecto/directorio de trabajo previsto está identificado, no existe conflicto de propiedad y cualquier elección de modelo/proveedor interno requerida operativamente está instalada y autenticada. El operador externo puede seleccionar o verificar esa configuración de Argus aquí cuando esté autorizado, pero no debe tratarla como otra parte operativa. La ayuda de nivel superior actual de Argus es intencionalmente escueta y puede omitir banderas de automatización compatibles; antes de usar --notify, daemon, acotado o superficies API contra otra compilación, verifíquelas desde los documentos/parseador de esa compilación o mediante una sonda segura. Consulte references/argus-runtime-surfaces.md.
4. Mantenga la configuración de ejecución interna explícita solo cuando sea necesario. Prefiera el modelo/proveedor interno ya configurado, instalado y autenticado de Argus. Califique los nombres de proveedores donde Argus lo requiera. No cambie silenciosamente la configuración después de una comprobación de preparación fallida; diagnostique primero y obtenga aprobación cuando el cambio exceda la autoridad delegada.
5. Despache una misión independiente. Desde el directorio de trabajo, proporcione a Argus un objetivo autocontenido que nombre las entradas y salidas preparadas. Solicite inspeccionar → ejecutar → validar → reparar → cierre de artefacto final. Delegue en la política nativa de revisión de riesgo/Vertical de Argus; solicite revisión independiente explícitamente solo cuando el contrato de la tarea o el riesgo material lo requieran. Mantenga un entregable acotado por misión. Para una misión acotada única donde no se solicite aprendizaje reutilizable y la política de implementación lo permita, establezca ARGUS_SKILL_REQUIRE_POST_TASK_LEARNING=0 para evitar la llamada de modelo de aprendizaje posterior a la tarea predeterminada; de lo contrario, conserve la política de aprendizaje configurada. Use la cabina interactiva cuando esté disponible; para ejecución desacoplada, use las superficies de demonio/acotado documentadas de Argus en lugar de un bucle de shell improvisado.
6. Preserve los límites de evidencia dentro de Argus. Argus puede separar la planificación, la ingeniería y la revisión internamente. Requiera misiones de tamaño de decisión y cambios de artefactos con evidencia. Cuando la política de Argus requiera revisión independiente, debe inspeccionar los artefactos reales, límites, citas y finalización. Estas son responsabilidades internas, no partes adicionales en el modelo operativo externo. Prefiera una comprobación decisiva por afirmación; evite evidencia duplicada ceremonial o turnos de modelo adicionales.
7. Monitoree usando la capacidad de host más fuerte disponible. Siga el adaptador seleccionado en references/adapters/. Las APIs de proceso/fondo del host mejoran la observación pero no son la fuente de verdad: el estado del proyecto duradero de Argus lo es. Use el demonio desacoplado de Argus solo donde el entorno activo conserve los procesos del host. De lo contrario, guarde la identidad exacta del proyecto/directorio de trabajo y reinicie Argus contra ese estado en un turno posterior. Si no se permite el lanzamiento desacoplado, mantenga una cabina en primer plano o pida al usuario que la deje ejecutándose; nunca afirme monitorización desatendida.
8. Ejecute el bucle de preguntas pendientes en cada límite. Inspeccione "$ARGUS_BIN" --status al despachar, en cada comprobación de estado significativa, después de resultados bloqueados/pausados/replanificados, antes de dejar una ejecución desatendida, después de responder y antes del cierre. esperándole : N pregunta(s) sin respuesta es una señal de parada. Cuando esté disponible, inspeccione también el mensaje Necesita de ti de la cabina/interfaz Web. En la compilación validada Argus 0.1.1, los operadores con capacidad de API pueden inspeccionar GET /api/projects/{sid}/status o GET /api/projects/{sid}/snapshot?compact=true; ambos exponen pending_questions, mientras que las instantáneas completas exponen filas en backlog. Estas rutas de lectura pueden permanecer no autenticadas incluso cuando ARGUS_SKILL_WEB_TOKEN está configurado: manténgalas solo en bucle local, o colóquelas detrás de una VPN de confianza/proxy inverso autenticador; nunca las exponga directamente a una red no confiable. Detecte características de estas rutas en otras compilaciones. La prosa de progreso por sí sola no es suficiente.
9. Clasifique cada pregunta. Un marcador duradero no resuelto es una fila de backlog con pending_question no vacío; una tarjeta tipada también tiene operator_decision.status == "pending", además de id, question, reason, evidence y options opcionales. Esto no es una pregunta de chat informativa, texto de objetivo, prosa de revisión o /ask ordinario. Trate el marcador duradero como bloqueante incluso junto a texto de failed, paused_operator o de apariencia exitosa. Permita que Argus retenga el enrutamiento técnico reversible a menos que una pregunta planteada caiga claramente dentro de la autoridad delegada. Escale credenciales/secretos, gastos, eliminación/force-push/publicación/envíos externos, acciones irreversibles o hacia afuera, cambios de seguridad/límite de confianza, decisiones legales/de licencia, cambios materiales de alcance/aceptación y opciones ambiguas de alto impacto.
10. Responda a través de una superficie autoritativa. Prefiera la tarjeta Necesita de ti específica del elemento en la cabina de terminal/Web. En la compilación validada Argus 0.1.1, los clientes API pueden usar POST /api/projects/{sid}/decisions/{decision_id}/resolve con {"option_id":"…","note":"…"}, o el heredado POST /api/projects/{sid}/backlog/{item_id}/answer con {"text":"…"}. Una respuesta normal de cabina o POST /api/projects/{sid}/message es enrutada por Manager solo cuando exactamente una pregunta está pendiente; cuando hay varias, diríjase a la tarjeta/elemento específico. "$ARGUS_BIN" --notify '<respuesta>' encola orientación y puede ser vinculado por Manager solo cuando exactamente una pregunta está pendiente; el acuse de recibo de la cola no es resolución. Detecte características de rutas que no son de cabina en otras compilaciones. Nunca adivine en nombre del usuario.
11. Verifique la grabación, luego reanude. En la compilación validada, exija resolved: true donde la superficie lo devuelva. Confirme que el antiguo pending_question se ha borrado y se ha grabado una resolución. Cuando exista una tarjeta de decisión tipada, exija también que esa tarjeta se vuelva resolved; las preguntas heredadas sin tipo pueden no tener tarjeta o resolution_id. Observe la continuación en su estado real pendiente, ejecutándose, completado o detenido, en lugar de exigir que todavía esté activa en el momento de la inspección. Una decisión stop en su lugar aborta el elemento, preserva el trabajo, deshabilita el modo continuo y no crea continuación. Vuelva a ejecutar el estado y verifique que la ejecución se reanudó, completó o detuvo según lo previsto. Si el marcador permanece, aclare o escale; no envíe conjeturas duplicadas.
12. Inspeccione sin importar la trayectoria. Use estado/cabina para misión actual, rol, etapa, backlog, resultado, última posición verificada y Necesita de ti. Trate el backlog más la última evidencia verificada como la frontera. Mantenga transcripciones sin procesar, registros de demonio, E/S de agente, registros de uso y libros de contabilidad privados localmente.
13. Recupere y verifique artefactos. Lea las rutas de salida nombradas. Verifique la existencia, el alcance solicitado y las pruebas decisivas. Resuelva cada cita material a la fuente preparada; rechace citas fabricadas, desactualizadas o que no coincidan con la afirmación. Nunca infiera éxito a partir de un mensaje de progreso.
14. Recupérese desde el estado duradero. Reanude el trabajo de escritura/ejecución pausado pidiendo a Argus que reanude desde el estado duradero con un objetivo de reanudación autocontenido, no una respuesta de chat en línea. Si un hilo de ejecución interno no puede reanudarse, use puntos de verificación/cápsulas de Argus. Diagnostique preguntas no resueltas, propiedad, preparación del modelo/proveedor interno, presupuesto/enfriamiento e infraestructura antes de cambiar la configuración u objetivo de Argus.
15. Cierre solo con evidencia. Finalice cuando se cumpla el objetivo acotado, los artefactos y las comprobaciones decisivas pasen, el veredicto del Revisor requerido sea done, y no quede ninguna pregunta/tarjeta pendiente. continue, replan_requested, blocked, pausa de investigación o Necesita de ti sin respuesta no es finalización. Distinga la finalización de la misión de la finalización del proyecto/etapa. Use references/closeout-checklist.md.

Reservas de capacidad

• Sin descubrimiento nativo de habilidades: proporcione el paquete completo o indique explícitamente al host que lea este archivo y el adaptador correspondiente; no afirme activación automática.
• Sin shell: el host no puede operar directamente Argus localmente. Use una integración remota aprobada de shell/terminal o entregue pasos exactos del operador; marque la ejecución como bloqueada en lugar de simularla.
• Shell pero sin API de procesos: prefiera --daemon de Argus solo cuando el entorno conserve procesos; siempre persista la identidad del proyecto/directorio de trabajo y vuelva a entrar con estado/cabina. No ejecute en segundo plano con frágiles &, nohup o bucles de sleep/poll a menos que el entorno documentado del host lo convierta en la única ruta aprobada.
• API de procesos pero no duradera entre sesiones de host: úsela solo para registros en vivo; el estado del proyecto duradero de Argus sigue siendo el ancla de recuperación, y es posible que sea necesario reiniciar el demonio.
• Sin cliente HTTP/API: use cabina de terminal/Web y --status. Nunca requiera acceso API para el bucle de preguntas.
• Sin ruta de aprobación interactiva: cierre con fallo en acciones con compuerta de aprobación. Separe la preparación segura del lanzamiento mutante, o pida al humano que apruebe a través de la interfaz de usuario compatible de ese host. Nunca omita las banderas de aprobación/caja de arena simplemente para ejecutar desatendido.
• Sin ejecución desatendida permitida: mantenga una sesión interactiva abierta o deténgase con una instrucción de reanudación precisa y estado no resuelto. Informe la monitorización como condicional, no activa.

Privacidad, autoridad y retorno

Prepare datos mínimos. Mantenga la interfaz Web solo en bucle local a menos que el usuario apruebe acceso remoto protegido. Las instrucciones actuales del usuario y la evidencia fresca anulan planes anteriores o sugerencias de tiempo de ejecución.

Devuelva solo a la superficie invocante: identidad del proyecto/directorio de trabajo, resultado/frontera compacto, veredicto del Revisor, rutas de artefactos, validación decisiva, excepciones de citas.