dsh-openwrite 0.2.28 → 0.2.33

package/docs/ISSUE_123_FOLLOWUP.md

@@ -1,5 +1,6 @@
 # #123 回复补修与验收（候选 0.2.28 / Core 5.8.18，未发布）
 
+这些补修已包含于正式 0.2.28（最终 Core 5.8.20）。下文保留 Core 5.8.18 的历史候选验收；该候选未单独发行。最终公开下载与哈希见[发布验收](RELEASE_ACCEPTANCE.md)。#123 的两项外部/真机条件仍未完成。
 依据报告者的[升级、会话与模型调用记录](https://github.com/LiPu-jpg/Openwrite/issues/123#issuecomment-6422870871)及 [B-13 Windows 实测](https://github.com/LiPu-jpg/Openwrite/issues/123#issuecomment-6423904648)更新结论。回复是有版本、入口和结果的外部验收证据；不把其中推测当成已证实根因。
 
 ## 两项原待办已有实机证据
@@ -27,7 +28,7 @@
 
 这轮修复了解压工具的依赖入口，并避免新安装记录引用易删除的 tgz；**不承诺修复宿主的 pnpm 11 store、构建授权或既有损坏锁文件**。遇到安装器失败，活动 profile 保持原样，保留操作日志与旧完整目录；不要反复改 profile 的依赖、store 配置和锁文件拼凑安装成功。
 
-#124/#125 的首次评审输出预算与 B-20 的运行历史留存是两件事；后者已由 #126/#127 补修。0.2.27 已正式发布；这里的 Core 5.8.18 和插件 0.2.28 仍为候选，未经新一轮全部验收不发布。
+#124/#125 的首次评审输出预算与 B-20 的运行历史留存是两件事；后者已由 #126/#127 补修。这里的 Core 5.8.18 产物当时为未发布候选；后续补修及完整验收已形成正式 0.2.28（最终 Core 5.8.20），此早期候选包未单独发行。
 
 ## 继续保留的两项
 
@@ -51,4 +52,4 @@
 
 Core 固定提交 `43cb604a7583b7268f47e54ceb8a0c30b95e82b2`，wheel SHA-256 `09f9baef5fe0d502510c8542f20c6abaf6893f02e2d069d7f0d7cc50c7aeea93`。候选 tarball SHA-256 `4bcde6d6f535906a5a04490218a0d972e84329ff750af6803a4214fbf609024e`；CI 来源提交 `ecfb7c34c5b0a29d395136da775bb964c3c91d11` 与主分支修复合并提交 `14dd3a5dbc7d1661adb9b684e0f137298bf2591f` 的 tree 同为 `67042838daf11f5c7fc27e0ffe158677a73c3196`。
 
-本轮没有发起真实付费模型请求，thinking 参数通过实际 LLMClient 到提供方请求边界的替身验证；不把它描述为真实服务商计费或输出质量验收。候选产物只保存为验收证据，**未发布 npm 或 GitHub Release，公开版本仍为 0.2.27**。
+本轮没有发起真实付费模型请求，thinking 参数通过实际 LLMClient 到提供方请求边界的替身验证；不把它描述为真实服务商计费或输出质量验收。这份 5.8.18 候选产物仅作历史验收证据，未单独发行；代码已包含于正式 0.2.28，最终公开包与校验值以 [发布验收](RELEASE_ACCEPTANCE.md) 为准。

package/docs/ISSUE_146_REVIEW_EVIDENCE.md

@@ -0,0 +1,53 @@
+# #146：审稿证据回填与状态批注隔离
+
+面向 0.2.29 候选 / Core 5.8.22，尚未发布。
+报告：[OpenWrite Core 5.8.20 B-28 / B-29](https://github.com/LiPu-jpg/Openwrite/issues/146)。
+
+## B-28：同条判据已有引用却被判未定论
+
+审稿模型有时把有效的原文引用放进 criterion 自己的 `issues[].evidence`，
+却漏填 `criterion.evidence`。旧实现只检查后者，正分会被清零并将该项判为 `inconclusive`。
+
+修复先在送审正文中验证引用。若 criterion 没有有效的直接证据，则从**同一 criterion** 的有效问题
+回填引用；保留模型给出的 `evaluated` 状态和分值上限，并在返回值标记
+`evidence_source: "criterion_issues"`。直接证据若误填为一个字符串，按一整条引用处理，
+避免逐字符迭代后把碰巧存在的单字当成原文证据。
+
+同时将 criterion 内的问题纳入完整问题列表，包含有原文依据的 `critical`。
+缺少 `dimension` 时沿用所属 criterion 的第一个 legacy check 标签；显式越出该 criterion 的标签、
+无效严重度和无法在正文中定位的引用不参与回填。
+
+真正缺少引用、模型明确给出 `inconclusive`、硬门禁未定论或严重问题，仍不能通过交付。
+没有放宽正典门禁、评分完整性要求或最小覆盖率策略。修复的目标是使已有证据进入正确字段，
+让正常的完整评审能获得正确状态；真实未完成的检查仍须补齐。
+
+报告中提到的部分审稿，当前实现已有 `scope_status: partial`、`scope_quality_score`、
+`scope_passed` 与 `unreviewed_dimensions`；整章 `delivery_status` 保持 `inconclusive`，
+`quality_score` 为 null。新增回归再次覆盖仅请求 coherence 的情况，避免误报整章通过。
+
+## B-29：机器批注进入送审正文
+
+审稿入口在术语检查、规则检查、AI 痕迹分析、模型评审和正文统计前调用
+`strip_character_state_annotations`。各域、硬门禁及旧分批审稿入口也执行同一处理，
+确保上下文检查器等直接调用路径一致。
+
+清理范围沿用现有阅读/导出契约：有效的角色状态和关系注册从读者正文移除；
+正常代码示例与不符合批注契约的作者文本保留。原稿和状态批注文件都不会被重写。
+已有审稿记录保持原样，需要用新版本重新审稿才能得到修复后的结果。
+
+## 回归方法
+
+`tests/test_issue146_review_evidence.py` 覆盖：
+
+- 三项 criterion 漏填直接证据、同条问题有原文时，恢复到完整 80 分并允许交付。
+- 缺失/伪造引用、显式未定论、硬门禁未定论、嵌套严重问题继续阻断。
+- 不借用相邻判据的引用、不接受无效证据类型或越界标签。
+- 仅审 coherence 明确保持部分审稿。
+- 所有七次正常评审请求，以及直接域/门禁/旧版分批请求，都不包含机器批注。
+- 真实 `execute_review_chapter` 管线将正确结果存入 ReviewStore，原稿保持不变。
+
+相同测试在修复前的冻结源码上为 **8 failed / 5 passed**，修复后全部通过。
+所有模型响应均由测试夹具提供，没有调用真实或付费模型，也不读写作者作品和真实项目登记。
+
+本地完整 Core 回归：1564 passed / 32 existing skipped；定向组合回归 52 passed。
+Core wheel 从冻结 Git 提交归档构建，打包后逐文件核对运行时源码。

package/docs/LEARNING.md

@@ -62,7 +62,7 @@
 | 编辑器选区润色（扩写/缩写/去 AI 味/按审稿改这段） | done | 选区动作走 `/revisions/selection`（expand/compress/naturalize）与 `/revisions/from-review`；hunk 应用走 `/revisions/{id}/apply` + `selected_hunk_ids`，不 PUT 正文；源 revision 不一致时拒绝覆盖 |
 | 正文提及高亮与资料卡 | done | 创作页用现有 `/assets` 的人物/地点名与别名做最长匹配；点击在创作视图打开只读资料卡；切章/切 Workspace 清卡；不进资料库、不 POST 资产更新 |
 | 斜杠命令 / 7 个作者入口 | done | `presets/openwrite/skills/{progress,write-next,review-chapter,revise-span,foreshadow,canon,export-book}` 接到 `novel_*`；persona 默认工作流为看进度 → 写下一章 → 审这一章 → 改这段；其余技能 `user-invocable: false`；`npm run test:preset` 断言入口存在并拒绝旧 Python 命令名 |
-| 项目级 `/learn` 写法记忆 | done | `presets/openwrite/skills/learn`：风格/成功钩子/作者偏好走 `novel_source_action` 与 `novel_structured_change_plan`，随 Workspace 资产走；无 cwd 时现有工具返回 `WORKSPACE_CONTEXT_MISSING`；`npm run test:preset` 24 skills / 8 author entries |
+| 项目级 `/learn` 写法记忆 | done | `presets/openwrite/skills/learn`：风格/成功钩子/作者偏好走 `novel_source_action` 与 `novel_change_plan(action="structured")`，随 Workspace 资产走；无 cwd 时现有工具返回 `WORKSPACE_CONTEXT_MISSING`；`npm run test:preset` 24 skills / 8 author entries |
 | 网文可选审稿维（钩子/黄金三章/追读力） | done | `form: web_novel` 时六域上附加 `max=0` 的钩子/黄金三章/追读力；37 项与质量分不变；黄金三章仅第 1–3 章；非网文项目不附加 |
 | 每 50 章规划窗口 | done | `novel_rolling_plan_action` 默认/上限 50 章；`accepted_window` 只含已接纳正文，`planned_window` 只含未接纳大纲计划；create 不改正文/事实 |
 | 写作冲刺统计 | done | 创作动态页从工作简报字数目标 + 已知 `writing_units_delta` 推导新增/删减/净增；修订净增只来自 `revision_applied`；无 delta 的事件不猜来源；不另建冲刺账本 |

package/docs/MOBILE_READINESS.md

@@ -0,0 +1,62 @@
+# 手机浏览器开发验收（0.2.29 候选，未发布）
+
+此轮改善电脑托管、手机浏览器访问时的编辑可靠性，以及 Android 自备 Python / external
+Studio 的前端体验。正式发行版本仍为 0.2.28；没有新增 iOS App 或 Android 原生 Python/ONNX 包。
+
+## 已实现
+
+- 原生工作台监听页面隐藏和 `pagehide`，在编辑器延迟回调到达之前收集最后输入，沿用按作品、
+  文档隔离的本机恢复草稿。触屏点选区操作时保留选中的正文。
+- 修正真实 Vditor 初始化期间提前读取 Lute 的竞态；首次读取等编辑器 `after` 就绪。
+- 手机与平板的章节栏、参考栏关闭时不可交互；窄屏保持可用编辑高度、触控按钮和表单字号。
+- 导出先挂载下载链接，再延迟回收 Blob 地址，覆盖中文文件名、UTF-8 `filename*` 和含 `%` 的旧文件名。
+- 独立 Core Studio 的正文也增加本机恢复草稿。草稿按作品路径、作品 ID、文档和服务器版本隔离；
+  刷新后明确提示恢复或下载。服务器版本变化时禁止直接恢复，保留副本供作者比对。
+  编辑新版正文不会覆盖旧版冲突草稿。
+- 手动保存先读取最后输入；保存请求绑定原作品和文档。切章后晚到的响应不能替换当前正文；
+  请求途中继续输入的内容保留为待保存草稿。保留现有服务器版本冲突检查。
+
+本机草稿保存在该浏览器、该站点的 localStorage，不能替代作品备份，也不会在设备间同步。
+浏览器禁用存储或空间不足时会提示手动保存。独立 Studio 这一轮恢复范围为正文；资料表单
+仍按既有保存流程使用。手机系统强制结束浏览器不保证触发生命周期事件，建议看到保存成功再离开。
+
+## 自动回归
+
+`packages/studio-panel/scripts/mobile-browser.mjs` 使用真实 Vditor，分别运行 Chromium 和 WebKit，
+检查 320 / 390 / 768 像素宽度及 480 像素可视高度。隔离夹具不打开作品，不调用模型。
+
+覆盖后台前的中文与 emoji 输入、模拟组合输入、触屏选区、中文下载文件和内容、窄屏抽屉、
+刷新恢复、服务器版本冲突、显式恢复、立即保存、切章后的旧保存响应，以及保存途中继续输入。
+组合输入事件是模拟值，不能代替真机中文输入法。
+
+CI 从待发布 tgz 提取 Core wheel，核对原生编辑器源码与包内 source map、编译 CSS 及供应商资源，
+再运行上述用例。两种引擎的报告均为发布验收前置条件，记录安装包 SHA-256 和输入来源。
+WebKit 是浏览器引擎测试，不等于 iPhone Safari、iOS 模拟器或 Android/Termux 验收。
+
+本地源码验证：
+
+```sh
+node packages/studio-panel/scripts/mobile-browser.mjs --browser=webkit --core=/absolute/core/tools/studio_assets
+node packages/studio-panel/scripts/mobile-browser.mjs --browser=chromium --core=/absolute/core/tools/studio_assets
+```
+
+## 之后的真机验收
+
+iPhone / iPad 可以测试电脑托管的 Web 工作台或独立 Studio。电脑需保持运行，手机通过受信任的
+私有网络或经过认证的 HTTPS 入口访问；手机上的 `127.0.0.1` 指向手机自身。不要直接公开未鉴权的
+Core 端口。DSH 的远程入口与访问控制按所用宿主版本设置；OpenWrite 不提供独立的 iOS 本地后端。
+
+在测试作品中逐项记录设备、系统、浏览器、宿主和候选包版本：
+
+1. 打开章节、人物与设定，确认关闭的抽屉不能挡住正文；竖屏、横屏和软键盘弹出时能继续编辑。
+2. 用中文输入法连续输入、选择候选词并加入 emoji；立即保存，刷新确认最后一句和格式完整。
+3. 输入后立即切 App、锁屏再回来；检查服务器保存状态。未保存时刷新，应能恢复本机草稿。
+4. 在另一浏览器修改同章后回来，检查版本冲突提示；旧草稿只下载对比，不覆盖新版正文。
+5. 长按选择正文后使用扩写或审稿入口，确认作用范围。先检查预览；实际模型请求另计。
+6. 导出 Markdown / EPUB，确认下载名称和文件内容，再检查“文件”App 中的文件。
+7. 快速切章、切作品，在网络较慢时保存，确认正文和草稿归属正确。
+
+Android / Termux 另需按照 [安装说明](INSTALL.md#android--termux) 验收解释器、原生依赖、
+external 鉴权、Workspace 路径绑定及实际工具调用。iOS 测试不能替代这部分。
+
+上述真机项目仍待完成，继续在 [#123](https://github.com/LiPu-jpg/Openwrite/issues/123) 跟踪。

package/docs/PLUGIN_MAINTENANCE.md

@@ -9,8 +9,6 @@ npm ci --ignore-scripts
 node scripts/prepare.mjs
 npm run check:plugin
 npm run test:managed
-npm --prefix vendor/dsh-dog run typecheck
-npm --prefix vendor/dsh-dog test
 node scripts/release-provenance.mjs
 npm pack --ignore-scripts
 node scripts/release-check.mjs
@@ -23,7 +21,7 @@ node scripts/release-smoke.mjs
 
 ## 发布产物
 
-根包 `dsh-openwrite` 组合运行时、bridge、panel、DoG 和版本预设。Core 使用 `native-core` 固定 commit 的 wheel；用户无需切换分支。版本、来源和所有平台下载哈希记录在 runtime manifest。
+根包 `dsh-openwrite` 组合运行时、bridge、panel 和版本预设。Core 使用 `native-core` 固定 commit 的 wheel；用户无需切换分支。版本、来源和所有平台下载哈希记录在 runtime manifest。
 
 Python 主依赖从该 wheel 的 METADATA 导出到 `release/core-requirements.in`，用固定 uv 重建：
 

package/docs/RELEASE_ACCEPTANCE.md

@@ -1,12 +1,29 @@
 # 发布验收记录
 
-## 0.2.28 候选（未发布）
+## 0.2.28
 
 本轮捆绑 Core **5.8.20**，固定源码 `9611c654e5d77bcb5968105a7adfa8e9b4f9624a`。修复正文延迟输入漏存、按审稿修订越过作者选区，以及真实 Vditor 换行规范化导致的选区拒绝，详见[补修范围](EDITOR_SAFETY_REPAIRS.md)。
 
-本地 Core **1550 passed / 32 skipped**、真实 HTTP **14 passed**、界面 **336 passed**、managed **34 passed**、完整插件检查通过。新增真实候选包编辑器浏览器场景 **9 组通过**。wheel 的 499 个运行时文件与固定源码逐字节一致，163 个应打包 Python 文件无遗漏，SHA-256 为 `aa1f25f3c615497cd73c3c059fd2acc4e71ba2e936765d02331d1382df4b201a`。跨平台最终结果在验收后补齐。
+本地 Core **1550 passed / 32 skipped**、真实 HTTP **14 passed**、界面 **336 passed**、managed **34 passed**、完整插件检查通过。新增真实候选包编辑器浏览器场景 **9 组通过**。wheel 的 499 个运行时文件与固定源码逐字节一致，163 个应打包 Python 文件无遗漏，SHA-256 为 `aa1f25f3c615497cd73c3c059fd2acc4e71ba2e936765d02331d1382df4b201a`。最终跨平台验收与产物复核结果如下。
 
-候选仍未发布，公开版本为 **0.2.27**；#123 的宿主正式发布和 Android/Termux 真机条件继续保留。
+[Core PR #137](https://github.com/LiPu-jpg/Openwrite/pull/137) 和 [插件 PR #138](https://github.com/LiPu-jpg/Openwrite/pull/138) 已合并。最终 **22 项检查全部通过**：[三系统回归](https://github.com/LiPu-jpg/Openwrite/actions/runs/40453781968)、[安装/客户端验收](https://github.com/LiPu-jpg/Openwrite/actions/runs/40453781862)、[插件检查](https://github.com/LiPu-jpg/Openwrite/actions/runs/40453781876)。下载原始报告后核对：
+
+| 验收 | Linux | macOS | Windows |
+| --- | --- | --- | --- |
+| 固定 Core 全量 | 1550 passed / 32 skipped | 1550 passed / 32 skipped | 1550 passed / 32 skipped |
+| 真实 HTTP 路由与选区上限 | 14 passed | 14 passed | 14 passed |
+| 真实 Electron 44.7.0 | 5 passed / 0 skipped | 5 passed / 0 skipped | 5 passed / 0 skipped |
+| wheel 源码字节 / 应打包 Python 文件 | 499 / 163 一致 | 499 / 163 一致 | 499 / 163 一致 |
+
+8 份安装/源码、5 份客户端、6 份原生报告全部通过。每组原生验收运行 40 项预设/升级/运行时回归，并对同一 tarball 内的真实 Vditor、独立编辑器包装、Core 与原生面板映射器验证 9 组场景，editorSerialization 字段全部为通过。Core 的 32 项跳过仍来自缺失旧样例或外部 checkout，新增回归无跳过；本轮不调用付费模型。
+
+macOS ARM 首次 npm ci 从第三方镜像下载依赖超时；只重跑失败任务和依赖的汇总步骤后通过，构建产物保持相同。没有放宽验收或替换依赖版本。
+
+候选 tarball SHA-256：`3a50ad3cb080eec50b28f3196d5c0cd476643db894b06df0dfc8c394fec1bcfd`。CI 提交 `9390c7826024ee78cc91d5a144825a55ca0016e0` 与插件合并提交 `6117a19a26b60ab6d55bff23fdfb46f84fd02320` 的源码 tree 同为 `d59236a0d5dd77ce0d960586cd7c59eeaf0b96c9`。Core 固定来源保留于 native-core 合并提交 `40e25b7a27a4b0f9430d0cc15b775c601f28a91e`。
+
+[GitHub 0.2.28](https://github.com/LiPu-jpg/Openwrite/releases/tag/v0.2.28) 与 [npm 0.2.28](https://www.npmjs.com/package/dsh-openwrite/v/0.2.28) 均已正式发布，npm `latest` 为 **0.2.28**。GitHub 四份公开附件的服务端 digest 和无认证下载字节均与 CI 原件一致；官方 npm registry 无认证下载的完整 **10,232,555 字节**包也逐字节一致，SHA-256、SHA-1 及 SHA-512 integrity 已核对。发布使用上述 CI 原始包，没有重新构建。#123 的两项仍未验收，不因发行而标为完成。
+
+下方为形成最终版本之前的历史候选证据；早期暂停与未发布状态反映当时情况，各早期候选未单独发行，最终发布仅使用 Core 5.8.20 的上述产物。
 
 ### 前轮候选证据（Core 5.8.19，未发布）
 

package/docs/REVIEW_ROUND_22.md

@@ -0,0 +1,67 @@
+# 第二十二轮：插件侧并发与安装/升级路径审查
+
+## 结论：2 个真实缺陷（已修）
+
+## V-1：companion 升级后缓存不失效
+
+`companions.mjs` 的缓存 fingerprint 只包含 profile 的 `package.json` mtime，**不含 companion 自身的 manifest**。而 companion 的 `package.json`（`peerDependencies['@deepseek-ai/dsh']`）正是判定宿主兼容性的依据。
+
+后果：升级 companion（放宽或收紧 peer range）后，缓存仍返回旧判定——正是 #150/#151/#142 那一类问题的复发路径，只是触发条件从"版本比较错"变成"缓存不失效"。
+
+修复：把每个候选 companion 的 manifest mtime 纳入 fingerprint。
+
+**测试因此在断言错误行为**：原测试 `a cache hit serves the stored answer instead of recomputing` 删掉 companion 包后断言仍返回 `cached: true, usable: true`——即"包没了还说可用"。已改为正确语义（删除后必须失效、重新计算为不可用），并补了第三次调用验证纯重复仍命中缓存。
+
+## V-2：损坏的 ownership marker 被永久误判
+
+`install.sh` 用裸 `cat >` 写 `.openwrite-managed.json`，崩溃会留下截断文件。`maintenance.mjs` 的 `inspectPresets` 对解析失败 `.catch(() => null)` → 判为 `author-owned` → **升级被永久拒绝，且没有任何诊断说明原因**。
+
+fail-closed 方向是对的（不会误覆盖作者数据），但不可恢复、不可诊断。
+
+双管齐下：
+- **消除根因**：marker 改为 `mktemp` + `mv` 原子写入，带 `trap` 清理临时文件
+- **可诊断**：`inspectPresets` 区分 `marker-corrupt` 与 `author-owned`，并返回 marker 内容
+
+## V-2b 的测试三次才抓住
+
+内容断言无法区分原子写和非原子写（成功时字节相同）。前两次尝试：
+1. 断言 marker 内容完整 → 两种写法都通过
+2. 断言 `version` 非空 → 发现 fixture 的 package.json 没 version 字段（不是产品缺陷）
+
+最终用**结构性断言**：install.sh 必须匹配 `marker_tmp=$(mktemp ...)` + `mv "$marker_tmp" "$target/.openwrite-managed.json"`，且不得匹配 `cat > "$target/.openwrite-managed.json"`。
+
+## 审查过但未发现问题的部分
+
+- **`safe-upgrade.mjs` 的 `acquireRecoveryLock`**：`mkdir` 原子创建 + `dev/ino/birthtime` 身份校验 + 每秒心跳续租 + 30 秒陈旧回收。实现相当严谨，未发现问题。
+- **`install.sh` 的 move-aside + rsync**：`set -euo pipefail` 保证 `mv` 失败即中止（rsync 不会执行），`mktemp -d` 避免同秒冲突，NUL 分隔处理任意文件名。安全。
+- **companion 缓存的并发写**：`writeFile` 非原子，但读侧有容错，损坏只导致缓存失效（重新计算），不会产生错误结果。低风险。
+
+## 验证
+
+| 变异 | 结果 |
+|---|---|
+| V-1a fingerprint 不含 companion manifest | 3 failing ✓ |
+| V-2a 损坏 marker 当作 author-owned | 3 failing ✓ |
+| V-2b install.sh marker 裸写 | 3 failing ✓ |
+
+## 最终状态
+
+| | |
+|---|---|
+| 插件 test:maintenance | **81 passed / 0 failed**（原 80） |
+| studio-panel | **41 files / 358 passed / 0 failed** |
+| docs:check / doctor | 全绿 |
+| lifecycle | 10 passed |
+
+改动：插件 211 项，未提交。
+
+## 二十二轮总账
+
+| 维度 | 轮次 | 结果 |
+|---|---|---|
+| 变异验证 | 13–14 | 15 个修复无防线 |
+| 数据丢失 | 12–16 | 5 个模块 |
+| 门禁 fail-open | 17 | 2 处 |
+| except 方向 | 18–19 | 7 个错误码缺失 |
+| 并发（Core） | 20–21 | 1 个无锁缺陷 |
+| 并发（插件）+ 安装路径 | 22 | 2 个缺陷 |

package/docs/REVIEW_ROUND_23.md

@@ -0,0 +1,48 @@
+# 第二十三轮：缓存/标记失效条件的系统性审计
+
+## 结论：未发现新缺陷（V-1/V-2 已在第二十二轮修复）
+
+本轮按第二十二轮识别出的模式（**缓存/标记与事实不同步**）做了两个系统化审计，都是零命中。
+
+## W-1：派生缓存的失效键（Core 侧全部完备）
+
+自动扫描噪音太大（正则匹配到 `us` 之类的碎片），改为按已知缓存逐个查：
+
+| 缓存 | 失效键 | 判定 |
+|---|---|---|
+| `writing_assets` | `sha256(内容)` | 内容哈希，比 mtime 更可靠 |
+| `context_manifest` | `sha256(rendered)` | 内容哈希 |
+| `character_state_index` | `path + size + mtime_ns` 三元组 | 路径集变化也会改变 manifest（列表长度不同） |
+| `chapter_memory` / `review_store` | `source_revision` 对比 | 三态 current/stale/corrupt |
+| `companions.mjs` | **已在 V-1 修复** | 现含 companion manifest mtime |
+
+`character_state_index._load_cache` 对损坏返回 `{}` → `cached` 为假 → 重新计算。**fail-open 到"重新算"，是安全方向**。
+
+其余 `st_mtime` 用法（`arc_audit`、`narrative_forecast`、`research_service`、`review_store`）都是"取最新的 N 个"排序，不是缓存判定。
+
+## W-2：二值/三态判定的第三态
+
+V-2 已修（`marker-corrupt`）。其余：
+
+| 判定 | 第三态行为 | 判定 |
+|---|---|---|
+| `preset-definition.legacyPresetIds` | version 不可解析 → `[]` | fail-open 到"无兼容别名"，但此时整个插件都该失败，不会静默 |
+| `chapter_memory` acceptance head 检查 | `except Exception: pass` 保持原 freshness | **有意的权衡**：降到 `unknown` 会让所有摘要都不进 prompt（可用性骤降），而保持 current 的风险只是"摘要略旧" |
+| `manuscript_editing.revision_matches` | 允许 16 位短哈希前缀 | 空串不匹配（`fullmatch` 拒绝），16^16 碰撞可忽略 |
+
+## 方法论：本轮为什么零命中
+
+不是因为没有问题了，而是：
+
+1. **W-1 的自动扫描失败了**——正则噪音让我无法相信它的输出，只好回到手工逐个查。这意味着"系统性"只覆盖了我已知列表里的缓存，可能漏掉我没列出的。
+2. **W-2 的判定大多是三态或 fail-open 到重新计算**——这是第二十二轮修复 + 前几轮修复的结果，模式已经被清理过一遍。
+
+## 状态
+
+Core 缓存/新鲜度相关测试 **102 passed**，插件 81 passed，改动未提交（第二十二轮的 211 项 + 本轮无新改动）。
+
+## 剩余未覆盖面
+
+- **W-1 的自动扫描能力缺失**：我没有可靠的方法枚举"所有派生缓存"。本轮靠手工列表，可能遗漏。一个可靠的扫描需要先定义"缓存"的语义（有失效键的持久化数据），这本身是个待建能力。
+- `live_tests/`、三系统 CI、真实设备（始终未覆盖）。
+- **性能/资源维度**：从未审查过（内存增长、文件句柄泄漏、无界增长）。

package/docs/REVIEW_ROUND_25.md

@@ -0,0 +1,51 @@
+# 第二十五轮：插件侧资源生命周期
+
+## 结论：1 个真实缺陷（已修）
+
+## Y-2：失败升级留下整个 profile 副本
+
+`upgradeProfile` 的 staging 目录是**完整 profile 副本，含 node_modules**（数百 MB）。它的 finally 只关 log 和释放锁，**从不删除 staging**。
+
+全仓库只有一处 `openwrite-stage-`（创建处），没有任何清理处——`recoverUpgrade` 也不清理。所以每次失败升级都永久留下一个 staging 目录，重试一次再多一个，无上限。
+
+对比：同文件其他资源都有 finally 保护——文件句柄（第 90 行）、pending 文件（第 94 行）、定时器/ drain（第 163 行）、恢复租约（第 208/283/307 行）。**只有 staging 漏了**，而它是最大的那个。
+
+### 修复
+
+```js
+} finally {
+  try { await log?.close() } finally {
+    try { await rm(staging, { recursive: true, force: true }) } catch { /* best effort */ }
+    await release()
+  }
+}
+```
+
+成功路径上 staging 已被 `rename` 到 target，所以这个 `rm` 是 no-op；失败路径上 reclaimed。
+
+## 已确认正确的部分
+
+- `managed-runtime.download`：`.partial` 文件有 finally 清理，且启动时清理历史残留（issue #82 的修复）
+- `install.sh`：`set -euo pipefail` 保证 `mv` 失败即中止（rsync 不执行）；marker 写入已原子化（V-2）
+- `safe-upgrade` 的锁：`mkdir` 原子创建 + dev/ino/birthtime 身份校验 + 心跳续租 + 陈旧回收
+- Core 侧 `atomic_write`：finally 清理（第二十四轮统一了 5 处）
+
+## 验证
+
+| 变异 | 结果 |
+|---|---|
+| Y-2a 失败升级不清理 staging | 3 failing ✓ |
+
+| | |
+|---|---|
+| 插件 test:maintenance | **81 passed / 0 failed**（原 80） |
+| docs:check / doctor | 全绿 |
+| studio-panel | **41 files / 358 passed / 0 failed** |
+
+改动：插件 212 项，未提交。
+
+## 本轮的模式
+
+又是"同一个缺陷类修了 N 个、漏 1 个"：`safe-upgrade.mjs` 内部有 5 处 finally 覆盖了句柄/临时文件/定时器/租约，**唯独漏了最大的那个资源**（staging 目录）。
+
+这与第二十四轮（5 个模块有上限，1 个没有）、第十六轮（5 个模块原子写，1 个没有）是同一模式：**逐个处理具体症状时不漏大项，因为大项往往不在当时视野里**。只有按维度（资源生命周期）主动枚举才能找出来。

package/docs/SELECTION_UPGRADE_REPAIRS.md

@@ -1,6 +1,6 @@
 # 选区与中断升级补修
 
-本轮对应未发布候选 0.2.28 / Core 5.8.19；公开版本仍为 0.2.27。来自已关闭报告的相关路径复查，四个问题均先独立复现，再加入回归。
+本轮记录 Core 5.8.19 的历史候选补修，已包含于正式 0.2.28（最终 Core 5.8.20）；5.8.19 候选包未单独发行。来自已关闭报告的相关路径复查，四个问题均先独立复现，再加入回归。
 
 | 问题 | 修复后行为 | 验证 |
 | --- | --- | --- |
@@ -13,4 +13,4 @@
 
 本地验证：Core 全量 1542 passed / 32 skipped，修订服务与真实 HTTP 23 passed，原生预设/升级/运行时 40 passed，managed 33 passed，界面 319 passed，插件完整检查通过。独立 Studio 用打包 wheel 内的实际绑定代码测试隐藏 textarea 的换行规范化；HTTP 用实际两端映射模块发送请求。测试使用隔离自动化目录，未调用模型。
 
-跨平台最终结果及确切来源在 [发布验收](RELEASE_ACCEPTANCE.md) 记录。#123 的宿主正式发布与 Android/Termux 真机验证仍未完成，本轮修复不解除发布暂停。
+跨平台最终结果及确切来源在 [发布验收](RELEASE_ACCEPTANCE.md) 记录。#123 的宿主正式发布与 Android/Termux 真机验证仍未完成，最终 0.2.28 发行保留上述限制，不将它们标记完成。