v0.5.0 — reliable offline local model scanning

Local model scanning that works offline

• Fix plugin configuration validation and Cordis injection handling that prevented inventory routes from registering and caused HTTP 404 responses.
• Make Scan and Refresh strictly read-only: neither starts nor stops engines.
• Discover active-catalog models, configured and installed workflow stores, catalog-relative workflow files, and supported local Ollama manifests even when servers are unreachable.
• Probe engines independently with bounded timeouts and retain partial results with honest availability, installation evidence, freshness, and per-engine errors.
• Preserve stale inventory after refresh failures; support Retry without reloading; prevent superseded requests and scans from overwriting newer results.
• Fix workflow identity collisions, partial directory failures, invalid engine responses, and stale provider registration.
• Include rebuilt production JavaScript artifacts and expanded regression coverage.

Verification

The full regression suite, TypeScript checks, production build, and real installed Cordis/WebServer route tests passed. Automated fixtures cover both engines running, either one running, both offline, missing installations, malformed responses, timeouts, and repeated Scan/Refresh requests. The real-machine observation covered Ollama running with ComfyUI installed but unreachable; other live engine combinations were not claimed as tested.

Upgrade

Update the plugin, reload it or restart DSH, then refresh the browser. This release does not automatically start local engines. Endpoint reachability is not a guarantee of workflow execution or model-file integrity.

v0.4.0 — runs on every DSH 0.x release, not one of them

AI Model Hub 0.4.0 — Compatibility fixes for DSH 0.1.x and 0.2.x

Fixes a compatibility issue that prevented AI Model Hub from loading on DSH 0.2.x. Runtime checks also let the plugin keep its tools available when optional host features are missing or unusable.

Fixed: plugin rejected before loading

The previous peer dependency range, ^0.1.5-rc.2, excluded DSH 0.2.x. DSH checks peer compatibility before importing a plugin, so the rejection prevented apply from running.

The three gated peer dependencies now use:

>=0.1.5-rc.2 <0.3.0

This extends the declared compatibility range to DSH 0.2.x while keeping 0.3.0 and 1.0.0 outside it.

Prerelease compatibility is tested through DSH’s own compatibility gate, including 0.2.0-rc.2 and 0.2.1-alpha.2. Acceptance of these versions depends on the gate’s prerelease handling; the range alone does not opt into them under npm’s default rules.

Peers that a host composition may omit—cordis, schemastery, react, and dsh-system-prompt—are now marked optional.

Added: runtime compatibility checks

The new dsh-plugin/compat.ts centralizes host capability checks and guarded registration helpers.

Missing host feature	Effect
tools	Loading fails with an explicit diagnostic naming the required registry.
systemPrompt	The prompt capability snapshot is unavailable; tools remain available.
webServer	The Local models and Priorities pages are unavailable; tools remain available.
effect	Automatic process cleanup on unload is unavailable; the effect callback is not executed.
skills, sandboxPolicy, or get	Only the corresponding integration is unavailable.
logger	Diagnostics fall back to the console.

Optional integrations report missing, unusable, or throwing host members through focused diagnostics.

Validation

625 tests passing, 0 failing.

Coverage includes:

• Peer dependency ranges and compatibility checks through DSH’s own gate.
• Loading the real plugin with only a tool registry.
• Missing, unusable, throwing, and partially implemented host members.
• Source audits for host context access and dependency injection declarations.

Also fixed

Repaired five incorrectly encoded em dashes in dsh-plugin/index.ts that appeared as garbled text in the source and compiled output.

Install

dsh plugin --profile web add github:Mhmd7-7/dsh-ai-model-hub

Restart DeepSeek Harness after installation.

v0.3.0 — ComfyUI workflow discovery and 3D execution

The minor bump reflects a new capability rather than a fix: ComfyUI discovery now reads the workflows saved in ComfyUI and infers what they can do from their own graphs, so image_to_3d and text_to_3d become routable with no catalog entry.

Discovery reads workflows, not just weights

ComfyUI holds weight files and workflows, and only the second proves a capability. Discovery already read /object_info for the first; it now also lists /userdata?dir=workflows, fetches each workflow, and reads it as a graph:

image input  +  a node that returns MESH  +  a node that persists a 3D file
   = image_to_3d      (plus text_to_3d when the prompt reaches the generator)

• Capability is inferred from structure - declared port types and reachability - never from a filename or a model name.
• A UI-format export is converted to an API-format graph using each nodes declared inputs, because the editors widgets_values are positional. When a node pack is missing, the conversion is refused loudly rather than guessed.
• A graph that only previews a mesh, or that post-processes one, proves nothing and is published disabled with the reason in its notes.
• A workflow whose weights are not installed is published disabled too, naming the missing files - so "installed but not runnable" stays visible instead of becoming a runtime failure.

3D execution

invoke_model({ capability: 'image_to_3d', inputs: [image] }) now finds the workflow, uploads the image to /upload/image, injects ComfyUIs returned filename into the graphs image loader, queues it, polls /history, and returns the result as a sniffed model_3d artifact with any companion render after it. GLB, glTF, OBJ, STL and PLY are identified from their bytes, not from an extension.

text_to_3d is advertised only when a prompt genuinely reaches the 3D generator. A prompt supplied to a graph with no text node is refused rather than silently dropped.

Capability belongs to the thing that demonstrates it

A discovered weight file no longer inherits 3D capabilities from installed nodes. This corrects a real false positive: a checkpoint was advertising image_to_3d merely because 3D node packs were present, which routes work into a guaranteed failure. Workflows carry those capabilities because their graphs prove them; checkpoints never do.

Configuration stays an override layer

Host-level adapterConfig.workflows matches a workflow by the name ComfyUI stores it under and can:

• pin a preferred one with priority
• disable one with enabled: false
• correct discoverys heuristic resource estimate with vramGb / ramGb
• narrow its capabilities with capabilities - never widen; a capability the graph does not prove cannot be added
• run a different file with workflowPath, for a UI export that could not be converted faithfully

Unchanged

ModelHub, the router, the runtime manager, the DSH plugin and the artifact system. No removed API: every v0.2.0 entry in config/models.json keeps working.

Tests

40 new tests (482 total, all passing) covering: no 3D workflow; image_to_3d; text_to_3d; missing nodes; missing weights; an unhealthy engine; insufficient VRAM; several candidates; routing between them and pinning; prompt islands; preview-only and post-process-only graphs; and mesh artifact normalization.