Build DSH Plugin

Was macht Build DSH Plugin?

Nutzen Sie diesen Workflow, um eine DSH-Plugin-Idee in ein Standard-Bundle zu verwandeln, ohne die Harness selbst zu modifizieren oder zu überschatten.

Normalisieren Sie die Benutzerkurzbeschreibung

Lesen Sie intake.md für jede neue Plugin-Anfrage. Akzeptieren Sie entweder gewöhnliche Sprache, die minimale chinesische Kurzbeschreibung oder die strukturierte JSON-Vorlage unter plugin-brief.template.json.

Verlangen Sie vor der Quellgenerierung nur drei semantische Fakten:

1. das aktuelle Benutzerproblem;
2. das erwartete Benutzerergebnis;
3. mindestens ein beobachtbares Abnahmekriterium.

Leiten Sie Namen, Paket-IDs, Architekturkandidaten, Risikoklasse, Projektstruktur, Tests und sichere Standardwerte ab. Fragen Sie den Benutzer nicht, ob er Host-APIs, Cordis-Einträge, Schemata, Build-Tools oder Teststrategien entwerfen soll, es sei denn, er hat eine Präferenz.

Wenn optionale Felder fehlen, standardisieren Sie auf Nur-Quellgenerierung, Standard-DSH-Bundle, Nur-Lese-Verhalten, keine echte Profilmutation, kein Neustart, kein externes Netzwerk/Prozess/Konto/Gerät, keine Anmeldedaten, nur lokale Exposition, keine Veröffentlichung und E3-wegwerfbare Abnahme. Bauen Sie wiederverwendbare DSH-Bundles mit einer marktplatzkompatiblen Paketstruktur als Standard, aber leiten Sie keine Autorisierung zum Einreichen oder Ändern des DSH STORE ab. Geben Sie jede Voreinstellung als Annahme an. „Keine Veröffentlichung“ ist eine Autorisierungsvoreinstellung, kein dauerhaftes Verbot: Eine ausdrücklich autorisierte, ordnungsgemäß lizenzierte, in sich konsistente, feste Veröffentlichung darf von einer Website vertrieben oder einem Marktplatz vorgeschlagen werden.

Stellen Sie nur Fragen, deren Antworten das Produktergebnis oder die Risikogrenze wesentlich verändern. Fehlendes Problem, Ergebnis oder Abnahme blockiert die Generierung. Fehlende Ziel-Profil, Mutationsbereich, Inhaber der Anmeldedaten, LAN/Internet-Sicherheit oder echtes Gerät/Konto blockiert nur die entsprechende reale Operation; es blockiert kein sicheres Quellgerüst, wenn Schnittstellen abstrakt bleiben können.

Führen Sie den deterministischen Normalisierer aus, wenn eine JSON-Kurzbeschreibung verfügbar ist:

node scripts/normalize-brief.mjs /absoluter/pfad/zu/plugin-brief.json
node scripts/normalize-brief.mjs /absoluter/pfad/zu/plugin-brief.json --json

Wenn der normalisierte Status READY oder READY_WITH_ASSUMPTIONS ist und der angeforderte Modus build-source ist, fahren Sie mit den Phasen 0–6 fort, ohne eine weitere breite Klärungsrunde. Stoppen Sie vor der Freigabe, der echten Profilmutation, dem Neustart, den Anmeldedaten, dem Gerät oder der öffentlichen Exposition, sofern nicht separat autorisiert und vollständig spezifiziert.

Legen Sie den Vertrag fest

Beginnen Sie im Nur-Lese-Modus. Überprüfen Sie die Repository-Anweisungen, die Ziel-DSH-Version, die offizielle Plugin-Dokumentation, das aktive Profil nur, wenn relevant, und ein aktuelles Standard-Plugin-Beispiel. Gehen Sie nicht von einem API- oder Paketvertrag aus einem älteren Projekt aus.

Befolgen Sie immer diese Regeln:

• Bauen Sie ein DSH-Bundle, keine Desktop-App oder einen Fork von DSH.
• Modifizieren Sie niemals den DSH-Quellbaum oder ein @deepseek-ai/*-Paket.
• Deaktivieren, ersetzen oder überschatten Sie niemals das offizielle Plugin-Inventar.
• Rufen Sie niemals Loader/Fiber-Mutations-APIs auf. Verwenden Sie öffentliche Host-Dienste und Bundle-Komposition.
• Verwenden Sie die offizielle DSH-CLI für Paketänderungen. Übergeben Sie feste Argument-Arrays; bauen Sie niemals Shell-Befehlsstrings.
• Halten Sie Tests in wegwerfbaren Home-Verzeichnissen/Profilen. Schreiben Sie niemals Tests gegen echtes ~/.dsh.
• Legen Sie keine Anmeldedaten, vollständige Benutzerdateien, injizierten System-/Plugin-Kontext, Modellüberlegungen oder privaten Pfade durch Protokolle oder Clients offen.
• Halten Sie Planung, Codevervollständigung, Paketfreigabe, Profilinstallation, Laufzeitabnahme und externe/Geräteabnahme als separate Zustände.
• Halten Sie Plugin-Bereitschaft, Katalog-Kandidaten-Bereitschaft, Registry-PR/CI, zusammengeführten Katalog, öffentliche Marktplatzsichtbarkeit und Profilinstallation als separate Zustände.
• Halten Sie kanonische Tool-Ausgabe, modellseitige Darstellung, anbieterneutrale Absicht der Karte und optionale benutzerdefinierte Client-Darstellung als separate Verträge.

Lesen Sie boundaries.md vor der Implementierung oder Installation. Harte Blocker in dieser Datei überschreiben jede Bewertung. Lesen Sie card-contract.md vor der Implementierung eines Modell-Tools, presentCall, presentResult, presentationMeta oder einer benutzerdefinierten Tool-Karte.

Erklären Sie jede folgenreiche Entscheidung

Geben Sie keine Regeliste ohne ihre Entscheidungslogik aus. Notieren Sie für jede Architektur-, Berechtigungs-, Mutations-, Freigabe- oder Abnahmeentscheidung:

1. Ziel: den Fehler oder das Ergebnis, das die Entscheidung kontrolliert.
2. Begründung: warum die DSH-Mechanik oder das aktuelle Bedrohungsmodell dies erfordert.
3. Vorteile: was sicherer, einfacher, kompatibler oder leichter zu überprüfen wird.
4. Kosten: Implementierungsaufwand, UX-Reibung, Leistungskosten, Fähigkeitsverlust oder Betriebsverzögerung.
5. Anwendbarkeit: die Bedingungen, unter denen die Entscheidung angemessen ist.
6. Alternativen: tragfähige Optionen, warum sie abgelehnt wurden und wann sie erneut in Betracht gezogen werden sollten.
7. Vorgehen: konkrete Schritte, Verantwortlicher, Eingaben, Ausgaben und Rollback-Verhalten.
8. Evidenzprüfpunkt: der beobachtbare Nachweis, der zum Fortschritt erforderlich ist, und die Bedingung, die die Arbeit stoppt.

Lesen Sie decision-guide.md bei der Planung, Überprüfung oder Erläuterung eines Plugins. Verwenden Sie dessen Entscheidungskarten, anstatt ein bevorzugtes Muster ohne Analyse zu kopieren.

Führen Sie den Workflow aus

Folgen Sie workflow.md für den vollständigen phasengesteuerten Prozess und die erforderlichen Artefakte. Überspringen Sie keine Phase, nur weil ein ähnliches Plugin sie zuvor bestanden hat; DSH-Versionen, Profilzusammensetzung, Abhängigkeiten und externe Dienste können sich ändern.

1. Nachweis der Host-Kompatibilität

Identifizieren Sie den Ziel-Host, die Erweiterungsnaht, das angeforderte Benutzerergebnis, die Zustandsmutationen, die externen Abhängigkeiten und die Abnahmeoberfläche.

Stoppen Sie und melden Sie eine Host-Inkompatibilität, wenn das Projekt auf Obsidian, VS Code, eine Browsererweiterung, nur MCP oder eine andere Laufzeit ohne nachgewiesenen DSH-Bundle-Vertrag abzielt. Bieten Sie den kompatiblen Host oder einen bewusst abgegrenzten Adapter an. Weichen Sie nicht in ein benachbartes Projekt aus.

Erstellen Sie einen Host-Vertragsnachweis und einen Architekturvergleich. Prüfpunkt: kompatibel, adapter-erforderlich oder inkompatibel; lassen Sie dies niemals als impliziten Prosa.

2. Risikoklassifizierung

Weisen Sie eine Klasse aus scorecard.md zu:

• R0: Nur-Lese-Metadaten/Benutzeroberfläche.
• R1: Host-Tools/-Dienste oder benutzereigener Plugin-Status, keine Profillebenszyklus-Schreibvorgänge.
• R2: externer Prozess, Netzwerk, Anmeldedaten oder Gerätebrücke.
• R3: Profillebenszyklus, Neustart, Fernsteuerung oder umfassende Verwaltung.

Verwenden Sie bei Unsicherheit die höhere Klasse. Notieren Sie Nicht-Ziele und verbotene Oberflächen vor der Codierung.

Erstellen Sie ein Risikoregister, das Assets, Akteure, Vertrauensgrenzen, Schreiboberflächen, Fehlerauswirkungen, minimales Evidenzniveau und den Grund für die Wahl der Klasse benennt.

3. Auswahl des Standardmusters

• Nur-Host-Bundle: einen öffentlichen Cordis-Dienst/ein öffentliches Cordis-Tool bereitstellen und eine oder mehrere eindeutige Patch-Zeilen beitragen.
• Host + Client: Browser-Code getrennt halten; mit window.__ModuleLoader__.load() und Slots registrieren. Browser-Code darf keine Host/Node-Module importieren.
• Optionale Web-Route: Registrierung mit ctx.inject(['webServer'], ...) verzögern; headless-/No-Web-Profile müssen trotzdem starten.
• Fähigkeitsadapter: isolierte Fähigkeitsdateien einbinden; die externe Laufzeit, Erweiterung oder Anmeldedaten nicht stillschweigend installieren.
• ApiProxy-Brücke: die enge öffentliche entfernte Oberfläche mit einer Positivliste, Schwärzung, Authentifizierung, begrenzter Analyse und fail-closed-Transportsicherheit anpassen.
• Lebenszyklusmanager: jede Profiländerung als R3-Transaktion behandeln und das folgende Mutationsprotokoll verwenden.
• Tool-Kartenvertrag: anbieterneutrale presentCall/presentResult-Render-Absichten bevorzugen; eine benutzerdefinierte Client-Slot-Karte nur für ein Plugin-eigenes Tool verwenden, wenn der untersuchte integrierte Wortschatz das Ergebnis nicht ausdrücken kann.

Erstellen Sie ein Bundle-Manifest mit dsh.bundle.patch, einem paketauflösbaren cordis.patch.yml, eindeutigen Eintrags-IDs, expliziten Dateien, Version, Lizenz und Build-Vertrag. Denken Sie daran, dass spätere Patch-Ebenen die gesamte config einer Zeile ersetzen; sie führen keine Tiefenzusammenführung durch.

Vergleichen Sie mindestens zwei plausible Muster, wenn die Wahl Berechtigungen, Prozessgrenzen, Installationsverhalten oder Benutzererfahrung betrifft. Notieren Sie Vorteile und Kosten; wählen Sie keine Architektur nur, weil ein früheres Projekt sie verwendet hat.

4. Implementieren Sie das Least-Privilege-Prinzip

Verwenden Sie öffentliche Dienste, die bereits von der untersuchten DSH-Version bereitgestellt werden. Wenn die erforderliche Naht fehlt, stoppen Sie und schlagen Sie einen Adapter oder eine Upstream-Änderung vor, anstatt den Kern zu patchen.

Bevorzugen Sie Nur-Lese-Erkennung und Dry-Run/Preview-APIs. Machen Sie Schreibfunktionen separat aktivierbar. Validieren Sie Schemata und Größenbeschränkungen vor der Geschäftslogik. Lehnen Sie fehlerhafte Profile, mehrdeutige Pfade, unbekannte offizielle Komponenten, veralteten Zustand, Wiederholungen, gleichzeitige Änderungen und fehlende Nachweise ab.

Notieren Sie für jedes Modell-Tool die kanonische Ausgabe, den modellseitigen Renderer, die ausstehende Karte, die abgeschlossene Karte, dauerhafte Präsentationsmetadaten, Grenzen/Schwärzung, generischen Fallback und Live-/Wiederholungsnachweise. Präsentatoren müssen deterministisch sein und keine E/A-, Takt-/Zufallszugriffe, Sitzungslesevorgänge oder zusätzliche berechtigungstragende Arbeit ausführen. Legen Sie niemals Anmeldedaten, vollständige private Dateien, Modellüberlegungen oder unbegrenzte Argumente in eine Karte.

Lesen Sie bei wiederkehrenden Fehlermustern problem-playbook.md.

Erstellen Sie eine Berechtigungsmatrix mit jeder Datenquelle/Aktion, besitzender Seite, zulässigem Aufrufer, Schwärzung, Größen-/Ratenbegrenzung, Fehlermodus und Test. Jede Berechtigung ohne Benutzerergebnis und Test wird entfernt.

5. Anwenden des Mutationsprotokolls

Erstellen Sie für Profil-/Paket-/Neustart-Mutationen einen neuen, typisierten Plan für genau eine Operation, der Folgendes enthält:

1. Operation und Ziel-Profil;
2. unveränderliche Paket-/Quellidentität;
3. genauer Dateibereich und erwartete Vorzustands-Hashes;
4. Befehls-argv und Arbeitsverzeichnis;
5. Sicherungsort und Rollback-Verfahren;
6. Nachzustand und Gesundheitschecks;
7. genau einen Bestätigungssatz;
8. Ablaufzeit und einmalige Identität.

Zeigen Sie den Plan an und warten Sie auf die genaue, operationsspezifische Bestätigung. Machen Sie ihn bei Nichtübereinstimmung, Ablauf, gleichzeitiger Änderung oder vorheriger Verwendung ungültig. Sichern Sie vor dem Schreiben, committen Sie atomar, führen Sie Konfigurations- und Laufzeit-Gesundheitschecks durch und führen Sie bei Fehlschlag ein Rollback durch. Eine Repository-Freigabe autorisiert niemals eine lokale Profilaktualisierung.

Behandeln Sie den Bestätigungsaufwand und die Transaktionsmechanik als explizite Kosten. Akzeptieren Sie diese Kosten für R3, da die Alternative eine stille, schwer wiederherstellbare Beschädigung des Benutzerzustands ist. Erlegen Sie das Mutationsprotokoll nicht bei reinen R0-Lesevorgängen auf.

6. Erklimmen Sie die Evidenzleiter

Fahren Sie nur mit aktuellen Nachweisen fort:

• E0: Idee oder Plan.
• E1: statische Struktur-/Quellüberprüfung.
• E2: automatisierte Unit-/Vertrags-/Fehlertests.
• E3: wegwerfbare Profilinstallation, --dump-config, Start und API-Smoke.
• E4: separat bestätigte echte Profilversion, Prozess/Port, offizielles Inventar/API und sichtbares UI-Rücklesen.
• E5: externe/öffentliche/Geräteabnahme plus Fehlerbehebungs- oder Rollback-Nachweise.

Leiten Sie niemals eine höhere Ebene aus einer niedrigeren ab. UI-Screenshots beweisen kein Rollback; HTTP 200 beweist kein sichtbares UI; Installationserfolg beweist keine Neustart-Gesundheit; Simulatorausgabe beweist kein echtes Gerät.

Für Tool-Karten umfasst E2 deterministische Präsentator-, fehlerhafte Wiederholungs-, Schwärzungs-, Begrenzungs-, Abschneidungs- und generische Fallback-Tests. E3 umfasst Live- plus beibehaltene Wiederholungsparität in einer isolierten DSH-Laufzeit. Sichtbares Kartenverhalten im Profil des Benutzers bleibt E4.

Erstellen Sie eine Evidenzmatrix pro Fähigkeit. Fügen Sie negative und Wiederherstellungsnachweise hinzu, nicht nur den Happy Path. Eine Bewertung bewertet die Bereitschaft; sie gewährt niemals Autorität oder ersetzt einen harten Prüfpunkt.

7. Freigabe und Installation getrennt

Vor der Repository-Freigabe synchronisieren Sie Paketversion, README, Katalogeintrag, unveränderlichen Installationsanker, Tests und feste Quellmetadaten. Für Git-Quellen entweder erstellte Artefakte ausliefern oder ein in sich geschlossenes prepare-Skript deklarieren und pnpm allowBuilds offenlegen; einen vollständigen Commit-SHA festlegen.

Führen Sie Repository-Prüfungen, Quellverifizierung und Pack-Dry-Run durch. Überprüfen Sie den entfernten Commit und die öffentlichen Assets nach dem Merge. Dann anhalten. Aktualisieren Sie ein echtes Profil nur unter einem neuen bestätigten Mutationsplan, starten Sie es über den genehmigten Mechanismus neu und lesen Sie die aufgelöste Version und den Laufzeitzustand zurück.

Erstellen Sie zwei separate Berichte: Repository-Freigabenachweise und Profil-/Laufzeitabnahmenachweise. Wenn der zweite Bericht fehlt, geben Sie Profil unverändert oder Profil unbestätigt an.

8. Machen Sie wiederverwendbare Plugins DSH-STORE-bereit

Lesen Sie marketplace.md, wann immer Sie ein wiederverwendbares DSH-Plugin eines Drittanbieters erstellen, ein bestehendes Repository für den DSH STORE bewerten oder einen Katalogeintrag vorbereiten.

Warten Sie nicht bis zur Einreichung, um Listen-Inkompatibilitäten zu entdecken. Reservieren Sie ab dem ersten Gerüst eindeutige Paket-/Katalog-/Eintrags-IDs; erklären Sie Repository, Version, Lizenz, sicheres dsh.bundle.patch, paketrelativen Patch, Laufzeit-/Build-Dateien, Lebenszyklus-Skripte, Berechtigungen, Abhängigkeiten und Kompatibilitätsnachweise. Führen Sie zu Beginn jeder STORE-Bewertung node scripts/official-dsh-releases.mjs aus und verwenden Sie dessen offizielles „letzten drei“-Fenster; verwenden Sie kein gespeichertes Fenster erneut. Der Resolver folgt dem höchsten aktiven npm latest/alpha/beta/rc-Kanal, schließt next-nur und veraltete Versionen aus und schlägt bei ungültiger Autorität fail-closed fehl. Das beobachtete Fenster von 2026-09-02 ist 0.1.2-alpha.2, 0.1.2-alpha.3 und 0.1.2-alpha.4, aber es ist ein Nachweis und keine permanente Konstante. Halten Sie genaue compatibility.dshReleases und passende compatibility.dshOperations-Aufzeichnungen für Installation, Start, Deinstallation und Rollback für jede Veröffentlichung im aufgelösten Fenster. Historische Schlüssel können bleiben, aber unbekannte Metadaten bleiben unbekannt, anstatt geraten zu werden.

Halten Sie STORE-Erkennung und vertrauenswürdige Installation physisch und logisch getrennt. Ein Eintrag in registry/candidates.json dient nur der Erkennung, trägt keinen Paket-/Installations-/Berechtigungsvertrag und muss zu installable: false ohne zulässige Aktionen normalisieren. Er kann sich nur nach einer separaten Überprüfung der festen Quelle, des Bundles, der Lizenz, der Berechtigung, der Kompatibilität und der Nachweise zu registry/catalog.json bewegen. Förderung, Empfehlung, Sponsoring, Sterne oder Abzeichen ändern diesen Vertrag nicht, da sie keine separate Verifizierung ersetzen.