Desktop shell configuration independent of the Host
Desktop 壳层配置独立于 Host
Desktop updates and native recovery can run before the Host starts or while it is unavailable. Depending on Host configuration prevents these functions from resolving their preferences when needed. A shared settings page does not identify which process owns each preference.
English
Problem
Desktop updates and native recovery can run before the Host starts or while it is unavailable. Depending on Host configuration prevents these functions from resolving their preferences when needed. A shared settings page does not identify which process owns each preference.
Decision
Electron main owns userData/desktop/settings.json independently of Host startup and Cordis evaluation. The test authentication popup switch uses this file; the Desktop reference owns its fields and behavior.
Ownership follows runtime dependencies: Electron-owned functions needing configuration before Host startup or while the Host is unavailable use shell configuration. Host plugin settings, including shared Web/Desktop preferences, continue to use Cordis. Displaying a setting in Desktop alone does not justify shell ownership. A unified settings interface can use separate storage owners.
The desktop subdirectory groups shell configuration without relocating existing files. The shortcut decision retains ownership of userData/keybindings.json and its persistence semantics. The shared Web application decision still governs Host composition and profile configuration.
Alternatives considered
Put every preference in Cordis. This requires a working Host. Reading cordis.patch.yml directly in Electron duplicates configuration evaluation; a patch alone omits plugin defaults and other configuration layers.
Move every setting shown in Desktop. Interface placement does not imply a Host-independent requirement. This splits shared Web/Desktop preferences and moves configuration away from its consuming plugins.
Consequences
Shell and Host configuration have separate owners. Each setting needs documented ownership and effective timing. Independent shell configuration supports additional Host-independent functions without introducing a second application backend.
Existing settings are candidates for individual evaluation when their functionality changes or a Host-independent use is required. This is an evaluation direction, not a scheduled migration or predefined list. A migration must identify a single authoritative source, transfer existing values and define when changes take effect, without ambiguous precedence between two stores. Shared Host-managed settings remain in Cordis unless their ownership requirements change.
中文
Problem
Desktop 更新和原生恢复可以在 Host 启动前或不可用时运行。依赖 Host 配置会使这些功能无法在需要时解析偏好。统一设置页面不能决定每项偏好由哪个进程负责。
Decision
Electron 主进程负责 userData/desktop/settings.json，不依赖 Host 启动或 Cordis 求值。测试鉴权弹窗开关使用此文件；Desktop 参考文档统一说明字段和行为。
配置归属按运行依赖划分：由 Electron 负责且需要在 Host 启动前或不可用时读取配置的功能，使用壳层配置。Host 插件设置，包括 Web/Desktop 共用偏好，继续使用 Cordis。仅仅展示在 Desktop 中，不构成归属壳层的理由。统一设置界面可以使用不同的存储归属。
desktop 子目录集中存放壳层配置，不迁移已有文件。快捷键决策继续负责 userData/keybindings.json 及其持久化语义。共享 Web 应用决策仍约束 Host 组合和 profile 配置。
Alternatives considered
所有偏好都放入 Cordis。 这需要可用的 Host。由 Electron 直接读取 cordis.patch.yml 会重复实现配置求值；单独的 patch 不包含插件默认值和其他配置层。
迁移所有在 Desktop 展示的设置。 界面位置不意味着需要独立于 Host。这会拆分 Web/Desktop 共用偏好，并让配置脱离实际使用它的插件。
Consequences
壳层与 Host 配置分别有自己的归属。每项设置需说明归属和生效时机。独立壳层配置支持更多不依赖 Host 的功能，但不引入第二套应用后端。
现有设置在功能调整或需要独立于 Host 使用时，可逐项评估。这是评估方向，不是已排期的迁移计划或预设清单。实际迁移需明确唯一配置来源、迁移已有值并定义生效时机，避免两套存储间存在含糊的优先级。共用的 Host 设置在归属要求不变时继续使用 Cordis。