dsh-capability-facade

Community plugins often register every internal step as a model-visible tool, leaving the model to pick names, decide order, and make multiple root calls for what the author already knows is a fixed pipeline. dsh-capability-facade offers a narrower design: the author declares a capability, packages the deterministic multi-step sequence into one semantic operation, and the harness executes each step in declared order under a single root call via nested dispatch. When no capability is declared, the cost is zero—no extra schema, no prompt tokens, no code path.

The core principle is explicit declaration over a universal entry point. Every operation is a named, described, typed tool; internally it runs through ctx.tools.execute(), so guards, approvals, sandboxing, and timeouts apply exactly as they would on a direct call. register() is all-or-nothing with a precise disposer on teardown. The repo also ships a read-only static analyzer that maps which tools a plugin exposes and heuristically flags implementation primitives, plus an isolated-profile verification script to confirm changes without touching the target profile.

This plugin is for plugin authors at design time: when your internals contain stable, repeatable multi-step combinations (extract then layout, check then vet), a facade lets the model complete the whole pipeline in one call, removing the cognitive overhead of the model reasoning through order and selection each round. It is not for hiding tools that are already registered—DSH's visibility resolver simultaneously feeds presentation, lookup, and dispatch, so restriction is all-or-nothing and a facade cannot shrink a surface that is already exposed. In short: design narrow from the start, rather than trying to hide what is already visible.