dsh-tool-vision 0.9.1 → 0.9.3

package/LICENSE

@@ -1,23 +1,23 @@
-MIT License
-
-Copyright (c) 2026 Scorp1o117
-Bridge image preview contributed by xing666173 (dsh-bridge-preview),
-Copyright (c) 2026 xing666173
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+MIT License
+
+Copyright (c) 2026 Scorp1o117
+Bridge image preview contributed by xing666173 (dsh-bridge-preview),
+Copyright (c) 2026 xing666173
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -42,15 +42,15 @@ bridge keeps its conversion inside that durable path:
   key lives in `settings.yaml`, not the profile patch. Mount by package name
   (`name: 'dsh-tool-vision'`) so the web client bundle is discovered.
 
-## Compatibility (v0.9.1)
-
-Verified in a DSH `0.1.5-rc.3` (`next`) disposable Web profile; DSH
-`0.1.5-rc.2` remains `latest`. The rc.3 host currently references an
-unpublished `dsh-client-ui-sidebar-documentpreview@0.1.5-rc.3`, so the smoke
-profile temporarily used that unrelated UI package at rc.2. A clean rc.3
-installation is blocked upstream. Alpha releases remain `unknown`.
-
-## Install
+## Compatibility (v0.9.1)
+
+Verified in a DSH `0.1.5-rc.3` (`next`) disposable Web profile; DSH
+`0.1.5-rc.2` remains `latest`. The rc.3 host currently references an
+unpublished `dsh-client-ui-sidebar-documentpreview@0.1.5-rc.3`, so the smoke
+profile temporarily used that unrelated UI package at rc.2. A clean rc.3
+installation is blocked upstream. Alpha releases remain `unknown`.
+
+## Install
 
 Mount in a profile patch (`$DSH_HOME/profiles/<name>/cordis.patch.yml`):
 
@@ -382,6 +382,81 @@ the panel's picker carries a badge:
 > A route on an unknown protocol (e.g. `openai-responses`) returns `unknown`
 > with a reason, rather than guessing confidently with `chat/completions`.
 
+## v0.9.3: adapter snapshot model admission (pi-ai guard)
+
+**The bug.** `v0.9.2`'s `installDispatchImageAdmission` satisfied DSH core's
+`LlmService.generate` by declaring `image` on `adapterCall.model.inputModalities`.
+However, `dsh-llm-pi-ai`'s adapter executes a second internal guard inside its
+streaming path (`streamWithSnapshot`):
+
+```js
+const model = this.modelOf(snapshot, options.provider, options.model);
+if (containsImage && !model.input.includes("image"))
+  throw new LlmError(`pi-ai model "${model.id}" does not support image input`, "UNSUPPORTED_CONTENT");
+```
+
+`this.modelOf` resolves from the adapter's own `snapshot.models` catalog, which
+defaults to `input: ["text"]` unless the user explicitly declared
+`input: [text, image]` in `settings.yaml`. When admitted by `v0.9.2`, the raw image
+reached `streamWithSnapshot` and triggered `UNSUPPORTED_CONTENT`. Since the image
+was already in the session's durable transcript, every subsequent turn failed.
+
+**The fix.** On direct routes, `installDispatchImageAdmission` now additionally:
+1. Wraps `adapter.modelOf` (when present) to include `"image"` in `resolved.input`;
+2. Enriches the live snapshot model (`snapshot.models.getModel(route, model).input`)
+   with `"image"`;
+3. Fully restores `adapter.modelOf` and reverts modified input arrays upon dispose.
+
+## v0.9.2: admission is not dispatch
+
+**The bug.** Every capability signal this plugin collects — `probeResults`,
+`multimodalModels`, `autoDetectMultimodal` — decided whether the *bridge*
+intercepts an image. None of them decided whether the model *receives* it.
+
+`LlmService.generate` resolves modalities from the adapter, not from the plugin:
+
+```js
+const adapterCall = await adapter.prepareCall(provider, model, signal);
+modelInfo = this.normalizeModelInfo(registration, model, adapterCall.model);
+if (modelInfo.inputModalities !== undefined
+    && !modelInfo.inputModalities.includes("image")
+    && projectedMessages.some((message) => contentHasImage(message.content)))
+  projectedMessages = projectImagesForTextModel(projectedMessages);
+```
+
+`projectImagesForTextModel` rewrites every image block into
+`[image omitted because this model accepts text only; attachment sha256:…]`
+**before the adapter is called**. So on a route the plugin had measured as
+image-capable — where the bridge therefore stepped aside and let the image
+through — the image was still destroyed, by a check that reads the adapter's
+declaration and nothing else. The `resolveModelInfo` wrap (`bridgeAutoImage`) is
+*admission*: it decides who may offer an image, and it never changes what the
+adapter streams. Nothing in the plugin reached the layer that does.
+
+The symptom is a route that probes `yes`, is listed in `multimodalModels`, and
+still answers `[image omitted …]`.
+
+**The fix.** `installDispatchImageAdmission` wraps `llm.registration` — the
+accessor the core itself calls — so every adapter, including one registered
+later, answers `prepareCall` through the same `routeDirectDecision` the bridge
+uses. One precedence rule, two seams, so the two can never disagree about a
+route. When the decision is "bridge", nothing changes: the bridge already turned
+the image into an `inspect_image` hint, and the core's projection stays as the
+correct fallback for any image that still reaches dispatch.
+
+Three properties worth stating, because each one is a test:
+
+- **Fail closed.** A decision that cannot be made (a throwing config) leaves the
+  call untouched, rather than sending pixels a route may reject.
+- **Reversible.** Dispose restores every adapter it patched *and* the accessor
+  itself; a re-install after dispose wraps again.
+- **Late providers count.** The wrap is on the accessor rather than on a snapshot
+  of adapters, so a provider registered after install is covered too.
+
+`routeDirectDecision` is now the single implementation of the precedence rule,
+shared by the bridge and the dispatch path — two copies of it would drift, and
+this one has three inputs.
+
 ## v0.8.0: master switch, and the save-path fix
 
 **Master switch.** `enabled`, plus a one-click button at the top of the section