TC-NET-604结案为非缺陷：Trap21改短+删机理图解+N-7作废，清理源码误导注释

docs/问题记录/CH395F_Trap_Records.md

@@ -537,81 +537,28 @@ NET 层 TCP Client（阶段 7）`net_connect()` 返回 0，但 `net_poll()` 报
 ### 发现时间
 阶段 8 大文件传输实现，2026-08-26。
 
-## Trap 21：接收缓冲"恰好填满 + 排空"窗口冻结（TC-NET-604）
+## Trap 21：接收缓冲"恰好填满 + 排空"窗口冻结（TC-NET-604）—— **结论：非缺陷（2026-09-23 结案）**
 
-> **⚠️ 2026-09-23 更正（重要，撤回本轮大部分结论）**：本节 2026-09-22"精确定位轮"中**所有"冻结/WEDGE/停摆"结论均为台架假象，全部撤回**。以脚本层 STEP 行为真值的逐条复核：
-> 1. **分类器误判**：C0/C0b（修复前）脚本层为 `STEP B1460 rx=1460/1460 OK` + `K1460+TAIL rx=2100/2100 OK`，且内容逐字节匹配（0x80,0x81,… 与 `pattern(640,1460)` 一致）——**从未冻结**，而 `probe_classify.py` A/C 模式报 `STALL@B1460 | fill part 0/1460`（其"fill part"比对取错 HEX 块、且未扣除固件探针吞噬的字节）。
-> 2. **探针吞噬即短收**：S1–S4/O1/O1f 的脚本层短收量**恰等于固件探针吃掉的字节数**（S1：4736−4608 = 128 = 2×64 探针读），即"少回显的正是测试程序自己吞掉的那几个包"——非芯片故障。
-> 3. **V1/V1F"唯一真实冻结"同样是假象**：设备侧日志显示 `stage fd=2 avail=64 len=64`，即 **Phase 11 的每 tick 64B 读把对端整包读走后直接丢弃**（该测试分支只判 `n==0`，不处理已收数据），PC 侧下一轮 `STEP R r06 rx=0/64 QUIET`；对照 E 系列（仅 Phase 6、无额外读者）40/40 全过。→ "冻结"= **测试程序自吞数据造成的空洞**，不是芯片 TX 死亡。
-> 4. **撤回清单**：下方"致命性模型"整表（部分排空 10/10 致命、持续第二读 50/50、+0/+80/+120/+160ms 全致命、再武装区间 ≥160ms、相位刀口 O1f、C/C0 = 生产复现、keepalive/快重连排除项中的台架依据）**全部作废**；"生产 lftpd STOR 被 C 配方 10/10 复现"不成立。
-> 5. **仍然成立的部分**：E 系列（Phase 6-only，排空间隔 10/20/40/60ms，标准 `tcp_client` 序列）40/40 通过（脚本层逐步匹配）；"芯片 RX 读是否必须读空"**未被任何有效台架证伪或证实**。
-> 6. **现场 TC-NET-604 冻结仍未解释**：需以可信工具重新复现——判读一律用 `MDK-ARM/bench_verdict.py`（脚本层 STEP 为真值，并扣除固件读者吞噬的字节），`probe_classify.py` 仅作参考；台架配方必须避免"固件内非回显读者"（Phase 9/11、探针）与 PC 侧期望值混用。
-> 7. 相关代码：本轮 N-7 原型（net 层"读必读空"+ 共用中转槽，+3KB）**未提交**，仅存设计；在机理确认前不落地（见 `docs/待处理内容.md` N-7 撤回标注）。
-> 8. **可信复现首轮（2026-09-23）**：改用**真实生产路径**——产品固件（无测试套件、**无任何固件探针**）+ 真 lftpd FTP 上传，判据 = FTP 协议结果 + **上传后 RETR 下载比对 SHA-256**（内容真值）+ 卡住时用**控制通道 NOOP** 区分"数据 socket 卡死 vs 整层卡死"（工具 `MDK-ARM/ftp_freeze_probe.py`，判据天生免疫"固件读者吞数据"假象）。结果：**177 轮全过**（8KB×10、64KB×10/20/100、256KB×5、1MB×2；含零间隔快速重连与 100 轮浸泡），SHA-256 全匹配；并发 UI 流（`:7003`，600 帧）CRC 600/0 全过；设备侧日志无 FAIL/ERROR/WARN（仅每轮数据 socket 正常 `auto-relisten ok`）。→ **当前固件在该组条件下未复现现场冻结**；现场现象是否已被 2026-09-20 起的一系列修复（Trap 09 重监听重试 / L3 pending 化 / D20 / 自动重监听）顺带消除，或需更极端的客户端行为，待进一步验证。
+### 结案结论
+原报告（阶段 8 大文件传输期间：同连接前序突发后 4096B 突发"前 2KB 正常回显、其余静默无回显"）**在当前固件上无法复现，判定为非缺陷**。可信判据（产品固件 + 真实 lftpd FTP 上传，成功 = FTP 协议结果 + **上传后 RETR 回读比对 SHA-256**）实测：**227 轮全过**（8KB/64KB/256KB/1MB；含零间隔快速重连与 100 轮浸泡），并发生产 UI 流（`:7003`）600 帧 CRC 全过，设备侧日志无 FAIL/ERROR/WARN。
 
-### 现象
-单条 TCP 连接在传输中途**静默单向死亡**：设备侧回显/应答流戛然而止（PC 侧 0 字节），连接不 RST（两侧均保持 ESTABLISHED）、无芯片断开事件；**芯片接收路径仍然健康**（2026-09-22 精确定位轮实证：冻结后继续到达的数据芯片照常接收、MCU 照常排空，命令流节奏完整），**芯片发送路径永久死亡**（已写入的发送数据不出线——SPI 写被芯片接受但线上无任何段；ACK/窗口更新随之停止）→ 对端剩余数据滞留**对端发送缓冲**（窗口视图冻结在 0，对端"重传"实为等窗口的空等，10s 无效）。对端断开重连（新 Socket）后恢复正常。2026-09-22 精确定位轮最小复现：64×10 + 1460B 填充 + **1024B 部分排空**（C/C0 配方，Phase 6-only 构建、零第二命令，10/10）；原三因子配方（F1 组合 + 4096B 超容突发）10/10 维持。
+### 为什么原台架会"复现"——**教训，务必先读**
+2026-09-22"精确定位轮"给出的**全部"冻结/停摆/WEDGE"结论均为台架假象，已撤回**：
+1. **测试程序自吞数据**：台架配方里的固件内读者（Phase 9/11 的 64B 读、固件探针读）把对端数据读走后**不回显**——PC 端自然少收，被误当成"设备停摆"。实测短收量**恰等于被吞字节数**（例：`4736−4608 = 128 = 2×64` 探针读）；所谓"V1 配方必冻结"就是 Phase 11 吞掉整包（设备日志 `avail=64 len=64`，PC 侧下一轮 `rx=0/64`）。对照组（仅 Phase 6、无额外读者）40/40 全过。
+2. **判读工具误判**：`probe_classify.py` A/C 模式把**通过**的运行报成 `STALL`（C0 的脚本层实测为 `1460/1460` + 尾段 `2100/2100`，且内容逐字节匹配）。
+3. 由此派生的"部分排空致命 / 再武装区间 ≥160ms / 相位刀口 / C 配方复现生产停摆"等结论**全部作废**；MSS=512 实验的"停摆"亦未经可信判据复核。
 
-> **通俗图解与修复方案**（比喻版机理 + net 层"读必读空"设计 + 代码落点 + RAM 账）：见 `CH395F_Trap21_机制图解.md`。
+### 现在怎么做（台架纪律）
+1. 判读一律用 `MDK-ARM/bench_verdict.py`：**以脚本层 STEP 行为真值**，并扣除固件读者吞噬的字节；
+2. 冻结/卡死类问题走**真实生产路径 + 端到端内容校验**：`MDK-ARM/ftp_freeze_probe.py`（FTP 上传 + RETR 回读 SHA-256）；卡住时用**控制通道 NOOP** 区分"数据面卡死"与"整层卡死"；
+3. **禁止把"固件内非回显读者"与固定期望值混用在同一配方里**——这是本轮最大的教训。
 
-### 根因
-CH395F 片内 TCP 状态机的角（芯片固件，MCU 侧无法修补）。2026-09-22 精确定位轮（11 组台架、110+ 运行、芯片命令序列级 netcmd 日志）定案：致命变量是 **RX 排空的结束态（排空后缓冲是否残留）**，与命令条数/类型/窗口时长无关（逐组实证见下）：
+### 保留的代码变更（与被撤回的机理无关）
+缓冲块布局与 MSS 解耦（`ch395f.h`）、超限读 OVERSIZE 金丝雀（`ch395f.c`）保留：属防御性/可观测性改进，不回退。
 
-1. **结构性前提**：窗口=剩余空间（手册 L1281）→ 守规矩的对端永远把窗口灌满 → 每个稳态轮次缓冲**恰好填满**（2048/2048，窗口=0）是结构性必达状态，无法通过几何裕量规避。
-2. **冻结机制（实证签名）**：MCU 的 RX 数据读命令使芯片 RX 缓冲**残留非空**（窗口重通告到部分值——既非 0 也非满）时，芯片 TCP 再武装状态机被破坏：**芯片发送路径永久死亡**（已写入发送缓冲的数据永不出线——SPI 写被接受但线上无段，ACK/窗口更新随之停止），**接收路径与 MCU 侧 SPI 交互完全健康**（命令序列日志：冻结后 MCU 命令流节奏完整，继续到达的数据芯片照常接收、MCU 照常排空），连接保持 ESTABLISHED → 单向死亡；对端剩余数据滞留对端发送缓冲（窗口视图冻结在 0）。WCH 在 CH395 系列官方 FAQ 留档了同类现象："接收缓冲区需要大于 2 倍设置的 MSS 值，否则……若对端设备不会根据 tcp 窗口来分包发送数据时，有可能会造成 CH395 收不到数据且 TCP 窗口不更新现象"（www.cnblogs.com/sw111/p/18750601，2025-03）；WIZnet W5500（同类：每 Socket 小型缓冲 + 片内 TCP + 窗口=剩余空间）官方文档同为"缓冲满则挂起连接等待空闲空间"模型，zero-window 停摆是该类芯片的经典病理（docs.wiznet.io W5500 TCP Application 文档；Wireshark 论坛 49849 实例）。
-3. **致命性模型（2026-09-22 精确定位轮：11 组台架、110+ 运行、芯片命令序列级 netcmd 日志；逐组实证，非日志/生产时基；Δ = 本次读移走的字节数，"残留" = 排空后缓冲剩余）——取代下方旧"三因子/50–100ms"模型**：
-
-   | RX 读模式（构建） | n | 结果 |
-   |---|---|---|
-   | 排空至空（窗口→满），10/20/40/60ms 节拍，任意 Δ（64/1460/2048B；E 系列） | 40/40 | **全过**（含 10ms 节拍 E0：满→空→满 正常循环，排空后 10ms 再排空安全） |
-   | Δ=0 纯状态读（GET_RECV_LEN 空读 / SINT 中断读 / poll 每 tick）与 TX 命令（E 系列 / B 系列 0.4s 静置 ~40 次状态读） | 40/40+ | **全过**（任何偏移/密度） |
-   | 满(零窗)排空 + 一次性 64B 部分读 @~50ms（v3 O1，10ms 栅格） | 10/10 | 过（相位刀口，见下） |
-   | 同上 + netcmd 命令日志（netTask 时移数 ms，O1f） | 5/5 | **全冻结**（一次性落点相位翻转） |
-   | 满排空 + 每 tick 64B 部分读（持续 Δ=64）：10ms(S1) / 90ms(S2,+80ms) / 130ms(S3,+120ms) / 170ms(S4,+160ms) / 60ms(V1、V1F) | 50/50（6 构建） | **全冻结**（每事件相位风险累积） |
-   | **部分排空（1460 中排 1024、留 436 残留）、零第二命令（C0）** | **10/10** | **全冻结（第一条命令即致命）** |
-   | 部分排空 + 一次性 64B 部分读（C） | 10/10 | 全冻结 |
-   | 快速重连链（20 连接、0.6s 间隔、窗口内状态读 + canary；F1 链） | 20/20 | 全过（"快重连预置"假说证伪） |
-
-   → **部分窗口重通告（排空后缓冲残留）= 致命类**：小 Δ（64B）呈**相位刀口**——残留态持续 ~10ms 多为安全（v3 O1 10/10）、~20ms 多为致命（O1f 5/5）、45–60ms 多为致命（V1/V1F 10/10）：芯片再武装内部子相位周期性，且对构建/时基对齐敏感（O1f：命令日志引入数 ms 时移即 10/10 过 → 5/5 冻）；大 Δ（1KB 级 = 生产 lftpd 块读）为**确定性致命**（C0：残留态 10ms 后即被下一次排空清掉仍 10/10 冻结）；小 Δ 持续重复 = 数百事件累积 → 必然（S1–S4/V1/V1F 50/50）。**排空至空（窗口→满）恒安全**（40/40，含 10ms 节拍）——芯片设计的正常循环；Δ=0 命令（状态读/中断读/TX）恒安全（B/E 系列）。
-   - **再武装区间（实测下界）**：满排空后的"第二条 RX 数据读"在 +0/+80/+120/+160ms 偏移位均致命（S1–S4 各 10/10）→ 脆弱区间 **≥160ms**，内部致命子相位周期性、相位敏感 → **不存在可移植的单值窗口**；旧"~50–100ms"为两点外推（V1 45ms 致命 / E 95ms 安全），上界被 S3/S4（120/160ms 仍致命）证伪。
-   - **生产触发（实证复现）**：lftpd 数据通道 STOR 块循环 = 每 1KB 一条 `net_recv(1024)`（部分排空、留 ~1KB 残留、间隔 15–70ms）= C/C0 模式 → **10/10 确定性冻结**（C 系列 = 生产停摆的台架复现，无需任何其他因子）；RETR（下载，设备为发送方）不经芯片 RX 排空路径，不受本机制影响。
-   - 历史条目（前轮台架，与新模型自洽）：MSS=512 时新连接 4096B 突发（8×512 段）确定性停摆恒剩 64B = 高段密度下部分读事件密集；单轮 ≤2KB 无溢出突发在任何几何/命令结构下正常（排空即至空）。
-
-4. **（历史记录：2026-09-22 二次台架"三因子/第二条 RX 命令"模型——已被上方致命性模型取代，保留作过程记录）**
-   - **三因子模型（MSS=1024 基线；主因已定案）**：① 同连接前序突发（芯片 RX 状态预置；高段密度可等效替代，见 MSS=512 条）+ ② 后续突发超缓冲容量（4096B > 2KB，需 ≥2 个填周期）+ ③ **填周期内第二条 RX 命令**（排空之后同一 socket 的任何额外 SPI 命令——纯状态读 GET_RECV_LEN 即足够）——**三者齐备才触发，缺一不触发**：
-
-     | 变体 | 与 Phase 6-only（单 RX 命令路径）的差异 | 结果 |
-     |---|---|---|
-     | Phase 6/9/11（每周期多路 RX 命令） | Phase 9/11 各加一路 RX 命令/周期 | **10/10 停摆**（4096B 步：前 2048B 回显正常，余停） |
-     | Phase 6-only + 排空间隔 10/20/40/60ms（E 系列） | **只拉长排空间隔，不加第二条命令** | **40/40 全过**（每档 10/10，含满态持续 60ms+） |
-     | Phase 6 + 11 + 60ms 间隔（V1，最小扰动） | 每周期加一条 GET_RECV_LEN 状态读（落点 ≈ 排空后 45ms） | **10/10 停摆**（4096B 步，落点与经典模式一致） |
-     | 多路 RX 命令、无前序突发 | 新连接独立 4096B | 过（31ms；probe_mss 对照——前序突发因子缺失） |
-
-    - **主因（历史记录：二次台架时的"第二条 RX 命令"定案——已由上方致命性模型精化：真致命类 = 排空后缓冲残留的部分窗口重通告，"第二条命令"是其在当时构建中的表面形态）**：冻结与缓冲"满"的持续时长**无关**——排空间隔拉到 60ms、缓冲满态持续 60ms+，单命令路径仍 40/40 干净（"满了滞后不舀"假设被证伪，此条仍然成立）。旧结论"排空后 ~50–100ms 内到达的第二条 socket 命令"为两点外推（V1 落点 45ms → 10/10 卡死；E 系列落点 ≈95ms → 10/10 干净），上界被精确定位轮 S3/S4（+120/+160ms 仍致命）证伪；一次性第二条命令的生死取决于落点相位（v3 O1 10/10 过 / O1f 5/5 冻，同一构型仅时移数 ms）。
-   - MSS=512：新连接 4096B 突发（8×512 段，4 段装不进 2KB 缓冲）**确定性停摆**，恒剩 64B 未达（4032/4096，2/2 同值）——段密度维度：满周期内段数越多，突发内自我预置越快，越易触发（该实验在多 RX 命令构建上执行，与主因模型自洽）。
-   - 单轮无溢出突发（≤2KB，如 1460B）在任何几何/命令结构下均正常。
-5. **排除项**：① 驱动层"超限读静默丢弃"排除——SPI DMA 缓冲 = 2×MSS+4 = 2052B（载荷 2048 = 整个接收缓冲），整缓冲读单事务完成，失败运行中丢弃事件 0 次（Trap 13 所记 1500B DMA 缓冲为 8-Socket 改造前旧值，改造后扩至 2052B）；② L3 pending 化排除（切片构建 A/B 行为逐字节一致）；③ "RX > 2×MSS"裕量假设排除——MSS 1024→512 实验（2KB=4×MSS、1KB 裕量）既未消除原复现序列的停摆（10/10），又新增新连接停摆 → 已回退 1024；④ "快速重连残留预置"假说排除——受控 20 连接 0.6s 间隔链 20/20 干净（v2 轮 1/9 单例未复现，按孤立事件处理）；⑤ keepalive 命令排除——S1 纯探针构建（无 keepalive）10/10 冻结，V1F（带 keepalive）10/10 = 与部分读机制一致，keepalive 既非触发也非保护。
-
-### 解决（2026-09-22；精确定位轮定案更新：MCU 侧修复 = 非阻塞 RX 读强制排空至空）
-1. **MSS 维持 1024**（布局允许最大值；实测 1024 下新连接 4096B 正常、每满周期段数少 = 预置积累最慢）。MSS=512 裕量方案被证伪并回退。
-2. **缓冲块布局与 MSS 解耦**（`ch395f.h`）：`CH395F_RECV_BLOCKS=4` / `CH395F_SEND_BLOCKS=2` 固定（此前由 MSS 推导，改 MSS 会连带缩小布局）；`CH395F_SPI_DMA_BUF_SIZE = 接收缓冲 + 4`（此前 2×MSS+4，改 MSS 会缩到装不下整缓冲）。
-3. **超限读金丝雀**（`ch395f_read_recv_buf`）：正常路径不可能发起超过接收缓冲（2KB）的读；守卫命中即留痕 `read_recv_buf OVERSIZE`（原为静默 return，会把窗口锁死在 0 且无从诊断）。
-4. **MCU 侧修复（2026-09-22 精确定位轮定案 → N-7，待批准实施）**：致命类 = 部分窗口重通告（排空后缓冲残留）→ net 层**强制一切非阻塞（DONTWAIT）RX 读排空至空**：RX 读上限强制为接收缓冲全量（2048B）——"只读一部分"经安全 API 不可表达；应用按自身块粒度消化排空结果（lftpd `receive_file` 块循环 `net_recv(1024)` → `net_recv(2048)`，仍按 1KB 块处理，接收缓冲需 ≥2KB）。依据：排空至空任意节拍均安全（E 系列 40/40，含 10ms E0）→ **无需时间守卫/冷却**（旧"第二命令暂缓 + 120ms 冷却"设计作废：C0 证明部分排空自身即致命（零第二命令也 10/10 冻结），E0 证明排空至空后 10ms 再来一次排空也安全——时间守卫既不足又多余）；Δ=0 命令（状态读/中断读/poll/TX）豁免（实测安全，不过度阻塞）。残留约束：阻塞/pending 读若以部分结果落地且未即刻排空至空，仍属致命类（pending 完成点同样强制全量，或应用同 tick 内排空）——N-7 实施时处理。
-5. **兜底缓解（决策项，未实施）**：冻结不自恢复（对端重传 10s 无效；芯片无限期保持连接）。唯一恢复 = 断开受影响连接（释放芯片 per-socket 状态）+ 对端重试（新连接成功率高；台架实测停摆后重连回显正常）。现 lftpd 数据路径预算 `LFTPD_TOTAL_BUDGET_MS=30000`（每次读 30s）即实际停摆超时——若将**数据通道**预算单独缩短（10–15s，与控制行预算分离），可把停摆暴露时间从 30s 压缩到客户端重试路径；代价 = 慢速但健康的传输也会被中断（机器客户端不受影响，人工客户端受影响）→ 已列 `docs/待处理内容.md` N-1 待决策（N-7 落地后本项紧迫性下降，保留为兜底）。
-
-### 注意事项
-- 复现模式（2026-09-22 精确定位轮更新）：**部分排空（读后缓冲残留）= 唯一实证致命模式**——最小台架复现 = 64×10 + 1460B 填充 + 1024B 部分排空（C/C0 配方，Phase 6-only 构建，零第二命令，10/10 冻结）；旧"三因子"配方（F1 组合 + 4096B 超容突发）10/10 维持，其中 Phase 9/11 每 tick 64B 读、V1 每周期状态读后的 64B 读、生产块循环 1KB 读均为"部分读"模式的不同剂量形态。生产主要风险场景 = **lftpd 数据通道 STOR（上传）**：块循环每 1KB 一条 `net_recv`（大 Δ 部分排空，间隔 15–70ms）= C 配方 10/10；RETR（下载，设备为发送方）不经芯片 RX 排空路径，不受本机制影响；N-7（排空至空强制）落地后 STOR 块循环转为 E 系列模式（40/40 安全）。
-- 与 Trap 22 的鉴别（两者都可在断连/重监听后出现）：本条 = RX 路径冻结（有 standalone accept、前段回显正常、其后 RECV_OK 永不再来、无 send 失败）；Trap 22 = 连接状态失同步（缺 standalone accept + `send -1` + `WARNING: listen` + 监听死亡）。
-- 冻结对 MCU 是静默的：无 RST、无芯片断开事件、无 send 失败；精确定位轮命令序列日志修正旧表述——MCU 侧 RX 路径照常工作（冻结后到达的数据可正常排空，命令流节奏完整），**死的是芯片 TX 路径**（已写入的发送段永不出线）；MCU 无直接信号，只能靠应用层数据预算（lftpd 30s / 客户端自身超时）或对端视角（收不到回显/ACK）发现。
-- E-02 审计"STOR 方向缓冲满 + 重传耗尽 → 必断"的预警方向成立（STOR 方向 = 致命），机制修正为本条 RX 冻结（非 RST 拆连）。
-- WCH FAQ"发送缓冲必须大于 MSS"为严格不等式；本设计发送缓冲 = MSS（1KB = 1024）取等值——台架实测芯片在缓冲边界可正常成包（L3/L8 基线在 1KB 分块写入下全部正常），该条按保守表述处理，非运行约束。
-- 本条的冻结是确定性触发模式缺陷（排空结束态 = 缓冲残留的部分窗口重通告；小 Δ 落点另有相位刀口），非低概率随机竞态——发现新停摆模式时先核对"是否存在部分排空（net_recv 上限 < 缓冲现有字节数，读后缓冲非空）"，再怀疑 MCU 侧。
-
-### 对应文件
-`Drivers/BSP/CH395F/ch395f.h`（布局解耦 + MSS=1024 维持）；`Drivers/BSP/CH395F/ch395f.c`（OVERSIZE 金丝雀）；`Drivers/BSP/NET/net_socket.c`（MSS 下发注释；netcmd 芯片命令序列日志——bench 开关 `NET_BENCH_CMD_LOG` 默认关，2026-09-22 精确定位轮工具）；`test/ch395f_socket_test.py`（复现：tcp_client 全序列）；`MDK-ARM/probe_mss.py`（MSS/芯片 TX 分包探针）+ `probe_{boundary,status,partial,fastrecon}.py`、`probe_classify.py`、`netcmd_extract.py`（精确定位轮台架/离线判读/命令序列提取工具，均本地不提交）。
-
-### 发现时间
-2026-09-22（TC-NET-604；根因确认、MSS=512 证伪与回退、布局解耦同日完成，提交于 wip/v2-pending-recv 分支）。2026-09-22 精确定位轮：11 组台架 110+ 运行（E/O/B/F1/S1–S4/C/C0/V1F/O1f）定案"部分窗口重通告"致命性模型，N-7 设计由"排空后 RX 守卫 + 120ms 冷却"改为"非阻塞 RX 读强制排空至空"（无时间守卫），netcmd 命令序列日志工具入库（默认关）。
+### 相关
+- 真实缺陷见 **Trap 23**（上传中止后首笔复连上传被静默截断，已可信复现并修复）；
+- 发现：2026-08-26（阶段 8）；结案：2026-09-23。
 
 ## Trap 22：重监听后快速重连丢失 CONNECT 中断 → 监听静默死亡
 
@@ -623,7 +570,7 @@ CH395F 片内 TCP 状态机的角（芯片固件，MCU 侧无法修补）。2026
 1. 芯片硬件完成握手但 CONNECT 中断未上报（或 MCU 侧丢失）→ `handle_connect_event` 未执行 → 状态滞留 LISTENING。
 2. **实证边界（2×2 台架）**：失同步仅现于"轻负载 + 重监听历史 + 快速重连（~600ms）"组合；重负载（Phase 6/9/11）下断连后 ~500ms 重连仍同步正常（B' 组 20/20 standalone accept、10/10 全连接成功）；轻负载 + 15s 重连间隔亦全正常（A' 组 20/20）。即中断丢失窗口 ≈ "close → 重监听 → SYN" 间隔 < ~1s 且 netTask 相对空闲。芯片侧丢中断的具体原因未解（列为后续观察项，不阻塞下述修复）。
 3. 后果链确定：状态滞留 LISTENING → `net_send` 被拒（send -1）→ 断开时 DISCONNECT 落 LISTENING 分支（现有代码仅告警）→ 芯片自动关闭 Socket → MCU 不再重开 → 监听死亡。
-4. 与 Trap 21 的关系：**独立失效模式**——Trap 21 = RX 路径冻结（缓冲空、无 RECV_OK、窗口冻结、连接状态正常）；本条 = 连接状态失同步（数据可流但发送被拒，且可致监听死亡）。日志签名鉴别：Trap 21 无 standalone accept 缺失、无 send -1；本条三者齐现（缺 standalone accept + `send -1` + `WARNING: listen`）。
+4. 与 Trap 21 的关系：Trap 21（TC-NET-604 "RX 窗口冻结"）**已结案为非缺陷**（真实生产路径 227 轮全过；原台架"停摆"系测试程序自吞数据 + 判读工具误判，见 Trap 21）；本条（Trap 22）是**独立且仍待修**的失效模式：连接状态失同步（缺 standalone accept + `send -1` + `WARNING: listen`），须与之分开跟踪。
 
 ### 修复（方案，未实施 → N-6）
 1. `handle_disconnect_event` LISTENING 分支：回读芯片 socket 状态，非可监听状态（即芯片已自动关闭）时执行 `net_relisten_try` 重建（重 OPEN + TCP_LISTEN）——D20 陈旧事件修复的 LISTENING 分支姊妹情形（D20 只处理 ESTABLISHED 分支）。
@@ -657,7 +604,7 @@ CH395F 片内 TCP 状态机的角（芯片固件，MCU 侧无法修补）。2026
 ### 影响
 - **静默数据损坏**：上传被中断后"重试的第一笔"会生成截断文件且客户端收到成功回报（FTP 客户端通常不做长度校验）→ 现场可能表现为"上传的文件损坏/不完整"；
 - 主风险面 = 生产路径 STOR（上传）；RETR（下载）不涉及；
-- 与 TC-NET-604 的关系：本条为**独立、已复现**的真实缺陷；TC-NET-604 的台架"冻结"结论已撤回（见 Trap 21 顶部更正块），现场"卡死/失败"报告应优先用本条的判据（协议结果 + 哈希往返）复核。
+- 与 TC-NET-604 的关系：本条（Trap 23）是**独立、已可信复现并已修复**的真实缺陷；TC-NET-604 已结案为非缺陷（见 Trap 21）。现场"上传失败/文件不完整/像卡死"类报告，应优先用本条的判据复核：**FTP 协议结果 + 上传后 RETR 回读 SHA-256**（+ 卡住时控制通道 NOOP 探活）。
 
 ### 复现
 ```