dsh-patch-edit-plus 0.4.6 → 0.4.8

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,63 @@
1
+ # Änderungsprotokoll
2
+
3
+
4
+ ## [0.4.2] — 2026-10-17
5
+
6
+ ### Geändert
7
+
8
+ - **Host-Linie `0.2.1-rc.1` unterstützt.** `engines.dsh`, alle sieben `@deepseek-ai/dsh-*`-Peer-Bereiche und `dsh.plugin.json` zählen jetzt 16 exakte rc-Versionen auf (`0.1.0-rc.2` … `0.2.1-rc.1`) statt des Bereichs `>=0.1.0-rc.8 <0.2.1-0` — seit 0.2.1-alpha.4 urteilt der Kompatibilitätsgate eigenständig über `engines.dsh`, und der alte -0-Obergrenzen-Sentinel lehnte `0.2.1-rc.1` ab.
9
+ - Kompatibilitätsdeklarationen sind überall exakte Aufzählungen: keine offenen Bereiche, ungetestete künftige Hosts werden abgewiesen.
10
+ - devDependencies auf die echte `0.2.1-rc.1`-Peer-Basisline; `npm run typecheck:0.2.1` (vorher `:0.2.0`) belegt diese Basis über saubere Registry-Installationen; die Typecheck-Matrix deckt jetzt sieben Linien inkl. `0.2.1-rc.1` ab.
11
+
12
+ ### Neu
13
+
14
+ - `prepack` führt den Build aus (npm pack kann kein veraltetes `lib/` mehr einschließen); `publishConfig.registry` auf den offiziellen npm-Registry festgenagelt.
15
+
16
+ ## [0.4.0] — 2026-10-09
17
+
18
+ ### Hinzugefügt
19
+
20
+ - **Eine einzige Version für alle Host-Linien.** Eine einzelne Version (0.4.0) bedient alle DSH-Hosts von `0.1.0-rc.8` bis `0.2.0-rc.2` — alle 15 RCs plus Desktop; die Peer-Bereiche enumerieren alle 15 RCs und `engines.dsh` deklariert `>=0.1.0-rc.8`. Die eingestellten compat-Zweige (`compat/0.1.2`, `compat/0.1.5`, `compat/0.1.7`) und das `main`-Aufteilungsschema sind entfernt; nach der Veröffentlichung konvergieren die npm-Dist-Tags `latest`, `dsh-0.2.0`, `dsh-0.1.7`, `dsh-0.1.5` und `dsh-0.1.2` alle auf 0.4.0.
21
+ - **Drei Einstellungs-Generationen in einer Codebasis**: deklaratives `.volatile()` plus Neuregistrierung über `loader/volatile-update` auf 0.1.7+ (und Desktop); Instanz-`settings.installSection`/`register` auf 0.1.2/0.1.5; modulweites `installSettingsSection` aus `@deepseek-ai/dsh-settings` auf 0.1.0/0.1.1. Die Konfigurationskarte auf der Plugin-Seite (Client-Hälfte) hat nur auf 0.1.7+/Desktop einen Platz und fehlt auf älteren Linien elegant.
22
+ - `defineTool`-Authoring-Pfad mit weicher fs-Degradation: Auf Host-Linien, deren `fs` kein write-intent hat, degradieren Schreibvorgänge zu direkten Schreibzugriffen mit genau einem `console.warn`, statt zu fehlschlagen.
23
+ - Typecheck-Matrix über sechs Linien sowie ein Smoke-Gate für die Szenarien der eleganten Abwesenheit.
24
+
25
+ ### Geändert
26
+
27
+ - **Brechend: `allowCodexPatch` hat nun den Standardwert `false`** (Opt-in, an der 0.2.0-Linie ausgerichtet; der alte Standard der 0.1.7-Linie war `true`). Bestehende Benutzer der 0.1.7-Linie müssen ihn nach dem Upgrade auf 0.4.0 manuell aktivieren.
28
+
29
+ ## [0.3.0] — 2026-09-29
30
+
31
+ ### Geändert
32
+
33
+ - **Unterstützung der DSH-0.2.0-Linie (Zweig `compat/0.2.0`).** Die Peer-Bereiche und `engines.dsh` (beide Manifeste) deklarieren nun `>=0.2.0-rc.1 <0.2.1-0`; Version 0.3.0. Die devDependencies pinnen die echte `0.2.0-rc.1`-Typ-Baseline, und das Gegenprüfungsskript wird zu `npm run typecheck:0.2.0` ausgebaut (installiert die echten Peer-Pakete aus der Registry). 0.1.x-Hosts werden weiterhin vom Zweig `compat/0.1.7` / dem Dist-Tag `dsh-0.1.7` bedient.
34
+ - **Delete/Move auf die aktuelle Shell-Executor-API migriert.** Zwischen den Host-Linien 0.1.2 und 0.1.7 wurde `ShellExecutor.run(spec)` in `execute(spec)` umbenannt — mit Rückgabe eines `ShellProcess`-Handles samt `result()`-Foreground-Projektion. Der alte devDependency-Pin (`0.1.2-rc.1`) verschleierte das: Das Paket der 0.1.7-Linie (0.2.1) typecheckte grün gegen eine veraltete Baseline, und zur Laufzeit auf echten 0.1.7+-Hosts griff sein auf `run` basierendes Duck-Typing nie, sodass Delete/Move zum strukturierten UNSUPPORTED-Fehler degradierten. Diese Linie ruft `shell.execute(...)` und erwartet `execution.result()`; der Executor wird über `execute` erkannt.
35
+
36
+ ## [0.1.2] — 2026-09-19
37
+
38
+ ### Behoben
39
+
40
+ - **Der Einstellungsabschnitt wurde nie registriert.** Der Einstellungs-Namespace `patch_edit_plus` enthält einen Unterstrich, den das Namespace-Muster von `dsh-settings` (`^[a-z][a-z0-9-]*$`) ablehnt; `register()` warf daher einen Fehler, bevor irgendetwas persistiert wurde — kein Einstellungseintrag erschien im Panel oder in `~/.dsh/settings.yaml`. Umbenannt in `patch-edit-plus` (keine Migration nötig: der alte Abschnitt konnte nie existieren).
41
+ - **Konfigurationsänderungen aus der Einstellungsschicht erreichten das Werkzeug nie.** Die Hooks `setSource`/`onChange` waren No-ops, und die aufgelöste Konfiguration wurde beim Laden einmalig memoisiert. Das Plugin nutzt nun die aufgelöste Quelle: Jede übernommene Einstellungsänderung (oder der Legacy-`register`-Watch) löst die Konfiguration neu auf und registriert das Werkzeug neu — nachdem die alte Registrierung verworfen wurde, da eine Neuregistrierung über einen bereits lebenden Namen ihn still umbenennt. `allowCodexPatch` und jedes andere Feld lassen sich jetzt über das DSH-Einstellungspanel umschalten und wirken sofort, wobei die Werkzeugbeschreibung (die Liste der akzeptierten Patch-Stile) synchron bleibt; kein Prozessneustart erforderlich. Beim Ablösen des Einstellungsdienstes fällt das Plugin auf den Kompositionseintrag zurück, und die Neubewertung ist idempotent (die gesamte aufgelöste Konfiguration wird verglichen, nicht nur ein Feld).
42
+
43
+ ## [0.1.1] — 2026-09-17
44
+
45
+ ### Behoben
46
+
47
+ - **Jeder Schreibvorgang wurde unter `workspace-write` verweigert.** Das Werkzeug übergab keine `sandboxPolicy` pro Aufruf, daher fiel das durchsetzende Dateisystem auf `ctx.sandboxPolicy.resolve()` ohne Gültigkeitsbereich zurück — die DEPLOYMENT-Workspace-Wurzel (das Startverzeichnis des Servers) statt des Session-cwd. Ein eindeutig innerhalb des Session-Workspaces liegender Pfad scheiterte daher an der Eingrenzung und lieferte `file access denied under workspace-write mode`, selbst in einer `danger-full-access`-Sitzung, in der der Modus nicht einmal gelesen wurde. Die Richtlinie wird jetzt pro Aufruf mit der aufrufenden Sitzung im Gültigkeitsbereich aufgelöst (`resolve({ session })`) und jedem Schreibvorgang sowie jeder Delete/Move-Shell-Anfrage aufgeprägt — genau wie es die nativen `write`/`edit`-Werkzeuge tun. Beide Hälften des Modus werden nun beachtet: die `sandbox/mode`-Übersteuerung der Sitzung und deren cwd als Workspace-Wurzel.
48
+ - Pfadauflösung und Zaun teilen sich nun eine Wurzel: Der Plan löst jedes Ziel gegen die `workspaceRoot` der Richtlinie auf (mit Rückfall auf das Session-cwd), sodass der Pfad, den die Engine schreibt, der Pfad ist, den der Zaun misst.
49
+
50
+ ## Unreleased
51
+
52
+ ### Hinzugefügt
53
+
54
+ - Einziges dem Modell zugängliches Werkzeug `apply_patch`, das git/unified diff (Standard) und die Codex-`apply_patch`-Syntax (Opt-in über `allowCodexPatch`) akzeptiert.
55
+ - Automatische Formaterkennung mit umsetzbarem Hinweis, wenn ein erkannter, aber deaktivierter Stil eintrifft.
56
+ - Operationen Add / Update (multi-hunk) / Delete / Move; Delete und Move laufen über den sandbox-bewussten `ctx.shell`, Pfade werden ausschließlich über Umgebungsvariablen übergeben.
57
+ - Zweiphasige Alles-oder-Nichts-Engine: vollständige Lese-Verifikation (Kontextlokalisierung mit drei Toleranzstufen, Workspace-Eingrenzung, Symlink-Ablehnung, Erkennung doppelter Pfade) vor jedem Schreibvorgang.
58
+ - Offizieller Write-Intent-Ablauf bei jedem Schreibvorgang: `fs/write-intent`-Wasserfall → geschütztes `writeText` → `fs/observed`-Emission, damit die Read-before-Write-Schranke für Patch-Schreibvorgänge gilt.
59
+ - Vier Elemente umfassende Diagnostik bei Hunk-Fehlanpassung (Datei + Hunk-Index, Suchursprung, erwartete Vorschau mit sichtbarem Whitespace, tatsächlicher Auszug) plus gezielter Hinweis.
60
+ - Parameter `dryRun` und Konfiguration `dryRunByDefault`.
61
+ - Gruppierte Ausgabe nach Codex-Semantik (added → modified → deleted) mit je-Datei-Diffs, begrenzt durch `maxDiffBytes`, und replay-sicherem `presentationMeta`.
62
+ - Dreistufiger Schutz vor Werkzeugnamens-Konflikten (`rename` Standard / `skip` / `fail`), sodass Namenskollisionen mit anderen `apply_patch`-Providern den DSH-Start nie brechen.
63
+ - DSH-`0.1.2-rc.1` ~ `0.1.5-rc.2`-Kompatibilität: einzelner Codepfad zur Werkzeigerstellung plus statische Verifikation `typecheck:0.1.5` gegen die 0.1.5-rc.2-Peer-Pakete; Dual-API-Fallback für Einstellungen (`installSection` / `register`).
@@ -0,0 +1,63 @@
1
+ # Registro de cambios
2
+
3
+
4
+ ## [0.4.2] — 2026-10-17
5
+
6
+ ### Cambios
7
+
8
+ - **Línea de host `0.2.1-rc.1` compatible.** `engines.dsh`, los siete rangos de pares `@deepseek-ai/dsh-*` y `dsh.plugin.json` ahora enumeran 16 rc exactos (`0.1.0-rc.2` … `0.2.1-rc.1`) en lugar del rango `>=0.1.0-rc.8 <0.2.1-0` — desde 0.2.1-alpha.4 la puerta de compatibilidad juzga `engines.dsh` de forma independiente, y el viejo centinela `-0` rechazaba `0.2.1-rc.1`.
9
+ - Las declaraciones de compatibilidad son enumeraciones exactas en todos los puntos: sin rangos abiertos; los hosts futuros no probados se rechazan.
10
+ - Las devDependencies pasaron a la línea base real de pares `0.2.1-rc.1`; `npm run typecheck:0.2.1` (antes `:0.2.0`) verifica esa base con instalaciones limpias desde el registry; la matriz de typecheck cubre ahora siete líneas incluida `0.2.1-rc.1`.
11
+
12
+ ### Añadido
13
+
14
+ - `prepack` ejecuta el build (npm pack ya no puede incluir un `lib/` obsoleto); `publishConfig.registry` fijado al registry oficial de npm.
15
+
16
+ ## [0.4.0] — 2026-10-09
17
+
18
+ ### Añadido
19
+
20
+ - **Una única versión para todas las líneas de hosts.** Una sola versión (0.4.0) atiende todos los hosts DSH desde `0.1.0-rc.8` hasta `0.2.0-rc.2` — los 15 rc más desktop; los rangos de peers enumeran los 15 rc y `engines.dsh` declara `>=0.1.0-rc.8`. Las ramas compat retiradas (`compat/0.1.2`, `compat/0.1.5`, `compat/0.1.7`) y el esquema de división por `main` se eliminan; tras la publicación, los dist-tags de npm `latest`, `dsh-0.2.0`, `dsh-0.1.7`, `dsh-0.1.5` y `dsh-0.1.2` convergen todos en 0.4.0.
21
+ - **Tres generaciones de ajustes en una sola base de código**: `.volatile()` declarativo más re-registro vía `loader/volatile-update` en 0.1.7+ (y desktop); `settings.installSection`/`register` de instancia en 0.1.2/0.1.5; `installSettingsSection` a nivel de módulo de `@deepseek-ai/dsh-settings` en 0.1.0/0.1.1. La tarjeta de configuración de la página del plugin (mitad cliente) solo tiene sitio en 0.1.7+/desktop y en las líneas antiguas está ausente con elegancia.
22
+ - Ruta de autoría `defineTool` con degradación suave del fs: en las líneas cuyo `fs` carece de write-intent, las escrituras degradan a escritura directa con un único `console.warn` en lugar de fallar.
23
+ - Matriz de typecheck de seis líneas, más una compuerta de smoke que cubre los escenarios de ausencia elegante.
24
+
25
+ ### Cambiado
26
+
27
+ - **Ruptura: `allowCodexPatch` ahora es `false` por defecto** (opt-in, alineado con la línea 0.2.0; el antiguo valor por defecto de la línea 0.1.7 era `true`). Los usuarios existentes de la línea 0.1.7 deben activarlo manualmente tras actualizar a 0.4.0.
28
+
29
+ ## [0.3.0] — 2026-09-29
30
+
31
+ ### Cambiado
32
+
33
+ - **Soporte de la línea DSH 0.2.0 (rama `compat/0.2.0`).** Los rangos de peers y `engines.dsh` (ambos manifiestos) ahora declaran `>=0.2.0-rc.1 <0.2.1-0`; versión 0.3.0. Las devDependencies fijan la línea base de tipos real `0.2.0-rc.1`, y el script de verificación cruzada pasa a ser `npm run typecheck:0.2.0` (instala los paquetes peer reales desde el registry). Los hosts 0.1.x siguen siendo atendidos por la rama `compat/0.1.7` / el dist-tag `dsh-0.1.7`.
34
+ - **Delete/Move migrados a la API actual del ejecutor de shell.** Entre las líneas de host 0.1.2 y 0.1.7, `ShellExecutor.run(spec)` fue renombrado a `execute(spec)` — devolviendo un manejador `ShellProcess` con una proyección de primer plano `result()`. El pin antiguo de devDependency (`0.1.2-rc.1`) lo enmascaraba: el paquete de la línea 0.1.7 (0.2.1) pasaba la comprobación de tipos contra una línea base obsoleta, y en ejecución sobre hosts 0.1.7+ reales su duck-typing basado en `run` nunca coincidía, de modo que Delete/Move se degradaban al error estructurado UNSUPPORTED. Esta línea llama a `shell.execute(...)` y espera `execution.result()`; el ejecutor se detecta mediante `execute`.
35
+
36
+ ## [0.1.2] — 2026-09-19
37
+
38
+ ### Corregido
39
+
40
+ - **La sección de ajustes nunca llegó a registrarse.** El espacio de nombres de ajustes `patch_edit_plus` contiene un guion bajo, que el patrón de espacios de nombres de `dsh-settings` (`^[a-z][a-z0-9-]*$`) rechaza, así que `register()` lanzaba una excepción antes de que nada se persistiera — no aparecía ninguna entrada de ajustes en el panel ni en `~/.dsh/settings.yaml`. Renombrado a `patch-edit-plus` (sin migración necesaria: la sección antigua nunca pudo existir).
41
+ - **Los cambios de configuración de la capa de ajustes nunca llegaban a la herramienta.** Los hooks `setSource`/`onChange` eran no-ops y la configuración resuelta se memoizaba una sola vez al cargar. El plugin ahora consume la fuente resuelta: cada cambio de ajustes confirmado (o el watch heredado de `register`) vuelve a resolver la configuración y vuelve a registrar la herramienta — eliminando antes el registro antiguo, porque registrar de nuevo sobre un nombre ya vivo lo renombra silenciosamente. `allowCodexPatch` y todos los demás campos ya se pueden conmutar desde el panel de ajustes de DSH y surten efecto de inmediato, con la descripción de la herramienta (la lista de estilos de parche aceptados) manteniéndose sincronizada; sin necesidad de reiniciar el proceso. Al desacoplar el servicio de ajustes se vuelve a la entrada de composición, y el rejuicio es idempotente (se compara toda la configuración resuelta, no solo un campo).
42
+
43
+ ## [0.1.1] — 2026-09-17
44
+
45
+ ### Corregido
46
+
47
+ - **Cada escritura era denegada bajo `workspace-write`.** La herramienta no pasaba ninguna `sandboxPolicy` por llamada, así que el sistema de archivos que hace cumplir la política retrocedía a `ctx.sandboxPolicy.resolve()` sin ámbito — la raíz del workspace de DESPLIEGUE (el directorio de arranque del servidor) en lugar del cwd de la sesión. Una ruta claramente dentro del workspace de la sesión fallaba por tanto la prueba de contención y devolvía `file access denied under workspace-write mode`, incluso en una sesión `danger-full-access`, donde el modo ni siquiera se leía. La política ahora se resuelve por llamada con la sesión llamante en el ámbito (`resolve({ session })`) y se estampa en cada escritura y en cada petición de shell de Delete/Move, exactamente como lo hacen las herramientas nativas `write`/`edit`. Ahora se honran ambas mitades del modo: la anulación `sandbox/mode` de la sesión y su cwd como raíz del workspace.
48
+ - La resolución de rutas y la valla ahora comparten una misma raíz: el plan resuelve cada objetivo contra el `workspaceRoot` de la política (con retroceso al cwd de la sesión), de modo que la ruta que escribe el motor es la ruta que mide la valla.
49
+
50
+ ## Unreleased
51
+
52
+ ### Añadido
53
+
54
+ - Única herramienta `apply_patch` expuesta al modelo, que acepta diff git/unificado (por defecto) y la sintaxis `apply_patch` de Codex (opcional mediante `allowCodexPatch`).
55
+ - Detección automática de formato con una pista accionable cuando llega un estilo reconocido pero desactivado.
56
+ - Operaciones Add / Update (multi-hunk) / Delete / Move; Delete y Move pasan por el `ctx.shell` consciente de la sandbox, con las rutas pasadas únicamente por variables de entorno.
57
+ - Motor de dos fases todo-o-nada: verificación completa en solo lectura (localización del contexto con tres niveles de tolerancia, contención del workspace, rechazo de symlinks, detección de rutas duplicadas) antes de cualquier escritura.
58
+ - Secuencia oficial de write-intent en cada escritura: cascada `fs/write-intent` → `writeText` protegido → emisión `fs/observed`, de modo que la barrera de leer-antes-de-escribir se aplica a las escrituras de parches.
59
+ - Diagnóstico de cuatro elementos para hunks que no coinciden (archivo + índice del hunk, origen de la búsqueda, vista previa esperada con espacios visibles, extracto real) más una pista concreta.
60
+ - Parámetro `dryRun` y configuración `dryRunByDefault`.
61
+ - Salida agrupada con semántica Codex (added → modified → deleted), con diffs por archivo limitados por `maxDiffBytes` y `presentationMeta` seguro para el replay.
62
+ - Protección de tres niveles frente a conflictos de nombres de herramientas (`rename` por defecto / `skip` / `fail`), de modo que las colisiones con otros proveedores de `apply_patch` nunca rompan el arranque de DSH.
63
+ - Compatibilidad con DSH `0.1.2-rc.1` ~ `0.1.5-rc.2`: ruta de código única de autoría de herramientas más verificación estática `typecheck:0.1.5` contra los paquetes peer 0.1.5-rc.2; fallback de doble API para ajustes (`installSection` / `register`).
@@ -0,0 +1,63 @@
1
+ # Journal des modifications
2
+
3
+
4
+ ## [0.4.2] — 2026-10-17
5
+
6
+ ### Changements
7
+
8
+ - **Ligne hôte `0.2.1-rc.1` prise en charge.** `engines.dsh`, les sept plages de pairs `@deepseek-ai/dsh-*` et `dsh.plugin.json` énumèrent désormais 16 versions rc exactes (`0.1.0-rc.2` … `0.2.1-rc.1`) au lieu de la plage `>=0.1.0-rc.8 <0.2.1-0` — depuis 0.2.1-alpha.4 la porte de compatibilité juge `engines.dsh` séparément, et le sentinel supérieur `-0` rejetait `0.2.1-rc.1`.
9
+ - Les déclarations de compatibilité sont partout des énumérations exactes : pas d'intervalles ouverts, les hôtes futurs non testés sont refusés.
10
+ - Les devDependencies passent à la vraie base de pairs `0.2.1-rc.1` ; `npm run typecheck:0.2.1` (ex `:0.2.0`) prouve cette base via des installations propres depuis le registry ; la matrice de typecheck couvre désormais sept lignes dont `0.2.1-rc.1`.
11
+
12
+ ### Ajouts
13
+
14
+ - `prepack` exécute le build (npm pack ne peut plus embarquer un `lib/` périmé) ; `publishConfig.registry` épinglé sur le registry npm officiel.
15
+
16
+ ## [0.4.0] — 2026-10-09
17
+
18
+ ### Ajouté
19
+
20
+ - **Une version unique pour toutes les lignes d'hôtes.** Une seule version (0.4.0) sert tous les hôtes DSH de `0.1.0-rc.8` à `0.2.0-rc.2` — les 15 rc plus desktop ; les plages de pairs énumèrent les 15 rc et `engines.dsh` déclare `>=0.1.0-rc.8`. Les branches compat retirées (`compat/0.1.2`, `compat/0.1.5`, `compat/0.1.7`) et le schéma de scission `main` sont supprimés ; après publication, les dist-tags npm `latest`, `dsh-0.2.0`, `dsh-0.1.7`, `dsh-0.1.5` et `dsh-0.1.2` convergent tous vers 0.4.0.
21
+ - **Trois générations de paramètres dans une seule base de code** : `.volatile()` déclaratif plus réenregistrement via `loader/volatile-update` sur 0.1.7+ (et desktop) ; `settings.installSection`/`register` d'instance sur 0.1.2/0.1.5 ; `installSettingsSection` au niveau module de `@deepseek-ai/dsh-settings` sur 0.1.0/0.1.1. La carte de configuration de la page du plugin (moitié client) n'a sa place que sur 0.1.7+/desktop et est absente avec élégance sur les anciennes lignes.
22
+ - Chemin d'écriture `defineTool` avec dégradation logicielle du fs : sur les lignes dont le `fs` est dépourvu de write-intent, les écritures dégradent en écriture directe avec un seul `console.warn` au lieu d'échouer.
23
+ - Matrice de typecheck sur six lignes, plus un garde-fou de smoke couvrant les scénarios d'absence élégante.
24
+
25
+ ### Modifié
26
+
27
+ - **Rupture : `allowCodexPatch` est désormais `false` par défaut** (opt-in, aligné sur la ligne 0.2.0 ; l'ancien défaut de la ligne 0.1.7 était `true`). Les utilisateurs existants de la ligne 0.1.7 doivent l'activer manuellement après la mise à niveau vers 0.4.0.
28
+
29
+ ## [0.3.0] — 2026-09-29
30
+
31
+ ### Modifié
32
+
33
+ - **Prise en charge de la ligne DSH 0.2.0 (branche `compat/0.2.0`).** Les plages de pairs et `engines.dsh` (les deux manifestes) déclarent désormais `>=0.2.0-rc.1 <0.2.1-0` ; version 0.3.0. Les devDependencies épinglent la vraie baseline de types `0.2.0-rc.1`, et le script de contre-vérification devient `npm run typecheck:0.2.0` (installe les vrais paquets pairs depuis le registry). Les hôtes 0.1.x restent servis par la branche `compat/0.1.7` / le dist-tag `dsh-0.1.7`.
34
+ - **Delete/Move migrés vers l'API actuelle de l'exécuteur shell.** `ShellExecutor.run(spec)` a été renommé `execute(spec)` — renvoyant un handle `ShellProcess` avec une projection de premier plan `result()` — entre les lignes d'hôte 0.1.2 et 0.1.7. L'ancien pin de devDependency (`0.1.2-rc.1`) masquait cela : le paquet de la ligne 0.1.7 (0.2.1) passait la vérification de types sur une baseline périmée, et à l'exécution sur de vrais hôtes 0.1.7+ son duck-typing fondé sur `run` ne correspondait jamais, si bien que Delete/Move dégradaient en erreur structurée UNSUPPORTED. Cette ligne appelle `shell.execute(...)` et attend `execution.result()` ; l'exécuteur est détecté via `execute`.
35
+
36
+ ## [0.1.2] — 2026-09-19
37
+
38
+ ### Corrigé
39
+
40
+ - **La section de paramètres n'a jamais été enregistrée.** L'espace de noms des paramètres `patch_edit_plus` contient un underscore, que le motif d'espace de noms de `dsh-settings` (`^[a-z][a-z0-9-]*$`) rejette ; `register()` levait donc une exception avant toute persistance — aucune entrée de paramètres n'apparaissait dans le panneau ni dans `~/.dsh/settings.yaml`. Renommé en `patch-edit-plus` (aucune migration nécessaire : l'ancienne section n'a jamais pu exister).
41
+ - **Les changements de configuration venant de la couche de paramètres n'atteignaient jamais l'outil.** Les hooks `setSource`/`onChange` étaient des no-op et la config résolue était mémorisée une seule fois au chargement. Le plugin consomme désormais la source résolue : chaque changement de paramètres validé (ou watch `register` hérité) résout à nouveau la config et réenregistre l'outil — en disposant d'abord l'ancien enregistrement, car réenregistrer sur un nom déjà vivant le renomme silencieusement. `allowCodexPatch` et tous les autres champs peuvent maintenant être basculés depuis le panneau de paramètres DSH et prennent effet immédiatement, la description de l'outil (la liste des styles de patch acceptés) restant synchronisée ; aucun redémarrage du processus requis. Le détachement du service de paramètres retombe sur l'entrée de composition, et le rejugement est idempotent (c'est toute la config résolue qui est comparée, pas un seul champ).
42
+
43
+ ## [0.1.1] — 2026-09-17
44
+
45
+ ### Corrigé
46
+
47
+ - **Chaque écriture était refusée sous `workspace-write`.** L'outil ne transmettait pas de `sandboxPolicy` par appel ; le système de fichiers contraignant retombait donc sur `ctx.sandboxPolicy.resolve()` sans portée — la racine d'espace de travail de DÉPLOIEMENT (le répertoire de lancement du serveur) au lieu du cwd de la session. Un chemin pourtant situé dans l'espace de travail de la session échouait donc au test de confinement avec `file access denied under workspace-write mode`, même dans une session `danger-full-access`, où le mode n'était même pas lu. La politique est désormais résolue à chaque appel avec la session appelante en portée (`resolve({ session })`) et apposée sur chaque écriture et chaque requête shell Delete/Move, exactement comme le font les outils natifs `write`/`edit`. Les deux moitiés du mode sont honorées : la surcharge `sandbox/mode` de la session et son cwd comme racine d'espace de travail.
48
+ - La résolution des chemins et la clôture partagent désormais une même racine : le plan résout chaque cible par rapport au `workspaceRoot` de la politique (avec repli sur le cwd de la session), si bien que le chemin écrit par le moteur est celui que mesure la clôture.
49
+
50
+ ## Unreleased
51
+
52
+ ### Ajouté
53
+
54
+ - Unique outil `apply_patch` exposé au modèle, acceptant le diff git/unifié (par défaut) et la syntaxe `apply_patch` de Codex (opt-in via `allowCodexPatch`).
55
+ - Détection automatique du format, avec une aide actionnable quand arrive un style reconnu mais désactivé.
56
+ - Opérations Add / Update (multi-hunks) / Delete / Move ; Delete et Move passent par le `ctx.shell` conscient de la sandbox, les chemins n'étant transmis que via des variables d'environnement.
57
+ - Moteur en deux phases tout-ou-rien : vérification complète en lecture seule (localisation du contexte à trois niveaux de tolérance, confinement de l'espace de travail, rejet des symlinks, détection des chemins dupliqués) avant toute écriture.
58
+ - Séquence d'intent en écriture officielle à chaque écriture : cascade `fs/write-intent` → `writeText` gardé → émission `fs/observed`, afin que le verrou lecture-avant-écriture s'applique aux écritures de patch.
59
+ - Diagnostics de hunk non correspondant à quatre éléments (fichier + index du hunk, origine de recherche, aperçu attendu avec espaces visibles, extrait réel), plus une indication ciblée.
60
+ - Paramètre `dryRun` et config `dryRunByDefault`.
61
+ - Sortie groupée à la sémantique Codex (added → modified → deleted), avec diffs par fichier plafonnés par `maxDiffBytes` et `presentationMeta` sûr pour le replay.
62
+ - Protection à trois niveaux contre les conflits de noms d'outils (`rename` par défaut / `skip` / `fail`), afin que les collisions avec d'autres fournisseurs d'`apply_patch` ne cassent jamais le démarrage de DSH.
63
+ - Compatibilité DSH `0.1.2-rc.1` ~ `0.1.5-rc.2` : chemin de code unique d'écriture d'outils, plus vérification statique `typecheck:0.1.5` contre les paquets pairs 0.1.5-rc.2 ; repli bi-API des paramètres (`installSection` / `register`).
@@ -0,0 +1,63 @@
1
+ # Registro delle modifiche
2
+
3
+
4
+ ## [0.4.2] — 2026-10-17
5
+
6
+ ### Modifiche
7
+
8
+ - **Linea host `0.2.1-rc.1` supportata.** `engines.dsh`, tutti e sette gli intervalli peer `@deepseek-ai/dsh-*` e `dsh.plugin.json` ora enumerano 16 rc esatte (`0.1.0-rc.2` … `0.2.1-rc.1`) invece dell'intervallo `>=0.1.0-rc.8 <0.2.1-0` — dalla 0.2.1-alpha.4 il gate di compatibilità giudica `engines.dsh` in modo autonomo, e il vecchio sentinel `-0` rifiutava `0.2.1-rc.1`.
9
+ - Le dichiarazioni di compatibilità sono ovunque enumerazioni esatte: nessun intervallo aperto, gli host futuri non testati sono rifiutati.
10
+ - devDependencies portate alla vera linea di base peer `0.2.1-rc.1`; `npm run typecheck:0.2.1` (ex `:0.2.0`) dimostra tale base con installazioni pulite dal registry; la matrice typecheck copre ora sette linee inclusa `0.2.1-rc.1`.
11
+
12
+ ### Aggiunte
13
+
14
+ - `prepack` esegue la build (npm pack non può più includere `lib/` obsoleta); `publishConfig.registry` fissato al registry npm ufficiale.
15
+
16
+ ## [0.4.0] — 2026-10-09
17
+
18
+ ### Aggiunto
19
+
20
+ - **Una singola versione per tutte le linee di host.** Una sola versione (0.4.0) serve tutti gli host DSH da `0.1.0-rc.8` a `0.2.0-rc.2` — tutti i 15 rc più desktop; gli intervalli dei peer enumerano tutti i 15 rc e `engines.dsh` dichiara `>=0.1.0-rc.8`. I rami compat ritirati (`compat/0.1.2`, `compat/0.1.5`, `compat/0.1.7`) e lo schema di biforcazione `main` sono rimossi; dopo la pubblicazione, i dist-tag npm `latest`, `dsh-0.2.0`, `dsh-0.1.7`, `dsh-0.1.5` e `dsh-0.1.2` convergono tutti su 0.4.0.
21
+ - **Tre generazioni di impostazioni in un'unica codebase**: `.volatile()` dichiarativo più ri-registrazione via `loader/volatile-update` su 0.1.7+ (e desktop); `settings.installSection`/`register` di istanza su 0.1.2/0.1.5; `installSettingsSection` a livello di modulo da `@deepseek-ai/dsh-settings` su 0.1.0/0.1.1. La scheda di configurazione nella pagina del plugin (metà client) ha un posto solo su 0.1.7+/desktop ed è assente con eleganza sulle linee precedenti.
22
+ - Percorso di authoring `defineTool` con degradazione morbida del fs: sulle linee il cui `fs` è privo di write-intent, le scritture degradano a scrittura diretta con un solo `console.warn` invece di fallire.
23
+ - Matrice di typecheck su sei linee, più un gate di smoke che copre gli scenari di assenza elegante.
24
+
25
+ ### Modificato
26
+
27
+ - **Rottura: `allowCodexPatch` ora è `false` per impostazione predefinita** (opt-in, allineato alla linea 0.2.0; il vecchio predefinito della linea 0.1.7 era `true`). Gli utenti esistenti della linea 0.1.7 devono attivarlo manualmente dopo l'aggiornamento a 0.4.0.
28
+
29
+ ## [0.3.0] — 2026-09-29
30
+
31
+ ### Modificato
32
+
33
+ - **Supporto della linea DSH 0.2.0 (ramo `compat/0.2.0`).** Gli intervalli dei peer e `engines.dsh` (entrambi i manifest) ora dichiarano `>=0.2.0-rc.1 <0.2.1-0`; versione 0.3.0. Le devDependencies fissano la vera baseline di tipi `0.2.0-rc.1`, e lo script di controverifica diventa `npm run typecheck:0.2.0` (installa i veri pacchetti peer dal registry). Gli host 0.1.x restano serviti dal ramo `compat/0.1.7` / dal dist-tag `dsh-0.1.7`.
34
+ - **Delete/Move migrati all'API attuale dell'esecutore shell.** Tra le linee host 0.1.2 e 0.1.7 `ShellExecutor.run(spec)` è stato rinominato `execute(spec)` — con restituzione di un handle `ShellProcess` e una proiezione in primo piano `result()`. Il vecchio pin della devDependency (`0.1.2-rc.1`) mascherava la cosa: il pacchetto della linea 0.1.7 (0.2.1) superava il typecheck contro una baseline superata, e a runtime sui veri host 0.1.7+ il suo duck-typing basato su `run` non corrispondeva mai, così Delete/Move degradavano all'errore strutturato UNSUPPORTED. Questa linea chiama `shell.execute(...)` e attende `execution.result()`; l'esecutore viene rilevato tramite `execute`.
35
+
36
+ ## [0.1.2] — 2026-09-19
37
+
38
+ ### Corretto
39
+
40
+ - **La sezione delle impostazioni non è mai stata registrata.** Il namespace delle impostazioni `patch_edit_plus` contiene un underscore, che il pattern dei namespace di `dsh-settings` (`^[a-z][a-z0-9-]*$`) rifiuta; quindi `register()` lanciava un'eccezione prima che qualsiasi cosa venisse persistita — nessuna voce delle impostazioni compariva nel pannello né in `~/.dsh/settings.yaml`. Rinominato in `patch-edit-plus` (nessuna migrazione necessaria: la vecchia sezione non poté mai esistere).
41
+ - **Le modifiche di configurazione provenienti dal livello delle impostazioni non raggiungevano mai lo strumento.** Gli hook `setSource`/`onChange` erano no-op e la configurazione risolta veniva memoizzata una sola volta al caricamento. Il plugin ora consuma la sorgente risolta: ogni modifica alle impostazioni confermata (o il watch `register` legacy) risolve nuovamente la configurazione e registra di nuovo lo strumento — eliminando prima la registrazione precedente, poiché registrarsi di nuovo su un nome già attivo lo rinomina silenziosamente. `allowCodexPatch` e ogni altro campo ora possono essere commutati dal pannello delle impostazioni DSH e hanno effetto immediato, con la descrizione dello strumento (l'elenco degli stili di patch accettati) che resta sincronizzata; nessun riavvio del processo richiesto. Lo scollegamento del servizio delle impostazioni ricade sulla voce di composizione, e il nuovo giudizio è idempotente (viene confrontata l'intera configurazione risolta, non un solo campo).
42
+
43
+ ## [0.1.1] — 2026-09-17
44
+
45
+ ### Corretto
46
+
47
+ - **Ogni scrittura veniva negata sotto `workspace-write`.** Lo strumento non passava alcuna `sandboxPolicy` per chiamata, quindi il filesystem di applicazione ricadeva su `ctx.sandboxPolicy.resolve()` senza ambito — la radice del workspace di DEPLOYMENT (la directory di avvio del server) invece del cwd della sessione. Un percorso chiaramente interno al workspace della sessione falliva quindi il test di contenimento con `file access denied under workspace-write mode`, persino in una sessione `danger-full-access`, dove la modalità non veniva nemmeno letta. La politica ora viene risolta a ogni chiamata con la sessione chiamante nell'ambito (`resolve({ session })`) e applicata a ogni scrittura e a ogni richiesta shell Delete/Move, esattamente come fanno gli strumenti nativi `write`/`edit`. Ora sono onorate entrambe le metà della modalità: l'override `sandbox/mode` della sessione e il suo cwd come radice del workspace.
48
+ - La risoluzione dei percorsi e la recinzione ora condividono una sola radice: il piano risolve ogni bersaglio rispetto al `workspaceRoot` della politica (ricadendo sul cwd della sessione), così il percorso che il motore scrive è il percorso che la recinzione misura.
49
+
50
+ ## Unreleased
51
+
52
+ ### Aggiunto
53
+
54
+ - Unico strumento `apply_patch` esposto al modello, che accetta diff git/unificati (predefinito) e la sintassi `apply_patch` di Codex (opt-in tramite `allowCodexPatch`).
55
+ - Rilevamento automatico del formato con un suggerimento azionabile quando arriva uno stile riconosciuto ma disabilitato.
56
+ - Operazioni Add / Update (multi-hunk) / Delete / Move; Delete e Move passano attraverso `ctx.shell`, consapevole della sandbox, con i percorsi passati solo tramite variabili d'ambiente.
57
+ - Motore a due fasi tutto-o-nulla: verifica completa in sola lettura (localizzazione del contesto con tre livelli di tolleranza, contenimento del workspace, rifiuto dei symlink, rilevamento dei percorsi duplicati) prima di qualsiasi scrittura.
58
+ - Sequenza ufficiale di write-intent su ogni scrittura: cascata `fs/write-intent` → `writeText` protetto → emissione `fs/observed`, così che il cancello leggi-prima-di-scrivere si applichi alle scritture delle patch.
59
+ - Diagnostica a quattro elementi per gli hunk non corrispondenti (file + indice dell'hunk, origine della ricerca, anteprima attesa con spazi visibili, estratto reale) più un suggerimento mirato.
60
+ - Parametro `dryRun` e configurazione `dryRunByDefault`.
61
+ - Uscita raggruppata con semantica Codex (added → modified → deleted), con diff per file limitati da `maxDiffBytes` e `presentationMeta` replay-safe.
62
+ - Protezione a tre livelli dai conflitti di nomi degli strumenti (`rename` predefinito / `skip` / `fail`), così che le collisioni con altri provider di `apply_patch` non rompano mai l'avvio di DSH.
63
+ - Compatibilità DSH `0.1.2-rc.1` ~ `0.1.5-rc.2`: singolo percorso di codice per la creazione degli strumenti più verifica statica `typecheck:0.1.5` contro i pacchetti peer 0.1.5-rc.2; fallback dual-API delle impostazioni (`installSection` / `register`).
@@ -0,0 +1,68 @@
1
+ # 変更履歴
2
+
3
+
4
+
5
+ ## [0.4.2] — 2026-10-17
6
+
7
+ ### 変更
8
+
9
+ - **ホストライン `0.2.1-rc.1` に対応。** `engines.dsh`、7 個の `@deepseek-ai/dsh-*` peer 範囲および `dsh.plugin.json` を `>=0.1.0-rc.8 <0.2.1-0` のレンジから 16 個の正確な rc 列挙(`0.1.0-rc.2` … `0.2.1-rc.1`)に変更——0.2.1-alpha.4 以降互換ゲートは `engines.dsh` を単独で判定するため、旧 `-0` 上限センチネルは `0.2.1-rc.1` を拒否していました。
10
+ - 互換宣言はすべて正確な列挙:开区間なし、未テストの将来ホストは拒否。
11
+ - devDependencies を実 `0.2.1-rc.1` peer ベースラインに更新;`npm run typecheck:0.2.1`(旧 `:0.2.0`)がクリーンインストールで同ベースラインを検証;型チェックマトリクスは `0.2.1-rc.1` を含む 7 ラインに拡張。
12
+
13
+ ### 追加
14
+
15
+ - `prepack` がビルドを実行(npm pack が古い `lib/` を同梱するのを防止);`publishConfig.registry` を公式 npm registry に固定。
16
+
17
+ ## [0.4.0] — 2026-10-09
18
+
19
+ ### 追加
20
+
21
+ - **全ホストラインを 1 つのバージョンでカバー。** 1 つのバージョン(0.4.0)が `0.1.0-rc.8` から `0.2.0-rc.2` までのすべての DSH ホスト——15 個の rc 全部 + desktop——を担当します。peer 範囲は 15 rc をすべて列挙し、`engines.dsh` は `>=0.1.0-rc.8` を宣言。退役した compat ブランチ(`compat/0.1.2`、`compat/0.1.5`、`compat/0.1.7`)と `main` 分割スキームは撤去されました。公開後、npm dist-tag の `latest`、`dsh-0.2.0`、`dsh-0.1.7`、`dsh-0.1.5`、`dsh-0.1.2` はすべて 0.4.0 に収束します。
22
+ - **1 つのコードベースで 3 世代の設定面をカバー**:0.1.7+(および desktop)は宣言的 `.volatile()` + `loader/volatile-update` 再登録。0.1.2/0.1.5 はインスタンスの `settings.installSection`/`register`。0.1.0/0.1.1 は `@deepseek-ai/dsh-settings` のモジュールレベル `installSettingsSection`。プラグインページの設定カード(client 側)は 0.1.7+/desktop のみに席があり、旧ラインでは適切に省かれます。
23
+ - `defineTool` オーサリングパスと fs ソフト低下:ホストの `fs` に write-intent がないラインでは、書き込みは失敗せず直接書き込みへ自動低下し、`console.warn` を 1 回だけ出力します。
24
+ - 6 ラインの typecheck マトリクスと、縮退シナリオをカバーする smoke ゲート。
25
+
26
+ ### 変更
27
+
28
+ - **破壊的変更:`allowCodexPatch` の既定値は `false` になりました**(オプトイン、0.2.0 ラインに合わせました。旧 0.1.7 ラインの既定は `true`)。既存の 0.1.7 ライン ユーザーは 0.4.0 へのアップグレード後、手動で有効にする必要があります。
29
+
30
+ ## [0.3.1] — 2026-10-01
31
+
32
+ ### 修正
33
+ - **ヘッダーなしの複数ファイル unified diff が 1 つのファイル section に潰されていた**(0.1.7 ラインの 0.2.5 で修正したのと同じ欠陥):`diff --git` 区切りがない場合、2 番目のファイルの `--- `/`+++ ` ヘッダーが前の section のパスを上書きし、その hunk が誤った内容に照合されて最初のファイル以降の全 section が `the context does not match the file` で失敗。現在の section が占有済みなら `--- ` が新 section を開くように。パーサー層とエンドツーエンドの回帰テスト追加。
34
+ ## [0.3.0] — 2026-09-29
35
+
36
+ ### 変更
37
+
38
+ - **DSH 0.2.0 ライン対応(`compat/0.2.0` ブランチ)。** peer 範囲と両マニフェストの `engines.dsh` を `>=0.2.0-rc.1 <0.2.1-0` に更新、バージョンは 0.3.0。devDependencies は実際の `0.2.0-rc.1` 型ベースラインに固定し、クロスチェックスクリプトを `npm run typecheck:0.2.0` に拡張しました(registry から実際のピアパッケージをインストールして検証)。0.1.x ホストは引き続き `compat/0.1.7` ブランチ / `dsh-0.1.7` dist-tag が担当します。
39
+ - **Delete/Move を現行のシェル実行器 API に移行。** ホストは 0.1.2 → 0.1.7 ラインの間に `ShellExecutor.run(spec)` を `execute(spec)` に改名しました(`ShellProcess` ハンドルを返し、フォアグラウンド結果は `result()` で取得)。旧 devDependency の固定(`0.1.2-rc.1`)がこれを覆い隠していました: 0.1.7 ラインのパッケージ(0.2.1)は古いベースラインに対してグリーンに見え、実際の 0.1.7+ ホスト上では `run` ベースのダックタイピングが決して一致せず、Delete/Move は構造化 UNSUPPORTED エラーに退化していました。本ラインでは `shell.execute(...)` を呼び、`execution.result()` を待つ方式に変更し、実行器は `execute` で構造検出します。
40
+
41
+ ## [0.1.2] — 2026-09-19
42
+
43
+ ### 修正
44
+
45
+ - **設定セクションが一度も登録されていませんでした。** settings 名前空間 `patch_edit_plus` はアンダースコアを含むため、`dsh-settings` の名前空間パターン(`^[a-z][a-z0-9-]*$`)に拒否され、`register()` は検証の時点でスローしていました。パネルにも `~/.dsh/settings.yaml` にも設定セクションは現れません。`patch-edit-plus` に改名しました(移行は不要です。旧セクションは存在し得なかったため)。
46
+ - **設定レイヤーからの設定変更がツールに届いていませんでした。** `setSource`/`onChange` フックは空実装で、解決済み設定はロード時に一度固定化されていました。プラグインは解決済みソースを実際に消費するようになりました: 設定のコミットごと(または旧 `register` の watch)に設定を再解決し、ツールを再登録します。まず旧登録を破棄してから再登録するため、ライブな名前への再登録で静かに改名されることはありません。`allowCodexPatch` を含むすべてのフィールドを DSH 設定パネルから変更でき、即座に反映されます。ツールの説明(利用可能なパッチ構文の一覧)も同期し、プロセスの再起動は不要です。settings サービスのデタッチ時は composition エントリにフォールバックし、再判定は冪等です(解決済み設定全体を比較)。
47
+
48
+ ## [0.1.1] — 2026-09-17
49
+
50
+ ### 修正
51
+
52
+ - **`workspace-write` 下ですべての書き込みが拒否されていました。** ツールが呼び出し単位の `sandboxPolicy` を渡していなかったため、強制実行するファイルシステムはスコープなしの `ctx.sandboxPolicy.resolve()` にフォールバックし、**デプロイメント**のワークスペースルート(サーバーの起動ディレクトリ)をセッション cwd の代わりに取得していました。そのため、セッションのワークスペース内に明らかにあるパスが内包チェックを通らず、`danger-full-access` セッションであっても `file access denied under workspace-write mode` を返していました(そのモードはそもそも読まれてもいませんでした)。ポリシーは呼び出しごとに呼び出し元セッションをスコープとして解決され(`resolve({ session })`)、すべての書き込みとすべての Delete/Move の shell リクエストに付与されます。ネイティブの `write`/`edit` ツールとまったく同じです。モードの両方の側面が有効になりました: セッションの `sandbox/mode` オーバーライドと、ワークスペースルートとしてのセッション cwd です。
53
+ - パス解決とフェンスが単一のルートを共有するようになりました: プランはすべてのターゲットをポリシーの `workspaceRoot`(セッション cwd へのフォールバックあり)に対して解決するため、エンジンが書き込むパスはフェンスが測定するパスと一致します。
54
+
55
+ ## 未リリース
56
+
57
+ ### 追加
58
+
59
+ - git/unified diff(既定)と Codex `apply_patch` 構文(`allowCodexPatch` によるオプトイン)を受け付ける、単一のモデル公開ツール `apply_patch`。
60
+ - 形式の自動検出。認識済みだが無効化されているスタイルが届いた場合は、実行可能なヒントを返します。
61
+ - 追加 / 更新(マルチハンク)/ 削除 / 移動の各操作。削除と移動はサンドボックス対応の `ctx.shell` を通じて実行され、パスは環境変数のみで渡されます。
62
+ - オール・オア・ナッシングの二段階エンジン: 書き込み前に完全な読み取り専用検証(3 段階の許容度によるコンテキスト位置特定、ワークスペース内包、シンボリックリンク拒否、重複パス検出)を実施します。
63
+ - すべての書き込みにおける公式の write-intent dance: `fs/write-intent` ウォーターフォール → ガード付き `writeText` → `fs/observed` 発火。これにより read-before-write ゲートがパッチ書き込みにも適用されます。
64
+ - ハンク不一致時の四要素診断(ファイル + ハンクインデックス、検索開始位置、空白を可視化した期待プレビュー、実際の抜粋)と的を絞ったヒント。
65
+ - `dryRun` パラメータと `dryRunByDefault` 設定。
66
+ - Codex セマンティクスに基づくグループ化出力(追加 → 変更 → 削除)。ファイル単位の diff は `maxDiffBytes` で上限が設けられ、リプレイ可能な `presentationMeta` を備えます。
67
+ - 三層のツール名競合保護(既定は `rename` / `skip` / `fail`)。他の `apply_patch` 提供元との名前衝突が DSH の起動を壊すことはありません。
68
+ - DSH `0.1.2-rc.1` 〜 `0.1.5-rc.2` の互換性: 単一のツールオーサリングコードパスに加え、0.1.5-rc.2 のピアパッケージに対する `typecheck:0.1.5` の静的検証。設定のデュアル API フォールバック(`installSection` / `register`)。
@@ -0,0 +1,68 @@
1
+ # 변경 이력
2
+
3
+
4
+
5
+ ## [0.4.2] — 2026-10-17
6
+
7
+ ### 변경
8
+
9
+ - **호스트 라인 `0.2.1-rc.1` 지원.** `engines.dsh`, 7개의 `@deepseek-ai/dsh-*` peer 범위, `dsh.plugin.json`을 `>=0.1.0-rc.8 <0.2.1-0` 구간에서 16개 정확한 rc 열거(`0.1.0-rc.2` … `0.2.1-rc.1`)로 전환 — 0.2.1-alpha.4부터 호환 게이트가 `engines.dsh`를 단독 판정하므로 이전 `-0` 상한 센티널이 `0.2.1-rc.1`을 거부했습니다.
10
+ - 호환 선언은 전부 정확한 열거: 열린 구간 없음, 미검증 미래 호스트는 거부.
11
+ - devDependencies를 실제 `0.2.1-rc.1` peer 기준으로 교체; `npm run typecheck:0.2.1`(기존 `:0.2.0`)이 클린 설치로 동일 기준을 검증; 타입체크 매트릭스는 `0.2.1-rc.1`을 포함한 7개 라인으로 확장.
12
+
13
+ ### 추가
14
+
15
+ - `prepack`이 빌드를 실행(npm pack의 오래된 `lib/` 동봉 방지); `publishConfig.registry`를 공식 npm registry에 고정.
16
+
17
+ ## [0.4.0] — 2026-10-09
18
+
19
+ ### 추가됨
20
+
21
+ - **모든 호스트 라인을 단일 버전으로 커버.** 하나의 버전(0.4.0)이 `0.1.0-rc.8`부터 `0.2.0-rc.2`까지(15개 rc 전부 + desktop) 모든 DSH 호스트를 지원합니다. peer 범위는 15개 rc를 모두 열거하고 `engines.dsh`는 `>=0.1.0-rc.8`을 선언합니다. 은퇴한 compat 브랜치(`compat/0.1.2`, `compat/0.1.5`, `compat/0.1.7`)와 `main` 분할 방식은 제거되었습니다. 배포 후 npm dist-tag `latest`, `dsh-0.2.0`, `dsh-0.1.7`, `dsh-0.1.5`, `dsh-0.1.2`는 모두 0.4.0으로 수렴합니다.
22
+ - **하나의 코드베이스로 3세대 설정 면을 커버**: 0.1.7+(및 desktop)은 선언적 `.volatile()` + `loader/volatile-update` 재등록. 0.1.2/0.1.5는 인스턴스 `settings.installSection`/`register`. 0.1.0/0.1.1은 `@deepseek-ai/dsh-settings`의 모듈 수준 `installSettingsSection`. 플러그인 페이지 설정 카드(client 쪽)는 0.1.7+/desktop에만 자리가 있고 구 라인에서는 우아하게 부재합니다.
23
+ - `defineTool` 저작 경로와 fs 소프트 강등: 호스트 `fs`에 write-intent가 없는 라인에서는 쓰기가 실패하지 않고 직접 쓰기로 자동 강등되며 `console.warn`을 1회만 출력합니다.
24
+ - 6라인 typecheck 매트릭스와 우아한 부재 시나리오를 커버하는 smoke 게이트.
25
+
26
+ ### 변경됨
27
+
28
+ - **파괴적 변경: `allowCodexPatch` 기본값이 `false`로 바뀌었습니다**(옵트인, 0.2.0 라인과 정렬. 기존 0.1.7 라인의 기본값은 `true`). 기존 0.1.7 라인 사용자는 0.4.0으로 업그레이드한 후 수동으로 켜야 합니다.
29
+
30
+ ## [0.3.1] — 2026-10-01
31
+
32
+ ### 수정
33
+ - **헤더 없는 다중 파일 unified diff가 하나의 파일 section으로 뭉개졌음** (0.1.7 라인 0.2.5에서 수정한 것과 동일한 결함): `diff --git` 구분이 없으면 두 번째 파일의 `--- `/`+++ ` 헤더가 이전 section의 경로를 덮어써 그 hunk가 잘못된 내용과 대조되어 첫 파일 이후 모든 section이 `the context does not match the file`로 실패. 현재 section이 점유된 상태면 `--- `가 새 section을 열도록 수정. 파서 수준과 엔드투엔드 회귀 테스트 추가.
34
+ ## [0.3.0] — 2026-09-29
35
+
36
+ ### 변경됨
37
+
38
+ - **DSH 0.2.0 라인 지원(`compat/0.2.0` 브랜치).** peer 범위와 두 매니페스트의 `engines.dsh`를 `>=0.2.0-rc.1 <0.2.1-0`으로 업데이트하고 버전은 0.3.0. devDependencies는 실제 `0.2.0-rc.1` 타입 베이스라인에 고정하고, 크로스 체크 스크립트를 `npm run typecheck:0.2.0`으로 업그레이드했습니다(registry에서 실제 peer 패키지를 설치해 검증). 0.1.x 호스트는 계속 `compat/0.1.7` 브랜치 / `dsh-0.1.7` dist-tag가 담당합니다.
39
+ - **Delete/Move를 현행 셸 실행기 API로 이전.** 호스트는 0.1.2 → 0.1.7 라인 사이에 `ShellExecutor.run(spec)`을 `execute(spec)`로 이름을 바꿨습니다(`ShellProcess` 핸들을 반환하고, 포그라운드 결과는 `result()`로 획득). 이전 devDependency 고정(`0.1.2-rc.1`)이 이를 가렸습니다: 0.1.7 라인 패키지(0.2.1)는 낡은 베이스라인에 대해 그린으로 보였고, 실제 0.1.7+ 호스트에서는 `run` 기반 덕 타이핑이 일치하지 않아 Delete/Move가 구조화된 UNSUPPORTED 오류로 저하되었습니다. 본 라인은 `shell.execute(...)`를 호출하고 `execution.result()`를 기다리는 방식으로 변경하며, 실행기는 `execute`로 구조 검출합니다.
40
+
41
+ ## [0.1.2] — 2026-09-19
42
+
43
+ ### 수정됨
44
+
45
+ - **설정 섹션이 한 번도 등록되지 않았습니다.** settings 네임스페이스 `patch_edit_plus`는 밑줄을 포함해 `dsh-settings`의 네임스페이스 패턴(`^[a-z][a-z0-9-]*$`)에 거부되었고, `register()`는 검증 단계에서 던졌습니다. 패널이나 `~/.dsh/settings.yaml` 어디에도 설정 섹션이 나타나지 않았습니다. `patch-edit-plus`로 이름을 변경했습니다(마이그레이션 불필요: 이전 섹션은 존재할 수 없었습니다).
46
+ - **설정 레이어의 구성 변경이 도구에 전달되지 않았습니다.** `setSource`/`onChange` 훅이 빈 구현이었고 해석된 구성은 로드 시 한 번 고정되었습니다. 이제 플러그인이 해석된 소스를 실제로 소비합니다: 설정 커밋(또는 레거시 `register`의 watch)이 있을 때마다 구성을 다시 해석하고 도구를 다시 등록합니다. 재등록 전에 먼저 이전 등록을 해제하므로, 살아 있는 이름 위에 재등록하며 조용히 이름이 바뀌는 일은 없습니다. `allowCodexPatch`를 비롯한 모든 필드를 DSH 설정 패널에서 변경하면 즉시 적용되고, 도구 설명(허용되는 패치 구문 목록)도 동기화되며, 프로세스 재시작이 필요 없습니다. settings 서비스가 분리되면 composition 엔트리로 폴백하며, 재판정은 멱등입니다(단일 필드가 아닌 해석된 구성 전체를 비교).
47
+
48
+ ## [0.1.1] — 2026-09-17
49
+
50
+ ### 수정됨
51
+
52
+ - **`workspace-write`에서 모든 쓰기가 거부되었습니다.** 도구가 호출별 `sandboxPolicy`를 전달하지 않아, 강제 적용하는 파일 시스템이 범위 없는 `ctx.sandboxPolicy.resolve()`로 폴백했습니다. 그 결과 세션 cwd 대신 **배포** 워크스페이스 루트(서버 실행 디렉터리)를 얻게 되었고, 세션 워크스페이스 안에 분명히 있는 경로가 경계 검사를 통과하지 못해 `danger-full-access` 세션에서도 `file access denied under workspace-write mode`를 반환했습니다. 이제 정책은 호출마다 호출 세션을 범위로 하여 해석되고(`resolve({ session })`), 모든 쓰기와 모든 Delete/Move shell 요청에 부여됩니다. 네이티브 `write`/`edit` 도구와 완전히 동일합니다. 모드의 양쪽 측면이 모두 적용됩니다: 세션의 `sandbox/mode` 재정의와 워크스페이스 루트로서의 세션 cwd입니다.
53
+ - 경로 해석과 경계가 이제 하나의 루트를 공유합니다: 계획 단계에서 모든 대상을 정책의 `workspaceRoot`(세션 cwd로 폴백)에 대해 해석하므로, 엔진이 쓰는 경로가 경계가 측정하는 경로와 일치합니다.
54
+
55
+ ## 미출시
56
+
57
+ ### 추가됨
58
+
59
+ - git/unified diff(기본)와 Codex `apply_patch` 문법(`allowCodexPatch`로 옵트인)을 모두 받아들이는, 모델에 노출되는 단일 `apply_patch` 도구.
60
+ - 형식 자동 감지 기능. 인식은 되지만 비활성화된 스타일이 들어오면 실행 가능한 힌트를 제공합니다.
61
+ - 추가 / 업데이트(다중 hunk) / 삭제 / 이동 연산. 삭제와 이동은 샌드박스 인식 `ctx.shell`을 통해 실행되며, 경로는 환경 변수로만 전달됩니다.
62
+ - 전부 아니면 전무 방식의 2단계 엔진: 무엇이든 쓰기 전에 전체를 읽기 전용으로 검증합니다(세 단계 허용 오차를 적용한 컨텍스트 위치 탐색, 워크스페이스 경계, 심볼릭 링크 거부, 중복 경로 감지).
63
+ - 모든 쓰기에 공식 쓰기 인텐트 댄스를 적용: `fs/write-intent` 워터폴 → 가드된 `writeText` → `fs/observed` 발생. 따라서 쓰기 전 읽기 게이트가 패치 쓰기에도 적용됩니다.
64
+ - 4요소 hunk 불일치 진단(파일 + hunk 인덱스, 탐색 시작 지점, 공백이 보이는 예상 미리보기, 실제 발췌)과 표적화된 힌트.
65
+ - `dryRun` 파라미터와 `dryRunByDefault` 설정.
66
+ - Codex 시맨틱 기반 그룹화 출력(추가 → 수정 → 삭제). 파일별 diff는 `maxDiffBytes`로 상한이 적용되며 `presentationMeta`는 재생(replay) 안전합니다.
67
+ - 3중 도구 이름 충돌 보호(`rename` 기본 / `skip` / `fail`)로, 다른 `apply_patch` 제공자와 이름이 충돌해도 DSH 시작이 깨지지 않습니다.
68
+ - DSH `0.1.2-rc.1` ~ `0.1.5-rc.2` 호환성: 단일 도구 작성 코드 경로와 0.1.5-rc.2 peer 패키지에 대한 `typecheck:0.1.5` 정적 검증, 그리고 설정 이중 API 폴백(`installSection` / `register`).
package/CHANGELOG.md CHANGED
@@ -1,5 +1,18 @@
1
1
  # Changelog
2
2
 
3
+ ## [0.4.8] — 2026-11-10
4
+
5
+ ### Added
6
+
7
+ - **Patch routing guidance as a system-prompt section on every supported host.** DSH 0.2.2-rc.1 is the first host that ships its own `apply_patch` (`dsh-tool-fs`, config `applyPatch`) together with a `tool:apply_patch` prompt section at `TOOL_APPLY_PATCH` (1350) and a description line that says to prefer it over separate edit calls. Older hosts ship neither, so a plugin-provided patch tool was described only by its per-call schema. The plugin now registers `plugin:patch-edit-plus:apply_patch` (same order, right after `tool:edit`) and carries the same one-line routing hint in the tool description.
8
+ - **Borrowed from 0.2.2**: the "prefer apply_patch over separate edit calls" phrasing, the hunk-context advice, "a rejected patch changes nothing", and the scope-aware empty text while the tool is absent. **Not borrowed**: "not rolled back" — verification here is all-or-nothing but the write phase is sequential, so the guidance claims only what is true.
9
+ - New `guidance: 'auto' | 'on' | 'off'` config (default `auto`). `auto` registers the section only when the tool kept its configured name; when rename avoidance had to step aside for another `apply_patch`, no second guidance text is injected.
10
+
11
+ ### Compatibility
12
+
13
+ - The section order falls back through `TOOL_APPLY_PATCH` → `TOOL_EDIT + 50` → `1350`: `TOOL_APPLY_PATCH` only exists from 0.2.2, and `0.1.0-rc.8` has no `getSectionOrder` at all, while a non-finite order makes `systemPrompt.section()` throw. The `systemPrompt` service is probed through the cordis inject gate and never added to `inject`, so a host without it keeps loading with only the guidance absent.
14
+ - DSH 0.2.2-rc.1 itself is not declared yet: its peer enumeration and coexistence with the host-shipped `apply_patch` are out of scope for this release.
15
+
3
16
  0.4.4: host enumeration addendum for DSH 0.2.1-rc.3 (declaration-only bump; contract plane zero diff).
4
17
 
5
18
  ## 0.4.3 (2026-10-18)
@@ -0,0 +1,63 @@
1
+ # История изменений
2
+
3
+
4
+ ## [0.4.2] — 2026-10-17
5
+
6
+ ### Изменено
7
+
8
+ - **Поддержана линия хостов `0.2.1-rc.1`.** `engines.dsh`, все семь диапазонов peer-`@deepseek-ai/dsh-*` и `dsh.plugin.json` теперь перечисляют 16 точных rc (`0.1.0-rc.2` … `0.2.1-rc.1`) вместо диапазона `>=0.1.0-rc.8 <0.2.1-0` — с 0.2.1-alpha.4 гейт совместимости судит `engines.dsh` отдельно, и старый `-0`-сентинел отклонял `0.2.1-rc.1`.
9
+ - Декларации совместимости везде точные перечисления: без открытых интервалов, непроверенные будущие хосты отклоняются.
10
+ - devDependencies переведены на реальную peer-базу `0.2.1-rc.1`; `npm run typecheck:0.2.1` (бывш. `:0.2.0`) подтверждает её чистой установкой из registry; матрица typecheck теперь покрывает семь линий, включая `0.2.1-rc.1`.
11
+
12
+ ### Добавлено
13
+
14
+ - `prepack` запускает сборку (npm pack больше не может упаковать устаревший `lib/`); `publishConfig.registry` закреплён на официальном npm-registry.
15
+
16
+ ## [0.4.0] — 2026-10-09
17
+
18
+ ### Добавлено
19
+
20
+ - **Единая версия для всех линий хостов.** Одна версия (0.4.0) обслуживает все хосты DSH от `0.1.0-rc.8` до `0.2.0-rc.2` — все 15 rc плюс desktop; диапазоны peer перечисляют все 15 rc, а `engines.dsh` объявляет `>=0.1.0-rc.8`. Выведенные из эксплуатации compat-ветки (`compat/0.1.2`, `compat/0.1.5`, `compat/0.1.7`) и схема разделения по `main` удалены; после публикации npm dist-tag'и `latest`, `dsh-0.2.0`, `dsh-0.1.7`, `dsh-0.1.5` и `dsh-0.1.2` сходятся на 0.4.0.
21
+ - **Три поколения настроек в одной кодовой базе**: декларативный `.volatile()` плюс перерегистрация через `loader/volatile-update` на 0.1.7+ (и desktop); экземплярные `settings.installSection`/`register` на 0.1.2/0.1.5; модульный `installSettingsSection` из `@deepseek-ai/dsh-settings` на 0.1.0/0.1.1. Карточка конфигурации на странице плагина (клиентская половина) присутствует только на 0.1.7+/desktop и на старых линиях изящно отсутствует.
22
+ - Путь авторинга `defineTool` с мягкой деградацией fs: на линиях, где в `fs` нет write-intent, запись деградирует до прямой с одним `console.warn` вместо сбоя.
23
+ - Матрица тайпчека по шести линиям, плюс smoke-шлюз, покрывающий сценарии изящного отсутствия.
24
+
25
+ ### Изменено
26
+
27
+ - **Ломающее изменение: `allowCodexPatch` по умолчанию теперь `false`** (включение вручную, выровнено с линией 0.2.0; старое значение по умолчанию на линии 0.1.7 было `true`). Существующим пользователям линии 0.1.7 нужно включить его вручную после обновления до 0.4.0.
28
+
29
+ ## [0.3.0] — 2026-09-29
30
+
31
+ ### Изменено
32
+
33
+ - **Поддержка линии DSH 0.2.0 (ветка `compat/0.2.0`).** Диапазоны peer-зависимостей и `engines.dsh` (в обоих манифестах) теперь объявляют `>=0.2.0-rc.1 <0.2.1-0`; версия 0.3.0. devDependencies фиксируют реальную типовую базу `0.2.0-rc.1`, а скрипт перекрёстной проверки переведён на `npm run typecheck:0.2.0` (устанавливает реальные peer-пакеты из registry). Хосты 0.1.x по-прежнему обслуживаются веткой `compat/0.1.7` / dist-tag `dsh-0.1.7`.
34
+ - **Delete/Move переведены на актуальный API shell-исполнителя.** Между линиями хостов 0.1.2 и 0.1.7 `ShellExecutor.run(spec)` был переименован в `execute(spec)` — с возвратом дескриптора `ShellProcess` и foreground-проекцией `result()`. Старый пин devDependency (`0.1.2-rc.1`) маскировал это: пакет линии 0.1.7 (0.2.1) зелено проходил тайпчек против устаревшей базы, а на реальных хостах 0.1.7+ его утинная типизация на основе `run` никогда не совпадала, из-за чего Delete/Move деградировали до структурированной ошибки UNSUPPORTED. Эта линия вызывает `shell.execute(...)` и ожидает `execution.result()`; исполнитель распознаётся по `execute`.
35
+
36
+ ## [0.1.2] — 2026-09-19
37
+
38
+ ### Исправлено
39
+
40
+ - **Секция настроек так и не была зарегистрирована.** Пространство имён настроек `patch_edit_plus` содержит подчёркивание, которое отклоняется шаблоном пространств имён `dsh-settings` (`^[a-z][a-z0-9-]*$`), поэтому `register()` падал до всякой записи — ни в панели, ни в `~/.dsh/settings.yaml` запись настроек не появлялась. Переименовано в `patch-edit-plus` (миграция не нужна: старая секция не могла существовать в принципе).
41
+ - **Изменения конфигурации из слоя настроек никогда не доходили до инструмента.** Хуки `setSource`/`onChange` были заглушками, а разрешённая конфигурация мемоизировалась один раз при загрузке. Теперь плагин потребляет разрешённый источник: каждое подтверждённое изменение настроек (или legacy-watch `register`) заново разрешает конфигурацию и перерегистрирует инструмент — предварительно уничтожая старую регистрацию, поскольку перерегистрация поверх живого имени молча его переименовывает. `allowCodexPatch` и все остальные поля теперь переключаются из панели настроек DSH и вступают в силу немедленно, причём описание инструмента (список принимаемых стилей патчей) остаётся синхронным; перезапуск процесса не требуется. При отключении сервиса настроек происходит откат к записи композиции, а повторное суждение идемпотентно (сравнивается вся разрешённая конфигурация, а не одно поле).
42
+
43
+ ## [0.1.1] — 2026-09-17
44
+
45
+ ### Исправлено
46
+
47
+ - **Каждая запись отклонялась под `workspace-write`.** Инструмент не передавал `sandboxPolicy` на вызов, поэтому принуждающая файловая система откатывалась к `ctx.sandboxPolicy.resolve()` без области видимости — корень рабочей области РАЗВЁРТЫВАНИЯ (каталог запуска сервера) вместо cwd сессии. Путь, явно лежащий внутри рабочей области сессии, не проходил проверку охвата и возвращал `file access denied under workspace-write mode`, даже в сессии `danger-full-access`, где режим даже не считывался. Теперь политика разрешается при каждом вызове с вызывающей сессией в области видимости (`resolve({ session })`) и проставляется на каждую запись и каждый shell-запрос Delete/Move — в точности как у нативных инструментов `write`/`edit`. Теперь соблюдаются обе половины режима: переопределение `sandbox/mode` сессии и её cwd как корень рабочей области.
48
+ - Разрешение путей и ограждение теперь используют один корень: план разрешает каждую цель относительно `workspaceRoot` политики (с откатом к cwd сессии), так что путь, который пишет движок, — это путь, который измеряет ограждение.
49
+
50
+ ## Unreleased
51
+
52
+ ### Добавлено
53
+
54
+ - Единственный доступный модели инструмент `apply_patch`, принимающий git/unified diff (по умолчанию) и синтаксис `apply_patch` от Codex (по явному включению через `allowCodexPatch`).
55
+ - Автоопределение формата с действенной подсказкой, когда приходит распознанный, но отключённый стиль.
56
+ - Операции Add / Update (multi-hunk) / Delete / Move; Delete и Move идут через учитывающий sandbox `ctx.shell`, пути передаются только через переменные окружения.
57
+ - Двухфазный движок «всё-или-ничего»: полная проверка в режиме только чтение (локализация контекста с тремя уровнями допуска, удержание в рабочей области, отклонение symlink, обнаружение дублирующихся путей) перед любой записью.
58
+ - Официальная write-intent-последовательность при каждой записи: водопад `fs/write-intent` → защищённый `writeText` → эмиссия `fs/observed`, так что барьер «сначала прочти, потом пиши» действует и для записей патчей.
59
+ - Четырёхэлементная диагностика несовпадения хунка (файл + индекс хунка, начало поиска, ожидаемое превью с видимыми пробелами, фактический фрагмент) плюс адресная подсказка.
60
+ - Параметр `dryRun` и настройка `dryRunByDefault`.
61
+ - Группированный вывод с семантикой Codex (added → modified → deleted) с диффами по файлам, ограниченными `maxDiffBytes`, и устойчивым к повторному проигрыванию `presentationMeta`.
62
+ - Трёхуровневая защита от конфликтов имён инструментов (`rename` по умолчанию / `skip` / `fail`), чтобы столкновения имён с другими провайдерами `apply_patch` никогда не ломали запуск DSH.
63
+ - Совместимость с DSH `0.1.2-rc.1` ~ `0.1.5-rc.2`: единый путь кода для авторинга инструментов плюс статическая проверка `typecheck:0.1.5` против peer-пакетов 0.1.5-rc.2; двух-API-фолбэк настроек (`installSection` / `register`).
package/CHANGELOG.zh.md CHANGED
@@ -1,5 +1,18 @@
1
1
  # 更新日志
2
2
 
3
+ ## [0.4.8] — 2026-11-10
4
+
5
+ ### 新增
6
+
7
+ - **在所有支持的宿主线注入 patch 路由段(系统提示层)。** DSH 0.2.2-rc.1 是第一个自带 `apply_patch` 的宿主(`dsh-tool-fs`,配置项 `applyPatch`),并首次配上 `tool:apply_patch` 提示段(order 为 `TOOL_APPLY_PATCH`,1350)与“优先于多次 edit”的 description 一句。更早的宿主两者都没有,插件提供的 patch 工具只能靠每次调用附带的 schema 描述。本版改为注册 `plugin:patch-edit-plus:apply_patch`(同序号,紧跟 `tool:edit`),并在工具 description 里带上同一句路由提示。
8
+ - **取自 0.2.2**:`prefer apply_patch over separate edit calls` 的优先口径、hunk 上下文行建议、`被拒绝的 patch 不改变任何文件`、以及“工具不在作用域时输出空文本”。**未取**:`not rolled back`——本插件的验证是全有或全无,但写入阶段是顺序执行、不回滚,所以提示只陈述事实。
9
+ - 新增配置项 `guidance: 'auto' | 'on' | 'off'`(默认 `auto`)。`auto` 仅在工具保持配置名时注册提示段;若因重名避让被改名(例如宿主已自带 `apply_patch`),不再注入第二套提示。
10
+
11
+ ### 兼容性
12
+
13
+ - 提示段序号按 `TOOL_APPLY_PATCH` → `TOOL_EDIT + 50` → `1350` 逐级回退:`TOOL_APPLY_PATCH` 从 0.2.2 才有,`0.1.0-rc.8` 连 `getSectionOrder` 都没有,而非有限数会让 `systemPrompt.section()` 直接抛出。`systemPrompt` 服务经 cordis 注入门探测,**不**加入 `inject`,因此没有该服务的宿主照常加载,仅缺少提示段。
14
+ - 本版尚未声明适配 DSH 0.2.2-rc.1:其 peer 枚举与“宿主内置 `apply_patch` 共存”不在本次范围内。
15
+
3
16
  0.4.4:宿主枚举补票 DSH 0.2.1-rc.3(声明面换代,契约零改动)。
4
17
 
5
18