dsh-intent-network

In the DSH ecosystem, turning a vague one-sentence user request into a multi-step tool invocation chain often means hand-writing JSON, hard-coding branches, and debugging by guesswork. dsh-intent-network reframes that pipeline as a structured intent graph: nodes are DSH-registered tools (including external MCP tools bridged via adapters), edges encode conditional branches, dependencies, and fallback paths, and semantics are drawn from CDP metadata. The graph is editable, auditable, and every execution is traced to disk, so you can always pinpoint which node fired and why a particular edge was taken.

On the execution side, the plugin ships a built-in planner (rule, LLM, or hybrid strategies, defaulting to zero LLM overhead), parallel and loop-limit controls, AbortSignal-based mid-run cancellation, and a critical safety mechanism: when a node is tagged by CDP metadata with irreversible side-effects or an advisor role, execution halts and returns ConfirmationRequired, waiting for explicit human approval before proceeding—no silent pass-through. Fallback paths ensure that a single node failure does not crash the whole graph; execution simply follows a pre-defined degradation chain.

It works best as the orchestration layer in a DSH workflow: you have already described tool semantics with dsh-cdp-metadata and pulled in external MCP tools via dsh-cordis-universal-adapter, and what you are missing is something to wire them into an executable, observable, rollback-friendly graph. That is exactly what intent-network provides. The three plugins are orthogonal, do not override each other's configuration, and can be installed together. Keep in mind that the M1 release does not yet include automatic learning (trace collection only), the planner's LLM mode depends on the host supplying ctx.llm, and the plugin does not implement a sandbox—tool side-effects remain the responsibility of the host environment and the tools themselves.