Jak napisać własną wtyczkę do DeepSeek Harness

Czym w rzeczywistości jest wtyczka dsh

Wtyczka dsh to pakiet npm, który eksportuje funkcję apply i dostarcza jeden niewielki plik YAML, informujący DeepSeek Harness o konieczności jej załadowania. Nie istnieje osobny zestaw SDK dla wtyczek, którego należałoby się uczyć. dsh jest aplikacją typu Cordis, a stwierdzenie „wszystko jest wtyczką” należy rozumieć dosłownie: rejestr narzędzi, pętla agenta, magazyn sesji oraz serwer WWW to wiersze w tym samym drzewie wtyczek, do którego dołącza Twój pakiet.

Cordis to ogólny framework kompozycyjny, zbudowany niezależnie i używany od lat jako podstawa frameworka chatbotowego Koishi. Obsługuje on ładowanie i usuwanie wtyczek oraz rozwiązuje zależności między nimi. Nie posiada wiedzy na temat agentów. Wszystko, co związane z agentami, pochodzi z pakietów typu harness, które są na nim nadbudowane, dlatego struktura wtyczki opisana poniżej jest tak niewielka. Większość funkcjonalności jest dziedziczona.

Wtyczka składa się z dwóch części. Część hosta działa w środowisku Node, rejestruje narzędzia i detektory zdarzeń oraz może dostarczać własne usługi. Część przeglądarkowa działa wewnątrz interfejsu Web UI i rejestruje sloty interfejsu. Pierwsza wtyczka niemal zawsze ogranicza się tylko do hosta, więc traktuj część przeglądarkową jako opcjonalną, dopóki nie stanie się potrzebna.

Niniejszy przewodnik został przygotowany dla wersji @deepseek-ai/dsh 0.1.0-rc.7, oznaczonej tagiem npm latest w dniu 19 sierpnia 2026 r. dsh znajduje się w fazie przeglądu deweloperskiego (developer preview), a jego plik README ostrzega przed zmianami naruszającymi kompatybilność. Każda nazwa klucza poniżej została odczytana z oficjalnej dokumentacji oraz repozytorium w tym dniu. Podczas ponownej weryfikacji przewodnika w dniu 12 października 2026 r. tag npm latest wskazywał wersję 0.2.0-rc.2, a poniższe sekcje wskazują, gdzie to wydanie zachowuje się inaczej. Przed poleganiem na konkretnym kluczu należy ponownie sprawdzić jego nazwę, ponieważ API w fazie przeglądu zmienia nazwy pól pomiędzy kandydatami do wydania. Jeśli harness jeszcze nie działa, skonfiguruj go najpierw zgodnie z DeepSeek Harness na VPS oraz kluczem API dsh i konfiguracją modelu, a następnie wróć tutaj.

Wczytaj jeden plik roboczy przed spakowaniem czegokolwiek

Pakowanie na początku to powolna metoda nauki. Wczytaj pojedynczy plik, sprawdź, czy środowisko uruchomieniowe wywołuje Twój kod, a dopiero potem go spakuj.

Utwórz folder poza katalogiem roboczym środowiska testowego i umieść w nim jeden plik.

import type { Context } from '@deepseek-ai/cordis'

export const name = 'hello-plugin'

export function apply(ctx: Context) {
  console.log('[hello-plugin] plugin loaded')
}

export const name to metadane używane do oznaczenia wtyczki w diagnostyce. apply stanowi pełną umowę: Cordis wywołuje ją raz i przekazuje kontekst ograniczony do Twojej wtyczki. Wszystko, co zarejestrujesz w tym kontekście, zostanie automatycznie cofnięte po usunięciu wtyczki.

Obok utwórz plik cordis.yml.

- insert:
    - id: hello
      name: '/absolute/path/to/scratch-plugin/hello.ts'

Teraz uruchom profil z nałożonym na wierzch tym plikiem.

dsh web --patch ./scratch-plugin/cordis.yml

Jeśli dsh nie znajduje się w Twoim PATH, npx @deepseek-ai/dsh web --patch ./scratch-plugin/cordis.yml wykonuje to samo zadanie. Ścieżka przez npx może dostarczyć starszą wersję kandydującą zamiast wersji opisanej w tym przewodniku, więc jeśli środowisko testowe odrzuci udokumentowaną flagę, wykonaj poprawki instalacji i błędów wersji dsh przed podważaniem poprawności własnego pliku. W terminalu, w którym uruchomiono dsh, powinieneś zobaczyć [hello-plugin] plugin loaded. Jeśli nic się nie pojawia, wiersz nie został poprawnie rozpoznany.

Pole name przyjmuje nazwę pakietu npm lub ścieżkę w systemie plików, a dokumentacja nadrzędna stanowi, że ścieżka musi być bezwzględna. Względna ścieżka ./hello.ts to pierwsza rzecz do sprawdzenia, gdy wtyczka robocza nie generuje żadnych danych wyjściowych. Drugą jest rozszerzenie pliku. Udokumentowana pętla jest uruchamiana jako pnpm dsh web --patch ... z klonu repozytorium środowiska testowego, gdzie wpisy TypeScript są ładowane przez tsx. Jeśli Twój dsh pochodzi z npm, wskaż w wierszu zwykły plik JavaScript lub najpierw zbuduj plik.

--patch to flaga uruchamiania, a jej nakładka jest stosowana na samym końcu, po wszystkich pakietach i po Twojej własnej poprawce profilu. Nakładka robocza ma zatem zawsze pierwszeństwo, co jest pożądanym zachowaniem podczas iteracji.

Napisz najmniejsze narzędzie, które wykonuje użyteczne zadanie

Wiersz dziennika potwierdza załadowanie wtyczki. Narzędzie potwierdza, że wtyczka jest częścią agenta.

import type { Context } from '@deepseek-ai/cordis'
import { defineTool } from '@deepseek-ai/dsh-tools'

export const name = 'greet-tool'
export const inject = ['tools']

export function apply(ctx: Context) {
  ctx.tools.register(defineTool({
    name: 'greet',
    description: 'Greet someone by name.',
    parameters: {
      name: { type: 'string', required: true, description: 'The name to greet' },
    },
    output: {
      schema: { type: 'string' },
      render: (_args, value) => [{ type: 'text', text: value }],
    },
    async execute(args) {
      return `Hello, ${args.name}!`
    },
  }))
}

export const inject = ['tools'] to wiersz, który ludzie pomijają. Wpisy w konfiguracji Cordis uruchamiają się współbieżnie, więc pozycja wiersza w pliku nie gwarantuje kolejności ładowania. Kolejność wynika z zadeklarowanych zależności. inject instruuje Cordis, aby zaczekał na istnienie ctx.tools przed wywołaniem Twojego apply; bez tego Twój kod może zostać uruchomiony w momencie, gdy rejestr nie jest jeszcze dostępny.

Reszta obiektu stanowi kontrakt widoczny dla modelu. parameters to schemat argumentów, a execute otrzymuje argumenty już przetworzone zgodnie z nim. output.schema opisuje wartość zwracaną przez execute, podczas gdy render konwertuje tę wartość na bloki treści odczytywane przez model. Rozdzielenie tych dwóch elementów pozwala interfejsowi wyświetlać jedną rzecz, podczas gdy model odczytuje inną.

Uruchom profil i poproś asystenta o powitanie kogoś z imienia. Odpowiedź wraca przez Twoje execute. Rejestracja przez ctx jest odwracalna, więc usunięcie wtyczki automatycznie wyrejestrowuje narzędzie. W przypadku wszystkiego, o czym Cordis nie może wiedzieć, jak gniazdo lub uchwyt pliku, wywołaj ctx.effect() i przekaż mu dyspozytor.

Dwa punkty rozszerzeń, z którymi styka się pierwsza wtyczka

Pełna lista punktów styku jest długa. Dwa z nich obejmują niemal każdą pierwszą wtyczkę.

Zdarzenia konwersacji stanowią trwały, rejestrowany strumień. W wersji 0.1.0-rc.7 nazwy to session/event, turn/start, turn/end, step/start, step/end, user/message, assistant/message, assistant/chunk, tool/call oraz tool/result. Wydanie 0.2.0-rc.2 nie zawiera assistant/chunk. Strumieniowanie na żywo przeniesiono do agent/assistant-stream, którego ramki pozostają w procesie i nie są logowane, a nowe trwałe zdarzenie assistant/attempt przechowuje nieudane, ponowione i anulowane próby. Dołącza się do nich zwykły odbiornik (listener).

ctx.on('tool/call', (payload) => {
  console.log('[my-plugin] tool/call', JSON.stringify(payload))
})

Wypisz ładunek (payload) raz i odczytaj go. Nie kopiuj nazw pól ładunku z żadnego przewodnika, w tym z tego, ponieważ struktury ładunku są częścią API w wersji zapoznawczej, które zmienia się najczęściej.

Drugim punktem rozszerzeń jest kaskada (waterfall). Zdarzenia agent/pre-step, agent/request, agent/request-error, llm/stream oraz tools/* to kaskady, a odbiornik kaskadowy posiada inną sygnaturę. Przyjmuje on wywołanie zwrotne next, a łańcuch jest kontynuowany tylko wtedy, gdy zostanie ono wywołane.

ctx.on('agent/request', async (payload, next) => {
  const startedAt = Date.now()
  const downstream = await next()
  console.log('[my-plugin] model request took', Date.now() - startedAt, 'ms')
  return downstream
})

Jeśli zapomnisz o await next(), nie dodasz punktu zaczepienia (hook). Zastąpisz wywołanie modelu niczym, a agent zatrzyma się w tym miejscu, ponieważ zwarcie (short circuiting) jest zamierzonym zachowaniem wtyczki bramy, która celowo odrzuca żądanie. Ta jedna różnica powoduje najwięcej zamieszania przy tworzeniu pierwszych wtyczek. Napisz wywołanie next(), zanim napiszesz cokolwiek wokół niego.

agent/request otacza samo wywołanie modelu. Jego ładunek przenosi agenta wykonującego wywołanie, numer otwartej tury, krok, do którego należy żądanie, oraz sygnał przerwania tej tury, co czyni go właściwym punktem styku dla rejestratora żądań lub ogranicznika szybkości (rate limiter). Kaskady tools/* mają ten sam kształt o jedną warstwę niżej. tools/pre-execute zezwala, odrzuca lub wymaga zatwierdzenia przed wysłaniem. tools/execute otacza wysyłkę. tools/post-execute może zastąpić lub zablokować znormalizowany wynik. tools/result jedynie obserwuje ustalony rezultat.

Pakowanie jako zestaw do instalacji przez innych użytkowników

Zestaw to pakiet npm, którego package.json zawiera pole dsh.bundle wskazujące na plik poprawki. Ta deklaracja stanowi jedyną różnicę między plikiem roboczym a obiektem gotowym do instalacji.

{
  "name": "dsh-plugin-hello",
  "version": "0.1.0",
  "type": "module",
  "main": "lib/index.js",
  "files": ["lib", "cordis.patch.yml", "README.md", "LICENSE"],
  "engines": { "node": "^22.19 || >=24", "dsh": ">=0.1.0-rc.6" },
  "dsh": { "bundle": { "patch": "./cordis.patch.yml" } },
  "keywords": ["dsh-plugin", "deepseek-harness"],
  "scripts": { "build": "tsdown", "prepare": "pnpm run build" },
  "exports": {
    ".": { "types": "./lib/index.d.ts", "default": "./lib/index.js" },
    "./cordis.patch.yml": "./cordis.patch.yml",
    "./package.json": "./package.json"
  }
}

Plik cordis.patch.yml znajdujący się obok jest krótki.

- insert:
    - id: dsh-plugin-hello
      name: dsh-plugin-hello

Wiersz name określa nazwę pakietu, dlatego oba te ciągi znaków muszą być identyczne. Wiersz id jest celem, do którego odwołuje się kolejna warstwa, gdy użytkownik nadpisuje konfigurację, dlatego należy wybrać nazwę stabilną i nigdy nie używać jej ponownie dla innej wtyczki.

files musi zawierać cordis.patch.yml. Pominięcie tego spowoduje, że opublikowane archiwum tarball będzie zawierać dsh.bundle.patch wskazujący na plik, który nie został spakowany, przez co pakiet zainstaluje się, ale nie wprowadzi żadnych zmian w drzewie.

Instalację w profilu należy przeprowadzić z katalogu zawierającego folder wtyczki.

dsh plugin --profile demo add ./dsh-plugin-hello
dsh --profile demo --dump-config
dsh --profile demo

dsh plugin --profile <name> przekazuje pozostałe argumenty do pnpm wewnątrz tego katalogu profilu, dzięki czemu add oraz remove działają zgodnie z zachowaniem pnpm. Odinstalowanie odbywa się za pomocą dsh plugin --profile demo remove dsh-plugin-hello. Dostarczone profile web, headless, sdk, sdk-minimal oraz acp tworzą się automatycznie z szablonów przy pierwszym użyciu. W wersji 0.2.0-rc.2 każda inna nazwa jest tworzona na jeden z dwóch sposobów. dsh plugin uruchamia profil wyłącznie na podstawie bazowego zestawu. dsh --profile <name> --from-default-profile <template> kopiuje listę zestawów z dostarczonego szablonu. Uruchomienie niestandardowego profilu, który jeszcze nie istnieje, kończy się niepowodzeniem i wyświetleniem wskazówki o konieczności wykonania dsh plugin.

Dlaczego wiersz nie pojawia się w złożonym drzewie

Proces kompozycji rozpoczyna się od pustej listy wpisów, a następnie nakłada warstwy w ustalonej kolejności. Najpierw dodawane są wszystkie pakiety wymienione w dsh.profile.bundles profilu, zgodnie z podaną kolejnością. Następnie przetwarzane są cordis.patch.yml profilu. Kolejnym krokiem jest $DSH_HOME/cordis.patch.yml. Na końcu nakładane są wszelkie nakładki --patch z wiersza poleceń. Późniejsze warstwy zastępują wcześniejsze wiersze o tym samym identyfikatorze.

Profile znajdują się w $DSH_HOME/profiles/<name>. Katalog profilu zawiera plik package.json z manifestem dsh.profile, który przechowuje uporządkowaną listę bundles oraz plik poprawek użytkownika. Nazwy pakietów są rozwiązywane najpierw w instalacji dsh, a następnie w node_modules profilu, gdzie pnpm umieszcza wtyczki spoza drzewa.

Polecenie dsh --profile demo --dump-config wyświetla w pełni złożone drzewo bez uruchamiania jakichkolwiek procesów; wynik tego polecenia stanowi granicę diagnostyczną. Jeśli identyfikator wiersza jest nieobecny, problem leży w kompozycji: nazwa nie została rozwiązana lub plik poprawki nie został spakowany. Jeśli wiersz jest obecny, a mimo to nic się nie dzieje, problem dotyczy kodu. Rozstrzygnięcie tej kwestii na początku pozwala wyeliminować większość domysłów.

Gdzie faktycznie pojawiają się błędy ładowania

Błąd zgłoszony wewnątrz apply jest wyraźnie widoczny. Proces kończy działanie z tym wyjątkiem, a użytkownik otrzymuje ślad stosu wskazujący na konkretną linię kodu.

Błędy rozpoznawania modułów są ciche. Ładowacz zgłasza moduł, którego nie może rozpoznać, za pośrednictwem loggera Cordis, zamiast powodować awarię. Dokumentacja źródłowa ostrzega, że komunikaty te mogą zostać pominięte podczas uruchamiania, ponieważ są emitowane przed podłączeniem eksporterów konsoli. Literówka w ścieżce wygląda zatem dokładnie tak samo, jak wtyczka, która załadowała się, ale nie wykonała żadnego działania. Dlatego warto wykonać sprawdzenie --dump-config przed przystąpieniem do analizy kodu.

Podczas programowania należy umieścić console.log jako pierwszą instrukcję w apply. Jej brak pozwala określić, z którą częścią problemu mamy do czynienia, a usunięcie tego fragmentu później nie generuje żadnych kosztów. Na serwerze, podczas iteracji, należy uruchamiać środowisko testowe na pierwszym planie, zamiast korzystać z menedżera usług. Dzięki temu dane wyjściowe ładowacza trafią bezpośrednio do terminala, zamiast do dziennika systemowego, który trzeba osobno przeglądać.

Iteracja bez restartu całego środowiska

W wersji 0.1.0-rc.7 rozwiązanie dla części hosta było proste: wymagany był restart. Pakiet aplikacji webowej z tego wydania zawierał wyłączoną funkcję współdzielonego przeładowania modułów (hot module reload), a w pliku znajdowała się adnotacja, że zostanie ona ponownie włączona po przetestowaniu cyklu życia przeładowania. W wersji 0.2.0-rc.2 to nadpisanie zostało usunięte. Podstawowy pakiet montuje @deepseek-ai/dsh-hmr w każdym profilu z root: [], pod komentarzem „Konfiguracja profilu przeładowuje się domyślnie; katalogi główne modułów wymagają aktywacji”. Poprawne edycje plików profilu oraz plików patcha domowego są teraz stosowane ponownie bez restartu. Kod źródłowy wtyczki nadal nie jest monitorowany, chyba że dodasz jej katalog do root w tym wierszu. Dodawanie, usuwanie lub aktualizacja pakietu nadal wymaga restartu. Łańcuch przeładowania po stronie klienta jest zawsze zamontowany, ale pozostaje nieaktywny, dopóki mechanizm monitorujący przebudowę nie nadpisze pakietów klienta, więc nie wpływa on również na część Node.

Zadbaj o to, aby restart był szybki, zamiast polegać na przeładowaniu, które wymaga ręcznej aktywacji. Utrzymuj wtyczkę w jednym pliku. Ładuj ją za pomocą --patch zamiast instalować w profilu, dzięki czemu żaden krok budowania ani krok pnpm nie dzieli edycji od uruchomienia. Rejestruj wszystko przez ctx, aby restart nie pozostawił zduplikowanego narzędzia ani nieaktualnego procesu nasłuchującego. Każdy zasób, który przydzielasz samodzielnie, opakuj w ctx.effect() z odpowiednim mechanizmem usuwania (disposer), ponieważ typowym objawem braku usuwania jest niepowodzenie drugiego uruchomienia z powodu portu zajętego przez pierwsze uruchomienie.

Jeśli tworzysz oprogramowanie w oparciu o środowisko testowe działające na serwerze, a nie na laptopie, powyższe zasady pozostają bez zmian, ale powiązanie interfejsu webowego (Web UI) ma znaczenie. Uruchomienie lokalne serwuje Web UI pod adresem http://127.0.0.1:3080 i otwiera je w domyślnej przeglądarce lub pomija przeglądarkę, jeśli przekażesz flagę --no-open. Uruchomienie przez SSH jedynie wyświetla adres URL hosta, więc na Twojej maszynie nic się nie otwiera. Powiązanie loopback na porcie 3080 wyjaśnia, dlaczego w takim przypadku strona się nie otwiera i co należy z tym zrobić.

Część przeglądarkowa i poziom zaufania do niej

Dodaj ten element tylko wtedy, gdy wtyczka wymaga własnego interfejsu. Deklaruje się go w tym samym polu dsh co pakiet.

{
  "dsh": {
    "client": {
      "platform": "web",
      "inject": [],
      "external": [],
      "immediately": false
    }
  },
  "exports": {
    ".": "./src/index.ts",
    "./client": "./src/client/apply.ts",
    "./package.json": "./package.json"
  }
}

Pole "platform": "web" jest wymagane, a skaner zgłasza błąd, jeśli pakiet nie posiada eksportu ./client, dlatego mapa eksportów stanowi część manifestu, a nie udogodnienie. Punkt wejścia klienta otrzymuje obiekt Cordis Context rozszerzony o typ środowiska uruchomieniowego klienta, a każda rejestracja odbywa się wewnątrz apply poprzez ctx.slots.register. Efekty uboczne na poziomie modułu są tam niedozwolone.

import type { Context } from 'cordis'
import type { DshClientContext } from '@deepseek-ai/dsh-client-runtime'

export async function apply(ctx: Context & DshClientContext) {
  ctx.slots.register({ name: 'domain.entry.slot' }, MyComponent)
}

Przed rozpoczęciem warto poznać dwa szczegóły. Pole inject w manifeście klienta pełni funkcję dokumentacyjną, a nie harmonogramu: rejestruje krawędzie zależności na poziomie pakietu i nie kontroluje kolejności aktywacji. Pole external deklaruje żądania modułów spoza linii bazowej, jednak bieżące notatki klienta wskazują, że nie jest to mechanizm zależności dla wtyczki funkcyjnej i jest zarezerwowany dla infrastruktury, transportu oraz wygenerowanego kodu asemblera. W przypadku wtyczki funkcyjnej pozostaw to pole puste. Jest to najszybciej zmieniający się obszar wersji zapoznawczej, dlatego zapoznaj się z plikiem packages/client/AGENTS.md w repozytorium harness w dniu pisania kodu, a nie w dniu czytania poradnika na ten temat.

Publikacja i informacja o tym, do czego dostęp ma wtyczka

Dodanie tematu dsh-plugin do repozytorium GitHub umieszcza je na liście przeglądanej przez osoby poszukujące wtyczek. Jest to deklaracja zaufania, która wiąże się z określonymi zobowiązaniami. Zobowiązania te są lustrzanym odbiciem tego, co nasz przewodnik weryfikacji wtyczek dsh przed instalacją zaleca sprawdzić użytkownikom, więc pisanie zgodnie z tą listą kontrolną jest najprostszym sposobem na jej przejście.

• Blokuj wersje zależności. Zakres z daszkiem (caret range) dla zależności przechodniej sprawia, że pakiet, który był bezpieczny w zeszłym tygodniu, w tym tygodniu uruchamia inny kod; jest to dokładnie mechanizm stojący za atakami na łańcuch dostaw npm na serwerze.
• Niech manifest informuje, do czego masz dostęp. Twoja lista inject to uczciwe, czytelne dla maszyny podsumowanie usług harness, z których korzystasz. Recenzent przeczyta ją w kilka sekund i wyrobi sobie na jej podstawie opinię.
• Brak ukrytych wywołań sieciowych. Jeśli narzędzie wywołuje API, podaj nazwę hosta w pliku README i spraw, aby punkt końcowy był konfigurowalny. Wtyczka, która kontaktuje się z serwerem, o którym nie wspomniała, zostanie usunięta z listy przez osoby audytujące takie rozwiązania.
• Utrzymuj files w ścisłych ryzach. Publikowanie całego folderu roboczego prowadzi do sytuacji, w której plik z poświadczeniami trafia do rejestru.
• Dostarcz instalatorom korzystającym z git skrypt prepare, który buduje projekt bez założeń dotyczących środowiska deweloperskiego, i poinformuj ich w pliku README, że muszą dodać to budowanie do listy dozwolonych w pliku pnpm-workspace.yaml swojego profilu.
• Oznacz plik README datą odpowiadającą wersji release candidate, z którą budowałeś i testowałeś wtyczkę. Czytelnicy korzystający z wersji preview API muszą wiedzieć, z którą z nich pracowałeś.

Aby zobaczyć, jak gotowa wtyczka wygląda z zewnątrz, przeczytaj wtyczki dsh warte zainstalowania i zwróć uwagę na to, co każdy plik README przekazuje przed instalacją. Jeśli tworzyłeś rozszerzenia dla innego agenta, sposób budowy wtyczek Claude Code stanowi użyteczny punkt odniesienia. Harness przekazuje Ci aktywny graf obiektów i odwracalną rejestrację, co daje większe możliwości niż zwykły manifest plików, ale wiąże się z większą odpowiedzialnością.

FAQ

Czy muszę publikować w npm, aby napisać wtyczkę dsh?

Nie. Ścieżka w systemie plików w nakładce cordis.yml, ładowana za pomocą dsh web --patch ./scratch-plugin/cordis.yml, wystarcza do uruchomienia własnego kodu wewnątrz harness. Ścieżka musi być bezwzględna. Pakowanie ma znaczenie tylko wtedy, gdy ktoś inny instaluje wtyczkę, a nawet wtedy można zainstalować lokalny folder za pomocą dsh plugin --profile demo add ./my-plugin, aby przetestować spakowaną formę bez dotykania rejestru.

Dlaczego moja wtyczka się ładuje, ale narzędzie się nie pojawia?

Uruchom najpierw dsh --profile demo --dump-config. Jeśli identyfikator Twojego wiersza nie znajduje się w tym wyniku, wtyczka nigdy nie została zamontowana, a przyczyna leży w kompozycji, a nie w kodzie. Jeśli wiersz jest obecny, sprawdź export const inject = ['tools']. Wpisy w konfiguracji Cordis uruchamiają się współbieżnie, więc kolejność plików nie decyduje o kolejności ładowania. Bez tej deklaracji Cordis nie czeka na rejestr narzędzi, a Twój apply może zostać uruchomiony w momencie, gdy ctx.tools nie jest jeszcze dostępny do rejestracji.

Jaka jest różnica między cordis.yml a cordis.patch.yml?

cordis.yml to pełna lista wpisów. cordis.patch.yml to warstwa nakładana na listę, celująca w wiersze według identyfikatora w celu wstawienia nowych lub zastąpienia istniejącej konfiguracji. Pakiet wskazuje na własny plik patch poprzez dsh.bundle.patch w package.json. Warstwy nakładają się w ustalonej kolejności: każdy pakiet w kolejności wymienionej w profilu, następnie plik patch profilu, potem $DSH_HOME/cordis.patch.yml, a na końcu dowolna nakładka --patch. Późniejsze warstwy mają pierwszeństwo.

Czy mogę przeładować wtyczkę dsh na gorąco podczas pracy agenta?

Nie w wersji 0.1.0-rc.7, której pakiet web miał wyłączony wiersz współdzielonego przeładowania modułów (hot module reload). W wersji 0.2.0-rc.2 wiersz ten jest montowany w każdym profilu, ale domyślnie przeładowuje tylko konfigurację profilu. Katalogi główne modułów wymagają aktywacji poprzez listę root, więc kod wtyczki nadal wymaga restartu, chyba że go dodasz. W każdym przypadku projektuj z myślą o szybkim restarcie: jeden plik, ładowany przez --patch bez etapu budowania, oraz każda rejestracja wykonana przez ctx, aby nic nie wyciekało z jednego uruchomienia do drugiego. Użyj ctx.effect() z dyspozytorem dla zasobów, których Cordis nie może wyczyścić samodzielnie.