Argus-Laufzeitorchestrierung

Was macht Argus-Laufzeitorchestrierung?

Verwenden Sie diesen Skill, wenn eine Aufgabe von dauerhaftem Zustand, Artefakten, Experimenten, Hintergrundausführung, unabhängiger Überprüfung, Pause/Fortsetzen oder einer Fortsetzung über einen Modellturn hinaus profitiert. Nicht verwenden für eine schnelle Antwort, eine einfache schreibgeschützte Inspektion oder eine kleine Operation, die der aktuelle Host sicher abschließen und direkt verifizieren kann.

Bekannte Einschränkungen

• Argus bietet keinen universell tragbaren Push-/Callback von Braucht dich in jeden Outer-Operator. Der Outer-Operator muss aktiv kompakte Argus-Status-/Ausgaben an sinnvollen Grenzen überprüfen. Die Interventionserkennung kann nicht in Echtzeit erfolgen, wenn der Host keine dauerhafte Überwachung aufrechterhalten kann, und dieser Skill verbietet es, in diesem Fall unbeaufsichtigte Überwachung zu behaupten.
• Die Adapter für Hermes Agent und Claude Code sind derzeit nur dokumentationsvalidiert, nicht lokal auf diesem Host ausgeführtstestet.
• Einige Copilot-CLI-Skill-Befehle in der aktuellen Dokumentation fehlen im lokal getesteten Build 1.0.39, daher ist eine Funktionserkennung erforderlich.

Zwei-Parteien-Betriebsmodell und Konfiguration

Es gibt genau zwei operative Parteien:

1. Der Outer-Operator: OpenClaw, Hermes Agent, Claude Code, Codex CLI, Copilot CLI oder ein anderer shell-fähiger Agent, der diesem Skill folgt. Er bereitet die Mission vor, startet und beobachtet Argus, beantwortet Operator-Fragen im Rahmen der delegierten Autorität, überprüft Artefakte und berichtet kompakt.
2. Argus: das dauerhafte überwachte System, das plant, ausführt, überprüft, Zustand persistiert, Fragen aufwirft sowie Beweise und Artefakte produziert.

Jedes Modell/Provider-CLI, das Argus intern verwendet – wie codex, copilot, claude, pi, opencode oder grok – ist eine Argus-Konfiguration und ein Implementierungsdetail, keine dritte Rolle, kein gleichberechtigter Akteur und keine separate Partei in dieser Prozedur. Der Outer-Operator kann das konfigurierte interne Modell/Provider von Argus während des Preflights auswählen oder überprüfen, wenn dies betrieblich notwendig und autorisiert ist; andernfalls behandelt er Argus als ein einziges dauerhaftes überwachtes System. Leiten Sie die Argus-Konfiguration nicht aus der Identität des Outer-Operators ab, selbst wenn die Namen zufällig übereinstimmen.

Lösen Sie die ausführbare Datei explizit auf; gehen Sie nicht von einem universellen Installationspfad aus. POSIX-Shell:

if [ -n "${ARGUS_BIN:-}" ]; then
  : # Operator hat einen ausführbaren Pfad angegeben
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 "Setzen Sie ARGUS_BIN oder ARGUS_INSTALL" >&2; exit 2
fi

Natives PowerShell:

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 "Setzen Sie ARGUS_BIN oder ARGUS_INSTALL"
}

Die untenstehenden Befehlsbeispiele verwenden POSIX-"$ARGUS_BIN" ...-Syntax. Rufen Sie in PowerShell den aufgelösten Pfad als & $ArgusBin ... auf.

Für einen Source-Checkout ist ARGUS_INSTALL="$HOME/src/Argus" nur ein Beispiel, kein portabler Standard. Notieren Sie den aufgelösten absoluten ausführbaren Pfad. Laden Sie niemals herunter, installieren Sie neu, ändern Sie die interne Modell-/Provider-Konfiguration von Argus oder erweitern Sie Berechtigungen stillschweigend.

Kernbetriebsablauf

1. Wählen Sie ein eigenes Arbeitsverzeichnis und eine echte Sicherheitsgrenze. Verwenden Sie ein dediziertes absolutes Verzeichnis pro Argus-Projekt. Überschneiden Sie niemals die Verzeichnishierarchie eines anderen aktiven Argus-Projekts. Verschieben, löschen oder teilen Sie es nicht schreibend, während sein Daemon aktiv ist. Echte parallele Arbeit erhält separate Projekte. Das Arbeitsverzeichnis ist eine Eigentumsgrenze, keine Sandbox. ARGUS_SKILL_SAFE_MODE=1 fügt Schutzmaßnahmen hinzu, ist aber selbst keine Isolierung für jedes Backend. Vor dem Bereitstellen sensibler Eingaben ist eine verifizierte Sandbox für das ausgewählte Backend erforderlich, oder führen Sie Argus in einer entsprechend isolierten OS-/Container-Grenze aus. Der Standardmodus unbeaufsichtigt kann internen Agenten Zugriff über das Arbeitsverzeichnis hinaus gewähren.
2. Stufen Sie begrenzte Eingaben bereit. Kopieren Sie nur aufgabenrelevante, offenlegungssichere Eingaben unter inputs/. Schreiben Sie OBJECTIVE.md mit Ergebnis, Nicht-Zielen, Ausgabepfaden, Abnahmekriterien, Autoritätsgrenzen sowie Überprüfungs-/Zitationsanforderungen. Stellen Sie keine Umgebungs-Konversationshistorie, Anmeldeinformationen oder nicht zusammenhängende private Daten bereit.
3. Preflight vom genauen Arbeitsverzeichnis aus. Führen Sie "$ARGUS_BIN" doctor aus, dann prüfen Sie "$ARGUS_BIN" --status. Verwenden Sie doctor --deep nur, wenn die Backend-Authentifizierung verifiziert werden muss; fügen Sie diese Netzwerk-/Auth-Latenz nicht zu jedem routinemäßigen Preflight hinzu. Deep Doctor ist kein universeller Beweis für lebende Authentifizierung: Wenn es ein ungeprüftes Token, eine Offline-Fähigkeit oder eine unerreichbare Route meldet, verwenden Sie den dokumentierten nicht-mutierenden Live-Bereitschaftstest dieses Backends vor dem Dispatch. Fahren Sie nur fort, wenn die erforderlichen Prüfungen bestanden sind, das beabsichtigte Projekt/Arbeitsverzeichnis identifiziert ist, kein Eigentumskonflikt besteht und alle betrieblich erforderlichen internen Modell-/Provider-Entscheidungen installiert und authentifiziert sind. Der Outer-Operator kann diese Argus-Konfiguration hier auswählen oder überprüfen, wenn er autorisiert ist, darf sie aber nicht als eine weitere operative Partei behandeln. Die aktuelle Argus-Top-Level-Hilfe ist absichtlich kurz und kann unterstützende Automatisierungsflags auslassen; bevor Sie --notify, Daemon-, gebundene oder API-Oberflächen gegen einen anderen Build verwenden, verifizieren Sie diese aus der Dokumentation/dem Parser dieses Builds oder durch einen sicheren Test. Siehe references/argus-runtime-surfaces.md.
4. Halten Sie die interne Ausführungskonfiguration nur dann explizit, wenn nötig. Bevorzugen Sie das bereits konfigurierte, installierte, authentifizierte interne Modell/Provider von Argus. Qualifizieren Sie Provider-Namen dort, wo Argus dies erfordert. Ändern Sie die Konfiguration nicht stillschweigend nach einem fehlgeschlagenen Bereitschaftstest; diagnostizieren Sie zuerst und holen Sie die Genehmigung ein, wenn die Änderung die delegierte Autorität überschreitet.
5. Starten Sie eine eigenständliche Mission. Geben Sie Argus vom Arbeitsverzeichnis aus ein in sich geschlossenes Ziel, das die bereitgestellten Eingaben und Ausgaben benennt. Fordern Sie den Abschluss von Inspizieren → Ausführen → Validieren → Reparieren → End-Artefakt an. Verweisen Sie auf die native Risiko-/Vertikale-Überprüfungsrichtlinie von Argus; fordern Sie eine unabhängige Überprüfung nur dann explizit an, wenn der Aufgabenvertrag oder das materielle Risiko dies erfordert. Halten Sie eine begrenzte Lieferung pro Mission. Für eine einmalige, begrenzte Mission, bei der kein wiederverwendbares Lernen angefordert wird und die Bereitstellungsrichtlinie dies zulässt, setzen Sie ARGUS_SKILL_REQUIRE_POST_TASK_LEARNING=0, um den standardmäßigen Post-Task-Learning-Modellaufruf zu vermeiden; andernfalls bewahren Sie die konfigurierte Lernrichtlinie. Verwenden Sie das interaktive Cockpit, wenn verfügbar; für die entkoppelte Ausführung verwenden Sie die dokumentierten Daemon-/gebundenen Oberflächen von Argus, keine improvisierte Shell-Schleife.
6. Bewahren Sie Beweisgrenzen innerhalb von Argus. Argus kann Planung, Engineering und Überprüfung intern trennen. Erfordern Sie entscheidungsgroße Missionen und Artefaktänderungen mit Beweisen. Wenn die Richtlinie von Argus eine unabhängige Überprüfung erfordert, muss diese die tatsächlichen Artefakte, Grenzen, Zitate und die Vollständigkeit überprüfen. Dies sind interne Verantwortlichkeiten, keine zusätzlichen Parteien im äußeren Betriebsmodell. Bevorzugen Sie einen entscheidenden Check pro Behauptung; vermeiden Sie zeremonielle doppelte Beweise oder zusätzliche Modellturns.
7. Überwachen Sie mit der stärksten verfügbaren Host-Fähigkeit. Folgen Sie dem ausgewählten Adapter in references/adapters/. Host-Hintergrund-/Prozess-APIs verbessern die Beobachtung, sind aber nicht die Quelle der Wahrheit: Der dauerhafte Argus-Projektzustand ist es. Verwenden Sie den entkoppelten Daemon von Argus nur, wenn die aktive Umgebung Host-Prozesse bewahrt. Andernfalls speichern Sie die genaue Arbeitsverzeichnis-/Projektidentität und starten Sie Argus in einem späteren Turn gegen diesen Zustand neu. Wenn kein entkoppelter Start erlaubt ist, behalten Sie ein Vordergrund-Cockpit bei oder bitten Sie den Benutzer, es laufen zu lassen; beanspruchen Sie niemals unbeaufsichtigte Überwachung.
8. Führen Sie die Schleife der ausstehenden Fragen an jeder Grenze aus. Überprüfen Sie "$ARGUS_BIN" --status beim Dispatch, bei jeder sinnvollen Statusprüfung, nach blockierten/pausierten/umgeplanten Ergebnissen, bevor Sie einen Lauf unbeaufsichtigt lassen, nach der Beantwortung und vor dem Abschluss. warte auf dich : N unbeantwortete Frage(n) ist ein Stoppsignal. Überprüfen Sie, wenn verfügbar, auch die Braucht dich-Eingabeaufforderung im Cockpit/Web-UI. Auf dem validierten Argus 0.1.1-Build können API-fähige Operatoren GET /api/projects/{sid}/status oder GET /api/projects/{sid}/snapshot?compact=true überprüfen; beide zeigen pending_questions, während vollständige Snapshots Zeilen im backlog zeigen. Diese Lese-Routen können möglicherweise auch dann unauthentifiziert bleiben, wenn ARGUS_SKILL_WEB_TOKEN konfiguriert ist: halten Sie sie Loopback-only oder platzieren Sie sie hinter einem vertrauenswürdigen VPN/authentifizierenden Reverse-Proxy; setzen Sie sie niemals direkt einem nicht vertrauenswürdigen Netzwerk aus. Erkennen Sie diese Routen bei anderen Builds durch Feature-Erkennung. Fortschrittsprosa allein ist nicht ausreichend.
9. Klassifizieren Sie jede Frage. Ein dauerhafter, nicht aufgelöster Marker ist eine Backlog-Zeile mit nicht leerem pending_question; eine typisierte Karte hat auch operator_decision.status == "pending", plus id, question, reason, evidence und optionale options. Dies ist keine informative Chat-Frage, kein Zieltext, kein Überprüfungsprosa und kein gewöhnliches /ask. Behandeln Sie den dauerhaften Marker als blockierend, selbst neben failed, paused_operator oder erfolgreich aussehendem Text. Lassen Sie Argus reversibles technisches Routing beibehalten, es sei denn, eine aufgeworfene Frage fällt eindeutig in die delegierte Autorität. Eskalieren Sie Anmeldeinformationen/Geheimnisse, Ausgaben, Löschung/Force-Push/Veröffentlichung/externe Sendungen, irreversible oder nach außen gerichtete Aktionen, Sicherheits-/Vertrauensgrenzenänderungen, rechtliche/Lizenzentscheidungen, materielle Umfangs-/Akzeptanzänderungen und mehrdeutige risikoreiche Entscheidungen.
10. Antworten Sie über eine autoritative Oberfläche. Bevorzugen Sie die artikelspezifische Braucht dich-Karte im Terminal-/Web-Cockpit. Auf dem validierten Argus 0.1.1-Build können API-Clients POST /api/projects/{sid}/decisions/{decision_id}/resolve mit {"option_id":"…","note":"…"} oder das Legacy-POST /api/projects/{sid}/backlog/{item_id}/answer mit {"text":"…"} verwenden. Eine normale Cockpit-Antwort oder POST /api/projects/{sid}/message wird vom Manager nur weitergeleitet, wenn genau eine Frage aussteht; wenn mehrere existieren, adressieren Sie die spezifische Karte/den spezifischen Artikel. "$ARGUS_BIN" --notify '<answer>' stellt Leitlinien in die Warteschlange und kann vom Manager nur gebunden werden, wenn genau eine Frage aussteht; die Bestätigung der Warteschlange ist keine Auflösung. Erkennen Sie Nicht-Cockpit-Routen auf anderen Builds durch Feature-Erkennung. Raten Sie niemals im Namen des Benutzers.
11. Verifizieren Sie die Aufzeichnung, dann setzen Sie fort. Fordern Sie auf dem validierten Build resolved: true, wo die Oberfläche es zurückgibt. Bestätigen Sie, dass der alte pending_question gelöscht wurde und eine Auflösung aufgezeichnet wurde. Wenn eine typisierte Entscheidungskarte existiert, fordern Sie auch, dass diese Karte resolved wird; Legacy-untypisierte Fragen haben möglicherweise keine Karte oder resolution_id. Beobachten Sie die Fortsetzung in ihrem tatsächlichen ausstehenden, laufenden, abgeschlossenen oder gestoppten Zustand, anstatt zu verlangen, dass sie zum Zeitpunkt der Inspektion noch aktiv ist. Ein stop-Entscheid bricht stattdessen den Artikel ab, bewahrt die Arbeit, deaktiviert den kontinuierlichen Modus und erzeugt keine Fortsetzung. Führen Sie den Status erneut aus und verifizieren Sie, dass die Ausführung wie beabsichtigt fortgesetzt, abgeschlossen oder gestoppt wurde. Wenn der Marker bestehen bleibt, klären Sie ihn oder eskalieren Sie; senden Sie keine doppelten Vermutungen.
12. Überprüfen Sie, ohne die Trajektorie zu importieren. Verwenden Sie Status/Cockpit für aktuelle Mission, Rolle, Phase, Backlog, Ergebnis, aktuellste verifizierte Position und Braucht dich. Behandeln Sie Backlog und aktuellste verifizierte Beweise als die Grenze. Halten Sie rohe Transkripte, Daemon-Protokolle, Agent-I/O, Nutzungsprotokolle und private Journale lokal.
13. Rufen Sie Artefakte ab und verifizieren Sie sie. Lesen Sie benannte Ausgabepfade. Überprüfen Sie Existenz, angefragten Umfang und entscheidende Tests. Lösen Sie jedes wesentliche Zitat zur bereitgestellten Quelle auf; weisen Sie fabrizierte, veraltet-aktuelle oder behauptungsinkonsistente Zitate zurück. Leiten Sie niemals Erfolg aus einer Fortschrittsmeldung ab.
14. Stellen Sie aus dem dauerhaften Zustand wieder her. Setzen Sie pausierte Schreib-/Ausführungsarbeit fort, indem Sie Argus bitten, mit einem in sich geschlossenen Fortsetzungsziel aus dem dauerhaften Zustand fortzusetzen, nicht mit einer Inline-Chat-Antwort. Wenn ein interner Ausführungsthread nicht fortgesetzt werden kann, verwenden Sie Argus-Checkpoints/Kapseln. Diagnostizieren Sie nicht aufgelöste Fragen, Eigentumsverhältnisse, interne Modell-/Provider-Bereitschaft, Budget/Cooldown und Infrastruktur, bevor Sie die Argus-Konfiguration oder das Ziel ändern.
15. Schließen Sie nur mit Beweisen ab. Beenden Sie, wenn das begrenzte Ziel erfüllt ist, Artefakte und entscheidende Prüfungen bestanden sind, die erforderliche Prüferbewertung done ist und keine ausstehende Frage/Karte mehr vorhanden ist. continue, replan_requested, blocked, Research-Pause oder unbeantwortetes Braucht dich ist kein Abschluss. Unterscheiden Sie den Missionsabschluss vom Projekt-/Phasenabschluss. Verwenden Sie references/closeout-checklist.md.

Funktions-Fallbacks

• Keine native Skill-Erkennung: Stellen Sie das vollständige Bundle bereit oder weisen Sie den Host explizit an, diese Datei und den passenden Adapter zu lesen; beanspruchen Sie keine automatische Aktivierung.
• Keine Shell: Der Host kann nicht direkt lokal Argus bedienen. Verwenden Sie eine genehmigte Remoteshell-/Terminalintegration oder geben Sie exakte Operator-Schritte weiter; markieren Sie die Ausführung als blockiert, anstatt sie zu simulieren.
• Shell, aber keine Prozess-API: Bevorzugen Sie Argus --daemon nur, wenn die Umgebung Prozesse bewahrt; persistieren Sie immer die Projekt-/Arbeitsverzeichnisidentität und treten Sie mit Status/Cockpit wieder ein. Führen Sie keinen Hintergrund mit fragilen &, nohup oder Sleep/Poll-Schleifen aus, es sei denn, die dokumentierte Umgebung des Hosts macht dies zum einzigen genehmigten Pfad.
• Prozess-API, aber nicht dauerhaft über Host-Sitzungen hinweg: Verwenden Sie sie nur für Live-Protokolle; der dauerhafte Argus-Projektzustand bleibt der Wiederherstellungsanker, und der Daemon muss möglicherweise neu gestartet werden.
• Kein HTTP/API-Client: Verwenden Sie Terminal-/Web-Cockpit und --status. Erfordern Sie niemals API-Zugriff für die Fragen-Schleife.
• Kein interaktiver Genehmigungsweg: Scheitern Sie geschlossen bei genehmigungspflichtigen Aktionen. Teilen Sie den sicheren Preflight vom mutierenden Start, oder bitten Sie den Menschen, über das unterstützte UI des Hosts zu genehmigen. Umgehen Sie niemals Genehmigungs-/Sandbox-Flags nur, um unbeaufsichtigt zu laufen.
• Keine unbeaufsichtigte Ausführung erlaubt: Halten Sie eine interaktive Sitzung offen oder stoppen Sie mit einer präzisen Fortsetzungsanweisung und nicht aufgelöstem Zustand. Melden Sie die Überwachung als bedingt, nicht als aktiv.

Datenschutz, Autorität und Rückkehr

Stellen Sie minimale Daten bereit. Halten Sie das Web-UI Loopback-only, es sei denn, der Benutzer genehmigt geschützten Remote-Zugriff. Aktuelle Benutzeranweisungen und frische Beweise überschreiben vorherige Pläne oder Laufzeitvorschläge.

Kehren Sie nur zur aufrufenden Oberfläche zurück: Arbeitsverzeichnis-/Projektidentität, kompaktes Ergebnis/Grenze, Prüferbewertung, Artefaktpfade, entscheidende Validierung, Zitatausnahmen,

…

[gekürzt für Übersetzung]