 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 / 行尾空格全清。已提交本地，未推送。
|
2026-10-22 15:08:04 +08:00 |
|
|
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 转绿。
|
2026-10-22 11:03:05 +08:00 |
|
|
wandering1
|
af411866a8
|
feat(门禁): 批 9 位号规则扩展到引脚名 + 修 --prune-backlog 丢 reason 的 bug
规则扩展（scripts/check_ids.py，两处共用同一正则）
- 原：^[RCDJXUT][0-9]{1,3}（单字母位号）
- 现：再加 ^[A-Z]{2,3}[0-9]{1,2}(-[0-9]{1,2})? → 收掉硬件语料里的**引脚名 / 总线名 /
网名 / 引脚区间**：PB12-15、PG0-15、PF13-15、DB0-15、OS0-2、KEY1-3、AIN1 这类
- 关键边界：带连字符的一字母形态（C-10 / A-9 / N-18 / D-7）与 TC-206、TC1003 **不落在
新形状里**，照旧判定 → 报告自有条目号这类真编号没被顺手挡掉（实测台账仍留 21 类真债）
- 位号与引脚名都不进 refs_total：错误级 661 → **651**，refs_total 8807 → 8797（同步 −10），
可判定比例 82.84% → **82.94%**（分母没被噪声灌水，涨幅来自噪声出清而非真进展）
修自己的 bug：--prune-backlog 会静默丢掉 reason 字段
- 症状：收账一次后，那 28 类硬件存量条目的「这笔债为什么该存在」说明全部消失
- 根因：prune 用 dict 字面量重建条目，只写了 file/code/literal/count 四个键
- 修法：改为从原始 JSON 取整条再覆盖 count，其它字段原样保留；已实测幂等
（再跑一次「还清 0 条、剩 313 条、带 reason 仍 21 类」）
- 21 类真债的 reason 已重新写回，内容含一条判断：器件料号 FOC-817 **不做**形状规则，
因为 [A-Z]{3}-\d{3} 与真家族 DEF-* 撞形，宁可留一条记账也不制造盲区
验证：id-check --strict 通过（存量 651 全在台账内、无未登记新账）；
doc-links --all 失效与待确认均 0；未改 C/H 不需 @build；台账只减不增
|
2026-10-22 08:49:39 +08:00 |
|
|
wandering1
|
125140a3c6
|
feat(门禁): 硬件语料纳入扫描——位号不进编号也不进比例分母
- check_ids.py 扫描循环：位号（[RCDJXUT][0-9]{1,3} 无连字符）在 refs_total 之前 continue，
既不产生结论也不灌分母；add() 里的同一道判定保留作兜底
- 注册表 excluded_paths 移除 docs/硬件平台/（docs/芯片手册/ 仍排除）
- 首次纳入暴露 28 类先前不可见的存量 → 按规矩逐条写 reason 入台账（**不重打快照**，
台账只增带理由的条目）；错误级 626 → 661，可判定 82.84%（基线 82.6 仍守住）
- 遗留噪声已在 designator_rule 记明：引脚名 PB12-15 / PG0-15 / DB0-15（两字母+数字+区间）
不是编号，但位号规则不覆盖这种形状，先记账、待加 pin-name 类型规则后清除
- 验证：--strict 通过（无未登记的台账外新账）；未改 C/H 不需 @build
|
2026-10-22 06:43:58 +08:00 |
|
|
wandering1
|
11c82c0d99
|
feat(门禁): 位号类型识别机制落地（暂不纳入硬件语料）
- check_ids.py 的 add() 加一道类型判定：硬件类语料（docs/硬件平台/、docs/芯片手册/）里
匹配「单个大写字母 + 1~3 位数字、无连字符」的字面量判为**位号**（R 电阻 / C 电容 /
D 二极管 / J 接插件 / X 晶振 / U 芯片 / T 变压器），直接不产生编号结论，并计数到
stats[designator_skipped]，不是静默放过
- 两处刻意收窄：字母集**不含 B**（V0.0 网表报告里的 B1 是真专项条目）；要求 fullmatch
无连字符，所以 D-7 / N-18 / TC-206 / TC1003 这些真编号与违规形态一律照旧判
- 注册表新增 designator_rule 说明口径；**本批不解除 excluded_paths 里的硬件目录排除**：
粗测该目录约 4200 处位号，会灌进可判定比例的分母 refs_total，把真实变化盖掉——
解除排除必须先把位号从分母里减掉，那是下一件事
- 因此本批对现有数字零影响：错误级仍 626、可判定比例不变、--strict 通过
|
2026-10-22 06:38:29 +08:00 |
|
|
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
|
2026-10-22 06:33:00 +08:00 |
|
|
wandering1
|
ebe2807ffd
|
docs(内存管理): 回填 adc-health 合并后的 Flash/RAM 快照
CI / L0 静态门禁 (pre-commit) (push) Failing after 2m31s
CI / L0.5 主机侧单测 (MSVC) (push) Successful in 20s
合并 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 例外闭环（见
9f826db 与 790e153 提交正文的 gate 行）。
验证：check_mem_numbers.py --write + ram_baseline.py --write 后两条钩子
Passed；pre-commit run --all-files 全绿；@build 0 错 0 警
（Code=213520 RO=18580 RW=1184 ZI=131504）。
|
2026-10-22 00:47:39 +08:00 |
|
|
wandering1
|
0a66e56770
|
merge: task/adc-health-design-doc 合入 v2-on-ui
任务 adc-health（4 个提交）经 task-worktree 回收：
- fix(adc_input): 丢帧计数改按帧点数累计，与 TPAFE 侧 tgap 同单位
- fix(protect): 采样陈旧时独立闭锁保护（判定层失明的兜底门）
- fix(adc_task): 接上从未被调用的任务初始化入口（含判定层参照系）
- docs(algo): 新增 adc_health 单文件深设计与三张配图
|
2026-10-22 00:44:32 +08:00 |
|
|
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 合并后统一回填。
|
2026-10-22 00:43:32 +08:00 |
|
|
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 列导致新列被备注框盖住的问题。
|
2026-10-22 00:43:32 +08:00 |
|
|
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 像素中性）。是否让基线入库待裁。
|
2026-10-22 00:43:31 +08:00 |
|
|
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
|
2026-10-22 00:43:31 +08:00 |
|
|
wandering1
|
a26a9d6f52
|
test(NET): 阶段 8/9 实现体补挂用例号 TC-NET-801/802/901/902
先纠正我上一轮的错判：这 4 条不是「被重构丢掉」，实现体一直都在，
只是从来没挂号——我在旧路径 test/ch395f_test_task.c 里找，而它们已在
2026-08-26 前后搬进 test/board/net_test_task.c（文件搬迁导致我误判成删除）
判据（为何不是有目的删除，也不是遗漏实现）：
- 开关在（ch395f_test.h:62/63）、调用点在（net_test_task.c 主循环 phase8_run /
phase9_run）、函数体在（phase8_run / phase9_run）三者齐全 → 若是有意删除
必然连开关与调用一起清掉
- 内容逐条对得上：phase8_run 按 PHASE8_DIRECTION 编译期切 SEND/RECV、逐字节 +
尾附 4B CRC32（= TC-NET-801 SEND / TC-NET-802 RECV）；phase9_run 注释即
「有数据返回正数 / NET_FD_ISSET 正确 / 超时 50ms 返回 0」
（= TC-NET-901 就绪检测 / TC-NET-902 超时）
→ 所以按用户的判据（没意义才删）结论是**不删**，删了反而抹掉四条已有覆盖的入口
验证：@build 0 错误 0 警告，Program Size 与改前逐字节相同 → 只动注释；
DOC-ONLY 10 → 6、追溯交集 261 → 265；id-check --strict 无台账外新账；
BOM=否 CR=0 U+FFFD=0
|
2026-10-21 23:45:06 +08:00 |
|
|
wandering1
|
3c69411409
|
test(NET): 阶段 1 实现体补挂用例号 TC-NET-101 / TC-NET-102
手法与上一批 TC-NET-1101 相同：只把号挂到已有实现体的注释上，不改任何语义
- 第一轮第 1 项处补挂 TC-NET-101（附录 B 的 ✅ 由此可走到实现体）
- 第一轮第 6 项处补挂 TC-NET-102，并注明条目何时删、汇总行为何遗留
顺带修一处被门禁当场咬住的写法：注释里原写「P1-01~P1-09」这个范围式，
让校验 6 多出 2 类台账外新账 → 按既定规矩改写成平实语言，**不往债务台账塞条目**
验证：@build 0 错误 0 警告且 Program Size 与改前逐字节相同
（Code=213356 RO=18580 RW=1184 ZI=131480）→ 证实只动注释；
id-check --strict 通过（无台账外新账）；doc-links --all 143 篇 0 失效；
追溯交集 259 → 261（101/102 两侧现在都有号，是真对上，不是靠注记压掉）；
BOM / CR / U+FFFD 与 HEAD 逐项一致
|
2026-10-21 23:35:40 +08:00 |
|
|
wandering1
|
4d18e3b60d
|
docs(测试): 补注 TC-NET-102 汇总行的真实来源（查清遗留，不是假 ✅）
查证链（全部有据，可复核）
- b0feaff 2026-07-22 引入「### TC-NET-102: 全局中断状态一致性」正文条目 + 汇总行 ✅
- c2fb2d9 2026-08-22「构建测试」删掉正文条目，附录 B 汇总行未同步 → 号从 3 处减到 1 处
- 现在 ch395f_test_task.c:179 起的第一轮第 6 项测的就是同一件事：
ch395f_get_glob_int_status_all() 先自清读、延时 10ms、第二次读断言 0x0000
所以那个 ✅ 说的是真事，只是没人能从号走到证据；测试项从未被放弃，
丢掉的只是条目与编号映射。据此不删行、也不改成失败，而是写实状态列。
|
2026-10-21 23:35:35 +08:00 |
|
|
wandering1
|
514a514601
|
test(NET): 阶段 11 实现体补挂用例号 TC-NET-1101
不是新增测试，是把已有实现体的号补上：ENABLE_PHASE11_TESTS 在
ch395f_test.h:65 是打开状态，实现体在 net_test_task.c:810 起（phase11_run），
但从未挂 TC-NET-1101 → 追溯器把它当成「文档声明却无载体」
改法：只在阶段 11 说明块补一行用例号注释（含属主文档路径，满足 §5.2 紧邻要求）
验证：@build 0 错误 0 警告，Program Size 与改前逐字节相同
（Code=213356 RO-data=18580 RW-data=1184 ZI-data=131480）→ 证实只动注释；
BOM / CR / U+FFFD 与 HEAD 逐项一致；id-check --strict 通过
|
2026-10-21 23:14:31 +08:00 |
|
|
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
|
2026-10-21 23:14:25 +08:00 |
|
|
wandering1
|
fca414102e
|
fix(编号): 批 6 追溯器分档 + 板级 NET 用例号标注归一
步骤 1：追溯器分两档（不改数据，改判据）
- BENCH：文档**定义行**（标题行或表格首格）带「（硬件层）」或其所属章节带的号 →
人工台架用例，不期望有 C 代码载体；NOTIMPL：定义行标了未实现/待补/暂缓/已取消
- 两档**单列示数恒打印**、明细进 --verbose，不是静默豁免；也不等于"已验证"
- 两个实测坑写在脚本注释里：① 按"任意行出现即算"实现时 BENCH 收 14 个号却只消掉
1 处差异（同一号被别处引用一次就复活）→ 改为只认定义行 + 从文档全集整体减档；
② 载体类型必须由定义处决定，引用行不影响判断
- 另把 has_intent() 收窄到同号所在行（原先整文件任意位置有人话就算过关）
步骤 2：板级 NET 用例标注归一（真债，改名 109 处 / 5 文件）
- 取证发现"文档声明却无载体"绝大多数是**标注形态烂**：实现体里写的是
TC204 / TC-201 / TC 703 / TC1501 / TC1502b（三种畸形），文档写 TC-NET-204 等
- 序号一位不改、只补模块码（§7.1）；作用域限定 5 个真载体文件：
test/board/ch395f_test_task.c(67) net_test_task.c(37) net_test_task.h(1)
test/host/ch395f_socket_test.py(3) Drivers/BSP/CH395F/ch395f.c(1)
- 审计轨迹 scripts/rename_maps/batch6-net-annotate.json；别名自动登记（scoped）
实测
- DOC-ONLY 29 → 15：701~704 的 NET 层实现体一直存在（net_test_task.c），
此前因裸形标注被误判成"未实现"；1501~1503 属硬件层人工 + 同样裸形
- 交集 260 不变、代码侧 578 不减（识别面没缩）；BENCH 14 个号 / NOTIMPL 1 个
- 台账 --prune-backlog 还清 6 条（只减不增）；@build 0 错误 0 警告
（Program Size 与改前逐字节相同：Code=213356 RO=18580 RW=1184 ZI=131480
→ 证实只动了注释与日志串）；7 个改动文件 BOM/CR/U+FFFD 与 HEAD 逐项一致
剩余 15 处 DOC-ONLY 的组成（步骤 3 未完，下轮处理）
- 4 处文档侧无模块码形态（TC-1003/206/501/704）→ 属 ② 大批
- TC-NET-607 一条是历史指称（原文"原 607/608/609，现 701/702/703"）
- 真未实现 10 条：TC-NET-101/102/601/606/801/802/901/902/1006/1101
——其中 801/802/901/902 曾在 2026-08 的代码里有载体、后被重构丢掉，最值得补
|
2026-10-21 13:53:06 +08:00 |
|
|
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 处销账）
|
2026-10-21 13:25:06 +08:00 |
|
|
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 条、变更记录
|
2026-10-21 12:32:13 +08:00 |
|
|
wandering1
|
51604f7717
|
merge: task/doctrim-adc-tick-history 合入 v2-on-ui
CI / L0 静态门禁 (pre-commit) (push) Failing after 50s
CI / L0.5 主机侧单测 (MSVC) (push) Failing after 45s
任务 doctrim（3 个提交）经 task-worktree 回收：
- chore(注释): 清掉源码里不可检索的过程编码
- docs(algo): App/algo/README 缩成目录索引，详细设计迁入 docs/算法
- docs(ADC): 采样节拍设计说明只留现状，历史决策与台架记录移出
|
2026-10-21 11:44:31 +08:00 |
|
|
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
|
2026-10-21 11:39:53 +08:00 |
|
|
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
|
2026-10-21 11:39:53 +08:00 |
|
|
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 区
|
2026-10-21 11:39:52 +08:00 |
|
|
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 改为已关闸增量拦截。
|
2026-10-21 11:35:30 +08:00 |
|
|
wandering1
|
d74cd030ea
|
fix(门禁): 追溯脚本与 B 层口径对齐 + [示例] 行豁免写反的 bug
为什么改（第 1 件，用户裁定的顺序）
- B 层已认 test/host/<模块>/* 为 TC 号属主登记处，但 check_test_traceability.py
仍按老规矩要求"每个号都必须出现在文档" → 两处判据互相打脸
- 实测矛盾面 284 处里有 173 处属于该口径：照老口径升 --strict 会当场拦死这些
本不该写文档的号，唯一出路是 --no-verify——门禁公信力就是这么丢的
追溯差异改为三档（口径与编号门禁一致）
- DOC-ONLY：文档声明了、代码没有 → 真断链，38 处
- CODE-ONLY：代码有、母号不在登记处、**且号旁边没写人话意图** → 真未登记，7 处
- IN-CODE：靠"号旁写着意图"放过 → 238 处，**弱于文档的保证，单列示数不算过关**，
对外举证仍需 C 层模块级说明（脚本里写明这条边界，禁止把它读成"已登记"）
- 小写子项后缀（TC-TIMESYNC-003b）按母号算，与 check_ids 的 subitem_ok 同口径
- 真差异从 284 降到 45（38 + 7）
顺带修两个自己的 bug
- TC_RE 模块码上界停在 {0,4}：批 2 模块码单词化（ADCHEALTH 9 位）后代码侧集合
从 556 悄悄缩到 217（339 个号隐形）→ 放宽到 {0,8}。**同一个坑第二次踩**，
第一次是 check_ids.py 的候选正则——改名必须复核**所有**识别面，已写进 §8.1
- _scan_malformed 的豁免条件写成 `(skip and name != "空格形 Trap")`，语义正好反了：
带 [示例] 的行反而专门被 Trap 规则咬。改为示例行**全部**形态规则不判，
并给引用示例号的两行文档补 [示例] 标记
验证
- 编号门禁：错误级 712 → 710，可判定比例 82.73%（基线 82.6% 未跌破），校验 1/4/5 仍 0
- 追溯：代码侧 578 / 文档侧 298 / 交集 260 / 差异 45；--board-only 回退口径不变
- check_doc_links.py --all 文档路径与章节引用均通过；字节卫生复查 BOM=否、CR=0
- 未改 C/H，不需 @build
文档：docs/编号规范.md §8「顺带收编」条目改写 + §8.1 口径修正记录补两行 + 变更记录；
docs/代码规范/pre-commit使用说明.md §2.25「顺带收编」行同步三档口径
|
2026-10-21 11:24:05 +08:00 |
|
|
wandering1
|
4b9a4f4e24
|
refactor(编号): B 层口径落地——主机侧单测认代码为属主登记处
为什么不是"补 7 篇文档"
- 实测这些号在代码目录外**零消费者**（NANDPORT 47 / PROTELEM 13 / PROTSET 11 /
FREQ 11 / FTPAUTH 10 / SHA256 8 / SOE 7 / ADCHEALTH 11 / IEC104 23，共 141 号），
唯一"外部引用"是 scripts/id_aliases.json 自己 → 逐号写文档等于造一份没人读、
还要跟着代码同步改的复述层（违反"同一事实只在一处详述"）
判据与注册表改动
- 新增 9 族 TC-HOST-<模块码>：class 仍为 TC（跨模块同号照旧由校验 4 抓）、
owner_docs_glob = test/host/<目录>/*、每模块游标做号段不越界（含 IEC104 补漏：
它上批改名前是纯数字 TC-104-*，没进当时的悬空普查所以漏建族）
- 新旗标 allow_orphans（不补该旗标会让 141 号全变孤儿告警）、
subitem_ok（小写子项后缀母号在册即算已定义，差异仍由双向追溯如实报）
- snapshot_only：§4.3 冻结快照族不参与"定义位优先"——先试无差别生效时，已销项的
登记簿 N-21 被审计报告同号接管，校验 6 从 266 暴涨到 1437、可判定比例假崩 68.7%，
且提示会教人补错文档名（正是 §1.2 的 N-31 撞号制造方式），故回退并改为快照族豁免
- excluded_paths 加 scripts/id_aliases.json 与 scripts/id_registry.json：
别名表/注册表自身不得制造引用面
- T-2 / T-3 / T-4 / T-6 入别名表标 void（2026-10-02 复审专项条目，销项只删行没清引用）
修自己的漏配（这条是 bug 修复，不是口径）
- N / S-LDG / T-LDG 族漏登记 docs/任务规划/README.md（活登记处，N-21 在其中出现 2 次），
只登记了 docs/任务规划/登记簿.md（N-21 为 0）→ 74 处真条目被误判
数字与诚实交代
- 错误级 1318 → 711（②398 + ③44 + ⑥269）；可判定比例 82.74%（基线 82.6%）
- ⚠ 其中 504 处属**口径修正**、74 处属**修 bug**，**真正变好 0 处**；已在
docs/编号规范.md §8.1 写口径修正记录表，禁止拿 711 与 1318 直接比
- 文档：§4.1 补 TC-HOST 说明、§8.1 口径修正记录、§8.3 批 3 行、变更记录；
pre-commit使用说明 §2.25 判定口径与最新实测同步
- 未改任何 C/H，不需 @build；提交钩子即 L0 + L0.5 全量验证
|
2026-10-21 10:51:25 +08:00 |
|
|
wandering1
|
bda7ab2b50
|
refactor(编号): 16 个测试模块码单词化 + 门禁识别面连带放宽
批 2（用户授权改名 + 「新名要一眼看懂」裁定）
- 16 个有歧义模块码单词化，共 1,146 处随 scripts/rename_ids.py 改写：
AI→ADCIN、AH→ADCHEALTH、PS→PROTSET、PE→PROTELEM、PH→PHASOR、
TS→TIMESYNC、VL→VOLLOCK、NP→NANDPORT、CFG→CONFIG、CLK→SYSCLK、
WD→WATCHDOG、STO→STORAGE、SH→SHA256、FA→FTPAUTH、FR→FREQ、104→IEC104
- 不动 NET/GD5F/RTC/SOE/UI/ADC/LOG/RS485/TOOL（已是单词、芯片名或业界通用词，
改了纯属 churn）
- 别名按全局登记：这批字面量已完全限定（TC-<码>-<nnn>），不存在裸形多义
- 映射表存档 scripts/rename_maps/batch2.json 作审计轨迹；§6 模块码表同步
连带修门禁（关键教训）
- 模块码涨到 9 位（ADCHEALTH/WATCHDOG）后，候选正则与族正则的 {0,4} 上界
会让改名后的号**整批从门禁眼里消失**：实测编号字面量从 8271 掉到 7315、
悬空假降 490 处。已放宽到 {0,9} 并写进 §6 注记
- 结论：改名批次必须连带复核识别面，只改数据不改判据 = 静默放行；
这次是靠「可判定比例跌破基线即失败」那条线拦下来的
现状与遗留
- 校验 1 未登记前缀 0 处；可判定比例 82.71%（基线 82.6%，只涨不跌成立）
- 遗留：7 个模块的「单元测试说明.md」仍缺（PROTSET 116、NANDPORT 109、
PROTELEM 65、FREQ 48、FTPAUTH 45、SHA256 25、SOE 14 处悬空）——改名不解决
缺文档，处置方式待议
- 遗留：T-2/T-3/T-4/T-6 历史任务号悬空（别名表未收全，属本工具批次漏项）
- 未改任何 C/H 可编译语义（仅注释与宏名内的编号），故不需 @build
|
2026-10-21 09:53:28 +08:00 |
|
|
wandering1
|
301c3e5183
|
feat(门禁): 编号门禁 id-check 落地（36→37 钩子）+ 批 1 编号单词化改名
新增门禁本体
- scripts/check_ids.py：实现 docs/编号规范.md §8 八项校验；默认 warn-only，
唯一硬拦项是「可判定比例跌破基线」（防回退的本体）
- scripts/id_registry.json：66 个前缀族，逐项来自 §4 总表 + 全库实测游标，
偏差一律写进 cursor_note，不凭记忆编造
- scripts/id_aliases.json：旧号 → 新号 / 作废标记（照搬 section_aliases.json 范式）
- 顺带收编 check_test_traceability.py：正则补齐大写后缀与无模块码形态，
比对范围扩到 test/host 与 7 篇「单元测试说明.md」，另加 --board-only 回退旧口径
批 1 改名（用户授权解禁「不改写存量号」）
- 代码规范条款 S1~S19 → CODE-RULE-nn：78 处 / 2 文件
- UI 像素回归状态 S0~S7 → MENU-STATE-nn：61 处 / 3 文件（冻结在 07）
- 两族属主登记处 = 脚本自身的规则表 / STATES 表，文档只作引用方
- 新增 scripts/rename_ids.py（§7.3 规划脚本）：映射表驱动、显式 scope、默认干跑、
自动写 scoped 别名，跳过 [示例]/[计划] 行与变更记录表，按原字节读写保 BOM 行尾
- 已应用映射表存档 scripts/rename_maps/batch1.json 作审计轨迹
有牙实测（证明门禁不是空转）
- 注入 Z-99 / 裸形 / 悬空 / 越游标 / 未紧邻 / 跨文档重复定义 六例，
分别被校验 1/2/3/5/6/4 点名，--strict 退出码 1；临时档删除后工作树干净
验证与同步
- 可判定比例基线 82.3% → 82.7%（已 --update-baseline 入档）；错误级 1312 → 1291
- ci_local.py 全绿（L0 + L0.5 共 1104 断言）；ui-golden Passed；
check_doc_links.py --all 无法判定 0
- 未改任何 C/H 源文件，故本次不需 @build
- 文档：AGENTS.md 与 pre-commit使用说明.md 计数 36→37 并新增 §2.25 详解；
编号规范 §4.1 补两行、§8.1 落地记录、§8.2 规范与仓库偏差、§8.3 迁移批次记录
|
2026-10-21 09:33:54 +08:00 |
|
|
wandering1
|
efeaccbb18
|
docs(规划): U5 明确暂缓，等页清单
CI / L0 静态门禁 (pre-commit) (push) Failing after 3m27s
CI / L0.5 主机侧单测 (MSVC) (push) Successful in 39s
报告 §6.5 U5 行与任务规划 README 的 W6 行补一句带日期的裁定：
剩余页面尚未规划，本轮不补页；现存 7 个 ui_page_*.c 即当前全部内容，
报告里的 27 页是目标数、不可当差集清单用。
U1-U4 已全部落地，故 U5 未来开工是纯增量活（实测新增一页 = 3 处人工 +
1 条生成器命令，且 ui-golden 已在提交门禁兜像素）。
此前这两处读起来像"随时可开工"，与实情不符，会误导排期。
未改 §1.1 编号列表（§2 有引用，不可重编号），只改两个表格行。
|
2026-10-20 23:11:40 +08:00 |
|
|
wandering1
|
fafe13f7ea
|
docs(报告): 状态表与 U2 落地对齐
§6.x 组件清单 `ui_w_records` 行：未建 -> 已建成，附证据与实测增减（-116 B / +8 B）。
§6.5 U2 行：未办 -> 已落地，指回组件行避免同一事实两处详述。
§0.1 UI 行：改为"组件库已起步但仅此 1 个组件"，不夸大成已有组件体系。
代码已随 64abefa 入库，此处只补状态表，不让文档比仓库旧。
|
2026-10-20 22:58:39 +08:00 |
|
|
wandering1
|
64abefaa00
|
refactor(UI): U2 合并运行/自检记录两页为共享组件 ui_w_records
ui_page_runlog.c 与 ui_page_selftest.c 各 102 行，逐行比对后差异全是命名：
唯一的功能变量是日志 ID（SYSLOG_RUN / SYSLOG_SELFTEST），计数、每记录 2 行、
同记录读盘缓存、空态伪行的实现两边逐字相同。是真重复，不是推测出的抽象。
## 落地
新建 Drivers/BSP/UI/ui_w_records.{c,h}（已在 uvprojx + CMakeLists 双端注册；
生成器只自动管 ui_page_*.c，故这两处手工加）。两页各留一个实例与两个薄跳板，
.count_cb/.refresh 名字不变 => 注册表与生成器零改动。
净效果：两页 90 删 / 28 增（−62 行），重复逻辑收成一份。
## 合并唯一的真陷阱：缓存归属
count_cb/refresh 签名里没有 user context，最容易写的版本是把
s_cache_valid / s_last_rec / s_ts / s_desc 留成组件级静态——那样两页共用一份
缓存，从 A 页切到 B 页会因记录号相同而直接命中缓存，显示另一页的陈旧行，
是静默错数据而非崩溃。故缓存内嵌进实例（ui_w_records_t），每页各一份。
## 验证
@build 0 错 0 警；golden 经真实 ui-golden 钩子跑通：菜单 8 状态 + 内容页
11 页（含这两页）逐字节一致，未用 --update 刷基线 => 语义搬迁行为等价有证。
ER_IROM1 232,052 → 231,936 B（−116 B）。RW_IRAM1 75,232 → 75,240 B（+8 B），
原因如实记录：原先 4 个文件级静态零初始化落 ZI，现在 s_rec 带 .id 初值整个
结构体落 .data(RW)，两页合计净 +8 B；要压回 0 需把 .id 留零再加 init 钩子，
为 8 字节引入运行时初始化顺序不值得，故保留并把账写在此处。
stack_report FAIL 行数 0（间接层未顶破栈预算）；mem-budget / mem-numbers 已
按 @build 后规定回填台账。
## 过程中的两处自我失误（已修复，记录以免重犯）
① 用 stem[:2] 生成函数前缀，对 selftest 得到 se_ 而非 st_，锚点失配。
② 撤销脚本里 ${UI_DIR} 被 PowerShell here-string 插值吞掉，导致"边校验边写"
把树留在引用组件但未注册的链接错误态。教训：回滚脚本必须比正向脚本更保守，
全部校验通过后才允许写盘。
|
2026-10-20 22:57:13 +08:00 |
|
|
wandering1
|
44dec5c49b
|
feat(UI): golden 像素回归入提交门禁（W6 U4 第三件，35→36 钩子）
补上我上一轮自己标记为 2/3 的那块缺口：两个 golden 脚本早已存在且一直在
人工跑，但**从未进自动门禁**——"有基线"不等于"有门禁"（§6.1 原文即自认）。
## 先实测成本再定形态
改一个 UI 源文件后「增量重编模拟器 + 两条 golden」合计 **2~4 秒**，支持走
自动门禁。若实测要几分钟，正确做法是明确不挂、改为文档化人工门禁——一个
逼人 --no-verify 的门禁等于没有门禁，故这个数字是本决定的前提而非附注。
## 落地
新增 scripts/check_ui_golden.py：串「增量构建 → 菜单 8 状态 → 内容页 11 页
+ 池水位」。**有意忽略 argv 且 pass_filenames: false**——两条 golden 按整棵
菜单树 + 全量参考图工作，不接受文件参数，pre-commit 传的变更名对它无意义。
files: 覆盖 UI 源 + ui_task.{c,h} + 模拟器 tests/sim/src + main.c +
CMakeLists + lv_conf.h + 包装器与本配置自身（pre-commit 4.x 无 always: true，
files 是唯一触发手段）。
## 端到端验的是钩子，不是脚本
干净树连跑 3 次 rc=0 全 Passed；给 ui_page_dc.c 的 .top_y 注入 +5 位移 →
**钩子 Failed** 并点名 `[dc] FAIL 与参考页不一致（1882 px 差异）`；还原后
git diff 干净、simulator/tests/ref 的 git status 为空——**全程未用 --update
刷基线**（那正是本钩子要防的行为）。
诚实记录瑕疵：首次实测在"连续注入/还原的紧邻重建"之间偶发失败一次，疑似
MSBuild 节点争用，此后 3 次连跑均绿。已把"单次失败先复跑、连续两次才当真、
不许直接 --no-verify 绕过"写进钩子注释。
## 文档同步
AGENTS.md 钩子数与文末索引 35→36 + 钩子清单补 ui-golden；
pre-commit使用说明.md 概览计数同步；报告 §6.5 U4 由 2/3 → **3/3**（这次是
"真进了自动门禁"，不是"脚本存在"）、§6.1 golden 行转 ✅、§0.1 缺口描述更新。
## W6 剩余
U2 合并两页记录、U5 落地目标页（须先对齐"目标页 vs 现存 7 个 ui_page_*.c"
的差集——报告的"27 页"是目标数而非现状数）。
|
2026-10-20 22:14:42 +08:00 |
|
|
wandering1
|
dafc18f5ed
|
feat(UI): W6 第一波——设计令牌层、页面注册表生成器与 UI 门禁补强
启动 docs/任务规划/README.md 的 W6 UI 扩展簇（用户裁定，覆盖 2026-10-11
的"本轮不排期"）。四个工作包，全部验证通过。
## U1 设计令牌层（零行为变化）
新建 Drivers/BSP/UI/ui_tokens.h（20 个宏），框架 + 7 个页面 + App/task/
ui_task.c 全部接入。屏幕几何**复用 ui_port.h 既有 UI_SCREEN_W/H**，不重复
定义；令牌头自身只 include ui_port.h，不把 LVGL 拖进全部消费者。
补收了报告没列但代码里真重复的量：UI_TEXT_BAND_H 15（7 次）、列表左右边界
与每页行数（各 4 个页面逐字复制）、推流协议几何与显示几何同源（此前硬编码
3200 且注释写着"须与 UI_FB_SIZE 一致"——典型漂移隐患）、UI_TASK_TICK_MS
（ui_port_step 与 osDelay 必须同值，原先靠注释维系）。
故意不收页面私有几何与"同形不同义"的值（device_info 的 pitch=15 与列表
UI_ROW_PITCH=14 合并即改像素）。
## U3 页面注册表与生成器（删手工分发）
ui_page_registry.{c,h} 由生成器产出，**手工 menu_content_page_for() 已删
除**（仓库内仅存 2 处历史说明注释）。密码页按代码实况**单独出口**
（ui_page_registry_password()）——它非节点绑定，任何 #P 叶子进同一页。
顺带落地此前判定"U1 阶段做不了"的共享 flat 样式 ui_style.{c,h}。
生成器除产注册表外**自动把新 .c 写进 uvprojx 与 CMakeLists.txt**，且
**双向对账**：加页打印 registered、删页打印 pruned，不留死条目；并双向
校验（#page 找不到实例报错、实例未被任何 #page 引用也报错）。
## U4 门禁补强（35 个钩子）
新增 font-charset 钩子（scripts/check_font_charset.py）：复用
tools/font_gen 的同一套提取与 cmap 解析规则（importlib 直载，零第二套
规则），A 段查源码在用 vs 字符集、B 段查字符集 vs 字体 cmap。
registration-check 补第 ④ 类：实测原规则对"进了两端构建但没接描述符表"
的页面**全绿**——desc 被链接器剥离、编译链接全过、菜单永远打不开的死代码。
仍照不出的两项已如实写进文档（枚举漏加归 @build、菜单树漏挂归 golden）。
## 字体子集瘦身（D 案，4 留 3 删）
ui_cn_chars.txt 122→119 字（恰删 上/电/重，零新增）。异/常/片/芯 进
KEEP_EXTRA 带理由白名单：它们曾在 9eb1bd63 被写进中文自检描述落盘
/log/selftest.log（定长 64B 记录跨固件持久），删字形会使历史故障记录
渲染空白且不可逆。保留字按**必需**处理，反向有牙——谁只跑 extract_cn
把它们静默洗掉，钩子直接 FAIL 并逐字打印理由。
--strict 口径为"未知冗余 = 0"而非"冗余 = 0"。
## 验证
@build 0 错 0 警；ER_IROM1 232,052 B（较 HEAD −228 B）、RW_IRAM1
75,232 B **零增量**、RW_CCM 87.9% 未变。golden：菜单 8 状态全像素一致 +
内容页 11 页逐字节一致，**参考图 sha256 差异 0 条**（未用 --update 刷
基线）；池水位菜单基线 5368 B、开页-关页往返 5448 B 与 U1 时相同。
38 个在途修改文件逐个核对 BOM/CRLF/U+FFFD 全部与 HEAD 一致。
L0 33 钩子 + L0.5 16 runner / 1104 断言全绿；check_doc_links --all
142 篇、无法判定 0；mem-budget / mem-numbers 已回填。
## 单位成本实测（U5 排期依据）
临时页 zzprobe 绑到"遥信量"叶子 → 只跑生成器 → 带页 @build 0/0 →
注册表出现 {5u, &ui_page_zzprobe_desc} → 回滚后 6 个产出文件 zzprobe
残留计数均 0、重编回基线。
**结论：新增一页 = 3 处人工（新 .c + 新 .h + 菜单树那一行加
#page=<名>）+ 1 条生成器命令，手工编辑注册文件 0 处。**
据此修正报告原口径"8 处降到 1 处"——那个 1 只在"1 处对既有文件的修改"
意义下成立，页面自身 2 个文件本就要写，真实处数是 3。
## 文档同步与两处自我修正
§0.1 UI 行 B → B+；§6.1「内容页」「设计令牌」两行按实况回填；§6.5 U1/U3
状态更新；§6 顶部加"建议栏不可照抄"总警示（本轮四次证伪：ui_port.h 已有
同名宏、LV_COLOR_BLACK/WHITE 不存在且极性反了、27 页实为目标页数现存 7
个、生成器草图漏密码页非节点绑定）。
两处改口：① §6.5 U4 从我上一版**误写的 3/3 改回 2/3**——"golden 脚本早已
存在"不等于"已进自动门禁"，两个 golden 脚本至今未挂 pre-commit，该缺口
单列为待办；② 原计划"分三笔提交"**作废**，U1 与 U3 改同一批文件、文件内
交叠，硬切会产生不可编译的中间态，故整波一笔。
|
2026-10-20 21:14:14 +08:00 |
|
|
wandering1
|
9d06798f2d
|
docs(规划): 删 §0.3 内存主线复述层，记录 W6 UI 簇启动与并行度约束
§0.3 第 1 条「内存这条线到此为止」是同日暂缓裁定的**复述层**，同一事实已有
三处单点详述（§0.4 内存两行、§5.3 暂缓横幅、登记簿 N-27 与内存管理两份文档
的横幅）。按「同一事实只在一处详述」删复述、留权威。§0.3 现只剩 UI 一条
主线；标题「两条主线建议」→「主线建议」，**编号不变**（任务规划 README §2
前言引用的是编号不是标题）。上一条变更记录里「内存簇暂缓 → §0.3 主线一」
这个去处自此失效，以本次新增行记载为准——变更记录本身是历史，不回改。
启动 W6：用户裁定**覆盖** 2026-10-11 的「本轮不排期」，按覆盖记录而非静默
改掉。已把 U1~U5 拆成 5 个工作包上共享任务板，第一波 U1 令牌层 ∥ U4 门禁
补强两名成员并行，写范围严格不相交。
并行度的真实约束已写进文档：不是任务数量，而是**注册文件**——新增一个 .c
必须同时改 uvprojx 与 CMakeLists.txt 这两个共享文件，同一工作树里两人同改
必然互相踩。所以 U3（原型化 + 生成器）是必须串行的地基段，U2/U5 排在它
后面；U5 的页面批量要等 U3 把注册自动化之后才谈得上并行。
修正两处失真：① 交付物清单里移植层单测还写着拟名 `test/host/dhara/` ❌
未建，实际落地为 `test/host/nand_port/`（149 断言、第 16 个 -unit-test
钩子）→ ✅；② 报告称「27 页未落地」实为**目标页数**，现存 `ui_page_*.c`
实测只有 7 个，已在 §6.5 注明 U5 开工前先对齐目标/已实现差集，不要照抄
报告数字。
check_doc_links --all：142 篇、无法判定 0。
|
2026-10-15 14:42:08 +08:00 |
|
|
wandering1
|
118ea4f005
|
docs(报告): 删除 §0.2「未闭环问题」小节
Top 2 修复销项后该节只剩指针与暂缓说明，而三条内容都已在别处单点详述：
未闭环清单 → §0.4；内存簇暂缓 → §0.3 主线一与 §5.3 暂缓横幅；Top 2 修复
证据 → 变更记录与文末「已销项条目的记录去处」。按 ../文档规范.md「同一
事实只在一处详述」删除，不留空壳。
§0.3 / §0.4 编号保持不变、不重排：../任务规划/README.md §2 前言正引用
本报告 §0.3，报告内部另有 §0.4 交叉引用，重排会全断（与本报告 2026-10-14
变更记录第 ⑤ 条「报告自有编号不回改、不重排」同一口径）。代价是 §0 下
现为 0.1 → 0.3 → 0.4 的空号，已在变更记录里写明理由。
文首「销项状态」行指针 §0.2 / §0.4 → §0.4；变更记录补一行删除说明。
check_doc_links --all：142 篇、无法判定 0。
|
2026-10-15 13:45:54 +08:00 |
|
|
wandering1
|
db16694a87
|
refactor(nand): dhara 几何字面量收单一真源 + 两条编译期守卫
CI / L0 静态门禁 (pre-commit) (push) Failing after 1m45s
CI / L0.5 主机侧单测 (MSVC) (push) Successful in 18s
上一笔提交 720f841 留下的待办，已登记在报告与 GD5F Trap Records 遗留 3。
ftl_page_in_range() 的越界上界 = num_blocks << log2_ppb，完全依赖 log2_ppb；
而这两个 log2_* 原本在 disk_initialize 里是裸字面量 11 / 6。将来换 128 页/块
的兼容片、只改了 GD5F_* 常量而忘了同步字面量，守卫会**静默算错**——偏大就是
越界守卫失效，正是它要防的那一类错误，且不报任何错。
收口方式比"加一条断言"更彻底：字面量收成 FTL_LOG2_PAGE_SIZE / FTL_LOG2_PPB
单一真源（disk_initialize 与守卫同取此宏，杜绝两处各写一遍再各自漂移），再加
两条负数组编译期守卫 FTL_PAGE_SIZE == (1 << FTL_LOG2_PAGE_SIZE) 与
GD5F_PAGES_PER_BLOCK == (1 << FTL_LOG2_PPB)。AC5 不支持 C11 _Static_assert，
负数组是本项目惯用法（同本目录 gd5f2gq5ue.h 的 N-26 DMA 契约守卫）。
验证：@build 0 错 0 警且**代码尺寸逐字节不变**（Code 213,540 / ER_IROM1
232,280 B / RW_IRAM1 75,232 B）→ 纯语义等价重构；主机侧移植层单测
149/149 PASSED。**守卫牙齿实测**：临时把 FTL_LOG2_PPB 改成 7 → 编译失败
（nand_ftl.c:70 error C2118 负下标），改回即恢复，证明它真会拦而不是摆设。
文档：GD5F Trap Records 遗留 3 由"待办"改为"同日已收口"并记收口方式；
nand_ftl.c 模块头修改记录补第 ④ 条。
|
2026-10-15 13:35:31 +08:00 |
|
|
wandering1
|
720f841494
|
fix(storage): dhara 移植层 is_free 整页精度 + HAL 越界守卫；日志读写批量化
登记簿 N-21（报告 N-12/N-13）与 N-24（报告 N-16）两项未闭环问题修复并销项。
N-12：dhara_nand_is_free() 旧实现只读页首 64 B 判全 0xFF，会把"页首
0xFF、后段有数据"的已编程页误判空闲，dhara 遂往已编程页再编程 = 位碰撞、
journal/map 指向垃圾且不报任何错。改整页扫描（栈上 64 B 分块、页首命中即
早退，故"已编程且页首有数据"的绝大多数页成本与旧实现同价）。
N-13：报告原建议经核对不成立——本仓裁剪版 dhara 既无 DHARA_NO_PAGE（哨兵
实为 DHARA_PAGE_NONE，journal.h:46）也无 DHARA_E_UNSUPPORTED（error.h 枚举
里没有，照抄直接编译失败），且 map.c 三处 dhara_journal_copy 调用点各自已
挡掉哨兵。真风险是移植层零上界校验：越界页号被芯片地址位截断成某个真实页
→ 静默读写错页。改为六个 HAL 入口统一几何上界守卫 + DHARA_E_CORRUPT_MAP。
错误码选择是刻意的：BAD_BLOCK 会让 journal.c:904 标坏无辜好块，RECOVER 会
让 map.c:275 启动回收；无错误通道的 is_free/is_bad/mark_bad 一律取保守值。
N-16 写侧：一次排空合并成"每文件一次 open/write/close"（≤8 条 = 512 B
静态缓冲）。掉电语义不变——批次仍在同一次 drain 调用内 close，而 close
回写目录项这个不同 LPN 会把 FTL 单页写回缓存逼出到 NAND；失败尾部回投
队列，条目不丢（旧实现 -2 卷忙会直接丢掉那一条）。容量轮转仍只在按条慢
路径做，批量路径发现装不下一批就返回 -3 退回。
N-16 读侧：s_read_raw() 加 8 条滑动读窗口 + 写者代数失效，API 与 UI 零改动。
验证：@build 0 错 0 警（Code 213,540 / ER_IROM1 232,280 B = 22.2%，
RW_IRAM1 75,232 B = 57.4%，ZI +1,640 B 全为静态缓冲、不吃任务栈）；
@test PASS，且台架 journal 恢复点与修复前同轨——连续四次启动 sectors used
恒 14,094、Map head 每轮 +128 单调推进、epoch 稳定 3 → 整页 is_free 未
改变恢复语义、无双编程、无回退；stack_report 9 个任务全 PASS（defaultTask
静态最坏链 3,024 B / 余 40%，实测峰值 2,164 B / 余 57%）。
新增主机侧移植层单测 test/host/nand_port/（第 16 个 -unit-test 钩子）：
RAM 假芯片 + 真实 dhara map/journal 源，149 断言，含"旧算法只看页首 64 B"
对照用例（将来有人把 is_free 改回去会立刻红）与 dhara 级 resume 双编程计数
为 0 的场景。L0.5 由 15 runner / 955 断言 → 16 runner / 1,104 断言。
文档：存储架构说明 §5.3 加移植层两条硬约束；运行与自检记录设计说明
§4.4/§4.5 写批量化与读窗口；GD5F Trap Records 新增 Trap 07（含三条遗留
代价与一条待办编译期断言）；登记簿 N-21/N-24 删行销项并同步 README
§1/§2.0/§2.1、排期详述 C3、报告 §0.1/§0.2/§0.4/§4.x/§7 与去处表；
钩子计数 33→34、主机侧单测 15→16 全库同步。
|
2026-10-15 12:34:39 +08:00 |
|
|
wandering1
|
8739faa7fe
|
docs: 裁定——内存优化簇整簇暂缓（R-2 后半 / R-3 / R-4 / R-6）
用户判定"把 LVGL 池与 UI 帧缓冲（现 ≈29.6 KB）搬进 CCM 作为后续
功能预算来源"这个决定不合适，内存优化的事先放一放。据此把这条
主线降级为暂缓，同时明确：不回退已落地的部分，不拆治理面。
报告（docs/问题记录/项目审查与优化建议报告.md）：
- §0.2 Top 3 → Top 2：R-2 剩余移出，表下加一条 ⏸ 说明
- §0.3 主线一由"把内存从卡死变富裕"改写为"这条线到此为止"
- §0.4 两条内存条目 🟡/❌ → ⏸ 暂缓
- §5.1 结论段与 §5.2 诊断补"不代表现在要动"
- §5.3 加暂缓横幅：三条理由（没有功能等这块预算 / 搬迁有风险和
工时 / 收益与代价不对称）+ 保留常开的治理面 + 三条重开条件
- §5.3 表内 R-2 / R-3 / R-4 / R-6 优先级一律 ~~P1/P2~~ → ⏸ 暂缓
- §7 路线图 W3 划掉标暂缓，映射行改为"暂缓期间无验收动作"
- 去处表 R-9 行注明"该簇其余部分已暂缓"；变更记录加一条
任务规划：登记簿 N-27 波次 W3 → 暂缓，并写清代价——CCM 只剩
7,904 B、FreeRTOS 堆实测 min_ever 8,464 B，**加任务 / 抬栈 / 加堆
会先在这里撞墙**，届时 mem-budget 会先报警，那就是重开信号。
README §1 结构/健壮性 7 → 6、暂缓块 1 簇 → 2 簇、§2.0 第 3 条
订正（顺带修掉旧值 ≈8,160 B → 实测 7,904 B）、W3 行与 §2.1 链路
图标暂缓、§3 暂缓规则推广到"只在原处标注"的簇。**W3 槽位保留
不重编号**，避免全库改 W4~W7 引用。
内存管理三篇：RAM预算台账 §2 把 UI 超配额改判为"已知长期挂账"
（R-2 暂缓后这条 ⚠ 会一直挂着，别每轮当新问题追）、§3 解锁链标
暂缓并去掉"← 现在卡在这一步"；RAM使用分析 §4 加实施状态横幅
（测量与长效机制常开 / 已落地不回退 / 1.2、1.3、2.2、2.3 与 8KB
试探暂缓）、§5 加"别拿目标列当现状"、§6 S5 补 ✅ 2026-10-15、
S6/S7/S8 改暂缓、S9 台账门禁补 ✅、1.5 里"缓冲已迁 CCM"订正为
"实际仍在 SRAM1"；存储栈RAM优化调研加同款横幅（P0-2 / P1-5 /
第三步）。
校验：check_doc_links --all 通过（142 文档、无法判定 0）；
check_mem_numbers 与 .map 一致；6 个文件无 BOM/CRLF/U+FFFD。
纯文档改动，不涉及代码与构建，故未跑 @build / @test。
|
2026-10-15 10:27:02 +08:00 |
|
|
wandering1
|
ff9fcbd43c
|
docs(报告): 补漏——§0.1 六维评分与口径/附录数字追平 R-9 后状态
用户指出 §0.1「内存使用」行仍写"LVGL 池 + UI 两份缓冲 54,146 B
仍在 SRAM1，而 CCM 只剩 7,904 B → R-2 后半被堵死，须先 R-9"。
上一条 R-9 提交只改了 §0.2/§0.3/§0.4/§5.x，漏了 §0.1、§1 术语表、
§3.1 体量表与附录 A 证据表。全库重扫后修这些：
- §0.1 内存使用：SRAM1 74.9% → **56.1%（余 57,504 B）**，瓶颈收敛
到 CCM 单点（87.9%、只剩 7,904 B），待迁体量 29,570 B，只差
"缩堆"一步；评级 B → **B+**（SRAM1 由卡点变富裕、治理三件套与
观测齐备；扣分项换成 CCM 单点 + MicroLIB C 堆无机械检查）
- §0.1 Flash、§1 术语表、§6.4：231,036 → **231,084**
- §1 术语表：`ROM = 231,324 B` 是**算术错**，Code+RO+RW 实为
**232,196 B**（§5.1 早前已修，这处漏了）
- §1 术语表 RAM 占用定义：98,144 / 74.9% → **73,568 / 56.1%**
- 附录 A 证据行：改 `RW_IRAM1 Size: 0x00011f60`、余 57,504 B
- §0.1 与 §3.1：工程文档 88 篇 / 31,416 行 → **87 篇 / 30,781 行**、
受控文件 2,466 / 79.3 MB → **2,465 / 79.2 MB**（随 506eccc 删除
错误码传播审计.md，−1 篇 / −635 行）；同表 docs/ **56.9 MB** 与
手册图片 **703 张 / 36.3 MB** 实测未变，保留
- §0.1 / §0.2 / §0.4 与附录的复核日期统一标 2026-10-15
- 最近复核行的 HEAD 改指 a7f5265，并注明"后续文档与模拟器侧提交
不影响固件"，避免每提交一次就再次过期
未改一处：§3.1"全部 Markdown 只有 5.4 MB"——本次复算得 5.8 MB /
192 篇，但原计数规则无法复现，差异也远超一次删除的量级，不猜着改，
留给下次复核定口径。
校验：check_doc_links --all 通过（142 文档、章节引用无法判定 0）；
check_mem_numbers 与 .map 一致；无 BOM / CRLF / U+FFFD。
|
2026-10-15 10:14:34 +08:00 |
|
|
wandering1
|
172b3f4a20
|
fix(sim): UI 回归改为自洽运行——修 netcfg_save 假失败
现象：check_content_pages.py 只有 netcfg_save 一页 FAIL（保存行值列
显示 ERR 而非 OK），其余 10 页像素与两处往返池水位全过。
真因不是代码回归：模拟器按**当前工作目录**读写 sim_config.ini，而
--cfgtest 的 E-01 场景 2 会伪造一份 4000 B 纯注释"雷"文件、并断言
"拒写后原文件不动"（size == 4000）——连正常通过路径也不删除它。
实测仓库根那份是 2026-10-11 08:37 留下的。之后每次运行都会加载它
→ 外科式保存要在 4000 B 注释后补写受管段 → 输出必超
CFG_FILE_MAX_LEN → 引擎按设计拒写 → 保存行显示 ERR，与"工厂默认
态"的黄金参考对不上。引擎行为是对的，错在自检留雷 + 回归不自洽。
修三处：
- simulator/main.c：run_cfgtest 拆成 scenarios + 外壳，无论成败一律
cfg_store_remove 配置路径与临时路径，让配置回到"无文件 = 工厂默认"
- check_menu_rows.py / check_content_pages.py：以空临时目录当工作
目录跑 lvgl_sim（cwd=tmp），调用目录里的残留档不再影响结果
- check_content_pages.py：作废"删 sim_netcfg.bin 残留"的旧兼容清理
（旧档迁移 2026-10-10 已删），改为只提示、不删别人的档
验证：--cfgtest PASS 且跑完不再留下 sim_config.ini；
check_menu_rows.py PASS（8 状态 + 池基线 5,368 B）；
check_content_pages.py "PASS: 11 内容页 + 往返池水位全部通过"，
往返 5,448 B。**未刷任何黄金参考**——参考本来就是对的。顺带删掉
本地两份 4000 B 残留（仓库根与 build/Debug，均 gitignore 产物）。
未跑 @build：本次只改 simulator/ 侧代码，固件工程无涉及；模拟器
CMake 构建 0 错 0 警，cppcheck 钩子覆盖 simulator/main.c。
文档：UI_自动化测试流程 §五 加排查行 + 变更记录；simulator/README
§3.7 说明删除保证与原因；lvgl-simulator skill 同步；订正审查报告
R-9 那条把该差异误归给 cfg_file 改动的表述。
|
2026-10-15 10:05:37 +08:00 |
|
|
wandering1
|
0cece5a305
|
docs(编号规范): 新增 P-8 语义优先与语义标识规范（§3.3 / §5.7）
规划 / 待办类条目改以一行短语作标识，不再分配字母+数字号：
- §2 加 P-8「语义优先」，七条原则变八条
- §3 主轴由"两层编号"扩为 编号 / 语义标识 / 章节引用 三种形态
- 新增 §3.3 形态规则与适用分界：TC / TRAP / FR / NFR 等需机器
解析或作历史证词的仍保留编号，并强制带语义括注（P-7）
- 新增 §5.7 登记、冻结与别名规则：短语即标识，改措辞等于换 ID；
销项 = 删行 + 清全库引用，短语不复用
- §4.2 加修订说明，§9 加「0.5 语义标识」迁移阶段
起因：N-31 销项删行后按"现存最大值 +1"又被取走，与两处历史引用
撞号（见 docs/任务规划/README.md §0）。
注：本文件不是 R-9 会话所改，按"全部提交"一并入库。
|
2026-10-15 09:56:33 +08:00 |
|
|
wandering1
|
a7f526569a
|
perf(mem): R-9 落地——LVGL 池 40→16 KB，SRAM1 74.9%→56.1%
取值依据是实测水位，不是预估：菜单根框 5,368 B、开页-关页往返
5,448 B、最重页面峰值 6,568 B（占 16 KB 的 40%）、真机开机
used=3,192 B。注意 16,384 B 建池后 lv_mem_monitor 报的 total 是
15,020 B（TLSF 控制块与对齐元数据 ≈1,364 B），核算余量用后者。
两端 lv_conf.h 同步改值（lv-conf-sync 生效值比对 163 项 PASS），
Lib/lv_conf.h 的 UTF-8 BOM 已按原样补回（Edit 会静默剥掉）。
验证：
- @build 0 错 0 警；ZI 154,456 → 129,880，精确 −24,576 B
- SRAM1 98,144/74.9% → 73,568/56.1%（余 57,504 B）；CCM 不变 87.9%
- 模拟器菜单回归 PASS（8 状态像素 + 池基线 5,368 B 未变）；11 页
黄金参考逐字节 10/11 一致，往返池水位 5,448 B 分毫未变
- 唯一差异 netcfg_save 保存态：用 40 KB 旧池做 A/B 复测同样失败，
确认与本改动无关（属 506eccc 的 cfg_file 行为变化），未刷黄金
参考掩盖，留给该改动属主处置
- @test PASS：fw build Oct 15 2026 07:31:34，无 [ERR]/Fault，
开机 622 ms 到 net init: OK，menu build done: used=3192
- 本地 CI 全绿（L0 + L0.5，15 runner / 955 断言）
- 台账受管区与内存快照区已 --write 回填，mem-budget / mem-numbers
由红转绿
连带结论：R-2 后半待迁体量 54,146 → 29,570 B，瓶颈由 SRAM1 换到
CCM（只剩 7,904 B）；解锁链第 ① 步完成，下一步只差缩堆 56→32 KB
（B5 是反向扩容，缩回前须重跑 stack_report.py + 上板 min_ever）。
文档同步 20 处：本报告按修复即销项删除 R-9 行，并改写 §0.2/§0.3/
§0.4/§5.1/§5.2/§5.3/§6.4 与变更记录、去处表；RAM使用分析 §2.6.2
新增实测水位表、阶段 1.1 标已执行；台账 §3 解锁链、登记簿 N-27、
任务规划 README W3 行与链路图；UI 四篇、产品需求、内存内容分配
策略、运行与自检记录、项目部署环境要求、测试开发标准流程、
simulator/README、ui-verify skill 常量。顺带订正三处与脚本不符的
旧值：池水位常量 4784/4864 → 5368/5448、FreeRTOS 堆 48 → 56 KB。
|
2026-10-15 09:56:15 +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
|
803f7717ed
|
chore(skills): 纳入 template-skill 骨架（DSH 建 skill 的空白模板）
.dsh/skills/ 是入库的项目知识（.gitignore 用 `!.dsh/skills/` 显式放行），
此前该目录未被跟踪，现按同一口径纳入。
内容为 DSH 新建 skill 的空白骨架：description 仍是占位文案、正文未填。
后续要落地具体 skill 时直接改写本文件；确认不需要则删目录即可。
|
2026-10-14 23:22:26 +08:00 |
|
|
wandering1
|
617c84f570
|
docs: 文档去阶段化——清理"自愈收敛阶段 / L3 pending / 一期二期"标签
CI / L0 静态门禁 (pre-commit) (push) Failing after 2m11s
CI / L0.5 主机侧单测 (MSVC) (push) Successful in 17s
代码注释去阶段化已在 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
|
1e568b8549
|
merge: task/ARCHDOCS-sync-20261014 合入 v2-on-ui
任务 ARCHDOCS（2 个提交）经 task-worktree 回收：
- refactor(NET): 源码注释去阶段化 + 网络两份文档重构 + 不稳根因图更新
- docs(架构): 全景/启动顺序/存储/引用图与 README 同步任务面与 NET 内部模块
备注：架构设计文档+README 同步现状（补登记：任务先以 task-arch-docs-sync 手工分支完成，现按 task-worktree 规...
|
2026-10-14 22:52:40 +08:00 |
|
|
wandering1
|
d770e36c7c
|
refactor(NET): 源码注释去阶段化 + 网络两份文档重构 + 不稳根因图更新
- 源码注释：删去自愈收敛阶段
1/1.5/3等 scaffolding 称谓，改为语义引用
（E-02 收口 / F-NET-2/3/4 / docs/网络/网络自愈架构设计.md §5.2 E13）；
涉及 net_socket/.h、net_events、net_listener、net_pending、net_types、
net_config、ch395f、time_sync、iec104_serv、ui_net_sink、lftpd、
simulator/sim/net_socket_sim、board/host 测试与探针
- 文档重构：网络自愈架构设计.md 与 Net层阻塞模型架构设计.md 改为现状口径
（删历史节与阶段叙事），NET/README.md、docs/README.md 同步
- 工具与配图：gen_net_instability_svg.py 与
docs/images/网络不稳根因总览.svg 随源码口径一并更新
- 门禁：@build 0 错误 0 警告
|
2026-10-14 22:05:53 +08:00 |
|
|
wandering1
|
cea2b51efb
|
docs(架构): 全景/启动顺序/存储/引用图与 README 同步任务面与 NET 内部模块
- 项目架构总览 v1.1：§1.1 去重复⑥行、硬件行 UART4/TIM3/ADC1；§2.1
任务表 6→9 行且栈值按 freertos.c 校准；§3 补采集算法链与 TIM3 节拍；
§5 补 net_events/net_listener/net_pending 与 iec104_serv，单客户端
恢复窗更正为实测 p50 208ms；§7 目录树、§9 索引、§10 变更记录同步
- 项目启动顺序管理：任务表 5→10 行；启动轨迹表 8→14 行（fw build、
ADC input layer、phasor/freq/protection、SD2506 明细、TIM3 启动）
- 存储架构说明：§1 初始化顺序块重写（gd5f 归位 app_main_init 内、
rs485Task 未创建、补 TIM3 与 L1~L3 链）
- 引用关系图说明 §7 统计与产物重跑刷新；就绪屏障 SVG 补 iec104Task
消费者后重生成（1400x912）
- README：外设引脚纠错（RS485=UART4/PC10/PC11/PA15、TPAFE 控制脚
PC8/PC9/PC7）、启动流程补 sys_clock/adc_input/TIM3、任务表重生成
（9 任务）、目录树与 NET 小节同步、ftp_speed_test→regression/
integrity、文档表补四条专项索引
- 工具：gen_task_table.py 补 iec104Task/protectTask 职责；
gen_barrier_svg.py 补 iec104Task 消费者与 bit0 计数
|
2026-10-14 19:07:48 +08:00 |
|
|
wandering1
|
4f8e298394
|
chore(gitignore): .dsh 会话草稿不入库，skills 照常跟踪
现象：每轮 agent 会话在 .dsh/ 根目录留下草稿（提交信息草稿、门禁输出、台架
日志、一次性改名脚本、故障注入 patch），全部以 ?? 挂在 git status 里，混在
真改动中间。本次清掉 17 个：196 KB 门禁输出、台架日志、3 份提交信息草稿、
4 个注入 patch、2 个已合并实现的过程 diff、1 个一次性改名脚本。
规则：`.dsh/*` 忽略 + `!.dsh/skills/` 放行 —— skills 是**入库的项目知识**
（子域方法论），30 个已跟踪文件不受影响。
判据写进注释而非只写"忽略草稿"，命中任一就不值得留：
① 能重跑的（门禁输出、日志）；
② 内容已在 git 历史里的（已合并实现的过程 diff —— 如 T0/T1 E17 与
sock_reset，主干已有 ch395f_sock_reset_begin/poll）；
③ 离开已丢弃的任务分支就跑不通的（依赖 NET_FAULT_INJECT 的注入产物）。
第 ③ 条是关键：这类东西提交进去是"看着有证据、实际不可复现"的**假证据**，
比没有更坏；方法应沉淀成文档文字 —— docs/网络/网络自愈架构设计.md §5.2
E18/E19 已完整记录注入点、触发方式、判据与实测结果，patch 不是唯一载体。
与 MDK-ARM/retracted_bench_20260922 归档先例的区别（避免下次误套）：那次
归档的 probe_*.py 独立可运行，归档理由是"判据是错的，但要立牌警示后人别
再用"。归档的前提是**还能跑、结论错**，不是"根本跑不起来"。
验证：git check-ignore 双向确认（草稿命中 .dsh/*、skills 路径不被忽略）；
删除前逐个 git ls-files --error-unmatch 确认未跟踪，**未用 git clean**（会
误伤 skills 下可能存在的未跟踪文件）；skills 跟踪数 30 不变；.gitignore 无
BOM / 无 U+FFFD / 无 CR。
|
2026-10-14 18:25:23 +08:00 |
|