5224f21622d94826fad7b2672352bf1b17e57d00
376 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 wandering1
|
5224f21622 |
fix(NET,lftpd): 处置覆盖率照出的三处死路径（改名 + 修 timeout=0 + 激活异常集）
三处都由本轮 P1 新增的主机单测照出，用户逐条裁定后实施。共同性质：都不是改动引入
的回归，而是**从没被执行到的分支**——生产路径上要么没有调用者、要么没走边界，所以
编译器（0 错 0 警）、cppcheck、真机日志对它都无话可说。
1) 缺陷一（选 a：改名，行为零变化）
lftpd_string_trim 的尾部循环起点落在 strlen(p) 那一格 NUL，isspace(0) 为假 →
循环体一次都不执行，"尾部空白从未被裁"，而名字承诺两头都去。改名
lftpd_string_ltrim + 删掉那条死循环 + 在 .h/.c 写明"只去前导"。不去尾才是对的：
RFC 959 以命令终止符 CRLF 界定命令，参数（PASS 口令、含空格的文件名）的尾随
空格属于参数本体，去掉等于静默改数据；CRLF 已由 lftpd_inet_read_line 截断。
调用点 lftpd.c 同步改名。全库无遗留真引用（余 6 处旧名均为解释改名历史的散文）。
2) 缺陷二（按推荐修）
net_select 的 timeout = {0,0} 换算出 timeout_ms = 0，而退出条件写着
if ((timeout_ms > 0) && (已用时 >= timeout_ms)) → 超时永不生效，退化成死等；
POSIX 语义是"只查一轮立即返回"。去掉 timeout_ms > 0 这个错误前置即可。就绪
检查在本判断之前，故有就绪时仍立刻带计数返回；同文件 net_poll_events 的
timeout >= 0 本来就对，现在两条对齐。风险面：拿它当"非阻塞查一遍"会让 netTask
回不到主循环，而 netTask 在 IWDG required_mask 里（串行 socket 栈唯一执行者）。
3) 缺陷三（选 ①：按 POSIX 置位）
exceptfds 是恒为空的死参数：循环开头 p_sock == NULL → continue 先跳过，而
check_socket_error() 只有"表项为空 / fd 越界"才返回 1，越界的 i 又不在本循环
范围内 → 调用方按 POSIX 直觉用它收异常，永远什么都收不到，且返回码不报错。
把异常判定提到 continue 之前：表项不存在的 fd 计入 exceptfds 与返回计数，并更新
函数注释。选 ① 会改变返回计数语义，故补一条"未请求异常集时不计数"的用例，
确保只查可读的老调用方不被误伤（TC-NETSEL-012b）。
测试同步翻转：原 TC-NETSEL-008 / TC-NETSEL-012 是"现状桩、改了会响"，现在改成正向
契约，并新增 TC-NETSEL-012c（异常位只落到被请求的那个集合）；TC-LFTSTR-005 从
"尾部不裁"的现状登记改为正向契约（尾随空格必须保留）。net_select 22/22、
lftpd_io 33/33 全绿。
@build：0 错误 0 警告。实测体积 ER_IROM1 232,512 B（快照 232,536 → **−24 B**）、
Flash 233,704 B（−20 B）、RW_IRAM1 75,272 B（+8 B 是上一提交 net_cfg 那个字节，
本批零新增）、**RW_CCM 57,376 B 不变**；四档百分比 22.2/57.4/87.9/22.3 全不变。
Code 减少 36 B 即删掉的死循环。
覆盖率台账：门禁如实报了一次 lftpd_string.c 已覆盖行 8 → 7（**代码少了一行**，不是
覆盖退化），已 --update-baseline 重登；现 22/22 套件、line=3003/3446（87.1%）、
func=236/259（91.1%）、tested_files=26、untested_files=118。
文档：主机单测覆盖率口径 §9 新增"三处死路径的处置"小节（裁定、改法、影响、钉住
它的用例一一对应），并把两处"等裁定"的登记改为已处置。
自查：coding-standard / test-cppcheck / id-check --strict（无台账外新账）/ doc-links
（35 处 = 存量）全过；八个改动文件与 HEAD 逐项比对 BOM/CR/U+FFFD/行尾无变化
（这几个文件本就不带 BOM，未被动过）。pre-commit --all-files 仍只有三条失败且与
本分支无关：mem-numbers / mem-budget（.map 与 docs/内存管理 受管快照漂移，增量见
上，按并行分支约定不在分支里 --write，等 Lead 合并后统一回填）与 ui-golden
（simulator/tests/ref/*.bin 在 .gitignore 内，新建 worktree 天生没有黄金参考）。
|
||
|
wandering1
|
658bc40ccc |
test(NET): net_select 模块（21 条）与 NET 域首份 ch395f 桩，登记两处死路径
P1 的 NET 四块开了第一块：新增 test/host/net_select/，21 条断言全部 MSVC 编译
通过并 PASS。net_select.c 一个芯片函数都不调，所以它是四块里唯一不需要假芯片的，
先把它拿下，顺带把 NET 域的桩骨架立起来。
钉住的契约：
- 就绪位回写：入参集合里未就绪的 fd 必须被清掉，只留就绪的（POSIX 语义）；未请求
的集合不被写回、可以传 NULL。
- 状态准入：LISTENING 即使 readable 也不算可读（accept 语义不在这层）；ESTABLISHED
+ send_ready 才可写；CONNECTING 时 send_ready 不作数。
- 边界：nfds 为 0 / 负 / 超过 NET_MAX_SOCKETS 都返回 -1（不许扫出 socket 表外）。
- 超时算术：tv_usec 是**整除截断**（1999us 当 1ms 而不是 2ms）；timeout=NULL 时
无限等并由对端事件唤醒；poll 的 timeout=0 首轮即退、每轮先清 revents。
用可控 tick（每问一次 +1）+ 可控 osDelay（计数、可指定轮数后造一个就绪 socket）
把这些变成确定性轮数，台架上根本构造不出"没人来连时该怎么退"。
照出两处**死路径**（只登记，未改语义；全库唯一调用点 test/board/net_test_task.c
传的是 NULL 与非零 tv，今天没有受害者）：
1. net_select 的 timeout = {0,0} 换算出 timeout_ms = 0，而退出条件写的是
if ((timeout_ms > 0) && (已用时 >= timeout_ms)) → **超时 0 永不触发退出**，退化成
无限等；POSIX 在这里必须立刻返回 0。同文件 net_poll_events 写的 timeout >= 0
是对的，两条并排放着正好是对照。风险面：谁拿它当"非阻塞查一遍"，netTask 就
回不到主循环，而 netTask 在 IWDG required_mask 里。
2. exceptfds 是恒为空的死参数：循环体开头 p_sock == NULL → continue 先跳过，
check_socket_error 的 NULL 分支从 select 里到不了。按 POSIX 直觉用它收异常的人
会永远什么都收不到。
两处都用"现状桩"钉成改了会响（用例名里写明不是期望行为）。另修掉我自己写错的一条
用例：给 timeout=NULL 又没有就绪 fd，直接死循环——已在假 osDelay 里加了 500 轮
保险（跑飞就 exit(2)），因为挂死的测试会把 exe 文件名占住、让后续构建报 LNK1104。
桩的边界写死在文件头：net_select.h / net_types.h / net_config.h 用真实头（net_sock_t
字段名与 NET_SOCK_STATE_* 一改即编译期报错）；main.h / cmsis_os.h / FreeRTOS.h /
task.h 是本目录桩；新建的 ch395f.h 是**空壳**，只服务不调芯片函数的文件——
net_pending / net_events / net_listener 直接调十余处 ch395f_*，要的是可脚本化返回的
假芯片，不要把这个空壳当成"NET 域桩已就绪"。
覆盖率：套件 21 → 22 全绿；files_tested 25 → 26；未触及 .c 41 → 40；分母 3,332 →
3,446 行；net_select.c 97/114（85.1%）。恒等式更新为 40 = 6(P1 剩) + 5(P2) + 29(P3)。
编号按 B 层口径补建 TC-HOST-NETSEL（游标 019），TC-HOST 族现共 16 族；注册表仍只
做增量插入。
自查：test-cppcheck Passed；check_ids --strict 通过；doc-links = 35 处（= 存量）；
BOM/CR/U+FFFD/行尾逐项净。本增量零生产代码改动，未跑 @build。--all-files 仍只有
mem-numbers / mem-budget（.map 台账漂移，等 Lead 合并后统一回填）与 ui-golden
（ref/*.bin 不入库，新 worktree 天生没有黄金参考）三条失败，与本分支无关。
|
||
|
wandering1
|
6bdf063f50 |
test(NET/lftpd): P1 增补 lftpd_io 模块（33 条），登记 FTP 域一处潜伏缺陷
新增 test/host/lftpd_io/：一个 TU 同时纳入生产源 lftpd_io.c 与 lftpd_string.c （两者静态符号不冲突，省一套桩），33 条断言全部 MSVC 编译通过并 PASS。 钉住的契约（都是真机上偶发、日志看不出根因的那类）： - 路径规范化：**".." 上跳过头仍被钳在根内**（"/a" + "../../x" = "/x"）——FTP 客户端 可发任意路径，这是安全属性；绝对名忽略 base、"." 丢弃、段间多余斜杠折叠、 NULL 入参容忍、全空结果归 "/"。 - 分配失败：这个函数返回 pvPortMalloc 出来的指针（历史上正是它落在 C 库 malloc 上， RAM 方案 §4.2.1）。用**可注入失败的假堆**跑两条分支：首块失败 → NULL；结果缓冲 失败 → NULL **且第一块已 vPortFree**（不泄漏堆）。模拟器宿主 CRT 永不失败，这条 只有假堆能构造。 - 卷锁时机：open 成功**故意不释放**（整个传输期独占卷，由 close 释放），失败必须 释放并留 ERROR；单文件槽守卫 s_file_open 命中时**不碰卷锁也不碰 FatFs**。 - 等卷锁循环每轮喂看门狗（lftpd_task_wd_beat）：defaultTask 与 FTP 争卷时这里可能 空转上百毫秒，漏喂就是整机复位。脚本化 vol_lock_wait 的返回序列直接构造 2 轮空等。 - lftpd_string_trim：行首空白由**返回指针**跳过、原缓冲不搬移（调用点 lftpd.c 用的 正是返回值）；全空白串返回空串。 **本批照出一处，未改语义、只登记**：lftpd_string_trim 的尾部循环写成 for (i = strlen(p); i >= 0 && isspace(p[i]); i--)，i 起步那格是 NUL、isspace(0) 为假 → 循环一次都不执行，**尾部空白与 CRLF 从未被裁掉**。今天不发作是因为 CRLF 在 lftpd_inet_read_line 里已用 strstr 截断、且唯一调用点只关心行首；风险在于"以后有人 拿它去尾部空白"不会生效。修法只要一行（i 从 strlen(p)-1 起），但那会改变 FTP 参数 （含空格的文件名/口令）的可见行为，需要 FTP 域一起过，**留给用户裁定**；当前用 TC-LFTSTR-005 把现状钉成"改了会响"（明确标注是现状桩、不是期望行为）。 未覆盖也写在文件头：lftpd_io_read/write/close/stat/unlink/opendir/readdir/closedir 要先把假 FIL/FILINFO 的字段语义（fptr、obj.objsize、fname 等）做实，否则断言会落在 假件自己写的规则上；这 8 个 f_* 只给了可链接的 FR_INT_ERR 实现，走进即失败不静默。 覆盖率：套件 20 → 21 全绿；files_tested 23 → 25；未触及 .c 43 → 41；分母 3,163 → 3,332 行；lftpd_io.c 85/159（53.5%）、lftpd_string.c 8/10。总体 line_rate 88.9% → 87.2% —— **这是摊薄不是回退**（新进来的文件只测了一半，分母涨得比分子快），已按 §5 口径写进口径文档 §9 的落地进度表；恒等式更新为 41 = 7(P1 剩) + 5(P2) + 29(P3)。 编号：按 B 层口径补建 2 族 TC-HOST-LFTPIO（游标 037）与 TC-HOST-LFTSTR（005）， TC-HOST 族现共 **15** 族；id_registry.json 仍只做增量插入（无重排）。 自查：test-cppcheck Passed；coding-standard Passed；check_ids --strict 通过（无台账外 新账）；check_doc_links --all = 35 处（= 存量，本分支贡献 0）；新增/改动文件 BOM/CR/ U+FFFD/行尾卫生逐项净。**本增量零生产代码改动**（只加测试、注册表与文档），故未跑 @build。pre-commit --all-files 仍只有三条失败且与本分支无关：mem-numbers / mem-budget （本 worktree 上次 @build 生成的 .map 与受管快照漂移，增量 ER_IROM1 +12B、RW_IRAM1 +8B、CCM 0，按并行分支约定不在分支里 --write，等 Lead 合并后统一回填）与 ui-golden （simulator/tests/ref/*.bin 在 .gitignore 内，新 worktree 天生没有黄金参考）。 |
||
|
wandering1
|
b1291f1308 |
test(NETCFG,CFG): P1①四个主机单测模块，并修 net_cfg 的 WAIT 契约与定长错记
按 docs/测试说明/主机单测覆盖率口径.md §9 的清单吃 P1 第①批「配置与工具」四块， 新增 4 个主机单测模块共 104 条断言，全部 MSVC 编译通过并 PASS： - test/host/net_cfg/（45 条）：出厂默认可用、注册幂等与内容、load 报 -1 仍返回 0 （RAM 恒有效契约）、跨任务保存交接状态机 IDLE/WAIT/OK/FAIL、MAC 三态优先级、 IPv4 定长格式化。 - test/host/ftp_cfg/（16 条）：[ftp] 段注册（**p_cb 必须为 NULL**，口令下次登录才 生效）、默认口令判定大小写不敏感、NULL 一律判不等（fail-closed）。 - test/host/prot_set_store/（16 条）：blob 返回码分流 1 无档 / 0 成功 / **2 换代 （只打 INFO）** / -1 损坏；写盘失败必须回置脏标志（否则定值静默丢失）。 - test/host/task_prof/（27 条）：无效样本闸门（防 DWT 复位把 max 抬到 2^32）、 未 enter 就 exit 不记账、首次 5s + 每 2s 节流、环形缓冲与裸发两通道、 周期→微秒换算随 SystemCoreClock 变。 覆盖率收益（已 --update-baseline 登记）：套件 16 → 20 全绿；files_tested 19 → 23； 未触及 125 → 121 个文件（.c 47 → 43、9,657 → 9,228 行）；分母 2,893 → 3,163 插桩 行；line=2811/3163（88.9%）、func=225/240（93.8%）。§9 的恒等式同步更新且仍咬合： 43 = 9(P1 剩) + 5(P2) + 29(P3)、9,228 = 2,188 + 2,226 + 4,814。 新单测照出并修掉两处真问题（都在 net_cfg，不是测试写错）： 1. 实现违反自己的文档契约：net_cfg.h 明写"属主任务写盘中显示 WAIT"，但 net_cfg_save_run 为了不丢新请求会先清 pending 再写盘 → 写盘那几百毫秒里 UI 保存行退回上一轮的 OK/IDLE（第一次保存按 ENTER 后屏幕上还是 ENTER），用户只 会再按一次。补 s_save_busy 标志，TC-NETCFG-028/026/030 钉死（含失败路径必须 清 busy，否则 UI 永久卡 WAIT）。 2. "定长 11 字符"是错的：%03u.%03u.%03u.%03u = 4 段×3 位 + 3 个点 = **15**。这个数 错了 4 处（net_cfg.h、net_cfg.c、网络配置说明.md 两处）——是我照抄它才撞上 FAIL，错在文档不是代码。已全部更正，并确认 len ≥ 16 的要求与 UI_BUF_STRLEN=32 本来就没问题（无截断风险）。 桩的口径（沿用既有模块，不另起一套）：真实头优先——cfg_file.h / cfg_file_store.h / console_log.h / prot_set.h 全用真头（接口一漂移就编译期报错），只有 main.h 必须桩 （真实 main.h 拉整棵 HAL 头树，PC 上编不动；桩里字段名与位掩码宏名与 CMSIS 一致）。 prot_set_store 连真实 prot_set.c 一起编：blob 的编解码与脏标志在它里面，只有拿真 serialize 产出的 blob 才能造出"换代"与"损坏"两种真实形态，手搓等于测自己的桩。 配置引擎本身（解析/写盘/沉降）归 test/host/cfg_file 的 103 条，本批不重复测。 编号门禁：按 2026-10-21 批 3 的 B 层口径补建 4 族 TC-HOST-*（NETCFG 游标 056 / FTPCFG 014 / PROTSTOR 016 / TASKPROF 020，代码即属主登记处）。这一步不是走形式： 建族之前文档里引用 TC-NETCFG-028 被判「台账之外新账」直接卡提交，建族后才通过； 编号规范 §8.4 变更记录加一行说明族数 9 → 13。id_registry.json 只做增量插入（+88 行， 无重排）。 自查（提交时 pre-commit run --all-files，**仅 3 条失败且都与本分支改动无关**）： - mem-numbers / mem-budget：本 worktree 因需验证代码改动而 @build 过，新生成的 .map 与 docs/内存管理 受管快照漂移。实测增量 ER_IROM1 +12 B、RW_IRAM1 +8 B、Flash +16 B、**CCM 0**，水位百分比全不变（改动 = 1 个静态字节 + 几条指令）。按并行分支 约定**不在分支里 --write**，台账由 Lead 合并后统一回填。 - ui-golden：simulator/tests/ref/*.bin 写在 .gitignore 里（黄金参考是本地生成物）， 新建的 worktree 天生没有，报的是"缺黄金参考"而非像素差异；本分支零 UI 文件改动。 - 其余全部 Passed，含 @build 0 错误 0 警告、test-cppcheck（它抓到过我一条 p!=NULL 后又解引用的写法，已改为断言+显式守卫）、coding-standard、doc-links（35 处=存量）、 id-check --strict、mojibake 与 BOM/CR/U+FFFD/行尾逐项卫生。 - 自审修掉自己写的两条恒真断言（形如 x==0?1:1 的假绿）与一个重复编号标签。 - 4 个新模块**尚未挂 pre-commit 钩子**：.pre-commit-config.yaml 是单写文件，任务工作 树内不改；覆盖率脚本按 test/host/**/run_unit_test.py 自动发现，已实跑 20/20。 - 未跑 @test：改动仅 1 个静态字节 + UI 保存行的显示时序，无硬件语义变化。 |
||
|
wandering1
|
e70b861215 |
docs(覆盖率): 新增 §9 未触及面建桩优先级清单（P1/P2/P3 逐个画像）
回答"那 125 个到底怎么吃"：对 47 个未触及 .c（9,657 有效代码行）逐个量化后再排序， 不靠拍脑袋。排序口径写进文档、可复核可反驳：价值 = 有效代码行 × 逻辑度 × 缺陷历史 （该文件的 fix/refactor 提交数），成本 = 要桩的外部头数 − 能复用的现有桩；逻辑度 = 1 − 硬件符号密度（HAL_*() / FatFs f_*() / CH395F_* / SPI-I2C / OSAL 调用数 ÷ 行数）。 三档（数字互相咬合，覆盖率"不该 100%"在这里是算出来的）： - P1 先吃 13 个 .c = 2,617 行：配置与工具 429（真实头即可编译，建议第一个落地，先用它 跑通"新增文件进台账 + NOTE 不误报回退"这条链）→ FTP 一套 1,083（20 次提交里 6 次 fix，最近两条都是静默型）→ NET 拆出的四块 903（须新建 stub/ch395f.h）→ 104 服务层 202。 - P2 值得但工程量大 5 个 = 2,226 行：net_socket.c 1,251（51 函数，**必须分片**，先测状态 迁移与语义判据）；假 FatFs 一次吃 sys_log_mcu/cfg_file_store_mcu/soe_store 共 710； console_log 265（单写者契约 K1/K2 已写成表）。 - P3 明确不做 29 个 = 4,814 行，并把理由写死免得下次又列回待办：芯片驱动 1,990（假到底 ≈ 重写驱动，测的是自己的桩）、UI 侧 1,942（与模拟器同一份源码，已由 ui-golden 覆盖）、 任务编排 747（4~5 个函数的装配层，写成单测就是"断言我调了几次"）、app_main 135 （被测对象本身就是内核启动前的时序约束）。 - 恒等式：47 = 13 + 5 + 29、9,657 = 2,617 + 2,226 + 4,814；做完 P1+P2 约 4.8k 行进分母 （现分母 2,893），files_tested 19 → 37。 配套口径修正： - "125 个未触及"易被读成 125 个待办，三处写精确 = 47 个 .c（9,657 行）+ 78 个 .h （2,182 行，多为声明与宏）；待办池是那 47 个 .c。 - §8 下一步①改为指向 §9；终点判据从百分比改成"untested_sources 里剩下的每一条都能在 P3 表里找到归属"，并提醒盯 files_tested/files_untested 而不是 88.2%（新增大块未测代码 会把它摊薄，那不是回退）。 自查：check_doc_links.py --all = 35 处（与主干同数，本分支贡献 0；期间修掉一处 §4.5 被 误算成本文自引用）；check_ids.py --strict 通过；check_mojibake + BOM/CR/行尾卫生净。 本轮纯文档，零 .c/.h 改动，未跑 @build、未占 build/bench 锁。 |
||
|
wandering1
|
6505cef9df |
feat(门禁): coding-standard 加 CODE-RULE-20 禁 C 库堆分配（销 §4.8 空白 ②）
规则：在**掩码后**的文本上匹配 malloc/calloc/realloc/strdup/strndup/ free/aligned_alloc 调用。三条判据都是踩过坑之后定的—— - 大小写敏感：pvPortMalloc / vPortFree（唯一允许的配对）不会误报； - 词边界 \b：dhara_nand_is_free(、buf_alloc( 这类同形后缀不误报； - 用掩码：注释与字符串字面量里写 malloc 不报（规范示例就踩过这种）。 覆盖名比 AGENTS 列的五枚多带上 strndup / aligned_alloc——同族同类， 漏一个就等于留后门。 出处不在规范 V1.0，在平台约束：MicroLIB 的 C 堆由 startup_stm32f407xx.s 的 Heap_Size EQU 0x200 只有 512 B，KB 级分配必返 NULL，而模拟器（宿主 CRT 堆）完全正常、**照不出来**——配置引擎 2026-09-18 那次堆分配纠偏与 lftpd 的 malloc 隐患都是**先上线才发现**的那类，靠评审等于没管。 落地前按 门禁说明/coding-standard.md §8 的纪律先全库普查：钩子范围内 C/H 共 151 个文件，命中**只有** simulator/sim/cfg_file_store_sim.c 两行， 即 cfg_store_alloc/cfg_store_free = **平台分配后端的宿主侧实现**（设计依据 写在 docs/子系统设计/配置文件设计说明.md 的"MCU 端 = pvPortMalloc、 模拟器端 = 宿主 CRT"）。所以零基线、直接硬拦截；豁免用脚本里的 HEAP_ALLOC_ALLOWLIST（**文件路径 + 函数名**双条件），刻意不做目录级豁免： 下次谁要碰 C 堆就得往这张表加一行，评审看得见。 自证：临时样例文件里 malloc/calloc/free 各报一处，pvPortMalloc/vPortFree/ buf_alloc(、注释、字符串五种陷阱形态全部不误报； pre-commit run coding-standard --all-files → **Passed**（= 全库零存量）。 顺带修三处口径不一致： - 规范 V1.0 §6.1 的示例自己写着 malloc/free（通用 C 模板遗留）→ 已在示例 下加"本仓例外，别照抄"批注，事实源指向 AGENTS.md 平台约束； - docs/门禁说明/mem-budget.md 里"这条纪律只靠 AGENTS 铁律与评审"已过期 → 更正为由 CODE-RULE-20 机器拦截； - AGENTS.md 平台约束条加"已机器拦截 + 唯一豁免"一句；scripts/README.md 补登 check_test_coverage.py（上一个提交漏登记）。 另：本次一并修好上一处编辑事故——报告 §4.8 曾被我的脚本调用截成半句 （只落第一行、丢掉 malloc 那半句），已重写为"两处空白均已闭合"。 自查：pre-commit run --files（9 个改动文件）适用项全 Passed； check_doc_links.py --all = 35 处，与主干同数（本分支贡献 0）； check_ids.py --strict 通过（裸编号 P0-1 改平实说法，避免记成新账）； 9 个文件 BOM/CR/U+FFFD/行尾与 HEAD 逐项一致。本轮零 .c/.h 改动，未跑 @build、未占 build/bench 锁；分支已 rebase 到 v2-on-ui，覆盖率脚本全量 回归仍 16/16、line=2552/2893 不变。 |
||
|
wandering1
|
2bfa09ed15 |
feat(门禁): 主机单测覆盖率脚本与口径落地（销报告 §4.8 空白 ①）
落地物： - scripts/check_test_coverage.py：发现规则与 L0.5 同一条（test/host/**/ run_unit_test.py），直接 import 各运行器复用其 TestBuild 与 unit_test_harness._BASE_FLAGS —— 配置零复制，不会漂出第二套口径； 只算自研生产源码（App/**、Drivers/BSP/**）的行/函数、多套取并集、 生成物（文件头写"自动生成/请勿手改"）不进分母、分母一律来自插桩 报告不猜行数；中间物全在 %TEMP%，不新增 .gitignore 规则。 - scripts/test_coverage_baseline.json：增量拦截台账（只拦回退不拦进步， 与 layer-deps / bsp-err 同姿态）；ci_local.py 加 opt-in --coverage。 - docs/测试说明/主机单测覆盖率口径.md：口径 + 工具链实测 + 九条盲区。 - 报告 §0.1 / §0.4 / §4.8 / §5.5 / §7 改写 + 变更记录 + 去处表。 工具链是实测出来的（换机必读）：Windows 原生侧无任何 gcc/gcov（全盘扫 Program Files*、msys64、scoop、choco、.platformio、LocalAppData = 0 处）； MSVC 14.51 已砍 /coverage，且只报 D9002 后照常编译成功 = 静默假数据； CodeCoverage.exe 17.0 三个子命令只打印用法。最终用 mscoverage 18.x （Microsoft.CodeCoverage.Console.exe）collect -f cobertura 做加载期动态 插桩，并实测它透传子进程退出码 → "插桩运行下仍必须 PASS"可当硬条件。 首登数字：16/16 套插桩下全绿，并集 line=2552/2893（88.2%）、 func=193/207（93.2%）、19 个文件在测、**未触及 125 个生产源文件 / 约 11,839 行**——最后一栏才是这套口径真正照出来的东西。 门禁自证：人为抬高基线后 行/函数/总计 三条回退路径都报 REGRESS 且 退出码 1；--module 子集跑不再假报总计回退（首版会，已修：并集口径下 子集必然变小，全部回退判定只在全量跑时生效）。 GCC 追问的复测结论（口径文档 §2.1 决策记录）：本机 WSL2 Ubuntu 确实有 gcc/gcov 15.2.0，16 套单测在 gcc 下全部编过、用例数与 MSVC 逐个一致， gcov -b -c 也确实给出分支覆盖（nand_ftl.c 分支至少走过一次 41.40%）； 但换编译器=换分母（sha256.c gcc 105 行 vs MSVC 114 行；adc_input.c 101 vs 120）。**用户裁定：本仓只留 MSVC 一条覆盖率通道**，不建第二条—— 多一套工具链就多一套分母、多一本台账、多一个"这台机器到底有没有 WSL/ gcov"的未决项，换来的只有分支这一维。分支覆盖因此**记为已接受缺口** （不是待办）：绿灯只证明行与函数被测到，补偿判据 = TC 双向追溯 + 用例显式列边界值；§8 写明重开该裁定的前提是先答"两份分母怎么对齐"。 刻意未挂 pre-commit：16 个单测钩子已经跑过同一批测试；依赖 VS 可选 组件（缺组件时 skip 会静默失效、FAIL 会拦换机）；待一个真实回退事件。 YAML 片段与理由写在口径文档 §8。 自查：pre-commit run --files（6 个改动文件）全 Passed；check_doc_links --all 回到存量 35 处（本分支贡献 0）；check_ids.py --strict PASS； check_mojibake + BOM/CR/U+FFFD/行尾卫生逐项自查全净。本轮零 .c/.h 改动 （纯 .py/.json/.md），故未跑 @build、未占 build/bench 锁。 |
||
|
wandering1
|
49a257b34c |
docs(任务规划): 立项 W8 数据可信，补 ADC 注入验证两卡，新增并行分道方案
- W8 数据可信：通道标定 → 遥测链 → 运行参数，14 张任务卡。 - 补卡：核查确认 ADC 从未采过已知电压（只验过通路活），新增 "已知电压注入验证"（只需万用表）与"端子变比确认"两卡；M4 的承诺 边界改为"ADC 引脚电压"，二次值降为依赖变比的条件项。 - 撤销"1k+1k 即 2:1 分压"的换算用法：该网络被定性为源阻抗匹配， 且端子→引脚变比仓库内无文档。 - 并行分道方案：全部待办归入 8 条道 / 8 个写域，给批次与合并次序。 |
||
|
wandering1
|
c0ccd777ae |
docs(UI): 页面补齐规划、逐页扩充方案与实时数据供给设计
- 页面补齐规划：重算菜单树（42 节点 / 33 叶子 / 6 已绑页 / 27 空叶子）， 27 叶归并为 7 模块 + 2 项前置能力 + 1 数据层，分 4 批。 - 页面扩充详细方案：逐页规格（行表、数据来源、交互、字号），并纠正 已建 6 页里 3 页实为 Flash 字面量。 - UI 数据供给设计说明：选定"快照推送"（App 推 / BSP 存 / 页面只读）， rt 200ms + par 变化触发双通道；单写者同上下文故无需锁；记录页改为 注入 reader，可回收 3 条分层门禁基线（6→3）。 |
||
|
wandering1
|
70dd6f8192 |
docs(评测): 新增采集与数据处理短板评测（对照 CLS100 参考项目）
按"采集→数据处理"全链逐层对照参考项目，结论：已建成的是保护链， 还不是能上送的测控装置。四类阻断短板：工程量折算缺失、遥测链整条 缺失、运行参数段 0x8020~0x8058 未实现、录波与 104 文件传输缺失。 另登记两处此前未记录的发现：固件无任何开入/开出代码；交流量与 直流量页为硬编码占位值，运行时不变。 建议分三阶段：数据可信 → 精度与安全网 → 录波与文件。 |
||
|
wandering1
|
1e4f74ba14 |
merge: task/ui-golden-ui-golden-ref 合入 v2-on-ui
任务 ui-golden（1 个提交）经 task-worktree 回收： - chore(ui-golden): 像素黄金参考 ref/*.bin 入库（把门禁改成可移植） |
||
|
wandering1
|
b22779d244 |
docs(存储): 补上 N-15 页缓冲可合并性论证，判定三块不可合并
报告 N-15 一直写"与 R-3 同批评估"，但评估从来没写过——nand_ftl.c:300 的注释直接引用了这份不存在的"报告 R-3"。本次补齐： - 6,216 B = RW 16 + ZI 6,200，三块 2 KB 页缓冲 6,144 B 占 98.8% - 不可合并：dhara_map_write 先 auto_gc（map.c:327）再落数据，GC 搬页 与"待写的 s_cache_buf""攒了 16 页的 checkpoint 元数据 s_page_buf" 三方同时存活，任两块合并都是静默错数据而非报错 - s_page_buf 也不能缩：元数据跨 0..1,999 偏移，编程的是整页 - 唯一可动的是 s_copy_buf：分块 512 B（-1,536 B，4 次 CPU 轮询）或 内部搬页 copy-back（-2,048 B，须实证"奇偶属性相同"限制） - 收益落点 RW_IRAM1（余 55,808 B），红线在 CCM（余 7,904 B）→ 判定不做 顺带订正 nand_ftl.c 两处注释：悬空引用改指本节；s_page_buf 原文写 "仅装 132 B 走轮询"不成立，实际按整页 2,048 B 编程、同样走 DMA。 @build 0 错 0 警告，镜像逐项不变（232,536 / 132,688 / 232,824）。 |
||
|
wandering1
|
6822726b2c |
docs(门禁说明): 手册 §2 收敛为通用机制与查号表，逐项详解归一到 23 篇
用户一句"现在门禁都在干什么，我一概不知"引出的收尾。原手册 §2 有 27 个逐钩子小节，只回答 "拦了什么、怎么配"，回答不了"什么时候会骗我"；docs/门禁说明/ 已把逐项详解（含"限制与盲区" 一节）建好，本笔做收敛：同一事实只留一处（docs/文档规范.md 的要求）。 **先搬后删**（否则收敛等于丢事实）：旧 §2 里独有条目逐篇折回，共 18 处插入、15 篇受益。折回的 东西包括：六套主机单测的来历与用例规模（13/36/82/46/32/149 断言，含 nand-port 的"与旧算法 对照"）与"改动公共骨架 unit_test_harness.py 会同时触发 16 个钩子"；UI 页面**两层注册**（构建 注册 vs 框架注册：枚举 + s_defs[] 描述符表）与"豁免不整目录一刀切"；lv-conf-sync 首次落地清掉 26 个 LVGL 9.3 不存在的选项、3 处重复定义、10 项隐式开关显式化，以及 ALLOW_DIFF 端专属白名单 与必须穿过 lv_conf_internal.h 里那层 KCONFIG 包裹；cubemx-survival 的 16 项清单、断言前先剥 C 注释（本仓注释刻意引用历史代码，不剥就恒定误报）、旧手册"自造标记区"建议与看门狗文档实测 教训之间的优先级；id-check 顺带收编 check_test_traceability.py、裸形同字母多义属**显式承认的 盲区**、--update-baseline 只许涨；layer-deps 的注入自证与报错时三条修法（注入回调 / 上层递数据 / 才谈 ALLOW）；coding-standard **nand_ftl.* 也在排除清单**（我先前那篇漏了）；test-suite-switch 的剥注释判定与派生宏白名单；mem-budget 两类软提醒不拦、退出码 2 是解析失败不是通过；doc-links 的排除目录与状态词 ±40 字符距离；task-table 改栈三步；gitlint 报错样例；no-mojibake 的修复路径。 **顺带抓到旧文档两处错**（记进文档，不悄悄改）：一是 check-added-large-files 的阈值旧手册写 "单个文件 > 1MB"，按本机安装的钩子源码实测是 --maxkb 默认 **500**（500 KB）——已更正，并把 "本目录任何默认值都以实测或安装的钩子源码为准"写进 end-of-file-fixer 当反面教材；二是 **ui-golden 在旧手册里连小节都没有**，只活在配置注释里：除了"有基线不等于有门禁"，这是另一种 失踪——有钩子、没文档。 手册 §2 改写为三节：迁移说明 / **旧编号 → 新文档 查号表**（历史引用靠它读，旧号按"冻结历史不 回改"保留）/ **跨钩子通用机制**：两阶段与换机必须重装 hooks 才带 commit-msg、stash 陷阱、 always: true 已废、改写型与只读型豁免不对称、增量拦截三段式且刻意没有 --write、没有 .map 是 "跳过"不是"通过"、改配置的验收是看目标钩子出现在输出里且不是 Skipped、新增门禁三步必须做 注入自证且"限制与盲区"不许留空，另有快速自查入口。手册 707 行 → 273 行。 引用**按内容**重指（只核编号存在与否不够，同号小节会被当本文自引用静默放过）：编号规范、 scripts/README（顺带更正那里过时的 warn-only 说法，早已关闸为增量拦截）、RAM 使用分析与优化 方案、测试开发标准流程、lvgl-simulator skill、AGENTS 文档表（拆成"每门禁一篇详解"与"通用 机制"两行）、.pre-commit-config.yaml 头注释、docs/README.md 描述、手册自身 §5.5 与 §6 的两处 内部引用。另：表格里的裸节号会被 doc-links 判成本文自引用，查号表统一写成不带 § 的形态。 写说明过程又被自家门禁拦一次：gitlint 篇里引用报错样例时写了两个规则号字面量，被判形态不合规 → 改成中文描述，没有往台账里塞 reason 解决。 验证：纯文档与注释改动，不动代码，Program Size 不变，故不跑 @build/@test； check_doc_links --all --sections-strict **171 篇 0 问题**；id-check 增量拦截通过； pre-commit run **RC=0 / 13 项 Passed**；28 个改动文件字节卫生 **0 异常**（无 BOM、无 CR、 无 U+FFFD、均 LF、无行尾空白）。 |
||
|
wandering1
|
871ace422b | docs(门禁说明): 统一第八节标题措辞，新增模块单测的入口写在标题上 | ||
|
wandering1
|
dc44c1e54e |
docs(门禁说明): 补齐 23 篇逐项门禁文档，每种门禁一篇含限制与盲区
用户诉求原话："现在门禁都在干什么，我一概不知。" 原有文档回答"有哪些钩子、怎么配"，回答不了 "这一条到底在拦什么、什么时候会骗我"。本目录按**每种门禁一篇**补齐 23 篇（39 个 hook id 全覆盖： 16 个主机单测是同机制 16 实例合一篇；cppcheck 与 test-cppcheck 是同工具两套范围合一篇）， 文件名用 hook id，与提交输出里的名字一致、可 grep。 八段固定结构：查什么 / 为什么要它（拦下过什么真事）/ 触发面 / 报错怎么读 / 好处 / **限制与盲区** / 豁免与基线口径 / 改门禁本身要注意什么。最后一节是这批文档存在的理由—— 只看"拦了什么"的文档会让人以为绿就是对的；本仓三个增量拦截门禁（layer-deps 6 条、bsp-err 38 条、 id-check 台账 640 处）的绿灯含义只是"没比上次更差"。README 另立"三种拦截姿态"一节：改写型 / 硬拦截 / 增量拦截，分清才知道报错时该改代码还是该还基线。 有实证的地方全部带数字，没实证的地方直接写"预防性、未记录到实际拦截案例"（不编故事）： · cppcheck：把 simulator/ 纳入受检后立刻揪出 sim_syslog.c 真实空指针；test/ 曾有 s_rx_buf 使用先于声明；**并记入两条实测负结果**——它对 14 处丢弃 HAL_SPI_* 返回值与"未初始化局部量 进 P_FAIL 判定"一条不报（这正是 consume-result 的由来）。 · lv-conf-sync：漂移导致 64,576 B 死代码入库（旧镜像的 23.5%），且 golden 跑的是模拟器那份配置。 · cubemx-survival：2026-09-29 一次重生成覆盖 4 处定制（P0×1+P1×2+P2×1），且不报编译错。 · registration-check：rs485_task.c、lftpd_log.c 两处都没注册 = 从不参与编译的死代码；第四类 "页面描述了但没接进 s_defs[] 表"编译链接全过，前三类完全照不出。 · test-suite-switch：实测已提交的 HEAD 里 TEST_SUITE_CH395F 就是开着的，.map 含 34 处 test 代码。 · task-table：2026-09 两张表都比源码落后一大截（写 2048/4096/…/16384，实际 1024…512）。 · mem-numbers：2026-09-26 复核，文档写 82,048 B / 62.6%，实际 87,040 B / 66.4%；Flash 写 249,432 / 23.8%，实际 261,932 / 25.0%。 · ui-golden：注入 .top_y +3 像素 → golden FAIL 点名"1366 px 差异"、退出码 1；并把"有基线 ≠ 有门禁"与"逼人 --no-verify 的门禁等于没有门禁"两条选型依据写进去。 · check-yaml：本仓已移除的 always 键只告警 Unexpected key(s) 然后忽略——配置"看起来生效其实没 生效"而本门全绿，所以验收方式是实跑看目标钩子是 Passed 还是 Skipped。 · no-mojibake：types: [c] 只管 C/H，**文档侧乱码无人管**——覆盖面与需求错配定性写进限制一节。 盲区写法示例（每篇都要求写真实限度，不留空）：layer-deps 只查直接 include、按 basename 匹配、 不查是否真的用到；font-charset 管不到运行期拼出来的字符串与配置文件里的字；host-unit-tests 用宿主 编译器、桩是第二份真相、include_dirs 手写、没有对应钩子的模块等于零回归；mem-budget 的 92% 是管理 阈值不是安全余量、.map 缺失即"通过式跳过"；registration-check 不看条件编译与注册指向是否正确； coding-standard 的 CODE-RULE-17 在无配对头时跳过、规则编号 14 作废不回收。 写文档过程自己被自家门禁拦了两轮，都按规矩改而不是绕过： ① doc-links 拦下我自己——我在解释"写 §数字 而没紧邻文档名会被判成本文自引用"这段话里，正好 就犯了这个写法（两处），另有一处示例输出未标记；改成正例写法 + [示例] 标记。 ② id-check 拦下 7 类新账：示例报错行里的号、档号引用未紧邻文档名、说明"裸形不合规"时自己写了 裸形。全部改成平实描述或补文档名、给样例加 [示例]，没有一条是往台账里塞 reason 解决的。 这两次本身已写进相关篇目的"限制/变更记录"，是这套文档最实在的注脚。 同步：手册 pre-commit使用说明.md 的 §2 顶部加指针（逐项详解已迁往本目录；两处收敛为"通用机制 + 总览 + 指针"排在 docs/门禁说明/README.md §4 的下一步，并注明收敛要按内容重指既有引用——只核编号 存在与否不够）；README 索引 23 行状态全部置为已写、文档列改为可达链接。 验证：纯文档，不动代码与构建产物；check_doc_links --all --sections-strict **171 篇 0 问题** （新目录 24 个文件的内部链接与跨文档引用都纳入判定）；id-check --strict 增量拦截通过；本次受影响 文件 pre-commit run **RC=0**；24 个文件字节卫生 0 异常（无 BOM、无 CR、无 U+FFFD、均有尾换行）。 |
||
|
wandering1
|
3488617bc9 |
docs(门禁说明): 新建逐项门禁文档目录，先落索引 README 与 bsp-err 首篇
用户的原话是："现在门禁都在干什么，我一概不知。" 现有文档只回答"有哪些钩子、怎么配" （docs/代码规范/pre-commit使用说明.md），回答不了"这一条到底在拦什么、什么时候会骗我"。 故新开一个目录，**每种门禁一篇**，八段固定结构：查什么 / 为什么要它（拦下过什么真事）/ 触发面 / 报错怎么读 / 好处 / **限制与盲区** / 豁免与基线口径 / 改门禁本身要注意什么。 **最后一节是这批文档存在的理由**：只看"拦了什么"的门禁文档会让人以为绿就是对的。而本仓 三个增量拦截门禁（layer-deps 6 条、bsp-err 38 条、id-check 台账 640 处）的绿灯含义只是 "没有比上次更差"。 索引按 39 个 hook → 23 篇规划（16 个主机单测是同机制 16 实例，合一篇；cppcheck 与 test-cppcheck 是同工具两套范围，合一篇），文件直接用 hook id 命名，与提交输出里的名字 一致、可 grep。README 另有一节"三种拦截姿态"——改写型 / 硬拦截 / 增量拦截——分清这三类， 报错时才知道该改代码、还是该还基线。钩子清单、files 范围、pass_filenames 全部从 .pre-commit-config.yaml 实测解析（39 个 id：官方 5 + gitlint + local 33），不是手抄。 本次交付：索引 README + 首篇 bsp-err.md。首篇里把今天踩过的坑全写进"限制与盲区"，共 10 条， 例如：只扫 Drivers/BSP（App 层同类问题仍无人管）；consume-result 只认单行整句的裸调用， 跨行写的调用按正则形状测不到；must-use 名单靠"返回类型 + 注释关键词"启发式，注释不写 "错误码/失败"就漏、改名就能绕开规则；HAL 族是固定清单，清单外的返回 HAL 状态的函数不在 名单里；return-doc 的判据是"注释块里出现『返回值』字样"，**散文里出现这三个字也会放行** （本仓真发生过两条靠函数说明里的关键词误判通过）；基线键带出现序号，--prune 只报"消失"、 不会报告某处只是搬了家；改标签名等于改基线键，必须原子完成。在册数量与构成按当前基线 逐条数出来写（38 = consume-result 37：gd5f2gq5ue.c 28 含 14 处 HAL 丢弃 + 14 处自家原语、 ui_net_sink.c 6 全为 net_close、rs485.c 2、nand_ftl.c 1；err-type 1 为 bool ui_content_page_open()）。 同步指向：AGENTS.md 提交门禁一节改为"每种门禁一篇详解 → docs/门禁说明/README.md"，通用 机制仍指 pre-commit使用说明.md；docs/README.md §7.1 增加索引行；.pre-commit-config.yaml 的 bsp-err 注释块顺手更正（原文还写着"三条规则""现 1 条""只能靠书写约定兜着"，均已过时）。 迁移状态用索引表的"状态"列跟踪；全部写完后 pre-commit使用说明.md §2 收敛为通用机制 + 总览，同一事实只留一处（docs/文档规范.md 的要求）。 验证：纯文档与注释改动，未触碰构建产物；check_doc_links --all --sections-strict 149 篇 0 问题（新目录的相对链接、跨文档章节引用都能判定）；bsp-err 仍 38/38/0；本次受影响文件的 pre-commit 全绿 RC=0；两份新文档字节卫生 ok（无 BOM、无 CR、无 U+FFFD、有尾换行）。 |
||
|
wandering1
|
2575177e81 |
refactor(gate): bsp-err 四项检查改用自描述标签，废掉 R1~R4 这组撞车代号
纯改名，检查行为一个字没动：规则逻辑、阈值、豁免形状全部原样。 改名原因（用户一句「R4 到底是什么」问出来的）：R1~R4 是我在 check_bsp_err.py 注释里 自造的序号，而这个裸形在本仓另有含义——R1~R8 已在 scripts/id_registry.json 登记为 "专项风险"的文档内编号（保护规划与看门狗的风险表都在用），带连字符的那一族又是审查 报告的可靠性 / 内存优化项编号（编号规范 §1 的"连字符承载语义"一行正是这么写的）。 **同一个裸形四种意思**。最刺人的一点：编号门禁**不会报**这种撞法，因为编号规范 §4.3 已把这些裸形声明为"同号不同义"、走 collides_with 白名单，校验 4 不计事故——同一天里 我起的另一组自造号被当场拦下、这组代号却一路绿灯，差别不在我做对了什么，而在白名单 挡的是"事故"、不是"可读性"。 新名同时是基线键的第二字段（格式 文件|标签|名字）： · err-type 错误通道不外泄（对外接口不拿 HAL_StatusTypeDef / bool 当成败） · timeout-name 超时宏不取负值 · return-doc 公开函数必须写「返回值：」 · consume-result 返回值不得裸丢弃（须接住或显式 (void)） 老名对照：R1=err-type、R2=timeout-name、R3=return-doc、R4=consume-result。 同步面：脚本里的规则码与 38 条基线键的字段**一起换**（中途不跑 --prune，否则改名会被 读成"38 条全还清 + 38 条新账"），换完 --emit-baseline 复核仍是 38/38/0、RC=0。现状类 文本全部换新名：AGENTS.md、pre-commit使用说明.md §2.27（新增"检查项叫什么"一行含老新 对照与撞号说明）、bsp_err.h 边界纪律、报告 §0.4 / §9 / 附录 A，以及代码注释里的 5 处 （gd5f2gq5ue.c/.h、nand_ftl.h、ui_menu_tab.h）。已提交的变更记录行里的老名按"冻结历史 不回改"处理，以 §2.27 对照行为准。ui_menu_tab.h 带 BOM，Edit 又剥掉、已按原样补回。 写说明文字时又被编号门禁拦了一次：我为了举例"老名撞车"，在那段话里写了两个编号字面， 被判"未紧邻文档名 / 未登记前缀"共 3 类新账——连批评自造编号的段落本身都在自造编号。 改法是不写号、只描述形态并指向权威条目。 验证：@build **0 错 0 警告**，Program Size 与上一笔**逐字段相同**（Code 213,676、RO 18,860、RW 1,188、ZI 131,500）→ 证明确为注释与文案，故不跑 @test（无指令变化）； pre-commit run 全绿 **17 项 Passed**；check_doc_links --all --sections-strict 147 篇 0 问题（中途我自己写的 §4.3 没紧邻文档名，被判成本文自引用，已补全路径）；9 个文件字节 卫生 0 异常（UI 头 BOM 仍在、无 CR、无 U+FFFD、均有尾换行）。 |
||
|
wandering1
|
d9b887c0af |
feat(S-5 R4): 返回值不得裸丢弃成为机械检查，并修掉照出的第一处 ECC 静默降级
B 的第一步（加规则）与第二步（修最小最值的那处）。用户裁定"B 按你说的进行"。 **为什么只能项目侧自己做**（两条实测负结果，已写进 §2.27 与 bsp_err.h 边界纪律 4）： · ARMCC v5 对 __attribute__((warn_unused_result)) 不生效（凌晨在 rs485_transmit 上实测：属性 在位、调用点裸调不接返回值，构建仍 0 错 0 警告）； · cppcheck 也照不出来——按本仓自己的 --enable=warning,style,performance,portability 跑 gd5f2gq5ue.c，对 14 处丢弃 HAL_SPI_* 返回值、以及"未初始化局部量直接进 P_FAIL 判定" **一条不报**（它假定 gd5f_read_status(&status) 会写出参，而失败路径根本不写）。 结论：**丢弃底层传输的返回值，今天没有任何工具会响**。 **R4 上线即照出 37 条存量丢弃**：gd5f2gq5ue.c 29（14 处 HAL + 15 处自家原语）、net_socket.c 8、 ui_net_sink.c 4（net_close）、rs485.c 2、nand_ftl.c 1。按增量拦截老规矩入基线、只减不增—— 这是覆盖面扩大新暴露的历史债，不是新增违规；基线 19 → 1 → **38**。 **R4 自己被修三次（逐条记下，都是"规则比我想的更脆"）**： ① 首版漏判"裸调用行尾带注释"这种写法（正则的 \s*$ 卡死），而那恰是最常见的"带说明的丢弃" → 补可选注释分支，并做 6 条正/反例自检； ② 把 net_set_errno 八处误判成丢弃（它是 setter，返回 int 是状态回声不是调用成败）→ **按真实 反例把规则收窄**（谓词 + setter 两类豁免），而不是塞进基线洗掉假阳性； ③ must-use 名单只从**头文件**取，gd5f_set_feature 这类 static 原语整个在视野外——而下面那处 真窟窿恰恰是 static、靠人工才发现 → 名单扩到 .c 内 static 定义（同一套启发式），补完立刻 又照出 gd5f_bbt_save#1：**运行时标坏后 BBT 落盘结果被丢弃 = 坏块记账可能没持久化**，已入 基线记为待还，本步不动行为。 另修一处自己的排版误判：R3 原本要求注释块出现字面"返回值"，规范 V1.0 允许列对齐写法 「返 回 值：」→ 改为忽略空格匹配（门禁不该规定排版）。 **修掉的第一处真窟窿**：bbt_rebuild 的注释写着"无论扫描成败都须恢复 ECC，否则后续 I/O 在无 ECC 下运行"，而它下面 gd5f_set_feature(0xB0,…) + gd5f_wait_busy(100) **返回值全丢**：SPI 一抖 ECC 就保持关闭，且 gd5f_check_ecc() 在 ECC 关闭时恒读"无 ECC 错"——整条链再没有任何信号。 补法复用 init 路径的 E-10（写完回读 B0h 验 ECC_EN 位真生效，"写了但没生效"与写失败同罪）， 并把"关 ECC 失败"改成**立即中止**（此时 ECC 仍开着，是安全侧；带着 ECC 去扫 spare 反而会把 厂标好块误判成坏块，"重建 BBT"变成制造坏块）。恢复失败时按 (void)gd5f_bbt_load() 回读盘上 副本，避免 RAM 留着"比盘上更新"的表而下次上电又退回旧表。 **一条定位纠正（差点把修复记大）**：查链接映射发现 Removing gd5f2gq5ue.o (i.gd5f2gq5ue_bbt_rebuild), (604 bytes)——该函数在产品镜像里**根本没被链接**（产品构建无调用 者），只由 ENABLE_STORAGE_RECOVERY_TESTS 的恢复构建经 testTask 调用。所以本次修的是**恢复流程 自身的安全**（跑恢复时若 ECC 没恢复，设备会带着"已恢复"的结论在无保护状态下继续跑），不是 现场日常路径；相应地镜像 Code 的 +28 B 也不是它带来的（未逐字节追，线索是 gd5f_private_get_feature 由单调用点变多调用点、内联决策可能变化）。验证因此不能只跑产品构建： 临时打开 TEST_SUITE_STORAGE + ENABLE_STORAGE_RECOVERY_TESTS 编一次（0 错 0 警告且该函数不再 出现在 Removing 列表），随即还原两处开关并重编产品构建核对（test/board 无残留差异）。 **编号门禁把我自己的自造编号拦下了**：我起初用 B-1/B2/B3/B4 标记这批缺陷，id-check 报"未登记 前缀"13 处（且 B2/B3/B4 会与真实里程碑号撞号）→ 全部改写成平实语言。这是那条"注释与文档里 不许用没人检索得到的内部阶段编号"的规则第一次在提交前拦住我，规则是对的。 验证：@build 0 错 0 警告，Code 213,648 → **213,676**、RO 18,860、ER_IROM1 **232,536 B / 22.2%** （ROM 合计 233,724 B；RAM 逐字段不变）；ram_report 重生成 + ram_baseline.py --update + 配图常量 同步（mem-numbers Passed）；@test **PASS**（到 net init: OK 682 ms、[ERR] 0）；R4 两处**探针 实证**（临时加一条裸调用 → 立刻成为新增并 RC=1；还原 → 38/38/0）；--prune 点名本次还掉的 2 条 已删；pre-commit run 全绿 15 Passed；check_doc_links --all --sections-strict 147 篇 0 问题； id-check --strict 增量拦截通过。 文档：AGENTS.md 与 .pre-commit-config.yaml 的 bsp-err 口径（四条规则、基线 38）； pre-commit使用说明.md §2.27（R4 全量口径 + 两条负结果 + 名单来源与豁免形状 + 单行限度）； bsp_err.h 边界纪律 4；报告 §0.4 / §5.1 / §9 / 附录 A + 变更记录；存储维护与容量恢复.md 新增 §4.3（运维判据：出现 ECC restore FAILED / ECC not enabled 即本次恢复**不算完成**，须断电重启 重走 init，不许接着 nand_ftl_format() 当作已修好；并记明该函数产品镜像不链接）——顺带修该文 结构缺陷：原 ## 5. 变更记录 误插在 §4.1 与 §4.2 之间，会让 §4.2 变成 §5 的子节。 |
||
|
wandering1
|
cc2966319a |
docs(S-5): 补齐 16 条返回值约定，bsp-err 基线 19 → 1，并修门禁自身误判
A（还债）先行，B（GD5F 的 SPI 失败被吞成成功）另波处理。本笔不改行为：@build 的 Program Size 与上一笔逐字段相同（Code 213,648、RO 18,860、RW 1,188、ZI 131,500）。 **补齐 16 条「返回值：」约定，bsp-err 存量基线 19 → 1**： · gd5f2gq5ue.h 九个 SPI 原语（wait_busy / write_enable / read_status / page_read / read_from_cache / program_load / program_exec / block_erase / check_ecc） 写全规范五要素， 并把**每个函数能返回哪些码**写死：哪一个是"可重试"的 GD5F_WAIT_EXPIRED、哪一个才是 器件自认坏块的 P_FAIL/E_FAIL、失败时出参为什么不可信（E-42 同族）。 · nand_ftl.h 从零散三行补成带模块头，并明写 **nand_ftl_init() 的 −1 抹掉了失败类**： 分类目前只在失败点进日志，要按类分支需要 C4 快照（现无消费者故未做）；同时警告"不得 把 −1 解读成卷坏了可以重格式化"（E-31 的教训正在这条上）。 · ui_menu_tab.h 五个表查询 API 由行尾短注释升级为完整块（含"越界返回 false 是保守取 只读"、"宁可按一张错表导航失败也不要按错表导航成功"这类判断依据）。 **修掉门禁自己的一条误判口径**（本笔最该记的）：R3 原本要求紧邻注释块里出现字面"返回值"， 而规范 V1.0 允许列对齐写法「返 回 值：」。后果有两层：① 合规写法被判违规；② 反向更糟—— gd5f_write_enable / gd5f_read_status 两条**早就"通过"了**，原因竟是它们的**函数说明**里顺口 写了"返回值"三个字，而不是真有一行返回值说明。**一条会因为散文里出现关键词而放行的规则， 等于在奖励运气**。修法是在块内忽略空格后再匹配关键词（排版选择不是违规），并在注释里写明 为什么不许把"必须写成不空格的形式"写进规则。 剩余 1 条刻意保留：bool ui_content_page_open()。它与"补注释"不是一档事——要改签名、要处理 3 个调用点（ui_menu.c:138/192/196 **今天三处全部丢弃返回值**，即"按 ENTER 开页失败是静默的" 这件事现在没人知道）、且 UI 源码双端编译（模拟器同一份），验证面是"重建模拟器 + 像素回归 + 真机逐页进菜单"。这不是还债，是独立一波改动，留档待决策。UI 三个文件带 BOM，Edit 会静默 剥掉 → 已按原样补回 3 字节（AGENTS 铁律：丢 BOM 后 ARMCC 按 CP936 解码，中文报 #870-D）。 **更正我自己写进文档的一条错话**：S-5 各条里我把 GD5F_SPI_TIMEOUT 100 记成"自旋圈数（改 分频时长会变）"。这次逐行核它 12 处用法，**全部是 HAL_* 超时参数或 HAL_GetTick() 差值 → 它也是毫秒**。真问题降级为"单位没写进名字（缺 _MS 后缀），读代码必须回实现里查单位"。 osWaitForever 与 HAL_MAX_DELAY 同为 0xFFFFFFFFU、以及 *_BUSY_TIMEOUT = -2 其实是返回码这两条 仍然成立（后者已改）。现状类条目（报告 §0.4、bsp_err.h、pre-commit使用说明.md §2.27、脚本 文件头）已全部改准；**已提交的变更记录行仍写着旧说法——按 §8.1 冻结历史不回改，以本笔新增 的更正行为准**。 验证：@build 0 错 0 警告（尺寸同上，故**不跑 @test**——无指令变化，跑它没有新信息）；受影响 文件的 17 个钩子全 Passed（含 ui-golden 像素回归、cppcheck、编码规范、bsp-err 1/1/0 且 --prune 干净）；check_doc_links --all --sections-strict 147 篇 0 问题；id-check --strict 通过； 9 个文件字节卫生 0 异常（UI 头 BOM 仍在、无 CR、无 U+FFFD、无行尾空格、均有尾换行）。 口径同步：AGENTS.md、.pre-commit-config.yaml、pre-commit使用说明.md §2.27 的基线计数 19 → 1； 报告 §0.4 / §9 / 附录 A 与变更记录两条（还债一条、更正一条）。 |
||
|
wandering1
|
78248a1cdf |
feat(S-5): 收编 SD2506/TPAFE 并给 dhara 失败分类，门禁基线 19→17
前一笔立契约与门禁（`Drivers/BSP/bsp_err.h` + `bsp-err` 钩子 + RS485 试点）；这一笔按用户
指定顺序 C3 → C1 → C2 把三个模块真正收编，并让存储失败第一次变得可读、可分类。
**C3 · SD2506 整模块（11 个公共 API + 6 个内部 helper）**：三枚私有宏 `SD2506_OK`/
`SD2506_ERROR`/`SD2506_I2C_ERROR` **删除而不是留别名**——留别名等于新代码还能用旧形状，
把迁移洗掉；编译器替我们找全所有调用点。新增 `sd2506_err_from_hal()`，**把 I2C 超时从
"和没人应答共用一个 −2"里拆出来归成 `BSP_ERR_TIMEOUT`（可重试）**——SD2506 是启动链第一站、
I2C1 上电时序敏感，这是本波唯一真正的语义改善，不是改名。`sd2506_init` 的 charge 寄存器
**回读校验不符**原返参数类错误，改归 `BSP_ERR_IO`（那不是调用方的错）。
**C1 · 同形两义**：`GD5F_BUSY_TIMEOUT` → `GD5F_WAIT_EXPIRED`（**值 −2 不变**，纯消"名字叫
TIMEOUT 其实是返回码"）。**GD5F 私有码集整体收编刻意没做**：169 处引用里 48 处在板级套件、
还要动 Trap 记录用词，属另一波带真机+套件回归的工作，不夹带。TPAFE5160 收编 23 处：
`BUSY_TIMEOUT → BSP_ERR_TIMEOUT`、`ERROR → BSP_ERR_PARAM`（**同值 −1，行为零变化**）、
`FRSTDATA_ERR → BSP_ERR_NO_DEVICE`（E-44 的本义就是"芯片没驱动 DB 总线"，归到器件无响应比
私有 −3 有用，且避开与 `BSP_ERR_TIMEOUT` 撞值）。实测 `tpafe5160.o`/`gd5f2gq5ue.o` 的 Code
增量为 **0**——改名不产生一条指令。
⚠ **`tpafe5160_snapshot()` 刻意不套成败码**：它是 1=有新帧 / 0=无新帧 / −1=参数错 的三态
**状态**返回，0 不是错误而是"这一拍没有新数据"，强行收编会把慢消费者的正常路径变成失败。
顺带订正我上一版在 `bsp_err.h` 的断言——"本层只有 `net_*` 把数量与错误挤同一返回值"是错的，
`snapshot`/`adc_input_poll` 就是第二族；两族现都已写明并各注保留理由。
**C2 · FTL 坍缩点分类**：`ftl_flush_cache`/`ftl_read_page` 不再把 dhara 失败压成
`GD5F_ERROR`，
按**处置差异**分三类，并在最早同时知道 LPN 与原始码的位置就地打印：`ECC`/`TOO_BAD` →
`BSP_ERR_CRC`（页级，重试或换页，不代表卷坏）；`JOURNAL_FULL`/`MAP_FULL` →
`BSP_ERR_NO_SPACE`（介质健康但块池/日志见底，此时重格式化只是把问题推回去）；
`BAD_BLOCK`/`RECOVER`/`CORRUPT_MAP`/越界 → `BSP_ERR_IO`（完整性故障，保卷 + 上报，不许自愈
重格式化）。这与 **E-31** 是同一条纪律的两端。可读名用自建短表：**本仓 dhara 没有编
`error.c`，用 `dhara_strerror()` 会直接链接失败**。`disk_read`/`disk_write` 仍回
`RES_ERROR`
（FatFs 契约）；要让 defaultTask 卷健康探针按类分支还差跨调用存活的快照 → C4 待还。
**两次靠核实拦住的自我错误**：① 我一度认定 `DBG_ERROR("... err=%d", err)` 是把结构体塞进
varargs 的格式 bug——核 `Lib/dhara/error.h` 后确认 `dhara_error_t` 是 `enum`（标量），那行日志
本来合法，改了反而是引入错误；② `bsp-err` 一次 `replace_all` 越界把 8 处 **GD5F 码空间**的
判据改成 `!= BSP_OK`（数值同为 0、无行为变化），但那正是"把两个码空间混起来"，已逐一还原。
`cppcheck` 亦抓到 `cls` 声明作用域过宽，已收进失败分支。
**验证**：`@build` 0 错 0 警告（`Code` 213,648、RO 18,860、`ER_IROM1` 232,508 B /
22.2%、
`ROM 合计` 233,696；**RAM 三项零增量**）；`@test` PASS（692 ms，烧入戳 `Oct 23 01:35:32`）
且逐条读到被改模块的锚点：`SD2506 init: OK (ret=0)` 与 ID/时间/温度/电池四条读回正常、
`ADC init: OK`、`NAND init: OK`、`Map resumed: 14094/97504`、`adc=` 帧计数持续递增（证明
snapshot 三态未被改坏）、`[ERR]`/Fault/FAIL 0 条。主机单测：系统时钟 100/100、dhara NAND
移植层 149/149（两者都因本次改动需补 `Drivers/BSP` include 路径，补后在钩子内实跑 Passed）。
`pre-commit run` 全量 RC=0（20 个实跑钩子 Passed）；`bsp-err` 基线 **19 → 17**（还掉两个
`*_BUSY_TIMEOUT = -2`）、`--prune` 干净；`doc-links --all --sections-strict` 147 篇
0 问题；
`id-check --strict`、`layer-deps`、`mem-numbers`、`mem-budget`、`ui-golden` 全过；33
个文件
字节卫生 0 异常（无 CR / 无 U+FFFD / 无行尾空格 / 均有尾换行）。
**口径与数字联动**：新增 `docs/架构设计/STM32F4-Base存储架构说明.md` §10.4（三类码与处置
理由）；`pre-commit使用说明.md` §2.27 与 `AGENTS.md` 基线计数 19 → 17；TPAFE README、
GD5F 测试指南与 Trap 记录均**保留旧名留痕**以便对旧日志；配图桶按 .map 对象级增量重算
（`dhara/FTL` 10,931 → 11,222，+291 全部落在 `nand_ftl.o`；应用代码/UI +36 落在
`app_main.o`；其余散量入"其他"7,557；桶和 = Code+RO 断言通过、文本溢出 0）；
`ram_baseline --update/--write`、`ram_report_20261023.md` 快照、报告 §1.3/§5.1/§5.4
与
部署文档 §3.3 数字全部同步；报告 §0.4/§9 的 S-5 状态改为 🟡 主体已落地。
|
||
|
wandering1
|
8d3349c587 |
docs(存储维护): 记录自检台账清零与 flushchk 孤儿清理，修表格断行
设备侧动作（不动仓库内容）与文档同步，一并落在这里。 **① 自检台账清零，重建 S7 审计基线**：`/log/selftest.log` 里 29 条历史记录（**16 × `watchdog` `reset` + 13 × `heap low water`**，跨度 `2026-10-10 09:24:12 → 2026-10-14 06:55:02`，看门狗 引入期与堆迁移期留下，两案后来都已结案）按用户决定删除。**安全判据**：`sys_log_mcu.c` 是每条 记录开-写-关（`f_open(FA_WRITE|FA_OPEN_APPEND)` → `f_write(64)` → `f_close`），**不持常驻 句柄** → FTP 侧 `DELE` 不会撕裂，下次真有故障时自动重建。删前把导出副本留档（1856 B = 29×64）。 **② 顺带清掉一个孤儿**：`/log/flushchk.bin` 32,768 B，全库零引用——已退役的 flush 诱导实验 留下的（`sys_log_mcu.c` 注释里"旧称 flush 诱导"就是它）。**删前先 RETR 出来验过内容**：256 种 字节值全部出现、前 64 字节全 `FF` → 一份 0..255 图案的写盘校验填充，无任何产品语义；留档后再 `DELE`。判据同 §4.1：**先知道删的是什么，再删**。 **清理后 `/log` 只剩三条、全是产品数据**：`run.log` / `wdev.log`（掉电取证）/ `soe.log` （B9 SOE）——这三条是固件在写的活文件，容量护栏由固件自己管，**别手删**，文档里也这么写。 **验收（两条判定路径都要过才算基线干净）**： · `--require-selftest-pass`（默认 `this-run`）→ PASS，`SELFTEST_BASELINE: 既有记录 0 条` （`status=absent`）； · `--selftest-scope all`（累计硬口径）→ **PASS**：`selftest: no fault record`——**清零前这条是 `29 fault record(s)` FAIL**，也就是那条判据在台架上从来没可能通过；现在真的能用了。 · 之后再跑 `@test` → PASS（699 ms、`[STACK] heap` 等锚点齐全、无 `[ERR]`/Fault）。 设备侧无此文件时 lftpd 回 450，被按"台账干净"处理——这条映射过去是假绿来源，现在是有意的正常 路径（见 `../架构设计/STM32F4-Base存储架构说明.md` §10.3 与 S7 判定表）。 **修自己的排版 bug**：上一笔（`23daa3d`）把 §4.1 的变更记录行拆成了三行——Markdown 表格行必须 单行，会渲染成断裂的表。已合并；本次两条变更行（§4.1、§4.2）都是单行。 门禁：`check_doc_links.py --all --sections-strict` 146 文档 0 问题；`check_ids.py --strict` 增量 拦截通过（可判定 82.82%）；文件字节卫生 BOM 无 / CR 0 / U+FFFD 0 / 无行尾空格 / 尾换行。本轮无 固件与脚本改动，故不跑 `@build`（`@test` 已跑，镜像仍是 `23daa3d` 那笔的构建）。 |
||
|
wandering1
|
23daa3d9ad |
chore(台架): 删零引用的一次性探针、修可信判据工具登录、清理口径落文
两件事一起做：把"没人用又已经失效"的一次性探针清掉，把"台架现场脏"这件事的口径写进文档。 **删除（5 个文件，全库零引用）**：`MDK-ARM/ftp_retr_abort_probe.py`（其职能已被 `test/host/ftp_abort_probe.py` 取代，Trap 记录引用的也是后者）与整个 `MDK-ARM/bench_diag/` （4 个诊断脚本：abort_gap / pcref / recover / sink_recycle）。删除判据三条同时成立：① 全库 `git grep` 除自身外零引用；② 自 2026-10-11 设备启用 FTP 鉴权起，脚本里写死的匿名登录必然 530 → 已经跑不动 11 天；③ 都是"跑一次拿现场"的诊断件，价值在结论而结论已沉淀进 Trap 记录。 需要时从 git 历史取回（`test/host/README.md` 与 `MDK-ARM/README.md` 都写明了这一点）。 **刻意保留并修好**：`MDK-ARM/ftp_freeze_probe.py`——它不是一次性件： `CH395F_Trap_Records.md` 拿它当"177 轮 SHA-256 全匹配"的**可信复现配方**、 `BSD_Socket_API_使用指南.md` 把它列进排障判据、`Drivers/BSP/NET/lftpd/README.md` 也指它。 删掉它等于删掉文档指定的真值工具。改为 `--user/--password`（默认出厂 admin/admin，模块常量 `FTP_USER`/`FTP_PASS`，两处登录点都读它），实测一轮：`ROUND 1 size=4096 stor=OK retr=OK hash=MATCH`、`SUMMARY pass=1 fail=0`——修前它连 530 都过不去。 **台架设备清理（不动仓库内容）**：`/` 根目录实测残留 **27 个探针文件 / 262 KB**（`AB000x`、 `A000x`、`R000x`、`SZ2K~64K`、`E12A`、`DIAG_A`、`PP0~PP4`——正是刚删的那批一次性探针留下的）。 逐个 `DELE` 后剩 `LOG` + `CONFIG.INI` + `PROT_SET.BIN` 三条目。**判据：只删显式点名的文件， 绝不 glob**；保留清单必须含 `/config.ini`（网口 + FTP 鉴权）、`/PROT_SET.BIN`（保护定值 blob， `PROT_SET_BLOB_SZ` = 176 B，删了等于定值清零）、`/log` 目录。清完两步验收：`@test` PASS （630 ms，定值巡检与配置加载都在这条链上）+ `ftp_list_fill_test.py` PASS（29 行 / 1851 B / 完成回包 226，26 个新文件全列出）。口径写进 `docs/测试说明/存储维护与容量恢复.md` 新 §4.1 （明确它是"动作 D 清文件"，与 A 重建 BBT / B 全片擦除 / C 容量恢复区分——那三个会丢卷内容）。 门禁：`py_compile`（freeze 探针）通过；`check_doc_links.py --all --sections-strict` 146 文档 0 问题（删除的 5 个文件确认无任何文档引用）；`check_ids.py --strict` 增量拦截通过（可判定 82.82%）；`layer-deps` 通过；4 个改动文件字节卫生 BOM 无 / CR 0 / U+FFFD 0 / 无行尾空格。 本轮无固件改动，未跑 `@build`（设备侧清理后的 `@test` 已跑，镜像仍是上一笔的构建）。未推送。 |
||
|
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 / 无行尾空格。未推送。 |
||
|
wandering1
|
4c21cff753 |
fix(lftpd): 对端行为不再打 [ERR]——新增 lftpd_peer 级别并划清级别边界
现象：抓自检台账基线那次 FTP 会话一结束，设备就打 `[ERR] [FTP] error reading next command`， 本次 `@test` 直接 FAIL（Forbidden 含 `[ERR]`）。查下去发现 lftpd 把**全部**异常路径一律按 error 级打，其中九处其实由外部输入决定：客户端关窗口、连上就走、PASV 后不建数据连接、 运维改 IP 触发监听重建。两条代价：① 任何人"连 21 端口一下就断开"就能把一次启动测试打成 FAIL；② 同样的动作可以**无限制造固件级 ERROR 日志**——日志面与门禁面都可被外部驱动， 工业现场过不了审。 **做法**：`private/lftpd_log.h` 新增 `lftpd_log_peer()`（info 级，带 `[FTP]` 前缀），而不是 就地改成 `DBG_INFO`——让"谁才算真故障"在读代码时一目了然，也防止后来者顺手把对端行为升回 error。降级的九处：控制通道被对端关闭（原 `error reading next command`，改为 `control channel closed by peer (ret=%d)`，措辞原先把正常收尾写成故障、误导过排查方向）、 发送 220 前对端已走、`listener rebuilt`（网络重建，原因由 accept 层自己记）、四处 `data accept failed`（PASV 后没来数据连接）、`accept timeout`。 **刻意留在 error 的**：create/bind/listen/取端口失败、写通道失败、文件打开失败、 `DOWNLOAD/UPLOAD FAILED`（对端中途退出确实让一次传输没走完 = 数据完整性事件， `../问题记录/CH395F_Trap_Records.md` 的中止家族要靠这些锚点定位）、 `data listener disarmed`（控制连接还活着而我方数据监听已不在服役 = 本侧异常，就地注明）。 **实测划清的边界**：客户端**干净收尾**（发 `QUIT` 或 FIN 半关）现在整条链路没有任何 `[ERR]`； 但 **RST 硬拆**（`SO_LINGER` 清零 / 进程被杀 / 拔线）仍会留一条 `[ERR][NET] sockN TIMEOUT`—— 那是 net 层的套接字超时锚点，网络自愈架构判据要读它，不在本次降级范围。所以"采集窗口内别跑 `data listener disarmed`（控制连接还活着而我方数据监听已不在服役 = 本侧异常，就地注明）。 **真机验证**：`@build` 0 错 0 警告；`@test --require-selftest-pass --device-ip` → **PASS** （基线 29 条 → 本次无新增；`net init: OK` 726 ms）；专门写了 RST 复现脚本（登录后 `SO_LINGER` 清零直接关）→ 串口得到 `[FTP] control channel closed by peer (ret=-1)`，**不再是 `[ERR]` 行**； 同一份日志里 QUIT 收尾的那次会话完全没有错误行。 体量：`Code` 213,236 → **213,264 B（+28）**、`RO` 18,580 → **18,652 B（+72）**（措辞变长）， 同一份日志里 QUIT 收尾的那次会话完全没有错误行。 `ZI` 131,500、`RW_IRAM1` 75,264 B 57.4% / `RW_CCM` 57,376 B 87.9% 全不变）。数字联动照做： 两份 `data/` 快照、`ram_baseline --update/--write`、`check_mem_numbers --write`、FLASH 配图 常量重算重生成（桶合计 = 231,916 与 `Code+RO` 相符；越界复查 0）、报告 §1.3/§5.1/§5.4 与 部署文档 §3.3 同步。 口径落文：新增 `docs/架构设计/STM32F4-Base存储架构说明.md` §10.3「FTP 日志级别划分：对端行为 vs 固件故障」（含两类的判据表与边界），并更新 `docs/测试说明/自动化测试流程.md` 的采集窗口警示。 顺手把 `private/lftpd_log.h` 工作区的 CRLF 混用归一回 LF（仓库里 blob 本来就是 LF，diff 无影响）。 门禁：`doc-links --all --sections-strict` 146 文档 0 问题、`id-check --strict` 增量拦截通过 （可判定 82.82%）、`mem-numbers` / `mem-budget` / `layer-deps` 全绿；改动文件字节卫生 BOM 无 / CR 0 / U+FFFD 0 / 无行尾空格。未推送。 |
||
|
wandering1
|
af5bad5609 |
fix(测试工具): 自检台账判据改为只看本次启动新增（修假绿）
接上一笔（FTP 凭据）之后，`@test --require-selftest-pass` 仍不可用——它其实是**三个 bug 叠
在一起**，这次一并收口。
**① 抓取失败被当成"设备干净"**：`_fetch_selftest_log()` 把"设备侧无此文件"（正常路径，
"仅故障才写"语义下干净设备本就没有该文件）和"连不上/登录被拒/FTP 故障"（结果**未知**）
都返回 `""`，调用方一律按"无记录 → PASS"处理。叠加上一笔修掉的匿名登录 530，这条门禁
**从写下那天起一次都没真正读到过那个文件**。现在 fetch 返回 `(路径, 状态)`，状态 ∈
{ok, absent, error}，三者分开判。
**② 判据本身判不了"一次启动"**：`/log/selftest.log` 是 **512 条环形累计历史**（设计文档
§4.2 容量表），而旧判据是"文件非空即 FAIL"——在任何做过故障注入或长跑的设备上**永远不
可能 PASS**。本次实机抓到的 29 条记录，时间戳全是 2026-10-10 ~ 10-14，没有一条来自本次。
新判据 `--selftest-scope this-run`（默认）：**烧录之前**先取基线，启动后再取一次，只把
"基线最后一条之后"的记录交给判定（差集落成临时副本，命名落在 `selftest_log_*.log` 里，
才会被 `--keep-out` 的保留规则收走）。
**③ 取基线本身会污染本次启动日志**（我这次实测踩到的）：抓基线是一次真实 FTP 会话——
设备把 `USER/PASS/RETR` 打到串口上，客户端退出时还多打一行 `[ERR] [FTP] error reading
next command`。放在 `open/clear`（采集武装）之后，这些行就落进本次启动日志：Forbidden
`[ERR]` 命中 → 本次 FAIL，开机耗时从 612 ms 被拉到 **7997 ms**。所以基线固定在 open 之前，
并把这条写进文档当规避口径。
**判定表**（`docs/测试说明/自动化测试流程.md` §自检结果判定整段重写）：无此文件=PASS；
本次无新增=PASS；本次有新增=FAIL；连不上/登录被拒/FTP 故障=**FAIL**；既无 `device_ip`
又无 `--selftest-log`=**FAIL**（要求判定却没有数据源，不能再"视为无记录"）；基线最后一条
被 512 条环覆盖（更新量 ≥ 环容）= **FAIL**（不拿"看不到"当"没有"）。后四种"判不了"由调用
方在 `verify()` 之后强制收口成 RC=1——否则标记全中就把"没判"读成"判过了、没问题"。
`--selftest-scope all` 保留旧的累计口径（审计 / 第一次建基线用）；给了 `--selftest-log`
（本地副本）就没有基线可比 → 自动降级为 all 并打印一行说明；FTP 凭据 `--ftp-user`/
`--ftp-pass`（config `ftp_user`/`ftp_pass`，默认出厂 admin/admin）。退出码 1 的含义、
`verify_log.py` 的语义条目、SKILL.md 参数表（+2 行）、config.example.json（+3 键）同步。
**真机三跑，三条路径各自验过**：
· 默认 this-run + `--device-ip` → **PASS / RC=0**：`基线 29 条 → 台账不变`、boot banner ×1、
`net init: OK` **612 ms**（证明污染已消除）、Forbidden 零命中。
· `--selftest-scope all` → **FAIL / RC=1**：`29 fault record(s)`（累计口径仍可用）。
· 不给 `--device-ip` → **FAIL / RC=1**：`verify_log` 那侧显示 `no fault record → PASS`，
调用方收口为 `RUN_TEST_VERDICT: FAIL —— 自检台账判定未能执行`（正是要的行为）。
门禁：`py_compile`（run_boot_test + verify_log）通过；`check_doc_links.py --all
--sections-strict` 146 文档 0 问题；`check_ids.py --strict` 增量拦截通过（可判定 82.82%，
在地板之上）；6 个文件字节卫生 BOM 无 / CR 0 / U+FFFD 0 / 无行尾空格。
**仍待办（本笔未做）**：设备侧"FTP 客户端中途退出"按 ERROR 级打日志（要不要降级）；lftpd
的 LIST 传完回 550 而非 226；设备 `/` 残留约 24 个旧探针文件；`MDK-ARM/` 下 4 个一次性
探针脚本仍写匿名。未推送。
|
||
|
wandering1
|
15d01d4dc1 |
fix(测试工具): FTP 脚本与 @test 抓取改用设备鉴权账号（修 11 天假绿）
设备 FTP 自鉴权落地起就**没有匿名通道**（实测 `USER anonymous` → 530、`admin`+错口令 → 530、`admin`/`admin` → 230；`lftpd` 源码里也没有 anonymous 特判），但三个老主机脚本、 `@test` 的自检记录抓取、以及测试指南都还写着匿名——同目录的 `ftp_auth_bench.py` / `ftp_abort_probe.py` 反而早就记着"匿名一律 530"，可见当时只改了新增件。 **改动**： · `test/host/ftp_test.py`、`ftp_up_dl_test.py`、`ftp_speed_test.py`：写死的 `USER anonymous` / `PASS test@test.com` 改为 `--user` / `--password`（默认出厂 admin/admin）；**USER 的期望码从 230 修成"230 或 331"**——要口令的服务器在 USER 后 回 331，脚本原先要求 USER 直接给 230，这是第二个 bug（就算口令对也过不了）；登录 失败时打印口径提示（`/config.ini` 的 `[ftp]`、无匿名通道、连续 5 次失败锁 60 秒）。 · `.dsh/skills/serial-boot-test/scripts/run_boot_test.py`：`ftp.login()`（匿名）→ `ftp.login(user, pass)`，新增 `--ftp-user/--ftp-pass` 与 config 的 `ftp_user`/ `ftp_pass`（默认 admin）；函数文档与 `--device-ip` 的 help 去掉 "(anonymous)"。 · `docs/测试说明/FTP_Test_Guide.md`：§1 的"匿名登录（`USER anonymous` / `PASS` 任意）" 改为鉴权口径（`user` / `pwd_hash` = SHA-256(user‖password) / `write`，出厂 admin/admin，默认口令在用有启动告警，5 次失败锁 60 秒，**无匿名通道**），§4 参数说明 补两个新参数，§4.1 期望改为 `USER admin`→331、`PASS admin`→230，FileZilla 的用户 由 `anonymous` 改 `admin`。 **这才是真正的危害**：`@test --require-selftest-pass` 的抓取走匿名登录 → 必然 530 → 落 进 `RUN_TEST_WARN … treated as no record (S7 PASS path)` → **每次都判 PASS**。也就是 说这条"联合判定自检记录"的门禁从写下那天起就没真正看过文件（假绿）。修完凭据后第一次 真抓到 `/log/selftest.log`（1856 B），立刻报出 29 条故障记录——而它们的**时间戳全是 2026-10-10 ~ 10-14**，没有一条来自本次启动：`/log/selftest.log` 是 512 条环形累计历史， 而 S7 的判据是"有任何 64B 记录就 FAIL" → **在任何做过故障注入或长跑的设备上，这条 门禁都不可能 PASS**。判据本身要改成"只看本次启动新增"，已单独提出，不在本笔。 **验证（全部真机实跑）**：`ftp_up_dl_test.py` → TEST PASSED（10 项全过，含 STOR/LIST/ RETR/逐字节比对/DELE）；`ftp_speed_test.py --size 128` → TEST PASSED（上行 225.8 KB/s、 下行 250.9 KB/s，131,072 B 逐字节一致）；`@test` → PASS（625 ms 到 `net init: OK`）； `@test --require-selftest-pass --device-ip 192.168.1.100` → `SELFTEST_FETCH: … (1856 bytes)`，抓取路径真跑通（旧代码在此步必 530）。 `py_compile` 四个脚本全过；`check_doc_links.py --all --sections-strict` 146 文档 0 问题； `check_ids.py --strict` 增量拦截通过；5 个文件字节卫生 BOM 无 / CR 0 / U+FFFD 0 / 无行尾空格。 **顺带暴露、未在本笔处理**：① `ftp_test.py` 的 `LIST 150->226` 断言失败——lftpd 的 LIST 数据本身正确（1512 B 全收到），但传输结束后控制通道回的是 **550** 而不是 226，需单独查 收尾路径；② 设备 `/` 根目录残留约 24 个旧探针文件（AB*/E12A/SZ*/A000x/R000x/DIAG_A）； ③ `MDK-ARM/` 下 4 个一次性探针脚本仍写匿名，现在必然登录不上。未推送。 |
||
|
wandering1
|
e7f28502bc |
refactor(NET): netMsgQueueHandle 收进 net_socket 私有，改为创建后绑定
结构债 S-2 的最后一步——**该族的 24 处手写跨模块裸 extern 就此全部清零**。 队列对象仍由 CubeMX 在 `MX_FREERTOS_Init()` 创建（**创建点不可外移**： `osKernelInitialize()` 之前的任何创建类 API 会杀死启动，见 `docs/架构设计/项目启动顺序管理.md`）；改为创建后立刻在 `Src/freertos.c` 的 `USER CODE BEGIN RTOS_QUEUES` 区调用 `net_msg_queue_adopt(netMsgQueueHandle)`， 把句柄交给唯一使用者。`net_socket.c` 内改用 `static osMessageQueueId_t s_net_msg_queue`（21 处引用改名），BSP 对该全局变量的裸 `extern` 消失——现在 `netMsgQueueHandle` 只出现在生成文件自己的两处（定义 + 创建）。 两个刻意的设计决定： ① **不新建第二个队列**。自建队列 + 删 `.ioc` 里的 netMsgQueue 也能收口，但要 CubeMX 重生成（Ask-first），过渡期还会同时存在两个队列，白占 CCM 堆里 8 × `net_msg_t` 的空间——CCM 正是当下 87.9% 的红线。故选"创建后绑定"。 ② `adopt()` **拒绝重复绑定、保留首次句柄**。真出现两处绑定时，静默换句柄会让 已入队的请求留在旧队列里永不处理；拒掉第二个反而更容易暴露。绑定前的判空 是真实防线：丢了那一行，后果是"所有 net_* 请求被丢弃、网络全线静默不通"， 不是崩溃。 **防回退**：`check_cubemx_survival.py` 新增存活项 `net-msgq-adopt`（region `RTOS_QUEUES`、`must_contain=["net_msg_queue_adopt"]`），易失清单 29 → 30 项全部 到位；基线已重建（有意的 USER CODE 区改动，按脚本文档流程 `--write`）。 **体量**：`Code` 213,204 → **213,236 B（+32）**、`ER_IROM1` **231,816 B（22.1%）**； `RW +4 / ZI −4` → `RW_IRAM1` 恒 **75,264 B（57.4%）**、`RW_CCM` 恒 **57,376 B （87.9%）**、`RW+ZI` 总量 132,688 B 不变（没有多占一个字节 RAM）。 **验证**：`@build` 0 错 0 警告；`@test` PASS——624 ms 到 `net init: OK`、`i104: listening on 2404`、无 `[ERR]`/Fault、`heap free=15800 min_ever=8464` 逐项不变。 另在真机跑了一次 FTP 控制通道往返：220 → `USER admin` 331 → `PASS admin` 230 → `PWD` 257 → `TYPE I` 200 → `QUIT` 221。每条命令都是一次过队列的 net_recv/net_send，证明绑定路径真在跑；`.map` 里 `freertos.o(MX_FREERTOS_Init) refers to net_socket.o(i.net_msg_queue_adopt)` 证明镜像含该行。 ⚠ **顺带揪出一条测试工具漂移（本次未修，等定夺）**： `test/host/ftp_up_dl_test.py:123/126` 仍写死 `USER anonymous` / `PASS test@test.com`，而设备自 N-19（2026-10-11）起按 `/config.ini [ftp]` 校验 admin/admin（SHA-256 `pwd_hash`）→ 该脚本必然登录失败。它是手工工具、不在任何 pre-commit 钩子里，所以 11 天没人发现，而 `docs/测试说明/FTP_Test_Guide.md` 把它 列为"推荐入口"。建议加 `--user/--password`（默认 admin/admin），并连 `ftp_speed_test.py` 一起核。 数字联动：两份 `data/` 快照重跑、`ram_baseline --update/--write`、 `check_mem_numbers --write`、FLASH 与任务栈两张配图常量重算并重新生成（逐文本按 字号与锚点复查越界 = 0）、报告 §1.3/§5.1/§5.4 与部署文档 §3.3 同步。报告 §0.4 的 S-2 行按「完成即销项」改写为已闭环，§9 拆出独立 S-2 行标 ✅。 门禁：`@build` 0/0、`@test` PASS、`layer-deps` / `cubemx-survival` / `mem-numbers` （本次改到台账受管区，scan 已过）/ `mem-budget`（57.4% / 87.9%）/ `task-table` / `doc-links --all`（146 文档 0 问题）/ `id-check --strict`（增量拦截通过、可判定 82.84%、存量债 640）全绿；14 个文件字节卫生 BOM 无 / CR 0 / U+FFFD 0 / 无尾空格。 未推送。 |
||
|
wandering1
|
6ede1443e9 |
feat(门禁): 新增 layer-deps——BSP 反向 include App 的增量拦截（37→38）
推荐清单第 5 步的拆分执行：反转依赖（5a）暂缓，**只把"防扩大"的门禁先上**。
**为什么门禁比搬迁值钱**：AGENTS.md 与分层图早就写着"六层单向依赖"，可从来没有
机械检查——于是同一件事的记载从 2026-09 审查报告的"NETCFG 一处"，漂到 2026-10-22
实测的 **8 个文件 9 处**，全靠人读代码才发现。边界的静默腐蚀只能靠门禁止住。
**机制（与 `id-check` 的增量拦截同构）**：`scripts/check_layer_deps.py` 扫
`Drivers/BSP/**.{c,h}` 的 include，按 `App/**` 头文件索引解析反向边（同名头按字面
路径消歧），命中分三类：
· ALLOW 永久豁免 3 条横切叶子头——`App/log/console_log.h`（日志后端，BSP 的
dbg_log.h 就建在它上面）、`App/util/sys_clock.h`（时间源）、`App/util/sha256.h`
（纯算法、无状态）。它们是"任何层都要用的叶子能力"，不是上层服务；新增豁免
必须先回答"它为什么不是上层服务"。
· BASELINE 钉住存量 6 条：`cfg_file.h`×2（NETCFG）、`vol_lock.h`×1（lftpd_io）、
`sys_log.h`×3（UI 两处 + `ui_w_records.h`）。**只减不增**（脚本没有 `--write`）。
· 新出现的 (BSP 文件, App 头) 组合 → FAIL，并给出三条出路（注入回调 / 上层传参 /
确属叶子才可豁免）。
`--prune` 在某条存量还清时点名"可从基线删除"，于是"还欠几条"成为可见进度，而不是
文档里的一句口号。
**当场自证**：落地时临时给 `Drivers/BSP/RS485/rs485.c` 加了一行 include `cfg_file.h
`，钩子当场 FAIL 并点名该文件与该头（退出码 1），删掉后转绿——没被触发过的门禁
等于没有门禁。
**边界要说清（免得被误读成缺陷）**：本钩子只拦**静态 include 方向**。运行时的属主
纪律本来就没破——UI 只投递 `net_cfg_save_request()`，真正写盘在 defaultTask，模拟器
也早在主机侧跑整条配置链。
**口径同步**：钩子数 37 → 38 共 6 处（`AGENTS.md` 两处、`pre-commit使用说明.md` 两处
并新增 §2.26 详解、`并行任务工作树方案.md`、报告 §0.1/§1.1）；
`项目架构总览.md` §1 分层原则处补"此方向已机械检查"；报告 §0.4 的 S-1 计数由
"7 文件 15 处"更正为脚本口径的 8 文件 9 处，§9 状态改 🟡。
**暂缓项（都已在报告 §0.4 记因）**：5a 反转依赖——没有功能在等它，且要过"改 IP
免重启生效"整条真机链，留给下次真动 NETCFG/UI 时顺带做；5b 目录搬迁——uvprojx 326
条 + IncludePath + CMakeLists + 42 个 UI 文件 + 全库引用改写，收益只是"目录名好看"，
而远程 CI 仍刻意不跑 `@build`，兜底未成立。
门禁：`layer-deps` 自身通过；`check_doc_links.py --all --sections-strict` 146 文档 0
问题；`check_ids.py --strict` 增量拦截通过、可判定 82.84%；`mem-numbers` 0；
`py_compile` 通过。本轮无 `.c/.h` 改动，未重跑 `@build`。未推送。
|
||
|
wandering1
|
7e77af08a0 |
fix(BSP): SPI1 完成标志收回 GD5F 私有，HAL 回调改契约转调
推荐清单第 4a 步（结构债 S-2 剩余面里唯一带"静默失效"属性的那条）。 **问题不是风格**：HAL 的 SPI 完成/错误回调是**全局唯一符号**，整个工程只能有一份 实现，当前由 CH395F 代管并按 `hspi->Instance` 分发——于是 GD5F 的完成标志 `g_spi1_dma_done` 被 CH395F 跨模块裸 `extern` 直接写，**GD5F 出错时的"释放等待者" 寄居在别人的 .c 里**。谁哪天做"CH395F 清理"，把那两个 `else if (SPI1)` 分支当无关 代码删掉：编译零报错，GD5F 的 DMA 等待在出错时只能干等 `GD5F_SPI_TIMEOUT` 兜底。 **改法（时序一字不动，只换所有权）**： · 标志收为 GD5F 文件内 `static volatile uint8_t s_spi1_dma_done`（6 处引用同步改名） · GD5F 导出 `gd5f_spi1_notify_done()` / `gd5f_spi1_notify_error()`，头文件里写明 "SPI1 分支必须转调这两个函数，否则本模块的 DMA 等待在出错时只能靠超时兜底" · CH395F 删除裸 `extern`、include `gd5f2gq5ue.h`、两个 SPI1 分支改为转调并就地注明 "勿删：少了这行 GD5F 的 DMA 出错只能靠超时退出" `HAL_SPI_AbortCpltCallback`（`HAL_SPI_DMAStop()` 会触发）本次**刻意不做**——它会改 变中止语义、需要真机专项，当前超时兜底可用（已在报告 §0.4 记为观察项）。 **体量代价**：`ch395f.o` −8 B、`gd5f2gq5ue.o` +24 B → `Code` 213,188 → **213,204 B （+16 B）**，RO/RW/ZI 全不变，`ER_IROM1` 231,768 → **231,784 B（22.1%）**。16 B 换 掉一个静默失效类，划算。 **真机 `@test` PASS**：无 `[ERR]`/Fault，复位原因 software；`[STACK] heap free=15800 min_ever=8464` 与改前**逐项相同**；各任务实测峰值 default 2152 / net 1116 / ftp 764 / ui 4052 / timesync 616 / adc 952 / iec104 540 / protect 624， **静态最坏链全部未变**（3024/1912/1456/4052/1264/1320/1456/872）→ 9/9 PASS。 ⚠ 记一条读数陷阱：测试脚本打印的 "boot to net init: OK = 7,907 ms" 是采集窗口 锚点造成的度量偏差，真机日志里 `boot: syslog init OK → net init: OK` 实测 ≈699 ms， 与改前一致，**不是性能回退**。 **数字联动**：`data/ram_report_20261022.md`、`data/stack_report_20261022.md` 重跑； `ram_baseline.py --update/--write`；`check_mem_numbers.py --write`（RAM 方案受管区 + 台账）；`gen_memory_svg.py` 常量更新后重新生成 FLASH 与任务栈两张配图（逐文本按 字号与锚点复查越界 = 0；RAM 图无需变更）；报告 §1.3/§5.1/§5.4、部署文档 §3.3 的 Flash 数字同步；§0.4/§9 的 S-2 口径改为"24 处手写已消 23 处，只剩 `net_socket.c:77`"。 门禁：`@build` 0 错 0 警告；`cubemx-survival --check`、`mem-numbers`、`mem-budget` （57.4% / 87.9%）、`task-table`、`doc-links --all --sections-strict`（146 文档 0 问题）、 `id-check --strict`（增量拦截通过、可判定 82.83%）全绿；字节卫生 BOM/CR/U+FFFD/尾 空格全清；未提交 UV4 抖动的 `.uvprojx`（本次未被改写）。未推送。 |
||
|
wandering1
|
36a3c3449c |
refactor(task): 19 处任务句柄裸 extern 收拢为 task_handles.h 引用契约
推荐清单第 3 步（结构债 S-2 剩余面），用户批准"按你推荐做"。 新建 `App/task/task_handles.h`——**只有声明、没有 `.c`**：头文件不需要双端注册， 且 `../App/task` 本来就在 uvprojx 的 `<IncludePath>` 里，所以这一步零构建面。 - `App/task/default_task.c:52-69` 的 18 行局部 extern（9 个句柄 + 9 个 attributes） 删除，改 include；栈水位观测用的任务清单表本体仍留在该文件 - `App/task/adc_task.c:125` 的 1 行同法收口 - `Src/main.c` 函数内的 `extern volatile uint32_t g_rcc_csr_latched;` 移进 `App/app/app_main.h`（`main.c` 本来就 include 它），USER CODE 区内只留"读 RCC_CSR → 写 RMVF 清除"两句，顺序约束的原注释保留 为什么值得做：原先每加一个任务都得记得往 `default_task.c` 再抄两行 extern，抄 漏一行 = 读别人的栈（静默，无报错）。现在只有一个改动点；而且 CubeMX 若把句柄 改名，报错会落在链接期而不是静默通过。 **镜像逐项体积不变**：`Code=213,188 RO-data=18,580 RW-data=1,184 ZI-data=131,504`，`@build` 0 错 0 警告 → 行为中性。 `check_cubemx_survival.py` 对这次有意的 USER CODE 区改动报"漂移"，已按其文档流程 `--write` 重建基线（`.cubemx_survival_baseline.json` 仅 1 个指纹变化；顺手把该脚本 写文件带来的 CRLF 归一回 LF，符合 `* text=auto eol=lf`），`--check` 复跑通过、易失 清单 29 项全部到位。 报告 §0.4/§9 的 S-2 口径同时改成**精确分类**：该修的手写跨模块裸 extern **24 处， 今天已消 22 处，只剩 2 处**（`ch395f.c:177` 的 `g_spi1_dma_done` 与 `net_socket.c:77` 的 `netMsgQueueHandle`）；`stm32f4xx_it.c:241-256` 那 16 条是 CubeMX「External variables」生成块（删了会被重生成写回来，**不算债**），`:183/195/207/220` 那 4 条 是手写在 `__asm` Handler 里引用汇编标签（ARMCC `__asm` 取不到 C 数据符号， **合法例外**）。上一版写的"25 处"把这三类混在一起了，一并更正。另更正 §0.4 的 S-1 一格：不是"运行时属主纪律被破"（UI 只投递 `net_cfg_save_request()`，写盘在 defaultTask），也不是"进不了主机侧单测"（模拟器已跑整条链），要修的只是静态分层 方向。 门禁：`@build` 0/0；`cubemx-survival --check` 通过；`check_doc_links.py --all --sections-strict` 146 文档 0 问题；`check_ids.py --strict` 增量拦截通过、可判定 82.83%；`mem-numbers` 0。字节卫生：新增头文件与各改动文件 BOM 无 / CR 0 / U+FFFD 0。未推送。 |
||
|
wandering1
|
67fbdd9897 |
refactor(结构债): S-4 删零消费点占位宏；S-2 消两处与 Inc 重复的 extern
用户批准「先只跑 1+2」（报告 §0.4 结构债三项 S-1/S-2/S-4 的评估结论）。 **S-4 闭环**：删除 `App/app/app_cfg.h` 里 4 个**全库零消费点**的宏 （`APP_NET_ENABLE` / `APP_ADC_ENABLE` / `APP_RS485_ENABLE` / `APP_SYS_TIME_SRC`），文件降格为「决策占位说明」——修改记录 v1.2 写明为什么删、 将来在真实初始化点接入门控时怎么接回；同时去掉 `app_main.c` 里只为它存在的 include。留「看着能裁剪、其实不生效」的宏比不留更糟：它不产生任何编译期效果， 却会让评审误信模块可裁剪——此前为了对冲这个误解，AGENTS 之外还得在 6 处文档各 写一句「未接线占位，别当开关用」。 **文档口径同步 17 处**：`App/app/README.md`、`App/README.md`、根 `README.md`、 `项目架构总览.md`、`项目部署环境要求.md`（§3.2 两行 + 配置表一行）、`产品需求 设计文档.md`（B0 结论 + 配置表）、`基线与待确认.md`、`排期详述.md` C5、`登记簿 .md` N-23 残余、`RAM使用分析与优化方案.md` 三处。 **顺带纠出另一个「文档里有、代码里从来没有」的东西**：`RAM使用分析与优化方案 .md` 把 `APP_CCM_ENABLE` 写成「加在 `App/app/app_cfg.h`」，全库只有那篇文档提 到它，从未落地——已就地标注「未实现，重开本簇时一起落地」，免得下一个读者以为 CCM 有回退开关。 **S-2 第一步**：删 `gd5f2gq5ue.c:47`、`sd2506.c:20` 两处与 `Inc/spi.h` / `Inc/i2c.h` 重复的 `extern`；GD5F 改 `#include "spi.h"`（沿用 `ch395f.c:22` 的既有做法）。 **镜像体积逐项不变**：`Code=213,188 RO-data=18,580 RW-data=1,184 ZI-data=131,504` 与改动前完全相同，`@build` 0 错 0 警告 → 两步均为行为中性。 报告 §0.4/§9 同步为实测口径并**认错**：S-2 不是旧写的「4 处」而是 **25 处** （`App/task/default_task.c:52-69` 一次就 18 行任务句柄/属性 extern； `stm32f4xx_it.c` 的 `fault_entry_hard` 属 ARMCC `__asm` 合法例外，不该「 修」）；S-1 不是「语义层错位」而是**真实的 BSP→App 反向依赖**（NETCFG 10 处 include `App/cfg/cfg_file.h` + UI 3 个文件）。这两个旧数字是 v3.0 重写时沿用 未测所致。 途中被自家门禁正确拦下一次：在 .c 注释里写「S-2a」→ `+1 [校验1] 未登记编号 `，改成平实语言后转绿（正合既有纪律「代码注释禁用不可检索的内部编号」）。 门禁：`@build` 0/0；`check_ids.py --strict` 增量拦截通过、存量债 650 → 640、 可判定比例 82.83%（地板 82.6%+0.1pp）；`check_doc_links.py --all --sections-strict` 146 文档 0 问题；`pre-commit` 相关文件全 Passed；字节卫生 15 个文件 BOM/CR/U+FFFD/行尾空格全清（`end-of-file-fixer` 修掉 app_cfg.h 的一个 多余空行）。未推送。 |
||
|
wandering1
|
538c44c1cc |
docs(报告): 项目审查报告 v3.0 全量重写，按 2026-10-22 实测重判并删过时条目
用户裁定：报告很久没更新，过时的删除、重新写。697 → 440 行（−563 / +306）。
取数：旧报告里的数字一个都不沿用，全部按今天的仓库重测——`.map`（ER_IROM1
231,768 B / 22.1%，RW_IRAM1 75,264 / 57.4%，RW_CCM 57,376 / 87.9% 余 7,904 B）、
`.htm` + 同日真机 `[STACK]`（9/9 PASS、min_ever 8,464）、`git ls-files` 逐个 stat
（2,498 文件 / 80.0 MB，docs 45.3 MB 中芯片手册占 39.5 MB＝87%，.git 248 MB）、
37 个钩子、16 套主机单测、TC 593∶271 交集 265、登记簿在策 18 条。
删除：六维评分旧表与 §0.4 的 12 条已闭环行；§6「UI 8 人日方案」正文（四层设
问、逐日排期、27 页清单）；§7 交付物清单的已完成行与人日估算；§1~§3 的
2026-09-11 / 10-14 旧快照数字与附录 A 旧证据行；§4 各节的设计复述（同一事实
只在一处，细节归各自设计文档），改为"今天复核到的状态 + 仍在册问题 + 证据"。
刻意保留三层（删了会出事）：
① 新增 §9 编号族登记处——本文是 id_registry.json 中 N-RPT / D-RPT / S-RPT /
R-RPT(游标 R-9) / F-RPT / U-RPT(U5) 六族的属主登记处，5 族开 check_dangling，
且外部存在「报告 N-14」「报告 F-4/F-5/F-6」「报告 D-1」式紧邻引用，删定义位
会被编号门禁当"定义缺失"拦下；每个存量号一行状态 + 现去处。
② §1.2 / §1.3 复现命令与口径定义——保证每个数字可重跑。
③ 文末变更记录与已销项去处表 52 行原样冻结（登记簿销项纪律的落点）。
被外部点名的锚点 §0.3 / §3.1 / §4.1~§4.3 / §5.3×9 / §5.4 / §5.5×4 / §6.2 / §6.3 /
§6.5 逐个留位 → 全库 68 处入站引用零改动。
重审计改判三条：
· §6 原写 U1/U3/U4「❌ 未建」是错的：ui_tokens.h（69 行 L0 令牌）、
ui_page_registry.c（描述符注册表，已取代手写 case）、ui-golden + font-charset
两枚钩子都在；U2 只有 ui_w_records 一个组件；"27 页未落地"实为 7 页。
· "新增一页 ≤30 行"目标未达（最省 ui_page_dc.c 40 行，重页 275/370 行），如实
记为未达项。
· §0.4 与登记簿已漂开 → 本版把待办清单降级为快照 + 指向，权威只留一处。
门禁：check_doc_links.py --all --sections-strict → 146 文档 0 问题（章节引用
2,515、可判定 1,483）；check_ids.py --strict 增量拦截通过、存量债 650 → 641
（−9）、可判定比例 82.98% → 82.80%（基线 82.6% + 0.1pp 容差仍通过，缓冲从
0.38pp 缩到 0.20pp——被删引用 99% 可判定，属预期副作用）；mem-numbers、
ram_baseline --gate、task-table、cubemx-survival 全 0；字节卫生 BOM/CR/U+FFFD/
行尾空格全清。未改任何 .c/.h，未推送。
|
||
|
wandering1
|
504db26698 |
docs(内存): 阶段子项改层级编号 4.阶段.项，消除与顶层章节同号撞面
根因：`RAM使用分析与优化方案.md` 顶层有 §1 背景 / §2 现状测量（2.1~2.6），而 §4 「方案」下"阶段 N"的子项也用裸号 0.x / 1.x / 2.x——阶段 2 的 2.1/2.2/2.3 与顶层 2.x **完全同号**，阶段 1 的 1.x 又长得像"第 1 章第 x 节"。`doc-links` 对本文自 引用按设计直接放过，于是门禁和人一起看错：AGENTS.md 把"栈余量台账"写成 §1.4， 而 §1.4 其实是阶段 1 的 lftpd 静态化项（上一笔提交的信息里我把它误判成断链， 已 amend 更正）。 改法：阶段子项一律改层级编号，阶段号不变、只加 `4.` 前缀 —— 0.x→4.0.x、 1.x→4.1.x、2.x→4.2.x。共改 14 个标题；文内自引用与实施序列表（S4~S9 那套）、 暂缓清单、§5 预期效果列里的裸号一并补成 §4.x.y。 外部引用同步 15 处：AGENTS.md、lftpd/README ×2、菜单页面设计、RAM预算台账 ×2、 项目架构总览 ×3、FTP_Test_Guide ×3、boot_log_data/README、部署环境要求、审查 报告、ram_baseline.py ×3。最有说服力的两处歧义：审查报告与 RAM预算台账都写 "缩堆见 …§2.2"——既可读成顶层 §2.2（静态大项排行）也可读成阶段 2 第 2 项， 现均为 §4.2.2（阶段 2 第 2 项"缩堆"）。 另修 4 处把 §1.4 当"栈台账"的错指：采样有效性校验设计说明 :441/:593/:650 改 指 §2.3（任务栈配置与实测峰值）与 §4.0.6（静态最坏链与判定）；id_aliases.json 的 note 改指 §4.0.6 并标注"原 §1.4，2026-10-22 层级编号"。 冻结与示例：其它文档**变更记录行**里的旧编号按项目纪律不改写（项目架构总览 :367、RAM预算台账 :98），改在被引文档 §4 开头留一张换算表 + 约定说明；把旧号 当语法示例写的 7 处一并换掉（文档规范 ×3、check_doc_links ×3、rename_ref ×1）， 否则示例本身指向已改名的锚点。主文档版本行 bump 到 v1.3 / 2026-10-22。 门禁：check_doc_links.py --all --sections-strict → 146 个文档 0 问题（章节引用 2513 处、机器可判定 1491）；check_ids.py --strict 增量拦截通过；mem-numbers、 ram_baseline --gate（SRAM1 57.4% / CCM 87.9%）、task-table 全绿；本轮未改任何 .c/.h。16 个文件字节卫生自查 BOM/CR/U+FFFD/行尾空格全清。已提交本地，未推送。 |
||
|
wandering1
|
f4b9bd57d5 |
docs(部署): 删任务栈副本表改指针；纠 CCM/FPU 事实并刷新配图基线
范围：AGENTS.md 一处指针、部署环境要求 §2.2/§3.1/§3.3、RAM 方案 6 处现状 数字、内存配图生成器 + 3 张 SVG、两份报告脚本的行尾与路径修正、新增两份 .map/.htm 数据快照。未改任何 .c/.h（仍跑 @build 复核：0 错误 0 警告）。 部署环境要求.md - §3.3 删"任务栈预算"副本表、改为指针：该表已缺 adcTask/iec104Task/ protectTask，defaultTask/timeSyncTask 两值停在旧数，注释却写"由 gen_task_table.py 同源"——该钩子的校验面只有 README.md / AGENTS.md 两处受管块，抄出来的副本没有门禁、改栈后必漂。指针指向 Src/freertos.c + 两份受管表 + RAM 方案 §2.3/§0.6，并留一条"别再抄"的成因说明。 - §2.2 链接布局补 `RW_CCM 0x10000000`（scatter 给 0x0000FF00 = 65,280 B， 2026-10-11 起承载 FreeRTOS 堆；另有 256 B UNINIT_CCM 尾区），写明 CCM 不可 DMA。原文"SRAM3/CCM 故意未映射"与 STM32F407-Demo.sct 直接矛盾。 - §3.1 MCU 行更正为**单精度 FPU（VFPv4-SP，无硬件双精度）、无 TrustZone** （原写"双精度 FPU / TrustZone"是芯片事实错误，也正是报告 F-6 双精度软 浮点被长期误判的土壤）；SRAM 行改为"两块都在用，仅 SRAM3 未映射"。 - §3.3 资源预算表补 CCM 行，并把"主 SRAM 125,104 B / 95.4% / 极度紧张" 更正为 75,264 B / 57.4%（余 55,808 B）；红线改标在 CCM（余 7,904 B）。 - 变更记录补 2026-10-22 行（含上一提交里的资源表刷新那一笔）。 AGENTS.md：任务表注里 "RAM使用分析与优化方案.md §1.4" 是**指错小节**——§1.4 确实 存在（该文档 §4「方案」下的阶段 1 子项，讲 lftpd 大局部缓冲静态化），但栈余量 台账在 §2.3（任务栈配置与实测峰值）与 §0.6（静态最坏链与判定），故改指这两处 再加 内存内容分配策略.md §6。根因是该文档里 §1（背景）与 §4 下的 1.1~1.5 同号 撞面，人和 doc-links（自引用放过）都会看错——本会话我上一轮就被它带错过一次。 配图与数据（draw-diagram 流程：改生成器顶部数据 → 重跑 → 逐文本核越界） - 新增 data/ram_report_20261022.md、data/stack_report_20261022.md；后者 运行时水位取自 2026-10-22 真机 [STACK] 心跳（8 任务高水位 + heap free=15,800 / min_ever=8,464），静态侧来自同日 .htm（全局最深链 3,024 B）。 - gen_memory_svg.py：三组图数据从 2026-09-21 / 10-10 快照换成 2026-10-22 实测；任务栈 6 → 9 行，堆总量 48KB → 56KB，判定 6/6 → 9/9 PASS，新增 AboveNormal 配色；Flash 子条改为"窄段不压字 + 下方四列图例"；任务栈 画布 440 → 620 高。CCM 段总量按 scatter 用 65,280 B（与台账同口径）。 - 三张 SVG 重生成；用"CJK≈1.0em / 其余≈0.58em + 锚点"逐文本估算边界， 修掉 5 处文字越界/压字（生成器内置 ElementTree 自检亦通过）。 - ram_report.py / stack_report.py 两处工具性修正：write_text 未指定 newline 参数 → Windows 下把 data/ 快照写成 CRLF（与 .gitattributes 及既有快照 不符）；stack_report 的 relative_to 在传相对 -i 时抛 ValueError，且会把 本机绝对路径写进入库快照 → 统一走 resolve+relative_to 的相对路径回退。 RAM 方案：6 处"当前状态"随 .map/[STACK] 更正——RW_IRAM1 89,168 → 75,264、 RW_CCM 49,184 → 57,376、FreeRTOS 堆 48KB → 56KB（两处）、CCM 余量 ~16KB → 7,904 B、min_ever 4,848 → 8,464 B、6 任务全过 → 9/9 PASS；S-1 历史句保留。 门禁：pre-commit 对全部改动文件 Passed（doc-links --sections-strict、 task-table、mem-numbers、mem-budget、id-check 增量拦截）；字节卫生自查 BOM / CR / U+FFFD / 行尾空格全清。已提交本地，未推送。 |
||
|
wandering1
|
d4867ddbe2 |
fix(algo): Q10 定值宏改单精度；收口 Flash 优化簇并更正审查报告三处误判
影响面：一个头文件宏（App/algo/prot_set.h）+ 七份文档口径；固件行为逐位 等价，无功能变化。门禁全绿后提交，未推送。 验证链 - @build：0 错 0 警；Code 213,520 → 213,188（−332 B），RO/RW/ZI 不变。 - 真机 @test PASS：戳 fw build: Oct 22 2026 10:36:15 suite=NONE；无 [ERR]/ERROR/FAIL/Fault；708 ms 到 net init: OK；protect task start、 i104: listening on 2404、[STACK] 三面水位齐。 - 主机单测：prot_set 90/90、prot_elm 47/47、iec104 97/97。 - 等价性穷举：宏内 42 个字面量；int32 全域 ÷1024 往返 4,494,305 例零 差异；×1024 方向 20 万随机 float 零差异（×/÷1024 是 2^10 指数平移， 不产生尾数舍入）→ 定值默认值/上下限、校验和、104 上送值全部不变。 F-6 双精度软浮点（已落地） - 两个 Q10 宏去掉显式 (double)、1024.0 → 1024.0f：保护判据每 20 ms 每 元件 3 次定值读取改走 F407 单精度 FPU，不再软件模拟。 - .map 里 dflti/d2f/f2d/dfixi/fepilogue 共 300 B 消失；自研侧对双精度 helper 的引用归零。 - 更正报告归因：全库 0 处 %f（扫 App/Src/Inc/Drivers 共 173 个 .c/.h）， 剩下 dadd/dmul/ddiv/depilogue/dfixul = 1,018 B 由 MicroLIB printfa.o 的 _printf_core → _fp_digits 无条件引用，只要还用 snprintf 就删不掉； 报告"把 %f 改整数刻度"没有可执行对象。 F-4 LVGL 死代码（判定不做） - 报告列的五项字节数逐字节仍准（合计 10,060 B），但没有一项有开关： 根因是 lv_draw_sw.c 的 execute_drawing() 无条件 switch 引用全部 task 类型，链接器 --remove 无从下手。 - 唯一总开关 LV_DRAW_SW_COMPLEX 被 ui_deco.c 的"浅 V"3 px 粗斜腿依赖 （斜段与其所需 mask 核心都在该开关内）；2026-09-03 已实测失败并把两端 =1 固化 → UI_设计架构.md §1.4 第 7 条。 - 报告原"mask/grad 是文字与矩形绘制必经路径"证伪：字形走 blend 层 mask_buf，不经 lv_draw_sw_mask_*。 - 剩余路线需给 Lib/lvgl 打本地补丁（上限 ≈16 KB），而 Flash 仅占 22.1%、 无 OTA/双镜像预算 → 收益不抵代价；图片链同理不打补丁。 F-5 uvprojx 空 TU（降级为观察项） - 实测 326 个 .c / LVGL 201 个 / .map 零产出 127 个；但增量构建 4~5 s、 空 TU 只在全量重建或改 lv_conf.h 时才重编，且远程 CI 刻意不跑 @build。 - 报告原"编译时长 −40%"无基线记录，不复述；真要做用 Keil 原生 <IncludeInBuild>0</IncludeInBuild>，且排在任何 lv_conf.h 改动之后。 文档与台账 - 审查报告 §0.1/§0.4/§1/注册表/§5.1/§5.4/§6.4/W4 行按实测更正，补 2026-10-22 变更记录行与 F-4/F-6 记录去处行；登记簿 N-28 改写为"三项 已判定、仅剩 F-5 观察项"。 - 更正 FTL 写回缓存旧口径（sys_log_mcu.c 注释、运行与自检记录设计说明 §4.4、实机测试实施指南 §9.1）：f_close 经 sync_fs → CTRL_SYNC → ftl_flush_cache 已落盘，"写另一个文件逼出脏页"不是必要条件；2026-10-02 那次"复位后写入整段丢失"根因是 dhara resume 锚错 checkpoint。 - 部署环境要求 §3.3 资源预算由 2026-09-11 快照刷新为 2026-10-22 实测， 并补 CCM 红线行（旧"SRAM 95.4%/极度紧张"的说法早已失效）。 - ram_baseline.py --update/--write、check_mem_numbers.py --write 已回填： mem-budget（SRAM1 57.4% / CCM 87.9%，阈值 92%）与 mem-numbers 转绿。 |
||
|
wandering1
|
ee25b10053 |
chore(编号): 硬件网表报告里的 Trap05 统一为 TRAP-NET-05
- 6 处裸形 Trap05（V0.0 报告 5 处 + V0.1 报告 1 处）→ TRAP-NET-05，序号不变只补模块码 - 语义已核对：属主条目 docs/问题记录/CH395F_Trap_Records.md 的 TRAP-NET-05 就是 CH395F 与 RTL8305 自动协商不兼容，同名不同义的担心排除掉了 - 别名表登记 Trap05 → TRAP-NET-05（scope 限定这两个文件，写进真容器 aliases） - rename_ids.py 解除对 docs/硬件平台/ 的排除（芯片手册仍排除） - 注册表 TRAP 族注记改为事实：该目录仍不进门禁扫描语料——粗测约 4200 处 R/C/D/J/X/U/T 位号，位号类型识别做完前纳入只会让 --strict 为位号天天拦提交 验证：id-check --strict 无台账外新账；doc-links 失效与待确认均 0； 改名文件 BOM=否、CR=0、U+FFFD=0；未改 C/H，不需 @build |
||
|
wandering1
|
a38f862fb9 |
chore(ui-golden): 像素黄金参考 ref/*.bin 入库（把门禁改成可移植）
问题：ui-golden 是逐字节比对（check_content_pages.py 里 data == refdata）， 而基准 simulator/tests/ref/ 整目录被 .gitignore 忽略、从未入库。后果不是 "少几个文件"，而是这条门禁在任何新克隆 / 新并行工作树里必然报「缺黄金 参考」——只在有老副本的机器上它才是真的回归门禁。本会话已两次实测踩到 （并行工作树里只能现场 --update 造基准，而现场造出来的基准恰好失去意义）。 入库前先证明基线可复现，否则等于把一条天天误报的门禁写进仓库： - 主树 ref/ 生成于 2026-10-11，其间合入 B6~B9 与 UI 令牌化等多次改动； 今天用刚重建的 lvgl_sim 重跑 → 11 页 + 开页-关页往返池水位逐字节全过 - 主树与新工作树两份**独立构建**的 lvgl_sim（不同构建目录、不同绝对路径） 各自生成基准 → 11 个 .bin 的 SHA-256 全部一致 即渲染是 CPU 侧确定性输出，可以当仓库内容。 改动： - .gitignore：整目录忽略 → 只忽略派生的目检 PNG。另加一条 !simulator/tests/ref/*.bin 反选——第 115 行的全仓 *.bin 兜底（挡 sim_netcfg.bin 之类运行产物）会把基线一起挡掉，且反选必须排在它之后 才生效 - 不引入 LFS：11 x 3200 B = 34.4 KB（160x160 单色打包）。走 LFS 反而新增 失效面——没拉 LFS 的克隆会拿 pointer 文本去比像素，把"缺基准"换成 "比不中"。.gitattributes 已有 *.bin binary，check-attr 确认 text unset， 不会被行尾转换改写 - 基线不会被改写型钩子毁掉：trailing-whitespace / end-of-file-fixer 声明 types: [text]，位图含 NUL 被判二进制 → 实测 Skipped；索引 blob、磁盘、 主树参照三方哈希 11/11 一致 - 新增 11 个基线；同步 5 份文档与 3 处脚本口径：缺基准的提示从"首次/换机 请加 --update"改为"检出不完整 → git checkout -- simulator/tests/ref/ 取回， 不要用 --update 就地造基准"（旧提示正是自我实现型基准的来源） - 顺带修掉 simulator/tests/README.md 两处与实现不符的描述：基准写成 PNG （实为 .bin）、regen_ref_png.py 写成"重建黄金参考"（它只出目检图，基准 由 check_content_pages.py --update 刷） - .pre-commit-config.yaml 只改注释（原文明确断言 ref/ "永远不会进 git 索引"，已被本改动推翻）；ui-golden 的 files 面覆盖 simulator/tests/， 基线被改即触发回归，刷参考从此在 git diff 里显形 历史口径按纪律冻结：UI_自动化测试流程 2026-09-10 的"整目录不入库"等 6 处 变更记录行不改写，以新行登记反转。 实测：@build 0 错 0 警（Code=213520，与内存台账一致）；ui-golden Passed； pre-commit run --all-files = 36 Passed / 0 Failed（RC=0）。 |
||
|
wandering1
|
ebe2807ffd |
docs(内存管理): 回填 adc-health 合并后的 Flash/RAM 快照
合并 0a66e56（adc-health 四个提交）后主树才第一次 @build 出 .map， done 的快照同步当时按「未找到 .map」跳过 → 台账受管区仍停在合并前数字。 本次按新 .map 回填，增量为两个代码提交的累计： - ER_IROM1 231,936 → 232,100 B（+164 B）：接任务 init 入口 +68 B、 保护侧兜底门 +96 B - RW_IRAM1 75,240 → 75,264 B（+24 B）：protect_task.c 新增两份 adc_health_age_t（各 12 B，含对齐） - Flash 合计 233,120 → 233,284 B（+164 B），RW_CCM 57,376 B 不变 至此分支期间 mem-numbers / mem-budget 的 --no-verify 例外闭环（见 |
||
|
wandering1
|
790e153cd6 |
fix(adc_input): 丢帧计数改按帧点数累计，与 TPAFE 侧 tgap 同单位
读码确认的口径缺陷：两片转换器的丢帧计数单位不一致——TPAFE 侧 adc_health_tpafe_gaps() 按 (d-1) 加权记「帧点数」，STM32 侧 adc_input_stm32_gaps() 每次事件只 +1 记「次数」。两者都被当作心跳字段 并排打印（adc1_gap / tgap），一次跨多帧时数值就分叉：同样丢 3 帧， 一边记 2、一边记 1。跨字段对比或做除法会得出错误结论。 选 A（改代码，真对称）而不是只改字段名： - 单拍超一帧（d=2）时两者数值相同，历史上绝大多数样本本来就等价， 换单位对既有判读习惯冲击很小； - 只在一次跨 ≥2 帧时分叉，而那正是心跳日志突发期最常见的形态， 留在文档里当"注意点"迟早还会读错一次。 改动： - adc_input.c：s_stm32_gaps += (d - 1u)（d = seq - s_dma_seq_seen， 顺带把已算过的差值提成局部变量 d，不再重复算一遍） - adc_input.h / adc_input.c 函数头：单位写明「Σ 每次前进的超出部分」， 并点名 2026-10-21 之前固件该字段是次数口径，跨版本日志不可直接对比 - 用例：原两档只跨 1 帧（前进 2 记 1），钉不出单位；补第二档——连投 3 帧不消费（一次跨 2 帧）必须记 2 点、累计 1+2=3。补充断言沿用所属 用例覆盖点，不另立新编号，也不在文档外复制用例号（编号门禁按文件内 实例数比对台账豁免，多写一处即被判新债） - 文档同步：ADC采样节拍设计说明 §8/§9 字段口径与稳态基线、采集与算法 层设计说明 §3/§4、采样有效性校验设计说明 §6.2/§10/§11（并把"两车道 单位不同"从观测盲区降级为"历史日志口径差异"）、ADC输入层单元测试 说明用例表该行；两张配图生成器文案同步 实测： - @build 0 错 0 警；Program Size 与上一提交**逐字节相同**（Code=213520 RW=1184 ZI=131504）——编译器早已为半区推导算过同一差值并复用， 故本次净增 0 B，不产生新的台账漂移 - 主机单测：ADC 输入层 103/103、ADC 有效性 45/45 - stack_report：adcTask 1320 B / protectTask 872 B 均不变 - 字节卫生：BOM 无 / CR 0 / U+FFFD 0 / 文件尾换行齐 - id-check：Passed（曾因新增用例号实例触发"台账之外 +2"，已按不复制 用例号的方式消除，未动 id_known_backlog.json 台账） gate: only mem-budget/mem-numbers pending lead ledger backfill pre-commit run --all-files 失败仅这两条，漂移量来自上一条提交 6f90600 （+96 B Code / +24 B ZI）；本条自身 0 B。按并行分支约定本分支不跑 --write，台账由 Lead 合并后统一回填。 |
||
|
wandering1
|
9f826dbb4d |
fix(protect): 采样陈旧时独立闭锁保护（判定层失明的兜底门）
问题：L5-4 闭锁读的 adc_health_flags() 只有 adcTask 每拍跑 adc_health_check() 才可能置位。TIM3 一停，adcTask 就永久阻塞在 osThreadFlagsWait（刻意的 fail-safe），check() 不再执行 → stall 位 永远是 0，而 protectTask 仍每 20 ms 拿冻在最后一帧的相量继续判据。 窗口最坏约 800 ms（停喂阈值）+ 2498 ms（IWDG 标称）≈ 3.3 s。 方案：保护侧建一条与消费者存活完全解耦的兜底新鲜度门。 - adc_health.c/h 新增 adc_health_age_stale()：无模块状态的纯判据， 参照系 adc_health_age_t 由调用方自存。故意不让 protectTask 去调 adc_health_check()——那是「每拍一次、单写者」的契约，两个上下文 同写会互相刷新差值基线，把现有判定层一起弄坏。 - 新增 ADC_HF_STALE = bit8（与判定层 bit0..bit7 位段错开）。本位 不由判定层写、不进 sticky、不进编排层 logged 位图。 - protect_task.c 用自己的时基直接读两个**中断侧递增**的计数器 （tpafe5160_frame_seq / adc_input_stm32_seq），并入掩码。两条车道 各自一份 primed：共用会让先观测的那条把标志置 1，另一条首拍拿 adv_ms = 0 算年龄 → 开机即误锁保护。 - 门限 PROT_STALE_AGE_MS = 100 + 20 = 120 ms，买的是时序阶梯： 判定层活着时它先报 0x1/0x2（带日志与自检留痕），死了只出现 0x100。闭锁最迟 140 ms，仍远小于最小动作延时（默认 1000 ms）。 实测： - @build 0 错 0 警：Code 213424 → 213520（+96 B）；ZI 131480 → 131504（+24 B = 两份 age 结构）；RW-data 1184 不变 - stack_report：protectTask 静态最坏链 872 B 不变（余 1176 B / 57%）、 adcTask 1320 B 不变——新判据无日志，不进最坏链 - 主机单测 45/45（新增 TC-ADCHEALTH-012..017 共 14 条断言：首拍只建 基线 / 超拍不判老 / 门限含等号 / 跨 tick 回绕 / 倒退按分工不判老 / 双观察者互不污染 / 空参数不判老） - 台架注入（一次性停 TIM3 300 ms 探针，验完已撤；探针固件与最终 固件 Program Size 逐字节相同）： [+5462ms] [ERR][PROT] sampling FAULT -> protection blocked (hf=0x00000100) [+5757ms] [PROT] sampling recovered -> protection resumed 同次开机 [ADC_TASK] health: 出现 0 次；MISS 快照缺的正是 bit6 （0x1F7 - 0x1B7 = 0x40，实证 adcTask 当时确实阻塞，不是"在跑但没报"）； reset cause: 仅 1 次（300 ms 被 800 ms 容忍吸收，闭锁不靠复位） 证据 docs/测试说明/boot_log_data/20261021_probe_stale_gate_boot_log.txt - 字节卫生：BOM 无 / CR 0 / U+FFFD 0；新增行无非法字面量 gate: only mem-budget/mem-numbers pending lead ledger backfill pre-commit run --all-files 失败仅这两条（台账受管快照与本树 .map 的 Flash/RAM 水位漂移，即本次 +96 B Code、+24 B ZI）。按并行分支约定 本分支不跑 --write，台账由 Lead 合并后统一回填。 文档同步：设计说明新增 §15（原相关文档改 §16），§7 位表加 bit8 行、 §8 责任矩阵与「已知窗口」段改写为已闭合、§10 盲区第 3 条、§11 用例 表、§12 判读手册、§14 改前清单全部跟上；位图配图补 bit8 列，并修掉 生成器把列数硬编码成 8 列导致新列被备注框盖住的问题。 |
||
|
wandering1
|
60a650c175 |
fix(adc_task): 接上从未被调用的任务初始化入口（含判定层参照系）
问题：adc_task_func 函数头写「限定条件：adc_task_init() 已调用」，但 adc_task_init() 全库无调用点；同类空壳 net_task_init()（体内只有一条 DBG_INFO，函数头却写「创建 TCP Server 监听 Socket」）同样无人调用。 判定层为什么今天还没坏：状态全在 .bss（复位即 0），且 adc_health 的 首拍只建基线、不判定，所以漏调 init 只是「少清一次」。但假契约会让 下一个接手者照它推理，故必须修在成灾之前。 改动： - adc_task_func 进入循环之前（开闸 s_consumer_ready 之前）自己调用 adc_task_init()，不依赖外部接线；init 与首拍之间无抢占窗口 - adc_task_init() 去掉 DBG_INFO 并在函数头标注禁止加日志：它落在 adcTask 静态最坏调用链上，每条 DBG_* 约 216 B 栈，而这条启动行 无诊断价值（存活由首帧日志与 TASK_WD_ADC 心跳证明） - 删除 net_task.c/.h 里的空壳 net_task_init()（声明 + 定义 + 误述） - docs/算法/采样有效性校验设计说明.md §14 与变更记录同步改写： 原来登记的「init 不在产品路径」事实已修复，不留过时结论 实测（任务工作树 adc-health，构建 + 静态分析）： - @build 0 错 0 警；Code 213356 → 213424（+68 B） - RW-data 1184 / ZI-data 131480 逐字节不变 ⇒ RAM 零增量 - stack_report：adcTask 静态最坏链 1320 B → 1320 B 不变， 余 1240 B / 48% 仍 PASS（netTask 1912 B、protectTask 872 B 不变） - ADC 有效性单测 31/31 通过（钩子按 adc_task.c 自动触发） - 字节卫生自查：BOM 无 / CR 0 / U+FFFD 0，字符串字面量纯 ASCII （中文只在注释里），新增行无非 ASCII 字面量 gate: only mem-budget/mem-numbers pending lead ledger backfill pre-commit run --all-files = 33 Passed / 2 Failed，失败仅这两条， 均为台账受管区与本树 .map 的 Flash 差异（233,120 → 233,188，即本次 +68 B）；RW_IRAM1 75,240 与 RW_CCM 57,376 与台账完全一致。按并行 分支约定本分支不跑 --write，台账由 Lead 合并后统一回填。 另记一处门禁缺口（非本次引入）：ui-golden 的黄金参考 simulator/ tests/ref/ 被 .gitignore 排除、从未入库，新工作树里必然失败；本树 用 check_content_pages.py --update 生成 11 页基线后 ui-golden Passed （即本次改动对 UI 像素中性）。是否让基线入库待裁。 |
||
|
wandering1
|
513becd61d |
docs(algo): 新增 adc_health 单文件深设计与三张配图
- 新建 docs/算法/采样有效性校验设计说明.md（15 章）：判据推导
（100 ms 门限的三条独立依据）、电平/锁存/事件三种位语义与
位号对齐的收益代价、闭锁与 IWDG 兜底责任矩阵、观测盲区、
主机侧验证分工（11 组 TC / 31 断言映射）、现场判读手册、
自测问题与改前必读清单
- 配图走 draw-diagram 生成器路线（脚本 + 产物一并提交）：
tools/arch_diagram/gen_adc_health_flow_svg.py 等三个脚本 →
docs/images/ 下三张 SVG；文内另有 2 张 Mermaid（判定主干
flowchart、静默位生命周期 stateDiagram-v2，沿用仓内既有方言）
- 登记与指针：docs/README.md §5.2 加一行 + 变更记录；
docs/算法/采集与算法层设计说明.md §4 与 §13 加深读指针；
本文只写「为什么」，接口表仍由该文档属主，不重复
- 读码确认并如实登记三项（本提交不改代码，待裁）：
1) adc_task_init() 全库无调用点，adc_health_init() 因此不在
产品路径，判定正确只依赖 .bss 清零 + 首拍建基线
2) tgap 计帧点数（d-1 加权），adc1_gap 计次数——两侧单位
不对称，心跳里不可直接对比
3) TIM3 停摆时判定层随消费者一起停，最坏约 800 ms + 2498 ms
窗口内 protectTask 仍以旧相量判据（细节见 §10 / §14）
- 门禁自查：pre-commit 目标集全绿（doc-links / id-check /
空白 / EOF / 大文件）；主机单测 adc_health 31/31 复跑通过；
9 个新增或改动文件 BOM=无、CR=0、U+FFFD=0
|
||
|
wandering1
|
4d18e3b60d |
docs(测试): 补注 TC-NET-102 汇总行的真实来源（查清遗留，不是假 ✅）
查证链（全部有据，可复核） - |
||
|
wandering1
|
a9fd5572a3 |
docs(测试): 601/606/1006 标注真实覆盖状态（2026-10-21 用例清点）
按第 0 步的逐条覆盖核对结果写，不写笼统的「已覆盖」 - TC-NET-601：主路径确实由 602~605 + 701~704 覆盖（PC 侧 ch395f_socket_test.py:344-451 逐字节比对；固件侧 net_test_task.c:152 phase7_cksum 提供 32 位累加和），但「accept 返回同一 fd」的单连接语义与 「仅 Socket 0 状态变化、无其它 Socket 干扰」两点无任何观测 → 标部分覆盖， 不加状态词（既不是未实现也不是已覆盖，留着可见） - TC-NET-606：标未实现。不发 FIN 的静默断开 / KeepAlive 超时后 auto_relisten 能否自动回 LISTEN 无可重复观测；605 走的是干净 close（DISCONNECT 事件）， 与 TIMEOUT 路径机制不同，**不算覆盖**——这是本轮最实的一条发现： auto_relisten 是 FTP/对时/远程显示/104 四条链路共同的断连恢复底座， 而现场最常见的恰是拔网线、断电这类不发 FIN 的断开 - TC-NET-1006：标未实现。20 轮快速连接-断开与每轮回 LISTEN 的断言都没有； 单轮断开重连由 605 覆盖 验证：DOC-ONLY 15 → 12、NOTIMPL 1 → 4、BENCH 14 不变、错误级 632 → 626； id-check --strict 通过（未往债务台账塞条目）；doc-links --all 143 篇 0 失效； BOM=否、CR=0、U+FFFD=0 |
||
|
wandering1
|
43fbfa140b |
fix(门禁): 批 5 追溯器口径补齐——变更记录行不参与双向比对（未改任何号）
结论先行：我上一轮说「批 2 模块码单词化漏扫了 4 篇属主文档」——**被证据推翻** - 依据是 check_test_traceability.py 报的 DOC-ONLY 38 处里有 8 处旧模块码 （TC-AI-070/080/090、TC-PH-001/030、TC-TS-001、TC-VL-001），我据此写好了 逐号点名的改名映射表准备落盘 - 改名工具干跑 **0 处命中**：查下去这 8 处**全部在变更记录行**（| 2026-10-10 | … |）里， 写的是**当年**的用例名；按编号规范 §8.1 冻结历史不回改，旧号靠别名解析—— 而 TC-AI-070 → TC-ADCIN-070 这批**早在批 2 就已登记在 id_aliases.json** - 所以照原计划改等于**销毁历史记录、收益为零**。真缺口是判据：追溯器是唯一 没有「变更记录 / [示例] / [计划] 行豁免」的一支（check_ids / rename_ids / doc-links 都有），它把冻结历史当活引用 → 系统性假阳性 改了什么（判据，不改数据） - check_test_traceability.py 加 SKIP_LINE（与另三支脚本同源的豁免正则），两侧采集 都改为逐行判定，被豁免的号收进 frozen_ids 留痕，--verbose 全量列出—— **豁免不等于已对应**，别拿它当收敛 - 顺带把 has_intent() 的判定范围从整文件收窄到**同号所在行**（意图必须写在号旁边， 原先整文件里任何位置有人话就算过关，太松） 实测（关键是"没吞掉真对应"） - DOC-ONLY 38 → **29**（−9 全是冻结行假阳性，**不是真变好**）；总差异 45 → 36 - **交集 260 → 260 不变**：豁免只吐冻结行，没有让任何一条真实对应消失 - 代码侧 578 个号不变（识别面没缩，这是改名/改判据最容易踩的坑） - 错误级 632 不变（追溯不参与错误级计数）；可判定比例 83.02%；--strict 通过 剩 29 处是真问题，但**不是编号问题**（要人裁决，不由门禁决定） - 4 处无模块码形态（TC-1003 / TC-206 / TC-501 / TC-704）：② 大批的文档侧镜像 - TC-NET-607 一条是历史指称（原文「原 TC-NET-607/608/609，现 701/702/703」）， 一对多写不进一对一的别名表 - TC-NET-302/401/402/501 标题明写「（硬件层）」= 人工台架步骤，代码无载体是预期 - 其余 20 处（TC-NET-101/102/1101/601/606/701~704/801/802/901/902/1006/1501~1503、 TC-GD5F-503）**全库无任何载体**：文档声明了用例而代码/台架/模拟器都没有实现 另一个我自己的错误，记进 §8.3 而不只是提交信息 - 补别名时把 8 个键写到了 JSON **顶层**（真容器是 aliases，515 条）→ 条目完全无效； 是 assert k not in d['aliases'] 拦下的，删掉无效键后 id_aliases.json 字节与 HEAD 一致 - 教训：DOC-ONLY 这类两侧字面比对差异，先判它是不是冻结行/别名可解析，再谈改数据； 改名工具 0 命中与 assert 失败都是**信号**，不是小故障 文档：docs/编号规范.md §8.1 口径修正记录 + §8.3 批 5 行与经过段（含被推翻的判断）+ 变更记录； docs/代码规范/pre-commit使用说明.md §2.25 顺带收编行同步；脚本 docstring 同步 验证：check_doc_links.py --all 143 篇 0 失效；id-check --strict 通过；三个改动文件 BOM=否、CR=0；未改 C/H，不需 @build；台账无需收账（本轮 0 处销账） |
||
|
wandering1
|
52976bdec3 |
refactor(编号): 批 4 陷阱号统一为 TRAP-<模块码>-<nn>
本批是 ② 形态迁移清的第一族（用户裁定顺序：② 里的 Trap 一族先做） 统一了什么（数字不变、只补模块码，§7.1）——改名工具 23 处 / 11 文件 - Trap 01~07 → TRAP-GD5F-01~07：属主文档 7 个标题行从此成为定义位 - 陷阱 1 → TRAP-RTC-01（SD2506 属 RTC 域，§4.2）、见陷阱 01 → TRAP-GD5F-01 - Trap 21 / Trap 19 → TRAP-NET-21 / TRAP-NET-19（引用的是活登记处 CH395F_Trap_Records.md，号本身不变） - 波及 Drivers/BSP/GD5F2GQ5UE/*（4 处注释）与 test/board/*（2 处）→ 已重编 三处判读后**刻意不改**（写进 §8.3，不让人当成漏网） - docs/环境与部署/并行任务工作树方案.md 的 wip/trap22-fix 是 git 分支名，不是编号； 这类非编号字面量要靠类型处理，与位号 T1、IEEE 负序 S2、gitlint 规则 ID 同一批 - docs/UI设计/菜单页面设计.md 变更记录行的「陷阱 3」按 §8.1 冻结不改写 - docs/硬件平台/V0.0、V0.1 网表报告里 6 处 Trap05 语义确指 TRAP-NET-05，但该目录 是门禁与改名工具共同的排除语料 → 不越界动笔，盲区登记进注册表 TRAP 族 cursor_note 两处不是改名、是改错话（映射表类工具的典型失效：字面对了、意思错了） - scripts/README.md 原写「Trap 19 从未存在」；改名后字面变成 TRAP-NET-19，而它是 **真实条目**（SET_MAC 必须在 INIT_CH395 之前）→ 那句话成了假话，改用站得住的例子 - docs/编号规范.md 同一处事故叙述补准确说法：当年裸形不在册 ≠ 这个坑不存在 - 菜单页面设计.md 的「见 §8.2 陷阱 1」本就不是 TRAP-* 族的号（指本文小节第 1 条）， 改写成「见本文 §8.2 第 1 条（lv_text_get_width 的 length=0 陷阱）」 关闸第一次真拦人：咬的是自己家的审计表 - scripts/rename_maps/batch3-trap.json 里必然写着 Trap 21 / 陷阱 1 等旧形态， 被当成 6 类「台账外新账」→ 提交被拦（拦得对，但表不是语料） - 第 4 次同一类自循环（前三次：别名表、注册表、债务台账）→ 整个 rename_maps/ 目录入 excluded_paths；这条规律写进 §8.4：**登记号的表一律不得当引用语料** 实测变化 - 错误级 659 → 632（−27）；② 空格/中文形 Trap 残余 2 处（都是上面刻意保留的） - ③ 悬空错误 44 → 42：TRAP-GD5F-01/05/06 三处历史悬空引用自动落地为已定义 - 编号字面量 8277 → 8312（识别面没有缩水，这是改名最容易踩的坑）； 可判定比例 82.92% → 82.99%（基线 82.6%）；⑦ 定义无引用 100 → 103（如 TRAP-GD5F-02 只有定义位无人引用，如实挂 warn 不压掉） - 台账 --prune-backlog 收掉已还清 42 条，剩 298 条（只减不增）；--strict 通过 另修：core.autocrlf=true 把 SD2506_Trap_Records.md 检出成 CRLF（41 处）→ 还原 LF， 该文件 diff 只剩 1 行实质改动（仓库权威行尾是 LF，见 .gitattributes） 验证（全绿） - @build：0 错误 0 警告（Program Size Code=213356 RO=18580 RW=1184 ZI=131480） - ci_local.py：L0 + L0.5 全过（16 runner / 1104 断言） - check_doc_links.py --all：143 篇文档 0 失效、0 待确认 - 改动文件字节卫生逐项与 HEAD 对比：BOM / CR / U+FFFD 异常 0 审计轨迹与文档 - 映射表 scripts/rename_maps/batch3-trap.json（含作用域切分理由与刻意不改清单） - 别名 11 条全部带 scope；docs/编号规范.md §7.1 行状态、§8.3 批 4 行 + 说明段、 §8.4 自循环第 4 条、变更记录 |
||
|
wandering1
|
5a9988b557 |
chore(注释): 清掉源码里不可检索的过程编码
清掉的（读者无从解析、且所指文档已不存在） - 已删任务文档的编号：Task #32、其内部 §5 / §4.3、P1-5、P0-2、P1-4a、 "方案 a"、"Lead 批准 2026-10-12" - 正文里当代词用的文件版本号："（v2.7 起为 AboveNormal）""已随 v2.0 事件 驱动改造删除""（v2.0：DMA 消费）""见文件头 v1.3 说明"等 → 改写成陈述现状 - 测试与脚本同类：adc_input 桩头"v2.0：DMA 模型"、stub/adc.h 的 v2.0、 check_cubemx_survival.py 段头的"2026-10-10 v2.8"、run_all_suites.py 的"方案 A" 刻意保留 - 可检索登记簿锚点：P-AUDIT 真条目（P0-1/P1-8/P2-1/P2-9/P3-11）、S6/S11、 E-31/E-44、N-18/N-23/N-32、B1/B5/B7/B8、L1-x~L5-x 功能号 - 文件头修改记录块内的 vN.M（规范 V1.0 §2.1/§2.2 要求保留该块；块内编号 在本文件内自洽可读） 顺带纠正注释与代码已经不一致的过时事实 - 仍把 TIM6 写成现行节拍源：Src/main.c 的 include 注释与回调注释、 Src/freertos.c 的 adcTask 块 → 改 TIM3；adc_input.h 修订条目里"ADC1 只认 TIM2/TIM3/TIM8 的 TRGO"不准确 → 换成指向判据（ADC采样节拍设计说明 §3.2） - App/algo/phasor.c 双区注释称"唯一消费者是 adcTask、为后续保护任务预留"， 实际 protectTask 已跨上下文读（prot_elm_run -> phasor_get）→ 改为"读者跨 adcTask 心跳与 protectTask 判据两个上下文，勿改加锁、勿取消双区"，并同步 修正 docs/算法/采集与算法层设计说明.md 同一句 - adc_tick_irq_notify() 的"拒绝 ISR 内计算"理由仍写"内含 2 ms 忙等"（DMA 化 后已无忙等）→ 换成三条真实理由：任务级共享数据 / 计算量 / 生成区回调 - 裸 §5（指代不明）与"规划 §1.6 / 规划 §4"昵称式 → 写成完整路径紧邻式 字节卫生（Edit 会静默剥 BOM） - App/task/ui_task.c 与 Drivers/BSP/UI/ui_net_sink.c 被剥掉 BOM 两次，均按 3 字节 EF BB BF 前缀补回并复验；全部 20 个文件 CR=0、U+FFFD=0、无行尾空白 门禁 - @build 0 错误 0 警告，且 Program Size 与清理前逐项相同 （Code=213356 RO=18580 RW=1184 ZI=131480）→ 纯注释改动、中文未被误重编码 - ui-golden 首跑红：新工作树缺被 gitignore 的黄金参考 simulator/tests/ref/ （不入库、只在主工作树生成过）；从主工作树复制该基线后复跑通过 → 注释改动 零像素影响 - 全套 pre-commit 在这 20 个文件上 Passed（coding-standard / cppcheck / 6 个主机单测 / doc-links / task-table / mem-numbers / cubemx-survival / registration-check / mem-budget / font-charset / ui-golden / id-check） - id-check 可判定比例 82.71% -> 82.88%（删掉的是"形似 P-AUDIT 但查无定义"的 假锚点），悬空引用 863 -> 854 |
||
|
wandering1
|
64d8b052b1 |
docs(algo): App/algo/README 缩成目录索引，详细设计迁入 docs/算法
拆分层级 - 新建 docs/算法/采集与算法层设计说明.md（413 行、13 节）承接机制、契约、 判据与设计理由：定位与边界 / 数据流与初始化落点 / adc_input / adc_health / sample_ring / phasor / freq（7.1 为什么自适应窗、7.2 判据 J1~J6）/ prot_set / prot_elm / 关键约定与禁令 / 资源足迹 / 验证与判读 / 相关文档 - App/algo/README.md 360 -> 128 行：只留文件清单、依赖、逐文件"改代码必须 知道"的红线、构建与测试入口、新增模块动作；深挖改成逐条指针 - README 保留 §3.1-§3.7 原编号，既有"§3.7"引用不失效 索引与引用同步 - 索引：docs/README.md §5.2 新增行；项目架构总览主题表拆成"设计与判据 / 目录索引"两行；AGENTS.md 与 App/README.md 指向（后者原文还写着 L1/L2） - 按内容重指（编号仍在但内容已搬走，只核编号会静默指错）：App/algo/freq.h、 test/host/freq/freq_test.c、run_unit_test.py、继电保护规划 L2-4 行、 pre-commit使用说明 J4 行 -> 指向设计说明 - ADC采样节拍设计说明的两处指向同步改到新文档 修 README 内过时事实 - 挂载写"八个 .c"，实际 uvprojx 内 7 个 - SIM_EXEMPT 写"prot_set / freq 才登记豁免"，实际七个全在表内 - freq-unit-test 标"待登记"，实际已在 .pre-commit-config.yaml - 定值项数一处 31->40、一处 32->40；blob 144->176 B 证明是 32->40 - 用例与判据数字不再三处复制：属主是 test/host/<模块>/ 与 docs/测试说明/ 门禁 - doc-links --all 无新增问题；--sections-strict 覆盖 10 篇文档通过 - id-check 可判定 82.65%（基线 82.6，容差 0.1）；TC 双向追溯差异 124 处不变 - registration-check PASS（1 条已知 WARN）；freq 单测 46/46；@build 0 错 0 警 - 全部改动文件无 BOM、无 CR、U+FFFD = 0 |
||
|
wandering1
|
0f0d002afc |
docs(ADC): 采样节拍设计说明只留现状，历史决策与台架记录移出
删除（已确定的决策与过程记录，无现状信息量） - §2 方案选型（方案 A 推荐 / 方案 B 备选与结论） - §9 变更记录整表（9 行"已实现 / 已验收 / 已落地 / 复核修正"叙事） - §7.1、§10.3、§11.5 三张台架实测对照表 + 反向验证记录 + boot_log 证据行 - 用户决策与过程编号（Task #32 P1-5 方案 a、B1、P0-1/P0-2、v2.0/v2.2/v2.7/v2.8、 "规划未预见""原规划写错了"更正叙事） - §4 代码改造清单（改造已完成）与 §8 / §10.5 的后续规划口吻 保留并补齐现状 - 链路总览（新增 TIM3 同源 Mermaid）· 实现落点表 · TIM3 配置与"为什么是 TIM3" （F4 触发清单是硬约束）· ADC1 + DMA 四条硬约束与半区无竞态推导 · 上电自校准 · TPAFE 侧契约与原子快照 · 就绪门与节拍缺失 fail-safe · 单周期时序 · 心跳计数逐个判读（含相位伪影为何阈值取 2）· 性能与资源特征 · 设计边界与已知代价（N-18 无同刻性、滞后一拍、TPAFE 未 DMA 化的前提未定、 调频能力现状）· 设计铁律 - 468 -> 344 行 顺带修掉文档自相矛盾 - 原 §3 / §4 仍在教人配 TIM6（§11 已改 TIM3）-> 全文统一 TIM3 - 上位需求引用写成 继电保护功能复现规划.md §3.2，实际 L1-1 在 §3.1 连带引用同步（7 文件 8 处） - App/algo/adc_input.c -> §8；App/task/adc_task.c -> §6；Src/main.c -> §3.3； Src/freertos.c -> §9 与 §10（顺带纠正已失效的"ADC 2 ms 忙等"表述，DMA 化后 单拍取数已零忙等） - 看门狗设计说明 §6 与 §9 / §4.4；ADC通道映射说明 §4 与 §6； 继电保护功能复现规划 §3.2 - 其中 2 处活断链 doc-links --all 抓不到（整行含"已消""已实现"状态词被豁免）， 另写脚本按「文档名 + 章节号」全库扫出后修复 门禁 - doc-links --all（非 SDL2 问题 0，可判定 57% -> 58%）与 --sections-strict 通过 - no-mojibake / trailing-whitespace / end-of-file-fixer / id-check 通过； task-table / mem-numbers 一致；@build 0 错误 0 警告 - 改动文件均无 BOM、无 CR、U+FFFD = 0；CubeMX 文件的注释改动都落在 USER CODE 区 |
||
|
wandering1
|
858434492c |
feat(门禁): id-check 关闸——按债务台账增量拦截，warn-only 时代结束
机制（--strict 不再「有错就失败」，而是只拦台账外的新账） - scripts/id_known_backlog.json：340 条指纹覆盖 710 处存量（②167 类 / ⑥135 / ③38） - 指纹 = (文件, 校验号, 字面量) → 计数，故意不含行号：行号每改必漂， 用它当指纹会让台账天天假新增，三天后没人敢看 strict，台账失效比没台账更糟 - 带计数而非集合：同一文件里同一个号多出现一次也算新账（复制粘贴式扩散 正是编号烂掉的主路径，只按「出现过没有」判会放过它） - 新增 --write-backlog 与 --prune-backlog（只减不增；台账内条目变多当场点名）； --strict 缺台账返回 2，绝不退化成一次性拦死存量；--only 与 --strict 互斥 - 钩子 entry 加 --strict；--only 与 --strict 互斥 - 顺带修 _scan_malformed 的反向 bug：原条件 (skip and name != "空格形 Trap") 语义正好写反，带 [示例] 的行反而专被 Trap 规则咬；改为示例行全部不判 - 第一次提交就被自己的台账咬住（id_known_backlog.json 里当然写着 P1-3 等号， 被当成新引用）→ 台账加入 excluded_paths：登记号的表不是引用号的文档， 与 id_aliases.json / id_registry.json 同一条道理 为什么不照「清零再升 strict」的原节奏（§8.4 详述） - 存量 710 处清完要数周，这期间新债一条都不拦，而新增才是烂掉主因 - 「等清零」让人习惯「报红但照样提交」，真关闸那天没人再信门禁； 本仓已有 mem-budget / mem-numbers 走 --no-verify 的先例，不再开第二个口子 关闸验收三例（临时件当场还原、git diff 干净） - A 全新前缀 Z-99 → exit 1 点名 ✅ 咬 - B 同号计数 1→2 → exit 1 点名 ✅ 咬 - C 干净态 710 处 → exit 0 放行 ✅ 放（放不住存量就会逼出 --no-verify） 验证：--strict 干净态 exit 0；可判定比例 82.74%（基线 82.6%）； doc-links 失效/待确认 0；未改 C/H 不需 @build。 文档：编号规范 §8 上线节奏改写 + 新增 §8.4 机制表；pre-commit使用说明 §2.25； AGENTS.md 门禁行由 warn-only 改为已关闸增量拦截。 |