dsh-approval-explainer

Configuration

Not configurable through cordis.yml today. The tunables are constants at the top of lib/index.js, each with a measured rationale:

Constant	Default	Purpose
GENERATE_TIMEOUT_MS	40000	Generation deadline. Measured successes take 5–9 s
ENTRY_TTL_MS	600000	Annotation cache lifetime
MAX_ARGS_CHARS	12000	Tool-argument budget fed to the model
MAX_REASONING_CHARS	4000	Model reasoning budget
MAX_ASSISTANT_TEXT_CHARS	2000	Model answer budget
MAX_ENTRIES	200	Cache size cap

Why these are not config fields

The DSH documentation states a convention in Plugin configuration:

No hardcoded tunables — any value a deployment might need to change must be a config field. Test: can you change it in cordis.yml without editing code?

By that test all six should be exported as a Schemastery Config schema. They are not. This is a known deviation, and the reasons are measured rather than assumed:

1. It requires resolving a peer dependency before apply. Exporting Config needs import Schema from '@deepseek-ai/schemastery', and that package does not resolve from the plugin's own directory (measured: Cannot find module). Only the host runtime's peer resolution can supply it.
2. The import is evaluated before apply, so the plugin's try/catch cannot cover it. A resolution failure is a module load failure and marks the fiber FAILED — the exact failure class behind this plugin's early crashes.
3. The convention is a guideline, not a gate. Of six installed bundles on the author's machine, one exports Config; the other five — including a mature 190 KB plugin — do not.

The practical impact is limited: all six defaults are measured and work unchanged. Editing the constants and restarting covers the need.

One invariant if you edit them

lib/client.js polls POLL_LIMIT (120) × POLL_INTERVAL_MS (350 ms). That window must be ≥ GENERATE_TIMEOUT_MS, or the host is still generating while the panel has given up — the annotation is produced and thrown away while the user sees a failure.

The nominal window is 42 s, but the loop requests before it sleeps, so the last request lands at 119 × 350 ms ≈ 41.65 s. Change both values together.