A DeepSeek session whose screen names no model (dsh-TUI's status bar model
field off, or not drawn yet) can still name the model its route config pins
(owner request). src/deepseek-route-config.ts resolves it the way dsh and
dsh-TUI 0.10.0-beta.1 do, for the session's profile (else the one the launch
boots) under the session's dsh home:
- dsh composes a profile from patch layers: the bundles, then
profiles/<profile>/cordis.patch.yml, then $DSH_HOME/cordis.patch.yml (which
outranks it). A patch's `config` replaces the dsh-tui row's whole config, a
`name` mismatch skips it, `disabled` turns the row off.
- dsh-TUI takes its route from that config only when it names BOTH provider and
model (modelRoute.js); anything less falls back to state the config does not
hold, so the answer is nothing. The bundle row pins a provider alone by
design and is not read (it resolves outside the dsh home); settings.yaml's
agent-default-model is the headless default and is never read.
- Any doubt answers nothing: a profile without dsh-TUI, a half-pinned route,
an unreadable or oversized layer, a symlink out of the dsh home, a mount that
does not answer, a file beyond a narrow strict YAML subset (no dependency
added: plain keys, single-line string scalars for the values it needs; tags,
anchors, aliases, merge keys, multi-line scalars, flow or block-scalar
config, duplicate keys, typed scalars, a second document, or a nested row
re-defining dsh-tui all answer null).
- Bounded and read-only: every path is probed with probePathKind() first, read
async with a 64 KiB cap, and must realpath inside the dsh home. Only the
model id leaves the module.
The default-profile inventory reuses the resolver's classification through a
new pure deepSeekProfileFromManifest(), read with the same bounded rules.
Not wired to sessions yet; the next commit does.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
