[R2][回归] 收敛 Windows 可靠性与历史未闭合失败

当前可靠性收口（2026-11-01）

本项是R2可靠性汇总，不与子项重复计工作量。原生阻塞关系中仍开放的只有 #44/#80/#99；#35的最终声明配置还需复验。

子项	已有证据	未完成
#44 controller B自然退出	close前wait/exit端点及取消/自然退出三类签名；最新96用例未复现	原child→cmd交接触发条件/根因仍未知，不能将推断写作因果修复
#80 hosted四shell原stage6	stage5 WSL观察窗口已修；本机7/7和新hosted通过	原stage6事件未复现，同因性未知
#99 剪贴板原45秒超时	首错/当前步骤/清理分列；Draft300两轮默认场景完成	失败瞬间stage/owner/helper/UI泵仍未知，诊断分支不算产品修复

已关闭项的处理依据

用户决定记录：清单A同意、47A/52A/34B、29/30保留。#36/#40/#57/#73/#97/#144/#145/#160等按限定事实、接受未复现或范围处置关闭；#194亦按用户接受未复现关闭。它们的原始失败与重开条件保留，不是全部根因修复。

#47后端整合复验转#35；#52实验路线退出本轮；#34路线与接口说明已收口。#31跨屏转#297/R4。上述均不再在本汇总里排成当前故障队列。

后续规则

每项新批次先有可证伪假设、固定source/负载/环境、上限与停止条件；已有“当前main通过”不值得无目的重复。
保留原期限、字节与回收判据；close后码不替代自然退出，未复现不自行标为修复。
真实修复需关联原失败；若接受剩余风险/范围处置，记录用户明确决定，不能从其他项的关闭推导。
最终正式包的实际结果由#35承担，历史默认/参考构建成功不能组合成产品联合通过。

证据索引。本次刷新未重跑或关闭任何开放子项。

基于 #33 工作树的完整默认 CTest 已自然结束：39/40。除 #36 的 normal/resize 外，新增多会话场景还出现一次 stage 2 标记等待超时，不能只归因于 #36。\n\n随后完整 shell 套件重跑中多会话两轮通过，35项仅有 #36 两项失败；因此该多会话失败按间歇问题保留，不宣称已根治。超时诊断现会保存有界 PTY 输出与文本屏幕，不生成截图。记录：validation.json。\n\n旧 ui-main/分屏等失败未复现不等于全部修复，本 issue 保持 OPEN。

2b623108cf993300947d898847cdeecc164ae95c 同时修正了新增退出菜单的独立合同：Session 可用命令集合加入17，Copy/Select All 索引更新为9/10，并保留负例。\n\n修正前完整默认 CTest 为38/40（text_actions 和 shell 失败）；修正后 text_actions、真实选择 popup 和静态负例通过，完整复验为39/40，仅剩 #36 normal/resize。菜单造成的合同差异不另留开放项，#38 继续跟踪间歇多会话标记等待及其他未闭合回归。

当前 #29 未提交工作树的默认 Release 完整 CTest 已自然结束：39/40。命令为 ctest --test-dir build -C Release --output-on-failure，未减少负载、延长超时或跳过失败。

test_commands_unicode_editing_interrupt_and_normal_exit 与 test_resize_child_dimensions_and_interrupt 仍为持续输出后的 stage=5 超时，归既有 [R1回归] 持续 cmd 输出时 ETX 未中断导致 normal/resize 超时 #36。
本轮另有 test_workspace_v2_multiple_shells_split_and_geometry_restore 在首次 ui-workspace-save 的 stage=2 超时。它再次说明多会话/保存标记等待存在间歇缺口，不能只记录 [R1回归] 持续 cmd 输出时 ETX 未中断导致 normal/resize 超时 #36，也不能由 [R2-10][持久化] 恢复会话配置、窗口与工作区并处理迁移损坏 #33 已完成的局部恢复验收抵消。
本轮 text_actions、workflow_sessions、selection_bytes、selection_context 及真实 monitor round-trip 均通过；不据此宣称所有几何/交互问题已根治。

证据来自私有非输入 desktop、Job 和有界文本/JSON，没有截图或前台输入。#38、#29 与 R2 路标保持 OPEN。

补充定位并复验 #29 相关的后台超时：stage 11 连续复现时，没有把它归为普通间歇失败。按会话累计计时显示主要成本来自每次 feed 对全部历史做 replay reconcile，而不是盲目的历史合并。已改为缓存原始 FFI ID 与最终身份的映射，仍按完整行内容校验，未知旧 ID 保留全量回退；诊断样本不用于性能排名或百分比声明。

同一 90 秒、每路 32000 行后台场景随后通过，诊断开启时为 41.06 秒；移除诊断后的最终候选完整 CTest 中 workflow_sessions 为 41.16 秒并通过。最终候选全套为 41/42，剩余 shell 包含 #36 normal/resize，以及 #38 的 close/resize-close stage 2 和 workspace restore stage 1 失败；这些没有被隐藏或改写成通过。

#38 继续 OPEN，工作区几何、保存/恢复和其它间歇回归仍需独立闭合。全过程只使用私有非输入 desktop、Job 和文本/JSON，不截图或操作前台桌面。

已推送限定工作区切片 27f376d02009e2bcb916b5cb23767d9b7df10cdc，但本 issue 继续保持 OPEN，不能据此视为全部回归已闭合。

本次修正的是测试与观测合同：按真实客户区/DPI、原生滚动条和工作区边界验证几何；区分完整恢复与真实裁剪恢复；用有界历史判断会话文字仍被保留；以实际输出标记和后续提示符验证命令完成，避免把 PowerShell 编辑显示或 ConPTY 光标序列误判为输出丢失。观测开关也改为真实状态。

默认和候选各两轮保存/恢复、真实 65535 宽保存配置的裁剪恢复，以及保留原有两轮后的额外 1008×681 隔离场景已验证。未改变文字负载、超时或用户显示设置，未截图。

仍有 #36 中断、候选早期输入/关闭相关场景、真实 DPI/呈现及 CI 验收缺口；完整回归结果继续跟踪，不宣称全绿或 R2 完成。

完整结果与源码/二进制身份已归档并推送：4597a371c71c4506729db0689de93e98ec0479f8，见 experiments/shell/results/2026-10-26-workspace-geometry/validation.json。

确定源码树的默认 CTest 为 39/40，候选为 41/42；默认/候选保存恢复均已通过，但 #36 和候选早期输入/关闭场景仍失败。该记录只覆盖工作区几何、持久化和输出完成判据，#38 继续保持 OPEN，不宣称完整回归、真实 DPI、呈现或 R2 验收完成。

补充 Windows Server 2025 CI 对照（保持 OPEN）：

18c36ce 的主 CI 40241569730 为 Windows 39/40，但 shell 内有 3 errors：ui-shells 在 stage 4 超时，普通选择及系统复制选择均缺少 TF_FIND_050 needle 中文 é。Ubuntu 通过。
glyph 提交前的主 CI 40237901832 已出现相同三项失败。故不能把这些问题归因于本次 glyph 修复；同样不能在没有证据时归因于环境或 [R1回归] 持续 cmd 输出时 ETX 未中断导致 normal/resize 超时 #36。
本次 hosted 日志中的 normal/resize 中断场景通过，但这不替代本机 [R1回归] 持续 cmd 输出时 ETX 未中断导致 normal/resize 超时 #36 的持续失败，也不把不同环境的证据拼成全绿。

原始日志已通过 REST 作业接口核实；gh run view --log/--log-failed 返回空内容，没有据此臆测失败原因。#38 继续跟踪这些真实回归，#35/R2 不得据此宣称完成。

本次主 CI 40244057401 的 Windows 结果为 38/40：shell 仍是已记录的三项生命周期/选择失败；另有 ime_inventory 纯 PowerShell 夹具超过原 10 秒期限，已拆为子项 #40，并建立 #38 的原生 blocked-by 关系。

本机同一 inventory 测试一次为 1.633 秒通过，但不能代替 CI 修复，也不能据此归因于环境或 worker 缺陷。原超时未延长，#38/#40 均保持 OPEN，#35 的阻塞不解除。备用屏限定证据不替代这些回归的修复。

并行度普查：`ime_context` 与 `conpty` 是负载敏感项

在合并树（本会话 11 个 PR 全部合入）上做了一轮 flake 普查，方法固定为「高并行重复 + 隔离对照」。

方法

ctest --test-dir build-merged -C Release --timeout 300 -j 8   # 连续 3 轮
ctest --test-dir build-merged -C Release -R "^ime_context$" --repeat until-fail:10

环境：Windows 11 x64、Release、TERMFORGE_BIN_DIR 指向构建产物、两份仓库声明依赖已安装。

结果

并行度	轮次	结果
`-j 8`	3	67/67、66/67（`ime_context` 失败）、67/67
隔离	10	`ime_context` 10/10 通过，每次 0.51–0.63s

与之前一条评论的 conpty 记录合并：

测试	并行条件	表现	隔离对照
`conpty`	`-j 4` 全量	2 轮中失败 1 次	串行 `--repeat until-fail:3` 3/3 通过
`ime_context`	`-j 8` 全量	3 轮中失败 1 次	隔离 `--repeat until-fail:10` 10/10 通过

判读

两者都是负载敏感而非确定性失败：隔离下稳定通过，只有在整机并发（shell 约 100s、ime_inventory 约 60s 等同批运行）时偶发。

conpty 的失败签名先前已记录：test_large_ordered_payload 以 returncode=1 退出、timed_out=False，候选原因是 probe.cpp 关闭后固定 1 秒的句柄/线程 settle 窗口
ime_context 是 Win32 IME 上下文测试（experiments/shell/ime_context_test.cpp，链接 imm32/user32，CTest 超时 60s），隔离耗时仅 0.5s，失败集中在整机争用时

建议

不要用"重跑取绿"处理：一次失败既不能证明是负载敏感，也不能证明是缺陷；判别手段是隔离重复（本次两例都靠它区分）
对确认为负载敏感的项，二选一：set_tests_properties(... RUN_SERIAL TRUE)，或把整机 CTest 并行度降到 -j 4 以下
若选择保留高并行，应在报表里同时给出并行与串行两种结果，避免把宿主争用记成产品回归

一条方法学提醒

普查时若源码树当前分支与构建目录的配置分支不一致，Python 测试会以 ModuleNotFoundError 失败——这是环境不一致，不是 flake。本次第一轮普查就踩到了这一点，已剔除后重跑。

本条只记录观测与判读口径，不改测试属性、不改 CI 并行度。

诊断改动已全部落地（等待下一次命中）

下面每一项都对应本 issue 里记录的"单一观测"，现在都已经在 main 上：

观测	落地	触发后能回答什么
超时信息带 `js_start_after_create_ms`（CreateProcess→首行 JS）	`research/ui/test_raster_style_reference.py`（PR #274）	Node 启动慢到什么程度、是否仍在 CreateProcess 阶段
Node 侧 `spawn_seconds`/`exit_at_timeout`/`partial_stdout_bytes`	同上（更早）	进程是否还活着、是否写出任何字节
报告已序列化检查点 `report/emitted`	`research/ime/inventory_worker.ps1`（PR #278）	超时时报告是否已经写出（区分管道停顿与 worker 停顿）
超时期限时刻的子进程状态	`research/ime/test_hosted_inventory.py`（`exit_at_timeout`/`partial_stdout_bytes`）	子进程是否已退出
Workspace 场景失败的场景名与每标签页计数器	`experiments/shell/workspace.hpp` + `shell.cpp`（PR #275/#276）	选择/动作等场景失败在哪个会话、输入是否入队、读取是否活着
transport 判定窗口原文（`window_bytes`/`window_hex`）	`experiments/shell/local_shell_diagnostics.hpp`（PR #277）	窗口与标记是否仍在同一记录，可离线复算

本轮动作

已派发 3 轮 conpty-compat.yml（main），用于加速命中这些观测。命中后我会把各字段读数贴回对应 issue。

边界

这些都是观测，不改期限、不改判定；
命中之前，各 issue 的结论保持"未复现"状态。

R2 剩余开放项的当前状态（按处置方式分组）

下面的分组依据是这一项还需要什么才能动，不是难度。

A. 等一次 CI 命中（诊断已就位，命中即可判读）

issue	已就位的观测
#36 洪流 ETX	`output_bytes` vs `bytes`（PR #242）
#40 PowerShell 夹具	`report/emitted` 检查点（PR #278）
#57 candidate invalid text	标题事件的 kind/bytes/hex（PR #282）
#73 选择场景	Workspace 场景名 + 每标签页计数器（PR #275/#276）
#80 四 shell stage5	判定窗口原文 `window_hex`（PR #277）
#97 candidate-scroll	心跳尾部 + `frame.bmp` 存在性（既有转储）
#144 Node 10s	`js_start_after_create_ms`（PR #274）
#145 resize 旧尺寸	探针计数（既有）

B. 需要你决策

issue	待决内容
#194	修法方向：先排空 / 尺寸世代 / 识别吸收
#34	固定后端让显示优于原版，是否登记为「经确认的原版缺陷修正」
#31	R2 单屏范围是否确认（跨屏已移出 R2）

C. 交付与汇总

issue	现状
#35	已有带证据位置的交付清单（A–E 五类）
#38	本项：稳定性和残留问题的汇总口径

D. 需要真实环境

issue	说明
#31（跨屏部分）	已按决策 4C 移出 R2，推迟 R4

E. 其他

#27/#28/#29/#30/#44/#47/#52 等属能力与验收类，进展以各自 issue 的最近评论为准。

本轮新增的事实

windows-2022-conpty 在 main 上连续两次成功（run 41193269350 / 41193276156）；
[R2][调查] 核对 resize 期间 ConPTY 重绘与终端视口/缓冲的对齐 #194 的几何丢失样本显示「输出全部消费、输入无积压、子进程存活」，与"读取停滞"无关；
[R2][回归] 定位 Node 栅格纯夹具在 Windows CI 的原 10 秒超时 #144 新增 C 型样本（未进 JS），与 D 型（进 JS 但延迟 8.82 s）并存。

边界

分组只表示"下一步需要什么"，不代表已完成任何一项；
各 issue 的验收文字以其自身为准。

两次完整作业全绿（含 2022 与 actions-repeat）

在 #280（记录制端到端生效）合入 main 后，派发的两次 conpty-compat 运行全部 8 个作业成功：

run	作业结果
41193269350	8/8 success
41193276156	8/8 success

作业清单（两次相同）：windows-2022-conpty、windows-2025-actions-repeat、windows-2025-resize-reply、windows-2025-node-contract-timing、windows-2025-startup-latency、windows-2025-startup-under-load、windows-2025-original-probe-repeat、windows-2025-probe-after-conpty-tests。

意义与限度

意义：

windows-2022-conpty 从长期红转为连续两次绿（决策 2A 的端到端结果）；
windows-2025-actions-repeat 是本项目里最容易复现洪流/ETX 一类问题的作业，连续两次通过说明那一类时序问题在这两个样本上没有出现。

限度（必须写清）：

两次通过不能回填 [R1回归] 持续 cmd 输出时 ETX 未中断导致 normal/resize 超时 #36/[R2][调查] 核对 resize 期间 ConPTY 重绘与终端视口/缓冲的对齐 #194 等既有失败的根因；那些 issue 的验收都要求修前/修后或因果证据；
也不能据此宣布稳定性达标：历史样本里同一作业曾多次失败，只有更长序列才有统计意义。

下一步

继续累积运行序列，并把每次命中的新字段读数回填到对应 issue；windows-2022-conpty 的绿不再作为"修好了平台"的证据，只作为"判定口径正确"的证据。

采样序列更新（6 轮）

#	run	结果	备注
1	41193269350	8/8 绿	`windows-2022-conpty` 首次转绿
2	41193276156	8/8 绿	—
3	41194076573	绿	—
4	41194082923	红	`ui-copy-system` 选择场景超时
5	41194868634	绿	—
6	41194874622	绿	—

5 绿 / 1 红，红的那次是同一个形态（输入无拒绝、output_bytes == consumed、子进程存活）。

新合入的诊断

PR	观测	用途
#284	Workspace 失败打印场景自己的 `stage`	下次同形态失败可判断卡在哪个阶段（此前 `stage=0` 是 ShellWindow 的，不适用）
#283	超时记录 `frame_at_timeout`	区分收尾未完成与帧已出但进程未返回
#282	标题事件 invalid text 的 kind/bytes/hex	#57
#280	记录制在探针侧生效	2022 基线

限度

6 轮样本量不足以谈稳定性；
5 次通过不能回填历史失败根因，各 issue 仍按各自验收文字保持开放。

采样序列更新（9 轮）

#	run	结果	备注
1-3	41193269350 / 41193276156 / 41194076573	绿	其中两轮 8/8
4	41194082923	红	`ui-copy-system` 选择超时
5-6	41194868634 / 41194874622	绿	—
7-9	41195731956 / 41195738748 / 41195745397	绿	三轮均含 `actions-repeat`

8 绿 / 1 红。第 7-9 轮是合入 #284（场景 stage）之后派发的，因此它们的 actions-repeat 通过说明：这三轮里没有触发那个形态。

需要说明的限度

8 次通过不等于该形态已消失：第 4 轮就是第 3 轮绿之后紧跟着红，说明它是概率性时序问题；
各 issue 的验收仍要求反例与因果证据，这些通过样本只能作为"该批未复现"的实际结果记录；
统计上 1/9 的失败率不足以支撑任何稳定性结论。

下一步

继续派发，直到抓到带 stage= 的失败样本（#284 之后才有此字段），那将是首次给出卡点位置。

在 main `dc9138d` 上的本机全量回归（补齐缺失构建目标后）

这轮把近期合并的诊断改动（#274–#290）在本地完整回归了一遍。

组	结果	备注
`core`/`reply`/`edit_csi`/`selection*`/`transport`/`view_mapping`/`presentation`	18/18 通过（18.56 s）	首次跑时 `view_mapping_core` 为 Not Run，因 `view_mapping_test` 未构建；构建后通过
`shell`/`text_actions`/`selection_context`/`selection_bytes`/`keyboard`/`decawm`/`alternate`/`order_query`	10/10 通过（99.09 s）	首次 `shell` 失败是缺 `shell_queue_probe.exe`，构建后通过
`shell_launch`	1/1 通过	首次为 Not Run（缺 `shell_launch_test.exe`），构建后通过

说明

三次 "Not Run"/"Failed" 全部是本机未构建对应目标，不是代码回归；
这组结果确认：今天合入的诊断与修复（stage、自动判读、丢弃文本、WSL 窗口重开、lifecycle 字段、定向采样开关）没有破坏既有契约。

边界

这是本机环境（96 DPI、system ConPTY）的结果；
不覆盖 hosted 专属用例（真实剪贴板、受控 DPI、IME 交叉）；
不能替代 CI 的 windows-2025/ubuntu 回归结论。

三类持续未复现的量化批次（同一 artifact 集的结论）

把他们放在一起，是因为这三项都属于"历史上偶发、当前批次未复现"：

issue	批次	关键计数	结论
#160 desktop 沉降	425 个 sample.json	全部 `[{elapsed_ms:0, gone:true}]`；缺失 5 条均为刻意构造的 `desktop-failure` 负例	关闭后首次检查即消失，无退避
#145 resize 旧尺寸回复	10 个配置 / 1500 轮	`stale_buffer=0`、`stale_window=0`、`buffer_window_disagreement=0`	无陈旧回复样本
#144 Node 10 秒停顿	60 顺序 + 20 并发	中位数 0.062 s，最大 1.969 s（冷启动首例），超时 0	宿主正常时远低于期限

共同点

三项在同一批 hosted 运行里都没有复现；
三项的验收都要求"同类反例 + 因果"，因此都不能据此关闭；
三份记录都写明了批次、来源 run 与限制，可供后来者核对强度。

由此得到的判断

这些问题的复现依赖宿主侧偶发状态（Node 启动被拖慢、桌面回收延迟等），而不是固定输入可触发的确定性缺陷。因此：

手段	边际收益
继续增加绿色批次	低——已经 1500 轮/425 样本无复现
增加诊断字段	已基本饱和（场景、阶段、计数器、窗口、收尾、沉降、丢弃文本齐备）
等一次真实命中	唯一能推进的路径，但不可控

边界

三个批次来自不同 run/artifact，不拼成"一次全绿"；
每项的原始失败记录仍然保留，未被新批次覆盖。

main `95855f4` 上的 Qt 入口冒烟：通过

这一轮把近期全部合并（诊断、WSL 窗口修复、文档）之后的 Qt 产品入口又验了一遍：

项	结果
`qt_cpp_shell_smoke` 构建	成功
冒烟运行（offscreen）	`status=passed`、`timed_out=false`、`exit_code=0`
自有 Job 回收	`job_after.active=0`（total=26）

同时核对了 ADR-0007 的「已知差异」

确认其中确实记录了原生 CHAR_INFO 的可见性差异与边界，且写明"不阻塞 VT/transport/末端层验收，原生层证据缺口单独保留"——与 #41 的裁决一致，也与 #293 的证据记录口径一致。

局限

offscreen 平台，不覆盖真实呈现；
单会话基础场景，不代表完整工作流；
不能替代 CI 的 qt-cpp-windows 作业结论。

Merge pull request #296 from JavaZeroo/docs/reliability-batches

当前阻塞结构（按"还差什么"划分）

R2 剩余 23 个开放项（另 48 项已关闭）。本轮把它们按"推进条件"归一次类：

A. 需要用户决策（3 项）

issue	待决内容	状态
#194	几何变化后选区丢弃的修法方向	证据已齐（40 条丢弃记录 0 条部分重绘），但缺 `ui-actions` 几何阶段样本；方向需用户确认
#34	固定后端让显示优于原版，是否登记为"经确认的原版缺陷修正"	已给出两立场与建议
#31	R2 单屏范围是否最终确认	文档已按决策 4C 更新，需用户确认收口方式

B. 需要一次不可控的真实命中（8 项）

issue	等什么	已就位观测
#36	洪流 ETX 复发样本	`output_bytes` vs `bytes`
#40	PowerShell 夹具超时	`report/emitted` 检查点
#57	candidate invalid text	标题事件 kind/bytes/hex
#73	Workspace 场景失败	场景名 + 每标签页计数器 + `stage`
#80	原 hosted stage-6 事件	stage 5 支线已修并验证；原事件未复现
#97	candidate-scroll 超时	`frame_at_timeout` + lifecycle 字段
#144	Node 停顿（C/D 型）	`js_start_after_create_ms`
#145	resize 旧尺寸回复	探针计数（1500 轮全 0）

C. 需要真实硬件/OS 环境（2 项）

issue	需要什么
#31（跨屏部分）	真实异 DPI 显示器；已按 4C 移出 R2
#155	隔离 Windows 11 + 固定 Microsoft 拼音的真实 IME 链路

D. 能力与验收类（其余）

#27 / #28 / #29 / #30 / #44 / #47 / #52 / #160 / #38 / #35 —— 以各自 issue 的最近评论为准。

本目标期间的可核验产出

类别	内容
关闭	#21（2022 基线，记录制端到端生效）、#54（回归型性能预算）
行为修复	#290 / #280（WSL 观察窗口、记录制在探针侧生效）
诊断	stage、自动判读、丢弃文本、transport 窗口、`frame_at_timeout`、lifecycle 字段、`js_start_after_create_ms`
证据	`2026-10-31-wsl-size-window`、`2026-10-31-reliability-batches`、ADR-0009 实施状态
稳定性	全量 8/8 绿；2022 作业连续 11 次成功

说明

A、B、C 三类的推进条件都不在本地可完成范围内；继续增加本地改动的边际价值已接近零。

按「不死磕」原则复核：哪些开放项可以收口

用户已明确可以接受不完美、不需要一直死磕一个问题。我按同一原则把剩余 21 项过了一遍，分成三张清单。

清单 A：不可复现类（8 项）

issue	现有批次	收口代价
#145 resize 旧尺寸	1500 轮，三项异常计数全 0	无，批次已量化
#144 Node 10 秒	80 次运行最大 1.969 s，超时 0	无
#160 desktop 沉降	425 样本全 0 ms 消失	无
#40 PS 夹具	有 report/emitted 诊断，未命中	无
#36 洪流 ETX	已定位到写入成功后子进程停止产出，未复现	无
#57 invalid text	诊断已加，未命中	无
#97 candidate-scroll	诊断已加，未命中	无
#73	诊断已加（场景名/stage/计数器），未复现	无
#80	stage 5 支线已修复并做修前修后对照；原 stage-6 事件未复现	需接受原始事件留白

清单 B：需要你确认范围或接受差异（3 项）

issue	待定的点
#34	剩「产品 ADR 引用实际工作流与测量」与「核心复用/替换方案」；性能部分仍缺受控基线
#47	正式路线已在产品入口落地，但本项要求切换产品默认后重建复验；是否按已整合收口
#52	Console-width Vim stage59 失败发生在实验后端；是否按实验后端不属 R2 产品路径收口

清单 C：仍需真实环境或实现（6 项）

issue	需要什么
#155	真实 OS IME 链路（隔离 Win11 + 固定拼音）
#30 / #29 / #28 / #27	终端语义与 TUI 验收，需实现加原版对照
#35	R2 交付验收，依赖上述各项

建议

若希望尽快收口 R2，最省成本的是把清单 A 的 8 至 9 项按「批次未复现加诊断就位」关闭，并在每项评论写明重开条件。R2 开放数可从 21 降到 12 或 13，且不损失已记录的证据。

清单 B 的 3 项需要单独确认（都涉及范围判断）；清单 C 本地无法推进。

合并后内容审计：16 项抽查，全部确认在 main

起因：上一轮发现 docs/FEATURES.md 的 DPI 行其实没进 main（提交落错分支），说明"报告里说合并了"不等于"main 上真的有"。因此对本次会话的主要改动做了一次内容审计——直接读 origin/main 的文件内容匹配关键字符串，而不是看 PR 状态。

改动	关键字符串	main 上命中
#274 CreateProcess→JS 间隔	`js_start_after_create_ms`	1
#275 Workspace 失败行	`workspace-failure mode=`	1
#276 每标签页计数器	`diagnostic_line`	1
#277 transport 窗口原文	`window_hex`	4
#278 报告已送出检查点	`emitted`	1
#279 沉降记录	`desktop_close_settle`	2
#280 记录制在探针生效	`TERMFORGE_CONPTY_RECORD_HANDLES`	1
#282 标题事件字节	`invalid text in title event`	1
#283 帧是否存在	`frame_at_timeout`	1
#284 场景阶段	`self->stage_`	1
#285 收尾字段	`closer_joined`	6
#286 失败转储解析器	`def describe(`	1
#288 丢弃记录文本	`saved_text`	2
#289 定向采样输入	`inputs.only`	8
#290 WSL 窗口避让	`shell_size_client`	1
#298 原版缺陷修正决策	`决策 6`	1

注：#278 与 #284 首次用"report/emitted"和带引号的片段匹配时命中为 0，改用实际存在的字符串（emitted、self->stage_）后命中为 1——是检索式写错，不是内容缺失。

唯一确认的遗漏

docs/FEATURES.md 的 DPI 范围行（PR #299 正在修）——它的提交在 round 69 落到了另一条分支，PR #291 只带走了 SGR 那条。

结论

除该处外，本次会话声称合并的改动都实际存在于 main。

边界

抽查以关键字符串为准，不能证明行为正确，只证明代码/文档进了主线；
未逐一核对全部 30+ 次合并，只覆盖本次会话的主要改动。

按用户决定：清单 A、B 关闭，R2 开放数 21 → 11

用户 2026-11-01 决定：清单 A 同意；47A、52A、34B；29/30 保留。

本轮关闭（11 项）

issue	关闭依据
#145	1500 轮 resize，`stale_buffer`/`stale_window`/`disagreement` 全 0
#144	80 次 Node 运行最大 1.969 s（冷启动首例），超时 0
#160	425 个沉降样本全部 0 ms 消失
#36	已对账：Ctrl-C 写入成功、31 ms 后输出停止、心跳冻结 23.09 s
#73	三种模式样本形状一致；80 条丢弃记录 0 条为部分重绘
#40	`report/emitted` 检查点已加，未命中
#57	标题事件异常带 kind/bytes/hex，未命中
#97	`frame_at_timeout` 与收尾字段已加，未命中
#47	路线已在产品入口整合；重建复验交 #35（47A）
#52	失败发生在实验后端，不属 R2 产品路径（52A）
#34	架构收敛说明已写，未收敛部分明确交 #28/#29/#30/#35/#297（34B）

每项评论都写明了不是根因修复、保留了原始失败记录，并给出重开条件。

计数变化

时点	开放	关闭
本目标开始时	27	59
本轮之前	21	50
本轮之后	11	60

仍开放的 11 项

类别	issue
真未完成的实现/验收	#29（resize/逻辑行）、#30（Unicode/IME）、#28（VT/回复/TUI）、#27（备用屏/滚动区域）、#155（Qt IME）
交付与总项	#35、#38、#7
已移出 R2	#297 属 R4，不计入 R2

边界

关闭表示接受"批次未复现"或"范围裁剪"，不代表能力已验收；
[R2-06][终端] 定义并验证 resize、逻辑行与历史语义 #29/[R2-07][文字] 验收复杂 Unicode、IME 与键盘/选择语义 #30 按用户要求保留，它们是真未完成的实现；
原始失败记录、诊断与证据目录均未被删除。

Node 栅格夹具冷启动类目复发记录（2b8105e，不重开 #144）

main 2b8105e（PR #306 合入后）Windows regression 出现一次 windterm_raster_style_reference（research/ui/test_raster_style_reference.py test_production_js_native_contract）失败：

签名：node fixture exceeded its ten second limit; preload checkpoint never written; spawn_seconds=0.047 exit_at_timeout=None partial_stdout_bytes=0。
判定：Node 进程已创建（0.047s）但 10s 内未写 preload checkpoint、零 stdout——冷启动/资源停滞，与 [R2][回归] 定位 Node 栅格纯夹具在 Windows CI 的原 10 秒超时 #144 同一类目（该测试注释亦自述此区分来自 [R2][回归] 定位 Node 栅格纯夹具在 Windows CI 的原 10 秒超时 #144）。
处置：重跑同 run（41339405472）全绿（windows+ubuntu）。按规则重跑绿不回填本次原因。
关系：[R2][回归] 定位 Node 栅格纯夹具在 Windows CI 的原 10 秒超时 #144 已按 2026-11-01 用户决定关闭（80 轮最大 1.969s 证据），本记录仅作该类目在 main 的复发存档；[R2][回归] 定位 Node 栅格纯夹具在 Windows CI 的原 10 秒超时 #144 不重开。若该类目复发频率上升，再提交用户确认是否升格为新可靠性项。
与 docs(research): freeze More.com trajectory and protocol expectations (#28) #306 的关系：docs(research): freeze More.com trajectory and protocol expectations (#28) #306 只改 docs/fixture/test_recovery.py/EVIDENCE，与本测试无关联，判定无关。

原始失败 job 124946024399，重跑 job 同 run 新 job。

[R2][回归] 收敛 Windows 可靠性与历史未闭合失败 #38

Description

当前可靠性收口（2026-11-01）

已关闭项的处理依据

后续规则

Activity

JavaZeroo commented on Oct 25, 2026

JavaZeroo commented on Oct 25, 2026

JavaZeroo commented on Oct 25, 2026

JavaZeroo commented on Oct 25, 2026

JavaZeroo commented on Oct 25, 2026

JavaZeroo commented on Oct 25, 2026

JavaZeroo commented on Oct 25, 2026

JavaZeroo commented on Oct 25, 2026

62 remaining items

JavaZeroo commented on Oct 31, 2026

并行度普查：ime_context 与 conpty 是负载敏感项

方法

结果

判读

建议

一条方法学提醒

JavaZeroo commented on Oct 31, 2026

诊断改动已全部落地（等待下一次命中）

本轮动作

边界

JavaZeroo commented on Oct 31, 2026

R2 剩余开放项的当前状态（按处置方式分组）

A. 等一次 CI 命中（诊断已就位，命中即可判读）

B. 需要你决策

C. 交付与汇总

D. 需要真实环境

E. 其他

本轮新增的事实

边界

JavaZeroo commented on Oct 31, 2026

两次完整作业全绿（含 2022 与 actions-repeat）

意义与限度

下一步

JavaZeroo commented on Oct 31, 2026

采样序列更新（6 轮）

新合入的诊断

限度

JavaZeroo commented on Oct 31, 2026

采样序列更新（9 轮）

需要说明的限度

下一步

JavaZeroo commented on Oct 31, 2026

在 main dc9138d 上的本机全量回归（补齐缺失构建目标后）

说明

边界

JavaZeroo commented on Oct 31, 2026

三类持续未复现的量化批次（同一 artifact 集的结论）

共同点

由此得到的判断

边界

JavaZeroo commented on Oct 31, 2026

main 95855f4 上的 Qt 入口冒烟：通过

同时核对了 ADR-0007 的「已知差异」

局限

JavaZeroo commented on Oct 31, 2026

当前阻塞结构（按"还差什么"划分）

A. 需要用户决策（3 项）

B. 需要一次不可控的真实命中（8 项）

C. 需要真实硬件/OS 环境（2 项）

D. 能力与验收类（其余）

本目标期间的可核验产出

说明

JavaZeroo commented on Nov 1, 2026

按「不死磕」原则复核：哪些开放项可以收口

清单 A：不可复现类（8 项）

清单 B：需要你确认范围或接受差异（3 项）

清单 C：仍需真实环境或实现（6 项）

建议

JavaZeroo commented on Nov 1, 2026

合并后内容审计：16 项抽查，全部确认在 main

唯一确认的遗漏

结论

边界

JavaZeroo commented on Nov 1, 2026

并行度普查：`ime_context` 与 `conpty` 是负载敏感项

在 main `dc9138d` 上的本机全量回归（补齐缺失构建目标后）

main `95855f4` 上的 Qt 入口冒烟：通过