Engineering-Teams, die Conductor Cloud nutzen, sollten vor der Migration ihrer Workspaces offene Arbeiten der Agenten nachvollziehbar dokumentieren. In Conductors Ankündigung vom 4. November heißt es, dass Cloud am 13. November schreibgeschützt wird und am 20. November schließt, wenn die Löschung von Cloud-Nutzerdaten beginnt. Die unmittelbare Governance-Aufgabe besteht darin sicherzustellen, dass eine andere Ingenieurin oder ein anderer Ingenieur jede aktive Änderung erklären und weiterführen kann, nachdem der gehostete Workspace nicht mehr verfügbar ist.
Der angekündigte Übergang
Conductor kündigt an, künftig zu Meta zu gehören. Das Changelog vom 4. November bestätigt die Cloud-Termine und sagt, dass die lokale Version von Conductor bis Anfang 2027 neue Modelle und kritische Fehlerbehebungen erhalten wird. SiliconANGLE berichtet unabhängig über die Übernahme.
Zusätzlich zum Export der Kontodaten bietet das Unternehmen die Möglichkeit, einen Workspace samt Chats auf einen Mac zu übertragen. Das sind angekündigte Migrationswege, aber kein Nachweis dafür, dass Verlauf oder Arbeitszustand eines bestimmten Teams vollständig übertragen wurden. Die folgenden Prüfungen sind Empfehlungen von Maetra für Plattformverantwortliche und Engineering-Verantwortliche. Sie beschreiben weder eine getestete Migration noch ein garantiertes Exportformat von Conductor.
Ein Ziel und eine verantwortliche Person festlegen
Beginnen Sie mit den Workspaces, die eine aktive Änderung, eine noch ausstehende Begutachtung des Codes oder Informationen enthalten, die zur Rekonstruktion einer Freigabeentscheidung nötig sind. Weisen Sie jedem einen Engineering-Verantwortlichen zu. Halten Sie fest, ob das vorgesehene Ziel ein lokaler Workspace, ein internes Archiv oder eine andere genehmigte Entwicklungsumgebung ist.
Ein Download allein klärt nicht, wer für die Arbeit verantwortlich ist. Die übernehmende Person sollte wissen, welcher Branch aktuell ist, welche vorgeschlagenen Änderungen akzeptiert sind und welche Agentenvorschläge noch ungeprüft bleiben. Wenn mehrere Agenten beigetragen haben, sollte die Beziehung zwischen den Workspaces und den zugehörigen Repository-Änderungen erhalten bleiben, statt den letzten Chat als vollständigen Verlauf zu behandeln.
Verwenden Sie ein kompaktes Übergabeprotokoll: Workspace-Kennung, Repository, Branch, aktueller Commit, nicht abgeschlossene Änderungen, zugehöriger Pull Request, für die Übernahme zuständige Person und Speicherort des Archivs. Kennzeichnen Sie Felder, die sich nicht wiederherstellen lassen. Ein ausdrücklich als unbekannt markierter Wert gibt Prüferinnen und Prüfern einen Anlass zur Untersuchung, während eine abgeleitete, aber unbestätigte Kennung falsche Sicherheit darüber vermitteln kann, woher eine Änderung stammt.
Den Kontext zu den Codeänderungen sichern
Ein Commit im Repository kann den Code bewahren und zugleich die Begründung verlieren, die für seine Prüfung nötig ist. Für jede wesentliche nicht abgeschlossene Änderung sollten die dem Agenten erteilte Aufgabe, relevante Einschränkungen, die vorgeschlagene Änderung und der Bearbeitungsstand der Code-Review durch das Team erhalten bleiben. Sichern Sie bereits vorhandene Testnachweise und unterscheiden Sie diese von einer Behauptung im Chat, dass Tests erfolgreich waren.
Bewahren Sie nicht wahllos alles auf. Chats und lokale Arbeitsdateien können sensibles Material enthalten. Wenden Sie auf das Archiv die Zugriffs- und Aufbewahrungsregeln Ihrer Organisation an und machen Sie den Speicherort des Archivs für die Personen sichtbar, die ihn benötigen. Eine Zugriffsbegrenzung sollte nicht davon abhängen, dass sich jemand erinnert, auf welchem Laptop ein Download gelandet ist.
Vermeiden Sie es, aktive Zugangsdaten in ein erläuterndes Übergabedokument zu kopieren. Wenn das Ziel Zugriff auf ein Repository oder einen Dienst braucht, richten Sie diesen über den genehmigten Mechanismus für Zugangsdaten ein und dokumentieren Sie die verantwortliche Identität. Das Übergabeprotokoll sollte die Abhängigkeit erläutern, ohne das Geheimnis selbst offenzulegen.
Einen Transfer prüfen, bevor die Migration ausgeweitet wird
Wählen Sie einen repräsentativen Workspace aus und nutzen Sie den vom Anbieter dokumentierten Transfer- oder Exportweg. Anschließend sollte die übernehmende Ingenieurin oder der übernehmende Ingenieur den resultierenden Zustand prüfen. Maetra empfiehlt, diese Punkte zu kontrollieren, bevor dieser Workspace als übergeben gilt:
- Das erwartete Repository und der erwartete Branch sind vorhanden, mit dem vorgesehenen Ausgangs-Commit.
- Noch nicht per Commit gespeicherte Änderungen und von Git nicht erfasste Dateien wurden, wo relevant, erfasst.
- Die übernehmende Ingenieurin oder der übernehmende Ingenieur kann den Aufgabenkontext finden und geprüfte Arbeit von Vorschlägen unterscheiden.
- Vorhandene Testnachweise sind auffindbar, und jede erneute Ausführung wird als neues Ergebnis dokumentiert.
- Verknüpfungen zu Pull Requests, Issues und der verantwortlichen Person ergeben auch außerhalb des ursprünglichen Workspaces noch Sinn.
Diese Prüfungen vermeiden bewusst Annahmen darüber, was der Export enthält. Wenn ein Punkt fehlt, stellen Sie ihn über einen verfügbaren unterstützten Weg wieder her oder dokumentieren Sie die Lücke und entscheiden Sie, ob die betroffene Änderung erneut geprüft werden muss. Eine übertragene Arbeitsumgebung kann sich problemlos öffnen lassen, obwohl wichtige Teile der Arbeit darin nicht nachvollziehbar sind.
Sorgen Sie dafür, dass der ursprüngliche Workspace zugänglich bleibt, während die übernehmende Person die Übergabe prüft. Da Cloud vor der Schließung schreibgeschützt wird, sollte Ihr internes Abnahmedatum früh genug liegen, um Probleme noch beheben zu können. Conductor hat die Termine für die Einstellung des Dienstes bekannt gegeben. Jede frühere interne Frist ist eine Migrationsentscheidung Ihres Teams.
Den alten Zugriffsweg bewusst stilllegen
Sobald das Ziel für einen Workspace bestätigt wurde, prüfen Sie die Zugriffswege, die mit der ausgemusterten Umgebung verbunden sind. Identifizieren Sie die relevanten Repository-Verbindungen, Dienstidentitäten und lokal gespeicherten Konfigurationen. Entscheiden Sie, welche für die laufende Arbeit weiterhin benötigt werden und welche im Rahmen der normalen Administration entfernt werden können.
Gehen Sie nicht davon aus, dass die Übernahme selbst die Berechtigungen eines Kunden verändert oder belegt, dass der Zugriff beendet ist. Ebenso belegt der von einem Unternehmen genannte Zeitplan zur Datenlöschung nicht, dass Ihre Organisation ihre eigenen Aufbewahrungspflichten erfüllt hat. Halten Sie fest, welche Entscheidungen Ihr Team tatsächlich getroffen und welche Prüfungen es abgeschlossen hat.
Maetras Leitfaden Welche Nachweise für KI-Audits Teams erfassen sollten hilft dabei, den aufbewahrungswürdigen Verlauf zu bestimmen. Audit unterstützt nachvollziehbare Änderungshistorien, während Discover das Inventar von Agenten und Fähigkeiten unterstützt. Keines von beiden ist ein Migrationsservice für Conductor oder ein Versprechen, gelöschte Workspaces wiederherzustellen. Nutzen Sie die Maetra-Dokumentation, um die Übergabe einer überschaubaren Auswahl von Unterlagen zu planen. Diese Unterlagen sollten auch nach der Ablösung des ursprünglichen Werkzeugs verständlich bleiben.