dsh-model-retry-settings

Configuration

The card is the only surface. There is no Loader config file to edit and no plugin-specific state outside the settings document.

What	Where
the preference	the fields enabled and maxRetries of the model-retry-settings settings namespace
what that namespace is	this plugin's own Loader entry Config (id: model-retry-settings in cordis.patch.yml) — since dsh 0.1.7 an entry's Config is its settings namespace
how the card reads and writes it	ctx.configForms.get('model-retry-settings'), the same shared fenced form the host publishes, so a save is an ordinary settings mutation and the host stays the only authority on whether a value was accepted
what happens to the running process	nothing to restart: both fields are .volatile(), so a save updates the value in place on the running fiber and the next failed request reads the new number

The entry id, the settings namespace, the client's ctx.configForms.get(...) and the settings.models.footer registration id are all model-retry-settings and must agree; cordis.patch.yml carries the same value.

There is no build step. lib/index.js (host) and lib/client.js (browser) are hand-authored in the forms dsh loads them in — plain ESM for the host, and the module loader's window.__ModuleLoader__.load({ id, factory }) factory form for the browser, which is also why the plugin needs no bundler.

Development scripts, all run from the clone:

sh scripts/verify.sh           # 37 checks against the real dsh SDK (host + browser halves)
sh scripts/install.sh          # pack to dist/ and print the install path
sh scripts/dev-profile.sh boot # boot this plugin in an isolated profile on :19499
sh scripts/dev-profile.sh dump # print the composed profile tree
sh scripts/dev-profile.sh url  # print the served client-bundle URL
sh scripts/dev-profile.sh remove

sh scripts/dev-profile.sh writes only under .dev-home/ inside the clone: a private dsh home with its own profile, so the profile the desktop app is using is never touched. That is also where a change is cheapest to check — a fresh boot composes the profile with the plugin already in it, so it activates. test/README.md documents exactly what each suite proves.