DeepSeek-Harness-Plugins 2026 gestaffelt ausrollen

Der zeitliche Ablauf für ein kontrolliertes Plugin-Release

Ein gestaffeltes Release von DeepSeek-Harness-Plugins ist kein einzelner Installationsbefehl, sondern eine Abfolge von Kontrollpunkten. Das Projekt befindet sich laut offizieller Repository-Dokumentation weiterhin in der Developer Preview; dort wird ausdrücklich auf mögliche inkompatible Änderungen hingewiesen. Der Release v0.1.0-rc.7 ergänzt unter anderem registrierbare Einstellungs-Karten für Plugins, verändert aber nicht automatisch die Kompatibilitätslage jedes Drittanbieter-Plugins. Die offizielle Projektübersicht und die Release-Notizen zu v0.1.0-rc.7 sollten deshalb vor jedem Rollout gemeinsam mit dem Ziel-Plugin geprüft werden.

Diese zeitliche Trennung verhindert drei typische Fehleinschätzungen: Ein Plugin kann geladen werden, aber bei einer konkreten Tool-Aktion fehlschlagen; ein Dienst kann nach einem Neustart wieder erreichbar sein, während eine laufende Aufgabe nicht fortgesetzt werden kann; und ein scheinbar erfolgreiches Einzelupdate kann zusammen mit einer neuen Harness- oder Cordis-Version eine ungetestete Mischkombination bilden.

Vor dem Update: die gesamte Laufzeitkombination sichern

Nur die Namen der Plugins zu notieren, reicht für eine Rückkehr zum alten Zustand nicht aus. Für den Rückbau werden mindestens folgende Informationen benötigt:

1. Harness-Version und genauer Release- oder Commit-Stand.
2. Quelle jedes Plugins, etwa Registry, Quellcode-Checkout oder internes Paket.
3. Lock-Datei und Paketmanager-Metadaten.
4. Startbefehl, Arbeitsverzeichnis und verwendete Umgebungsvariablen.
5. Konfigurationsdateien einschließlich der tatsächlichen Suchpfade.
6. Host- und Client-Versionen sowie die relevante Node- oder Laufzeitversion.
7. Liste der registrierten Tools und der dafür erforderlichen Berechtigungen.
8. Ein Basistest, der vor dem Update erfolgreich abgeschlossen wurde.

Die Lock-Datei ist dabei ein Beweisstück, aber keine dauerhafte Stabilitätsgarantie. Sie hält eine konkrete Abhängigkeitsauflösung fest; sie verhindert jedoch nicht, dass sich ein Host-Vertrag, ein Plugin-API-Verhalten, ein Startskript oder ein Berechtigungsmodell verändert. Die offizielle Entwicklungsdokumentation und die Architekturhinweise des Projekts sollten deshalb zusammen mit dem Quellcode des Ziel-Plugins gelesen werden.

Ein mögliches Bestandsmanifest kann bewusst einfach gehalten werden:

mkdir -p release-evidence/current
dsh --version | tee release-evidence/current/harness-version.txt
node --version | tee release-evidence/current/runtime-version.txt
cp pnpm-lock.yaml release-evidence/current/
cp package.json release-evidence/current/
find . -maxdepth 3 -type f \
  \( -name '*config*' -o -name '*.json' -o -name '*.yaml' \) \
  > release-evidence/current/config-files.txt

Der Befehl ist kein universeller DeepSeek-Harness-Installer und muss an die tatsächliche Projektstruktur angepasst werden. Entscheidend ist das Prinzip: Die Belege müssen vor der Änderung erfasst werden, nicht erst nach einem Fehler. Automatische Aktualisierungen, unfixierte Tags und Installationsskripte ohne reproduzierbare Versionsangabe sollten während des Rollouts pausieren.

Müssen Teammitglieder dieselbe Plugin-Version verwenden?
Für eine gemeinsam genutzte Arbeitsumgebung lautet die belastbare Antwort grundsätzlich ja: Alle Instanzen, die dieselben Aufgaben, Konfigurationen oder Sitzungsdaten verwenden, sollten auf derselben freigegebenen Kombination laufen. Eine einheitliche Lock-Datei reduziert die Zahl der möglichen Fehlerbilder. Für Entwicklung und Validierung dürfen abweichende Versionen existieren, sofern die Umgebung eindeutig getrennt ist und nicht versehentlich produktive Sitzungen oder Kundendaten übernimmt.

Eine getrennte Prüfungsfläche statt eines riskanten Direktupdates

Die Validierungsumgebung muss nicht jedes Detail der Produktionsumgebung enthalten. Sie muss jedoch dieselbe Installationslogik und denselben Startweg verwenden. Wenn die produktive Instanz beispielsweise aus einem Quellcode-Checkout mit einem bestimmten Build-Skript startet, darf die Prüfung nicht ausschließlich über einen völlig anderen globalen Paketpfad erfolgen.

Für einen separaten lokalen Arbeitsbereich:

git clone --branch <bekannter-stand> <internes-repository> dsh-validation
cd dsh-validation
pnpm install --frozen-lockfile
pnpm run build
pnpm dsh web

Die Platzhalter sind absichtlich nicht durch erfundene Paketnamen oder Konfigurationsschlüssel ersetzt. Ein Beispielpaket aus einem Blogartikel darf nicht als offizielle Installationsanweisung verstanden werden. Welche Plugin-Einträge, Konfigurationspfade und Startparameter gelten, muss aus der aktuellen README, dem Entwicklungsleitfaden und dem Plugin-Quellcode abgeleitet werden. Die offiziellen Hinweise zum Beitrag und zur Entwicklung sind dafür geeigneter als Community-Kompatibilitätslisten.

Auf einem entfernten Mac gelten zusätzlich betriebliche Grenzen:

• Der Remote-Zugang darf nicht der einzige Rückfallweg sein.
• Die Testumgebung sollte einen eigenen Arbeitsbereich und getrennte Sitzungsdaten verwenden.
• Echte Kundenzugangsdaten, produktive API-Schlüssel und irreversible Aufgaben gehören nicht in die Prüfung.
• Bildschirmfreigabe, SSH-Zugang und lokale Prozessverwaltung müssen unabhängig voneinander funktionieren.
• Datenschutzvorgaben nach DSGVO sollten bereits beim Kopieren der Konfiguration berücksichtigt werden.

Fehlt eine zweite Ausführungsfläche, sollte die einzige Umgebung nicht aktualisiert werden. Ein kurzer Mietzeitraum für einen zusätzlichen Remote Mac kann in diesem Fall sinnvoller sein als ein unkontrollierter Produktionsausfall. NodeMini kann dafür eine zeitlich begrenzte Mac-Validierungsumgebung bereitstellen; die konkrete Eignung hängt von Zugriff, Datenhaltung und benötigten Schnittstellen ab.

Erste Prüfstufe: Laden und Konfigurationsvertrag

In der ersten Stufe wird ausschließlich geprüft, ob die neue Kombination technisch startet. Es geht noch nicht um produktive Tool-Aktionen. Der Test sollte beantworten:

• Wird das Plugin am erwarteten Suchpfad gefunden?
• Wird die Konfiguration gelesen, ohne stillschweigend auf Standardwerte zurückzufallen?
• Können Host und Client eine Sitzung eröffnen?
• Sind Plugin-Fehler vollständig im Protokoll sichtbar?
• Werden doppelte oder veraltete Plugin-Einträge erkannt?

Ein kontrollierter Start sollte die Ausgabe speichern:

dsh <freigegebener-startbefehl> 2>&1 | tee release-evidence/validation/load.log

Anschließend wird nicht nur nach einem erfolgreichen Exit-Code gesucht. Eine Anwendung kann mit Code 0 starten, obwohl ein Plugin intern deaktiviert wurde. Deshalb müssen die tatsächlich registrierten Erweiterungen, Warnungen und Konfigurationswerte mit dem eingefrorenen Baseline-Protokoll verglichen werden.

rc.7 unterstützt laut offiziellen Release-Notizen Plugin-eigene Einstellungs-Karten. Das ist ein konkretes neues Integrationsfeld: Ein Plugin kann nun zusätzliche Einstellungen sichtbar machen, aber daraus folgt nicht, dass vorhandene Drittanbieter-Konfigurationen unverändert funktionieren. Ein Test sollte daher prüfen, ob neue Karten nur lesbar angezeigt werden, ob Änderungen gespeichert werden und ob unbekannte Schlüssel sauber abgewiesen werden. Die vollständigen Release-Details sind dabei die Referenz; Namen aus Community-Beiträgen dürfen nicht ungeprüft übernommen werden.

Bei einem Fehler wird in dieser Phase nicht „weiterprobiert“, indem zusätzlich mehrere Plugins aktualisiert werden. Das neue Plugin wird aus der Validierungsfläche entfernt oder die gesamte Testkombination wird auf den bekannten Stand zurückgesetzt. So bleibt erkennbar, welche Änderung den Fehler ausgelöst hat.

Zweite Prüfstufe: Minimalaufgaben, Tool-Liste und Berechtigungen

Erst wenn der Ladevorgang und der Konfigurationsvertrag bestanden sind, folgen zwei kleine Aufgaben:

1. Eine rein lesende Aufgabe, zum Beispiel das Auflisten definierter Dateien oder das Prüfen einer unveränderten Konfigurationsdatei.
2. Eine begrenzte Schreibaufgabe, deren Ergebnis vollständig rückgängig gemacht werden kann.

Die Aufgaben sollten klein genug sein, dass eine Abweichung unmittelbar sichtbar wird. Ein Plugin-Update kann neue Tools registrieren, bestehende Werkzeugnamen verändern, Freigaben anders behandeln oder Standardrechte erweitern. Besonders riskant ist eine Berechtigung, die nur in der Benutzeroberfläche nicht mehr sichtbar ist, aber im Host weiterhin wirksam bleibt.

Was sollte vor dem Upgrade eines DeepSeek-Harness-Plugins getestet werden?
Nicht nur der Start. Erforderlich sind mindestens Plugin-Erkennung, Konfigurationslesung, Host- und Client-Verbindung, eine reine Leseaufgabe, eine rückgängig machbare Schreibaufgabe sowie ein Vergleich der Tool- und Berechtigungsliste. Bei einem Plugin mit Netzwerk-, Shell- oder Dateisystemzugriff ist jede Erweiterung der Rechte ein separater Freigabepunkt und kein gewöhnlicher Nebeneffekt des Updates.

Für die Vergleichsdaten genügt eine einfache, prüfbare Liste:

dsh <freigegebener-startbefehl> --list-tools \
  > release-evidence/validation/tools-after.txt

diff -u \
  release-evidence/current/tools-before.txt \
  release-evidence/validation/tools-after.txt

Falls der aktuelle Build keinen solchen Schalter anbietet, muss die Liste aus den Startprotokollen oder der Plugin-Registrierung gewonnen werden. Es wäre falsch, einen nicht dokumentierten Konfigurationsschlüssel zu erfinden, nur um den Vergleich zu automatisieren.

Dritte Prüfstufe: Sitzung, Persistenz und Prozessneustart

Die dritte Stufe trennt zwei häufig verwechselte Aussagen:

• „Der Dienst startet erneut.“
• „Die vorherige Aufgabe kann nach dem Neustart korrekt fortgesetzt werden.“

Nur die erste Aussage lässt sich durch einen erfolgreichen Prozessstart belegen. Für die zweite muss eine kontrollierte Sitzung angelegt, unterbrochen und anschließend wieder aufgenommen werden. Dabei sind mindestens eine neue Sitzung, eine bestehende Sitzung, gespeicherte Plugin-Einstellungen und ein vollständiger Prozessneustart zu prüfen.

Ein sinnvoller Ablauf lautet:

1. Neue Test-Sitzung mit der alten Kombination anlegen.
2. Dasselbe Baseline-Szenario mit der neuen Kombination starten.
3. Sitzung vor dem Abschluss kontrolliert beenden.
4. Prozess und relevante Host-Dienste neu starten.
5. Sitzung wieder öffnen und den Zustand vergleichen.
6. Erst danach eine längere Aufgabe zulassen.

Die Ergebnisse sollten nicht nur als „funktioniert“ markiert werden. Dokumentiert werden sollten Sitzungskennung, letzter abgeschlossener Schritt, erwartete Fortsetzung, tatsächliche Fortsetzung und eventuelle doppelte Tool-Aufrufe. Gerade bei dauerhaften Agents können doppelte Aktionen gefährlicher sein als ein sichtbarer Abbruch.

Die offizielle Repository-Struktur mit Paket-, Konfigurations- und Build-Dateien hilft bei der Zuordnung der betroffenen Komponenten. Für die eigentliche Kompatibilitätsentscheidung muss jedoch der konkrete Plugin-Code geprüft werden. Die Bezeichnung dsh-plugin allein sagt nicht, ob ein Plugin mit einer bestimmten Host- oder Cordis-Version kompatibel ist.

Die Freigabe als prüfbare Checkliste

Vor der ersten produktiven Umschaltung sollte die verantwortliche Person alle Punkte abhaken können:

• [ ] Harness-Version, Plugin-Versionen und Abhängigkeiten sind vollständig erfasst.
• [ ] Lock-Datei, Startbefehl und Konfigurationspfade liegen unverändert als Beleg vor.
• [ ] Automatische Updates sind für die Dauer des Rollouts deaktiviert.
• [ ] Eine getrennte Validierungsumgebung verwendet denselben Installations- und Startweg.
• [ ] Produktive Zugangsdaten und irreversible Aufgaben wurden ausgeschlossen.
• [ ] Plugin-Laden und Konfigurationslesung wurden erfolgreich protokolliert.
• [ ] Host und Client starten ohne unbekannte Fehler oder stille Fallbacks.
• [ ] Eine reine Leseaufgabe liefert das erwartete Ergebnis.
• [ ] Eine begrenzte Schreibaufgabe kann vollständig zurückgesetzt werden.
• [ ] Werkzeugliste und Berechtigungsgrenzen entsprechen der Baseline.
• [ ] Neue Rechte oder neue Standardwerkzeuge sind ausdrücklich genehmigt.
• [ ] Neue und bestehende Sitzungen wurden geprüft.
• [ ] Eine Fortsetzung nach Prozessneustart wurde tatsächlich getestet.
• [ ] Eine vollständige alte Plugin-Kombination ist sofort wiederherstellbar.
• [ ] Verantwortliche Person, Beobachtungszeitraum und Abbruchkriterien sind festgelegt.

Fehlt ein Häkchen bei der Wiederherstellung der vollständigen alten Kombination, ist die Freigabe nicht abgeschlossen. Ein einzelnes Downgrade kann eine ungetestete Mischung aus altem Plugin, neuer Harness-Version und veränderten Abhängigkeiten erzeugen.

Remote Mac: in kleinen Gruppen umschalten

Bei mehreren entfernten Macs sollte die Umschaltung nicht nach geografischer Nähe, sondern nach Aufgabenrisiko erfolgen. Zuerst wird eine Umgebung mit lesenden oder leicht rücksetzbaren Aufgaben aktualisiert. Danach folgt eine kleine Gruppe mit begrenzter gemeinsamer Nutzung. Erst wenn die Protokolle, Sitzungen und Neustarts unauffällig bleiben, wird die Änderung auf weitere Agents ausgeweitet.

Zwischen den Gruppen sollte ein festgelegtes Beobachtungsfenster liegen. Eine konkrete Dauer darf nicht pauschal behauptet werden, weil sie von Aufgabenlänge, Sitzungszustand und Rückfallmöglichkeit abhängt. Maßgeblich ist, dass mindestens ein neuer Start, eine bestehende Sitzung und ein kontrollierter Neustart beobachtet wurden.

Wenn Harness, Plugin und Abhängigkeiten gleichzeitig geändert werden, wird bei einem Fehler die gesamte bekannte Kombination wiederhergestellt. Das ist bei einem dsh-plugin wichtiger als die vermeintlich schnelle Rückkehr zu einer älteren Paketversion. Die alte Lock-Datei, der alte Build und die alte Konfiguration gehören zusammen.

Wie lässt sich ein fehlgeschlagenes dsh-plugin-Update schnell zurückrollen?
Zuerst wird die betroffene Umgebung aus dem Verkehr genommen, ohne laufende Logs zu löschen. Danach werden neue Sitzungen blockiert, die alte vollständige Kombination aktiviert und ein kurzer Basistest ausgeführt. Erst wenn Host, Client, Tool-Liste und eine sichere Minimalaufgabe wieder funktionieren, wird die Umgebung freigegeben. Ein bloßes Zurücksetzen der Plugin-Datei genügt nicht, wenn sich gleichzeitig Lock-Datei oder Harness-Version geändert haben.

Ein Rückfallprotokoll kann so aussehen:

git checkout <bekannter-stand>
pnpm install --frozen-lockfile
pnpm run build
pnpm dsh web

Auch hier müssen <bekannter-stand> und die konkreten Startbefehle aus der gesicherten Betriebsdokumentation stammen. Nach dem Rückbau sollten Version, Tool-Liste und Basistask erneut gespeichert werden, damit nicht nur ein Prozess startet, sondern der bekannte Betriebszustand nachgewiesen ist.

Wann ein Remote Mac die bessere Prüfungsentscheidung ist

Ein ausschließlich lokales Setup ist für einen einzelnen Entwickler oft ausreichend, solange eine zweite lokale Arbeitsfläche verfügbar ist und keine produktiven Langläufer betroffen sind. Für Plattformteams entstehen jedoch zusätzliche Kosten durch blockierte Arbeitszeit, schwer reproduzierbare Umgebungen und den Umstand, dass ein Mac während des Updates nicht gleichzeitig als stabile Produktionsfläche und als Testsystem dienen kann.

Ein Remote Mac ist besonders sinnvoll, wenn:

• die produktive Arbeitsfläche nicht unterbrochen werden darf;
• mehrere Plugin-Kombinationen parallel verglichen werden müssen;
• SSH, Bildschirmzugriff und Prozessneustart getrennt geprüft werden sollen;
• ein kurzfristiger Validierungsbedarf besteht;
• die lokalen Geräte keine klare Trennung von Test- und Produktionsdaten erlauben.

Die Nachteile bleiben bestehen: Ein Remote Mac benötigt eine saubere Zugriffsverwaltung, muss nach DSGVO-Grundsätzen betrieben werden und ersetzt keine Versionsstrategie. Wer dauerhaft hohe, stabile Last mit physischen Schnittstellen oder eigener Geräteverwaltung benötigt, fährt mit einer eigenen Mac-Flotte unter Umständen besser. Für kurzfristige Tests und ein kontrolliertes Release ist eine zusätzliche Umgebung jedoch oft die risikoärmere Option. Informationen zu verfügbaren Mac-Umgebungen für Tests und Betrieb können als Ausgangspunkt für die Planung dienen.

Eine klassische lokale Lösung hat dagegen ebenfalls klare Schwächen: Sie bindet die einzige Maschine während der Prüfung, erschwert die Trennung von Kundendaten und Testdaten und verleitet dazu, den Produktionsprozess direkt zu verändern. Ein gewöhnlicher Cloud-Server ist für Mac-spezifische Start-, Berechtigungs- oder Sitzungsfragen nicht immer gleichwertig. Wer nur gelegentlich eine zweite Ausführungsfläche braucht, kann deshalb mit einem gemieteten Mac von NodeMini schneller eine getrennte Validierungsbahn aufbauen, ohne sofort zusätzliche Hardware zu beschaffen. Die Entscheidung sollte trotzdem von Datenschutz, Zugriffskontrolle, Laufzeit und Rückfallanforderungen abhängen, nicht von der Bezeichnung „Cloud“ oder „Remote“.

Nach dem Rollout werden die Versionen, die verantwortliche Person, die beobachteten Aufgaben und die Bedingungen für die nächste Prüfung dokumentiert. Ein erneuter Review ist erforderlich, sobald sich die offizielle Harness-Version, die Plugin-API, die Cordis-Schnittstelle oder das Konfigurationsverzeichnis verändert. So bleibt das Release-Verfahren überprüfbar, auch wenn die Developer Preview weiterhin inkompatible Änderungen zulässt.