[qiyuanhuakai]

Task 50 — benchmark composition seeding.

runtime-v090-benchmark.mjs gains SLO, DATASET, TREE, planComposition, seedTreeComposition and planCompositionAgreesWithFrozenFixtureOracle; runtime-v090-performance.mjs is the driver. The two files are import-coupled (the driver imports SLO/DATASET/TREE from the benchmark) so they cannot be separated into different commits — the driver's own header still says "Task 44 — performance DRIVER".

Verification: app/runtimeFixture.test.ts (the referencing test) 8/8 green; vue-tsc --noEmit exit 0; oxlint warnings-only.

[qiyuanhuakai]

AI 辅助源码审查（dot；中文顶层评论，非 APPROVE / REQUEST_CHANGES）。

审查 head：45d30200fdd3ee74d8b058dae36f267dee45213e
base：ccca97b5ae8becbbd984f9d9b3791e9a31f9d278。
范围：本 PR 两个 benchmark/performance 文件及实际采样、评分与恢复验收调用链。发评前重读仍 open、未合并，head 未变、讨论为空。当前性能报告有以下误判通过及覆盖不足的问题。

1. [P2] 操作失败仍可通过性能评分。
   cacheOpenProbe 没找到 draft 仍记录耗时；cacheExportBatch 捕获异常后记录耗时和 null digest；event-visible 找不到新增 header 时返回 seen=false。但 openProbeFound、selectedPageDigests、eventVisible.seen 未进入评分条件，结果仅按延迟通过。因此在其余检查正常时，打开/导出失败或事件不可见，仍可能因“返回得快”通过。
   来源：打开/导出、event-visible、汇总、评分。
   建议先验证成功状态和内容，再评分耗时；失败样本必须使对应检查失败，并补失败但低延迟的负控。

2. [P2] draft coverage 四舍五入让遗漏记录仍成为 100%。
   coverage 公式 先把百分比四舍五入到两位，draft 评分 只判断 coveragePct===100。stress 预期 100001 个，visitedPrefix=99996 时公式仍得到100，漏5个也通过 complete coverage。pins/tree 有其他精确条件，drafts 没有等价保护。
   建议以 visitedPrefix===expected 决定通过，舍入只用于展示；增加缺1/5个的失败断言。

3. [P2] network100ms 的正式采样发生在网络延迟被清零之后。
   driver 顺序 是设置100ms网络→runDraftsLeg→正式采样/coverage；但 runDraftsLeg 离线结束 固定恢复 latency:0 与无限吞吐，没有恢复进入离线段前的profile，正式采样前也未重设。后续样本仍标记为100ms profile，实际网络条件已不同。
   建议保存/恢复原网络参数，正式采样前验证配置，避免按标签而非实际条件验收。

4. [P2] 没有执行 restart，却将恢复检查标为 offline/restart/switch/resume 通过。
   离线读取和关闭顺序 在现有 page/store/cache 中读回，dispose/close 在读取之后；此前没有销毁重建这些实例。评分 仅统计 offline hash、resume hash、switch found 三项却声称涵盖restart。这只支持当前实例的离线读取，不能证明重启恢复。
   建议增加实际销毁重建后的离线持久化读回，把restart作为单独的通过条件。

5. 覆盖缺口：只有2KiB单body草稿，没有大正文/附件场景。
   导入实现 只创建一个body part，每个draft输入 固定size:2048。增加记录数不等于验证单条大正文、跨分块或附件的读取、编辑、恢复与内存边界。此项是明确的验收覆盖缺口，不表述为已复现产品运行时故障。
   建议补大正文/附件负载、逐块内容/编辑hash及离线重启读回，报告分开记录不同负载；完成前限制相关覆盖声明。

验证与继承边界：本次重新核对该SHA的两文件及公式/调用顺序，没有新跑完整浏览器性能测试或重启恢复实验，也不把历史探针冒充本轮新执行。作者8/8及类型检查声明不作为我的独立结果。CI 39109829751 当前completed/failure，Validate在Lint/type-check失败；既有日志的TS7016属于上游ports声明缺口，不是上述benchmark问题的复现证据，也不重复计作本PR新问题。下游#205补声明不能修复此处评分/采样逻辑。本审查不保证没有其他缺陷。

[qiyuanhuakai]

AI 辅助增量源码复核（dot；中文顶层评论，非 APPROVE / REQUEST_CHANGES）。

审查 head：33af688b9abbaa103aa0976eae8da119a5dae7bc
base：ccca97b5ae8becbbd984f9d9b3791e9a31f9d278。
相对上轮评论的 45d3020，本次增量是 1 个提交、3 个文件。发评前重读仍 open、未合并，head 未变，无本轮重复结论。

原四项评分/采样问题已有实质修复，但新增两个阻塞，不能判整体验收通过。

• driver L114–117加入打开成功数、非空导出 digest 数和事件可见数门槛，失败但很快不再仅靠耗时通过。
• L131–132按精确数量评分，缺 1/5 条记录即便百分比四舍五入为 100 也拒绝。
• L299–306在恢复/负载操作结束后、正式采样前重新应用远程 network 条件，并加入实测往返检查；原先清零后仍按 100ms 标签采样的顺序问题已修。
• benchmark L1203–1216现在确实 dispose cache、close store、导航到新 document、重新打开 store/cache，再断网读回，并单独评分 restart。独立受控 stack 探针确认这个调用顺序及预期 hash；它证明重新建实例的编排，不是本轮真实 Chromium/IndexedDB 或整个应用离线冷启动验证。

新问题

1. [P1] 新增负载草稿污染普通 draft coverage，健康运行也必然失败。
   driver L299给 runLoadsLeg 传入 ${prefix}-load；benchmark L1271再生成两个 profile 共 8 个唯一 context。但 runCoverage L999–1003把所有以 ${prefix}- 开头的 context 都计入普通 2KiB 草稿，故这 8 条也被算进去。新精确评分行随即拒绝它们。
   本轮直接导入未修改的 runLoadsLeg、runCoverage、evaluateThresholds，在受控 page/store 响应中复现：两项负载各自 4/4、12/12 parts 的导入/hash/离线读回均成功，但标准 coverage 为 10009/10001，passed=false；stress 为 100009/100001，passed=false。network100ms 使用同一标准数据集也受影响。该探针没有运行真实浏览器或 IDB。
   建议让负载使用不匹配普通 draft filter 的独立命名空间，或让 coverage 严格识别该数据集的 identity；补 runLoadsLeg→runCoverage 联合回归。当前手工构造 COVERAGE 的评分单测不能发现这个集成冲突。

2. [P1] 新增 TypeScript 测试自身无法通过现有类型检查。
   测试 L11–12直接导入无声明的两个 .mjs；L49–60等处参数为隐式 any，extra 默认推断为 {} 却访问 draftsLeg/loadsLeg。
   本 head Validate 日志已报告该新文件 19 个错误：TS7016、TS7006、TS2339，pnpm lint / vue-tsc exit 2，后续测试未执行。另有 6 个既有 ports TS7016，属于继承问题，不能混成 25 个新缺陷，也不能把本次红灯全部归因上游。
   建议补可检查的模块声明和测试输入/输出类型，包括 helper 的 options 类型，重跑项目原有 type-check；不要只验证 Node 能执行断言。

原负载覆盖缺口：部分补齐，尚不能关闭全部范围。
新增 LOAD_PROFILES L124–139确实增加 512KiB body 与每条两个 128KiB attachment，并逐 part hash/离线重建读回。它仍没有覆盖仓库 seed090 L8–11规定的每 100 条 1MiB attachment 分布、16MiB body、64MiB large attachment。请补齐这些规模或明确缩小验收声明；这里是可核对的覆盖限制，不声称已经复现产品的大文件运行时故障。

独立验证与继承边界
用 Node v24.19.0 和轻量 assert 适配器执行新增测试的 15 个原始回调，15/15 通过，验证负控/正控的评分逻辑；这不是 Vitest 或 TypeScript 编译通过，恰好说明单测逻辑通过与新文件类型错误可以同时存在。另运行上述真实函数+受控响应的 prefix 集成及 restart 顺序探针。没有实际跑性能基准、浏览器/native、真实网络延迟或大负载内存测量，未把作者结果当独立实测。

本次 3 文件增量没有整合 #200 后续 App delivery 修复；其余 stack 问题仍按各自 SHA 判断。CI 终态补记（2026-10-19 04:07 UTC）：CI 39197361222已结束，Validate failure（19 个新增测试类型错误 + 6 个继承 ports 错误），其余 11 个 Electron/Bridge installer 矩阵任务 success，Complete CI failure，Publish draft release skipped。打包成功不代表 benchmark 已执行或性能通过。本审查不保证不存在其他缺陷。

[qiyuanhuakai]

AI 辅助增量源码复核（dot；中文顶层评论，非 APPROVE / REQUEST_CHANGES）。

审查 head：5e1ebc0ef1ecab1f6eac9504ec514e80baed9923。
相对上轮 33af688b 评论，本轮 1 个提交、5 个文件：两份模块声明、测试类型/联合回归与 draft identity 识别修正。

上轮两个 P1 已修复。

1. 普通 draft coverage 不再把 8 个 load drafts 算进去。benchmark L840–844及实际分页过滤 L1061–1071只识别 prefix-NNNNNN；drafts leg L1234–1241采用相同规则。driver L297–307经 shared helper 传 load prefix，负载仍有自己的逐 part/hash/restart 评分。
   本轮独立导入该 head 的实际 runLoadsLeg、runCoverage、evaluateThresholds，用受控 page/store 响应验证：总 header 数仍包含全部 8 条负载（10009 / 100009），普通 coverage 正确回到 10001/10001 和 100001/100001，passed=true；两个 load rows 的 4/4 和 12/12 parts 仍通过。删除一条普通 draft 的负控则分别得到 10000/10001、100000/100001，passed=false，全部 8 条 load 保留。原“健康运行必然失败”回归已消除，不是降低阈值或删除负载行。
2. 原测试 19 个类型错误已修。测试输入与 helper 类型 L49–98及新增 benchmark.d.mts、performance.d.mts补齐模块和参数类型。当前 Validate的 lint/type-check、测试和 web build 已 success；性能测试 21/21，整套 618 files / 6206 tests passed，2 files / 5 tests skipped。这些是独立读取的外部 CI 证据，不是本轮本地执行 vue-tsc/Vitest 的声明。

新增联合回归 L391–405确实把真实 drafts→loads→coverage 编排放在同一受控 header 集合上；它覆盖此前手工 COVERAGE 对象看不到的冲突。

仍需保留原负载覆盖限制。
LOAD_PROFILES L124–139仍是 512KiB body 和每条两个 128KiB attachment，没有补齐 seed090 L8–11规定的每 100 条 1MiB attachment 分布、16MiB body、64MiB large attachment。请补齐或明确缩小验收声明。这是原覆盖缺口未完成，不是新发现的大文件运行时故障；两个 P1 修好也不能证明全负载性能验收通过。

验证、继承与 CI 边界
本轮另用 Node 内置类型擦除 + node:assert 适配器执行该测试文件的全部 21 个原始回调，21/21 通过。适配仅替换 Vitest 导入和 evidence 输出为新建独占临时目录；保留断言/hooks，实际 benchmark/driver 未修改。这不是本地 Vitest 或 TypeScript 编译通过。本轮只做上述源码/声明对照和真实函数 + 受控响应的定向验证，没有执行完整性能 benchmark、真实浏览器/IndexedDB、native、网络延迟或峰值内存测量。此前四项评分/采样修复保留，本轮未确认新增运行时缺陷。

当前 #201 head 仍从 ccca97b 分叉；#200 最新 a828d34 不在其祖先链。CI 检出的实际测试合并提交 7612900 则已合入该最新 #200，所以旧六处 ports 错误在本次 CI 合并树消失。不能继续把它们列为当前 CI 红灯，也不能反过来说 #201 head 已回补所有 #200 修复。
CI 终态补记（2026-10-19 06:31 UTC）：CI 39209279577 completed/success；Validate、11 个 Electron/Bridge installer 打包任务及 Complete CI 均 success，Publish draft release skipped。以上是测试合并树的外部 CI 结果，打包/单测成功不等于性能 benchmark 或缺失的大负载规模已经验收。

[qiyuanhuakai]

本轮推送 2 个提交，PR head 已从 5e1ebc0 推进到 930bd4c。

1. 大负载覆盖缺口：已补齐，并明确缩小验收声明

LOAD_PROFILES 此前用的是缩小替代规格（512 KiB body、两条 128 KiB attachment），未触及 seed090.json 冻结输入规定的规模。现按冻结输入字面值执行：

• large-body：body 16 MiB（largeBodyBytes）
• multi-part-attachment：每 100 条记录的形状——2 KiB body + 两条 1 MiB attachment（attachmentBytes）
• 新增 oversized-draft（1 条）：16 MiB body + 64 MiB attachment，即 fixture 中那一份额外草稿本身
• expectedPartHash 改为记忆化：oracle 的输入与输出不变，只是避免重复生成相同的数 MiB 缓冲区

验收边界由检查保证，不是只在注释里声明：

• 每 100 条 1 MiB 附件的整体分布（10k 档 100 条、100k 档 1000 条）由 scripts/qa/runtime-v090-fixtures.mjs 的 check 对全量数据集逐 draft 校验（每条正文 2 KiB、仅第 100 条倍数带 1 MiB 附件、末尾一条 16 MiB/64 MiB，且逐字节区间做 hash 复核、文件级 hash 与总字节数兜底）；app/runtimeFixture.test.ts 在 10k 与 100k 两个档位都实际执行了 generate+check（8/8 通过，含 100k 全量分布检查）。
• 本 leg 采样规定尺寸（每个采样类 4 条 + 规定的 1 条超大草稿）：100k 档全部导入附件草稿（1000×1 MiB）超出本 leg 预算，故不做全量导入。
• 本 leg 验收的是每个负载类别经过真实 store 的规定 SIZE：逐 part 对照独立 Node 侧 oracle 做 hash 校验，导入时与真实离线重启后各一次，逐 part 记录在 load-import-hash-ledger.json（含每条 part 的 size、预期/落库/回读 hash 与 match）。

本地验证：app/runtimeV090Performance.test.ts 21/21（新增断言逐字校验 16 MiB / 2 KiB+1 MiB / 16 MiB+64 MiB，load header 计数改由 LOAD_PROFILES 导出而非冻结的 8）；app/runtimeFixture.test.ts 8/8；oxlint 退出 0；vue-tsc --noEmit 退出 0。未执行完整性能 benchmark、真实浏览器/IndexedDB、native、网络延迟或峰值内存测量——这些仍不在本次本地验证范围内。

2. #200 修复回补情况（精确表述）

精确说法：六份服务声明与 node:crypto 接缝在本 head 上以本分支自己的提交 a0ac53885 存在，与 #200 的 a828d3454a13 逐字节相同（blob sha 比对：checkpointService.d.ts、handoffService.d.ts、coordinator.d.ts、delegationService.d.ts、fanoutService.d.ts、mailbox.d.ts、app/utils/nodeCrypto.ts、nodeCrypto.test.ts、vite.config.ts 共 9 个文件全部 SAME）。不是"#200 已合入本分支"——a828d3454a13 的提交对象不在本分支祖先链中（merge-base --is-ancestor 为否）。

同时如实说明其余部分：a828d3454a13 该提交本身的 9 个文件之外，#200 分支还有三个更早的提交（086a59b1e 协作回执修复、6dfc672c2 backend-kind 接线、d8c11681b 合入 #199 的 App.vue 接线）改了 app/App.vue（+50/-8）与 app/appScopeRegressions.integration.test.ts（+324），这些不在本 head 上；本分支从未改动过这两个文件，它们随 #200 的堆叠合入自然带到 #201（CI 测试合并树 7612900 已包含）。因此不能说"#201 head 已回补所有 #200 修复"——本分支回补的是独立构建所需的声明层。

3. 本地全量测试结果

vitest run：620 个测试文件中 615 个通过；2 个文件失败（serverLive.integration.test.ts、buildArtifact.integration.test.ts），同一环境性原因：本 worktree 的 node_modules 是指向主仓库 vis/node_modules 的符号链接，ensure-production-dist 内部跑 pnpm install 时 pnpm 以 ERR_PNPM_UNSAFE_MODULES_DIR 拒绝（目标不在项目根目录内）。已将本轮改动 stash 后在纯 HEAD 上复跑这两个文件，失败完全相同，证明与本轮改动无关；这两个用例与两个已知 flake（runtimeGit 200-workspace、kimiWebWsProxy 502）本轮均未在 CI 之外引入新失败。

[qiyuanhuakai]

AI 辅助独立增量复核（dot）。

审查 head：930bd4cc69950be6c64f1e95a1bf0de78cb9d637。相对 5e1ebc0 为 2 个提交、11 文件；发布前重读 head/comments，PR open、未合并。

结论：原“大负载尺寸没有体现”的覆盖缺口已补齐，验收范围也已明确缩小为采样尺寸覆盖；本轮未确认新的增量缺陷。不能由此认定完整分布的实际性能已验收。

LOAD_PROFILES L144–170现在包含 4 条 16MiB 正文、4 条 2KiB 正文加两份 1MiB 附件、1 条 16MiB 正文加64MiB附件。尺寸对应 seed090 冻结输入 L7–11，没有继续用512KiB/128KiB替代大文件。已有 runLoadsLeg按各 profile 逐 part 写入与核 hash，driver L232–246遍历当前 LOAD_PROFILES，为新增 oversized-draft 单独评分；未测量的 profile 不会获得通过。hash memoization 以 size/seed 为 key，只复用预期摘要，不将存储回读结果拿来充当 oracle。

独立定向验证：重新取回当前实际 benchmark/driver/测试，以 Node 24 内置类型擦除和 node:assert 适配器执行测试文件的 21 个原始回调，21/21通过。适配只替换 Vitest 导入/断言及临时输出位置；测试使用受控 page/store 响应，实际编排与评分函数未改。新增尺寸断言、第三类负载、9个负载header与普通draft覆盖隔离均通过。此结果不等于运行了真实浏览器、IndexedDB或完整Vitest，也没有测出真实时间、网络、峰值内存或原生升级性能。

仍需保留的验收边界：

• L130–142 的说明已明确：本leg只采样每类4条加1条超大草稿；不把100k档全部1000份1MiB附件导入真实store。
• 每100条带附件的全量分布由 fixture生成/校验和 逐draft尺寸/字节清单校验负责。这验证生成数据分布，与真实store全量加载的性能是两种证据。本轮没有独立生成整套10k/100k fixture，也不把作者的本地报告改称我的执行结果。
• 多附件profile有两份1MiB附件，是采样覆盖，不是每100条恰好一份附件的全量数据集复现。最终性能结论应继续标明这一范围。

堆叠修复：新增六份声明、nodeCrypto seam/测试及Vite alias共9文件，与已审 #200 a828d34 逐一blob SHA一致，已实际回补本head；没有把此前App接线/协作回执等其他#200修改一并算作已回补。上轮两个P1修复维持原结论。

CI终态更新（2026-10-19 14:04 UTC）：head未变，39264057723 completed/success。Validate、11个安装/打包job、Complete CI共13个job成功，发布跳过。Validate日志显示 runtimeV090Performance.test.ts 21/21、runtimeFixture.test.ts 8/8，整套618 files / 6206 tests passed，2 files / 5 tests skipped；lint/type-check和web build成功。实际测试合并提交00bccf988b212d6ce7edf9df3969e24103b05c71合入#200 a828d34。CI属于外部运行证据，仍不能替代实际性能benchmark或全量附件分布导入验收。