v0.3.5

Changes in 0.3.5

• Remove Hardcoded Provider Restriction on reference_image: Removed the legacy client-side check that rejected reference_image when provider !== 'dashscope'.
• Full OpenAI-Compatible Image Editing (I2I): In OpenAI flavor, reference_image is now automatically encoded as a base64 data URL and passed via the image parameter to POST /images/generations, natively matching Alibaba / Qianwen Cloud's OpenAI-compatible image editing specifications.
• Robust Endpoint Normalization: Updated dashscopeRoot to strip full service URL paths (such as /api/v1/services/aigc/multimodal-generation/generation), ensuring both short domain roots and full documentation curl URLs work smoothly without duplication.

v0.3.4

Changes in 0.3.4

• Smart Intercept of Model 1024x1024 Boilerplate: When a user configures a custom defaultSize (e.g. 1920x1080), LLMs frequently emit size: 1024x1024 due to pre-training habits or multi-turn chat history copying. The runtime now detects whether 1024x1024 was explicitly requested in the prompt (e.g. 1024, 1:1, square, 正方形). If not, it automatically intercepts and applies the user's configured defaultSize.
• E2E Tool Echo: Added size to the tool's result schema and rendered text so that the actual resolution used is clearly reported in the conversation.
• Purged 1024 from Schema Description: Removed all mentions of 1024x1024 from parameter description to avoid prompting the model.

v0.3.3

Changes in 0.3.3

• Tool Schema & Prompt Guidance: Updated the generate_image tool's size parameter description to explicitly instruct LLMs to omit the size parameter unless the user explicitly requested a specific resolution or aspect ratio.
• Size Resolution & Fallback: Hardened runtime fallback logic in generate_image so that image.defaultSize (e.g. 1920x1080) reliably takes effect when size is omitted, empty, or set to generic values like default or auto.
• Cosmokit Container Unwrapping: Ensured unwrapConfig is applied consistently to initial configs during installSettingsCompat.

v0.3.2 — fix Schemastery volatile schema nesting and add unwrapConfig

dsh-image-plugins 0.3.2

Fixed

• Schemastery volatile nesting validation: Fix ValidationError: invalid config: - $.vision.enabled volatile fields require a fixed object path without an enclosing volatile field when enabling the plugin in DSH desktop (Cordis _resolveConfig). Removed asVolatile from enclosing z.object nodes (vision and image), keeping it strictly on leaf scalar fields as required by Schemastery / Cordis.
• Volatile reference unwrapping: Added unwrapConfig to recursively unwrap Cosmokit Volatile<T> ({ get(): T }) reference containers in resolveConfig, resolveVision, and resolveImage. This ensures all internal logic handles plain JavaScript primitives and prevents empty volatile blocks from falsely evaluating as configured.

Full changelog: v0.3.1...v0.3.2

v0.3.1 — dual-engine settings compatibility (dsh 0.1.5 → 0.2.0)

dsh-image-plugins 0.3.1 — dual-engine settings compatibility

One build now works across the dsh settings rewrite (0.1.5 → 0.1.7 → 0.2.0).

dsh 0.1.7 replaced the settings subsystem: the host dropped SettingsProvider.installSection(), the browser dropped the settingsScope service, and live-editable schema fields must be declared volatile. Against those hosts 0.3.0 crashed on load and its settings panel never rendered. 0.3.1 adapts at runtime instead of pinning a host version.

Fixed

• Host, dsh ≥ 0.1.7 / 0.2.0 — plugin load no longer throws settings.installSection is not a function. The new installSettingsCompat duck-types the host: installSection on ≤ 0.1.5, SettingsForms.configure({ auto: false }) plus an app-boot/config-reload listener on ≥ 0.1.7.
• Browser, dsh ≥ 0.1.7 / 0.2.0 — the settings panel no longer hangs. settingsScope is gone from the static inject list (declaring a service the host deleted blocks plugin activation entirely); the scope is resolved at runtime from configForms.get('image-plugins'), falling back to settingsScope.bind({ namespace: 'dsh-image-plugins' }) on older hosts.
• Schema — every editable field is marked volatile in the form hosts read it (meta.volatile, via .extra('volatile', true): schemastery 3.18.x ships no .volatile() method). Without it, 0.1.7+ hosts reject a live edit with Config field "…" is not volatile.

Verified hosts

Host	Settings path exercised
0.1.5-rc.x	installSection + settingsScope
0.1.7-rc.2	SettingsForms.configure + configForms
0.2.0-rc.2	same as 0.1.7 — confirmed by unpacking the host's own @deepseek-ai/dsh-settings, dsh-client-ui-settings, dsh-client-connection and dsh-credentials-local to check configure, meta.volatile, configForms.get, and the /api Fetch route registry

Changed

• peerDependencies widened to >=0.1.2-rc.1 so the 0.1.7+ compatibility pre-check accepts the plugin.
• Tests: 73 (was 69). Added tests/client.test.ts (classic-script evaluation plus both scope-resolution branches) and a 0.1.7 SettingsForms boot test asserting configure({ auto: false }) and config-reload behaviour.

Notes

• Where the panel persists edits follows the host: ~/.dsh/settings.yaml on ≤ 0.1.5; on ≥ 0.1.7 that global file is retired (archived as settings.yaml.imported) and edits land in the profile's cordis.patch.yml under the image-plugins entry. Secret values always live in ~/.dsh/.credentials.yaml.
• Unchanged from 0.3.0: per-capability enable switches for understand_image / generate_image, and the /api/image-plugin-status/snapshot status route.

Full changelog: v0.3.0...v0.3.1