super_agent_bot
0d469a835a
test(net/udp): 主机单测按真机改写 UDP-4/17/22/24，补残包组 UDP-26（#73）
剥头判据改了，测试就得跟着改——但这一条提交里真正值钱的是"为什么会错到"：
UDP-4 当时写的是"客户端形态整包都是载荷、源地址取对端记账"，UDP-24 的 240 轮
定种子随机长跑也照同一个模型脚本报假件。**随机长跑全绿恰恰不能证明模型对**：
它扫的是我自己写的那套模型，模型错了它一样绿。只有真机那次 48→56 的读数把这件事
钉死。
- UDP-4 改写为"客户端形态同样剥头"，源地址来自信息头（脚本里特意让头里的源
`119.28.220.215` ≠ 记账对端 `119.28.220.214`，这样"取错地方"就必然失败），
并补 UDP-4h 断言 `addrlen`/family 与服务器形态一字不差——一条读路径就该一个契约。
- UDP-17h/m、UDP-22c、UDP-24 的客户端轮同样按定案重写（先 `reset_recv_len` 再
宣布长度，假件的收包脚本必须可重排，这是长跑教过的第二条）。
- 改完判据后覆盖率门禁照出 `net_udp_src_from_peer()` 一行没人走了。**没有把基线
调低**，而是补 UDP-26（9 条）钉住"`<8` 字节残包"那一侧：整包原样交付、一个字
节都不许剥、源地址退到对端记账；没记账时交出全零这个"我不知道"，而不是包里的
字节——它是记账那本账如今唯一的读者。
全套 **677/677 绿**（改造前 470）；`net_udp.c` 回到 237/239 行、14/14 函数，
`net_socket.c` 966/969 行、59/59 函数，全仓 8372/9290（90.1 %）、47/47 套，
`scripts/test_coverage_baseline.json` 与改动前一字未变（即无回退）。
2026-11-04 09:15:52 +08:00
..
2026-10-24 17:54:02 +08:00
2026-11-03 18:44:01 +08:00
2026-11-03 18:44:01 +08:00
2026-11-03 18:44:01 +08:00
2026-10-24 21:00:17 +08:00
2026-10-27 08:59:26 +08:00
2026-10-27 08:59:26 +08:00
2026-11-03 18:44:01 +08:00
2026-11-03 18:44:01 +08:00
2026-11-04 09:15:52 +08:00
2026-10-30 07:16:07 +08:00