dsh-dcs-engine

The DSH protocol stack already provides five components — CDP semantic scoring, intent-network topology planning, CSP decision tracing, ASP safety review, and the universal-adapter tool bridge — yet in real projects, scattered MCP base tools often remain individually invocable with no middle layer to compose them into named, registrable, reusable capability units. dsh-dcs-engine (DCS) is exactly that Host composition layer: at runtime it selects tools from the base-tool pool, plans a full CapabilitySpec along an input → transform → output topology, and registers the result via defineTool so that an intent like analysing the AAPL decline and producing a Chinese-language report can be fulfilled end-to-end in a single call.

DCS does not replace any of the five components — it consumes them. It leverages CDP cognitive_style and semantic_tags for candidate scoring, reuses the intent network plan() when available (falling back to a built-in rule topology otherwise), writes decision_trace into CSP, and enforces an ASP side_effects review before registration: a verdict of fail immediately raises SynthesisRejectedError, safety first. The optional materializer can, on persistence, generate a complete deployable plugin skeleton including package.json, tsconfig.json, cordis.patch.yml, .cdp.json, capability.json, a README, and src/index.ts, turning a one-off synthesis into a shippable asset. The default synthesis strategy is rule (zero LLM overhead); hybrid and llm modes are best-effort add-ons.

If you are already running cordis and dsh-tools (>= 0.1.0) and hold a set of scattered MCP tools you want to compose into reusable capabilities — with semantic scoring, safety audit trails, and exportable skeleton artifacts — DCS is built for that scenario. It is currently a Developer Preview (M2); interfaces may shift within 0.1.x, and production deployments should await the 1.0 stable release.