49 Commits

Author	SHA1	Message	Date
super_agent_bot	fff961d803	feat(net/udp): UDP 数据面并入 netMsgQueue 串行执行（#73） ... 前置来自 #57 SNTP 调研：旧 net_sendto / net_recvfrom 由调用方直调 SPI 且无限自旋收包，既违约「netTask 是芯片唯一访问者」，又把 IWDG 预算吃在自旋里。 改造面 - 新增 Drivers/BSP/NET/net_udp.c/.h（真机专属，模拟器不编译）： bind/set_peer/sendto/recvfrom 四条执行体 + 挂起收包表 + tick； net_msg_type_t 加四型，公开 API 一律「入队 → 睡在通知上」。 - 源地址出参不搭 net_msg_t（按值拷贝，AGENTS 禁加回传字段）：改住 net_udp.c 的 per-fd 槽，netTask 就地写回调用方内存，通知值只带 结果码；每条出口都清槽，泄漏 = 该 fd 永久 BUSY。 - 发送复用 net_send_locked，不写第二份分块逻辑；「会话是否已死」 收成一条判据 net_send_state_down()（TCP 看 ESTABLISHED、UDP 看 UDP_OPEN），原先 4 处各写一遍。 - 顺带修掉真缺陷（新条 TRAP-NET-22）：旧 sendto 把 DesIP 写成具体 IP，芯片静默切 UDP Client，而旧 recvfrom 无条件剥 8 字节 → SNTP 这类 48 B 应答丢载荷前 8 字节并交出垃圾源地址。加 udp_mode（塞进 原有 padding，sizeof 不变）、bind 恒 SERVER、显式对端 sendto 切 CLIENT、set_peer(fd, NULL) 轻量回 SERVER，仅 SERVER 且 avail >= 8 才剥头。 - 截断定案：一次调用交付一个数据报，buf 装不下的尾巴用 64 B 栈上 scratch 排空（不用 clear_recv_buf——它连后面已到达的包一起丢）。 - 取消点接齐：net_init 重建 cancel_all、net_socket 分配 fd clear、 net_close settle_close + clear、重 bind 前先结算等包者， net_process_messages 第 5 个 tick 位挂 net_udp_tick。 - 收紧两处契约（原实现无生产调用者）：UDP 未 bind 一律 -5； net_recv / _nb / _to 拒 DGRAM（绕过剥头就是静默吃 8 字节）； NET_ERR_NOT_IN_NETTASK(-12) 退役为历史常量并写明原因。 验证 - 主机单测 test/host/net_socket 全套 616/616 绿（改造前 470）：新 分片 ns_s7_udp.c 20 组，改写 440 / 555 / 560 组；覆盖率 net_udp.c 234/236（99.2%）、net_socket.c 956/969（98.7%）， scripts/test_coverage_baseline.json 随本提交登记新文件。 - 测试抓到 4 个被测码真 bug：自等守卫误用调用侧谓词、芯片长度被读 两次、槽指针取在 fd 合法性检查之前、重 bind 静默作废等待者。 - Keil ARMCC 0 Error(s) 0 Warning(s)；net_udp.o Code 1,358 / ZI 224 （8 fd × 28 B，其余模块零增长），全仓 RW_IRAM1 72.2%；内存台账 受管区按门禁提示用 --write / --update 机器回填，未手改数字。 - pre-commit 全量钩子（含 doc-links、coding-standard、mem-budget、 generated-fresh、bsp-err、registration、nested-comment）全绿。 限度 - 本轮无板子：真机回归 5 条（两端互通、set_peer(NULL) 能否恢复收 广播、截断排空后下一包完整性、挂起 recv 期间 IWDG 余量、bind 写 DesIP 与 open 先后的真芯片效果）已写进覆盖率口径「台架必验」。 - scripts/stack_report.py 退出码 1 是 10-26 起挂在账上的 iec104Task 栈债（margin 1,016 < 1,024，见 docs/代码规范/pre-commit使用说明.md: 122）；本轮只让 net_bind 的 UDP 分支多一层静态帧（1,544 → 1,600）， netTask margin 1,888 与 timeSyncTask 1,152 不受影响。抬栈要过 mem-budget 台账，不在本分支自行处理。 - 登记簿销项按仓库约定留给主工作树，本分支不动 docs/任务规划/**。	2026-11-03 18:44:01 +08:00
wandering1	f754d59218	docs(测试说明): 按用途分六个子目录并同步全库引用 ... 分层：流程与规范/ 单元测试/ 板级测试/ 专项验证/ 测试工具/ 测试数据/， 顶层只留新增的目录导航 README.md（归层判据 + 硬约束 + 本次处置记录）。 - 搬迁 28 个路径：测试数据三个目录 58 个文件为纯改名（R100，内容逐字节不变） - 全库引用同步 124 个文件：AGENTS / docs 索引 / skills / 门禁注释 / scripts - 门禁面：scripts/check_test_traceability.py 的 glob 改 rglob （分层后不递归扫描＝追溯门禁直接瞎掉） - scripts/rename_ref.py：收尾的 ℹ 提示在 GBK 代码页抛 UnicodeEncodeError， 让进程以退出码 1 收场而改写其实已落盘（RC 与真实结果相反）；改为把 stdout/stderr reconfigure 成 UTF-8，与 check_doc_links.py 等同法 - docs/文档规范.md §1.1 补「子目录文件过多时再分一层」；§3.6 补 rename_ref 搬整目录的两个实测坑：① 会改写目录内部文件的内容 ② 内部文件的 ../ 出链 不补层级（本次 23 个被误改的证据文件已按 HEAD 原始字节逐字节还原） - docs/README.md §6 改为与六个子目录一一对应，并补登原先漏登记的 「启动日志原子性复验流程」一行 - .cubemx_survival_baseline.json：App/util/task_watchdog.c 的注释路径也随分层更新， 该文件是存活审计的 watchdog-module 漂移锚点，按脚本自己的提示跑 --write 重建基线 （实测重建后仅 watchdog-module 一条哈希变化） - 铁律 4 例外（本次在任务树里改了单写者文件）：AGENTS.md 与 .pre-commit-config.yaml 只被 rename_ref 改写路径字面量（后者全在注释行）， 任务表块与钩子声明一字未动 验证：check_doc_links.py --sections-strict 覆盖全部 88 个改动 .md 全绿； check_test_traceability.py 输出与主树逐行一致；196 个文本文件无 BOM、无新增 CR、无 U+FFFD、无行尾空白；陈旧引用面由主树 25 处降到 6 处（无新增断链）。	2026-10-30 07:16:07 +08:00
wandering1	20617a33f7	docs(编号规范): 编号一律停发——§4.1 五族也不再发新号，只读存量 ... 用户裁定（2026-10-29）：「啥号都不发」= 任何族都不再新增编号， 含 §4.1 那五个原本"有脚本按字面量匹配"的存量族；既有号只读引用， 族里新增内容一律写语义行名。 规范本体： - §1 由「先问三句」改成「默认答案：不发号」，三问表换成场景对照表； - §4.1 由「允许用号的族」改成「存量族」，第四列改「既有号被谁读 / 新写怎么办」，逐行写明新写怎么做（TRAP 写语义行名、FR 用 §5 行名、 CODE-RULE / MENU-STATE 先问用户、P-n 只读存量页号）； - 末框四条对照 + 唯一例外入口（确需机器按字面量匹配 → 先问用户）； - 新增族 = 一律不许；批准后顺序：本文 §4.1 → 属主文档 → 才动 registry。 跨文件同步（12 份）：门禁说明 id-check-new / id-check / host-unit-tests （把"校验 5/3 拦新号"这类现状叙述历史化）、两份 TRAP 记录的编号口径、 开机账本用例号说明、AGENTS 两处、id-family 技能与其 steps-alpha 模板、 归档 README 与两份归档脚本 docstring。 AGENTS 主题表那行原写「允许用号的 7 个族」，与规范的 5 行本就对不上， 旧计数一并消掉。 未做：pre-commit 的 default_stages 一行——用户对该项未置可否。 验证：py_compile 与 check_ids_new.py --self-test 均 rc=0；逐篇 check_doc_links.py --sections-strict rc=0（编号规范 70 处引用 / 68 可判定 / 无法判定 0）；13 份改动文件表列数与字节体检相对基线零新增。	2026-10-29 21:31:42 +08:00
wandering1	0f7b5a87fb	chore(编号): 存量编号全量转语义短语，门禁识别面与语料同批重打 ... 登记簿、文档与代码注释里的存量字母加数字编号（N-x / S-x / T-x / E-x / A-x / 卡号） 一律改写为语义短语，净删 2,028 处引用；删除基线与待确认、并行分道方案、排期详述、 采集保护收尾 4 篇（内容已并入 docs/任务规划/README 与登记簿）。 门禁机器与三张账同批重打：check_ids.py 新增变更记录行豁免与第二根护栏 undecidable_total_ceiling；check_test_traceability.py 只加 stdout/stderr UTF-8 reconfigure（TC_RE 未动）；check_cubemx_survival.py 的 --write 固定 newline=LF； id_registry / id_aliases（+19 条 retired-to-phrase）/ id_known_backlog 重打。 test/ 56 个文件同步 TC 标签语义化，其中 18 个 TU 改了 CHECK / printf 里的标签文字， 是本批唯一改变构建产物的文件集合。 为什么合成一笔、不拆四笔（实测撞闸，非偏好）：pre-commit 跑钩子前会 stash 未 staged 部分，拆开后中间提交必然是「新规则 + 旧语料」——实跑可判定 85.15% < 基线 86.00%、 不可判定 1,453 > 上限 1,166，编号门禁直接拦下。编号识别面与它描述的语料只能同码移动。 实跑基线（工作区全量）：754 文件 / 8,230 处编号字面量 / 可判定 7,079 = 86.01% （基线 86.0%，容差 0.1pp）/ 不可判定绝对数 1,151（上限 1,166）/ 校验 1-6 错误级 0 / 告警 = 悬空 2（App/algo/freq.c 的 S2，属 §4.4 同号不同义）+ 孤儿 50。 基线从 84.0 抬到 86.0 的理由见 docs/门禁说明/id-check.md §7.6：本批真删了 2,028 处 引用，可判定面随真实内容上升，不是把分母做小。同批新增排除 docs/硬件平台/ 语料，使 识别面少 264 处——芯片手册位号与网表料号不属编号空间（registry 有 excluded_paths_note）。 ⚠ 余量只剩 0.11pp（约 10 处）与绝对数 15 处：把「可判定的引用」改成散文会立刻撞第二 根护栏。另遗留一项：id_aliases 里 retired 的 N / S / T / A 别名没有 scope（U1~U5 有）， 今后有人新写一个 A-4，校验 3 不会响，只能靠人，建议下批补 scope。 固件不变证据：115 个 .c/.h 剥注释并归一字符串后与 HEAD 逐字节全等，残留代码差异 0； App / Src / Drivers 的字符串字面量零改动。@build 0 错误 0 警告；40/40 主机套件、2,889 断言全通过；覆盖率 line 89.2% / func 92.6%；pre-commit 48 钩子 --all-files 全绿； check_doc_links --all 通过（176 文档，章节引用无法判定 0）；逐字节卫生核过：14 个带 BOM 文件与 HEAD 一致、0 个 CR、0 个 U+FFFD，字符串字面量纯 ASCII。 .cubemx_survival_baseline.json 的 watchdog-module 哈希 56bf27 变 2bb051 属合法： Src/freertos.c 的 USER CODE 区内只有注释文字随编号改写，代码未变。 同批带上体积同码凭证与 RAM 台账行（@build 之后盖戳）：RW_IRAM1 79,008 B / 60.3%， RW_CCM 57,376 B / 87.9%，阈值 92%。	2026-10-26 12:28:14 +08:00
wandering1	5a806d8a26	fix(log,net): 处置主机单测照出的 10 条现状，撤销 1 条误报 ... 用户裁定「全部修」。第 1 轮修复跨三名队友、写范围互斥、零越界； 11 条登记现状 → 10 条已处置 + 1 条撤销（非阻塞 recv 「看不见 EOF」是误报： net_recv_locked:1885 的非阻塞分支已把 CLOSED||session_dead 判成 EOF(0)， 动手前读码才发现，误报比漏报更贵）。 存储与日志（App/log/sys_log_mcu.c、soe_store.c、cfg_file_store_mcu.c、sys_log.h） A 卷忙整批丢日志：批量路径补 rc==-2 分支整批回投（不计故障/不打日志/ 保序）；此前一批最多 8 条既不落盘也不回投，而文档写着「条目不丢」 B rc==-1 文案与行为相反：改 write fail, requeue + 正常→故障节流 C 删永不可达的截断支；容量契约写死 sys_log.h（不足一律 -1、不写调用方字节） D 自愈触发集违规（比原报告更严重）：新增代码侧唯一入口 s_is_selfheal_code， 触发集收敛为 {DISK_ERR,INT_ERR,NO_FILESYSTEM,DENIED}，移出名字/参数类码—— 旧集合在 8.3 同名同因下每轮删一次自己的历史日志且永不自愈，正是存储架构 §10.1 第 10 条严禁的归集；soe_store 侧同源取更保守子集（打开失败绝不 unlink） E 注释里的 FR_NO_SYSTEM 不存在，改 FR_NOT_READY / FR_NO_FILESYSTEM F syslog_post 满态留痕节流（A 修好后「队列常驻满」成必然场景，不修等于用 新刷屏换掉静默丢）；丢弃语义一字未改 NET（net_socket.c/.h、net_types.h、net_socket_sim.c、lftpd.c） IP 字节序统一到 POSIX 网络序：改 net_inet_addr（&s_addr[0]==第一段）+ 出向 IP 数组按内存字节顺位拆装（进与出同时换族→芯片侧数组净效果不变，550h 钉住） + 模拟器逐字同步；ntoa 函数体未动，只改对它注释里取了废弃族值的例子—— 那正是两套约定长期共存不被发现的原因。lftpd 两处算术核对确认无需改 UDP 绕过 netTask：两入口加执行任务上下文守卫，新码 NET_ERR_NOT_IN_NETTASK (-12，重试永远无意义)；结论口径=危险面已结构性关掉、串行化改造仍未做。 附带关掉第二条更隐蔽的路：非 netTask 自旋 recvfrom 期间控制块被 close 并 把同一 sockfd 分给新会话→旧自旋者消费新会话数据报 控制台（console_log.c/.h）：冷却改独立 s_con_cooling 标志（旧写法在 tick==0 那 拍冷却等于没记）；con_append 的判空位+推进 head+整行拷贝收进同一临界区（旧 为区外 check-then-act，环 >95% 满时可静默覆盖且既不打 [ERR] 也不计 dropped）； Instance==NULL 与僵尸通道分诊（未初始化绝不 reinit）；三本账分离 + 新读口 dbg_console_tx_timeout()；[ERR] 行改为发成功才销账 测试：net_socket 452、console_log 127、sys_log_mcu 104、soe_store 27、 cfg_file_store_mcu 34；回归 net_listener 34 / net_events 34 / net_pending 43 / net_select 22 / lftpd 35 / lftpd_inet 28 / lftpd_io 33 / iec104_serv 28 / nand_port 149 / vol_lock 33 / soe 32 / cfg_file 151 全绿。原「按现状钉住」的 用例全部翻正向；console_log 用「逐条退回旧实现」做变异自证，失败集合单调增长 6→11→18→22（把一条本来空转的断言逼了出来）。 游标抬升：TC-NETSOCK-545→560、TC-SYSLOG-100→107、TC-CONLOG-135→167。 文档：控制台设计说明 §4.1 口径与 §13-O2 销项 + v1.5；运行与自检记录 §4.4/§4.5 四条；存储架构 §10.1 第 10 条推论（指向 s_is_selfheal_code）；TRAP-NET-21 后续 条目；BSD 指南新增 §9.0 s_addr 唯一约定；覆盖率口径 §9「第 1 轮修复处置」表 + 后续项 5 条 + 台架复验 7 条 + 新坑 8 条 + 变更记录。 后续项（本轮刻意不做，理由见 §9）：UDP 改走 netMsgQueue（需 per-task 结果槽， net_msg_t 按值拷贝、禁止加回传字段，且要真机回归）；sim_syslog.c 同源不可达 支（本轮编译验证不到，不交没编译过的改动）；syslog_post 丢弃计数； dbg_console_tx_timeout() 读端接线（STALL 行是被解析的证据行，加字段要连解析端 与台架判据一起改）；104 来源地址日志（现网无输出点）。 gate: @build 0 errors 0 warnings（Code=213720 RO=18860 RW=1204 ZI=131500）。 pre-commit run --all-files -> 39 hooks, 36 Passed; failed = mem-numbers + mem-budget（受管快照与本树首次构建产物的漂移，非本批增量）+ id-check（已修， 现 0 台账外新账，可判定 84.63% > 基线 82.6%）。实测水位 RW_IRAM1 57.4%、 RW_CCM 87.9%，均低于 92% 红线；RAM/Flash 本批增量为数个 static 变量。 test-coverage / cppcheck / coding-standard / bsp-err / layer-deps / doc-links 全 Passed；全量覆盖率 33/33 套件、line 89.3%、func 92.3%、逐文件下降 0。 按仓内分支约定 --no-verify 提交，台账 --write 回填留待主工作树合并后。	2026-10-24 19:43:56 +08:00
wandering1	8b0ea17b71	fix(lftpd): LIST/NLST 满块续发——大目录不再被静默截断并回 550 ... 现象：`ftp_test.py` 的 `LIST 150->226` 断言失败——1512 B 数据全收到了，完成回包却是 **550**。 **根因**（`send_list`/`send_nlst` 各一处）：定案三把"整份目录一次性批量发送"落进 static 1536 B 缓冲时，顺手留下了"装满就 `break` 并回 −1"，`cmd_list` 据此回 550。于是目录一旦超过一块，客户端 拿到的是**静默截断**的清单**外加一个错误码**——而清单看起来完全像"目录里就这些"。这比单纯报错 更危险：没有人会去数条目个数。 **台架实测（同一台设备、同一个根目录，改动前后各测一次）**： · 改前：1512 B / **24 条目** / 完成回包 **550**（停在 A0007.BIN，后面 6 个文件被吞） · 改后：1880 B / **30 条目** / 完成回包 **226** **修法：满块续发**，而不是把缓冲区加大。新增 `list_batch_flush()`——装满一块就整块发出、清空 继续装，收尾再发最后一块。为什么仍要"批量"：定案三的本体是实测结论——同一连接上背靠背 ~60 B 小段写会毒化 CH395F 的 TX（芯片报 SEND_OK 但对端全丢，无 RST 无 DISCONNECT），而 RETR 的 1 KB 满块连发安全；所以这里只发大块，绝不退回"每行一发"。单行真装不下时**明确失败**而不是少发条目 （8.3 短名 + 定长格式远小于 1536，真发生说明格式被改坏）。两条出口的 `lftpd_io_closedir` 收敛到 循环后单点：卷锁持有至 closedir，任何提前 return 都会漏锁。 **防回退**（关键）：修完之后，**目录清空的设备上这颗雷再也暴露不出来**，所以补了 `test/host/ftp_list_fill_test.py`——自造 26 个 8.3 短名文件把清单撑过一块，三条判据（STOR 全 226 ／LIST 全文里每个名字都在／完成回包 226 而非 550，用 ftplib `retrlines` 让非 2xx 完成直接抛）， 跑完逐个 DELE 还原。真机实测 `收到 56 行 / 3544 字节`（跨 3 块，满块续发被真正走到）→ 三条全 PASS。用法登记进 `docs/测试说明/FTP_Test_Guide.md` §4.5，机理与增补写进 `docs/问题记录/CH395F_Trap_Records.md` 定案三。 **顺带记录的已知偏差（未修）**：`cmd_list`/`cmd_nlst` 忽略命令参数、恒列会话 CWD （`client->directory`）。主流客户端都是 `CWD` + 裸 `LIST`，实际影响小，先记在案。 体量：`Code` 213,264 → **213,436 B（+172）**、RO 不变 → `ER_IROM1` **232,088 B（22.1%） **、 `ROM 合计` 233,276 B；**RAM 一字未动**（`RW_IRAM1` 75,264 B 57.4% / `RW_CCM` 57,376 B 87.9%）。 数字联动照做：`data/ram_report` 重跑、`ram_baseline --update/--write`、 `check_mem_numbers --write`、 FLASH 配图常量重算重生成（桶合计 = 232,088 与 `Code+RO` 相符）、报告 §1.3/§5.1/§5.4 与部署 §3.3。 门禁：`@build` 0 错 0 警告；`@test` PASS（692 ms）；`ftp_test.py` → **TEST PASSED**（含此前失败 的 `LIST 150->226`）；`ftp_up_dl_test.py` → TEST PASSED；`ftp_list_fill_test.py` → TEST PASSED； `doc-links --all` 146 文档 0 问题；`id-check --strict` 增量拦截通过（可判定 82.82%）； `mem-numbers` / `mem-budget` 通过；改动文件字节卫生 BOM 无 / CR 0 / U+FFFD 0 / 无行尾空格。未推送。	2026-10-22 22:41:31 +08:00
wandering1	506eccc68f	docs: 错误码传播审计收口并删除该文档（E-xx 转历史编号族） ... 本次会话先后销项与关闭： - E-61 SD2506 清 INTAF：原实现只读取 CTR1，而按手册 ARST=0 时读操作 不清标志，属空操作；改为读-改-写 CTR1，并按手册订正 CTR1 位宏 （INTAF/INTDF/BLF 位置，ARST 归 CTR3） - E-16 cfg_file：新增 CFG_FILE_MAX_NAME_LEN（段名/键名 ≤15），注册时 拒绝超长键名；s_gen_document 两处 snprintf 改检查式；补 TC-CFG-024 用例（主机单测 149→151 PASSED） - E-23 TC704：PHASE7_MULTI_COUNT 8→5（并发上限 = 8 − 3 个常驻监听）， accept 失败分支加网络代次检查（网络重建即重建监听） - E-26（UDP）按“保留 API + 文档定案”关闭；E-30 评估为不必要后关闭； N-4（ACCEPT 决定不实施）关闭 审计文档剩余 5 项 P2 + 2 项监督，经用户裁定“都不重要”后整体删除： - 删除 docs/问题记录/错误码传播审计.md（634 行） - 九类缺陷模式表迁入 docs/编号规范.md §4.2.1（PAT-01~09） - E-xx 转为纯历史编号族：编号规范 §4.1 属主改“无（原属主已删除）”， §4.3 保持冻结；全仓 26 处引用按“保留编号、去悬空文档名”处理 - 顺带修正 N-4 收口遗留：排期详述 C1 才是 E-25/E-27/E-28 的承载处 （审计 §4 曾误写为登记簿）；README 两处 C1 旧名改回“net 层跨上下文收口” 一并提交此前遗留的体系层评审报告 2026-10-14 复核 WIP（六维评分复核、 未闭环 Top 5→3、三区水位实测刷新）。 校验：Keil 构建 0 错误 0 警告（Code=212344）；check_doc_links --sections-strict 与 --all（142 文档）通过；内存双台账刷新后均 PASS。	2026-10-15 07:39:38 +08:00
wandering1	617c84f570	docs: 文档去阶段化——清理"自愈收敛阶段 / L3 pending / 一期二期"标签 ... 代码注释去阶段化已在 task-arch-docs-sync 分支 d770e36 落地，本次把 同一口径补到文档正文（文末变更记录行作为历史保留不动）。 - BSD 使用指南 / 函数调用关系：删 自愈收敛阶段 N、N-32 P1/P2、 L3 pending、一期二期；职责边界与实现位置改为现状口径 - CH395F_Trap_Records：TRAP-NET-17 / -21 / B10 状态行改述为现行形态 - 链路延迟测试说明：L3 pending → 挂起 recv；P0-a 阶段标签删除 - 模拟器差距清单：N-3 / N-4 / N-6 行改述（对账形态③④、无手动 relisten） - 错误码传播审计：L3 pending → 挂起 recv；"N-4 二期" → N-4 - 任务规划 README / 登记簿 N-4 / 排期详述 C1 / 基线与待确认 §2.1： 一期二期 → recv 挂起已落地 / ACCEPT pending 化（§2.1 标题同步） - CH395F_Test_Guide：阶段 15 标题去掉撞名的"自愈收敛阶段 2" - IEC104 上行设计说明：门控迁移改现状口径；"随二期" → 未登记具体条目 - 保留可检索锚点：TRAP-NET-*、E* / U* / D10、形态③④、N-4、Phase 15 门禁：check_doc_links.py --all 通过（143 文档、可判定章节引用 1282 处、 0 错 0 警）；check_mojibake 全过；CR=0、U+FFFD=0、无 BOM 变化。 本轮只改 .md，无代码改动，故不跑 @build。	2026-10-14 23:05:17 +08:00
wandering1	2a6080827d	docs(网络): 自愈架构 §4.1 形态详解 / §4.10 读即清审计 / §1.5 横向对照 ... 四块内容，都是"把已经做完的事写进文档"，无新增设计。 1. §4.1 形态表扩成 6 小节：两个所有者 / 四个词 / 形态表（补"芯片命令"列与 U11 独立行）/ 每个形态为什么长这样、怎么验的 / 为什么 ①③⑤ 常态 0 命中 / M3 可疑门与沿革。 ⚠ 修一处文档 bug：原 ④ 行实际描述的是 U11，真正的 ④ 没有行。已补 U11 独立行，并在 ⚠ 注记里记录这次更正及其 U12 后果。 2. §4.10 读即清信源审计：两个读即清寄存器与两级门控、现存读清点全量清单 （产品代码 6 处）、已根除的三条互吞实例、一处"看着像缺陷其实是配对 消费"、新增一处读清的三条准入判据 + 结构性残余。AGENTS.md 的 CH395F 单连接 socket 条目加指针。 3. §1.5 与主流 offload 驱动的代码级对照（正面回答"是不是过度设计"）： ioLibrary close()/listen() 原文、四个机制一一映射、三条约束差异表、 "死等把代价挪到运行时"、lwIP/Zephyr 对照、诚实清单（可省 16 B / 不可省 沉降窗 + D10 + listen 前排清 + 登记执行分离）、唯一杠杆是芯片。 4. 模块归属修正（承接 63cf73b 的 net_events.c 抽出）： - §11.5 新增一节，含"为什么是一个模块而不是两个"（对账真实调用事件 处理器 2 处 + NET_RECON_STABLE_DEATH 两边共用）与三处非纯搬移； - §9 行数快照更新，并加警告：这类快照**当天就会漂移**，是地图不是判据； - §1.5 的 net_listener.c 行数随注释精简同步（508/277 → 386/155）。 引用修正波及 5 个文件：BSD_Socket_API 使用指南文件职责表（拆出 net_events.c 行）、函数调用关系 §4.8 标题、Net 层阻塞模型两处形态⑤表格、 CH395F_Trap_Records 两处"对应文件"（保留"原在 net_socket.c"的历史）。 ⚠ doc-links 只校验 § 编号存在性，照不出"函数在哪个文件"——这类归属 漂移门禁不拦，必须人工扫。 验证：check_doc_links --all --sections-strict PASS（2146 处引用，可判定 1263，无法判定 0，142 文档）；ci_local L0 32 钩子 + L0.5 953/953 全过。	2026-10-14 18:18:06 +08:00
wandering1	0edbfaf08b	fix(NET): 监听重建单一所有者收口 + 沉降窗 800ms 上限只留痕 ... T0 降噪 + T1 单一所有者：四处重建触发（recon/accept/eof/drop）与 pending 第五处统一走 net_listener_request()，由 net_listener_tick 单点执行； 沉降重试日志改"只留首末"（E0 口径），每次恢复少打 3 行重复行。 force open 降级为只留痕（E19 反事实 A/B 实测）：芯片未回 CLOSED 时强行 open 注定吃 USE 错（TRAP-NET-09），放行与不放行的端口恢复时刻同一分布 （放行 +512 / 不放行 +505·533 / 降级后 +509 ms）——恢复由芯片何时回 CLOSED 决定。真正兜住"监听器永久失效"的是 D10 预算到期 + 对账形态④ 重新登记，不是放行。新增 s_relisten_capped[] 使上限留痕只打一次， 隔离标志不清 → 下一轮继续排空残渣（构建 B 实测每 30ms 两行会刷屏）。 负向注入三轮打靶（E18，注入代码不入库）：形态① 吞掉 DISCONNECT 后 4/4 救回、③ 空闲监听器静默失位两轮独立复现、⑤ 开盲区吞掉芯片自发中断 + 收回 LISTEN 后 -> resync 命中且挂起 recv 被取消 → 三条均不可降级为 只留痕。顺带稳定复现 [ERR] relisten retry budget exhausted = 对端不配合 拆链的签名，非回归。 台架：boot PASS；ftp_abort_probe RST 10/10 + FIN 5/5；relisten_stress :21 50/50（p50 507ms）；n30_repro 30/30。构建 0 错 0 警 Code=212316； netTask 静态最坏链 1920→1912 B；RAM 台账受管区已 --write 同步（RW +8B）。 文档：E17/E18/E19 三行 + §4.1 常态 0 命中归因 + §4.3 兜底归属改正； 登记簿 N-31 销项（结论沉淀进 §4.3 与 E19）。	2026-10-14 15:57:10 +08:00
wandering1	f849c79b7a	feat(NET): SEND pending 二期落地 + 末块挂起越界缺陷修复（台架复测闭环） ... net_pending.c/h 增设第二张挂起表 s_net_send[]（与 recv 表完全独立，收发 互不阻塞）；net_send_locked 快速路径改为有界自旋，单次等待超出 NET_SEND_SPIN_MS(2ms) 即登记挂起 send，由 net_send_pending_tick 按主循环 节拍分块推进，netTask 最坏停滞由 1s 压到 2ms。net_listener_retry_tick 的 挂起保险扩展到 send 侧；net_close_locked / 网络重建 / 状态对账三路均先 取消再动作（取消必通知，调用方永不挂死）。 台架复测（A/B 对照 + 插桩定位）发现并修复末块挂起越界缺陷：内层"等本块 发完(SENBUF_FREE)"位于写块之后，写完末块时 sent 已 == len，若该次等待越过 2ms 预算便会调用 net_send_pending_register，而登记函数按 sent >= len 拒收 并回 -1，把一次实际已完整交付芯片的发送报成失败。修复为内层等待开头判 sent >= len 即跳出（末块已交付、SENBUF_FREE 等待是纯保守自旋），并置于 超时/自旋判定之前；该守卫同时保证后续登记必伴随 sent < len。 复验：ftp_regression 连续 19 次 11/11；ftp_integrity_test 20 轮 x 64KB STOR/RETR SHA-256 20/20 一致（两轮），吞吐稳定约 80KB/s；设备日志零 write error；ST-LINK 回读 No difference found。 文档：Net层阻塞模型架构设计.md 补二期设计与新增 9.1 缺陷记录，netTask 栈实测峰值按本次台架 920B 订正为 1116/3840（FTP 传输期 1164）；网络自愈 架构设计.md 吸收原监听生命周期文档、新增编号术语导读表，并把 5.2 "实验锚点速查"的 E 编号含义与 E-02 审计编号歧义写在表头（用户反馈该表 E 编号无法读懂）。 门禁：Keil 0 错 0 警；cppcheck / 编码规范 / 乱码零告警； check_mem_numbers PASS；check_doc_links --all --sections-strict 142 篇 PASS。	2026-10-14 12:05:21 +08:00
wandering1	df13dec479	refactor(net): 挂起 recv 模型拆出 net_pending.c/h + 留痕探针编译门控 + E15 归因修正 ... - E15 归因修正：幽灵状态 0x04+旧端口 = 芯片如实报告拆除中的旧连接 （文档化行为，非芯片故障；bit3=1 为我方设置（ver>=0x46）、 RFC 9293 §3.3.2 Fig5 拆除顺序、WCH 官方博客方案 = close 完成后重开监听） - 术语统一：全库"了结"→"结束"（约 45 处）；阻塞模型 §4 首次出现处定义"五路" - 注释清理：删孤儿函数头注释、考古叙事改现在时、去不可检索内部编码"L3" （33 处 6 文件）、banner 去重（唯一理由移到分支现场） - 挂起超时留痕探针：编译期开关 NET_PENDING_TRIPWIRE（默认 0 = 编译剔除， 省约 150B Flash；排查调用方挂死时置 1，只留痕绝不强制结束） - 拆模块：net_pending.c/h（363/94 行）承载挂起 recv 模型， net_socket.c 4059→3661 行；tick 收控制块表参数、settle_close 双参显式传； net_pending_active 声明移配对头（S17 2.2）；仅注册 uvprojx + check_registration MCU-only 白名单（同 net_listener.c 机制， 模拟器走 net_socket_sim.c 按外部语义模拟） - 文档：阻塞模型新增全过程小节（单主干流程图）+ §9 排查辅助； NET README / 函数调用关系 / 自愈架构 / BSD 指南同步；引用关系图重生成 - 台架回归：启动闭环 PASS（[ERR]/Fault 零命中、回读一致）、 :7003 重连探针 10/10、FTP 50 连接 STOR 50/50、回归窗口串口日志无异常 - RAM：ER_IROM1 230004B（探针门控后约 -150B），台账已回填	2026-10-14 09:53:38 +08:00
wandering1	a12367981d	fix(N34): E14 丢中断复核——芯片不丢事件；listen 排事件挪至 LISTEN 前+全局读收口+全库归因更正 ... 48 轮直读 SINT 矩阵（8 周期×6 变体）复核历史"丢中断"说法：芯片侧事件 丢失 = 0。归类：drain 读清消费 3/48（drain-int 探针现场抓获）、门控 竞态 2/48、主机同步 1/48、幽灵态 0/48 未复现。 根除性修复：net_listen_locked / net_listener_try 的排事件读清从 listen 后挪至 LISTEN 命令之前——新连接 CONNECT 落进该窗即被本方读清 吞掉，即"数据被吞"的生产侧自伤机制（台架 3/48 为同形态放大版）。 全局读收口：全局中断寄存器唯一读者 = net_poll（I7）；生产/测试/台架 游离全局读全部删除，ch395f.h 声明处加护栏注释。 归因更正：17 文件约 40 处"丢中断"措辞改为"事件未收到/读清消费竞态" （机制全部保留，仅归因更正）；设计文档 §5.2 新增 E14 锚点；Trap Records TRAP-NET-17/-20/B3 归因更正段；配图生成器与 SVG 重生成。 台架：事件未收到复核探针保留（drain-int / SINT 补读×3 / 超时归类）， 下次跑矩阵自动归类；实验注册（main.c/uvprojx）已完全还原。 验证：@build 0 错误 0 警告；ci_local L0 32/0 + gitlint + L0.5 953/953；doc-links --all --sections-strict 通过；@test PASS（无 [ERR]，net init 619ms）；回归 :7003 300ms×10 = 10/10、:21 n30×50 = 0/50 失败。	2026-10-14 02:48:50 +08:00
wandering1	1a35b3684c	docs(N34): 自愈审计目录 7 份文档合并为单文档，全库引用同步 ... - `docs/网络/N34-自愈审计/` 目录 7 份文档（根因总览 / net 层盘点 / 驱动层审计 / 主流对照 / 汇总裁决 / 实施方案 / 实验方案）合并为 `docs/网络/N34-自愈审计.md`（§0~§6），原目录删除；docs/README.md 索引与变更日志登记归档 - 全库引用同步：4 篇文档 + 驱动/NET/test 代码注释 + 配图生成器与 SVG - 内容零丢失抽查：E0~E13 实验记录、E6 裁决（命中=0 不立项）、 提交表（含 `925058a` 收口行）均在位 - 门禁：@build 0/0（注释级路径更新）；check_doc_links --all 143 文档 通过（净 −6 = 删 7 增 1 吻合）；ci_local L0+L0.5 全绿	2026-10-13 23:23:55 +08:00
wandering1	925058a5ae	fix(NET)+docs: lftpd 对端地址修复、E6 裁决收口、陷阱编号迁移重排 TRAP-NET-01~21 ... - lftpd：net_inet_ntoa 段序改 MSB 首 + 新增 net_getpeername，FTP 日志打印 真实对端地址（真机实证 192.168.1.2:55524，登记 TRAP-NET-21） - E6：NET_U15_PROBE 命中=0（含压测）→ 阶段 3 项 4 不立项，U15 登记观察项； 插桩留仓（宏=0 零成本），soak 驱动 test/host/e6_soak.py 入库 - 编号：全库 Trap NN → TRAP-NET-<nn> 迁移并重排连续 01~21（单调映射， 沿革见 CH395F_Trap_Records.md 头注）；死号 12/13/19/21 引用全部清除； GD5F 域引用补正为 TRAP-GD5F-NN - 陷阱文档全新化：索引 21 行行行真陷阱；删误判存档/发现时间/git 考古/ FTP 附录；台架纪律教训沉淀第六章方法论 - RAM：Code 211348→211456（+108 lftpd 修复），RW+ZI 净增 +4B； 优化方案/台账受管区/tsv 同笔同步 - ftp_abort_probe.py 挪 test/host/；引用关系图重生成 - 回归：@build 0/0；@test PASS；ftp_abort 10/10；relisten :7003 20/20； ci_local L0+L0.5 全绿；E6 窗口零复位，7 条 WD stall 登记压测假象备查	2026-10-13 20:54:31 +08:00
wandering1	74ba7ea61b	docs(问题记录): Trap 12 归档更正——FatFS 议题移入存储架构说明 §10.1 ... - Trap 12 非 CH395F 议题（`CH395F驱动层审计.md` 早已点破；重组时仅就地 更正未搬家，本次补正） - 完整内容与根因更正移入 `docs/架构设计/STM32F4-Base存储架构说明.md` §10.1 第 14 项——与第 10 项「严格 8.3 短名」通用规则同处，各得其所 - 原址留移档存根（编号保留防旧引用断链，同 Trap 19 惯例）；索引行改 ↦、状态图例补「↦ 已移入他档」；待修清单措辞同步 - 全库确认 Trap 12 无代码引用；check_doc_links 两文件通过	2026-10-13 17:28:53 +08:00
wandering1	b445cbb464	docs(问题记录): CH395F Trap_Records 重组审计——合并、删误判、主题分章 ... - 合并同根因：Trap 14+17（残留 DISCONNECT 污染下一连接）、Trap 13+21 （recv_len 归零/接收冻结家族，非缺陷结案）；FTP 改造清单表去重入附录 B - 删当时误判叙述（各留一行误判存档）：Trap 07 FIN_WAIT_2/RST 说、 Trap 18 bit0 迷思、Trap 25「芯片杀连接」解读；B1 KeepAlive 三段翻转 合并为定案链（E11 转正） - 规范化：顶部索引表+状态图例；六主题章+附录 A 速查/附录 B 存档； 条目统一「状态/现象/根因（定案）/修复/回归判据/教训」格式 - 状态刷新：B5 对端 IP 显示已修（代码随收尾批提交）、B10 标 net_drop_conn 根治出口；Trap 17/20 措辞、Trap 12 根因（按 ff.c）、日期口径就地更正 - 编号永不重排（代码注释 123 处引用）；跨文件断链 1 处改条目名引用 （生命周期设计说明 §877-878 → Trap 25「定案二」） - 体量 1018 行/102KB → 420 行/64KB；doc-links 两文件通过	2026-10-13 17:12:57 +08:00
wandering1	f51c0833ae	docs(N34): 阶段3 文档同步——reconciler 合并口径+net_drop_conn+Trap 补充 ... - BSD_Socket_API_使用指南：五层自愈→四层（合一 reconciler 形态①~⑤+U11， 分级去抖②1/③④⑤2/①4轮+1s冷却）；新增 net_drop_conn 小节（拆会话保 监听/幂等/EOF 不得调）；变更记录追加 2026-10-13 行 - BSD_Socket_API_函数调用关系：pump 节点删除、net_drop_conn 链路新增、 驱动接口表补 sock_reset/cmd_done/缓存行、常量清单更正 - 网络Socket监听生命周期设计说明：新增 §10.10 合并说明，历史文本保留+注记 - Net层阻塞模型架构设计：主循环 3 tick 口径 + 附录 B 追加 - RAM使用分析与优化方案：netTask 链尾改 retry_tick→relisten（1944 B 不变） - CH395F_Trap_Records：Trap 07 补充（close 无 RST：对端内核存活不 close → FIN_WAIT_2 长尾，兜底 E13）；Trap 09 补充（LISTEN 态二段关闭） - 实施方案 §5：项1/2/3/5 ✅、项4 受 E6 暂缓、§5.1 E-02 收口、§5.2 延后项 - 实验方案：E-02 收口台架小节（FIN_WAIT_2/TIME_WAIT ~150ms/双 PASS） - N34 README 裁决行更正；Test_Guide TC-NET-1101 pump→reconciler 形态③④ 历史变更记录与历史事故描述一律原文保留、只追加；check_doc_links --sections-strict 对改动文件 0 问题；乱码 0、无 BOM 变化。	2026-10-13 15:10:54 +08:00
wandering1	13a4a40a14	feat(net): 服务器侧 KeepAlive 转正（§5.56，E11）+ Phase 11 重开回归 ... E11（d96113b）证据链："链路在、对端静默"注入下生产参数 60/5/3 实测 判死 ≈30s → TIM_OUT → QUARANTINE → pump 重建；静默但存活对端不误杀。 handle_connect_event LISTENING 分支按手册规定位置开启；反汇编确认 编译器把两分支尾部合并（LISTENING 跳入含 keepalive+fire_event 的公共 尾部，hex 全片仅该分支偏移 1 行差异，Code 尺寸不变属填充巧合）。 Phase 11 重开时发现其拉入 32KB s_rx_buf 超产品 RAM 余量（L6406E 链接 失败）→ 改专用 64B 探针缓冲（本 Phase 仅 64B 探针读，门控注释已留 "勿加回"警示），套件恢复 0 错 0 警；TC-NET-1101 步骤同步死对端注入法 （禁用网卡；Windows 防火墙规则对已建立连接无效，E11 实证）。 验证：产品/套件双构建 0 错 0 警 + 反汇编确认调用落地；台架确认 （:7003 静默对端判死 + Phase 11 实跑）待设备冷启动断电重上电后补做。	2026-10-13 09:25:06 +08:00
wandering1	d96113bcc4	docs(net): N34 E11/E12 实验记录与台架脚本（KeepAlive 服务器侧缺口、TSL 规格偏离） ... E11：服务器侧 KeepAlive 未开启（静态证据链 + 注入手段两次修正 + 实测 生产参数 30.0s 判死、空闲存活会话不误杀），给出采纳建议；防火墙规则 对已建立连接无效、有效注入 = 禁用 PC 网卡，两条方法学留痕。 E12：缓存区读写路径长度→数据零间隔属规格偏离（读 0.4us/写 0.2us）， 但 460 轮/约 58MB 字节级校验未测得可复现危害；依 Trap 25 登记偏离、 B 变体（两段+TSL，+28B，吞吐无回退）留作待用补丁。 残渣风暴态跨烧录存活污染 A/B 连接级对比，教训写入 E12：实验前后必须 冷启动（断电重上电），MCU 覆写烧录/RESET_ALL 不足以清除。 新增 test/host/e11_keepalive_probe.py（idle/block 两模式 + 注入正对照） 与 test/host/ftp_integrity_test.py（STOR→RETR 全量 SHA-256 比对， 建议纳入常备回归集）。	2026-10-13 09:10:17 +08:00
wandering1	d3107f374f	docs: 待处理内容.md 解耦为 docs/任务规划/ 文件夹（README 排序权威 + 6 个职责单一文件） ... - rename_ref.py 搬迁：git mv + 全库引用改写 33 文件 82 处 - README.md 保留 §0 编号空间 / §1 未闭环一览 / §2 推进顺序权威 / §3 维护约定 - 拆出 6 文件：W1-采集保护收尾（任务卡五字段）、排期详述、暂缓-RS485、 登记簿、测试与架构专项、基线与待确认 - 外部引用重定位 ~50 处：裸「登记簿 §X」、§5.1→基线与待确认 §2.1、 §2.4→暂缓-RS485、§6→基线与待确认 §3、脚本注释 T-x/N-x→登记簿 - 新增并行写纪律：任务分支不改本文件夹，状态列由 Lead 主工作树更新 - 验证：doc-links 141 文档全绿；mem-numbers 一致；refgraph 重生成； @build 0 错误 0 警告；新文件无 BOM / LF / 零乱码	2026-10-12 13:42:47 +08:00
wandering1	09f8a6fb20	docs(net): 监听生命周期根治设计——证据、决策与执行清单 ... 新增 docs/子系统设计/网络Socket监听生命周期设计说明.md（9 节）： 原理三层证据——芯片层：LISTEN 与 ESTABLISHED 是同一 TCP 状态字节的互斥 取值（手册 §5.22 L535-545、§5.29 L609「直到连接成功后」），全手册无任何 "连接结束自动恢复监听"条款；且本仓 fun_para=0x08（bit3 SOCKET_CLOSE=1， Trap 18/25 定案）使断开后芯片停在 0x05/0x00，即 B10 看到的"孤儿芯片态" 是本仓配置的合法后果，而非芯片异常。规范层：RFC 1122 §4.2.2.18 明文被动 OPEN MUST NOT affect any previously created connection record，POSIX accept() 原文 socket 不变，lwIP 把监听器所有权写进 tcp_close() 文档—— 本仓需要靠"EOF 不得 close 监听 fd"铁律维持正确性，即架构欠债的凭证。 实现层：EOF 是时序敏感边沿（只在 recv 那一刻 state==CLOSED 才给），导致 重建所有者散成 12 个（栈内 8 + 应用 4）、15 个迁移点、15 个无人负责组合。 关键决定 D1~D7：不启用芯片原生多连接模式（A′ 出局——FTP 改造清单第 4 条 已定案"多连接模式不支持多监听"，本产品有 21/8888/7003 三个常驻监听加会 话期动态 PASV，且历史上踩过 Trap 02/11，FUN_PARA 初始化后不可改）；采用 "会话结束电平化 + 监听重建单一所有者"的形态 B 深化，不做控制面重写；对 账④保留不撤回（Trap 22 实证事件会丢，周期对账不可删），其副作用由 P1 消除；fun_para 保持 0x08，不回退 Trap 25 的排空契约。 证据附录含 B10 探针日志、A/B 归因数据（基线 5/1/1/5 vs B3 3/7/2/1，均值 3.0 vs 3.25，统计不可区分）、④ 修复后完整回归矩阵、官方 EXAM5/EXAM10 所 有权模型（SDK 行号）、状态机 15 迁移点与关键判据、三服务契约不一致表。 Trap_Records B10 残余改写为指向该文档，并明确记录 ④ 的副作用：抢先 relisten 会把慢消费者的 EOF 永久吞掉，g_client 不清、新客户端数据被旧会 话静默吸收——④ 修好了端口拒连却撑大了另一侧窗口，P1 必须补。 登记行 N-32 已写入 docs/待处理内容.md 工作区，但该文件与并发在途的 N-27 改动混杂，本次不提交，留待其归属方一并入库。	2026-10-12 11:17:48 +08:00
wandering1	4f2cc8bc90	fix(net): B3 只清本 Socket 中断；B10 对账认领孤儿监听修永久拒连 ... B3（net_listen_locked / net_relisten_locked 两处）： 原先对全部 8 个 Socket 做 GET_INT_STATUS_SN（读即清）并丢弃式读全局中断 状态。依据三条：§5.15 明文全局寄存器整体读即清且无按位清除手段；net_poll 只在全局位置位时才读该 Socket 的 SINT（位图门控）；SINT 粘滞到被读 （Trap 14 实证 close/open 都不清）→ 读走即永久销毁其它在用 Socket 的 CONNECT/DISCONNECT/TIM_OUT/SENBUF_FREE。git 考古定性为多连接时代调试遗留 （e862009bc → 319d00e3 → db64e6acf），不属于任何已登记 Trap 的修复；官方 SDK 21 个例程一律"位图门控 + 单 Socket 读 + 立刻转存"，open/listen 前后 不清任何中断，无一例全量读 8 个 SINT。现收窄为只清本 Socket 的 SINT， 全局交 net_poll 集中读清，与 AGENTS 模块约定一致。 B10（孤儿监听 → 端口永久拒连）： 断开时 handle_disconnect_event 释放分支置 CLOSED 并注释"等待应用重新监 听"，而 ui_net_sink 只在 net_recv 返 0（EOF）时才清 g_client，EOF 已被该 事件分支消费 → net 层等应用、应用等 EOF、对账只裁 ESTABLISHED/LISTENING 直接跳过、芯片不会自己回 LISTEN，四方互等。实测孤儿态 state=0 / chip=0x05/0x00 持续 12s+，:7003 300ms×10 为 0/10 且 +30s 仍拒连。 net_reconcile_tick 新增类型④认领孤儿，复用 net_relisten_try（自带"已在 重试队列不重复登记"保护，与 D10 队列、Trap 23 沉降隔离兼容）。门槛中 auto_relisten 是决定性一条：缺它则出向连接（板级 Phase 7 TC701~703 绑本 地口）会被误判孤儿并被 relisten 成监听器。 工具：ftp_abort_probe.py 仍用 anonymous 登录，N-19 后 530 拒 → Trap 23 两 条腿假 0/5（round1 PASV failed，且半认证会话占死 FTP 唯一会话）。改 admin/admin 后 RST 5/5、FIN 5/5。 回归：:7003 300ms×10 由 0/10 永久死 → 10/10（+20s 存活）；:21 0ms×50 与 100ms×50 均 50/50；:8888 0ms×20 为 20/20；ftp_regression 11/11×2；Trap 23 RST 5/5、FIN 5/5；@test PASS（600ms、回读无差异）；@build 0/0， Code=197084。 残余：B10 生产者未根治，释放分支仍把状态停在 CLOSED 等应用重建，类型④ 是兜底；根治涉及 Trap 25 closed-with-data 契约，单列评估。	2026-10-12 10:35:55 +08:00
wandering1	794a688a3c	fix(net): B2 不再丢弃 TCP_CONNECT 命令状态，命令级被拒立即回滚返 -1 ... 问题：net_connect_locked() 调 ch395f_tcp_connect() 后直接丢弃返回值， 而同函数内 open/listen 都查了状态。§9.2.2 ⑧ 明文：发完 CMD_TCP_CONNECT_SN 后须轮询 GET_CMD_STATUS，返回 SUCCESS 仅表示 **命令**执行成功（不代表 TCP 连接成功），其他值表示命令执行失败。 丢弃它 = 命令级被拒时本层停在 CONNECTING，要等 30 s recv 超时才暴露。 修法（不能一刀切）：只拦"非 SUCCESS 且非 BUSY"。因为 ch395f_poll_cmd_status() 超时返回的就是 CH395F_ERR_BUSY（= 4 s 内 芯片仍在执行，命令并未被拒绝），把它当失败会误杀慢芯片。明确失败 → 打 [ERR] rejected by chip: 0xNN 留痕 + 按 §9.2.2 ⑧"再次连接需从 ⑤ 重开"关掉 Socket、状态回滚 CLOSED、返 -1（NET_ERR_INVAL）。 顺带修一处错注释：原写"发起 TCP 连接（异步：芯片立即返回）"，实际 驱动内部已按 §9.2.2 ⑧ 轮询 GET_CMD_STATUS 最多 4 s，并非立即返回。 硬件回归（Phase 7，NET 层 TCP Client 主动连接）： - TC701 连接 + 64 B 回显逐字节比对 PASS（cksum=0x000007E0） - TC702 关闭重连 x3 全 PASS → 正常连接路径无误杀 - 不可达对端时芯片回的是 SUCCESS、ret=0 且不打 rejected by chip → 失败仍由 CONNECT TIMEOUT(~1.6 s) 裁定，行为未变；新分支只在 芯片明确说"命令执行失败"时才走 - TC704 socket create #5 FAIL = E-23 既有（NET_MAX_SOCKETS=8 减 3 个常驻监听 → 并发上限 5，而 PHASE7_MULTI_COUNT 仍是 8），与本次无关 - TC703 要求 PC 服务器离线，与 701/702/704 环境互斥，同轮连跑必有 一侧失真；其 rc==0 断言等于把"返回值被丢弃"写进判据，真发生命令 级被拒时它会 FAIL（属正确告警） 前两轮 Phase 7 全灭不是改动问题，已登记为台架坑：本机对 C:\programdata\anaconda3\python.exe 有两条 Public 入站 Block 规则， 而 .venv 的基座解释器正是 Anaconda python；Windows 防火墙块规则优先 于放行规则，故中途加的 8081 端口级 Allow 完全无效，只有临时关 Public 才通。症状极具误导性（芯片 1.6 s 报 CONNECT TIMEOUT、net_connect 仍 返 0、openOK 照常打印），看着像芯片/驱动故障。 残余（登记未动）：net_reconcile_tick 仍只裁 ESTABLISHED/LISTENING， CONNECTING 丢中断无人收口——产品不走出向连接、无法实测，按 Trap 25 "不加未证明的复杂度"只登记不实现。 验证：构建 0 错 0 警、Code=197032；内存快照已刷新；doc-links EXIT=0、 无 U+FFFD；@test 闭环 PASS（戳 fw build: Oct 12 2026 08:03:29 suite=NONE、回读无差异、548 ms）。测试宏已复原，两个测试头文件与 HEAD 字节一致；临时防火墙规则已删除、Public 已重新启用。	2026-10-12 08:17:36 +08:00
wandering1	9a45be1700	docs(net-audit): B1 服务器侧 KeepAlive 前提被实测推翻，撤回改动并记台架注入陷阱 ... B1 原判"产品路径从未启用 Socket KeepAlive → 静默断开无人知晓"（§5.56 要求 TCP 服务器在产生 SINT_STAT_CONNECT 后开启，产品三服务全是 Server，60s/5s/3 参数空转）。本轮按 §5.56 在 LISTENING→ESTABLISHED 分支补了 ch395f_set_keepalive_enable() 并上板做定案实验，结果推翻前提。 实测：连接静置时禁用 PC 网卡（真·静默死亡），芯片 +2 s 即报 "[ERR][NET] sock0 TIMEOUT" → 本层 relisten quarantine 释放重开监听。 2 s 只能是重传（§5.17 本仓 8×200 ms = 1.6 s 量级），与 KeepAlive 无 关——IDLE 最短 60 s、芯片默认也要 20 s。链路层失效本就被快速覆盖， 故依 Trap 25 铁律「不留未证明的复杂度」撤回该改动，只在代码内留注释 记录（含未覆盖场景与注入难点），不保留无证据的动作。 另一半天真：设备 2 s 就重开监听，PC 侧那条 socket 却继续"自认存活" 直到 4 分钟后自行 close（Python 对死链路 close() 不报错）。不对称恢复 才是现场隐患——客户端下次写会吃到 §5.29 的 RESET；单靠设备侧开 KeepAlive 只解决设备这一半。 新增「台架注入陷阱（2026-10-12）」四条（本轮踩到的，全部实测）： 1. Windows 出站防火墙规则不能模拟"对端静默死亡"——WFP 对已建立的流 有状态缓存，中途加 Block 不影响既有连接；实测静置+阻断 250 s 芯片 毫无反应，看着像"KeepAlive 不生效"，实则 ACK 一直正常往返。 2. 该规则还会吃掉本机后发的 FIN → 设备留下幽灵 ESTABLISHED，之后新 连接被 §5.29"向试图连接的远端发送 TCP RESET"直接 RST，表现为"端口 拒连"，极易误判成设备故障（实为自伤，撤规则后自愈）。 3. 真正掐断链路用 Disable-NetAdapter；本机该 cmdlet 只有 -Name / -InterfaceDescription，没有 -InterfaceIndex/-ifIndex（第一次写错 导致那轮网卡根本没关）。网卡名是中文，用 (Get-NetAdapter -InterfaceIndex 19).Name 取值再传，避免命令行写中文； 禁用/恢复必须写在 try/finally 里。 4. 仍未覆盖："链路仍在、对端静默"（NAT 会话过期、中间节点黑洞）才是 服务器侧 KeepAlive 唯一可能的价值场景，本机无安全注入手段（静态 ARP 黑洞会被交换机泛洪兜底、删 IP 会连带拆掉本机连接）——未证实， 故不保留改动。 判读教训（与 Trap 25 同源）：看到 TIMEOUT 先算时序再归因，2 s 与 60 s 一眼可分；否则会把重传超时误记成"KeepAlive 生效"，把相关性当因果。 验证：构建 0 错 0 警、Code=196912（与 afb0bfd 一致，说明撤回后二进制 回到已提交状态）；doc-links EXIT=0、Trap_Records 无 U+FFFD 无 BOM； @test 闭环 PASS（回读无差异 + forbidden 三项与 [ERR] 全缺席 + 594 ms）。	2026-10-12 07:49:58 +08:00
wandering1	afb0bfd5ff	fix(net-audit): 修 6 处寄存器口径/注释错误 + Trap 记录全量复核与审计章节 ... 智能体团队四路并行只读审计（驱动层逐命令 / NET+测试层逐调用点 / Trap 01-12 复核 / Trap 13-25 复核），三源交叉：芯片手册 + WCH 官方 SDK（CH395CMD.c / CH395INC.H / 21 个例程）+ git 历史。本提交只落 "已确认且低风险"的修法，其余发现登记进文末审计章节待逐项决策。 已修（A 类，全部有手册/SDK 出处）： A1 测试 TC-203 反核实写成 st_chk[0]==CH395F_TCP_ESTABLISHED——§5.22 byte0 只有 00H/05H，条件恒假，这道 Trap 14 防线自写下起从未生效 且日志无痕（与 Trap 07 同类的 byte0/byte1 语义越界）。改为 byte0==OPEN && byte1==ESTABLISHED。 A2 测试 Phase3/4 把 GET_RECV_LEN 返回值直接当读取长度（本地 rx_buf[300]/[64]，芯片 RX 缓冲 2KB）→ 栈溢出；补夹取 + 留痕 （同文件 TC201/202/204 早已 clamp，这两处是漏）。 A3 CH395F_GINT_STAT_DHCPV6 由 0x8000(bit15) 改 0x1000：SDK 是 (1<<12)、§5.16 明确 CH395F 的 [12:15] 保留。全仓零引用。 A4 ch395f.h 命令分组注释字节数错 4 处（GET_GLOB_INT_STATUS_ALL / GET_UNREACH_IPPT 归"1 字节输出"、SET_FUN_PARA 归"1 入 1 出"、 SET_RETRAN_PERIOD 归"3 字节输入"、GET_SOCKET_STATUS_SN 归"1 字节 输出"）；KeepAlive 参数注释"秒"改"毫秒"（§5.53/5.54 单位 ms）； set_retrans_count 删"0=默认值5"（§5.17 默认 12、无 0=默认语义）。 实现全对、注释误导——Trap 25 的 1 字节缓冲栈越界正是这类注释发起。 A5 net_socket.c 六处注释与手册/HEAD 相反：FUN_PARA(SOCKET_CLOSE=0) 实为 bit3=1（正是 closed-with-data accept 的契约依据，写反会诱导 把 0x08 改回去）、"初始化成功后设置 MAC"（§9.2.1 ① 是之前）、 "复用默认缓冲"（net_init 已为 8 Socket 显式分配）、"由 MSS 推导" （固定布局、Trap 21 已解耦）、"等 SEND_OK"（门控是 SENBUF_FREE）、 UDP 头 [0-1] reserved（§9.2.4 是数据长度）。 A6 ch395f.c write_send_buf 超限静默 return（void 无日志），且上限取 DMA 2048 而非发送缓冲 1024；读路径有 OVERSIZE 金丝雀、写路径没有 → 补 [ERR] 留痕 + >1KB 告警，行为不变（分块责任仍在调用方）。 审计确认"不是 bug"的最危险一项：GET_GLOB_INT_STATUS_ALL 拼装方向。 我们"第1字节|第2字节<<8"与官方 CH395CMDGetGlobIntStatus() 逐字相同， glob & (1<<(sock+4)) = §5.16 bit4..bit11 = SDK GINT_STAT_SOCKn，三源 一致。另 55 条命令码、9 处 16 位字节序、14 条读命令字节数、60 个 常量、12 个单位参数点、48 块缓冲布局逐条核对无异常；17 处 get_socket_status 调用点全是 st[2]，Trap 25 的 1 字节 bug 无残留。 文档：Trap_Records 加文末「2026-10-11 寄存器/数值口径全量审计」章节 （干净清单计数 + 15 条新发现含已修/待修 + 文档待修清单）。就地修正： Trap 07 定案更正里"全文 RST 仅见于错误码与引脚"的绝对表述（§5.29 / §9.2.6 其实写了芯片发 TCP RESET，只是都与 close 无关）+ 删不可核验的 "11 个悬空提交"；Trap 16 的"IP/端口寄存器大端"（端口 §5.25/5.26 明确 低字节在前）+ 注明 §5.8 总括与官方例程自相矛盾；Trap 18 删悬空 "Trap 19"（该条从未存在）、net_socket() 改 net_bind()；速查清单 DMA 1500 改 2052；Trap 13 加复核注（最高优先级：其"部分读后 recv_len 归零"与 §5.34 直接相左、与本仓 TC201 注释相反，且同族结论已被 Trap 21 撤回，却仍被 6 处当现行约束引用）；Test_Guide 的 TRAP-07 行仍教 "卡 FIN_WAIT_2 / close(RST)"、悬空的 Trap 19 与两处"见风险 #N"。 待修（B 类，登记未动，需逐项决策与实测）：B1 产品路径从未启用 Socket KeepAlive（唯一调用点在 client 分支，产品三服务全是 TCP Server， §5.56 要求服务器在 CONNECT 后开，60s/5s/3 参数空转）；B2 tcp_connect 返回值丢弃且 CONNECTING 不在对账范围；B3 net_listen_locked 全 8 Socket 读即清会吞别槽事件；B4 全局中断 bit0-3 从不消费、get_unreach_info 零 调用；B5 getsockname 的 s_addr 与本层约定相反致 FTP 日志设备 IP 反序 （PASV 双重反转恰好正确，勿误判）；B6 三处判据只看 byte1 未按 byte0 门控；B7 Phase5 单次写 4093B；B8 Phase4 缓冲块与 sock4 交叠；B9 杂项。 验证：产品构建 0 错 0 警、Code=196912（+124B，写路径两条新日志）； 测试路径（PHASE2/3/4 打开）单独编译 0/0；内存快照已刷新；doc-links EXIT=0、无 U+FFFD、pre-commit 全绿；@test 闭环 PASS（戳匹配 + 回读无 差异 + 锚点 x1 + 548ms）。	2026-10-12 00:20:17 +08:00
wandering1	bca6cc694c	test(net): TC-NET-204 定案 Trap 07——disconnect→close 不卡死，真因是 bit3 ... Trap 07（2026-07-19 写成"2025-07"）断言"disconnect→close 让 Socket 卡 FIN_WAIT_2 数分钟、因为 close 不发 RST"。新增定案用例 TC-NET-204（Phase 2 硬件层，同一 Socket、同一 PC 回显、FUN_PARA=0x08，三模式 × 5 轮 = 45 项判定 全过）做受控对照，实测推翻其机制说法、保留其做法： A close → 回 CLOSED 0/0/150/0/0 ms，重开 5/5 OK B disconnect → close → 全部 +0 ms，重开 5/5 OK（"卡死"未出现） C disconnect（不 close）→ 10 s 内从未回 CLOSED，byte0 恒 0x05、byte1 0x00； 直接 open → 0x20 FAIL（5/5），补 close 后 +0 ms 三条推翻：① FIN_WAIT_2(06H) 全程未出现（15 轮 × 9 采样点），实测过渡态只有 TIME_WAIT(0AH)；② 手册无 RST 语义（§5.35 只说 close 前自动断链），且主动发 FIN 先进 FIN_WAIT_1 才进 FIN_WAIT_2，原说法跳拍；③ 观测越过了 byte1 的语义 边界——§5.22 byte0 只有 00H/05H，官方 SDK 注释明确 byte1 仅在 byte0=OPEN 时 有意义，而当年代码判据用的是正确的 byte0，break 后照样打印 byte1，于是"已 CLOSED 下的残留读数"被读成"卡在某个 TCP 态"。 真因：FUN_PARA bit3 SOCKET_CLOSE=1（§5.52 ②）下产生 DISCONNECT 后芯片不关 Socket、不清缓冲，Socket 停在 0x05(OPEN)/0x00(TCP_CLOSED)，此时 open_socket 必返 0x20 FAIL——即历史那条 Phase 2 open_socket: 0x20 / socket 未完全关闭。 拉回 CLOSED 的动作是 close，与 RST 无关。 git 佐证：ch395f_tcp_disconnect() 自首个提交起只有定义、零调用点（含全部分支 与 11 个悬空提交），"disconnect→close" 从未进入提交代码；当时驱动已轮询 GET_CMD_STATUS（4 s 上限），也不是"命令没等完成"。 做法保留，理由换成三条有支撑的：§5.35 close 已自动断链故 disconnect 多余； disconnect 制造的 DISCONNECT 事件在 bit3=1 下须我方消费/预清（Trap 14/17/22）； 它把芯片推进 closing 过渡态、重开需沉降（Trap 09）。本轮 15 轮重开均未观察到 残留 DISCONNECT(0x10)——close 顺带清掉锁存，这才是"直接 close"安全的原因。 另消解 Trap 17 与 Trap 07 的旧矛盾：实测支持 Trap 17（close 走 FIN teardown、 0~150 ms 可见 TIME_WAIT），不支持 RST 说法。 文档：Trap_Records.md 加 Trap 07「定案更正」整节 + 改写「驱动关键点 → TCP 关闭 重连」速查清单（删 RST 说法、补 byte0/byte1 口径与 0x20 陷阱）；Test_Guide.md 新增 TC-NET-204 用例表（前置含 tcp_server --timeout 900 这条坑：首连后连接 间隔 >60 s 服务器会自行退出）。 验证：测试构建 0 错 0 警、Phase 2 74/75（唯一 FAIL 是 TC-203 环境守卫，PC 服务 未及时关闭）；宏已还原，产品构建 Code=196788 与 HEAD 一致（用例全在测试宏内、 产品零足迹），@test 闭环 PASS（戳匹配 + 回读无差异 + 锚点 x1 + 590 ms）。 pre-commit 全绿（test-cppcheck / doc-links / no-mojibake 均 Passed）。	2026-10-11 21:40:45 +08:00
wandering1	b8619a0984	docs(net): N-31 销项——0x08 下多 Socket 实测 34/34，补台架前置排雷 ... N-31（0x08 下的多 Socket 台架复测）已闭环并销项。 实测（2026-10-11 20:18，板端 CH395F ver=0x4A，日志 fun_para=0x08）： - 构建：TEST_SUITE_CH395F + ENABLE_PHASE7_TESTS，PHASE7_MULTI_COUNT=5 （E-23 未修：NET_MAX_SOCKETS=8 减去 FTP/对时/远显三个常驻监听） - PC 侧：ch395f_socket_test.py tcp_server --port 8081 --max-conn 8 - 结果：**Phase 7 34/34 PASSED（failed=0）**；TC704 五路全部 ESTABLISHED，每路 64 B 回显字节级比对通过 - 芯片 Socket 实测落在 sock2/4/5/6/7（0/1/3 被监听占用）→ Socket 4~7 在 bit0=0 下完全可用，与官方手册"8 Socket 原生 + _SN 索引寻址"一致 - 烧录 -Rst -Run + 回读 No difference found；测试宏已还原、产品构建重烧 台架前置排雷（两条都会造成全量假 FAIL，已登记进 Trap 18）： 1. PC 适配器落在 Public 防火墙配置文件 → 入站 8081 被静默丢弃，症状是 TC701/702/704 全部 CONNECT TIMEOUT（而 PC→设备 21 端口与 ping 正常）， 极易误判成"0x08 毁了 client"。 2. 上一轮遗留的 tcp_server 进程仍占着 8081，新起的服务器绑不上端口 却不报错。 登记簿：N-31 行删除（完成即销项），W5 行加销项注记；Test_Guide TC704 补复跑记录与前置条件；Trap 25 疑点条目改判为"已实测通过"。 验证：@build 0 错 0 警（产品构建 Code=196764）；check_doc_links --all 通过。	2026-10-11 20:24:39 +08:00
wandering1	d758d5cd7b	docs+net: FUN_PARA 定案 0x08——bit0 保留位证伪，Trap18 定案更正 + N-31 ... CH395F FUN_PARA 的 bit0 之争定案：取 0x08（bit3 SOCKET_CLOSE=1，bit0=0）。 证据（一手，按强度）： - 官方手册 V2.2/V2.3 与旧版 V1C/V1E/2020 版 §5.52 位表：bit0 一律 「保留,必须为0」，任何版本都不存在「bit0=多 Socket」这一行。 - 官方 SDK CH395INC.H:349-353 位宏只有 bit1/3/4/7/8，无 bit0 宏。 - 官方例程直接反例：EXAM5_TCP_Server 传 0x02（bit0=0）却给 Socket 0~7 全部配缓冲；EXAM11_FTPClient 直接传 0x08；全 EVT 包无一处 0x09。 - 手册命令章前言：8 Socket 是芯片原生能力，靠 _SN 索引寻址；§5.45 真正的门槛是缓冲分配（Socket 个数 >4 须重分配缓冲）。 - 概念讹传源是 bit1 FUN_PARA_FLAG_TCP_SERVER（服务器多连接，§9.2.6）。 - 互联网检索无任何出处称 bit0 为单/多 Socket 模式。 Trap 18 的「bit0 决定 Socket 数量」是推论而非实测：无日志、无 TC 号， 且当年 Socket 1~7 未显式配缓冲（Trap 01/02 混淆因子未排除）；TC704 40/40 与结论出自同一提交，属自证，不构成 0x08 的对照。 改动： - net_socket.c：0x09→0x08（原为未提交改动，现已过编译门禁）+ 版本留痕 - ch395f_reuse_bench.c：0x09→0x08，与生产 net_init 同构 - net_test_task.c：TC704 注释纠正（Socket 可用性不依赖 FUN_PARA） - Trap 18 新增「定案更正」完整证据链；Trap 25 疑点改判为定案 - Test_Guide / 产品需求 / 架构总览 / BSD 调用关系：0x09→0x08 改口径 - 待处理内容.md 登记 N-31：0x08 下多 Socket 台架复测（TC704 降并发 ≤5 + FTP 回归），补 Trap 25 销项时漏登记的尾巴 验证：@build 0 错误 0 警告；check_doc_links --all 通过；无 U+FFFD。	2026-10-11 20:05:22 +08:00
wandering1	d1e6bb4ba7	W5波+N-19收口：FTP鉴权落地、Trap25三连定案修复(N-30)、N-20/N-23/N-26 ... N-19 FTP 鉴权： - lftpd_auth（USER/PASS 状态机 + 连续5次失败锁60s）+ SHA-256 (user||pwd) 口令哈希；config.ini [ftp] 段 user/pwd_hash/write， 出厂 admin/admin 在用有启动告警；lftpd_log.c 删除并入 lftpd_auth - ftp_cfg 配置读写；台架 ftp_auth_bench.py 13/13 N-30 / Trap 25（CH395F_Trap_Records.md 四次定案全记录）： - 修复1 closed-with-data accept：客户端发完正常 FIN 后芯片按 FUN_PARA(0x09) §5.52② 保留 Socket+RX 缓冲，旧代码把 CLOSED 一律 relisten 自毁缓冲 → STOR 必挂 425；改为接受"已关但可读"连接排空 - 修复2 丢 CONNECT 中断探针 net_lost_connect_probe + last_peer_port 幽灵甄别（拆链窗口握手完成但中断丢失，双信源去抖补 accept） - 修复3 send_list/send_nlst 批量单发：背靠背 ~60B 小段毒化芯片 TX （芯片报 SEND_OK 但对端全丢），整份目录一次性写入 - 证伪存档：固定沉降/Socket 轮换冷却/listen 门控（台架 v7 矩阵） - 台架工具 test/board/ch395f_reuse_bench.{c,h} + host 脚本存档 （不注册编译；实验分支 n30-chip-bench 保留） N-20：Error_Handler 死循环降级（记录+复位路径） N-23：scripts/check_registration.py 双端注册反向校验（pre-commit） N-26：GD5F NAND 直 DMA 调用方缓冲窗口断言 验证：BUILD_OK 0/0；ftp_regression 连跑 4 轮 11/11（修复前 LIST#4/#7 100% 挂、STOR#2 曾 100% 425）；ftp_auth_bench 13/13； @test 启动标记 PASS；ci_local L0+L0.5 全过；doc-links 通过。 登记簿 N-30 已销项。	2026-10-11 18:50:24 +08:00
wandering1	de1b50efe9	修复 P1-7：MAC 写入顺序改为 INIT_CH395 之前 ... - 手册 §9.2.1：SET_MAC(步骤①) 必须先于 INIT_CH395(步骤⑤)；SET_MAC 写 芯片 EEPROM，INIT 从中加载 MAC——原顺序反了则本次上电 MAC 不生效 （回落芯片内置/上次值），UI 显示与设备在线身份不符 - net_socket.c net_init()：SET_MAC 移到 ch395f_init() 之前（对齐步骤①） - ch395f.c：四个 SET（MAC/IP/GWIP/MASK）限定条件注释由"芯片已初始化" 订正为"必须在 ch395f_init() 之前调用" - net_socket.h / BSD_Socket_API_函数调用关系.md：同步顺序描述 - CH395F_Trap_Records.md：新增 Trap 24 沉淀根因与修复 - 待处理内容.md：P1-7 销项（§1/§2 阶段 A/§3.1/§4）；阶段 A 清空后重编号 - 验证：Keil 构建 0 错 0 警；pre-commit 17/17 全通过	2026-10-04 23:07:00 +08:00
wandering1	22559365b9	整理 App 与 test 目录：按职责分子目录并同步全库引用	2026-09-26 12:52:39 +08:00
wandering1	8d86fb1149	登记簿完成即销项：待处理内容.md 删4项已闭环条目并清理全库引用 ... - 删 N-1/N-5/N-6/N-8（结论已沉淀于 Trap21/22/23 与 E-03，先验证后删） - 同步清理 3 处外部引用（错误码传播审计、CH395F_Trap_Records、Net层阻塞模型） - 文件头说明改写为「完成即销项，不保留已消化行」 - AGENTS.md 新增登记簿销项规定	2026-09-26 12:12:14 +08:00
wandering1	a6cdebde62	文档体系重组与 D-7 一致性门禁落地，清理芯片手册孤儿图片 ... - D-6 目录规范化：docs 根目录散落文档归入 UI设计/子系统设计/架构设计/审查记录/ 环境与部署/网络 等子目录，去掉目录名空格，重命名 嵌入式C语言代码规范_V1.0.md - D-7 三档一致性门禁：新增 scripts/check_doc_links.py（链接存在性）、 scripts/gen_task_table.py（FreeRTOS 任务表数值）、scripts/check_mem_numbers.py （内存/Flash 体积），均支持 --check/--write/--diff，pre-commit 钩子同步注册 - D-5 文档索引：新建 docs/README.md，新建 docs/文档规范.md 约束目录命名与链接写法 - D-1 芯片手册瘦身：删除 1069 张无引用孤儿图片（77.06 MB）， docs/芯片手册 120 MB → 41 MB，已引用图片零断链 - 同步 C 源码注释中的文档路径引用（D-6 重组后），构建 0 错误 0 警告	2026-09-26 00:51:53 +08:00
wandering1	c39ff11bb9	Trap 23: 4个可复用台架探针迁入MDK-ARM/bench_diag/并提交，10个一次性甄别脚本已删除	2026-09-25 05:38:03 +08:00
wandering1	c12139da06	Trap23待办3: 异常释放(TIMEOUT/RST)挂起recv以CONNRESET了结, STOR异常结束回450并删除截断文件, 探针加--check-abort	2026-09-25 02:04:46 +08:00
wandering1	a1f1f46262	Trap23两阶段修复: 异常释放400ms隔离+正常释放100ms沉降(仅收过数据), 修复中止后新传输首笔静默截断	2026-09-25 01:57:03 +08:00
wandering1	77ee778605	修复Trap22快速复连丢中断致监听死亡：net层周期对账自愈(去抖+冷却)，复现用例与回归全绿	2026-09-23 02:27:10 +08:00
wandering1	3ac8eb807d	TC-NET-604结案为非缺陷：Trap21改短+删机理图解+N-7作废，清理源码误导注释	2026-09-23 01:36:57 +08:00
wandering1	7d70445c16	修复Trap23：异常释放后复监听隔离并排空RX残渣，上传中止截断消除（RST10/10+FIN5/5通过，正常50/50）	2026-09-23 01:31:07 +08:00
wandering1	5a41b966fc	新增Trap23：上传中止后首笔复连上传被静默截断(2048B)并误报成功，可信复现15/15，N-8待修	2026-09-23 01:10:37 +08:00
wandering1	0e6efb44a3	可信复现首轮：真实FTP生产路径177轮全过（SHA-256全匹配）+并发UI 600帧，未复现冻结	2026-09-23 01:06:19 +08:00
wandering1	685a860635	撤回Trap21精确定位轮冻结结论（台架假象：分类器误判+固件读者吞噬数据），N-7暂不实施	2026-09-23 00:54:00 +08:00
wandering1	49458048fd	新增Trap21机制图解文档：读必读空方案、5处读路径落点与RAM账，N-7细化	2026-09-23 00:17:35 +08:00
wandering1	cca3b60d64	Trap21定案部分窗口重通告机制：N-7改非阻塞RX读强制排空至空，netcmd日志入库	2026-09-23 00:07:45 +08:00
wandering1	a5a14e5fe8	Trap 21 主因定案：排空后50-100ms内第二条RX命令（剂量台架证伪满态时长说）；新增N-7排空后RX守卫方案、指南最小复现配方	2026-09-22 21:21:05 +08:00
wandering1	1a872b05bc	Trap 21 触发模型修订为三因子（2×2 台架实证）；新增 Trap 22 快速重连监听死亡与 N-6 待办、604 复现/对照规则	2026-09-22 20:20:58 +08:00
wandering1	93bae35e21	TC-NET-604 根因闭环：芯片 RX 窗口冻结角（Trap 21），MSS=512 裕量方案证伪回退，缓冲布局与 MSS 解耦 + 超限读金丝雀 ... - 根因：CH395F 片内 TCP 状态机角（WCH 官方 FAQ 留档，W5500 同类）：窗口=接收缓冲剩余空间， 缓冲恰好填满 + 排空时序交叠后芯片 RX 静默冻结（不 RST、不自恢复），触发模式 = 同连接前序突发 + 新突发 + 任务负载；驱动超限读丢弃与 L3 pending 均经插桩台架排除 - MSS=512 裕量实验证伪（原序列 10/10 仍停摆，且新连接 4096B 确定性停摆恒剩 64B）→ 维持 1024 - 缓冲块布局（RX 4/TX 2 块）与 SPI DMA 缓冲（接收缓冲+4）与 MSS 解耦，杜绝改 MSS 连带缩小布局 - ch395f_read_recv_buf 超限守卫改为 OVERSIZE 留痕（原静默 return 会把窗口锁死 0 且无从诊断） - 文档：Trap 21 全记录（含 MSS=512 负结果/64B 残留/FAQ 引文/触发模式）；N-1 改写（残留决策项 = lftpd 数据通道停摆预算 30s→10-15s 待用户决策）；E-02 STOR 预测机制修正；延迟说明基线免重锁注记 - 台架复验：新连接 4096B 31ms PASS（4x1024 粒度）、竞争序列停摆复现（芯片角，已文档化）、 停摆后重连 520ms 恢复（auto-relisten + 回显正常）；芯片行为参数零变化 → M3 基线全部继续有效	2026-09-22 18:57:48 +08:00
wandering1	9c990ead43	文档结构调整	2026-08-28 22:02:24 +08:00