dsh-system-monitor

Configuration

Every tunable is read from the loader row's config. Override it in the profile's cordis.patch.yml — that layer survives plugin upgrades, unlike the bundle's own patch:

- id: dsh-system-monitor
  config:
    alertMemory: 95
    showGpu: false

Two details matter here, and both cost real debugging time:

• The id is the row id, not the package name. It is the id the bundle's cordis.patch.yml inserts.
• Omit name. A patch entry with both an id and a name re-declares the row, and the Loader will not re-apply an insert for an id it already knows — so the override is silently dropped. An id alone is an override; an id plus a name is an insert.

Key	Default	Meaning
alertCpu / alertMemory / alertGpu / alertDisk	85 / 92 / 95 / 92	Percent at which the sidebar badge lights
alertSustainSeconds	5	How long a reading must stay above its threshold first
showGpu	true	Hide the GPU card and series on machines where the counters misbehave
showClock	true	Show live CPU clock instead of the nominal one
showDiskThroughput	true	Show the disk throughput chart
showIcons	true	Extract and show application icons
showProcesses	true	Ship the per-application breakdown at all
persist	true	Keep extremes and the alert log in ~/.dsh-system-monitor/state.json across restarts
idleSamplingSeconds	20	Cadence with no viewer for 10 min; 0 stops the sampler instead
historyDays	7	Days of rolling NDJSON history kept on disk; 0 disables it

Forecasts are always computed; they surface on the memory and disk cards and on the Status tab.

Numbers are clamped and wrong types fall back to the default, so a typo can make a threshold odd but can never disable the sampler or wedge the page. The effective values are shown on the Status tab, so what actually took effect is never a guess.

A Config schema is exported when @deepseek-ai/schemastery resolves — which it does for a published npm install, giving the Plugin Manager a real settings form and validation at activation. It does not resolve from a linked development bundle, so the import is guarded and the plugin stays correct either way; the defaults live in resolveConfig rather than only in the schema.