Dauerhafte Sitzungen
Ein Agent kann Stunden damit verbringen, an einer Aufgabe zu arbeiten. Ich möchte nicht, dass diese Arbeit davon abhängt, dass ein Desktop-Fenster geöffnet bleibt. xNaut verwendet Zellij, einen Terminalsitzungsmanager, um unterstützte Terminalsitzungen unabhängig vom Client laufen zu lassen. Sie können das Fenster schliessen und die Verbindung zur Sitzung wiederherstellen, während der Host und die Prozesse weiterhin ausgeführt werden.
Eine dauerhafte Sitzung stellt nicht automatisch jeden fehlgeschlagenen Agentenprozess wieder her. Behandeln Sie Sitzungspersistenz, Prozesswiederherstellung und Aufgabenwiederholung als separate Anliegen.
Worktrees: ein Arbeitsverzeichnis für jede Aufgabe
Ein Git-Worktree ist ein weiterer Checkout desselben Repositorys in einem separaten Verzeichnis. Es verfügt über eigene ausgecheckte Dateien und einen Staging-Bereich und teilt gleichzeitig den Repository-Verlauf. Sie können einen Zweig in Ihrem Hauptverzeichnis geöffnet lassen und daneben an einem anderen Zweig arbeiten, ohne wiederholt Zweige zu wechseln oder unvollendete Änderungen zu speichern.
Beispielsweise kann ein Agent einen Anmeldefehler beheben, während ein anderer die Dokumentation aktualisiert. Geben Sie jedem einen Worktree und einen Zweig, und ihre Änderungen bleiben in separaten Verzeichnissen. Sie können jede Änderung prüfen und testen, bevor Sie sie zusammenführen. Sie können weiterhin dieselben Zeilen in ihren jeweiligen Zweigen ändern, sodass Zusammenführungskonflikte weiterhin möglich sind.
In xNaut listet der Worktree-Manager diese Checkouts auf, erstellt und entfernt. Durch das Starten einer Aufgabe aus einem Repository-Problem kann ein Worktree für dieses Ticket erstellt und dessen Kontext neben dem Code platziert werden. Beim normalen Entfernen wird ein Worktree mit nicht festgeschriebenen oder nicht verfolgten Dateien abgelehnt, sodass unvollendete Arbeiten nicht stillschweigend verworfen werden.
Ein Worktree trennt Dateien, nicht Berechtigungen. Ein lokal ausgeführter Agent hat möglicherweise weiterhin Zugriff auf Ihre Zugangsdaten, Ihr Netzwerk und andere Verzeichnisse. Hier wird eine Sandbox nützlich.
Sandboxes: Führen Sie den Code auf einem anderen Computer aus
Durch das Installieren von Abhängigkeiten, das Ausführen generierter Skripte und das Testen einer Anwendung wird Code ausgeführt. Eine Sandbox für virtuelle Maschinen gibt dieser Arbeit ein separates Betriebssystem und Dateisystem abseits Ihrer alltäglichen Entwicklungsmaschine. Sie wählen aus, welchen Code und welche Zugangsdaten Sie senden möchten.
Worktrees und Sandboxes ergänzen sich. Im Worktree liegen die Änderungen einer Aufgabe. Die Sandbox bietet die Umgebung, um sie zu bauen und zu testen. Die Ergebnisse müssen erkennen lassen, was ausgeführt wurde und welchen Code der Test geprüft hat. Ein bestandener Test mit dem gestrigen Checkout sagt wenig über die heutige Änderung aus.
Eine Sandbox benötigt weiterhin bewusste Zugriffseinstellungen. Die darin kopierten Zugangsdaten und über das Netzwerk bereitgestellten Dienste liegen in Ihrer Verantwortung. Isolation macht beliebigen Code nicht vertrauenswürdig.
Verwenden Sie die exe.dev-Integration
xNaut lässt sich in exe.dev integrieren, sodass Entwicklung und Tests in einer Remote-VM ausgeführt werden können. Erstellen Sie zunächst ein exe.dev-Konto, registrieren Sie Ihren SSH-Schlüssel und bereiten Sie eine VM mit den Tools vor, die Ihr Projekt benötigt. Verbinden Sie diese Umgebung mit xNaut, bevor Sie Arbeiten an sie senden. Ein Konto allein konfiguriert weder den Repository-Zugriff noch installiert es Ihre Toolchain.
Die dokumentierte Verifizierungsintegration wählt exe.dev pro Repository über .xnaut/verify.json aus. Es synchronisiert das Repository mit der konfigurierten VM und führt die Installations-, Build- und Testbefehle über SSH aus. Der Lauf erstellt eine Aufzeichnung und hängt die Ergebnisse zur Überprüfung an das Ticket an.
Dieses Setup verwendet eine persistente VM. Installierte Tools und Build-Caches können zwischen den Läufen überleben, wodurch vermieden wird, dass jede Prüfung von einem leeren Computer aus gestartet wird. Das bedeutet auch, dass Sie einen wiederholten Lauf in einer bestehenden Umgebung von einem Test in einer frisch erstellten Sandbox unterscheiden sollten.
NautLoop: Sandboxen mit einer Ablaufzeit
Ich entwickle auch NautLoop, unser eigenes Sandbox-System für diese Art von Arbeit. Sein GitVM-basierter Workflow gibt einem Projekt eine temporäre virtuelle Maschine mit einer definierten Lebensdauer. TTL bedeutet "Time to Live": Der Lease bestimmt, wie lange die Sandbox verfügbar bleibt, bevor das System sie zurückerhält.
Der GitVM-Workflow erstellt eine Sandbox für ein Arbeitsverzeichnis, synchronisiert den Code in dessen /workspace-Verzeichnis und führt dort Befehle aus. Ein konfigurierter offengelegter Port gibt der laufenden Anwendung eine URL, sodass Sie sie überprüfen oder testen können, während die Sandbox aktiv ist. Ein Worktree für jede Aufgabe ermöglicht es diesen Aufgaben, separate Sandbox-Umgebungen zu verwenden.
Der Lebenszyklus ist genauso wichtig wie die Erstellung der Maschine. Kopieren Sie die Dateien und Ergebnisse, die Sie behalten möchten, zurück, bevor Sie die Sandbox stoppen oder ihre Lease ablaufen lassen. Teardown zerstört seinen Arbeitsbereich. Ihr Repository bleibt die dauerhafte Aufzeichnung des Codes, nicht die temporäre VM.
NautLoop befindet sich noch in der Entwicklung. Es erfüllt den gleichen Bedarf an Remote-Entwicklung und -Tests, wobei der Schwerpunkt auf Umgebungen liegt, die nach der Arbeit ablaufen. Gehen Sie nicht davon aus, dass es das gleiche Setup oder die gleiche Verfügbarkeit wie exe.dev hat.
Bringen Sie das Ergebnis zurück zum Ticket
Der Verifizierungsplan teilt xNaut mit, wie das Projekt installiert, erstellt und getestet werden soll. Ein explizites .xnaut/verify.json stellt diese Befehle bereit; Unterstützte Node-Projekte können auch erkannte Paketskripte verwenden. Durch das Aufzeichnen der Befehle, Exit-Codes und Ausgaben können Sie einen fehlgeschlagenen Lauf untersuchen und erhalten keine vage Fehlermeldung.
Bei einem erfolgreichen Lauf wird die Arbeit zur Überprüfung zurückgegeben. Es stellt nicht sicher, dass die Tests alle Anforderungen abdecken oder dass sich die Anwendung in der Produktion korrekt verhält. Überprüfen Sie die getestete Revision, prüfen Sie die Änderungen und entscheiden Sie, ob die Nachweise das Ticket beantworten, bevor Sie es schliessen.
Erfassen Sie die Arbeit hinter einer Arbeitszeittabelle
Ein Kunde zweifelte einmal an, ob ich die abgerechnete Zeit tatsächlich für sein Projekt aufgewendet hatte. Mit meinem selbst entwickelten Werkzeug zur Arbeitsaufzeichnung konnte ich die Tätigkeiten hinter meinem Stundennachweis nachvollziehen. Diese Erfahrung ist ein wesentlicher Grund dafür, dass die Arbeitsprotokollierung zu xNaut gehört.
Starten Sie ein Arbeitsprotokoll für einen Kunden und ein Projekt. Während die Aufzeichnung aktiv ist, zeichnet xNaut erfasste Terminalbefehle mit ihren Zeitstempeln und Arbeitsverzeichnissen auf. Stoppen Sie die Sitzung, um sie abzuschliessen und einen Bericht mit den Sitzungszeiten und aufgezeichneten Aktionen zu erstellen. Es gibt Ihnen etwas Konkretes, das Sie neben der gelieferten Arbeit besprechen können.
Die Einträge bilden eine Hash-Kette: Jeder Eintrag enthält einen Fingerabdruck des vorherigen Eintrags. Wenn die Sitzung endet, kombiniert xNaut die Eintrags-Hashes in einem Merkle-Baum. Sein Stamm ist ein einzelner Fingerabdruck dieser Einträge, der mit einem zuvor gespeicherten Stamm verglichen werden kann, um Änderungen an den abgedeckten Feldern zu erkennen.
Das Protokoll unterstützt eine Arbeitszeittabelle; es misst nicht jede Minute menschlichen Einsatzes. Die Zeit zwischen den Befehlen kann Nachdenken, eine Besprechung, eine lange Bauphase oder eine Pause umfassen. Die Arbeit ausserhalb der eroberten Terminals bedarf einer eigenen Erklärung. Überprüfen Sie die Befehle und Pfade, bevor Sie einen Bericht freigeben, da diese möglicherweise Clientinformationen enthalten.
Unterzeichnen Sie einen Datensatz, damit jemand anderes ihn überprüfen kann
Ein lokal berechneter Hash ist keine digitale Signatur. Wer ein Protokoll kontrolliert, kann es ändern und neue Hashes berechnen. Eine vertrauenswürdige Kopie des Wurzel-Hashes hilft, spätere Änderungen zu erkennen. Für eine unabhängige Prüfung braucht es einen Nachweis, dem der Prüfer vertrauen kann.
xNaut verfügt ausserdem über ein separates Ausführungsnachweissystem für erfasste Agentenaktionen. Wenn die Securosys-Integration konfiguriert ist, gruppiert sie Datensätze in Merkle-Tree-Kontrollpunkten und signiert diese Kontrollpunkte mit einem Schlüssel, der in einem Hardware-Sicherheitsmodul gespeichert ist. Dies ist vom grundlegenden Arbeitsprotokollbericht getrennt; Beim Starten eines Arbeitsprotokolls erhält dieses nicht automatisch eine HSM-Signatur.
Ein exportiertes Nachweisbündel kann mithilfe eines separat vertrauenswürdigen öffentlichen Schlüssels offline überprüft werden. Der Verifizierer überprüft die Datensatz-Hashes, Ketten, Merkle-Roots und Checkpoint-Signaturen. Ein Prüfer kann prüfen, ob die abgedeckten Datensätze mit dem signierten Prüfpunkt übereinstimmen, ohne Zugriff auf den Signaturschlüssel zu benötigen. Die dokumentierten Prüfpunkt-, Export- und Verifizierungstools werden über die Befehlszeile ausgeführt.
Durch das Signieren wird die Integrität des abgedeckten Datensatzes in Bezug auf diesen Schlüssel hergestellt. Es stellt nicht unabhängig sicher, dass jedes Ereignis erfasst wurde, dass ein Zeitstempel eine unabhängig überprüfte Uhr widerspiegelt oder dass die gesamte verstrichene Zeit abrechnungsfähig war. Der Wert ist ein Datensatz, der zusammen mit dem Code, den Testergebnissen und der Projekthistorie untersucht und überprüft werden kann.