DeepSeek Harness v0.1.0-rc.7: Einstellungskarten

Wenn ein Plugin unter rc.7 zwar lädt, aber niemand weiß, ob die neue Einstellungskarte Werte wirklich speichert, sollten Sie noch kein großes Redesign starten.

Die schnellste Entscheidung: Die Einstellungskarte in DeepSeek Harness v0.1.0-rc.7 verändert zunächst den Verwaltungszugang zu Plugin-Konfigurationen. Sie beweist weder ein stabiles Konfigurationsmodell noch eine sichere Migration über spätere Versionen. Prüfen Sie bestehende Plugins am ersten Tag, pilotieren Sie in der ersten Woche ein kleines, nicht sensibles Feld und behalten Sie Validierung sowie Rückfallpfad bei.

Für wen diese Einordnung gedacht ist

Dieser Beitrag richtet sich an Plugin-Autoren, die beurteilen müssen, ob ein vorhandenes dsh-plugin unter rc.7 angepasst werden sollte. Ebenso angesprochen sind Teams, die mehrere Plugin-Einstellungen vereinheitlichen möchten, sowie technische Verantwortliche, die den Reifegrad der DeepSeek-Harness-Erweiterungen bewerten.

Wenn Sie für den Pilotbetrieb eine getrennte Remote-Umgebung benötigen, können Sie sich zunächst im VMSPIN-Startbereich für Remote-Mac-Arbeitsplätze über die verfügbaren Einsatzmöglichkeiten orientieren. Die technische Entscheidung über die Einstellungskarte sollte jedoch unabhängig von der Wahl der Testumgebung getroffen werden.

Letzte Aktualisierung: 18.08.2026. Die Datums- und Versionsangaben wurden anhand des offiziellen Release-Hinweises vom 17.08.2026, des offiziellen Repositories und der verfügbaren Cordis-Quellen geprüft.

17.08.2026: Bestätigt ist die Registrierung, nicht der gesamte Vertrag

Im offiziellen Release-Hinweis zu DeepSeek Harness v0.1.0-rc.7 ist bestätigt, dass Plugins eigene Einstellungskarten registrieren können. Das ist eine konkrete Änderung der Verwaltungsoberfläche: Einstellungen können näher an dem Plugin angezeigt werden, das sie verwendet, anstatt ausschließlich über allgemeine Konfigurationsdateien oder manuelle Deployment-Schritte erreichbar zu sein.

Die Aussage ist jedoch enger, als sie auf den ersten Blick klingt. Aus der Möglichkeit, eine Karte zu registrieren, folgt nicht automatisch, dass auch die folgenden Punkte neu geregelt sind:

• die langfristige Stabilität des Settings-API,
• die Priorität zwischen Karte, cordis.yml und Umgebungsvariablen,
• die Speicherung über Neustarts und Upgrades,
• die Rechteverwaltung für einzelne Felder,
• die Ablage von Geheimnissen,
• die Migration auf eine spätere Harness-Version,
• der Lebenszyklus von Plugin-Einstellungen.

Die offizielle Release-Seite für v0.1.0-rc.7 ist deshalb die maßgebliche Quelle für die bestätigte Änderung. Für Architekturfragen sollten Sie zusätzlich das offizielle DeepSeek-Harness-Repository und die dort verknüpften Entwicklungsunterlagen heranziehen.

Was ist die Einstellungskarte in DeepSeek Harness?

Sie ist zunächst eine hostintegrierte Darstellung für Plugin-Optionen. Sie kann die Auffindbarkeit verbessern, die Bedienung vereinheitlichen und dem Team zeigen, welche Werte ein Plugin anbietet. Sie ist aber noch kein Beweis dafür, dass das Plugin seine Konfiguration nach einem Neustart, einem Upgrade oder einem Benutzerwechsel identisch wieder einliest.

Für die technische Bewertung müssen Sie daher drei Ebenen trennen:

1. Darstellung: Wird die Karte angezeigt?
2. Verarbeitung: Liest das Plugin den Wert korrekt und validiert ihn?
3. Persistenz: Wird derselbe Wert später aus der erwarteten Quelle wieder geladen?

Nur wenn alle drei Ebenen geprüft sind, lässt sich von einem funktionierenden Konfigurationskreislauf sprechen.

Tag 1: Bestehende Plugins zuerst beobachten statt umbauen

Am ersten Tag nach dem Release sollten Sie eine Bestandsaufnahme durchführen. Der Zweck ist nicht, jede alte Konfiguration an die neue Oberfläche anzupassen, sondern echte Auswirkungen von bloßen Möglichkeiten zu unterscheiden.

Ein vorhandenes Plugin benötigt vermutlich keine sofortige Änderung, wenn es unter rc.7:

• normal geladen wird,
• seine bisherigen Konfigurationswerte liest,
• Werte weiterhin korrekt speichert,
• keine feste alte Seitenstruktur voraussetzt,
• keine undokumentierten UI-Selektoren verwendet,
• keine Fehlermeldung beim Öffnen des Einstellungsbereichs erzeugt.

Dringender ist die Prüfung, wenn Ihr Plugin direkt auf eine alte Oberfläche zugreift. Dazu gehören fest codierte Navigationspfade, DOM-Selektoren oder eigene Workarounds, die nie als öffentliche Schnittstelle dokumentiert wurden. Eine neue Einstellungskarte kann solche Annahmen sichtbar brechen, obwohl der eigentliche Plugin-Code weiterhin korrekt arbeitet.

Muss ein vorhandenes dsh-plugin wegen rc.7 angepasst werden?

Nicht allein deshalb, weil eine neue Karte verfügbar ist. Eine Anpassung ist erst dann gerechtfertigt, wenn ein reproduzierbarer Fehler auftritt oder Sie bewusst eine hostintegrierte Oberfläche bereitstellen möchten. Prüfen Sie zuerst Laden, Anzeigen, Lesen, Ändern, Speichern und erneutes Einlesen. Das entspricht dem konservativen Vorgehen, das bei einer Vorabversion mit möglicher Kompatibilitätsänderung angemessen ist. Das README des offiziellen Projekts sollte dabei als Referenz für den dokumentierten Projektstatus dienen.

Ein Plugin kann erfolgreich starten und trotzdem beim Speichern einen falschen Pfad verwenden. Ebenso kann die Oberfläche einen neuen Wert anzeigen, während der Prozess intern weiterhin den alten Wert nutzt. Solche Fehler sind im Team schwieriger zu erkennen als ein vollständiger Ladefehler, weil sie erst bei einer bestimmten Sitzung oder nach einem Neustart auftreten.

Die drei Risiken hinter einer kleinen Oberfläche

Konfigurationshoheit

Wenn dasselbe Feld in einer Einstellungskarte, in cordis.yml, in einer Umgebungsvariable und in einer Deployment-Datei bearbeitet werden kann, entsteht eine Prioritätskette. Ohne dokumentierte Reihenfolge weiß niemand sicher, welcher Wert aktiv ist.

Definieren Sie für jedes Feld eine führende Quelle. Andere Quellen sollten nur als Initialisierung, bewusst dokumentierte Überschreibung oder Rückfallmechanismus dienen. Diese Regel gehört in die Plugin-Dokumentation und in die Übergabe an den Betrieb.

Validierung

Eine Karte kann ein Formularfeld darstellen, ohne fachlich zu prüfen, ob der Wert verwendbar ist. Ein gültiges Textformat bedeutet beispielsweise nicht, dass eine URL erreichbar, ein Modellname unterstützt oder ein Dienstkonto berechtigt ist.

Die bisherige Plugin-Validierung muss deshalb erhalten bleiben. Prüfen Sie:

• Datentyp und erlaubtes Format,
• Pflicht- und Optionalfelder,
• Standardwert bei fehlender Konfiguration,
• Verhalten bei einem ungültigen gespeicherten Wert,
• verständliche Fehlermeldungen,
• Rückfall auf einen sicheren Zustand.

Zuständigkeit und Datenschutz

In einer gemeinsam genutzten Umgebung kann eine manuelle Änderung mehrere Sitzungen oder automatisierte Abläufe beeinflussen. Zusätzlich müssen Sie die Grundsätze der DSGVO beachten: API-Schlüssel, Zugangsdaten und personenbezogene Informationen gehören nicht in sichtbare Kartentexte, Browser-Protokolle oder frei zugängliche Exportdateien.

Erfahrungshinweis: Eine Meldung wie „Speichern erfolgreich“ bestätigt nur den Oberflächenvorgang. Erst eine Seitenaktualisierung, ein Prozessneustart und erneutes Einlesen zeigen, ob der Wert tatsächlich dauerhaft verfügbar ist.

Erste Woche: Ein minimales Plugin als Prüfstand

Das Ziel der ersten Woche ist kein vollständiges Team-Panel. Sie benötigen zunächst einen kleinen, reproduzierbaren Test mit einer ungefährlichen Einstellung. Wählen Sie keinen API-Schlüssel, keinen Produktions-Endpunkt und keine Berechtigung mit weitreichender Wirkung.

Schritt 1: Testfeld auswählen

Geeignet ist ein nicht sensibler Anzeige- oder Verhaltensparameter, dessen Änderung keinen Datenverlust verursacht. Dokumentieren Sie vor dem Test:

• Feldname,
• Standardwert,
• zulässige Werte,
• erwartete Wirkung,
• Zeitpunkt der Wirksamkeit,
• Rückfallwert.

Schritt 2: Ausgangszustand festhalten

Notieren Sie die Harness-Version, die Plugin-Version, den Commit und die bisherige Konfigurationsquelle. Bewahren Sie den Ausgangszustand unverändert auf. So können Sie nach einem fehlgeschlagenen Versuch eindeutig feststellen, ob der Fehler durch die neue Karte oder durch eine parallele Änderung entstanden ist.

Die allgemeine Cordis-Architektur ist dabei nur so weit als Grundlage zu verwenden, wie sie in den offiziellen Quellen dokumentiert ist. Das offizielle Cordis-Repository kann die Architektur und Plugin-Mechanismen erklären, ersetzt aber keine DeepSeek-Harness-Dokumentation für die konkrete Einstellungskarte.

Schritt 3: Registrierung isolieren

Registrieren Sie zunächst nur die Karte und ein einziges Feld. Verwenden Sie API-, Komponenten- und Lebenszyklus-Namen ausschließlich dann, wenn sie im offiziellen Code, in der offiziellen Dokumentation oder in einer real reproduzierten Testinstanz nachweisbar sind.

Prüfen Sie, ob die Karte:

• beim erwarteten Plugin-Start erscheint,
• dem richtigen Plugin zugeordnet ist,
• den Standardwert korrekt darstellt,
• bei fehlender Konfiguration einen definierten Zustand zeigt.

Schritt 4: Lesen und Ändern getrennt prüfen

Lesen Sie zuerst den vorhandenen Wert ein. Ändern Sie anschließend genau dieses eine Feld. Prüfen Sie danach sowohl die Anzeige als auch die fachliche Wirkung im Plugin.

Ein lokaler Formularzustand ist nicht dasselbe wie eine aktualisierte Plugin-Konfiguration. Wenn die Karte den neuen Wert zeigt, das Plugin aber weiterhin mit dem alten Wert arbeitet, fehlt eine funktionierende Verbindung zwischen Oberfläche und Laufzeit.

Schritt 5: Speichern und Aktualisieren erzwingen

Speichern Sie die Änderung und aktualisieren Sie anschließend die Seite oder öffnen Sie den Verwaltungsbereich neu. Der Wert muss aus derselben erwarteten Quelle wieder erscheinen. Verschwindet er nach der Aktualisierung, ist die Darstellung nicht mit einer belastbaren Speicherung gleichzusetzen.

Schritt 6: Fehlerfall auslösen

Testen Sie einen ungültigen Wert, ein leeres Pflichtfeld und – falls fachlich relevant – einen nicht erreichbaren Dienst. Die Karte sollte den Fehler verständlich melden oder den definierten Rückfallwert verwenden.

Schritt 7: Neustart dokumentieren

Starten Sie den Harness-Prozess neu und prüfen Sie den Wert erneut. Ein Neustarttest ist wichtig, weil eine laufende Sitzung Werte im Speicher halten kann, ohne sie dauerhaft abzulegen.

Schritt 8: Rückfall durchführen

Entfernen Sie die neue Kartenkonfiguration und stellen Sie die bisherige Quelle wieder her. Der Rückfall muss dokumentiert und ohne manuelle Reparatur möglich sein. Erst wenn dieser Test gelingt, ist ein begrenzter Pilotbetrieb vertretbar.

Abhakbare Entscheidung für den Pilotbetrieb

• [ ] Das Plugin lädt unter v0.1.0-rc.7 ohne Sonderbehandlung.
• [ ] Die Einstellungskarte erscheint nur beim erwarteten aktiven Plugin.
• [ ] Ein Standardwert wird bei fehlender Konfiguration korrekt verwendet.
• [ ] Ein gültiger Wert lässt sich ändern und nach einer Aktualisierung wieder einlesen.
• [ ] Ein Neustart übernimmt den gespeicherten Wert erneut.
• [ ] Ein ungültiger Wert erzeugt eine verständliche Fehlermeldung oder einen definierten Rückfall.
• [ ] Für jedes Feld ist eine führende Konfigurationsquelle dokumentiert.
• [ ] Geheimnisse werden nicht sichtbar ausgegeben.
• [ ] Das Verhalten bei einem zweiten Benutzerkonto wurde geprüft, sofern die Umgebung geteilt wird.
• [ ] Ein Rückfall auf die bisherige Konfigurationsquelle ist beschrieben.
• [ ] Jede verwendete API-Bezeichnung ist durch offiziellen Code, Dokumentation oder Reproduktion belegt.
• [ ] Versionsstand und Testergebnisse sind im Plugin-Übergabedokument festgehalten.

Bleiben zwei oder mehr Punkte offen, sollten Sie die Karte nicht als teamweite Standardoberfläche ausrollen. Führen Sie den Test als Pilot weiter und behalten Sie die bisherige Konfigurationsquelle.

Einstellungskarte oder cordis.yml: zwei verschiedene Aufgaben

Wird die Einstellungskarte cordis.yml ersetzen?

Nach dem am 18.08.2026 bestätigten Informationsstand gibt es dafür keinen belastbaren Nachweis. Der Release-Hinweis beschreibt die Registrierung von Einstellungskarten, aber keine vollständige Ablösung deklarativer Deployment-Konfiguration.

Die beiden Ansätze erfüllen unterschiedliche Aufgaben:

• Eine Einstellungskarte dient der interaktiven Verwaltung.
• cordis.yml kann einen reproduzierbaren Ausgangszustand beschreiben.
• Eine Umgebungsvariable eignet sich für Laufzeitwerte und die Übergabe von Geheimnissen.
• Ein plugininterner Speicher kann Zustand verwalten, wenn Persistenz und Migration ausdrücklich dokumentiert sind.

Für jedes Feld sollte Ihr Team vier Fragen beantworten: Wer schreibt den Wert? Wer liest ihn? Wann wird er wirksam? Wie wird er zurückgesetzt? Ohne diese Antworten entstehen Supportfälle, die wie Plugin-Fehler aussehen, tatsächlich aber aus konkurrierenden Schreibpfaden stammen.

Teamphase: Eigentum und Übergabe vor Vereinheitlichung

Wenn mehrere Plugins Einstellungskarten anbieten, müssen Sie die Verantwortlichkeit je Feld festlegen. Ordnen Sie jede Option einer von drei Ebenen zu:

1. Plugin: Das Plugin kennt Format, Validierung und fachliche Bedeutung.
2. Host: Der Host steuert globale Standardwerte, Konten oder gemeinsame Rechte.
3. Bereitstellung: Die Infrastruktur setzt reproduzierbare Werte für eine Umgebung.

Ein Plugin sollte nicht gleichzeitig globale Sicherheitsregeln und eigene Komfortoptionen verwalten, wenn diese Verantwortungsbereiche nicht getrennt sind. Besonders kritisch sind Felder, die wie normale Texteingaben aussehen, aber Netzwerkzugriff, externe Dienste oder personenbezogene Daten beeinflussen.

Für die Übergabe an Ihr Team genügt zunächst ein kompaktes Dokument mit:

• Plugin- und Harness-Version,
• Feldname und Standardwert,
• Eigentümer der Einstellung,
• zulässigen Werten,
• erforderlichen Berechtigungen,
• Speicherquelle,
• Wirksamkeit nach Änderung,
• Sicherungs- und Rückfallmethode,
• Verhalten bei inkompatibler Version.

Ein kleines Panel mit klarer Zuständigkeit ist belastbarer als eine große Oberfläche mit unklarer Priorität.

Remote-Umgebungen: Sichtbare Änderung ist noch keine Persistenz

Eine verifizierte VMSPIN-Messung zu Plugin-Installation, Speicherung, Neustart und Remote-Zugriff liegt für diese Veröffentlichung nicht vor. Deshalb werden hier keine angeblichen Durchlaufzeiten, Erfolgsquoten, Hardwaredaten oder Standortwerte als Praxisergebnis ausgegeben.

Ihre eigene Remote-Prüfung sollte mindestens diese Zustände abdecken:

• Änderung über den entfernten Browser,
• Aktualisierung der Sitzung,
• Abmeldung und erneute Anmeldung,
• Neustart des Harness-Prozesses,
• Neustart der gesamten Instanz,
• Prüfung mit einem zweiten berechtigten Konto,
• Upgrade und anschließender Rückfalltest.

Bei einem entfernten Mac können Browser-Sitzung, laufender Prozess, Benutzerkonto, persistenter Datenträger und Bereitstellungsdatei unterschiedliche Zustände anzeigen. Ein erfolgreicher Klick im Browser beweist daher nicht, dass der nächste Prozessstart denselben Wert verwendet.

Für die Planung einer isolierten Testumgebung können Sie den VMSPIN-Startbereich für Remote-Mac-Arbeitsplätze als organisatorischen Ausgangspunkt verwenden. Wenn Sie eine solche Umgebung auswählen, sollten Sie vorab Zugriff, Aufbewahrung der Konfiguration und Rückfall nach dem Test schriftlich festlegen. Für dauerhaft hohe Last, physische Schnittstellen oder vollständig eigene Sicherheitskontrollen bleibt ein selbst verwalteter Mac allerdings die passendere Lösung.

Welche Signale den größeren Rollout rechtfertigen

Erhöhen Sie den Investitionsumfang erst, wenn mehrere belastbare Signale vorliegen:

• eine offizielle Dokumentation der Einstellungskarten,
• ein nachvollziehbares Beispiel-Plugin,
• klare Aussagen zur Persistenz,
• definierte Rechte und Geheimnisbehandlung,
• eine Kompatibilitätszusage für kommende Versionen,
• Release Notes mit konkreten Änderungen am Settings-Vertrag,
• reproduzierbare Tests für Fehler- und Rückfallfälle.

Bis dahin sollten Sie keine zentrale Plugin-Verwaltung bauen, die von einer möglicherweise internen Oberflächenstruktur abhängt. Das Projekt befindet sich laut den offiziellen Projektunterlagen weiterhin in einer frühen Entwicklungsphase; entsprechend müssen Sie mit Änderungen rechnen. (Projektstatus und Entwicklungshinweise im offiziellen Repository)

Wie kann ein Plugin seine eigene Einstellungsseite registrieren?

Bestätigt ist für rc.7 die Möglichkeit der Registrierung. Die exakten API-, Komponenten- und Lebenszyklus-Namen sollten Sie jedoch nur aus offiziellen Quellen oder einer reproduzierten Testinstanz übernehmen. Eine ausführliche Anleitung mit geratenen Bezeichnern wäre bei einer schnell veränderlichen Vorabversion nicht verlässlich.

Als sichere Vorgehensweise genügt zunächst ein minimales Beispiel: ein nicht sensibles Feld, ein dokumentierter Standardwert, eine sichtbare Änderung, eine Aktualisierung, ein Neustart und ein Rückfall. Erst wenn diese Kette stabil ist, sollten Sie weitere Felder oder mehrere Plugins einbeziehen.

Entscheidung nach dem ersten Prüfzeitraum

Nach der ersten Woche können Sie Ihr Plugin einer von drei Gruppen zuordnen:

Weiter beobachten: Das Plugin funktioniert mit der bisherigen Konfiguration, die Karte ist sichtbar, aber Persistenz oder API-Vertrag bleiben offen. Sie ändern das produktive Modell nicht.

Begrenzt pilotieren: Ein kleines Plugin besteht Lesen, Ändern, Speichern, Aktualisierung, Neustart, Fehler- und Rückfallprüfung. Die Karte bleibt auf eine isolierte Umgebung beschränkt.

Teamweit ausbauen: Konfigurationshoheit, Rechte, Geheimnisbehandlung, Rückfall und Versionskompatibilität sind dokumentiert und reproduzierbar getestet.

Der aktuelle Ansatz ist weder einer lokalen Eigenverwaltung noch einer allgemeinen Cloud-Umgebung automatisch überlegen. Eine lokale Umgebung bietet direkten Zugriff und einfache Diagnose, verlangt aber eigene Wartung, Versionspflege und einheitliche Teamstandards. Eine allgemeine Cloud-Umgebung kann schnell verfügbar sein, passt jedoch nicht automatisch zu macOS-spezifischen Werkzeugketten, Remote-Zugriff und den Anforderungen an reproduzierbare Plugin-Tests.

Für kurzfristige Prüfungen kann eine gemietete Mac-Umgebung deshalb organisatorisch angenehmer sein: Testdauer, Zugriff und Gerätebestand lassen sich getrennt planen. Für langfristige, dauerhaft hohe Rechenlast oder besondere physische Schnittstellen ist der eigene Mac weiterhin die ehrlichere Wahl.

Der nächste sinnvolle Schritt lautet daher nicht „alle Plugins auf Einstellungskarten umstellen“. Prüfen Sie ein kleines dsh-plugin, halten Sie cordis.yml oder die bisherige Konfigurationsquelle als Rückfall bereit und erweitern Sie die Lösung erst, wenn Persistenz und Kompatibilität durch offizielle Signale oder reproduzierbare Tests bestätigt sind.