stratagate-dsh 0.3.13 → 0.3.14

package/docs/issue-128-lease-cache-review-followup.md

@@ -1,55 +1,55 @@
-# Issue #128：同 revision 续租缓存复审修复
-
-源码提交：`0f0cb8fbce5a116e4670785716aa62f68cdd9c08`。本报告之后的交付提交只增加证据文档；交付 SHA 以离线包 manifest 为准。
-
-上轮交付：`bc73b6b7b2353e9c82726b8976f440672546ce9e`。完整修复基线：`e954eaf2f2cbbef4bb6226a2ebb35191424868c2`。
-
-## 复现与修复
-
-审查指出的边界成立。B 在 A 续租前加载 running Job，A 用真实独立 OS 子进程调用 SQLite 续租接口，业务 revision 不变；推进时钟越过 B 缓存的租约时间，B 尝试处理另一线程的 Block。修复前，Summary、Extraction、Graph、Topic 四个定向用例均出现 `Storage lease conflict`，无法完成另一任务。干净复现日志为 `lease-cache-repro-fixed-fixture.log`，不是仅凭静态推断。
-
-最小修复继续把 Jobs 作为事实来源，不增加业务 revision、不引入新的业务状态机或常驻历史缓存：
-
-- SQLite 增加可选的轻量 `loadDerivationLeases()`。一次读事务获取当前 namespace 的 revision 和四类 running 认领元数据，不读取消息、Block 正文、Event 内容或 Graph 节点。Graph/Topic 只向调用者返回 Job 身份、attempt、updatedAt、leaseUntil；Topic 的 JSON 查询在 SQLite 内完成。
-- 本地发现 running 租约已到期时，恢复前先同步持久化元数据。`reloadFromStorage()` 与 `refreshFromStorage()` 在 revision 相同且认领身份一致时，只同步租约字段。业务 revision 变化，或 running 集合、attempt、updatedAt 不一致时，才读取完整权威快照；不能用租约读结果猜测业务状态。
-- Topic claim 使用同一个到期前置同步。正常完成、到期恢复、失败重试和最大次数仍由原有状态机处理，写入仍受 SQLite 事务认领与租约校验保护。
-- 心跳仍可能恰好发生在元数据读取之后、恢复写入之前。SQLite 会拒绝旧租约写入；前台 Block 调度遇到冲突后刷新持久化状态，并至少等待原有 3 秒 Worker 间隔后再试，不为这次正常竞争记录插件错误。其他抛出的异常也受同一个重排下限约束。新任务正常唤醒和既有持久化失败重试时间不变。
-
-没有调大后台轮询间隔。新元数据读取用于实际任务恢复及显式重载，空闲轮询仍只查到期调度/脏键索引、额度和独立 Profile Maintenance，不会因此逐个打开 namespace。旧数据库可按原有迁移与分批脏键重建发现旧任务；跨进程写入仍依赖持久化触发器和轻量轮询，不依赖内存通知。
-
-## 定向验证
-
-- 四类真实子进程续租：B 未显式 reload，也不会误恢复 A；A 保持 running、attempt 不变；另一线程任务完成；重复三轮不重复调用模型；续租同步期间完整 `SqliteStorage.load()` 调用为零。观察者的两种显式重载接口也取得同 revision 新租约。
-- 同 revision 下认领 attempt 或状态被外部 SQL 改变：确实加载一次完整权威快照，而不是只替换租约。
-- 前台真实 SQLite 竞争：读取旧元数据后 A 再续租，B 越过旧截止时间，事务拒绝恢复写入。没有插件错误日志；2,999ms 内不重试，3,000ms 后另一任务完成；额外推进 10 秒不再重排；完整加载仍为零。
-- 既有失败恢复测试改用模拟定时器，明确断言退避期间 namespace 仍可打开、退避后任务完成，没有增加测试超时。
-- 全范围自查还复现了最终一次 Summary/Extraction 租约中断后的终止边界：Core 已拒绝再执行，恢复留下的到期时间仍会让前台不断重排一个无法执行的任务。两个修复前回归均发现立即重试定时器；前台增加原有最大尝试次数过滤后，连续四次调度都不再创建定时器，模型调用为零。没有修改持久化重试 ledger 或增加尝试次数。
-
-时间边界使用注入时钟/模拟定时器；续租写入和认领竞争使用真实 SQLite，四类续租各使用真实独立 OS 进程。没有声称在本轮实际等待 5 分钟网络模型调用。
-
-## 整体核查与测试
-
-Windows x64 / Node `24.19.0` / `CI=true`：
-
-- `npm run check` 通过。
-- `npm test`：Core **312**、DSH **591**、WorkBuddy **10**，共 **913** 项通过、**1** 项既有跳过。
-- Issue #128 两个定向文件共 **41** 项通过（Core 30、DSH 11），包含先前 FTS、坏键公平重建、open tail、租约续期及本轮缓存和最终尝试边界回归。
-- `npm run build` 全部目标通过；`node scripts/verify-package.mjs` 验证 58 个包内文件及干净 tarball 安装，通过。
-- Windows DSH `0.2.0-rc.1` 和 `0.2.0-rc.2` 各自完整兼容脚本通过，均在冻结源码下完成类型检查、591 项 DSH 测试（1 项既有跳过）、构建、干净包安装、真实 CLI 启动、陈旧 peer 可恢复修复、管理能力、两条会话标题/页面和旧迁移，退出码均为 0。
-- 首次 rc.1 流程跨过了最终尝试次数补丁，未作为最终提交的完整证据。冻结后完整补跑日志为 `lease-cache-compat-rc1-final.log`；rc.2 日志为 `lease-cache-compat-rc2.log`。补跑 rc.1 和最后构建/包检查只关闭 npm 附带的 audit/fund 网络请求，依赖安装和全部功能断言保留；未执行安全漏洞审计。环境记录见 `lease-cache-validation-context.json`。
-
-自查覆盖整个调度与 FTS 范围：派生索引与任务保存仍在同一事务；坏键持久化 60 秒退避与 generation 校验保留；未变化消息 UPSERT/FTS UPDATE 触发器仍不污染 dirty 集合；普通打开不再全库检查 FTS，旧库按搜索 namespace 懒回填，显式修复入口保留；只有可封存 open tail 的资格检查与 Worker 一致；Topic Event 版本动态工作及历史额度、模型就绪、重启恢复和独立 Profile Maintenance 相关回归仍通过。
-
-本轮初次全量运行有一项失败：旧测试默认等待窗口短于新增 3 秒异常退避。修正为上述明确的时间边界断言后完整复验通过。离线包保留干净的修复前四类失败日志与最终通过日志，避免混用。
-
-## 性能与验收边界
-
-本轮没有重新采集 CPU/RSS 基准。此前 [Windows 合成数据](benchmarks/issue-128-windows-review.json) 属于源码 `415096f19d09d9bcc29c44634c7ae78fd6c2f52d`，其中 1449.42 MiB 合成库的 Worker CPU 61.80% → 1.20%、三轮完整加载 300 → 0，不能标注为本轮源码的测量。本轮的空闲回归继续验证 100 namespace 多轮、1000 namespace 大规模扫描不打开完整记忆；这不是完整 DSH 桌面进程 CPU 验收。
-
-原用户 168 MB / 14 namespace 数据库、真实网络长模型、桌面界面响应及长期 CPU/RSS 仍需人工验证；远端 CI 未知。没有访问或修改用户生产数据库，没有推送 GitHub、更新 PR、合并或发布版本。
-
-## 离线交付
-
-新包包含完整提交源码 ZIP、完整任务分支历史 Git bundle、相对基线完整补丁、相对上轮增量补丁、测试/兼容日志、报告、中文审查提示词和 SHA-256 manifest。bundle 包含基线及其祖先，无外部 prerequisite；会在本任务的新隔离目录实际克隆并检查 HEAD。它仅包含任务分支引用，不打包其他工作分支。
-
-完整源码包含 lockfile、测试夹具和构建配置。Node/npm 依赖未内嵌，重新执行测试需要可用 npm registry 或预先准备的依赖缓存；Git 仓库恢复本身不依赖 GitHub。历史报告与性能 JSON 保留原来的源码归属，最新结论以本报告和 manifest 为准。
+# Issue #128：同 revision 续租缓存复审修复
+
+源码提交：`0f0cb8fbce5a116e4670785716aa62f68cdd9c08`。本报告之后的交付提交只增加证据文档；交付 SHA 以离线包 manifest 为准。
+
+上轮交付：`bc73b6b7b2353e9c82726b8976f440672546ce9e`。完整修复基线：`e954eaf2f2cbbef4bb6226a2ebb35191424868c2`。
+
+## 复现与修复
+
+审查指出的边界成立。B 在 A 续租前加载 running Job，A 用真实独立 OS 子进程调用 SQLite 续租接口，业务 revision 不变；推进时钟越过 B 缓存的租约时间，B 尝试处理另一线程的 Block。修复前，Summary、Extraction、Graph、Topic 四个定向用例均出现 `Storage lease conflict`，无法完成另一任务。干净复现日志为 `lease-cache-repro-fixed-fixture.log`，不是仅凭静态推断。
+
+最小修复继续把 Jobs 作为事实来源，不增加业务 revision、不引入新的业务状态机或常驻历史缓存：
+
+- SQLite 增加可选的轻量 `loadDerivationLeases()`。一次读事务获取当前 namespace 的 revision 和四类 running 认领元数据，不读取消息、Block 正文、Event 内容或 Graph 节点。Graph/Topic 只向调用者返回 Job 身份、attempt、updatedAt、leaseUntil；Topic 的 JSON 查询在 SQLite 内完成。
+- 本地发现 running 租约已到期时，恢复前先同步持久化元数据。`reloadFromStorage()` 与 `refreshFromStorage()` 在 revision 相同且认领身份一致时，只同步租约字段。业务 revision 变化，或 running 集合、attempt、updatedAt 不一致时，才读取完整权威快照；不能用租约读结果猜测业务状态。
+- Topic claim 使用同一个到期前置同步。正常完成、到期恢复、失败重试和最大次数仍由原有状态机处理，写入仍受 SQLite 事务认领与租约校验保护。
+- 心跳仍可能恰好发生在元数据读取之后、恢复写入之前。SQLite 会拒绝旧租约写入；前台 Block 调度遇到冲突后刷新持久化状态，并至少等待原有 3 秒 Worker 间隔后再试，不为这次正常竞争记录插件错误。其他抛出的异常也受同一个重排下限约束。新任务正常唤醒和既有持久化失败重试时间不变。
+
+没有调大后台轮询间隔。新元数据读取用于实际任务恢复及显式重载，空闲轮询仍只查到期调度/脏键索引、额度和独立 Profile Maintenance，不会因此逐个打开 namespace。旧数据库可按原有迁移与分批脏键重建发现旧任务；跨进程写入仍依赖持久化触发器和轻量轮询，不依赖内存通知。
+
+## 定向验证
+
+- 四类真实子进程续租：B 未显式 reload，也不会误恢复 A；A 保持 running、attempt 不变；另一线程任务完成；重复三轮不重复调用模型；续租同步期间完整 `SqliteStorage.load()` 调用为零。观察者的两种显式重载接口也取得同 revision 新租约。
+- 同 revision 下认领 attempt 或状态被外部 SQL 改变：确实加载一次完整权威快照，而不是只替换租约。
+- 前台真实 SQLite 竞争：读取旧元数据后 A 再续租，B 越过旧截止时间，事务拒绝恢复写入。没有插件错误日志；2,999ms 内不重试，3,000ms 后另一任务完成；额外推进 10 秒不再重排；完整加载仍为零。
+- 既有失败恢复测试改用模拟定时器，明确断言退避期间 namespace 仍可打开、退避后任务完成，没有增加测试超时。
+- 全范围自查还复现了最终一次 Summary/Extraction 租约中断后的终止边界：Core 已拒绝再执行，恢复留下的到期时间仍会让前台不断重排一个无法执行的任务。两个修复前回归均发现立即重试定时器；前台增加原有最大尝试次数过滤后，连续四次调度都不再创建定时器，模型调用为零。没有修改持久化重试 ledger 或增加尝试次数。
+
+时间边界使用注入时钟/模拟定时器；续租写入和认领竞争使用真实 SQLite，四类续租各使用真实独立 OS 进程。没有声称在本轮实际等待 5 分钟网络模型调用。
+
+## 整体核查与测试
+
+Windows x64 / Node `24.19.0` / `CI=true`：
+
+- `npm run check` 通过。
+- `npm test`：Core **312**、DSH **591**、WorkBuddy **10**，共 **913** 项通过、**1** 项既有跳过。
+- Issue #128 两个定向文件共 **41** 项通过（Core 30、DSH 11），包含先前 FTS、坏键公平重建、open tail、租约续期及本轮缓存和最终尝试边界回归。
+- `npm run build` 全部目标通过；`node scripts/verify-package.mjs` 验证 58 个包内文件及干净 tarball 安装，通过。
+- Windows DSH `0.2.0-rc.1` 和 `0.2.0-rc.2` 各自完整兼容脚本通过，均在冻结源码下完成类型检查、591 项 DSH 测试（1 项既有跳过）、构建、干净包安装、真实 CLI 启动、陈旧 peer 可恢复修复、管理能力、两条会话标题/页面和旧迁移，退出码均为 0。
+- 首次 rc.1 流程跨过了最终尝试次数补丁，未作为最终提交的完整证据。冻结后完整补跑日志为 `lease-cache-compat-rc1-final.log`；rc.2 日志为 `lease-cache-compat-rc2.log`。补跑 rc.1 和最后构建/包检查只关闭 npm 附带的 audit/fund 网络请求，依赖安装和全部功能断言保留；未执行安全漏洞审计。环境记录见 `lease-cache-validation-context.json`。
+
+自查覆盖整个调度与 FTS 范围：派生索引与任务保存仍在同一事务；坏键持久化 60 秒退避与 generation 校验保留；未变化消息 UPSERT/FTS UPDATE 触发器仍不污染 dirty 集合；普通打开不再全库检查 FTS，旧库按搜索 namespace 懒回填，显式修复入口保留；只有可封存 open tail 的资格检查与 Worker 一致；Topic Event 版本动态工作及历史额度、模型就绪、重启恢复和独立 Profile Maintenance 相关回归仍通过。
+
+本轮初次全量运行有一项失败：旧测试默认等待窗口短于新增 3 秒异常退避。修正为上述明确的时间边界断言后完整复验通过。离线包保留干净的修复前四类失败日志与最终通过日志，避免混用。
+
+## 性能与验收边界
+
+本轮没有重新采集 CPU/RSS 基准。此前 [Windows 合成数据](benchmarks/issue-128-windows-review.json) 属于源码 `415096f19d09d9bcc29c44634c7ae78fd6c2f52d`，其中 1449.42 MiB 合成库的 Worker CPU 61.80% → 1.20%、三轮完整加载 300 → 0，不能标注为本轮源码的测量。本轮的空闲回归继续验证 100 namespace 多轮、1000 namespace 大规模扫描不打开完整记忆；这不是完整 DSH 桌面进程 CPU 验收。
+
+原用户 168 MB / 14 namespace 数据库、真实网络长模型、桌面界面响应及长期 CPU/RSS 仍需人工验证；远端 CI 未知。没有访问或修改用户生产数据库，没有推送 GitHub、更新 PR、合并或发布版本。
+
+## 离线交付
+
+新包包含完整提交源码 ZIP、完整任务分支历史 Git bundle、相对基线完整补丁、相对上轮增量补丁、测试/兼容日志、报告、中文审查提示词和 SHA-256 manifest。bundle 包含基线及其祖先，无外部 prerequisite；会在本任务的新隔离目录实际克隆并检查 HEAD。它仅包含任务分支引用，不打包其他工作分支。
+
+完整源码包含 lockfile、测试夹具和构建配置。Node/npm 依赖未内嵌，重新执行测试需要可用 npm registry 或预先准备的依赖缓存；Git 仓库恢复本身不依赖 GitHub。历史报告与性能 JSON 保留原来的源码归属，最新结论以本报告和 manifest 为准。

package/docs/issue-128-review-followup.md

@@ -1,58 +1,58 @@
-# Issue #128 复审修复记录
-
-本轮继续使用独立 Worktree `.worktrees/fix-128-background-worker` 和分支 `codex/fix-128-background-worker`。用户已取消 PR 交付：只保留本地提交、测试及复审材料，不推送、不更新 PR、不合并、不发布。源码固定提交为 `415096f19d09d9bcc29c44634c7ae78fd6c2f52d`（运行时修复提交为 `8a569b911f40f43934406f5362251cf44b2c28f0`，随后增加 Windows CI 并发限制）；后续证据提交只增加报告和测量结果。
-
-## 根因与修复
-
-原 Worker 在上一轮结束后重新安排 3 秒轮询，问题不是计时器重叠，而是每轮完整打开所有 namespace 才判断有无任务，以及 SQLite 打开时重复检查各 namespace 的 FTS 完整性。持久化派生索引已消除这一发现路径。本轮进一步修复独立复审发现的三个问题：
-
-1. **未变化的历史消息被重新标记为 FTS dirty。** 快照 UPSERT 会触发 UPDATE，但原触发器不检查变化。现在 UPSERT 跳过完全未变化的消息；FTS 触发器只关注内容、Block 归属、namespace 或 ID 的实际变化。直接 SQL 修改仍会标记旧键和新键，惰性修复保持增量。触发器升级置于事务内，避免安装期间漏掉并发写入。
-2. **前八个损坏键饿死后续健康键。** 重建新增持久化 `rebuild_after`，失败键等待 60 秒；通过到期索引选择下一批，跨重启继续。源数据变化立即重置等待并更换 generation。脏键不会使用过时的调度条目，失败也不会要求零延迟重排。该字段只属于可重建索引的修复信息，没有替代 Job 重试状态。
-3. **只有可封存 open tail 时反复加载而不封存。** Worker 使用 Core 的 `hasSealableTail()`，与实际封存使用同一判定；重启后即使没有任何 Job 也能生成 Block，完成后不再重复打开。直接 SQL 移除或移动 open tail 时也会使旧 namespace 失效。
-
-全范围自查及兼容复验另外发现并修复：
-
-- **额度恢复的毫秒竞态：** 本轮发现时间和历史额度截止时间原先各读一次时钟，跨毫秒时可能把可用额度当作未来到期；现在共享同一个 `now`，回归刻意让每次时钟读取递增。
-- **长模型超过租约时重复调用：** Summary、Extraction、Graph、Topic 仅在模型执行期间定期续租。续租只更新持久化 Job 元数据，不加载历史记忆，不修改业务 revision。正常保存会合并同一 running attempt 的新租约；恢复或完成写入在同一事务内校验修改前的租约，防止旧快照缩短租约或覆盖新认领。Topic 完成后仍清除租约，既有状态语义保留。租约停止续期后，原有到期恢复和尝试上限继续生效。
-- **空认领产生 revision 写入：** Graph/Topic 无可认领工作时直接返回，避免另一 worker 为一个空认领保存快照并使模型所有者的结果失效。
-- **Windows 测试进程压力：** 本地复验捕获了子进程启动 `EBUSY` 及其引起的 Vitest 进程池错误，不能把该轮断言通过当作整体通过。Windows CI 现在最多启动两个测试 worker；单项超时不变。后续在本任务内独立 Node 24/npm 入口下完整复验通过，未更改系统 Node 或其他任务运行时。
-
-## 空闲路径与旧任务
-
-空闲轮询只检查持久化调度/脏键到期索引、模型是否就绪、历史额度和独立 Profile Maintenance。不会枚举全部 namespace、打开完整记忆、读取原始消息正文、遍历历史 Graph 或重新计算全部 Topic 资格，也不再做全库 FTS 完整性检查。
-
-Jobs、Event 及 Topic ledger 始终是事实来源。任务保存与派生索引更新在同一事务中完成；同进程通知只是唤醒提示。跨进程写入由 SQLite 触发器留下持久化脏键，原有 3 秒轻量轮询发现它们。升级只初始化键列表，重建按 namespace 和 Event 批次让出事件循环，发布前校验 generation；重启、失败退避或模型未就绪不会丢掉待重建键。Topic 的 Event 版本变化即使尚无 Job，也参与派生资格计算。历史额度到期后恢复，Profile Maintenance 独立运行。
-
-## 验证
-
-- Windows x64 / Node `24.19.0`，`CI=true`：`npm run check`、`npm test`、`npm run build`、`node scripts/verify-package.mjs` 通过。
-- Core **306**、DSH **588**、WorkBuddy **10**，共 **904** 项通过，另有 **1** 项既有跳过。
-- Issue #128 定向回归共 **32** 项（Core 24、DSH 8）。包括 100 个含历史 namespace 十轮零完整加载；1000 个空闲 namespace 不枚举、不加载；只有任务 namespace 打开；四类调度；8 个坏键加第 9 个健康键及重启、退避解除；600 条旧消息在 Event/使用记录保存后 dirty 为零、检索修复调用为零；旧索引/FTS 升级；只有 open tail 的恢复；模型就绪、到期重试、次数上限、额度恢复和独立 Profile。
-- 四类长模型回归使用模拟时钟越过原 5 分钟租约，并启动另一真实 OS 进程；另一个进程模型调用/认领为零，原任务完成，续租计时器清除。另覆盖并发保存合并租约以及过时恢复/完成的事务拒绝。这是时间推进与真实进程竞争测试，不是真实等待数分钟的网络模型测量。
-- Windows DSH `0.2.0-rc.1` 的完整隔离兼容脚本已在上述固定源码、独立 Node 24/npm 入口下通过，包括类型检查、588 项 DSH 测试（1 项既有跳过）、构建、干净包安装、CLI 启动、管理接口、会话页及旧迁移。
-- Windows DSH `0.2.0-rc.2` 在同一固定源码和入口下完整通过同一流程，588 项 DSH 测试通过（1 项既有跳过），以及干净包安装、真实 CLI 启动、管理接口、会话页和旧迁移。两版脚本均正常退出，退出码为 0。
-
-最后一次完整测试中，原超时的 100 namespace 用例为 1.885 秒，历史额度章节重建用例为 2.268 秒；这些耗时包含各自夹具准备，受同机负载影响。没有提高原用例超时。夹具改用一个 writer 准备历史，完整加载计数只从夹具完成后开始。无法读取被封禁账号的 GitHub Actions 日志，因此不能把本地复验解释为已证明此前远端超时的唯一原因，也不声称远端 CI 已通过。
-
-单独的 rc.2 兼容轮中，上述两项分别为 0.959 秒和 0.981 秒，全部 DSH 测试用时 23.26 秒；此前整套测试中的 DSH 部分为 50.35 秒。保留两组结果，不用较快一轮代替较慢一轮。
-
-## 性能证据
-
-前次提交 `bf30690e7a6673f9c2a3a029f7506f368b6f8f9c` 的合成测量保留于 [原始 JSON](benchmarks/issue-128-windows.json)，未覆盖。上述固定源码的本轮测量另存为 [本轮 JSON](benchmarks/issue-128-windows-review.json)，其中记录了基线、源码 SHA、采集时间、CPU 原始时间和每轮耗时。
-
-命令：`node --expose-gc scripts/benchmark-worker-128.mjs`。Windows x64 / Node 24.19.0，每个场景 100 个 namespace，三轮串行 Worker 轮询，每轮结束后仍等待 3 秒，模型使用 stub。先准备一份已完成派生工作的数据库，再分别复制给基线 `e954eaf2f2cbbef4bb6226a2ebb35191424868c2` 和修复源码。基线副本移除新增调度/FTS dirty 触发器、表及 Summary/Extraction 租约列，避免把新维护成本算到旧代码。数据库准备、构建不计入轮询样本；测量时未并行运行本任务构建或测试。
-
-| 合成库 | 实现 | 进程 CPU 平均 | 平均轮询 ms | RSS 测量前/后 MiB | 峰值 RSS MiB | 三轮完整加载 |
-| --- | --- | ---: | ---: | ---: | ---: | ---: |
-| 8.53 MiB | 基线 | 19.66% | 2105.68 | 54.23 / 69.82 | 70.84 | 300 |
-| 8.53 MiB | 修复 | 0.34% | 13.50 | 53.98 / 51.82 | 55.27 | 0 |
-| 1449.42 MiB | 基线 | 61.80% | 10386.64 | 53.68 / 150.11 | 316.73 | 300 |
-| 1449.42 MiB | 修复 | 1.20% | 11.74 | 49.68 / 48.69 | 52.05 | 0 |
-
-CPU 使用 Node 进程 CPU 时间除以包含等待的总墙钟时间；RSS 是被测子进程内存，峰值由 `process.resourceUsage()` 提供。历史体积增加约 170 倍后，修复样本未表现出线性增长的轮询开销；零完整加载和索引查询计划另由定向回归保证。这里只测三轮，CPU 计数分辨率、同机负载及缓存会影响结果，不能据此承诺真实长期 CPU 固定为某个百分比。
-
-两次性能测量均是合成库、隔离 Worker 和模拟模型，不是用户 168 MB / 14 namespace 原库或完整 DSH 桌面进程。真实 CLI 兼容验收使用隔离 DSH Home/会话夹具，未接入用户生产数据库。实际原库的长期 CPU、内存、界面响应以及真实网络模型长耗时仍需人工验收。
-
-## 离线独立复审
-
-本轮没有推送或更新 PR #130。交付本地固定提交、相对基线的完整补丁、变更文件的完整当前/基线源码、Git bundle、本报告、两次原始性能 JSON、已通过的测试/兼容性日志以及中文复审提示词。离线包的 `manifest.json` 记录最终交付 SHA 和各文件 SHA-256；源码冻结在上述提交，后续证据提交只增加文档。复审必须检查整个调度与 FTS 改动，而不仅是三个阻塞项的补丁。
+# Issue #128 复审修复记录
+
+本轮继续使用独立 Worktree `.worktrees/fix-128-background-worker` 和分支 `codex/fix-128-background-worker`。用户已取消 PR 交付：只保留本地提交、测试及复审材料，不推送、不更新 PR、不合并、不发布。源码固定提交为 `415096f19d09d9bcc29c44634c7ae78fd6c2f52d`（运行时修复提交为 `8a569b911f40f43934406f5362251cf44b2c28f0`，随后增加 Windows CI 并发限制）；后续证据提交只增加报告和测量结果。
+
+## 根因与修复
+
+原 Worker 在上一轮结束后重新安排 3 秒轮询，问题不是计时器重叠，而是每轮完整打开所有 namespace 才判断有无任务，以及 SQLite 打开时重复检查各 namespace 的 FTS 完整性。持久化派生索引已消除这一发现路径。本轮进一步修复独立复审发现的三个问题：
+
+1. **未变化的历史消息被重新标记为 FTS dirty。** 快照 UPSERT 会触发 UPDATE，但原触发器不检查变化。现在 UPSERT 跳过完全未变化的消息；FTS 触发器只关注内容、Block 归属、namespace 或 ID 的实际变化。直接 SQL 修改仍会标记旧键和新键，惰性修复保持增量。触发器升级置于事务内，避免安装期间漏掉并发写入。
+2. **前八个损坏键饿死后续健康键。** 重建新增持久化 `rebuild_after`，失败键等待 60 秒；通过到期索引选择下一批，跨重启继续。源数据变化立即重置等待并更换 generation。脏键不会使用过时的调度条目，失败也不会要求零延迟重排。该字段只属于可重建索引的修复信息，没有替代 Job 重试状态。
+3. **只有可封存 open tail 时反复加载而不封存。** Worker 使用 Core 的 `hasSealableTail()`，与实际封存使用同一判定；重启后即使没有任何 Job 也能生成 Block，完成后不再重复打开。直接 SQL 移除或移动 open tail 时也会使旧 namespace 失效。
+
+全范围自查及兼容复验另外发现并修复：
+
+- **额度恢复的毫秒竞态：** 本轮发现时间和历史额度截止时间原先各读一次时钟，跨毫秒时可能把可用额度当作未来到期；现在共享同一个 `now`，回归刻意让每次时钟读取递增。
+- **长模型超过租约时重复调用：** Summary、Extraction、Graph、Topic 仅在模型执行期间定期续租。续租只更新持久化 Job 元数据，不加载历史记忆，不修改业务 revision。正常保存会合并同一 running attempt 的新租约；恢复或完成写入在同一事务内校验修改前的租约，防止旧快照缩短租约或覆盖新认领。Topic 完成后仍清除租约，既有状态语义保留。租约停止续期后，原有到期恢复和尝试上限继续生效。
+- **空认领产生 revision 写入：** Graph/Topic 无可认领工作时直接返回，避免另一 worker 为一个空认领保存快照并使模型所有者的结果失效。
+- **Windows 测试进程压力：** 本地复验捕获了子进程启动 `EBUSY` 及其引起的 Vitest 进程池错误，不能把该轮断言通过当作整体通过。Windows CI 现在最多启动两个测试 worker；单项超时不变。后续在本任务内独立 Node 24/npm 入口下完整复验通过，未更改系统 Node 或其他任务运行时。
+
+## 空闲路径与旧任务
+
+空闲轮询只检查持久化调度/脏键到期索引、模型是否就绪、历史额度和独立 Profile Maintenance。不会枚举全部 namespace、打开完整记忆、读取原始消息正文、遍历历史 Graph 或重新计算全部 Topic 资格，也不再做全库 FTS 完整性检查。
+
+Jobs、Event 及 Topic ledger 始终是事实来源。任务保存与派生索引更新在同一事务中完成；同进程通知只是唤醒提示。跨进程写入由 SQLite 触发器留下持久化脏键，原有 3 秒轻量轮询发现它们。升级只初始化键列表，重建按 namespace 和 Event 批次让出事件循环，发布前校验 generation；重启、失败退避或模型未就绪不会丢掉待重建键。Topic 的 Event 版本变化即使尚无 Job，也参与派生资格计算。历史额度到期后恢复，Profile Maintenance 独立运行。
+
+## 验证
+
+- Windows x64 / Node `24.19.0`，`CI=true`：`npm run check`、`npm test`、`npm run build`、`node scripts/verify-package.mjs` 通过。
+- Core **306**、DSH **588**、WorkBuddy **10**，共 **904** 项通过，另有 **1** 项既有跳过。
+- Issue #128 定向回归共 **32** 项（Core 24、DSH 8）。包括 100 个含历史 namespace 十轮零完整加载；1000 个空闲 namespace 不枚举、不加载；只有任务 namespace 打开；四类调度；8 个坏键加第 9 个健康键及重启、退避解除；600 条旧消息在 Event/使用记录保存后 dirty 为零、检索修复调用为零；旧索引/FTS 升级；只有 open tail 的恢复；模型就绪、到期重试、次数上限、额度恢复和独立 Profile。
+- 四类长模型回归使用模拟时钟越过原 5 分钟租约，并启动另一真实 OS 进程；另一个进程模型调用/认领为零，原任务完成，续租计时器清除。另覆盖并发保存合并租约以及过时恢复/完成的事务拒绝。这是时间推进与真实进程竞争测试，不是真实等待数分钟的网络模型测量。
+- Windows DSH `0.2.0-rc.1` 的完整隔离兼容脚本已在上述固定源码、独立 Node 24/npm 入口下通过，包括类型检查、588 项 DSH 测试（1 项既有跳过）、构建、干净包安装、CLI 启动、管理接口、会话页及旧迁移。
+- Windows DSH `0.2.0-rc.2` 在同一固定源码和入口下完整通过同一流程，588 项 DSH 测试通过（1 项既有跳过），以及干净包安装、真实 CLI 启动、管理接口、会话页和旧迁移。两版脚本均正常退出，退出码为 0。
+
+最后一次完整测试中，原超时的 100 namespace 用例为 1.885 秒，历史额度章节重建用例为 2.268 秒；这些耗时包含各自夹具准备，受同机负载影响。没有提高原用例超时。夹具改用一个 writer 准备历史，完整加载计数只从夹具完成后开始。无法读取被封禁账号的 GitHub Actions 日志，因此不能把本地复验解释为已证明此前远端超时的唯一原因，也不声称远端 CI 已通过。
+
+单独的 rc.2 兼容轮中，上述两项分别为 0.959 秒和 0.981 秒，全部 DSH 测试用时 23.26 秒；此前整套测试中的 DSH 部分为 50.35 秒。保留两组结果，不用较快一轮代替较慢一轮。
+
+## 性能证据
+
+前次提交 `bf30690e7a6673f9c2a3a029f7506f368b6f8f9c` 的合成测量保留于 [原始 JSON](benchmarks/issue-128-windows.json)，未覆盖。上述固定源码的本轮测量另存为 [本轮 JSON](benchmarks/issue-128-windows-review.json)，其中记录了基线、源码 SHA、采集时间、CPU 原始时间和每轮耗时。
+
+命令：`node --expose-gc scripts/benchmark-worker-128.mjs`。Windows x64 / Node 24.19.0，每个场景 100 个 namespace，三轮串行 Worker 轮询，每轮结束后仍等待 3 秒，模型使用 stub。先准备一份已完成派生工作的数据库，再分别复制给基线 `e954eaf2f2cbbef4bb6226a2ebb35191424868c2` 和修复源码。基线副本移除新增调度/FTS dirty 触发器、表及 Summary/Extraction 租约列，避免把新维护成本算到旧代码。数据库准备、构建不计入轮询样本；测量时未并行运行本任务构建或测试。
+
+| 合成库 | 实现 | 进程 CPU 平均 | 平均轮询 ms | RSS 测量前/后 MiB | 峰值 RSS MiB | 三轮完整加载 |
+| --- | --- | ---: | ---: | ---: | ---: | ---: |
+| 8.53 MiB | 基线 | 19.66% | 2105.68 | 54.23 / 69.82 | 70.84 | 300 |
+| 8.53 MiB | 修复 | 0.34% | 13.50 | 53.98 / 51.82 | 55.27 | 0 |
+| 1449.42 MiB | 基线 | 61.80% | 10386.64 | 53.68 / 150.11 | 316.73 | 300 |
+| 1449.42 MiB | 修复 | 1.20% | 11.74 | 49.68 / 48.69 | 52.05 | 0 |
+
+CPU 使用 Node 进程 CPU 时间除以包含等待的总墙钟时间；RSS 是被测子进程内存，峰值由 `process.resourceUsage()` 提供。历史体积增加约 170 倍后，修复样本未表现出线性增长的轮询开销；零完整加载和索引查询计划另由定向回归保证。这里只测三轮，CPU 计数分辨率、同机负载及缓存会影响结果，不能据此承诺真实长期 CPU 固定为某个百分比。
+
+两次性能测量均是合成库、隔离 Worker 和模拟模型，不是用户 168 MB / 14 namespace 原库或完整 DSH 桌面进程。真实 CLI 兼容验收使用隔离 DSH Home/会话夹具，未接入用户生产数据库。实际原库的长期 CPU、内存、界面响应以及真实网络模型长耗时仍需人工验收。
+
+## 离线独立复审
+
+本轮没有推送或更新 PR #130。交付本地固定提交、相对基线的完整补丁、变更文件的完整当前/基线源码、Git bundle、本报告、两次原始性能 JSON、已通过的测试/兼容性日志以及中文复审提示词。离线包的 `manifest.json` 记录最终交付 SHA 和各文件 SHA-256；源码冻结在上述提交，后续证据提交只增加文档。复审必须检查整个调度与 FTS 改动，而不仅是三个阻塞项的补丁。

package/docs/npm-release.md

@@ -0,0 +1,52 @@
+# npm 暂存发布
+
+目标是把大包上传、网络重试放在用户认证之前。当前仅走 npm；GitHub 恢复前不执行 PR、CI、Tag、Release、trusted publishing 或 Roadmap 同步。
+
+## 前置条件
+
+- 用户已验收候选并明确授权正式发布；本脚本不会代替验收、源码审查或相关测试。
+- 正式源码已固定，版本和锁文件一致，正式 `.tgz` 已构建、校验并记录 SHA-256。不得用候选版本代替正式版本，也不重新打包覆盖原文件。
+- 使用满足项目 engines 的 Node，及支持 `npm stage publish/list/view/download/approve` 的 npm CLI。
+- 复用现有 npm 登录。只有登录确实不可用时才要求用户登录；发布认证与账号登录是两件事。
+
+## 执行
+
+使用 `scripts/release-npm.mjs`；所有路径参数可为绝对路径。以下 PowerShell 变量需替换为本次真实证据，不要复制历史临时 npm 路径或硬编码 registry IP：
+
+```powershell
+$releaseArgs = @(
+  '--artifact', '<已校验的正式包.tgz>',
+  '--sha256', '<审查时记录的SHA-256>',
+  '--evidence', '<本次独立证据目录>',
+  '--npm-cli', '<支持stage的npm-cli.js>',
+  '--userconfig', '<当前有效的npmrc>'
+)
+node scripts/release-npm.mjs @releaseArgs --action status
+node scripts/release-npm.mjs @releaseArgs --action stage
+# validating 时等待后再执行 stage，复用同一个 stageId，不重新上传。
+# STAGE_VERIFIED 后，才进入需要用户在 Edge 完成认证的步骤。
+node scripts/release-npm.mjs @releaseArgs --action approve
+node scripts/release-npm.mjs @releaseArgs --action verify
+```
+
+`status` 为默认操作，只查询远端、记录本地状态；已发布但尚未做完整下载核验时返回 `PUBLISHED_NEEDS_VERIFICATION`，执行 `verify` 下载核验即可，不再上传或认证。`stage` 上传或复用暂存包，并下载比对 SHA-256；`approve` 只批准已有、通过字节校验的暂存包，不会上传新包，批准成功后自动核验公开包。发布过程中保持进程运行，给用户实际返回的认证链接，禁止打开内置浏览器。用户确认完成后先检查原进程，不要另起一条 approve。
+
+脚本保留 `npm-release-state.json` 和下载的暂存包，使用进程锁避免同一证据目录并发认证。记录不包含 npm token、OTP 或 npmrc 内容。脚本只调用官方 registry，不关闭 TLS 校验，也不更改系统代理或 DNS。
+
+## 中断恢复
+
+- 每次先查公开版本：同版本内容一致就核验并结束，不再上传或认证；内容冲突则停止。tag 不一致单独报告，不重新发布。
+- 上传结果不明：先 `status`，远端存在匹配暂存包就复用。无远端记录时不自动再次上传；核实失败后才用 `stage --retry-upload`。本地没有记录时也会查询远端，避免跨进程重传。
+- 认证或批准请求断线：先检查原进程、公开版本和 stage 状态。脚本保留 `APPROVAL_UNCERTAIN`，不自动再认证。确认确实未发布且需要重试后才用 `approve --retry-approval`。
+- 原进程仍运行时等待原进程；不要创建新认证链接。失效链接只在实际重新发起必要认证时替换。
+- 网络、权限、服务器校验失败时保留包和证据，先排查原因，不退回直接 `npm publish` 循环，不通过关闭二次认证来减少操作。
+
+通常只需要最后一次发布认证；登录过期、认证链接过期或服务端明确要求时仍可能需要额外认证，不能保证永远只有一次。
+
+## 本地验证脚本
+
+```powershell
+node --test tests/npm-release.test.mjs
+```
+
+测试使用模拟 npm 和 registry，覆盖恢复、重复上传防护、认证失败和字节冲突，不访问真实发布接口。

package/docs/validation/issue119.md

@@ -1,41 +1,41 @@
-# Issue #119 修复与验证
-
-基线：`e954eaf2f2cbbef4bb6226a2ebb35191424868c2`（main，stratagate-dsh 0.3.6）。
-
-## 根因与修改
-
-- 日志中的 656、778 字符概要均正常结束于 `tool-calls`，被 600 字符业务上限拒绝，不能归因于 token 截断。现在使用 `TOPIC_OVERVIEW_MAX_CHARACTERS = 1000`，按 Unicode code point 计数，保留原文，不截断。
-- DSH `StringValueSchemaSpec` 只支持类型、枚举、常量和注解，不支持 `maxLength`。工具字段说明与提示词引用同一常量，解析器和存储提交门调用同一校验函数。
-- 旧 `TopicOverviewRepairGuard` 把未保存的违规草稿计数和来源持久化成补写义务，还从历史字段错误推导“至少一段”的要求。删除这套草稿守卫、错误携带和跨批分配逻辑，保留语义去重。旧 `overviewRepairRequirements` 字段仅供快照兼容与识别恢复对象，不发送给模型、不约束提交，重排、失败或成功时清理。
-- 有效旧概要仍由原有存储逻辑继承；章节成员与小节归属、来源权限、批次覆盖、源版本、租约、陈旧响应和原子提交检查继续生效。原有合法重分类、来源失效和遗忘语义不变，旧小节消失时仍按现有规则移除孤立概要。
-- 提示词先要求完整事件归类；新增概要通常 0～2 段，无必要时允许空数组，建议 300～600 字符，不为凑长度省略事实，不复述已有内容。
-- 沿用 `recoveryVersion`，升级为 2。仅恢复仍有效、有未完成工作且命中概要字段、旧草稿要求、Provider 失败或原始 `invalid-output` 签名的终态任务。无关内容校验、超时和 worker 失败不获得新周期。已完成来源、失效来源、已有排队工作、重启和并发写入沿用原有排除与持久化机制；单周期仍最多三次任务尝试，没有新增恢复状态机。
-
-## Provider 预算与剩余证据
-
-DSH `LlmResolvedModelInfo` 公开 `context.contextWindow` 和 `defaultMaxTokens`；后者仅是未显式指定输出预算时使用的普通默认值，不证明模型能力，也不限制 Topic 的独立请求。Topic 保留 32,768 上限，仅按实际 provider/model 路由已知的上下文剩余空间收缩。当前元数据没有可用的已验证模型输出硬上限，不据默认值猜测 Provider 限制。提示中的预算与每次实际请求保持一致，包括内容重试和 reasoning-off 回退。审查后的实现删除了普通默认值限流和对应缓存。
-
-无法容纳输入的模型配置报告 `provider-failed`，不归类成内容校验错误。输出实际截断继续用 `max-tokens` 和现有有界拆批；Provider 异常继续走现有任务退避，无新增专属补丁或重试次数。普通默认值为 512、1024 的路由测试使用 12 张 Event 和两段 1000 字符概要，完整响应的估算 token 超过这些默认值，断言实际请求仍使用独立预算并只调用一次；这是模拟流的请求策略验证，不是低实际预算下的真实生成能力测试。人工重试路径同时保留携带敏感响应的普通 `worker-failed` 脱敏测试。
-
-Issue 中那次 `finishReason=error` 的根因尚未确认。32,768 可能超过部分模型的输出能力，但也可能是限流、路由或其他请求错误。确认仍需要实际 Provider/model 标识、路由配置的 defaultMaxTokens 与 contextWindow、Provider 错误码/HTTP 状态/请求编号，以及 token usage（含 reasoning）和对应失败请求日志。不得凭当前安全摘要断言是哪一项。
-
-## 固定模拟响应对比
-
-在固定 main 与首轮修复提交 `6edcb34445e58e9df1ede0189e118672f90fcb42` 上运行同一临时重放测试，使用 `tests/llm.test.ts` 的 `modelBridge`、`context`、`proposal` 辅助函数；只把新概要 text 替换成 `𠮷.repeat(length)`。第一次与第二次流均正常结束于 `tool-calls`；656、778、1000 的第二次响应重复原响应；1001 的第二次响应返回空概要且保留全部章节/小节归类。其余输入与输出一致。保留这次原始测量；审查修复不改变这些未配置路由默认值的概要校验场景，新的定向测试继续覆盖其行为。
-
-| 首次字符数 | 修复前结果 / 调用数 | 修复后结果 / 调用数 |
-| --- | --- | --- |
-| 656 | 长度校验失败 / 2 | 首次通过 / 1 |
-| 778 | 长度校验失败 / 2 | 首次通过 / 1 |
-| 1000 | 长度校验失败 / 2 | 首次通过 / 1 |
-| 1001 → 空概要 | 草稿守卫拒绝 / 2 | 合法重试通过 / 2 |
-
-这组样例首次通过率 0/4 → 3/4，总调用数 8 → 5，最终完成 0/4 → 4/4。1001 字符始终拒绝，成功来自第二次合法结果。原始输出保存在 [修复前](issue119-before.json) 与 [修复后](issue119-after.json)。这是模拟流经过真实实现的测量，不是线上成功率、真实模型遵从度或提示词效果的测量；未调用真实 Provider，未读取用户数据库。
-
-## 回归范围
-
-定向测试覆盖 656、778、1000 / 1001 与补充平面 Unicode 字符，字段级诊断、Schema 与提示词、草稿舍弃、完整 Event 分类、旧概要和来源继承、伪造来源和遗漏 Event 拒绝、SQLite 重启、旧恢复要求、部分完成与重叠任务、重复提交、并发初始化、失败后有界拆批，以及 Provider 预算配置与分类。
-
-首轮修复提交在 Node 24.19.0 下：`npm run check` 全部通过；`npm test` 的 core 286、DSH 580、WorkBuddy 10 项通过，共 876 项通过、1 项既有跳过；`npm run build` 的 core、DSH 和 WorkBuddy 全部通过。隔离安装最初跳过安装脚本，导致旧数据库迁移测试缺少 better-sqlite3 绑定；用相同 Node 24 执行 `npm rebuild better-sqlite3` 后，完整测试通过。未修改依赖或锁文件。
-
-审查修复后的本地验证：`tests/llm.test.ts` 与 `tests/memory-topics.test.ts` 共 194 项通过，`packages/core/tests/topic-recovery.test.ts` 25 项通过，共 219 项定向测试通过；`npm run check` 和 `npm run build` 全部通过。已自查实际预算反馈、内容重试与 reasoning-off 回退、上下文预检分类、持久化来源/归属/旧概要保护和有界恢复路径。新提交仍需独立复审及其对应的 CI 结果；未执行用户真实 Windows + DSH 数据库的升级验收。
+# Issue #119 修复与验证
+
+基线：`e954eaf2f2cbbef4bb6226a2ebb35191424868c2`（main，stratagate-dsh 0.3.6）。
+
+## 根因与修改
+
+- 日志中的 656、778 字符概要均正常结束于 `tool-calls`，被 600 字符业务上限拒绝，不能归因于 token 截断。现在使用 `TOPIC_OVERVIEW_MAX_CHARACTERS = 1000`，按 Unicode code point 计数，保留原文，不截断。
+- DSH `StringValueSchemaSpec` 只支持类型、枚举、常量和注解，不支持 `maxLength`。工具字段说明与提示词引用同一常量，解析器和存储提交门调用同一校验函数。
+- 旧 `TopicOverviewRepairGuard` 把未保存的违规草稿计数和来源持久化成补写义务，还从历史字段错误推导“至少一段”的要求。删除这套草稿守卫、错误携带和跨批分配逻辑，保留语义去重。旧 `overviewRepairRequirements` 字段仅供快照兼容与识别恢复对象，不发送给模型、不约束提交，重排、失败或成功时清理。
+- 有效旧概要仍由原有存储逻辑继承；章节成员与小节归属、来源权限、批次覆盖、源版本、租约、陈旧响应和原子提交检查继续生效。原有合法重分类、来源失效和遗忘语义不变，旧小节消失时仍按现有规则移除孤立概要。
+- 提示词先要求完整事件归类；新增概要通常 0～2 段，无必要时允许空数组，建议 300～600 字符，不为凑长度省略事实，不复述已有内容。
+- 沿用 `recoveryVersion`，升级为 2。仅恢复仍有效、有未完成工作且命中概要字段、旧草稿要求、Provider 失败或原始 `invalid-output` 签名的终态任务。无关内容校验、超时和 worker 失败不获得新周期。已完成来源、失效来源、已有排队工作、重启和并发写入沿用原有排除与持久化机制；单周期仍最多三次任务尝试，没有新增恢复状态机。
+
+## Provider 预算与剩余证据
+
+DSH `LlmResolvedModelInfo` 公开 `context.contextWindow` 和 `defaultMaxTokens`；后者仅是未显式指定输出预算时使用的普通默认值，不证明模型能力，也不限制 Topic 的独立请求。Topic 保留 32,768 上限，仅按实际 provider/model 路由已知的上下文剩余空间收缩。当前元数据没有可用的已验证模型输出硬上限，不据默认值猜测 Provider 限制。提示中的预算与每次实际请求保持一致，包括内容重试和 reasoning-off 回退。审查后的实现删除了普通默认值限流和对应缓存。
+
+无法容纳输入的模型配置报告 `provider-failed`，不归类成内容校验错误。输出实际截断继续用 `max-tokens` 和现有有界拆批；Provider 异常继续走现有任务退避，无新增专属补丁或重试次数。普通默认值为 512、1024 的路由测试使用 12 张 Event 和两段 1000 字符概要，完整响应的估算 token 超过这些默认值，断言实际请求仍使用独立预算并只调用一次；这是模拟流的请求策略验证，不是低实际预算下的真实生成能力测试。人工重试路径同时保留携带敏感响应的普通 `worker-failed` 脱敏测试。
+
+Issue 中那次 `finishReason=error` 的根因尚未确认。32,768 可能超过部分模型的输出能力，但也可能是限流、路由或其他请求错误。确认仍需要实际 Provider/model 标识、路由配置的 defaultMaxTokens 与 contextWindow、Provider 错误码/HTTP 状态/请求编号，以及 token usage（含 reasoning）和对应失败请求日志。不得凭当前安全摘要断言是哪一项。
+
+## 固定模拟响应对比
+
+在固定 main 与首轮修复提交 `6edcb34445e58e9df1ede0189e118672f90fcb42` 上运行同一临时重放测试，使用 `tests/llm.test.ts` 的 `modelBridge`、`context`、`proposal` 辅助函数；只把新概要 text 替换成 `𠮷.repeat(length)`。第一次与第二次流均正常结束于 `tool-calls`；656、778、1000 的第二次响应重复原响应；1001 的第二次响应返回空概要且保留全部章节/小节归类。其余输入与输出一致。保留这次原始测量；审查修复不改变这些未配置路由默认值的概要校验场景，新的定向测试继续覆盖其行为。
+
+| 首次字符数 | 修复前结果 / 调用数 | 修复后结果 / 调用数 |
+| --- | --- | --- |
+| 656 | 长度校验失败 / 2 | 首次通过 / 1 |
+| 778 | 长度校验失败 / 2 | 首次通过 / 1 |
+| 1000 | 长度校验失败 / 2 | 首次通过 / 1 |
+| 1001 → 空概要 | 草稿守卫拒绝 / 2 | 合法重试通过 / 2 |
+
+这组样例首次通过率 0/4 → 3/4，总调用数 8 → 5，最终完成 0/4 → 4/4。1001 字符始终拒绝，成功来自第二次合法结果。原始输出保存在 [修复前](issue119-before.json) 与 [修复后](issue119-after.json)。这是模拟流经过真实实现的测量，不是线上成功率、真实模型遵从度或提示词效果的测量；未调用真实 Provider，未读取用户数据库。
+
+## 回归范围
+
+定向测试覆盖 656、778、1000 / 1001 与补充平面 Unicode 字符，字段级诊断、Schema 与提示词、草稿舍弃、完整 Event 分类、旧概要和来源继承、伪造来源和遗漏 Event 拒绝、SQLite 重启、旧恢复要求、部分完成与重叠任务、重复提交、并发初始化、失败后有界拆批，以及 Provider 预算配置与分类。
+
+首轮修复提交在 Node 24.19.0 下：`npm run check` 全部通过；`npm test` 的 core 286、DSH 580、WorkBuddy 10 项通过，共 876 项通过、1 项既有跳过；`npm run build` 的 core、DSH 和 WorkBuddy 全部通过。隔离安装最初跳过安装脚本，导致旧数据库迁移测试缺少 better-sqlite3 绑定；用相同 Node 24 执行 `npm rebuild better-sqlite3` 后，完整测试通过。未修改依赖或锁文件。
+
+审查修复后的本地验证：`tests/llm.test.ts` 与 `tests/memory-topics.test.ts` 共 194 项通过，`packages/core/tests/topic-recovery.test.ts` 25 项通过，共 219 项定向测试通过；`npm run check` 和 `npm run build` 全部通过。已自查实际预算反馈、内容重试与 reasoning-off 回退、上下文预检分类、持久化来源/归属/旧概要保护和有界恢复路径。新提交仍需独立复审及其对应的 CI 结果；未执行用户真实 Windows + DSH 数据库的升级验收。