dsh-openwrite 0.2.27 → 0.2.33

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

@@ -0,0 +1,16 @@
+# 选区与中断升级补修
+
+本轮记录 Core 5.8.19 的历史候选补修，已包含于正式 0.2.28（最终 Core 5.8.20）；5.8.19 候选包未单独发行。来自已关闭报告的相关路径复查，四个问题均先独立复现，再加入回归。
+
+| 问题 | 修复后行为 | 验证 |
+| --- | --- | --- |
+| CRLF 或混合行尾在编辑器内变成 LF，选区错位或原文不匹配 | 根据完整原文与编辑器文本映射行尾边界，发送保存文件的原始片段 | 原生面板与 wheel 内独立 Studio 两条界面路径、真实 HTTP 多行选区 |
+| emoji 等字符的 JavaScript UTF-16 与 Python 字符索引不一致 | 请求使用原文 Unicode 码点坐标，批注也按原文坐标映射；重复句仍命中所选的那次 | emoji 前缀、第二次重复句、混合行尾与无末尾换行组合 |
+| 升级中断后 active profile 已移走，恢复脚本找不到依赖 | 恢复使用与正常升级互斥的原生文件锁，无须从已移走的 profile 加载依赖；恢复前核对备份清单指纹 | 独立脚本、失效依赖链接、锁互斥/心跳/陈旧锁和修改备份拒绝 |
+| 被中断的缓存写入留下不完整 tgz，重试永久冲突 | 完整写入并校验临时文件，再原子替换损坏缓存 | 预置部分缓存后重试成功，校验包指纹及临时文件清理 |
+
+映射只容许换行表示不同；正文编辑、普通空格与 NBSP 差别、半个代理对或半个 CRLF 边界均拒绝，不做模糊匹配。提交修订时另带整篇 revision：即使选区外正文变化，也在调用生成器前返回 DOCUMENT_CONFLICT，现有文件保持原样。两端共用映射源，docs:check 校验 wheel 中生成字节。
+
+本地验证：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 真机验证仍未完成，最终 0.2.28 发行保留上述限制，不将它们标记完成。