dsh-health-scheduler

Running a DS-Hns node means juggling thermal readings, memory pressure, worker saturation and UI state all at once. Watching these by hand is tiring and error-prone, and the moment the question slips from should we restart to who restarts, a failure cascade is set in motion. dsh-health-scheduler draws that line explicitly: it senses, scores, decides and requests, but it never executes a single restart.

Six weighted dimensions flow through HealthProviders into a single 0-100 restart-pressure index. Before any action leaves the policy engine the score must clear a sustain gate, a rolling window, a two-evaluation debounce, per-level cooldowns and a maintenance-window check. Levels 1-2 are dispatched to a worker-control adapter for throttling or pausing new work; levels 3-4 are emitted as requests to the separate dsh-restart bundle, which owns all restart execution, locks, rate limits and graceful shutdown. A dimension with no data scores null and redistributes its weight, so absence is never painted as healthy, and a single point sample can never drive a high-risk action.

It is built for operators who want unattended health coverage on one or more DS-Hns nodes, and for developers who want three read-only, model-facing tools (health_status, health_history, health_policy) that expose pressure, trends and the full decision policy inside a conversation. Every applied action writes exactly one audit record carrying its drivers, coverage and the adapter answer, and every number in the report traces back to a measurement: the model thought it should restart is not a possible reason code.