当前开发版本：
0.3.0-alpha.1。该版本不是 release candidate。
面向个人用户和非技术用户的 DeepSeek Harness Windows 桌面启动器。
dsh-studio 的目标是让用户不必先学习 Cordis、Profile、Bundle 或命令行，就能在 Windows 上安装、配置、启动和检查 DeepSeek Harness。
它不替代 DeepSeek Harness，也不重新实现 Agent、插件、Session、Tool、Provider 或插件市场。Harness 负责真正的运行行为；Studio 只负责把常用操作组织成一个简单、安全的桌面流程。
目标用户包括：
- 希望在个人电脑上使用 DeepSeek Harness，但不想手写配置的用户；
- 需要固定、可重复启动环境的个人开发者；
- 只想选择预设、填写模型配置并启动 Agent 的非技术用户。
默认操作路径应保持为：
安装或检查 Runtime
→ 选择 Agent Preset
→ 配置模型、工作区和能力开关
→ 启动
→ 查看状态或进行一次测试
用户不应为了完成这条路径而理解插件树、Service 依赖、Patch 层级或 Harness 内部对象。
第一阶段只交付一个可用的 Windows 启动器。
- 检查受支持的 Harness Runtime 是否存在；
- 启动、停止和重启受管 Runtime；
- 显示版本、运行状态和经过脱敏的启动错误；
- 固定并校验受支持的 Harness 与 Node 版本。
- 选择一套受支持的 Agent Preset；
- 配置模型、工作区和少量能力开关；
- 设置 Credential，但不在项目文件或界面回读密钥值；
- 对输入进行结构、长度和允许字段校验。
- 将用户选择转换为 Harness 官方支持的配置或 Patch；
- 由 Harness 的真实规则和 Runtime 决定配置是否有效；
- 应用失败时保留或恢复上一个可启动配置；
- 不让 Renderer 直接访问插件代码、Credential 或 loopback Runtime。
- 区分“配置有效”“Runtime 已启动”和“Agent 可用”；
- 将 Harness 返回的失败整理为简短、可操作、经过脱敏的诊断；
- 提供一个最小 Test Agent 入口，仅用于验证当前配置能够完成一次对话；
- Test Agent 不发展成完整聊天客户端或 Agent IDE。
为了控制项目范围，以下能力不属于第一阶段，也不应成为发布前置条件：
- 自建插件市场、社区爬取、排行、评论、更新或卸载系统；
- 用自然语言搜索插件；
- 面向普通用户的插件树、Composition Tree 或拖拽编排器；
- Agent 数据流、执行工作流、连线画布或可编辑依赖图；
- 任意第三方插件的自动安装、信任判断和兼容性承诺；
- 完整 Profile、Bundle、Cordis 或 Patch IDE；
- 多会话管理、附件管理、Prompt 工作台或完整 Agent 聊天客户端；
- 云同步、团队协作、账号系统、自动更新服务或插件发布平台；
- macOS、Linux 和移动端交付。
插件发现与生态市场应优先使用已有项目，例如 dsh-market 和 dsh-find-plugins。Studio 最多提供外部入口或导入候选；是否纳入受管配置，仍须经过本地版本和边界校验。
Harness 的底层组合仍然存在，但不是默认产品界面。
- 普通模式只展示 Preset、模型、工作区和能力开关；
- 必要的 Patch 由 Studio 确定性生成，不要求用户手工组织每个插件；
- 原始配置或最终组合可以作为只读诊断信息；
- 只有真实用户需求证明基础启动器不够用时，才考虑增加受限的高级编辑；
- 历史 React Flow 画布已移除，不得重新引入。
任何新功能进入路线图前，都必须同时满足：
- 直接帮助目标用户完成安装、基础配置、启动或故障定位；
- 不能更合适地由 Harness 或现有生态项目完成；
- 不要求 Studio 复制 Harness 的运行语义；
- 不显著增加第一阶段的安装、测试和维护负担。
不满足以上条件的功能默认不做。
项目处于开发阶段，不是 release candidate。代码库源自更宽的“Composition Studio”方向；React Flow、Catalog、Inspector 和图编辑代码已从可执行产品表面移除。相关设计与证据仅保存在 docs/history/，不构成当前产品承诺。
当前实现已经提供受支持设置的精确校验、Runtime 生命周期、Credential write-only 编排、三层就绪状态、串行 candidate Apply、last-known-good 恢复、明确的 recovery-required 状态和单 Session Test Agent。verify:runtime 使用隔离的临时 Profile 与真实 pinned Runtime 验证 minimal Session 创建/恢复和模型选择；fake Runtime/RPC 测试只用于证明 Desktop 协调与失败边界。
这不等于已经形成 release candidate。真实 Credential 下的 prompt/stream/stop、完整故障注入、同一候选 Runtime/Windows 打包以及干净 Windows x64 人工验收仍是发布门槛。当前证据矩阵见 docs/implementation-status.md。
当前 Runtime 基线为：
- DeepSeek Harness
0.1.0-rc.5； - upstream commit
066cdc25303d6daed99a6d1db222e867270deb12； - Windows x64；
- Node
24.12.0，记录于config/runtime.lock.json。
| DeepSeek Harness | dsh-studio |
|---|---|
| 加载和运行 Agent 与插件 | 管理受支持 Runtime 的启动和停止 |
| 解释 Profile、Bundle、Preset 和 Patch | 把少量用户选项转换为受支持配置 |
| 管理 Session、Tool、Provider 和 Service 生命周期 | 提供最小测试入口并展示结果 |
| 给出真实运行状态和错误 | 展示经过筛选、脱敏的状态与诊断 |
| 决定配置最终能否运行 | 在应用前做输入校验，并在失败时恢复 |
Studio 必须通过 bundle、Cordis 插件、Client module、Service/event 和受限 RPC/IPC 使用上游能力，不 fork Harness，也不维护一套平行的运行引擎。
- Credential、Session ID、消息、工具数据和本机恢复状态不进入可分享项目；
- Renderer 不直接连接 Harness loopback HTTP/WS，也不加载任意插件代码；
- IPC、项目输入和诊断输出必须经过结构、大小和字段边界校验；
- 日志和错误必须脱敏，界面只显示 Credential 是否已配置；
- Runtime 和配置变更由桌面主进程统一编排，避免多个组件同时修改受管 Profile。
| 路径 | 职责 |
|---|---|
apps/desktop |
Electron Main、preload、Renderer、Runtime 生命周期和 Harness RPC |
packages/core |
Studio 契约、解析、校验和确定性配置转换 |
packages/harness-host |
项目服务、Runtime lock、诊断和受管 Profile |
packages/harness-client |
桌面配置、状态、诊断和最小 Test Agent UI |
packages/harness-bundle |
将 Studio Host/Client 接入 Harness Profile |
packages/studio-tools |
仓库工程验证工具 |
tests/e2e |
跨包和 pinned Runtime 流程测试 |
scripts / packaging |
Runtime 校验、装配与 Windows 打包 |
deepseek-harness 和 deepseek-harness-guide 是只读上游参考。lib/、dist/、runtime/ 和 release/ 是生成物，不是源码证据。
目标工具链是 Node 22.19+ 或 24、pnpm 11.21.0 和 Windows x64。
corepack pnpm install --frozen-lockfile
corepack pnpm -r --if-present typecheck
corepack pnpm exec tsc -p tsconfig.scripts.json --noEmit
corepack pnpm test
corepack pnpm -r --if-present buildWindows 发布还需要验证 pinned upstream、装配 Runtime、构建安装包，并由用户执行真实 Windows 应用验收。README 的范围调整不代表当前工作区已经满足这些发布门槛。
本 README 定义新的收缩方向。docs/ 中部分文档仍描述此前的 Composition Studio 目标，在完成产品评审和代码盘点前，应视为待迁移的旧目标，而不是启动器第一阶段的承诺。
后续文档重构应依次更新产品范围、架构、项目格式、实施状态和发布验收，并将不再适用的设计移入 docs/history/。