dsh-lifecycle-inspector

DeepSeek Harness manages plugin registration and disposal through the Effect model, a powerful design that nevertheless makes day-to-day troubleshooting difficult: a plugin stuck in pending, an unload that drags on, or a suspected leftover resource usually forces operators to piece together clues from raw runtime logs. Lifecycle Inspector translates that internal state into an operator-friendly dashboard and concise diagnostic commands, so you can answer three practical questions without reading raw output: which plugins are active, inactive, or need attention; what services, event listeners, commands, tools, and child plugins a given plugin currently registers; and whether Cordis has finished disposing every Effect it manages, and how long the observed teardown took.

Core capabilities include a native DSH Web dashboard (Settings, Plugins, Lifecycle) with health totals, search, problem-only filtering, and expandable Effect details; readable reports that group low-level Effect labels into services, event listeners, commands and tools, child plugins, and cleanup-sensitive resources; Fiber health signals that highlight failed, pending, and unloading states; and teardown observations that record recent Fiber transitions and flag cleanup exceeding a configurable threshold. It also exposes the read-only lifecycle_inspect tool alongside /lifecycle commands for Agent or CLI use, and its own command, tool, HTTP route, styles, and UI slot are all registered as disposable Effects, adhering to the same ownership rules it helps users inspect.

This plugin is well suited to DSH operators and developers who need to diagnose plugin lifecycle issues: when you want to quickly confirm whether a plugin is healthy, whether its resources were properly released, and whether Cordis cleanup was complete, without modifying the Agent main loop, this lightweight, independently removable, strictly read-only inspector is a practical choice. It also explicitly states its own boundary: a cleared Effect tree proves only that Cordis completed every disposer registered in that tree, not that the plugin created no process, timer, socket, watcher, or other resource outside Cordis Effects, so a clean result is not mistaken for a complete external-resource audit.