dsh-openwrite 0.2.14 → 0.2.15

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -66,6 +66,8 @@ dsh web
66
66
 
67
67
  ### dsh 0.2 桌面端升级
68
68
 
69
+ `0.2.15` 候选包修复 [#63](https://github.com/LiPu-jpg/Openwrite/issues/63)/[#66](https://github.com/LiPu-jpg/Openwrite/issues/66)(Windows 残留 `project.lock` 永久阻断写作,报错 `[WinError 87]`;Core 5.8.6 自动清理死进程残留锁并带上下文报错)、[#64](https://github.com/LiPu-jpg/Openwrite/issues/64)/[#67](https://github.com/LiPu-jpg/Openwrite/issues/67)(`continuous_write` 单章失败即整队终止、`max_failures` 失效、字数超限丢弃初稿;现在按容错上限续跑并保留超长稿)、[#68](https://github.com/LiPu-jpg/Openwrite/issues/68)(横评进行中详情接口恒 400)和 [#69](https://github.com/LiPu-jpg/Openwrite/issues/69)(推理模型评审输出预算被锁死 4096 导致评审全灭)。正式可下载版本以 npm `latest` 和 GitHub Release 为准。升级后需停止并重新启动 dsh,使桥接服务端加载新代码,再刷新浏览器页面。
70
+
69
71
  `0.2.14` 候选包修复 [#60](https://github.com/LiPu-jpg/Openwrite/issues/60) 和 [#61](https://github.com/LiPu-jpg/Openwrite/issues/61):系统代理下 `NO_PROXY` 含 `[::1]` 不再让所有模型连接测试误报"服务商拒绝了请求"(桥接层消毒 + Core 5.8.5 归类为本地配置错误);Embedding 连接测试的依赖预热、硬超时与收尾兜底,加上桥接层的健康探活与 stderr 落盘,不再出现"后端活着但不服务、只能重启 dsh"的僵尸态。正式可下载版本以 npm `latest` 和 GitHub Release 为准。升级后需停止并重新启动 dsh,使桥接服务端加载新代码,再刷新浏览器页面。
70
72
 
71
73
  `0.2.13` 修复 [#57](https://github.com/LiPu-jpg/Openwrite/issues/57) 的创作页刷新循环:批注与版本读取不再作为写操作通知刷新,Core 的只读请求也不再增加工作区变更序号。正式可下载版本以 npm `latest` 和 GitHub Release 为准。升级后需停止并重新启动 dsh,使桥接服务端加载新代码,再刷新浏览器页面。
@@ -93,6 +95,8 @@ dsh web
93
95
 
94
96
  已有会话不会自动切换预设。详细操作与工作区规则见 [使用流程](docs/WORKFLOWS.md)。
95
97
 
98
+ **界面语言**:面板已内置中文与英文词典,跟随 dsh 语言设置。切换方法:Settings → General → Language → English(选择后存为 `locale.preference`)。注意 Agent 的 persona、技能说明与部分后端状态/报错信息仍以中文为主;Agent 会用你在对话中使用的语言回复。
99
+
96
100
  ## 配置模型
97
101
 
98
102
  安装和环境健康检查不需要模型 API Key,也不会调用写作模型。与 Agent 对话、生成章节和审稿需要可用的模型配置;使用收费服务商时会产生 API 费用。
@@ -0,0 +1,45 @@
1
+ # 引擎源码唯一真身(native-core)
2
+
3
+ ## 规则
4
+
5
+ 1. `native-core` 分支是 OpenWrite 引擎(Python Core:`craft/`、`contracts/`、`models/`、`tools/`、`integrations/`)的**唯一源码真身**。`main` 不携带引擎源码,只通过 `release/openwrite-*.whl` 制品依赖引擎。
6
+ 2. 引擎的任何修改必须先作为提交落在 `native-core` 并推送到远端,然后才能从该提交构建 wheel 进入 `release/`。**禁止从带未提交改动的工作树构建 wheel;禁止"只改 wheel、不回补源码"。**
7
+ 3. `release/runtime-manifest.json` 的 `sources.core.commit` 必须满足:指向 `native-core` 分支上的提交、已推送远端、且该提交的工作树与 wheel 内容完全一致(用 `git status` 确认干净,`git diff <commit> 工作树` 为空)。
8
+ 4. 当前两条消费线都以 `native-core` 为真身,形态不同:
9
+ - **dsh 插件线(本分支)**:制品依赖,`openwrite-bridge` 的 managed runtime 拉起 `release/` 里的 wheel。
10
+ - **JiuwenSwarm 迁移线(`jiuwenswarm-swarm` 分支)**:源码级依赖,`openwrite-mcp` 通过 `OPENWRITE_CORE` 直接挂载 native-core 工作树,引擎升级即时生效、无需 repack。
11
+
12
+ ## 构建 / 升级 wheel 流程
13
+
14
+ 1. 切到 native-core 的干净工作树:`git worktree add .wt-native-core native-core`。
15
+ 2. 应用引擎改动、提交、推送;**先在 native-core 上跑通引擎测试**(至少 `tests/test_managed_runtime.py`、`tests/test_embedding_runtime.py`、`tests/test_model_connection_test.py`)。
16
+ 3. 构建 wheel(纯 Python 包):`python -m pip wheel --no-deps -w dist .`,更新 `release/openwrite-<ver>-py3-none-any.whl`。
17
+ 4. 同步更新 `release/runtime-manifest.json`:`core_version`、`wheel.sha256`、`sources.core.commit`(= 本次构建的 native-core 提交)。
18
+ 5. 若依赖变化,从 wheel METADATA 重导 `release/core-requirements.in` 并用固定 uv 重建 `release/requirements.lock`。
19
+ 6. 提交 PR 走完整验收(见 [PLUGIN_MAINTENANCE](PLUGIN_MAINTENANCE.md) / [RELEASE_ACCEPTANCE](RELEASE_ACCEPTANCE.md))。
20
+
21
+ ## 事故记录:5.8.5 源码漂移(2026-10-09 修复)
22
+
23
+ **现象**:`release/openwrite-5.8.5-py3-none-any.whl` 内含 embedding 依赖预载、探测硬超时、有界收尾、httpx 构造期错误分类等源码改动(修复 #60/#61),但 `native-core` 分支上没有任何对应提交——wheel 是从带未提交改动的工作树打的,`runtime-manifest.json` 记录的 `sources.core.commit = 3a5da97` 无法复现 wheel 内容。
24
+
25
+ **后果**:
26
+
27
+ 1. 引擎源码线停留在 5.8.4,与制品线漂移;依赖源码的 JiuwenSwarm 迁移线(`OPENWRITE_CORE`)吃不到 #60/#61 修复。
28
+ 2. wheel 中 `_local_client_construction_error` 直接引用 `httpx.InvalidProxy`,而 `requirements.lock` 锁定的 `httpx==0.28.1` 并无该符号——`AttributeError` 会击穿整条连接错误分类路径。
29
+
30
+ **处理**(均已推送到 `native-core`):
31
+
32
+ | 提交 | 内容 |
33
+ |---|---|
34
+ | `e34ccdd` | 从 wheel 反解 5.8.4→5.8.5 源码差异并回流(4 文件) |
35
+ | `7a08855` | `httpx.InvalidProxy` 逐个 `getattr` 容错,兼容 0.28.1 及更早版本 |
36
+ | `d8e741c` | managed-runtime 健康检查断言改用 `tools.version.__version__`,不再硬编码 5.8.1 |
37
+
38
+ 回归:引擎三件套 33/33,蜂群桩件 18/18,MCP 写路径 6/6 全绿。
39
+
40
+ **教训**:wheel 是源码的投影,不是源码的替代品。manifest 里的 commit 必须能被 `git checkout <commit>` 后重新打出同一个 wheel。
41
+
42
+ ## 当前状态
43
+
44
+ - `native-core` HEAD:`d8e741c`(Core 5.8.5 + httpx 容错 + 测试修复)。
45
+ - `release/` 中的 wheel 仍为修复前版本;下次 repack 必须基于 `native-core` 上 ≥ `d8e741c` 的提交,并同步更新 manifest。
@@ -6,13 +6,27 @@
6
6
 
7
7
  新建作品的验收请求最多等待 60 秒(原为 15 秒),保留成功耗时和失败诊断;不重试写请求,超时仍失败。此调整容纳慢速运行器,不代表初始化耗时问题已被修复。
8
8
 
9
- ## 0.2.14 候选包
9
+ ## 0.2.15
10
+
11
+ 修复 #63/#66 Windows 残留 `project.lock` 永久阻断写章/审稿:Core 5.8.6 用 Windows 正确的进程存活探测(`OpenProcess`/`GetExitCodeProcess`)替换 POSIX 语义的 `os.kill(pid, 0)`——后者在 Windows 上被解释为发送 `CTRL_C_EVENT`(值为 0),对死进程抛 `OSError [WinError 87]` 且不被现有捕获分支覆盖,导致残留锁 100% 无法自愈。死进程持有的锁现在自动判陈旧并清理;存活探测本身失败时按"初始化宽限后视为陈旧"兜底,不再卡死写作。锁占用报错携带 operation、pid、起始时间与锁文件路径;写章/审稿不再预置 `model` 阶段标签,文件锁失败不会被误报为"模型生成失败"(阶段由流水线在真正生成时上报)。
12
+
13
+ 修复 #64/#67 `continuous_write` 单章失败即整队终止:`max_failures` 此前只在值为 1 时生效(首次失败 `1 < 2` 直接 `raise`),现在未达上限记录该章失败并继续下一章,达到上限优雅返回 `max_failures_reached`,结果附带 `failed_chapters`;`TaskCancelled` 与取消检查仍会立即中止队列。字数精简重试耗尽后不再丢弃初稿:最后一版正文标记 `length_out_of_range`/`length_warning` 保留为草稿并产生一条字数告警 issue。
14
+
15
+ 修复 #68 横评进行中详情接口恒 400:产物契约 `model_benchmark_v1` 的 `status` 枚举补齐 `running`/`cancelling`/`cancelled`,实时快照与取消终态均可通过校验。
16
+
17
+ 修复 #69 推理模型评审输出预算锁死 4096:观察到 usage 含 reasoning tokens 后评审与安全门的输出预算地板抬到 16384(仍受模型配置与上下文窗上限约束);截断后先按翻倍预算原批重试一次,仍失败才二分,且二分时不再沿用旧地板。思维链按调用计费,旧逻辑下拆分救不回来。
18
+
19
+ #65 部分落地:README 记录界面语言切换(Settings → General → Language),persona 增加语言跟随约定。英文 persona/skills 全集与后端信息英文化留待后续。
20
+
21
+ ## 0.2.14
22
+
23
+ [GitHub Release](https://github.com/LiPu-jpg/Openwrite/releases/tag/v0.2.14) 已发布,直接使用[完整 CI](https://github.com/LiPu-jpg/Openwrite/actions/runs/37679578150)验收的同一份包。来源提交 `f62f268bd2c74badc8af56ad4896164c5403def2`,SHA-256 为 `b61b2d98bac0235cb23361b2aa593e287bb47a2db24669c9893ef8e27e173549`。六组原生平台/Node、源码安装、alpha 兼容及三代宿主客户端共 11 份报告全部通过;Release 四份附件的校验值已与 CI `validated-release` 产物逐一核对。合并来源 [PR #62](https://github.com/LiPu-jpg/Openwrite/pull/62),#60、#61 随之关闭。npm `dsh-openwrite@0.2.14` 已发布,`latest` 已更新到 0.2.14;从公共 npm registry 无认证重新下载后,SHA-256 与上述 CI / Release 包一致。
10
24
 
11
25
  修复 #60 系统代理场景下 `NO_PROXY` 含 `[::1]` 导致所有模型连接测试误报"服务商拒绝了请求":桥接层 `buildChildEnv()` 转发前剥掉带方括号的 IPv6 字面量,Core 5.8.5 把 httpx 客户端构造期异常归类为本地配置错误(HTTP 412),`Studio request failed` 附带 `error.cause`。
12
26
 
13
27
  修复 #61 Embedding 连接测试在请求线程里懒加载 numpy 把后端变成"活着但不服务"的僵尸:Core 5.8.5 启动主线程预热 numpy、后台线程预热 fastembed,`run_embedding_probe()` 硬超时 `timeout_seconds + 30 s`,收尾限时 10 秒超时强制退出;桥接层复用就绪连接前做带超时的 `/api/health` 探活,探活失败的僵尸进程强制终止并自动恢复,子进程 stderr 落盘 `state/logs/backend.log`(末尾 64 KiB)。
14
28
 
15
- 新增回归覆盖 no_proxy 消毒矩阵、僵尸连接探活恢复、stderr 落盘、错误分类矩阵与探测硬超时;wheel 重打包后全量 RECORD 哈希校验(498 文件)与 manifest 一致性检查通过。完整发布验收正在运行,正式发布将使用通过门禁的同一份 CI 产物。Windows 上的依赖预热与僵尸恢复链路本机未复测,保留 0.2.13 的同一限制。
29
+ 新增回归覆盖 no_proxy 消毒矩阵、僵尸连接探活恢复、stderr 落盘、错误分类矩阵与探测硬超时;wheel 重打包后全量 RECORD 哈希校验(498 文件)与 manifest 一致性检查通过。CI 另修复 apt 镜像加固(pin 到 https archive.ubuntu.com + 连接超时),消除 ubuntu 运行器镜像故障导致的矩阵腿卡死。Windows 上的依赖预热与僵尸恢复链路本机未复测,保留 0.2.13 的同一限制;DSH 核心 `dsh-http-proxy` 向 `NO_PROXY` 注入 `[::1]` 的治本修复仍需向 DeepSeek Harness Desktop 团队转达。
16
30
 
17
31
  ## 0.2.13
18
32
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "dsh-openwrite",
3
- "version": "0.2.14",
3
+ "version": "0.2.15",
4
4
  "description": "OpenWrite 长篇小说领域后端接入 DeepSeek Harness:统一创作 Agent 预设 + 原生创作工作台",
5
5
  "type": "module",
6
6
  "scripts": {
@@ -157,7 +157,7 @@ export interface ModelBenchmarkV1Summary {
157
157
  export interface ModelBenchmarkV1 {
158
158
  schema_version: "openwrite.model-benchmark.v1";
159
159
  run_id: string;
160
- status: "completed" | "partial" | "failed";
160
+ status: "completed" | "partial" | "failed" | "running" | "cancelling" | "cancelled";
161
161
  context_hash: string;
162
162
  task_id?: string;
163
163
  started_at?: string;
@@ -605,7 +605,10 @@ const SCHEMAS = {
605
605
  "enum": [
606
606
  "completed",
607
607
  "partial",
608
- "failed"
608
+ "failed",
609
+ "running",
610
+ "cancelling",
611
+ "cancelled"
609
612
  ]
610
613
  },
611
614
  "summary": {