Orchestration d'exécution Argus

Que fait Orchestration d'exécution Argus ?

À utiliser lorsqu'une tâche bénéficie d'un état durable, d'artefacts, d'expériences, d'une exécution en arrière-plan, d'une révision indépendante, d'une pause/reprise ou d'une continuation au-delà d'un seul tour de modèle. Ne pas utiliser pour une réponse rapide, une simple inspection en lecture seule ou une petite opération que l'hôte actuel peut terminer et vérifier directement en toute sécurité.

Limitations connues

• Argus ne fournit pas de push/callback universellement portable de Besoins de l'opérateur (Needs you) vers chaque opérateur externe. L'opérateur externe doit inspecter activement l'état/la sortie compacte d'Argus à des limites significatives. La détection d'intervention peut ne pas être en temps réel lorsque l'hôte ne peut pas maintenir une surveillance durable, et cette compétence interdit de revendiquer une supervision sans surveillance dans ce cas.
• Les adaptateurs pour l'agent Hermes et Claude Code sont actuellement validés par la documentation plutôt que testés par exécution locale sur cet hôte.
• Certaines commandes de compétence Copilot CLI dans la documentation actuelle sont absentes de la version 1.0.39 testée localement, une détection de fonctionnalités est donc requise.

Modèle d'exploitation à deux parties et configuration

Il existe exactement deux parties opérationnelles :

1. L'opérateur externe : OpenClaw, agent Hermes, Claude Code, Codex CLI, Copilot CLI, ou tout autre agent capable d'utiliser un shell et suivant cette compétence. Il prépare la mission, lance et observe Argus, traite les questions de l'opérateur dans les limites de l'autorité déléguée, vérifie les artefacts et rend compte de manière concise.
2. Argus : le système supervisé durable qui planifie, exécute, révise, persiste l'état, pose des questions et produit des preuves et des artefacts.

Toute interface CLI de modèle/fournisseur qu'Argus utilise en interne—telle que codex, copilot, claude, pi, opencode ou grok—est une configuration d'Argus et un détail d'implémentation, et non un troisième rôle, un acteur pair ou une partie distincte dans cette procédure. L'opérateur externe peut sélectionner ou vérifier le modèle/fournisseur interne configuré d'Argus pendant le prévol lorsque cela est nécessaire sur le plan opérationnel et autorisé ; sinon, il traite Argus comme un seul système supervisé durable. Ne déduisez pas la configuration d'Argus de l'identité de l'opérateur externe, même si les noms correspondent par hasard.

Résolvez l'exécutable de manière explicite ; ne supposez pas un chemin d'installation universel. Shell POSIX :

if [ -n "${ARGUS_BIN:-}" ]; then
  : # opérateur a fourni un chemin d'exécutable
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 "Définissez ARGUS_BIN ou ARGUS_INSTALL" >&2; exit 2
fi

PowerShell natif :

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 "Définissez ARGUS_BIN ou ARGUS_INSTALL"
}

Les exemples de commandes ci-dessous utilisent la syntaxe POSIX "$ARGUS_BIN" .... Dans PowerShell, invoquez le chemin résolu avec & $ArgusBin ....

Pour un checkout de sources, ARGUS_INSTALL="$HOME/src/Argus" est un exemple uniquement, pas une valeur par défaut portable. Enregistrez le chemin absolu de l'exécutable résolu. Ne téléchargez, ne réinstallez, ne modifiez jamais la configuration du modèle/fournisseur interne d'Argus et n'élargissez pas les autorisations silencieusement.

Procédure opérationnelle de base

1. Choisissez un répertoire de travail dédié et une limite de sécurité réelle. Utilisez un répertoire absolu dédié par projet Argus. Ne chevauchez jamais la hiérarchie de répertoires d'un autre projet Argus actif. Ne déplacez, ne supprimez et n'écrivez pas en partage sur ce répertoire pendant que son démon est actif. Le travail parallèle réel obtient des projets séparés. Le répertoire de travail est une limite de propriété, pas un bac à sable. ARGUS_SKILL_SAFE_MODE=1 ajoute des garde-fous mais ne constitue pas en soi un isolement pour chaque backend. Avant de préparer des entrées sensibles, exigez un sandboxing vérifié pour le backend sélectionné ou exécutez Argus dans une limite OS/conteneur appropriée et isolée. Le mode sans surveillance par défaut peut accorder aux agents internes un accès au-delà du répertoire de travail.
2. Préparez des entrées limitées. Copiez uniquement les entrées pertinentes pour la tâche et sans risque de divulgation dans inputs/. Rédigez OBJECTIVE.md avec le résultat attendu, les objectifs non visés, les chemins de sortie, les critères d'acceptation, les limites d'autorité et les exigences de révision/de citation. Ne préparez pas l'historique de la conversation ambiante, les identifiants ou les données privées non liées.
3. Effectuez un prévol depuis le répertoire de travail exact. Exécutez "$ARGUS_BIN" doctor, puis sondez "$ARGUS_BIN" --status. Utilisez doctor --deep uniquement lorsque l'authentification du backend doit être vérifiée ; n'ajoutez pas cette latence réseau/d'authentification à chaque prévol de routine. Deep Doctor n'est pas une preuve universelle d'authentification en direct : lorsqu'il signale un jeton non vérifié, une capacité hors ligne ou une route inaccessible, utilisez la sonde de disponibilité en direct non modificatrice documentée de ce backend avant l'envoi. Continuez uniquement si les vérifications requises sont passées, le projet/répertoire de travail prévu est identifié, aucun conflit de propriété n'existe, et tout choix de modèle/fournisseur interne nécessaire sur le plan opérationnel est installé et authentifié. L'opérateur externe peut sélectionner ou vérifier cette configuration d'Argus ici lorsqu'il est autorisé, mais ne doit pas la traiter comme une autre partie opérationnelle. L'aide de niveau supérieur actuelle d'Argus est intentionnellement laconique et peut omettre les indicateurs d'automatisation pris en charge ; avant d'utiliser --notify, daemon, bounded, ou des surfaces API avec une autre version, vérifiez-les à partir de la documentation/analyseur de cette version ou d'une sonde sûre. Voir references/argus-runtime-surfaces.md.
4. Gardez la configuration d'exécution interne explicite uniquement lorsque nécessaire. Préférez le modèle/fournisseur interne déjà configuré, installé et authentifié d'Argus. Qualifiez les noms de fournisseurs là où Argus l'exige. Ne modifiez pas silencieusement la configuration après un échec de vérification de disponibilité ; diagnostiquez d'abord et obtenez l'approbation lorsque la modification dépasse l'autorité déléguée.
5. Envoyez une mission autonome. Depuis le répertoire de travail, donnez à Argus un objectif autonome nommant les entrées et sorties préparées. Demandez une clôture inspecter → exécuter → valider → réparer → artefact final. Déléguez à la politique de révision native des risques/verticale d'Argus ; exigez explicitement une révision indépendante uniquement lorsque le contrat de la tâche ou le risque matériel l'exige. Gardez un livrable limité par mission. Pour une mission unique et limitée où l'apprentissage réutilisable n'est pas demandé et que la politique de déploiement le permet, définissez ARGUS_SKILL_REQUIRE_POST_TASK_LEARNING=0 pour éviter l'appel de modèle d'apprentissage post-tâche par défaut ; sinon, préservez la politique d'apprentissage configurée. Utilisez le cockpit interactif lorsqu'il est disponible ; pour une exécution détachée, utilisez les surfaces daemon/bounded documentées d'Argus plutôt qu'une boucle shell improvisée.
6. Préservez les limites de preuves à l'intérieur d'Argus. Argus peut séparer la planification, l'ingénierie et la révision en interne. Exigez des missions de taille décisionnelle et des modifications d'artefacts avec des preuves. Lorsque la politique d'Argus exige une révision indépendante, elle doit inspecter les artefacts réels, les limites, les citations et l'achèvement. Ce sont des responsabilités internes, pas des parties supplémentaires dans le modèle d'exploitation externe. Préférez une vérification décisive par affirmation ; évitez les preuves redondantes cérémonielles ou les tours de modèle supplémentaires.
7. Surveillez en utilisant la capacité hôte la plus puissante disponible. Suivez l'adaptateur sélectionné dans references/adapters/. Les API de processus/arrière-plan de l'hôte améliorent l'observation mais ne sont pas la source de vérité : l'état durable du projet Argus l'est. Utilisez le démon détaché d'Argus uniquement là où l'environnement actif préserve les processus hôtes. Sinon, sauvegardez l'identité exacte du répertoire de travail/projet et relancez Argus avec cet état lors d'un tour ultérieur. Si aucun lancement détaché n'est autorisé, gardez un cockpit en premier plan ou demandez à l'utilisateur de le laisser fonctionner ; ne revendiquez jamais une surveillance sans surveillance.
8. Exécutez la boucle de questions en attente à chaque limite. Inspectez "$ARGUS_BIN" --status lors de l'envoi, de chaque vérification d'état significative, après les résultats bloqués/en pause/replanifiés, avant de laisser une exécution sans surveillance, après avoir répondu et avant la clôture. en attente de vous : N question(s) sans réponse est un signal d'arrêt. Lorsqu'il est disponible, inspectez également l'invite Besoins de l'opérateur (Needs you) du cockpit/interface Web. Sur la version validée d'Argus 0.1.1, les opérateurs capables d'API peuvent inspecter GET /api/projects/{sid}/status ou GET /api/projects/{sid}/snapshot?compact=true ; les deux exposent pending_questions, tandis que les instantanés complets exposent des lignes dans backlog. Ces routes de lecture peuvent rester non authentifiées même lorsque ARGUS_SKILL_WEB_TOKEN est configuré : gardez-les en boucle locale uniquement, ou placez-les derrière un VPN de confiance/proxy inverse d'authentification ; ne les exposez jamais directement à un réseau non fiable. Détectez ces routes sur d'autres versions. Les seuls textes de progression sont insuffisants.
9. Classez chaque question. Un marqueur durable non résolu est une ligne de backlog avec pending_question non vide ; une carte typée a également operator_decision.status == "pending", plus id, question, reason, evidence, et des options facultatives. Ce n'est pas une question de chat informative, un texte d'objectif, une prose de révision ou un /ask ordinaire. Traitez le marqueur durable comme bloquant même à côté d'un texte failed, paused_operator, ou d'un texte à succès apparent. Laissez Argus conserver un routage technique réversible à moins qu'une question posée ne relève clairement de l'autorité déléguée. Escaladez les identifiants/secrets, les dépenses, la suppression/force-push/publication/envois externes, les actions irréversibles ou tournées vers l'extérieur, les modifications de sécurité/limite de confiance, les décisions juridiques/de licence, les modifications matérielles de portée/d'acceptation, et les choix à fort impact ambigus.
10. Répondez via une surface faisant autorité. Préférez la carte Besoins de l'opérateur (Needs you) spécifique à l'élément dans le cockpit terminal/Web. Sur la version validée d'Argus 0.1.1, les clients API peuvent utiliser POST /api/projects/{sid}/decisions/{decision_id}/resolve avec {"option_id":"…","note":"…"}, ou l'ancien POST /api/projects/{sid}/backlog/{item_id}/answer avec {"text":"…"}. Une réponse normale du cockpit ou POST /api/projects/{sid}/message est routée par le gestionnaire uniquement lorsqu'exactement une question est en attente ; lorsqu'il y en a plusieurs, adressez la carte/élément spécifique. "$ARGUS_BIN" --notify '<réponse>' met en file d'attente des instructions et ne peut être lié par le gestionnaire que lorsqu'exactement une question est en attente ; l'accusé de réception de la file d'attente n'est pas une résolution. Détectez les routes non cockpit sur d'autres versions. Ne devinez jamais au nom de l'utilisateur.
11. Vérifiez l'enregistrement, puis reprenez. Sur la version validée, exigez resolved: true là où la surface le renvoie. Confirmez que l'ancien pending_question a été effacé et qu'une résolution a été enregistrée. Lorsqu'une carte de décision typée existe, exigez également que cette carte devienne resolved ; les questions non typées héritées peuvent ne pas avoir de carte ou de resolution_id. Observez la continuation dans son état réel en attente, en cours d'exécution, terminé ou arrêté plutôt que d'exiger qu'elle soit encore active au moment de l'inspection. Une décision stop annule plutôt l'élément, préserve le travail, désactive le mode continu et ne crée aucune continuation. Réexécutez le statut et vérifiez que l'exécution a repris, s'est terminée ou s'est arrêtée comme prévu. Si le marqueur persiste, clarifiez ou escaladez ; n'envoyez pas de suppositions en double.
12. Inspectez sans importer la trajectoire. Utilisez le statut/cockpit pour la mission actuelle, le rôle, l'étape, le backlog, le résultat, la dernière position vérifiée et Besoins de l'opérateur. Traitez le backlog et la dernière preuve vérifiée comme la frontière. Gardez les transcriptions brutes, les journaux du démon, les E/S des agents, les journaux d'utilisation et les registres privés en local.
13. Récupérez et vérifiez les artefacts. Lisez les chemins de sortie nommés. Vérifiez l'existence, la portée demandée et les tests décisifs. Résolvez chaque citation matérielle à la source préparée ; rejetez les citations fabriquées, obsolètes ou ne correspondant pas à l'affirmation. Ne déduisez jamais le succès d'un message de progression.
14. Récupérez à partir de l'état durable. Reprenez le travail d'écriture/exécution en pause en demandant à Argus de reprendre à partir de l'état durable avec un objectif de reprise autonome, et non une réponse de chat en ligne. Si un thread d'exécution interne ne peut pas reprendre, utilisez les points de contrôle/capsules d'Argus. Diagnostiquez les questions non résolues, la propriété, la disponibilité du modèle/fournisseur interne, le budget/refroidissement et l'infrastructure avant de modifier la configuration ou l'objectif d'Argus.
15. Fermez uniquement sur preuve. Terminez lorsque l'objectif limité est atteint, les artefacts et les vérifications décisives réussissent, le verdict du réviseur requis est done, et qu'aucune question/carte en attente ne reste. continue, replan_requested, blocked, une pause de recherche ou Besoins de l'opérateur sans réponse ne constituent pas une fin. Distinguez l'achèvement de la mission de l'achèvement du projet/de l'étape. Utilisez references/closeout-checklist.md.

Alternatives de capacité

• Pas de découverte native de compétences : fournissez le bundle complet ou indiquez explicitement à l'hôte de lire ce fichier et l'adaptateur correspondant ; ne revendiquez pas une activation automatique.
• Pas de shell : l'hôte ne peut pas opérer directement Argus localement. Utilisez une intégration shell/terminal distante approuvée ou transmettez les étapes exactes de l'opérateur ; marquez l'exécution comme bloquée plutôt que de la simuler.
• Shell mais pas d'API de processus : préférez Argus --daemon uniquement lorsque l'environnement préserve les processus ; persistez toujours l'identité du projet/répertoire de travail et rentrez à nouveau avec le statut/cockpit. Ne mettez pas en arrière-plan avec des boucles fragiles &, nohup ou sleep/poll, sauf si l'environnement documenté de l'hôte en fait le seul chemin approuvé.
• API de processus mais pas durable entre les sessions hôtes : utilisez-la pour les journaux en direct uniquement ; l'état durable du projet Argus reste l'ancre de récupération, et le démon peut devoir être relancé.
• Pas de client HTTP/API : utilisez le terminal/cockpit Web et --status. N'exigez jamais l'accès API pour la boucle de questions.
• Pas de route d'approbation interactive : échouez en toute sécurité sur les actions nécessitant une approbation. Séparez le prévol sûr du lancement modificateur, ou demandez à l'humain d'approuver via l'interface utilisateur prise en charge de cet hôte. Ne contournez jamais les indicateurs d'approbation/sandbox simplement pour fonctionner sans surveillance.
• Exécution sans surveillance non autorisée : gardez une session interactive ouverte ou arrêtez-vous avec une instruction de reprise précise et un état non résolu. Signalez la surveillance comme conditionnelle, pas active.

Confidentialité, autorité et retour

Préparez un minimum de données. Gardez l'interface Web en boucle locale uniquement, sauf si l'utilisateur approuve un accès distant protégé. Les instructions actuelles de l'utilisateur et les preuves fraîches remplacent les plans antérieurs ou les suggestions d'exécution.

Revenez uniquement sur la surface d'invocation : identité du répertoire de travail/projet, résultat/frontière compact, verdict du réviseur, chemins des artefacts, validation décisive, exceptions de citation,

...

[tronqué pour la traduction]