Lebenszyklus-sichere Verifikation

Was macht Lebenszyklus-sichere Verifikation?

Auslöser und Grenzen

Verwende dies vor einem Task-Abschluss, einer Überprüfungsübergabe, einem Workspace-Teardown oder einem anderen autorisierten Übergang, der das aktuelle Arbeitsverzeichnis löschen oder verschieben könnte. Dieses Skill autorisiert keine Bereinigung, Lebenszyklusübergänge, Statusänderungen, Prozessbeendigungen oder Wiederholungen. Folge dem tatsächlichen Lebenszyklusvertrag der Plattform; nicht jeder Übergang entfernt einen Worktree, und ein erfolgreicher Übergang muss keinen Worker-Prozess stoppen.

Vor dem Übergang

1. Stelle die genaue Identität fest: Task/Record-ID, Board oder Namespace, Profil/Konto, Repository und erwarteter Zustand. Verlasse dich nicht auf den impliziten aktuellen Task eines Tools nach dem Wechseln von Verzeichnissen. Verwende explizite Selektoren, die von der Plattform unterstützt werden.
2. Untersuche die Bereinigungssemantik und identifiziere task-eigene versus persistente Speicherorte. Wähle ein bestehendes stabiles Verzeichnis außerhalb jedes Workspace, den der Übergang entfernen kann. Ein übergeordneter Pfad ist nur sicher, wenn er ebenfalls die Bereinigung überlebt; ein Symlink in den entfernbaren Workspace ist kein dauerhafter Speicherort. Löse echte Pfade auf.
3. Schließe zuerst die Akzeptanzprüfungen ab. Sichere erforderliche Berichte, Prüfsummen, Commits und Anhänge über den von der Plattform unterstützten Mechanismus für dauerhafte Artefakte oder einen anderen vom Benutzer genehmigten persistenten Speicherort. Lies die genaue Artefakt-ID und den Inhalt zurück. Ein Pfadstring in einem Kommentar sichert nicht die Datei, die er benennt.
4. Zeichne einen kompakten Vorübergangsbeleg außerhalb des entfernbaren Verzeichnisses auf: genaue Identität, erwarteter Übergang, Beweisorte, Verifikationsbefehle und alle ungelösten Einschränkungen. Markiere niemals eine unvollständige Akzeptanz als abgeschlossen, nur um Beweise zu sichern; verwende stattdessen den entsprechenden autorisierten Checkpoint-/Übergabestatus.
5. Plane die Nachübergangs-Verifikation so, dass sie nicht den alten Checkout, seine Virtualenv, relative Dateien, umgebungsabhängige Board-Erkennung oder Hilfsskripte benötigt. Löse erforderliche ausführbare Dateien und dauerhafte Pfade vor dem Übergang auf.

Übergang und genaues Rücklesen

1. Führe den bereits autorisierten Übergang einmal durch. Erfasse seinen Beleg, ohne den Erfolg als Beweis für den gewünschten dauerhaften Zustand zu behandeln.
2. Starte das Rücklesen mit dem expliziten stabilen Arbeitsverzeichnis-Parameter des Ausführungswerkzeugs. Ein cd innerhalb des Befehls wird möglicherweise nie ausgeführt, wenn das Tool fehlschlägt, während es in sein gelöschtes CWD wechselt. Wenn das Tool keinen Arbeitsverzeichnis-Override hat, verwende eine unabhängige Sitzung, die in einem überlebenden Speicherort verwurzelt ist. Wiederhole nicht die Lebenszyklus-Mutation, um ein fehlgeschlagenes Rücklesen zu reparieren.
3. Lies den genauen Task/Record und das Übergangsereignis über eine unterstützte schreibgeschützte Schnittstelle. Überprüfe den erwarteten Status, die relevante Lauf-/Ereignis-ID und den Inhalt dauerhafter Artefakte. Wenn die Entfernung selbst angefordert wurde, überprüfe separat die Abwesenheit des Dateisystems und die Deregistrierung des Git-Worktrees. Nimm nicht an, dass Verzeichnisabwesenheit bedeutet, dass ein Branch oder Anhang entfernt wurde.
4. Wenn die Plattform den angeforderten Zustand transformiert hat (z.B. zur Überprüfung weitergeleitet), melde den tatsächlichen Zustand. Wenn ein Worker aktiv bleibt, melde dies separat; stoppe ihn nicht ohne Autorisierung.
5. Bei Fehlern überprüfe stderr und welche Stufe fehlgeschlagen ist. Ein Wrapper, der 126 mit cd: ... No such file or directory zurückgibt, ist kein Beweis dafür, dass die Zieldatei chmod benötigt. Wiederhole nur die schreibgeschützte Verifikation von einem stabilen Verzeichnis. Wenn der Datensatz nicht gelesen werden kann, melde den Übergang als bestätigt, aber die Verifikation als unvollständig.

Wiederverwendbare Regressions-Testfunktion

Die Testfunktion erstellt ein eigenes temporäres Git-Repository und einen verknüpften Worktree, sichert einen synthetischen Beleg in einem benachbarten dauerhaften Verzeichnis, entfernt nur diesen Test-Worktree und beweist dann, dass der Start aus dem entfernten CWD fehlschlägt, während der Start aus dem dauerhaften Verzeichnis gelingt. Sie überprüft auch die Git-Worktree-Liste und den Beleginhalt. Sie berührt niemals einen echten Task, ein Remote-Repository, einen Benutzer-Workspace oder eine Plattform-API.

Führe sie aus dem installierten Paketverzeichnis aus:

python -m unittest discover -s scripts -p 'test_*.py' -v

Dies testet Dateisystem-/Subprozess-/Git-Verhalten, kein universelles Plattform-Bereinigungsversprechen. Reale Abschlusssemantik und Rücklesen dauerhafter Artefakte erfordern weiterhin plattformspezifische Verifikation. Führe keine Entfernungsbefehle gegen den Workspace eines Benutzers als Demonstration aus.

Quellen und Herkunft

Unabhängig verfasst aus wiederkehrenden Fehlern bei der Verifikation entfernter CWDs; keine privaten Logs, Pfade oder Task-Identifikatoren enthalten. Pythons Subprocess-Dokumentation dokumentiert cwd, Rückgabecodes und Fehler beim Start von Kindprozessen. Das Git Worktree-Handbuch dokumentiert die Erstellung, Entfernung und Auflistung verknüpfter Worktrees. Diese Primitive unterstützen die Testfunktion, nicht eine Schlussfolgerung über die Implementierung eines bestimmten Task-Schedulers.