@xmoon76/dsh-profile-settings
DeepSeek Harness 的按配置文件设置叠加层：全局 settings.yaml 加上 profiles/<name>/settings.patch.yml，并透明地叠加到 ctx.settings 下
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:XMoon/dsh-profile-settings#5bff86db924103666fb024a10442c8275bf7c7c0Profile Settings 以 @xmoon76/dsh-profile-settings 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
点击下方 Badge 复制 Markdown，粘贴到 README 即可。
验证 package.json 声明的 GitHub 仓库，即可管理这个公开页面。认领后，Hub 会优先安排当前版本的安全扫描，并在通过后公开展示结果。
认领这个 Plugin →English | 中文
A DSH profile bundle that adds a per-profile settings overlay on top of the
official user-settings seam. $DSH_HOME/settings.yaml stays the global
baseline; every profile can override any settings namespace through its own
$DSH_HOME/profiles/<name>/settings.patch.yml — object sections merge
recursively, arrays and scalars replace wholesale, and !unset explicitly
deletes an inherited value.
Schema Defaults
↓
Composition Base
↓
~/.dsh/settings.yaml (global user layer)
↓
~/.dsh/profiles/<name>/settings.patch.yml (profile user layer)
↓
Effective Settings
Existing plugins keep using ctx.settings exactly as before — the overlay is
transparent. Writes (update / replace / mutate) land in the profile
overlay only; replace({}) re-inherits the global layer, never the
composition default. The official schema validation, revision semantics,
expectedRevision conflict detection, watchers, and events are untouched.
Requires a profile whose bundles include @deepseek-ai/dsh-base (every
shipped web / headless template does). Install into each profile that
should get its own overlay:
dsh plugin --profile web add @xmoon76/dsh-profile-settings
dsh plugin --profile pi-tui add @xmoon76/dsh-profile-settings
dsh plugin --profile <name> add installs the package and reconciles it into
the profile's dsh.profile.bundles automatically (the manifest declares
dsh.bundle). On the next boot the bundle patch (cordis.patch.yml)
settings row (@deepseek-ai/dsh-settings-file), andprofile-settings row owning ctx.settings.One composition may only hold one ctx.settings owner: if the base row is
still active beside this one, boot fails loud (Cordis duplicate-service
error) — never a silent override.
The inserted row needs no config (defaults below); a profile's own
cordis.patch.yml may override the row's config:
| key | default | meaning |
|---|---|---|
profile | auto-detected | explicit active profile name |
globalPath | $DSH_HOME/settings.yaml | global settings document |
profileFile | settings.patch.yml | overlay filename inside the profile dir |
dshHome | $DSH_HOME or ~/.dsh | harness home |
watch | true | hot-reload both documents |
debounceMs | 100 | watcher write-settle window |
writable | true | allow in-process writes into the overlay |
The active profile is resolved in this order (never from cwd): explicit
profile config → install location
(profiles/<name>/node_modules/…, the dsh plugin layout) → launcher
--profile <name> / --profile=<name> → DSH_PROFILE environment variable.
If none can be determined, boot fails loud.
# $DSH_HOME/profiles/web/settings.patch.yml
agent-default-model:
provider: pi-ai
model: gpt-5.6
permission:
mode: danger-full-access
some-plugin:
endpoint: !unset
Plain YAML values are overrides; !unset masks the lower layers (the
inherited value is deleted and the schema default applies unless the overlay
supplies its own value). Masks never enter the resolved JSON document — the
UI never sees them as values. The file is edited by hand or through the
settings command; in-process writes land here, never in settings.yaml.
settings commandWhen a command runtime is mounted, ctx.profileSettings and the settings
command family are available:
settings layers [ns [path]] per-leaf source provenance
settings get <ns.path> effective value
settings set <ns.path> <value> write the profile overlay
settings unset <ns.path> delete an overlay value (re-inherit)
settings mask <ns.path> write !unset
settings unmask <ns.path> remove the mask
settings reset <ns> replace({}) on the overlay
settings promote <ns.path> move a value up to the global document
settings demote <ns.path> move a value down to the profile overlay
settings migrate <ns.path> [--copy] move a global value into the overlay with
.bak.<timestamp> backups (--copy keeps it)
settings diff [ns] leaf-level global vs overlay diff
settings ui [ns] machine-readable layer snapshot (Web UI)
settings profile active profile and document paths
The bundle ships a browser half (dsh.client): the web Settings panel gains
a Profile Settings section with per-field source badges (Default /
Composition / Global / Profile / Masked), the effective value, and
set / unset / mask / unmask / promote / reset actions. All host interaction
flows through the /profile-settings loopback RPC channel registered by the
host half — no session context, no command logs.
The provider keeps the official base-class document as the profile raw
section, so update/replace/mutate/revision/expectedRevision/
describe keep their exact semantics; the global layer is folded into each
registration's composed base (applyMasks(merge(composition, global), masks)).
Only a narrow typed facade over the base class's TS-private members is
touched — no Settings machinery is forked. See docs/research.md for the
full M0 findings.
Fail-loud (boot): unresolvable profile, overlay root not a map, non-object
namespace section, !unset inside an array, unsupported YAML tags
(!!js/*, !!python/*, custom tags), overlay path escaping the profile
directory, global and overlay pointing at the same file, duplicate
ctx.settings owner.
Warn + keep last good (hot reload): temporarily invalid YAML in either document, unregistered namespaces (they are preserved for later-loading plugins).
| Scope | Guarantee |
|---|---|
In-process ordinary update/replace/mutate | official Settings semantics (per-namespace serialized write queue, expectedRevision conflict detection) |
| Cross-process file integrity (read-modify-write) | writer locks on both documents + atomic rename |
Cross-process custom layer operations (promote/demote/migrate/mask/unmask) | true transactions: both locks in a fixed order, fences checked inside the locks, layer revisions advance on every text change |
Cross-process ordinary update/mutate on the SAME profile + namespace | inherits the official seam limitation: the official revision is process-local to its write queue, so cross-process CAS on one namespace is best-effort (the last writer wins under the file lock) |
npm run typecheck # tsc over src + tests
npm test # vitest
npm run build # tsc build + copy-lib (lib/)
npm pack # prepack build + postpack tarball smoke (leak checks)
Requires Node ≥ 22.6 (type stripping) and a DSH harness (0.1.1-rc.2 family) for the peer dependencies, which resolve from the running installation — the package never bundles its own harness copy, so no module twin.
MIT