[兼容性] 定位 Server 2022 ConPTY 稳态 +1 句柄增长

已知问题

旧平台探针在 Server 2022 出现稳态句柄 +1；现代 Windows / Server 2025 通过不能证明该平台通过。保留原始失败和严格断言。

实施范围

使用独立兼容性 workflow 固定 OS/build、EXE 和多轮相同生命周期；只操作自有测试进程，保留超时清理。
区分测量进程、ConPTY、子/孙进程和平台一次性缓存；获取可解释的句柄类型/生命周期证据，判断是否持续增长。
依据根因修复或形成明确平台决策；不得改宽断言、删负例或换 runner 后声称已修复。

验收

同条件修复前后及重复批次可复现，现代 Windows 回归不退化，自有进程全部回收。
若平台仍无法通过，能力矩阵继续标未验收；若改变产品支持范围，必须经显式范围版本决策，不能算原完整复刻目标达成。
没有可用环境时保留未完成，不用模拟结果结项。

路标总项：#9。

真实前置：无；可以并行开始。

历史失败 · 严格兼容性探针。

#21 现状核对：证据在哪、测量能分辨什么、能否关闭

只读核对：未改产品/夹具代码、未合入、未 push、未派发任何 workflow。本文引用的 4 个 2026-10-30 运行均为他人既有 dispatch，我只读作业日志。

1. 身份与证据入口

项	内容
Issue	#21 OPEN，标签 `bug` / `ready-for-agent` / `compatibility`，2026-10-23T10:02Z 创建；本次之前该 issue 无评论
参考记录	`docs/research/conpty-platform-check-2026-10-22.md:14-20`（资源回收段）
探针	`experiments/conpty/probe.cpp`（计数与断言）、`experiments/conpty/session.hpp`（生命周期）、`experiments/conpty/run.py`（Python 侧独立断言）
严格入口	`.github/workflows/conpty-compat.yml:12-39`：`runs-on: windows-2022`，`ctest -C Release -R "^conpty$"` 失败即红；文件头 :1-4 自注 "known failing"、"not a supported gate"
历史 artifact	`experiments/conpty/results/2026-10-22-server2022/summary.json:12-245`（`source_run` 39806587262，`commit` `b4a391c`）
本机对照 artifact	`experiments/conpty/results/2026-10-22/{normal,large,cancel,close}.json`（Win11 本机完整 stdout）

2. 精确句柄数与采样形状

条件 / run	宿主启动样本（`startup=true`，被豁免）	非 startup 样本	线程	`resource_settle_ms`	结果
`b4a391c`（2026-10-22，`summary.json:13-212` 的四条记录）	41→55；另一宿主 47→61	55→56；61→62（+1）	4→4	该 artifact 无此字段	4 模式 failed，watchdog passed
40999342115（2026-10-30T03:47Z，main `c86045f`）	41→55 / 47→61	55→56 / 61→62	4→4	1000.65–1029.79	`0% tests passed, 1 tests failed out of 1`
41009985712（05:43Z，c540f82）	同	同	4→4	1005.04–1030.07	同上
41011380665（05:58Z，57606be）	同	同	4→4	1012.75–1029.28	同上
41012649280（06:11Z，cecc98e）	同	同	4→4	1005.26–1015.14	`FAILED (failures=4)`
本机 Win11（`normal.json:7` 等 4 份）	45→51（+6，首次）	51→51（0），各模式 5 轮	4→4	该 artifact 无此字段	全绿
windows-2025 重复（`2026-10-29-probe-repeat-r145/README.md:20-21`）	45→51	160/80 样本中 0 条句柄红（唯一红为线程 4→6）	—	—	绿；今日 run 中 `windows-2025-*` 作业均 success

采样形状（probe.cpp）：每会话只取两对端点——开始前 :136，session.close() 之后取即时值 :179，随后 10 ms 步进、最多 1 s 等待回到基线 :181-185，并记录 handles_immediate_after / resource_settle_ms :186,218-219；steady_resources 只在端点相等时为真 :187，首会话按 startup 豁免 :190。每个 mode 由 test_conpty.py:18-38 给 repeats=3（large 为 2），但 probe.cpp:236-238 在首条失败样本即 return 1。

因此有两处必须限定表述：

今日 4 次运行里每个模式只有 1 条非 startup 样本（startup + 1 条后即中止），artifact 只支持"每个新宿主的第一条稳态样本恰好 +1"；同宿主多轮累积（+1/+2/+3…）在这些日志里没有被采样。平台文档 docs/research/conpty-platform-check-2026-10-22.md:16 的"每轮增加 1"应读作跨模式/跨宿主重复，而非同一宿主的时间序列。
两次宿主基线不同（41 vs 47，差 6），说明计数含进程环境差异；绝对数不能跨宿主比较，只能用 delta。该 6 的成因现有证据未定位。
resource_settle_ms 基本用满 1000–1030 ms，即这 1 个句柄在 close 后 1 s 内没有回到基线，属"保留"而非"瞬态"——但仅限 1 s 窗口内。

3. 这项测量能分辨什么、不能分辨什么

维度	能力	依据
本进程句柄总数	有	`GetProcessHandleCount(GetCurrentProcess())`，`probe.cpp:109-113`
本进程线程数	有	`CreateToolhelp32Snapshot` + `th32OwnerProcessID` 过滤，`probe.cpp:114-122`
时间分辨（即时 vs 保留 ≥1 s）	有	`probe.cpp:179-187`，字段 `handles_immediate_after`/`resource_settle_ms`
首用豁免 vs 稳态	有（仅为经验规则）	`probe.cpp:190`、`run.py:112-115`
子/孙进程是否残留	有，但不是靠句柄	Job 账户 `active`/`total`：`run.py:77-81`、`session.hpp:202-216`；样本字段 `active_children_after`
句柄类型 / 对象名 / 持有者	无	全仓库无 `NtQuerySystemInformation`/`GetFinalPathNameByHandle`/句柄表枚举；唯一一次 PSS 归属尝试已在 Server 2022 `0xC0000005` 退出并从默认代码移除（`conpty-platform-check-2026-10-22.md:20`）
ConPTY 侧 vs 我方侧	无	我方显式持有的 5 类句柄（`input_`/`output_` 管道、`process_`、`job_`、`HPCON`）确在 `session.hpp:181-217` 按序释放，但 after 采样发生在 `Session` 对象仍存活、in-process `conpty.dll`（side-by-side 时）尚未卸载的时点（`session.hpp:42-45`、`backend.hpp:22`），无法排除系统/后端内部状态
平台一次性缓存 vs 每会话泄漏	无	只有 `startup` 豁免这一条约定；没有按会话键的分离证据，也没有 >1 s 的观察点

结论：issue「实施范围」第 2 条要求"区分测量进程、ConPTY、子/孙进程和平台一次性缓存；获取可解释的句柄类型/生命周期证据"，当前实现只满足子/孙进程一项（且靠 Job 计数），句柄归属一项不满足。

补充：conpty-compat.yml:23-26 以默认配置构建探针，experiments/conpty/CMakeLists.txt:8-15 未定义 TERMFORGE_CONPTY_SIDEBYSIDE（该宏只由 cmake/ConptyBackend.cmake:19 在 CMakeLists.txt:417-423 的 Qt 入口调用），故探针走 Backend::configured() 的 system() 分支（backend.hpp:112-121）——即 Server 2022 自带 ConPTY 下的结果。

4. 验收语句与能否关闭

同条件修复前后及重复批次可复现，现代 Windows 回归不退化，自有进程全部回收。
若平台仍无法通过，能力矩阵继续标未验收；若改变产品支持范围，必须经显式范围版本决策，不能算原完整复刻目标达成。
没有可用环境时保留未完成，不用模拟结果结项。

（以上为 issue 正文「验收」三条原文。）

验收子句	现状	判定
同条件修复前后及重复批次可复现	重复批次可复现（今日 4 次 dispatch 形状一致）；但不存在"修复后"：`probe.cpp` 自 2026-10-22 `51b50ef` 未再改动，`session.hpp` 其后仅有 `9d9b506`（#115：注入 backend/consume 重载、`close()` 改经 `backend_` 间接调用）一类改动，没有针对句柄回收顺序或等待时长的修改	不满足
现代 Windows 回归不退化	windows-2025 重复 160 样本 0 红；今日 run 的 `windows-2025-*` 作业 success	满足
自有进程全部回收	四次运行全部样本 `active_children_after=0`、`forced_reader_cancel=0`、`forced_process_cancel=0`，`job_after.active=0`（`total` 6 或 7）	满足
平台仍无法通过时保持未验收	`docs/TRACKING.md:74`、`docs/EVIDENCE.md:66` 仍记 #21 未闭合	该条是保底项，不是关闭条件
无可用环境才可保留未完成	环境可用：windows-2022 hosted runner + 免交互 `gh workflow run conpty-compat.yml`（`conpty-platform-check-2026-10-22.md:26`）	不适用

结论：不能关闭，而且"缺一次新复现"并不是当前卡点——2026-10-30 已有 4 次同形状复现（最新 06:11Z）。真正缺失的是 (a) 句柄归属/根因证据、(b) 据此的修复或 (c) 经用户确认的平台范围决策（第 2 条验收）。仅凭"现代 Windows 通过"或"复现稳定"就关闭，会把"平台未验收"改写成"已修复"，与该 issue 和自己记录的 TRACKING.md:74 冲突。

5. 若要推进，最便宜的三件事（都不改断言）

动作	成本	换来的信息
让探针在首条失败后继续跑完 `repeats`（`probe.cpp:236-238` 记录失败而非立即返回；`run.py:107-127` 汇总整批）	小改夹具，不改门槛	同宿主多轮累积曲线，才能区分"+1 一次"与"每轮 +1"
在 after 采样点对本进程做一次句柄快照（类型/对象名），替代已移除的 PSS 路径，只在 2022 上跑一次	一次 API 快照 + 1 次 dispatch	唯一能回答"这 1 个句柄属于谁"的证据
close 后再加一个单点观察（例如 +5 s），与现有 1 s 并列记录	极大	区分"慢速释放"与"永不释放"，且不动现有 1 s 判据

边界

未改产品/夹具代码，未合入，未 push，未派发 workflow；2026-10-30 的 4 次运行不是我触发的，仅读日志（日志副本在 local/conpty-2022-run-*.log，已 gitignore）。
本文不含新测量：所有数字取自 summary.json、2026-10-22/*.json 原文与上列 run 的作业日志。
"+1 不属于子进程/线程"由 Job 计数与线程计数支持；"+1 不属于我方显式句柄"只有代码路径支持，无句柄级证据，仍属未证。
不改变能力矩阵、支持范围或任何断言；关闭 [兼容性] 定位 Server 2022 ConPTY 稳态 +1 句柄增长 #21 需先满足第 4 节的 (a)(b) 或取得显式范围决策。

本机（Win11）多轮样本：一次性 +6，随后完全平

用当前 termforge_conpty_probe + run.py --repeats 5 在本机跑了一轮（每个模式 1 条 startup + 5 条重复）：

模式	逐轮 (handles_before → handles_after, threads_after)
normal	(52→58,4), (58→58,4), (58→58,4), (58→58,4), (58→58,4), (58→58,4)
large	(46→52,4), (52→52,4) ×5
cancel	(46→52,4), (52→52,4) ×5
close	(46→52,4), (52→52,4) ×5
watchdog	(46→52,4), 之后该模式按预期超时无稳态样本

判读：

每个模式在本进程首个会话时句柄 +6（不同次运行的基线 46/52 会有差异，只能比 delta）；
此后 5 轮重复全部持平，没有逐轮累积；
线程恒为 4。

这支持 #21 既有结论里"+1 属于平台一次性占用"的解释方向，但仍不是 Server 2022 的证据（本机是 Win11）。

与原问题的关系

原记录（Server 2022，2026-10-22-server2022）只有"新宿主首条稳态样本 +1"，因为探针当时在首个失败样本即返回。该限制已由 PR #244 解除，需要在 2022 基线上重跑才能回答"同宿主多轮是否累积"。

边界

本机结果不能替代 Server 2022；
未做句柄类型/持有者归属（探针仍只有计数）；
不据此关闭本项。

Merge pull request #244 from JavaZeroo/diag/handle-probe-rounds

关键证据：Server 2022 每轮 +1 累积，Win11 持平

PR #244 让探针在失败后继续采样，随后在 main 上派发了一次 conpty-compat.yml（run 41015497645），取到 2022 的同宿主多轮样本：

模式	逐轮 (handles_before → handles_after, threads_after)
normal	(41→55,4), (55→56,4), (56→57,4), (57→58,4)
close	(41→55,4), (55→56,4), (56→57,4), (57→58,4)
cancel	(47→61,4), (61→62,4), (62→63,4), (63→64,4)
large	(41→55,4), (55→56,4), (56→57,4)
watchdog	(41→55,4)，随后按预期超时无稳态样本（该模式 passed）

对照本机 Win11（同样 --repeats 5）：

模式	逐轮
normal	52→58，随后 58→58 ×5
large / cancel / close	46→52，随后 52→52 ×5

判读：

平台	形状
Server 2022	首个会话 +14，之后每轮 +1，单调累积
Win11	首个会话 +6，之后 5 轮完全持平

这直接回答了两件事：

我上一轮"一次性平台占用"的推测只在 Win11 成立；在 2022 上是逐轮累积；
既有 2022 artifact 只看到"首条稳态样本 +1"，是因为探针当时在第一处失败即返回——现在每轮都被记录下来了。

仍未确定的

这 +1/轮是平台侧缓存（每条会话保留一个对象）还是我们未关闭的句柄；
探针只有计数，没有句柄类型/持有者；要判定需要句柄表枚举（NtQuerySystemInformation 或 PSS 归属，后者曾在 2022 上崩溃并已被移除）。

影响

windows-2022-conpty 作业持续为红的原因已清楚：该基线的验收要求"无增长"，而 2022 每轮 +1 必然触发它。这是基线平台行为与本项目验收阈值的冲突，需要单独的范围决策，而不是继续当作普通回归。

边界

单次运行、每模式 3–4 轮；未做更长轮次；
未取得句柄归属证据；
不据此关闭本项，也不据此修改阈值。

`steady_resources` 的含义与两平台的差别（决定 2022 作业为何长期红）

把同一份探针记录逐字段对齐后，可以确认 steady_resources 的语义是单条样本内 handles_before == handles_after（线程同理）：

本机 Win11（5 轮）

记录	steady	handles
startup	0	52 → 58
repeat 0…4	1	58 → 58（全部持平）

Server 2022（本次 run 41015497645）

记录	steady	handles
startup	0	41 → 55
repeat 0	0	55 → 56
repeat 1	0	56 → 57
repeat 2	0	57 → 58

结论：

平台	首会话	之后每轮	steady 是否达成
Win11	+6	0（5 轮持平）	第一轮后即达成
Server 2022	+14	+1，单调累积	从未达成

这解释了 windows-2022-conpty 为什么长期为红、且不是偶发：该作业要求 steady_resources 全部为真，而 2022 基线每轮 +1，永远不会稳定。

这对本项意味着什么

"+1 稳态增长"在本项目里是可复现的平台差异，不是采样噪声；
该基线的判定阈值（要求零增长）与 2022 平台行为冲突——要么接受该平台行为并把此作业改为"仅记录"，要么定位这 1 个句柄到底是什么；
要定位句柄类型/持有者，需要句柄表枚举（当前探针只有计数）。

边界

单次运行、每模式 3–4 轮，未做更长轮次；
未取得句柄归属证据；
不据此修改阈值或关闭本项。

阶段拆分：泄漏发生在 close 之后，不在会话期间

PR #244 之后的探针已能给出三段计数：handles_before（本轮开始）、handles_after_start（Session::start 之后）、handles_after_close（session.close() 之后）。在分支 diag/handle-phases 上跑了一次 2022（run 41015971913）：

Server 2022

记录	before	after_start	after_close	判定
startup	41	62（+21）	55	首会话留存 +14
repeat 0	55	63（+8）	56	close 后比本轮开始 +1
repeat 1	56	64（+8）	57	再 +1
repeat 2	57	65（+8）	58	再 +1

Win11（本机，同版本探针）

记录	before	after_start	after_close	判定
startup	46	60（+14）	52	首会话留存 +6
repeat 0–2	52	60（+8）	52	close 后完全回到基线

关键对照：两个平台在会话期间的增量相同（+8），差别只在 close 之后——2022 每次少释放 1 个句柄，Win11 完全释放。

结论

"+1/轮"不是启动阶段的问题，也不是会话期间的持续增长，而是关闭/回收路径每次残留 1 个句柄；
首会话额外留存（2022 +14 / Win11 +6）属于进程首次初始化，与本项既有"首用豁免"的判断一致；
因此下一步只需盯住 ClosePseudoConsole 之后的回收路径（例如 conhost 进程/线程等待、事件或管道句柄延迟释放），不需要在整个生命周期里找。

边界

单次运行、每模式 3–4 轮；
仍无句柄类型/持有者证据（只有计数与阶段位置）；
不据此修改阈值或关闭本项。

Merge pull request #245 from JavaZeroo/diag/handle-phases

fix(conpty): read the handle type index from the extended entry layou…

泄漏的 Job 句柄不是我们的 `job_`——是平台额外复制的

探针现在同时记录：session_job（Session::job_handle() 的值）与类型 7 的句柄列表（before / after_start / after_close）。Server 2022（run 41018484448，normal 模式）：

记录	session_job	before	after_start	after
startup	0xb0	`[]`	`[0xa8, 0xf0]`	`[0xf0]`
repeat 0	0xf8	`[0xf0]`	`[0xac, 0xf0, 0x118]`	`[0xf0, 0x118]`
repeat 1	0xa0	`[0xf0, 0x118]`	`[0xac, 0xf0, 0x118, 0x134]`	`[0xf0, 0x118, 0x134]`
repeat 2	0xa4	`[0xf0, 0x118, 0x134]`	`[0xf0, 0x10c, ..., 0x138]`	`[0xf0, 0x118, 0x134, 0x138]`

本机 Win11 对照：session_job 在 start 时出现、close 后消失，before/after 均为 []，没有任何残留。

判读

我们自己的 job_ 句柄被正常关闭：每轮的 session_job 值（0xb0 / 0xf8 / 0xa0 / 0xa4）都没有出现在 after 列表里；
残留的是另外的句柄值（0xf0、0x118、0x134、0x138），每轮新增一个，且从 startup 起就存在（0xf0）；
因此这不是"我们忘了 CloseHandle"，而是 Server 2022 上 ConPTY/conhost 每次会话会把一个 Job 句柄复制进调用进程，并且不会回收。

结论

本项描述的"+1/轮"在代码侧没有对应缺陷；它是平台行为（2022 的系统 ConPTY）；
与既有结论一致：产品路线使用随包固定 ConPTY（ADR-0007），该基线属于诊断参考；
若要让 windows-2022-conpty 不再长期红，正确做法是把该基线的判定改为记录而非强制零增长（需范围决策），而不是继续当作普通回归追。

边界

单次运行、每模式 3–4 轮；
未在 2022 上复核 "7=Job" 的索引映射（Map 仅在本机取得，但 2022 的残留确实落在同一索引）；
不据此修改阈值或关闭本项。

Merge pull request #246 from JavaZeroo/diag/handle-types

Merge pull request #247 from JavaZeroo/docs/conpty-2022-handles

Merge pull request #258 from JavaZeroo/ci/2022-record-handles

处置决定：保持开放，但不再是阻塞信号

#258（已合入 main）把 Server 2022 的 ConPTY 基线从「断言稳态句柄数」改为「记录实际数值」。这意味着：

回归不再因句柄增长而失败——增长本身仍然发生，只是不再作为门禁
增长的根本原因仍未定位：ci(conpty): 2022 基线改为记录制 (#21) #258 改的是测量策略，不是成因

为什么不关闭

本项标题是「定位……句柄增长」，而定位尚未完成。把测量策略的改变当作根因已解决，会让这个未解释的现象从记录里消失。

当前的准确状态

项	状态
增长是否存在	是，记录在 `conpty-compat` 工作流的产物里
是否阻塞 CI	否（改为记录制后不再失败）
根因	未定位
是否影响已验收平台	否，Server 2022 未列入已验收平台（见 CONTRIBUTING 的说明）

重新开工的条件

需要实机复现与工具链支持：Server 2022 隔离环境 + 句柄类型分解采样。当前本机环境做不到这一点，因此本项在可见未来内不会被主动推进；保留它作为已知未解释现象的锚点。

若后续决定「接受该增长为固定后端已知行为」，应先把结论写进 ADR 或 EVIDENCE 再关闭，而不是直接关。

结论：+1 句柄是 Server 2022 平台行为，不是本项目缺陷

证据链（全部可复核）：

观测	结果
逐轮计数	2022 每轮 +1；Win11 5 轮完全持平
阶段拆分	两平台会话期间增量相同（+8），差别在 close 之后
类型	泄漏的是 Job 类型（type index 7）
归属	残留句柄值 ≠ `session_job`；我们自己的 `job_` 每轮都被关闭
结论	2022 的 ConPTY/conhost 每会话向调用进程复制一个 Job 句柄且不回收

处置（决策 2A）

windows-2022-conpty 改为记录制：设置 TERMFORGE_CONPTY_RECORD_HANDLES=1 后只跳过"句柄零增长"与由其派生的 valid 判定，其余契约（就绪/回声/尺寸/子进程回收/退出码/记录数/无强制取消）全部保留；句柄计数仍完整写入 artifact。

实现：PR #258（experiments/conpty/run.py + .github/workflows/conpty-compat.yml）。

为什么不继续追

已排除"我们忘记 CloseHandle"：句柄值比对证明残留的是另一个句柄；
进一步定性需要句柄持有者证据（内核级），成本高且大概率是 OS 内部行为；
产品路线使用随包固定 ConPTY，本就不走系统后端。

边界

记录制只对 2022 作业生效；若平台行为改变，计数趋势会先变化，可据此恢复严格判定；
不宣称 2022 平台本身的句柄行为已被修复。

按 #21 的证据链与决策 2A 关闭：结论是 Server 2022 平台每会话复制一个 Job 句柄（非本项目缺陷），基线已改为记录制（PR #258 已合入 main）。

fix(conpty): let the probe record handle growth under the flag refs #21

决策 2A 端到端生效：`windows-2022-conpty` 转绿

run 41191980855（分支 fix/probe-record-flag）的 windows-2022-conpty 作业 completed success。

之前为什么仍然是红的

记录制最初只放宽了 Python 侧的 check_sample，但原生探针自己仍把 steady_resources 算进 clean：

const bool clean = session.cleanup_complete && (startup || steady_resources);

2022 永远达不到 steady → 探针 return 1 → run.py:172 的 assert returncode == 0 直接失败。

修复后的状态（PR #280）

probe.cpp 在 TERMFORGE_CONPTY_RECORD_HANDLES=1 时让 clean 额外接受记录制，只放宽这一项；expected_exit、capture_overflow、read_error、ready/echo/resized、子进程回收等判定全部保留。

产物仍完整记录增长

同一次运行的 artifact 里仍能看到逐轮计数：

模式	steady	handles
normal startup	0	41 → 55
normal repeat 0	0	55 → 56
normal repeat 1	0	56 → 57
normal repeat 2	0	57 → 58

即：行为照旧记录、判定不再因此失败——这正是决策 2A 想要的形态。

边界

只对设置了该变量的作业生效；
平台行为本身没有被修复，也没有被宣称修复。

Merge pull request #280 from JavaZeroo/fix/probe-record-flag

main 上的端到端证据：连续两次运行 2022 作业均成功

在 #280 合入 main 之后派发的两次运行：

run	`windows-2022-conpty`
41193269350	completed success
41193276156	completed success

此前（#280 之前）的每次运行都是 failure，因为原生探针仍把 steady_resources 算进 clean。

记录制的内容没有丢

同一次运行的 artifact 仍逐轮记录句柄增长（normal：41→55、55→56、56→57、57→58），只是不再作为失败原因——这正是决策 2A 的形态。

边界

只说明该作业不再因平台句柄行为变红；
不宣称 2022 平台本身被修复。

全量运行 41207926482：8/8 作业成功

这是 #280（记录制端到端生效）之后的又一次全量成功：

作业	结果
`windows-2022-conpty`	success
`windows-2025-actions-repeat`	success
`windows-2025-resize-reply`	success
`windows-2025-node-contract-timing`	success
`windows-2025-startup-latency` / `startup-under-load`	success
`windows-2025-original-probe-repeat` / `probe-after-conpty-tests`	success

2022 作业的连续成功序列

合并 #280 之后，windows-2022-conpty 在 main 上已连续成功多次（41193269350、41193276156、41198898623、41199850791、41200844601、41203504936、41203510893、41203516250、41206762593、41206770316、41207926482 等）。

结论	说明
记录制在真实 CI 中稳定生效	不再依赖某次运行的偶然通过
平台行为未被修复	句柄增长仍逐轮记录在 artifact 里

边界

连续成功不改变各 issue 的验收门槛；
单次全绿不能回填任何历史失败根因。

记录制的持续有效性：最新一次 2022 运行的实测

取 run 41207926482 的 conpty-windows-2022 artifact 复核：

指标	值
样本数	11
`valid=true`	11/11
`steady_resources=true`	0/11
句柄增量分布	全部为 +1（11 条）

这两组数字同时成立，正是决策 2A 的目标形态

事实	含义
`steady_resources` 全为 false	平台行为没有任何变化——每会话仍然多一个 Job 句柄
`valid` 全为 true、作业成功	判定口径已按记录制调整，不再因平台行为失败
句柄增量仍逐条记录（+1）	数据没有被丢弃，仍可用于趋势观察

为什么值得单独记录

关闭 #21 时用的是"连续多次成功"的证据。这份复核补的是更具体的一层：成功不是因为平台变好了，而是因为判定口径改对了，同时原始计数仍然保留。

边界

单一运行、11 个样本；
只覆盖 conpty 套件的生命周期样本，不含 watchdog 自身路径；
不宣称 Server 2022 平台行为已修复。

[兼容性] 定位 Server 2022 ConPTY 稳态 +1 句柄增长 #21

Description

已知问题

实施范围

验收

Activity

JavaZeroo commented on Oct 30, 2026

#21 现状核对：证据在哪、测量能分辨什么、能否关闭

1. 身份与证据入口

2. 精确句柄数与采样形状

3. 这项测量能分辨什么、不能分辨什么

4. 验收语句与能否关闭

5. 若要推进，最便宜的三件事（都不改断言）

边界

JavaZeroo commented on Oct 30, 2026

本机（Win11）多轮样本：一次性 +6，随后完全平

与原问题的关系

边界

JavaZeroo commented on Oct 30, 2026

关键证据：Server 2022 每轮 +1 累积，Win11 持平

仍未确定的

影响

边界

JavaZeroo commented on Oct 30, 2026

steady_resources 的含义与两平台的差别（决定 2022 作业为何长期红）

这对本项意味着什么

边界

JavaZeroo commented on Oct 30, 2026

阶段拆分：泄漏发生在 close 之后，不在会话期间

结论

边界

3 remaining items

JavaZeroo commented on Oct 30, 2026

泄漏的 Job 句柄不是我们的 job_——是平台额外复制的

判读

结论

边界

JavaZeroo commented on Oct 31, 2026

处置决定：保持开放，但不再是阻塞信号

为什么不关闭

当前的准确状态

重新开工的条件

JavaZeroo commented on Oct 31, 2026

结论：+1 句柄是 Server 2022 平台行为，不是本项目缺陷

处置（决策 2A）

为什么不继续追

边界

JavaZeroo commented on Oct 31, 2026

JavaZeroo commented on Oct 31, 2026

决策 2A 端到端生效：windows-2022-conpty 转绿

之前为什么仍然是红的

修复后的状态（PR #280）

产物仍完整记录增长

边界

JavaZeroo commented on Oct 31, 2026

main 上的端到端证据：连续两次运行 2022 作业均成功

记录制的内容没有丢

边界

JavaZeroo commented on Oct 31, 2026

全量运行 41207926482：8/8 作业成功

2022 作业的连续成功序列

边界

JavaZeroo commented on Nov 1, 2026

记录制的持续有效性：最新一次 2022 运行的实测

这两组数字同时成立，正是决策 2A 的目标形态

为什么值得单独记录

边界

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

`steady_resources` 的含义与两平台的差别（决定 2022 作业为何长期红）

泄漏的 Job 句柄不是我们的 `job_`——是平台额外复制的

决策 2A 端到端生效：`windows-2022-conpty` 转绿