DeepSeek Harness Plus 0.2.0

DeepSeek Harness Plus 0.2.0

中文

DeepSeek Harness Plus 0.2.0 是一次面向本地桌面使用体验的完整升级。它打通了三个日常高频流程：直接打开 Harness 实际使用的配置文件、让 Web Search 跟随当前模型配置、通过可视化 Supervisor 管理和排查本地 Web runtime。亮点不在于增加更多开关，而在于让配置、运行、重启和故障定位形成可操作的完整闭环。

谁适合升级

建议以下用户从 0.1.0 升级：

• 在 Windows、WSL2 或 Linux 上使用 DeepSeek Harness Plus 桌面版。
• 需要直接查看或编辑当前 Harness 实际使用的配置文件。
• 使用 OpenAI Responses 兼容 provider，并希望 Web Search 跟随当前选中的 provider/model。
• 经常重建或重启本地 Harness，希望明确看到当前分支、revision、进程和构建日志。
• 希望 Web runtime 重启后页面自动恢复，而不是手动刷新并逐个寻找被中断的会话。

完整功能变化

1. 从设置页打开真实配置文件

设置页现在提供稳定的“打开配置文件”操作，目标是当前 Host 实际使用的 $DSH_HOME/settings.yaml，而不是浏览器猜测出的路径或项目目录中的示例文件。

完整操作链路如下：

1. settings-file 确认并准备当前 settings document。
2. 浏览器调用无路径参数的 settings.openDocument。
3. Host 再次解析自己持有的配置文件路径。
4. Host 把文件交给当前操作系统的原生打开机制。

这意味着文件路径始终由 Host 管理，不会暴露给浏览器，也不会因为前端工作目录不同而打开错误文件。

各平台行为：

• Windows：通过 PowerShell Invoke-Item 使用系统文件关联打开 YAML。
• WSL2：先用 wslpath -w 把 Linux 路径转换成 Windows/UNC 路径，再解析 Windows PowerShell 可执行文件并调用 Invoke-Item。
• Linux：通过 xdg-open 交给系统默认应用。
• macOS 源码运行环境：通过系统原生文本文件打开方式处理；本版本不提供公开 macOS 安装包。

WSL2 检测不再只依赖 WSL_INTEROP 或 WSL_DISTRO_NAME。即使 Supervisor 没有继承这些环境变量，也能根据 Microsoft WSL kernel release 识别 WSL2。这正是本版本在实际 WSL2 环境中修复的主要问题。

2. Settings 操作与 Host 实际能力保持一致

配置文件操作现在区分两个事实：

• 当前 settings provider 是否拥有可准备的本地文档。
• 当前 Host 是否能够把该文档交给原生应用。

用户体验上的变化：

• 文件型 settings provider 的操作入口保持稳定，不会因为 metadata 尚在加载而错误消失。
• 点击操作时由 Host 准备和打开文件，页面不自行拼接路径。
• 原生打开不可用时，界面明确表现为不可用状态，而不是提供一个点击后必然失败的假入口。
• 配置文件缺失时，可由 settings provider 以正确权限创建后再打开。

3. Web Search 跟随当前 provider 和 model

Web Search 不再默认假设用户一定使用 DeepSeek 官方 credential。当前搜索链路会读取 agent 实际选中的 provider/model，并选择与它匹配的搜索实现。

本版本支持的主要体验：

• 当前模型来自 OpenAI Responses 兼容 provider 时，使用该 provider 的 base URL、credential reference 和 model 进行搜索。
• 本机一类 link_api / gpt-5.6-sol 配置可以直接沿当前模型链路执行 Web Search。
• 显式配置的 DeepSeek 搜索模式继续保留，不会被移除。
• 当前协议不支持搜索时会明确失败，不会静默改走另一套 credential 或产生难以解释的认证错误。

对用户而言，模型选择和 Web Search 使用的是同一份运行时事实，不再需要维护两套容易漂移的 provider 配置。

4. 独立的本地 Runtime Supervisor

0.2.0 引入 Supervisor 作为 Harness Web runtime 的单一生命周期管理入口。桌面托盘和进度页不再各自直接管理进程，而是把命令交给 Supervisor control socket。

Supervisor 支持：

• 启动 Harness Web。
• 停止 Harness Web。
• 重启当前 runtime。
• 重新构建并重启 runtime。
• 在重建命令中选择目标分支。
• 串行执行维护操作，避免重复点击同时触发多个 restart/build。
• 将完整构建输出写入持久 runtime log。
• 将当前运行身份写入 Supervisor manifest。

进度页会显示：

• 安装路径。
• DSH_HOME。
• 当前 Git branch 和 revision。
• 工作树是否存在未提交改动。
• Web 端口和 progress 端口。
• Web PID 与 watcher PID。
• 当前 operation、phase 和最终结果。

默认本地布局为：

• Production Web：http://127.0.0.1:3080
• Production progress：http://127.0.0.1:3082
• Candidate Web：http://127.0.0.1:3081
• Candidate progress：http://127.0.0.1:3083

5. Supervisor 进度页重新设计

进度页从简单状态展示升级为面向重复运维操作的工作界面。

主要变化：

• 统一 DeepSeek Harness Plus 品牌，移除重复或不一致的标题和阶段信息。
• Runtime identity 独立展示，用户可以先确认“正在操作哪一个 runtime”。
• 活动时间线和原始运行日志使用固定高度、独立滚动区域，长时间构建不会把整个页面无限撑长。
• 日志按内容区分 phase、success、warning、error、command 和 artifact，错误与产物更容易定位。
• 操作按钮使用明确图标和状态，不需要依赖冗长说明文字理解动作。
• 当前 operation 运行时会禁用冲突操作，避免重复提交。
• 保留完整 raw output，简化状态不会替代真正的编译器和 runtime 日志。
• 窄屏和桌面布局都保持信息可读，不让日志、按钮或身份字段互相遮挡。

6. Plugin HMR 与 Web runtime 重启采用不同恢复方式

0.2.0 区分两类更新：

• 纯 client plugin rebuild：继续使用 HMR，只替换对应 Cordis plugin fiber，不刷新整页，当前页面和会话位置保持不变。
• 完整 Web runtime 重启：SSE 断开并重新连接后，现有页面自动 reload，使 shell、Host、core 和 bundle 使用新构建结果。

当 Web runtime 重启前存在正在运行的会话时，浏览器会记录这些 session id。页面重新连接后，会为对应会话排队发送以下恢复提示：

请继续完成任务，如果都已完成则回复没有未完成的任务即可

用户不需要在重启后逐个寻找会话并手动输入继续命令。已经完成的任务可以直接回复没有未完成任务，仍在进行的任务可以继续执行。

7. Candidate-first 本地开发与验收流程

本版本把候选环境优先的工作方式写入仓库规则和专用 skill，减少未验收改动直接影响 3080 的情况。

规则如下：

• 只有确认运行着 production watcher 的纯 client-plugin source edit 可以使用 3080 HMR。
• Web shell、client runtime、HMR infrastructure、Host、Supervisor、desktop、settings/schema、dependency、lockfile 和 bundle composition 改动都必须使用 candidate。
• Candidate 使用独立 Git worktree、独立 DSH_HOME、3081 Web 和 3083 progress。
• Candidate 完成真实 UI 验收后，才能由用户明确授权 promotion 到 production 3080/3082。
• Production worktree 不作为普通非 HMR 开发工作区。

这项变化主要服务维护者，但最终收益是用户看到的 production 页面始终对应已经验收的候选结果。

8. 原 PR 与本地汇总分支的同步规则

本版本补充了 Plus 的 PR 协作规则：本地汇总分支已经包含用户确认的完整改动，而原远端 PR 落后时，应把完成内容同步回原 PR，而不是关闭原 PR、另建竞争 PR 或擅自改变 PR 拆分方式。

该规则保留原 PR 的编号、评审历史和功能边界，使远端审阅内容与用户已经验收的本地结果一致。

从 0.1.0 升级后最直观的变化

0.1.0	0.2.0
配置文件通常需要手动寻找	从 Settings 直接打开 Host 实际使用的配置文件
WSL 可能被误判为普通无桌面 Linux	可从 Microsoft kernel 识别 WSL2 并调用 Windows 默认应用
Web Search 与当前模型配置可能分离	Search 跟随当前 provider/model
重建状态主要依赖托盘提示和原始日志	通过 3082 页面查看完整 runtime identity、阶段和日志
Web 重启后需要手动刷新和恢复会话	页面自动 reload，并向被中断的运行会话发送继续提示
非 HMR 改动可能直接在 production 工作树处理	非 HMR 改动先进入隔离的 3081/3083 candidate

下载与安装包

平台	文件	大小
Linux AppImage	deepseek-harness-plus-0.2.0.AppImage	115,578,976 bytes
Debian / Ubuntu	deepseek-harness-plus-0.2.0.deb	90,450,904 bytes
Windows	DeepSeek.Harness.Plus.Setup.0.2.0.exe	93,694,226 bytes

macOS 安装包仍未公开发布，需等待签名和 notarization 配置完成。源码中的 macOS 路径打开逻辑不等于提供了可分发的 macOS 安装包。

兼容性与升级说明

• 本版本没有修改 agent-loop。
• 本版本没有修改 session durable format。
• 现有 settings 仍由 DSH_HOME 下的 settings provider 管理。
• 当前桌面发行范围为 Linux 和 Windows。
• 当前 Harness runtime 仍建议运行在私有本地环境；本版本没有提供多用户或公网部署 preset。

本版本不包含

以下内容仍未进入 0.2.0：

• Draft PR #3 中的模型能力配置界面。
• 可见的 context window 和 maximum output token 设置。
• 图片理解与真实图片生成能力的独立声明。
• 图片生成 runtime 输出链路。
• 代码开发、智能问数、多用户、AIGC 和社区运营 presets。
• macOS 签名、notarization 和公开安装包。

验证证据

• Settings、native opener 和 config API 聚焦测试：67/67 通过。
• HMR/runtime 聚焦测试：11/11 通过。
• Feature、skill 和 release 文档门禁：doc-sync 28/28 通过。
• Linux AppImage/deb 在本地和 GitHub Actions 中完成真实打包。
• Windows NSIS installer 在 GitHub Actions 中完成真实打包。
• Candidate 3081 和 production 3080 均通过真实 Settings UI 调用 settings.openDocument，返回 opened: true，页面无错误提示。
• Tag workflow 成功生成并上传三个 0.2.0 资产。
• 三个公开下载地址均已实际请求验证，返回 HTTP 200。

关联改动

• PR #4 — Settings、当前模型搜索与系统默认应用 opener
• PR #5 — Supervisor、进度页与 Web 重启恢复
• PR #6 — 0.2.0 版本和发布元数据

完整变更范围固定在 tag plus-v0.2.0。

---

English

DeepSeek Harness Plus 0.2.0 is a comprehensive upgrade focused on the local desktop experience. It connects three high-frequency daily workflows: directly opening the configuration file actually used by Harness, making Web Search follow the current model configuration, and managing and troubleshooting the local Web runtime through a visual Supervisor. The focus is not on adding more switches, but on creating an actionable closed loop for configuration, operation, restart, and fault diagnosis.

Who Should Upgrade

The following users are recommended to upgrade from 0.1.0:

• Users of the DeepSeek Harness Plus desktop app on Windows, WSL2, or Linux.
• Users who need to directly view or edit the configuration file currently used by Harness.
• Users of an OpenAI Responses-compatible provider who want Web Search to follow the currently selected provider/model.
• Users who frequently rebuild or restart local Harness and want clear visibility into the current branch, revision, processes, and build logs.
• Users who want the page to recover automatically after a Web runtime restart, rather than manually refreshing and locating interrupted sessions one by one.

Complete Feature Changes

1. Open the Actual Configuration File from Settings

The Settings page now provides a reliable “Open Configuration File” action. Its target is the $DSH_HOME/settings.yaml actually used by the current Host, rather than a path guessed by the browser or an example file in the project directory.

The complete workflow is as follows:

1. settings-file confirms and prepares the current settings document.
2. The browser calls settings.openDocument with no path arguments.
3. The Host resolves the configuration file path it holds again.
4. The Host passes the file to the current operating system's native open mechanism.

This means that the file path is always managed by the Host, is not exposed to the browser, and cannot open the wrong file because the frontend has a different working directory.

Platform behavior:

• Windows: Opens the YAML using the system file association through PowerShell Invoke-Item.
• WSL2: First converts the Linux path to a Windows/UNC path with wslpath -w, then resolves the Windows PowerShell executable and calls Invoke-Item.
• Linux: Passes the file to the system default application through xdg-open.
• macOS source-run environments: Uses the system's native text-file opening mechanism; this release does not provide a public macOS installer package.

WSL2 detection no longer relies solely on WSL_INTEROP or WSL_DISTRO_NAME. Even when the Supervisor does not inherit these environment variables, it can identify WSL2 from the Microsoft WSL kernel release. This is the primary issue fixed in real WSL2 environments in this release.

2. Settings Actions Match Actual Host Capabilities

Configuration file actions now distinguish between two facts:

• Whether the current settings provider has a local document that can be prepared.
• Whether the current Host can pass that document to a native application.

Changes to the user experience:

• The action entry point for file-based settings providers remains stable and does not incorrectly disappear while metadata is still loading.
• When the action is clicked, the Host prepares and opens the file; the page does not construct the path itself.
• When native opening is unavailable, the UI clearly shows an unavailable state instead of presenting a false entry point that is certain to fail when clicked.
• When the configuration file is missing, the settings provider can create it with the correct permissions before opening it.

3. Web Search Follows the Current Provider and Model

Web Search no longer assumes by default that users must use official DeepSeek credentials. The current search path reads the provider/model actually selected by the agent and chooses the search implementation that matches it.

The primary experiences supported by this release:

• When the current model comes from an OpenAI Responses-compatible provider, search uses that provider's base URL, credential reference, and model.
• A local link_api / gpt-5.6-sol configuration can perform Web Search directly through the current model path.
• Explicitly configured DeepSeek search modes remain available and are not removed.
• When the current protocol does not support search, it fails explicitly rather than silently switching to another set of credentials or producing hard-to-explain authentication errors.

For users, model selection and Web Search use the same runtime facts. There is no longer a need to maintain two provider configurations that can easily drift apart.

4. Dedicated Local Runtime Supervisor

0.2.0 introduces the Supervisor as the single lifecycle management entry point for the Harness Web runtime. The desktop tray and progress page no longer manage processes directly on their own; they send commands to the Supervisor control socket instead.

The Supervisor supports:

• Starting Harness Web.
• Stopping Harness Web.
• Restarting the current runtime.
• Rebuilding and restarting the runtime.
• Selecting a target branch in the rebuild command.
• Running maintenance operations serially to prevent multiple restarts/builds from being triggered simultaneously by repeated clicks.
• Writing complete build output to the persistent runtime log.
• Writing the current runtime identity to the Supervisor manifest.

The progress page displays:

• Installation path.
• DSH_HOME.
• Current Git branch and revision.
• Whether the working tree has uncommitted changes.
• Web port and progress port.
• Web PID and watcher PID.
• Current operation, phase, and final result.

The default local layout is:

• Production Web: http://127.0.0.1:3080
• Production progress: http://127.0.0.1:3082
• Candidate Web: http://127.0.0.1:3081
• Candidate progress: http://127.0.0.1:3083

5. Redesigned Supervisor Progress Page

The progress page has been upgraded from a simple status display to a work interface for repeated operations and maintenance.

Key changes:

• A unified DeepSeek Harness Plus brand removes duplicate or inconsistent titles and phase information.
• Runtime identity is displayed separately, so users can first confirm “which runtime is being operated on.”
• The activity timeline and raw runtime log use fixed-height, independently scrollable areas, so long builds do not make the entire page infinitely tall.
• Logs distinguish phase, success, warning, error, command, and artifact by content, making errors and artifacts easier to locate.
• Action buttons use clear icons and states, without requiring lengthy explanatory text to understand the action.
• Conflicting actions are disabled while the current operation is running to prevent duplicate submissions.
• Complete raw output is retained; simplified status does not replace actual compiler and runtime logs.
• Both narrow-screen and desktop layouts keep information readable without logs, buttons, or identity fields obscuring one another.

6. Plugin HMR and Web Runtime Restarts Use Different Recovery Methods

0.2.0 distinguishes between two types of updates:

• Pure client plugin rebuild: Continues to use HMR, replacing only the corresponding Cordis plugin fiber without refreshing the entire page. The current page and session position remain unchanged.
• Full Web runtime restart: After SSE disconnects and reconnects, the existing page reloads automatically so that the shell, Host, core, and bundle use the new build output.

When there are running sessions before a Web runtime restart, the browser records those session ids. After the page reconnects, it queues the following recovery prompt for the corresponding sessions:

请继续完成任务，如果都已完成则回复没有未完成的任务即可

Users do not need to locate sessions one by one after a restart and manually enter a continue command. Completed tasks can reply directly that there are no unfinished tasks, and tasks still in progress can continue running.

7. Candidate-First Local Development and Acceptance Workflow

This release writes a candidate-environment-first way of working into repository rules and a dedicated skill, reducing cases where unaccepted changes directly affect 3080.

The rules are as follows:

• Only a pure client-plugin source edit with a confirmed production watcher running may use 3080 HMR.
• Changes to the Web shell, client runtime, HMR infrastructure, Host, Supervisor, desktop, settings/schema, dependencies, lockfile, and bundle composition must all use a candidate.
• The candidate uses an independent Git worktree, independent DSH_HOME, 3081 Web, and 3083 progress.
• Only after the candidate has completed real UI acceptance may the user explicitly authorize promotion to production 3080/3082.
• The production worktree is not used as a normal non-HMR development workspace.

This change primarily serves maintainers, but its ultimate benefit is that the production page seen by users always corresponds to an accepted candidate result.

8. Synchronization Rules for Original PRs and the Local Consolidation Branch

This release adds collaboration rules for Plus PRs: when the local consolidation branch already includes the complete user-confirmed changes but the original remote PR is behind, completed work should be synchronized back to the original PR rather than closing it, creating a competing PR, or changing the PR split without authorization.

This rule preserves the original PR's number, review history, and feature boundaries, ensuring that remote review content is consistent with the locally accepted result.

Most Visible Changes After Upgrading from 0.1.0

0.1.0	0.2.0
Configuration files usually had to be found manually	Open the configuration file actually used by the Host directly from Settings
WSL could be misidentified as ordinary headless Linux	Identify WSL2 from the Microsoft kernel and invoke the Windows default application
Web Search could be separate from the current model configuration	Search follows the current provider/model
Rebuild status mainly relied on tray notifications and raw logs	View complete runtime identity, phases, and logs through the 3082 page
After a Web restart, manual refresh and session recovery were required	The page reloads automatically and sends a continue prompt to interrupted running sessions
Non-HMR changes could be handled directly in the production worktree	Non-HMR changes first enter the isolated 3081/3083 candidate

Downloads and Installation Packages

Platform	File	Size
Linux AppImage	deepseek-harness-plus-0.2.0.AppImage	115,578,976 bytes
Debian / Ubuntu	deepseek-harness-plus-0.2.0.deb	90,450,904 bytes
Windows	DeepSeek.Harness.Plus.Setup.0.2.0.exe	93,694,226 bytes

A macOS installer package has not yet been publicly released and must wait for signing and notarization configuration to be completed. The macOS path-opening logic in the source does not mean that a distributable macOS installer package is provided.

Compatibility and Upgrade Notes

• This release does not modify agent-loop.
• This release does not modify the session durable format.
• Existing settings continue to be managed by the settings provider under DSH_HOME.
• The current desktop distribution scope is Linux and Windows.
• The current Harness runtime is still recommended to run in a private local environment; this release does not provide a multi-user or public-network deployment preset.

Not Included in This Release

The following are still not included in 0.2.0:

• The model capability configuration UI in Draft PR #3.
• Visible context window and maximum output token settings.
• Independent declarations of image understanding and actual image generation capabilities.
• The image generation runtime output pipeline.
• Presets for code development, intelligent data querying, multi-user, AIGC, and community operations.
• macOS signing, notarization, and a public installer package.

Validation Evidence

• Focused tests for Settings, the native opener, and the config API: 67/67 passed.
• Focused HMR/runtime tests: 11/11 passed.
• Feature, skill, and release documentation gate: doc-sync 28/28 passed.
• Linux AppImage/deb completed real packaging locally and in GitHub Actions.
• The Windows NSIS installer completed real packaging in GitHub Actions.
• Candidate 3081 and production 3080 both called settings.openDocument through the real Settings UI, returned opened: true, and showed no page error messages.
• The tag workflow successfully generated and uploaded all three 0.2.0 artifacts.
• All three public download URLs were actually requested and verified, returning HTTP 200.

Related Changes

• PR #4 — Settings, current-model search, and the system-default application opener
• PR #5 — Supervisor, progress page, and Web restart recovery
• PR #6 — 0.2.0 version and release metadata

The complete change scope is fixed at tag plus-v0.2.0.