wandering1/STM32F4-Base
1
0
Fork 0
Code Issues 29 Pull Requests 1 Actions Packages Projects 2 Releases Wiki Activity
876 Commits 4 Branches 0 Tags
3cce00a7cb945fe25dce9bea15280b7b26cff088
Commit Graph

74 Commits

Author SHA1 Message Date
wandering1 4a4ad6bc5f chore(全仓): @build/@test 旧文档别名清退为技能调用名 
现状口径：/keil-build 与 /serial-boot-test 是 DSH 会话的技能调用名，
不是 shell 命令；「名 + 命令行参数」的命令形态改为可执行体
run_boot_test.py 的真实调用。

- AGENTS.md：别名说明重写为「技能调用名不是 shell 命令」，两条目改
  「编译（/keil-build）」「串口回归（/serial-boot-test）」
- keil-build / serial-boot-test 两 skill 调用名与示例同步；task-worktree
  方案文档去掉 @build/@test 惯例从句；@task 保留（不在点名范围）
- 123 文件现状陈述全改；台架捕获、变更记录/时间线、rename 映射输入
  等 41 行历史证据保留旧名
- gen_memory_svg.py 6 处措辞随改，3 张 SVG 产物同批重跑
- 顺手补并行方案同行漏网计数 51→52 钩子

验证：提交期快钩子对 123 文件实跑全 Passed；check_doc_links --all
rc=0（3038 处、无法判定 0）；check_mermaid --all rc=0；YAML 解析 52
钩子不变；skill-size rc=0；py_compile 全过；字节卫生零漂移。
 2026-10-30 13:03:12 +08:00
wandering1 6ffbb7d5b5 docs(测试说明): 交流动态验证轮次加四张导读图（两 SVG 生成器 + 两 Mermaid） 
§8 开头插「六轮速查卡」：3x2 面板，每轮注入信号缩略图数据驱动
（正弦 / 同峰值方波三角 / UA·UN 异相 / 扫频 / 负半周钉 0 / 谐波叠
加），一卡给接法、判据一句话、主读数出口，先立轮廓再进执行卡。

§8.5 插「为什么连取 10 行取中位数」概念图：左栏机理（定宽 20 拍
窗逐窗滑动 → 读数拍频跳），右栏操作（中位数 / 平均 / 真值三线
错位对照 + 毛刺行标注）——取数口径 4e4d597e 刚定，此图补原理。

§8.3 / §8.5 各加一张 Mermaid：接线拓扑（端接高阻、万用表并接、
单点共地、STM32 五路仅削顶轮支线）；单轮执行主干（采集链与偏差
两级决策、分诊虚线回环，汇于关输出填表）。

新增生成器 gen_ac_rounds_svg.py / gen_ac_median_svg.py（纯标准库、
OVERFLOW 预检归零、generated-fresh 自动在册），README 补两行台账。

验证：两产物连跑两次 sha1 不变；check_generated_fresh rc=0 无
DIFF / NEW、漂移基线不增；mermaid-syntax 2 围栏新发 0；headless
Chrome 截图回读三轮，修掉两类只有渲染才暴露的真错（正文 x 在卡
循环外算导致第 2、3 列叠进第 1 列；三角波闭式值域 −2..4 画越界
尖峰）。六文件 BOM / CR / U+FFFD 均零。

注：当前 check_doc_links --all 报 27 处，全属并发会话在改的产品
需求三份文档，与本笔无关、未触碰。
 2026-10-30 12:21:02 +08:00
wandering1 f754d59218 docs(测试说明): 按用途分六个子目录并同步全库引用 
分层：流程与规范/ 单元测试/ 板级测试/ 专项验证/ 测试工具/ 测试数据/，
顶层只留新增的目录导航 README.md（归层判据 + 硬约束 + 本次处置记录）。

- 搬迁 28 个路径：测试数据三个目录 58 个文件为纯改名（R100，内容逐字节不变）
- 全库引用同步 124 个文件：AGENTS / docs 索引 / skills / 门禁注释 / scripts
- 门禁面：scripts/check_test_traceability.py 的 glob 改 rglob
  （分层后不递归扫描＝追溯门禁直接瞎掉）
- scripts/rename_ref.py：收尾的 ℹ 提示在 GBK 代码页抛 UnicodeEncodeError，
  让进程以退出码 1 收场而改写其实已落盘（RC 与真实结果相反）；改为把
  stdout/stderr reconfigure 成 UTF-8，与 check_doc_links.py 等同法
- docs/文档规范.md §1.1 补「子目录文件过多时再分一层」；§3.6 补 rename_ref
  搬整目录的两个实测坑：① 会改写目录内部文件的内容 ② 内部文件的 ../ 出链
  不补层级（本次 23 个被误改的证据文件已按 HEAD 原始字节逐字节还原）
- docs/README.md §6 改为与六个子目录一一对应，并补登原先漏登记的
  「启动日志原子性复验流程」一行
- .cubemx_survival_baseline.json：App/util/task_watchdog.c 的注释路径也随分层更新，
  该文件是存活审计的 watchdog-module 漂移锚点，按脚本自己的提示跑 --write 重建基线
  （实测重建后仅 watchdog-module 一条哈希变化）
- 铁律 4 例外（本次在任务树里改了单写者文件）：AGENTS.md 与
  .pre-commit-config.yaml 只被 rename_ref 改写路径字面量（后者全在注释行），
  任务表块与钩子声明一字未动

验证：check_doc_links.py --sections-strict 覆盖全部 88 个改动 .md 全绿；
check_test_traceability.py 输出与主树逐行一致；196 个文本文件无 BOM、无新增
CR、无 U+FFFD、无行尾空白；陈旧引用面由主树 25 处降到 6 处（无新增断链）。
 2026-10-30 07:16:07 +08:00
wandering1 fea4cc7502 docs(架构): 项目架构总览全局更新——同步录波/SOE/屏板并订正串口归属 
v1.1（2026-10-14）之后主干前进 59 笔，本总览积累系统性偏差，通读全文后
全局更新（含配图生成器数据同步）：

- 串口三分定态：USART1=屏板链路 700 kbaud、UART4=RS-485（B2 未接线）、
  UART5=控制台日志 115200（console_log CON_UART=huart5 实证；
  旧文把 USART1 标成调试口是屏板批 0 迁移前的口径）
- 采集主线补齐：adc_cal 标定折算、meas 200ms 遥测快照（adcTask 唯一
  发布者，104 与 UI 共用同一份上游）、录波环三任务交接（adcTask 写入
  冻结 / defaultTask 游标落 /wave / uiTask 单通道回放 / FTP 取回）
- SOE 事件记录链路入图：protectTask 动作/复归边沿投递（纯 RAM 队列）
  → defaultTask 经 syslog_drain 尾部落 /log/soe.log（64B 定长）
- 配置从 [network] 单段改五段注册制（+ftp/adc_cal/run_par/comm），
  另有 /prot_set.bin（B7 原子写）
- UI 一节按注册表驱动重写：菜单树 61 行、16 个 #P 受保护叶、26 个
  #page 绑定、ui_data 三帧契约（写侧唯一填充 ui_data_feed）、录波
  两页、显存一份三出（屏板主出口/:7003 镜像/模拟器）
- §2.1 任务表按 freertos.c 现值逐行核对；protectTask 如实标注
  「未标定闭锁」现状（产品 required_mask 0x1F7）
- 配图：gen_arch_svg.py 顶部数据（层芯片/串口/删悬空图脚注）重跑，
  脚本与产物同一笔提交；check_generated_fresh.py 按「只减不增、
  还清即删整条」把本次还清的 项目架构总览.svg 基线下架（留出处注）

验证：check_doc_links --all --sections-strict 通过；scripts/ci_local.py
全绿；generated-fresh 单跑 rc=0（无 DIFF/NEW）；SVG 无头渲染回读目检
两轮（首轮揪出悬空图脚注）；md 无 BOM/CR/U+FFFD；#P 计数剔注释行复核。
 2026-10-30 06:53:07 +08:00
wandering1 b49e226815 docs(配图): 菜单树总览改由生成器画，登记钩子扫不到的图 
- 新增 tools/arch_diagram/gen_menu_tree_svg.py → docs/images/菜单树总览
  .svg：43 节点 = 9 菜单 + 34 叶，30 已绑页 / 4 未绑 / 16 叶带密码门，
  最深 4 级；读数由脚本现算，不在文档里另抄一份
- 生成器内嵌 NODE_SRC（= ui_menu_tree.txt 的 43 行节点）：在仓库里跑会
  与真值逐行互验、不一致 exit 1；generated-fresh 在临时目录重跑读不到
  真值 → 用内嵌表，输出逐字节一致（实测临时目录产物同 sha256）
- 产品需求 §8.2 原先挂的是级联框显示几何图（画的是示例级联，从来不含
  整棵树的节点），换成这张树图，并删掉「该图仍是 42 节点时代所画」的
  补丁注
- 图形绘制流程新增 §2.1：登记 generated-fresh 扫不到的四张图 —— 两张
  tools/refgraph 产物（引用关系图 / _模块，不在 gen_*.py 命名面里）+
  两张手画稿（级联框总览、级联框几何计算）。钩子只扫
  tools/arch_diagram/gen_*.py，这些图改了不会有人报警；再多一张先说清
  为什么不能用生成器
- arch_diagram README 脚本一览加行
 2026-10-30 00:25:03 +08:00
wandering1 15bcfc7c92 merge: task/wave-record 合入 v2-on-ui（故障录波数据面与单通道回放页） 
冲突两处与处置
- docs/子系统设计/故障录波设计说明.md §5.2：上游把这张表交给格式化器重排，多出一列
  空列，并把「FA_WRITE 竖线 FA_OPEN_APPEND」里的竖线当成分隔符打断，标志位写法已损坏。
  取我方四条陷阱版（含实现期复核新增的第四条：搬段途中环被解冻甚至已换段 → 关档后
  复检环侧身份判废），并把标志位里的竖线转义（与 运行与自检记录设计说明.md 同一写法）。
  上游在表后新增的「取窗竞态的原因」配图不是本任务内容，原样保留未删。
- scripts/size_attestation.json：不手工拼接，改为合并后在主树重新构建再重盖凭证。

顺手修一处上一轮我引入的排版断行
- docs/任务规划/数据可信.md §4.6.5「跨转换器相位」那一行少一个分隔符，三列表渲染成
  两列；同时把引用从 §7 精确回 §7.1（链路分段）。合并面 68 个文档、46 张表逐张核对
  列数一致，命中 0。

合并态权威构建（主树，本次凭证的来源）
- 0 错误 0 警告；Code=243,552 / RO=28,784 / RW=1,972 / ZI=145,388；RW_IRAM1 89,936 B
  （68.6%）/ RW_CCM 57,376 B（87.9%）——与任务树逐项相同：上游自 merge-base 起对代码
  只改了 sample_ring 的注释与函数头，故台账数字无需重排，仅重盖同码凭证。
- 上游 14 个提交带来的门禁与技能改造（skill-size 钩子、五个技能正文外置）与本波正交，
  真重叠只有 docs/门禁说明/README.md 与 docs/测试说明/主机单测覆盖率口径.md 两处，
  按 hunk 距离自动并上，已逐项核对。

状态与后续
- 台架三条判据（注 1 V/50 Hz 对表、FTP 拉回比对、与 meas 及 104 同表读数）按用户裁定
  保持未完成，卡片不销项；本笔交付的是软件闭环。
- 全仓计数清扫（主机单测 41 → 44 套、无专属钩子 19 → 22 套、黄金 60 → 66 张、提交
  钩子数口径、两处钩子显示名）另开一笔，不与本笔混编。
- docs/任务规划/** 本应在主工作树改，本波由用户在任务树显式豁免、随本笔合回。
 2026-10-29 19:32:26 +08:00
wandering1 d64bbdc57f feat(wave): 故障录波数据面、接线与单通道回放页（软件闭环交付） 
数据面（App/algo，纯逻辑，双端编译）
- wave_ring：8 路 × 320 点列优先环（1 kHz，预触发 160 + 后触发 160），adcTask
  唯一写者；触发/冻结/封存/冷却四态，冻结持续到落盘回执才解冻，滞留 2 s 自弃
  兜底——下一次真故障无波可录比丢一段更贵
- wave_store：段头编解码 + 拉模式打包游标 + 自带无表位运算 CRC-16/MODBUS（带
  锚点自检）+ 段名与整段长度等式；格式不依赖平台类型宽度
- 段头只存原始码值与封存瞬间生效系数，工程量只当单位标签、不进任何算式
- 三套主机单测（环 113 / 编解码 170 / 触发状态机 110），全部无桩、生产源原样
  纳入；新文件补 stddef 是 ARMCC 与主机差异，主机侧照不出这条分叉
- test/host/wave_read.py 是按 §6.2 的独立第二实现（dump/fft/shape/plot），92 条
  自洽断言；三份合成段互读双校验全过、哈希钉死，格式面双向闭合
- 三套新单测不加专属钩子，由覆盖率总闸全量真跑（沿用既有裁定）

接线（任务层）
- adc_cal：新增生效系数的 32 位定点原值入口（与既有浮点入口共用生效视图），
  段头按最低有效位精确记账，不经浮点回算
- adcTask：每拍压 8 路语义原始码值并推进状态机，封存那一拍同拍交棒封存瞬间事实；
  台架定周期自抓走双层编译门，产品镜像里零存在；串口新增一条 wave: 周期行
- defaultTask：卷空闲后一次心跳整段搬完（try 锁 + 256 字节分片 + 一次完整开档到
  关档），成败都回执；失败先删半成品再计错，段号只在成功时推进；持锁超 50 ms
  补一条告警并记历史峰值（喂狗余量可核）
- Lead 复核补第四道并发陷阱：采集任务优先级高于落盘道，搬段中途它可能正好把滞留
  超时的本段自弃、甚至封出下一段——数据区校验和是对「实际读到的字节」算的，
  半新半旧的段照样自洽，故关档后复检环侧身份判废：删文件、不补账、段号不推进
- Lead 复核抓到触发挂号不是原子操作（旧实现分三个字节写，消费者可在窗口里读到
  上一段的触发源与元件号）：已把载荷压进一个字节，越界当场拒且不记任何计数；
  段文件字节布局零改动，三份合成段哈希逐字节不变
- protectTask：保护启动上升沿同点请求录波，一拍一次、元件号取最低位；判据本体
  零改动

人机（160×160 单色屏）
- 菜单树节点 26「手动录波」绑页面 + 记录查询组末新增「录波回放」叶，重跑生成器
  得 43 节点 / 34 叶 / 30 已绑，页面映射 28 → 30
- 回放页一屏一路、触发点前后各一周波共 40 点、每点 3 像素阶梯线（只用水平与
  垂直两种线段——单色屏斜线会被阈值裁掉）；零点虚线、触发光标、窗口峰值、
  单位徽标与形状受限徽标；空态与坏段各一句显式文案，绝不用半截波形冒充数据
- ui_data 新增录波注入通道（六件操作表、三态返回）；执行侧胶水带段头缓存、
  手动请求后连缓存一起作废、逐点走全仓唯一的码值换算入口
- 模拟器接真实环与编解码合成两段（含坏段与空态旗标），6 张新黄金参考，既有
  60 张逐字节零漂移未用更新模式；字库 218 → 224 字 / 319 字形
- 两份图形配置里图表组件仍为关；零堆分配；页面池水位不变
- 回放读路径的 uiTask 阻塞上界按实码写清：一次渲染 = 段表刷新 + 未缓存段头最坏
  22 次小读；已验段只剩一次开窗读 + 40 点解码；无实测数不编，实测归台架、
  仪器用已在跑的单轮工作耗时探针，不新加埋点

台账与文档
- 内存台账：录波环与落盘/回放静态逐条入册，三档对照 81,536 → 88,296 → 89,936
  字节（62.2% → 68.6%），累计 +8,400；预估 5.9 KB 与实测 +6,760 的差额点名；
  散列文件头注释同步；任务栈表核对后无需抬栈；体积趋势行与同码凭证由权威构建
  重打（0 错误 0 警告，四项体积与上一轮相同——本轮改动只有注释与声明位置）
- 设计说明：§5 补第四条并发陷阱；§6.3 定字段口径（两份独立实现的共同依据）；
  §7 回填实测；§9 周期行写实；§10 台架判据改两段式且不比绝对相位；§12 补读路径
  风险行；抬头状态改成「代码面已交付、未做完的只有板级那一轮」
- 卡片：软件闭环一栏列证据；台架三条按用户裁定保持未完成，不做虚假销项
- 口径同步：数据可信、UI 补齐、页面补齐规划、产品需求、采集短板评测、任务规划
  索引与两份 README；陈旧现状句清扫 16 处（带日期戳的历史取数行一律不动）
- 门禁说明：nested-comment 记仓库根探测必须兼容 linked worktree 的 gitdir 文件
  形态（修前该钩子在任务树里恒报环境错、静默不可用）；coding-standard 记
  「函数头注释超过 24 行就把函数功能挤出回看窗口」这条机制与本次现场
- 覆盖率基线登记两个新覆盖模块（套件 41 → 44 套）；环单测重打后该文件有效行
  227 → 226、覆盖行 226 → 225，比率仍 99.6%，是分母变小不是覆盖率回退

为什么是单一提交：文档链接、双端注册、生成器幂等（菜单与字库）、内存数字与
体积事实源、编号门禁这五道整仓门禁要求代码、页面、菜单树、字库、文档与台账
同处一个提交才自洽，按数据面/接线/人机/台账拆成四笔必然红其中至少四道

编号门禁新增行 14 处命中已按语义改写：魔数常量按字符命名、段名样例改由格式串
生成、频谱表头改 f / 2x / 5x 并加一行图例；改写后自洽断言 92 条仍全过
 2026-10-29 19:23:15 +08:00
wandering1 e71d623e60 docs(algo): 5.3 节补窗首下标的圆周图（三种写法对照） 
- 新增配图 采样环缓冲_窗首下标.svg：左侧 40 格圆环走一遍 head = 5、n = 20
  的「往回退 19 步」（跨过 0 与 39），右侧把直接减 / 16 位回绕后再取模 /
  先加 DEPTH 三种写法的结果并列，只有第三种落在 25。
- 与 5.2 的环形布局图分工：那张讲「窗在哪几格」，这张讲「下标怎么算出来」，
  不重复同一张图的语义。
- 生成器 gen_sample_ring_start_svg.py 顺带把 OVERFLOW 明细改到末尾统一打印
  （原先只在开头打，折行类告警只报计数、看不出是哪一条）。
- 门禁：doc-links --sections-strict 通过；id-check 新增行无未登记编号；
  generated-fresh 22 个生成器 17 一致、0 新漂移；产物连跑两次 sha1 不变。
 2026-10-29 17:28:48 +08:00
wandering1 c377fc8c15 docs(algo): 采样环缓冲补「为什么需要/设计思想」两节与两张配图 
- 采集与算法层设计说明第 5 节由单段说明拆成 5.1~5.5：为什么需要这一层
  （三个缺口 + 两个被否决的替代方案）、设计思想（五条不变量）、环内布局
  与 start 推导、API 契约、要点与禁令。
- 新增两张配图（生成器 + 产物同批提交）：
  采样环缓冲_为什么需要.svg —— 上游 1 kHz 覆盖写只交最新一帧 vs 下游
  20 点滑窗，缺口 19 点，以及三个消费者必须同源；
  采样环缓冲_环形布局.svg —— 40 格环里哪 20 格是本窗、写指针指「下一格」、
  回绕方向与三条设计不变量。
- 5.5 补一条「读者与写者必须同任务」，与故障录波设计说明的取窗竞态口径一致。
- 门禁：doc-links --sections-strict 通过（28 处章节引用全部可判定）；
  id-check 新增行无未登记编号；generated-fresh 21 个生成器 16 一致、0 新漂移。
 2026-10-29 17:15:48 +08:00
wandering1 d0e73d6553 docs: 录波立项波及的口径同步（索引、登记簿、需求与 UI 状态行） 
任务规划 README 顺序表：录波从「当前不排」移到独立行；动态波形验证让位给录波
数据面（段文件是现成的样本出口）。
登记簿：录波与 104 文件传输拆成两行，前者解除暂缓并指向新文档。
产品需求：立项未排行、录波文件存储行、文件传输行、录波采样率行补偏离登记指针。
UI：页面补齐规划第 26 叶与 UI补齐「不做」表改指故障录波立项，旧重开条件已满足。
短板评测记录链行、ADC前端注入验证流程的读数出口注、图形绘制流程与
tools/arch_diagram/README 的生成器清单同步。
 2026-10-29 13:19:12 +08:00
wandering1 b46e44d92c docs(采集可信): 数据可信文档台阶化重构并立项故障录波 
两份工作互锁（互相引用），故同一笔提交。

数据可信：全文按「五级台阶」重排（§1 全局 → §2 信度现状 → §3 M4 退出判据逐条 →
§4 设计约束 → §5 任务卡 → §6 顺序 → §7 决策 → §8 风险 → §9 边界 → §10 关系）。
恢复 §2.2 量纲错配（该节此前被瘦身删掉，test/host/prot_dim 的两处引用一直悬空）；
新增 §2.7 与 §4.6：ADC 只验过直流静态标定，正弦动态波形一次也没采过——用信号发生
器在既有注入点注 ±2 V 以内的正弦即可验全周傅氏、测频、快照与削顶路由，不必往端子
加压、也不需要标准源。§6 手绘框图改 Mermaid。章节编号未重排：§2 / §4 / §7 / §10 被
App 与 test 的头注释当规范引用。

故障录波：用户裁定 2026-10-29 录波先行，三条口径——1 kHz（每周波 20 点）、8 路
电气量全录、一屏只画一路共 8 路可切换。新增设计说明（与产品需求 80 点/周波口径的
偏离显式登记；存原始码值而非工程量，绕开未标定闭锁与测频幅值门；四个所有者的跨
任务边界与三条并发陷阱；段文件字节布局；单通道回放显示契约；约 5.9 KB 静态增量
触发 R6）与卡片登记簿（数据面最小闭环 → 手动与保护启动触发 → 现场单通道回放页，
二期的 4 kHz、突变量启动、COMTRADE、104 文件传输不返工的结构约束写进设计文档）。

两张旧配图与一张新配图改由 tools/arch_diagram/ 的生成器产出，脚本与产物同笔提交。
代码一行未动：本波只交付文档与设计。
 2026-10-29 13:18:28 +08:00
wandering1 21c68521ff feat(task-worktree): 桥接 DSH worktree 插件——补共享联接、锁归属 pw:<name>、修释放不掉 
诉求最初是升级 dsh-task-worktree：实测已装 0.4.6 = npm dist-tags.latest，无需升级；
真正的缺口是本仓 skill 看不见插件建的树（.dsh-worktrees/），故按用户追加指令把两套
系统接起来。回收方向刻意不打通：本 skill 永不删插件的树。

脚本 task_worktree.py：新增 plugin 子命令 list/adopt/unadopt，事实源是 git worktree
list（不是插件 manifest，免得被绕过）；adopt 只补缺失的 .venv 与 simulator/SDL2
联接，已有联接跳过、实体目录绝不碰；锁归属用 pw:<name> 前缀；new 顺带提示另有 N 棵
插件树、不占活跃上限 3。
一并修一处真 bug：lock release --bench-pass 在任务无台账时先 EnvError 退出、锁释放
不掉，导致每个任务的 done 收口连坐失败；现在改为警告后仍然释放。

keil-build：default_lock_task() 增加 .dsh-worktrees/ 反推分支，插件树内的构建归属
pw:<name> 而不是兜底的 build-cli（主树行为未变，本次 @build 实测仍走 build-cli）。

.gitignore 预先忽略 .dsh-worktrees/，让插件的 ensureIgnored() 找到同一字面量、不再
改写这份受控文件。check_doc_links / check_layer_deps / gen_refgraph 三处扫描面同步
排除：仓里再放一份仓会让 doc-links 假红、并让生成的配图字节漂移到 generated-fresh。

文档：并行任务工作树方案新增 §3.4 两套系统边界对照；SKILL.md 加 §F 共存一节，同时把
§B 从 53 行压到 29 行（净 +39，用户此前在飞的改写已 rebase 保留、未被覆盖）。

验证：@build 0 错误 0 警告；scripts/ci_local.py 48 根提交期钩子与 gitlint 全绿；
check_doc_links --all --sections-strict 通过（2596 章节引用、无法判定 0）；id-check-new
通过；改动文件字节体检无 BOM、CRLF 与 U+FFFD。桥接行为在临时 scratch 仓端到端跑过
（adopt 建两个 reparse、unadopt 只摘联接、pw 锁取放、缺台账也能释放、越界 name 退 2）。
 2026-10-29 07:50:05 +08:00
wandering1 7e15f49ff3 refactor(编号): UI 菜单层级 L0~L3 → 主界面/一级/二级/三级菜单（批次 3a） 
这族是菜单深度号：L0 根、L1 一级、L2 二级、L3 三级。用户 2026-10-28：「编号看不懂」，
且与采集链分层的 L1~L5 撞形（同一份文档里两套 L 号，读的人得先猜是哪套）。

改法（生成物走生成器，不手改）：
- `tools/menu_gen/gen_menu.py`：加 MENU_LEVEL_NAMES 常量，生成 ui_menu_tab.c 的注释从
  `/* 12 L2 */` 变成 `/* 12 二级菜单 */`；重跑生成器，生成物 42 行注释随之更新。
- 文档 4 篇 113 行：菜单页面设计（94）、内容页架构（10）、01_主界面_说明（8）、
  中文字体生成与配置（1）。映射：L0 → 主界面（根）、L1/L2/L3 → 一级/二级/三级菜单；
  `4 级（L0~L3）` → `4 级（主界面 → 三级菜单）`；括号里的 `（L1）` → `（一级菜单）`。

范围纪律：只动 UI 菜单这一族。同名的测试层级族（L0/L0.5/L1/L2/L3，见测试开发标准流程）
与链路延迟分段 L1~L8 不动——那两个属批次 3 的另两族。

验证：@build 0 错 0 警；check_menu_rows 8 状态 PASS（5368 B 池不变）；生成器重跑幂等
（rc=0，生成物只剩注释差异 42/42 行）；doc-links 通过（195 文档）；mojibake / bom-guard /
新编号门禁 / git diff --check 全绿。
 2026-10-28 13:12:06 +08:00
wandering1 593c5d0c84 refactor(编号): 采集链分层 L1/L1.5/L2/L2.5/L3/L4/L5 → 语义名（批次 1） 
用户裁定（2026-10-28）：L1/L1.5/L2/L2.5/L3 这套层号「谁能看懂」，改用语义名。
映射（同一批定稿，含 L4/L5）：
  L1   → 语义取数与有效性
  L1.5 → 标定折算
  L2   → 全周傅氏相量
  L2.5 → 测频与遥测快照
  L3   → 保护判据
  L4   → 出口与记录
  L5   → 动作留痕

实测规模：384 站点 / 62 文件（App/algo、App/task、test/host 六个套件、docs/算法、
产品需求、架构总览、启动顺序、ADC 采样节拍、IEC104 上行、采集短板评测、内存管理、
AGENTS.md、README.md、docs/README.md、.pre-commit-config.yaml 与 scripts 里的注释）。

改法（不是全局替换，逐模式有上下文规则）：
- 先吃同位语再落裸词：L1 有效性校验 → 语义取数与有效性校验、L2 相量层 → 全周傅氏
  相量层、L3 保护 → 保护判据、L2.5 遥测快照 → 测频与遥测快照，避免「保护判据保护判据」
  这类重复（第一版就是这么坏掉的，已整体回滚重做）。
- .c/.h 只改注释：先把字符串字面量切出去（引号数为奇数的跨行注释按整行处理），
  C 字符串里的 L2-in ring 之类原样保留——AGENTS 铁律「字符串字面量必须纯 ASCII」。
- 层内条目号（L1-3 / L2-3 这类）**本批不动**，属批次 2；另外三族（UI 菜单层级
  L0~L3、链路延迟分段 L1~L8、CubeMX 防丢失三层）也不动，属批次 3。
- 顺手修的措辞：范围写法 L1~L3 → 「分层（语义取数与有效性 → 保护判据）」、
  CI 段「不含 L1/L2/L3」→「不含采集链分层」、目录地图里同一处并列表述。

验证：@build 0 错 0 警（Code=236456，与改前逐字节同尺寸——纯注释改动）；
内存布局配图已按新脚本重生成（自检通过）；doc-links --all --sections-strict 通过
（195 文档）；mojibake / bom-guard / coding-standard / 新编号门禁自查 全 rc=0；
git diff --check 干净。
 2026-10-28 13:04:02 +08:00
wandering1 2b4c0e97c2 docs: ADC 注入流程 §4 补码值刻度图 
§4 的「码」定义表只有文字与数字，台架现场容易把 TPAFE 的
152.59 µV 与 STM32 的 805.66 µV 混着用。新增一张刻度尺对照
图（docs/images/ADC码值刻度.svg），上下两把尺子分别标出
11430 码 ≈ 1.744 V 与 1000 码 ≈ 0.806 V，把"同一整数在两片
转换器上代表不同电压"变成可见的；正文补一句两把尺子差 5.3
倍、§9 每格必须写明所属通道。

生成器 tools/arch_diagram/gen_adc_code_scale_svg.py 沿用图形绘制
流程 §3.2 约定（纯标准库 / html.escape / newline="\n" /
ElementTree 自检 + 文字溢出预检）；码制与 LSB 数据集中在
PANELS 常量，换芯片才重画。已登记到 tools/arch_diagram/README.md
与 docs/架构设计/图形绘制流程.md 的生成器表 + 变更记录。

目检用无头 Chrome 截图完成（cairosvg 未装，截图不入库）。
 2026-10-27 17:25:51 +08:00
wandering1 9163a92d3b docs(adc): 前端拓扑改 SVG，③ 段定死 1:1（本板不是分压器） 
ASCII 拓扑图把 C44 / R32 画成挂在 ADC7 下的一根竖线，读起来像 2:1 分压，
恰是文档要否掉的结论。改为两个节点分开画的 SVG，并加 STM32 侧对照面板。

- 新增 tools/arch_diagram/gen_adc_frontend_svg.py →
  docs/images/ADC前端电路.svg（纯标准库 + 文字溢出预检 + 幂等重跑）
- docs/测试说明/ADC前端注入验证流程.md §2、docs/硬件平台/
  ADC通道映射说明.md §7.1 的 ASCII 图换成该 SVG
- ③ 段（AINn ↔ 转换器引脚）定死变比 1:1：ADCn 节点只有
  {串阻.2, 滤波 C, 转换器引脚}，无对地元件；"1k 到地"接在差分负端
- 305.18 / 1611.3 µV/码（读法 A）作废；数据可信.md §2.1 表改为
  引脚侧系数 152.59 / 805.66，卡 0 判据从"判别两种读法"降为
  "确认转换器 LSB 与逐通道映射"
- 顺带修 ADC通道映射说明.md §8 步骤 1 的 §5.1 自引用误判
  （文档名以 V0.0 开头被前缀规则误认，改写成全路径形式）

门禁：Keil 无关（纯文档 + 生成器）；check_ids --strict、
check_doc_links --all --sections-strict、pre-commit 全过。
 2026-10-27 17:08:56 +08:00
wandering1 4c74cfa825 refactor(编号·批次二): 文档侧 194 处保护功能号改成功能名，定义表 7 张首格改语义标识 
批次二文档半（道 gate-docs 执行）。先纠三个数的口径账，别再拿任何旧数当准：**234 处是准数** —— 卡片写
52（Lead 用了门禁 Checker 的引用集合，它**刻意排除属主文档内部的定义位**）、道里先报 265（裸正则把
`SDL2-2.32.10` 里的 `L2-2` 当成功能号，误报 10 处）。最终边界口径 = 带左边界 + 跳过反引号代码段。

· 19 只文件 HEAD 共 234 处 → 现 40 处，**40 处 100% 落在变更记录行**（冻结历史，按 Q3 一条没动），
  非变更记录残留 **0**；改写 163 行 / 16 只文档。站点最多：规划文档 110→37、相量层单测说明 25→1、
  采集与数据处理短板评测 21→0、App/algo/README 26→0。
  （`App/algo/README.md` 由上一笔代码提交带上车，路径归属已在该笔正文注明，内容是本批改写）
· **定义表首列由编号改成语义标识**（编号规范 §3.3「表首格就是短语」的完全形态）：首列原为编号的表
  共 **7 张**（不是 5 张），删掉与之重复的「语义名」列；表头标签按域词区分——三张 L3 保护**元件**表
  保留 `| 元件 |`，四张 L1/L2 表用 `| 功能名 |`（把「元件」统一洗成功能名会丢掉领域信息）。
  七张表逐张核：表头竖线数 == 分隔行 == 首条数据行 == 列数+1；与 HEAD 逐块对拍**净新增不一致块 0**，
  并且正是这个对拍抓到第一版「三张表数据行已删列、表头没删」的破表。
· 7 处删号留下的残词/重复解释括号人工收口（如「L1-5（通道标定）」→「通道标定（一次系数 + 零漂）」），
  复扫待收口站点 0；措辞逐字取自映射表，无第二种说法。
· tools/arch_diagram 三只生成器 4 处（3 处 docstring + 1 处图形文案）与产物同批：重跑后**只有位图那张
  变 2 个 text 节点的换行位置**，画布 1580x740 与总行数不变，另两张逐字节未变；改前先干跑对照证明三张
  svg 原本与生成器一致（不在 stale 基线里）——`check_generated_fresh --only docs-svg` PASS。

本笔另含 **F-* 半批的文档面**（同一轮 `git add docs tools/arch_diagram AGENTS.md` 一并收进
，非误伤）：BSD
函数调用关系里 9 处反引号紧邻指针、属主文档 §7 的停发句与导读行（**12 条定义行原样保留、不删登记族**）、
以及 `gen_net_instability_svg.py` 与它的产物 `网络不稳根因总览.svg`（「唯一读者红线」那条的框宽自适应
526 → 551，右缘 1411 未越界，画布 1560x1468 不变）——该半批的**代码注释面**在下一笔。

⚠ 因 `docs/任务规划/登记簿.md` 与 `docs/任务规划/UI补齐.md` 正被另一张卡（UI 叶数复核）改动，本笔**不含
那两只文件**，批次二的 §9 存量收尾与它们同批提交。
 2026-10-27 09:05:24 +08:00
wandering1 0f7b5a87fb chore(编号): 存量编号全量转语义短语，门禁识别面与语料同批重打 
登记簿、文档与代码注释里的存量字母加数字编号（N-x / S-x / T-x / E-x / A-x / 卡号）
一律改写为语义短语，净删 2,028 处引用；删除基线与待确认、并行分道方案、排期详述、
采集保护收尾 4 篇（内容已并入 docs/任务规划/README 与登记簿）。

门禁机器与三张账同批重打：check_ids.py 新增变更记录行豁免与第二根护栏
undecidable_total_ceiling；check_test_traceability.py 只加 stdout/stderr UTF-8
reconfigure（TC_RE 未动）；check_cubemx_survival.py 的 --write 固定 newline=LF；
id_registry / id_aliases（+19 条 retired-to-phrase）/ id_known_backlog 重打。

test/ 56 个文件同步 TC 标签语义化，其中 18 个 TU 改了 CHECK / printf 里的标签文字，
是本批唯一改变构建产物的文件集合。

为什么合成一笔、不拆四笔（实测撞闸，非偏好）：pre-commit 跑钩子前会 stash 未 staged
部分，拆开后中间提交必然是「新规则 + 旧语料」——实跑可判定 85.15% < 基线 86.00%、
不可判定 1,453 > 上限 1,166，编号门禁直接拦下。编号识别面与它描述的语料只能同码移动。

实跑基线（工作区全量）：754 文件 / 8,230 处编号字面量 / 可判定 7,079 = 86.01%
（基线 86.0%，容差 0.1pp）/ 不可判定绝对数 1,151（上限 1,166）/ 校验 1-6 错误级 0 /
告警 = 悬空 2（App/algo/freq.c 的 S2，属 §4.4 同号不同义）+ 孤儿 50。

基线从 84.0 抬到 86.0 的理由见 docs/门禁说明/id-check.md §7.6：本批真删了 2,028 处
引用，可判定面随真实内容上升，不是把分母做小。同批新增排除 docs/硬件平台/ 语料，使
识别面少 264 处——芯片手册位号与网表料号不属编号空间（registry 有 excluded_paths_note）。

⚠ 余量只剩 0.11pp（约 10 处）与绝对数 15 处：把「可判定的引用」改成散文会立刻撞第二
根护栏。另遗留一项：id_aliases 里 retired 的 N / S / T / A 别名没有 scope（U1~U5 有），
今后有人新写一个 A-4，校验 3 不会响，只能靠人，建议下批补 scope。

固件不变证据：115 个 .c/.h 剥注释并归一字符串后与 HEAD 逐字节全等，残留代码差异 0；
App / Src / Drivers 的字符串字面量零改动。@build 0 错误 0 警告；40/40 主机套件、2,889
断言全通过；覆盖率 line 89.2% / func 92.6%；pre-commit 48 钩子 --all-files 全绿；
check_doc_links --all 通过（176 文档，章节引用无法判定 0）；逐字节卫生核过：14 个带
BOM 文件与 HEAD 一致、0 个 CR、0 个 U+FFFD，字符串字面量纯 ASCII。

.cubemx_survival_baseline.json 的 watchdog-module 哈希 56bf27 变 2bb051 属合法：
Src/freertos.c 的 USER CODE 区内只有注释文字随编号改写，代码未变。

同批带上体积同码凭证与 RAM 台账行（@build 之后盖戳）：RW_IRAM1 79,008 B / 60.3%，
RW_CCM 57,376 B / 87.9%，阈值 92%。
 2026-10-26 12:28:14 +08:00
wandering1 3dc7f4a088 docs(UI方案): 返回系数小数位按可分辨精度修正 + 遥信量落地注 
两件事都落在这份方案文档里，合一笔提交（同一文件的两处改动按文件切分提交不干净，故合并说明）。

一、四个返回系数：口径从"我偏离文档"改成"文档原口径错了"（Lead 裁定 2026-10-25）
- §3.2.2 表里 4 行小数位 3 → 2 并加 ⚠；落地注改写；同步去掉 ui_w_setview.c 注释与
  tools/setview_check/check_setview_limits.py 文档串里的"偏离"措辞。
- 原口径 3 位来自"把 Q10 当成十进制存储"这个误会：Q10 存不下 0.95（0.95×1024 截成 972，真存
  0.94921875），按 3 位显示等于多打一位根本不存在的数字；整定单写 0.95 的人看到屏上 0.949 会
  怀疑装置、甚至反复重输（重输还是 0.949）。2 位才是这份存储在自己可分辨精度上的正确读数。
- 不改行为，只改文档与注释：屏上显示与行表换算逻辑一笔未动。

二、§3.1.3 落地注（遥信量页落地后回填，含两条命名取舍与一条通用陷阱）
- 命名：idx0~3 屏上写「位置1~4」不写「YK1~4 位置」；idx30 写「保护闭锁」不写「闭锁1」；点表未
  定义名的行用点号占位，不编造功能名。
- 值映射次序（先无效 → 再单双点 → 后位值）与双点支路"当前无自动化证据"的诚实登记。
- 通用陷阱：把 *_PUT(dst, 字面量) 宏用在 const char *const 表项上，sizeof(源) 变成指针宽度，
  CJK 名被截而短 ASCII 名恰好完好——只有像素文本断言会报"名字匹配不到而值在原位"。

跳过的门禁（三条同族）：mem-numbers / mem-budget / size-gate（L0c），根因是台账与体积凭证待回填。
 2026-10-25 15:33:44 +08:00
wandering1 45393be3d5 feat(ui-pages): 参数定值控制字软压板四个查看页接 par 快照 
四个空叶子（参数定值 → 查看 → 参数/定值/控制字/软压板）接上 par 通道。页面薄、模型厚：
新建 Drivers/BSP/UI/ui_w_setview.{c,h} 收四张视图表 + Q10 换算 + 越界反显，四个页面各是
一份实例 + 四个跳板钩子；渲染与分页复用批 1 的 ui_w_setlist（查看态 commit=NULL：无保存行、
无编辑通路，§3.2.6 查看列口径）。

行表三项口径全部有真源，一项都不在这份文件里拟定
- id = App/algo/prot_set.h 的枚举序。BSP 不 include App 头（分层门禁），所以行表里是裸数字
  + 行尾注枚举名——这份对不上就没人能在 BSP 侧编译期发现，于是从外面钉：见下面的新脚本
- min/max = App/algo/prot_set.c 的 g_prot_set_meta Q10 上下限按该行小数位换算的结果。整定页
  下一批复用同一批表，界内界外一处一份，不会出现「查看看着合法、整定说越界」两套边界
- 显示名/小数位/单位 = docs/UI设计/页面扩充详细方案.md §3.2.2~§3.2.5 四张表

一处偏离文档（不是静默偏离，写进三处：代码注释 / 文档落地注 / 本正文）
- 四个返回系数按 2 位小数显示，文档写 3 位。理由是量值真实性不是排版：Q10 存不下 0.95
  （0.95×1024 截成 972 → 真存 0.94921875），按 3 位显示就多打一位根本不存在的数字；整定单
  上写 0.95 的人看到屏上 0.949 会怀疑装置、甚至反复重输（重输还是 0.949）。2 位才是这份存储
  在自身可分辨精度上的正确读数——文档的 3 位来自「把 Q10 当成十进制存储」这个误会
- 单位挂在值串尾（10.00A / 500ms）而不是塞进显示名：值列只有数字会让 60000 既是 ms 又是 A。
  为此给 ui_w_setlist_row_t 加了 unit 字段（该结构此前无任何消费者，扩展零成本）；只挂在
  非编辑态——编辑中是逐位输入串，挂单位会让位光标算错列宽。A/V/ms/Hz 全 ASCII 不占字库

新增可重跑核验：tools/setview_check/check_setview_limits.py
- 从外面把三件事钉住：四张表的 id 恰好覆盖 0..39 各一次；数值行 min/max 等于 meta 上下限的
  换算；kind 与 meta.is_ctl 一致、dec 查表与行表小数位一致、单位只允许 ASCII。改 meta 不改
  行表就红。当前输出：行表 40 行 / dec 40 项 / meta 40 项 -> OK
- 写这个脚本时自己踩的两个坑也留在脚本注释里：① 正则用 \w+ 吃不下带引号的单位，会让整行
  **静默跳过**（少检一行比检查错更难发现）→ 改 \S+ 并加「行数必须等于 40」硬闸；② 脚本要
  打印中文，Windows 控制台按 CP936 写 stdout 会崩在半路（崩在半路 = 一条都没检查）→ 开头
  把 stdout/stderr 锁到 UTF-8

两个只有画面才会暴露的错（都不是静态检查抓到的，都记进了注释）
- ui_data_par() 的通道是 0=成功 / -1=尚无首帧，我按 bool 反义用了：真机与模拟器上都会「永远
  读不到」，整页值列恒 --，而页面看起来完全正常、编译与钩子全绿。看像素图才发现满屏横杠
- 肉眼把 CT 一次额定读成 1000A，字形匹配器证明值列只有 4 个字符位（命中 x=101/107/113/119）：
  实际是 100A。断言因此按匹配器能证明的写。顺带一个自洽佐证：PT 10000/100 V 配 CT 100/5 A
  正是 10 kV 馈线终端的变比；控制字页默认值天然两两一组（Ⅰ/Ⅱ 段跳闸、Ⅲ 与过负荷段告警），
  行表若整体错位就不可能复现这个组合——这条已进像素断言，成为 id 对齐的机械证据

无数据时的显示口径
- 参数帧未就位：名字照打、值列打 --（不把 0 当定值显示，也不给整页空白让人以为菜单坏了）
- 越界反显只在 bad_valid=1 时参与：把「没数据」画成「这行有毛病」是假告警，比不画更糟
- Q10 换算不用浮点也不用 64 位除：整数段 + 小数段拆分四舍五入，满位进位（MicroLIB 软浮点与
  __aeabi_ldiv 一进镜像几百字节，模拟器（宿主 CRT）永远照不出这笔代价）

批 1 那个 KEEP_EXTRA 决策在这里第一次兑现
- 本批行表用到的「延时 / 电流 / 压力 / 总 / 配 / 重 / 间 / 未」等字，正是当时成组并入 KEEP_EXTRA
  的 35 个「未知冗余」字里的一批；若当时按 extract 输出重写字符集，这些字形已被洗掉，本批
  上屏就是白框，而 font-charset 只会报「字在清单里没有」——它报不出「字曾被删掉过」
- 本批 font-charset 直接 Passed，未扩字库、未重生成字体

验证
- @build 0 错误 0 警告；模拟器 0 警告；内容页 19 项 PASS（16 页像素 + 四页共 39 条文本断言），
  其余 12 页逐字节不变；菜单 8 状态 PASS；ui-data 83/83、soe 32/32
- 四页出图逐张肉眼确认：值列右缘不越屏（10000V 最宽）、名值不重叠、第 1 页行槽与页脚不撞；
  分页页码正确（定值 18 行 = 3 页、软压板 10 行 = 2 页）
- check_setview_limits.py OK；ui_menu_tab.h 等生成物全部由 gen_menu.py 重生成（手改生成物 = 一定
  会被覆盖，见批 2 那条），uvprojx/CMakeLists 注册由生成器写入，另手工登记 ui_w_setview.c 两处
- 全量钩子 --all-files：见下一行 gate；红项只有同族三条（台账与同码凭证回填归单写者）

体积（相对 b746a1f 台账 217204 / 21504 / 1256 / 132680）
- 实测 Code 221856 / RO 23508 / RW 1300 / ZI 134660
  → Code +4652、RO +2004、RW +44、ZI +1980
- Flash 合计 +6700 B、RAM +2024 B（三批累计）。本批 RO +2120 主要是 40 行行表与名称/单位串，
  ZI +388 是 par 帧缓存（184 B）+ 四个组件实例 + 注册表增量；这是把 40 项真定值上屏的代价，
  不是可省开销

待台架实测：装载真定值后的四页读数（含真机 bad_mask 非 0 时的反显行）、翻页节拍、
PT/CT 变比与 104 上位的定值读回（C_RD）一致性。

gate: only mem-budget/mem-numbers/size-gate pending lead ledger backfill
（同族三条，root cause 一条：台账与同码凭证回填归单写者）
像素基线单独提交（下一笔新增 4 个 shot_v*.bin）：本笔单独 checkout 时 ui-golden 会报缺参考，
属预期拆分；上面的钩子结论取自「本笔 + 下一笔」的合并树。
自查：12 个新增/改动 UI 源文件 BOM 与 HEAD 对齐（本批 edit 又剥掉 4 次，逐次补回）；CR = 0；
U+FFFD = 0；C 字面量纯 ASCII（中文只在带 BOM 文件里）。
 2026-10-25 14:44:47 +08:00
wandering1 67c469fa40 feat(ui-pages): SOE 记录页接 soe_store 只读遍历（类型 7/8 首次上屏） 
ui_w_soe 组件（task-14 落）此前两端都没绑 reader，只能显示"无记录"空态。本批补齐三件事：
App 侧只读遍历、两端 reader 绑定、SOE 记录页与菜单注册。

App/log/soe_store 只读 API（Lead 已放行，本批独占这两个文件）
- soe_store_count() / soe_store_read(idx, soe_rec_t*)：与 syslog_count /
  syslog_get_record 同构——8 条一窗（512 B）整块读、命中窗口零 I/O、卷锁 try（0 超时）
  非阻塞；定长记录逐条 open 等于同一扇区开 4 次，SPI NAND 上这个差距是肉眼可见的卡顿
- 读者不得看到半成品记录，三道保障缺一不可（规则写进 soe_store.h 头注，不只是提交信息）：
  ① 条数只数整条 64 B 槽（写者留下的半条尾槽天然不计入）；② 窗口代数：写者每次成功落盘 /
  容量重建在**卷锁区间内**自增代数，读者比对填窗时记下的代数，不符即重填（对齐 32 位读写
  在 ARM 上原子，跨任务无需临界区，最坏多读一轮）；③ 单条硬门槛：soe_rec_parse() 校版本 +
  校验和，撕裂/半写一律拒收
- 容忍的竞态只有一个：count 与 read 之间新落一条 → 本轮少看一条，下轮重绘（200 ms）自然
  追上；所以边界一律用锁内重取的条数，不信调用方传进来的旧值
- API **不带类型掩码**（Lead 裁定 2026-10-25）：5 个记录页怎么分组是界面语义，不进日志存储
  层；环容量小、页渲染全扫无成本，真变大了再加带 mask 的优化 API（YAGNI）

⚠ 顺带修掉一颗定时炸弹：菜单生成器与生成物漂移
- 提交里的 Drivers/BSP/UI/ui_menu_tab.h 带着 5 个表查询 API 的规范注释块，而
  tools/menu_gen/gen_menu.py 只会输出"声明 + 行尾短注释"——说明历史上有人**手改生成物**
  补注释、没回灌生成器。我这次加 #page=soe 后重新生成，等于把那些注释抹掉，bsp-err 立刻
  报 5 条 return-doc
- 修法不是把生成物改回去（下次重新生成还会再抹一次），而是把注释块**回灌进生成器**；
  回灌后重跑 gen_menu.py 产出的 ui_menu_tab.h 与 HEAD **逐字节一致**（git diff 为空），
  漂移关闭。生成物里的手工优化 = 一定会被覆盖的优化，要么进生成器要么别改生成物

时标口径（跨模块陷阱，注释即防线）
- 页面时标取记录内的 CP56（事件自己的时标，不是"现在"）。它与运行/自检记录页同口径，靠两条
  事实叠出来：sys_clock 的 epoch 域本身就是本地时间（App/util/sys_clock.h 的
  sys_clock_set_unix 注明"Unix epoch time (秒，本地时间)"），而 soe_rec.c 的 epoch→CP56
  分解不加任何时区偏移。**谁"顺手补 8 小时"，SOE 页就会和文本记录页差 8 小时**；要引显式
  时区必须两侧一起改

显示名回正：类型 7 用源词"未标定闭锁"
- 组件名字表里原写作"标定闭锁"——缩掉一个"未"字后意思可以读成"把标定闭锁了"，与"因未标定
  而闭锁"几乎相反；源词见 App/log/soe_rec.h 与"数据可信"卡 5，UI 表现层无权改写事实词
- 模拟器的 3 条假记录刻意含一条 type 7 + ELM_NONE（非元件支路）：这是 7/8 两个新类型
  **真的接上屏**的第一个像素级证据——只有主机断言时，名字表写错也照样一片绿
- 主机测试的宽度护栏随之按"画到哪一列"分列：动作/返回进值列（4 汉字 = 12 字节），其余类型
  名进名列（7 汉字 = 21 字节）；原来一刀切 12 字节会把正常名字判成违规

页面与注册
- 新建 Drivers/BSP/UI/ui_page_soe.{c,h}：薄跳板，一条记录两行共用组件内单条读盘缓存，
  实例独立（两页共用一份缓存会互相命中对方记录号，task-6 的教训）
- 菜单树 SOE记录 加 #page=soe；重生成 4 个生成物，uvprojx / CMakeLists 两处注册由生成器
  自动写入（本批 uvprojx 只含这一条新增，无 UV4 抖动）
- reader 绑定在两端适配层：真机 App/task/ui_task.c（CP56 → UI 视图 + 容量钳位），
  模拟器 simulator/main.c（固定 3 条、时标固定串，保证黄金参考可复现）

两处被门禁当场抓住的记录（都是有效拦截，不是噪音）
- id-check 拦下注释里裸引"P2-10"：编号引用必须可判定归属，代码注释也一样 → 改为指向
  App/log/sys_log_mcu.c 与事实本身，不留裸编号
- 又一次 BOM 铁律现场复现：一次编辑剥掉 ui_w_soe.c 的 BOM，ARMCC 立刻报一串 #8/#7/#20
  假语法错（missing closing quote 之类），而 MSVC 侧 0 警告完全照不出来；补回 EF BB BF
  即 0/0。本批提交前逐文件比 HEAD 做了 BOM 漂移审计（临时脚本，不入库）——建议把这条
  审计固化进 ui-verify skill 或门禁（不在本道写域，已回报 Lead）

验证
- @build：0 错误 0 警告；模拟器：0 警告
- 内容页回归 15 项 PASS：新增 soe 页 9 条文本断言（两条时标、过流Ⅰ段+动作、+返回、
  未标定闭锁、页码），其余 11 页逐字节不变；菜单 8 状态 PASS、池 5368 B
- soe 页刷新黄金参考前出图肉眼确认：6 行两两成对、19 字符时标在 94 px 名列内不越屏、
  非元件行的类型名落在名列且值列为空
- test/host/ui_data 83/83、test/host/soe 32/32；13 个代码/文档/注册类钩子（含
  coding-standard、bsp-err、id-check、cppcheck、registration-check、layer-deps、
  font-charset、doc-links）全 Passed
- 全量钩子红项只有同族三条：mem-numbers / mem-budget / size-gate（L0c），root cause 一条：
  Flash/RAM 台账与同码凭证回填归单写者 → 本批 --no-verify

体积（相对 b746a1f 台账 Code 217204 / RO 21504 / RW 1256 / ZI 132680）
- 实测 Code 219712、RO 21388、RW 1288、ZI 134272 → Code +2508、RO −116、RW +32、ZI +1592
  → Flash 合计 +2424 B、RAM +1624 B（含本批之前的三页回炉）
- 本批新增里约 1064 B ZI 是 SOE 读窗口（512 B）+ static FIL（528 B），一次性投入、页面打开
  才用得到；RAM 再紧张可把窗口降到 4 条（256 B）拿回一半，代价是跨窗记录多一次 I/O

待台架实测：真机 /log/soe.log 有记录时的翻页与尾部行为、卷忙时该行退化显示、SOE 页与文本
记录页时标一致性（跨 8 小时口径的现场核对）、记录增长时窗口代数失效后的重读节拍。

gate: only mem-budget/mem-numbers/size-gate pending lead ledger backfill
（同族三条，root cause 一条：台账与同码凭证回填归单写者）
像素基线单独提交（下一笔新增 simulator/tests/ref/shot_soe.bin）：本笔单独 checkout 时
ui-golden 会报"缺参考"，属预期拆分；上述钩子结论取自"本笔 + 下一笔"的合并树。
自查：BOM 漂移审计 17 个改动文件全对齐 HEAD；CR = 0；U+FFFD = 0；字面量纯 ASCII。
 2026-10-25 14:44:45 +08:00
wandering1 2e0f66a07e feat(UI字体): 扩字60字为页面扩充预置, 修复生成器cmap插入顺序缺陷 
字库扩充(批2页面预置, task-4/道B):
- ui_cn_chars.txt 119→179 字(CJK 176 + 符号 ▶/，/：)，含 ASCII 共 274 字形
- +60 字: Ⅰ Ⅱ Ⅲ 段 延 投 退 跳 闸 零 频 荷 负 低 过 电 一 二 次 位 公
  出 回 外 部 度 温 态 状 总 接 显 示 最 近 未 标 欠 闭 锁 长 间 障 配
  道 重 载 返 年 月 分 秒 合 已 请 求 确 取 消 越
  依据 = 页面补齐规划/页面扩充详细方案两篇规划中出现的页面显示串；
  待拍板的厂家设置支用字(厂/家/恢/调/试)不入
- Ⅰ/Ⅱ/Ⅲ 宋体有字形(simsun face0 cmap 实测 HAS)且正常入字体，罗马数字
  无需任何工具链兜底

make_font.py 修复(本次扩字暴露的真缺陷):
- LVGL get_glyph_dsc_id() 线性扫描 cmaps[]、首个包含码位的 range 即返回:
  Ⅰ(U+2160) 使稀疏 range 起点 0x4E09→0x2160，把 U+25B6 ▶ 单码位补回条目
  吞进宽 range → 模拟器箭头全变方框(菜单 658 px 差异)；旧 verify_coverage
  按"进了任一 range 即覆盖"判定，全绿照不出解析路径倒置
- 修复: _insert_cmap_entry() 把补回条目插到包含它的 range 之前;
  _cmap_lookup_gid() 可达性守卫，可达即跳合并(全角逗号走稀疏列表，不再
  追加永远不可达的死条目); verify_coverage() 改按首命中语义

验证(全绿):
- font-regen 四步(extract→并回 KEEP_EXTRA→make_font→diff)；仓库外沙箱
  dry-run + 确定性: 沙箱/仓库产物 sha256 一致(26e519db…)
- 逐码位结构对账: added=60 / removed=0 / 保留字形位图字节零差异 /
  度量一致(multiset 差 = 新字身)
- font-charset PASS(60 未知冗余 WARN = 预置字，批2接线后自然转在用)
- 模拟器菜单 8 状态 + 内容页 11 页黄金参考与旧字体逐字节一致(箭头恢复);
  ref/ 基线无变化，故无黄金参考更新提交
- @build 0 Error 0 Warning; A/B 同树构建: RO-data +1528 B, RW/ZI(RAM) 0

gate: only mem-budget/mem-numbers pending lead ledger backfill
- pre-commit --all-files 实测: 仅这两条失败(台账受管区/内存文档数字 vs
  .map 漂移; 根因是 RO-data +1528 B 的 Flash 增量, RAM 无变化);
  其余 38 钩子全绿(font-charset/ui-golden/cppcheck/编码规范/单测族均过)
- 修复手段 ram_baseline.py --write / check_mem_numbers.py --write 均写
  docs/内存管理/**(Lead 单写者域), 本分支按裁决不代跑, 请合并后回填
- 手工自查: 改动 8 文件 BOM/CR/U+FFFD 与各自原状一致(全 LF 无 BOM),
  字体产物纯 ASCII, make_font.py 中文仅在注释与打印, 无字面量改动
 2026-10-25 03:23:52 +08:00
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 的子节。
 2026-10-23 09:15:41 +08:00
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 状态改为 🟡 主体已落地。
 2026-10-23 07:42:02 +08:00
wandering1 8b0ea17b71 fix(lftpd): LIST/NLST 满块续发——大目录不再被静默截断并回 550 
现象：`ftp_test.py` 的 `LIST 150->226` 断言失败——1512 B 数据全收到了，完成回包却是 **550**。

**根因**（`send_list`/`send_nlst` 各一处）：定案三把"整份目录一次性批量发送"落进 static 1536 B
缓冲时，顺手留下了"装满就 `break` 并回 −1"，`cmd_list` 据此回 550。于是目录一旦超过一块，客户端
拿到的是**静默截断**的清单**外加一个错误码**——而清单看起来完全像"目录里就这些"。这比单纯报错
更危险：没有人会去数条目个数。

**台架实测（同一台设备、同一个根目录，改动前后各测一次）**：
· 改前：1512 B / **24 条目** / 完成回包 **550**（停在 A0007.BIN，后面 6 个文件被吞）
· 改后：1880 B / **30 条目** / 完成回包 **226**

**修法：满块续发**，而不是把缓冲区加大。新增 `list_batch_flush()`——装满一块就整块发出、清空
继续装，收尾再发最后一块。为什么仍要"批量"：定案三的本体是实测结论——同一连接上背靠背 ~60 B
小段写会毒化 CH395F 的 TX（芯片报 SEND_OK 但对端全丢，无 RST 无 DISCONNECT），而 RETR 的 1 KB
满块连发安全；所以这里只发大块，绝不退回"每行一发"。单行真装不下时**明确失败**而不是少发条目
（8.3 短名 + 定长格式远小于 1536，真发生说明格式被改坏）。两条出口的 `lftpd_io_closedir` 收敛到
循环后单点：卷锁持有至 closedir，任何提前 return 都会漏锁。

**防回退**（关键）：修完之后，**目录清空的设备上这颗雷再也暴露不出来**，所以补了
`test/host/ftp_list_fill_test.py`——自造 26 个 8.3 短名文件把清单撑过一块，三条判据（STOR 全 226
／LIST 全文里每个名字都在／完成回包 226 而非 550，用 ftplib `retrlines` 让非 2xx 完成直接抛），
跑完逐个 DELE 还原。真机实测 `收到 56 行 / 3544 字节`（跨 3 块，满块续发被真正走到）→ 三条全
PASS。用法登记进 `docs/测试说明/FTP_Test_Guide.md` §4.5，机理与增补写进
`docs/问题记录/CH395F_Trap_Records.md` 定案三。

**顺带记录的已知偏差（未修）**：`cmd_list`/`cmd_nlst` 忽略命令参数、恒列会话 CWD
（`client->directory`）。主流客户端都是 `CWD` + 裸 `LIST`，实际影响小，先记在案。

体量：`Code` 213,264 → **213,436 B（+172）**、RO 不变 → `ER_IROM1` **232,088 B（22.1%）
  **、
`ROM 合计` 233,276 B；**RAM 一字未动**（`RW_IRAM1` 75,264 B 57.4% / `RW_CCM` 57,376 B
  87.9%）。
数字联动照做：`data/ram_report` 重跑、`ram_baseline --update/--write`、
  `check_mem_numbers --write`、
FLASH 配图常量重算重生成（桶合计 = 232,088 与 `Code+RO` 相符）、报告 §1.3/§5.1/§5.4 与部署 §3.3。

门禁：`@build` 0 错 0 警告；`@test` PASS（692 ms）；`ftp_test.py` → **TEST
  PASSED**（含此前失败
的 `LIST 150->226`）；`ftp_up_dl_test.py` → TEST PASSED；`ftp_list_fill_test.py`
  → TEST PASSED；
`doc-links --all` 146 文档 0 问题；`id-check --strict` 增量拦截通过（可判定 82.82%）；
`mem-numbers` / `mem-budget` 通过；改动文件字节卫生 BOM 无 / CR 0 / U+FFFD 0 / 无行尾空格。未推送。
 2026-10-22 22:41:31 +08:00
wandering1 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 / 无行尾空格。未推送。
 2026-10-22 22:31:09 +08:00
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 / 无尾空格。
未推送。
 2026-10-22 20:01:40 +08:00
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`（本次未被改写）。未推送。
 2026-10-22 19:21:08 +08:00
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 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 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 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 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 0edbfaf08b fix(NET): 监听重建单一所有者收口 + 沉降窗 800ms 上限只留痕
CI / L0 静态门禁 (pre-commit) (push) Failing after 1m12s
Details
CI / L0.5 主机侧单测 (MSVC) (push) Successful in 17s
Details 
T0 降噪 + T1 单一所有者：四处重建触发（recon/accept/eof/drop）与 pending
第五处统一走 net_listener_request()，由 net_listener_tick 单点执行；
沉降重试日志改"只留首末"（E0 口径），每次恢复少打 3 行重复行。

force open 降级为只留痕（E19 反事实 A/B 实测）：芯片未回 CLOSED 时强行
open 注定吃 USE 错（TRAP-NET-09），放行与不放行的端口恢复时刻同一分布
（放行 +512 / 不放行 +505·533 / 降级后 +509 ms）——恢复由芯片何时回
CLOSED 决定。真正兜住"监听器永久失效"的是 D10 预算到期 + 对账形态④
重新登记，不是放行。新增 s_relisten_capped[] 使上限留痕只打一次，
隔离标志不清 → 下一轮继续排空残渣（构建 B 实测每 30ms 两行会刷屏）。

负向注入三轮打靶（E18，注入代码不入库）：形态① 吞掉 DISCONNECT 后
4/4 救回、③ 空闲监听器静默失位两轮独立复现、⑤ 开盲区吞掉芯片自发中断
+ 收回 LISTEN 后 -> resync 命中且挂起 recv 被取消 → 三条均不可降级为
只留痕。顺带稳定复现 [ERR] relisten retry budget exhausted = 对端不配合
拆链的签名，非回归。

台架：boot PASS；ftp_abort_probe RST 10/10 + FIN 5/5；relisten_stress
:21 50/50（p50 507ms）；n30_repro 30/30。构建 0 错 0 警 Code=212316；
netTask 静态最坏链 1920→1912 B；RAM 台账受管区已 --write 同步（RW +8B）。
文档：E17/E18/E19 三行 + §4.1 常态 0 命中归因 + §4.3 兜底归属改正；
登记簿 N-31 销项（结论沉淀进 §4.3 与 E19）。
 2026-10-14 15:57:10 +08:00
wandering1 f849c79b7a feat(NET): SEND pending 二期落地 + 末块挂起越界缺陷修复（台架复测闭环） 
net_pending.c/h 增设第二张挂起表 s_net_send[]（与 recv 表完全独立，收发
互不阻塞）；net_send_locked 快速路径改为有界自旋，单次等待超出
NET_SEND_SPIN_MS(2ms) 即登记挂起 send，由 net_send_pending_tick 按主循环
节拍分块推进，netTask 最坏停滞由 1s 压到 2ms。net_listener_retry_tick 的
挂起保险扩展到 send 侧；net_close_locked / 网络重建 / 状态对账三路均先
取消再动作（取消必通知，调用方永不挂死）。

台架复测（A/B 对照 + 插桩定位）发现并修复末块挂起越界缺陷：内层"等本块
发完(SENBUF_FREE)"位于写块之后，写完末块时 sent 已 == len，若该次等待越过
2ms 预算便会调用 net_send_pending_register，而登记函数按 sent >= len 拒收
并回 -1，把一次实际已完整交付芯片的发送报成失败。修复为内层等待开头判
sent >= len 即跳出（末块已交付、SENBUF_FREE 等待是纯保守自旋），并置于
超时/自旋判定之前；该守卫同时保证后续登记必伴随 sent < len。

复验：ftp_regression 连续 19 次 11/11；ftp_integrity_test 20 轮 x 64KB
STOR/RETR SHA-256 20/20 一致（两轮），吞吐稳定约 80KB/s；设备日志零
write error；ST-LINK 回读 No difference found。

文档：Net层阻塞模型架构设计.md 补二期设计与新增 9.1 缺陷记录，netTask
栈实测峰值按本次台架 920B 订正为 1116/3840（FTP 传输期 1164）；网络自愈
架构设计.md 吸收原监听生命周期文档、新增编号术语导读表，并把 5.2
"实验锚点速查"的 E 编号含义与 E-02 审计编号歧义写在表头（用户反馈该表
E 编号无法读懂）。

门禁：Keil 0 错 0 警；cppcheck / 编码规范 / 乱码零告警；
check_mem_numbers PASS；check_doc_links --all --sections-strict 142 篇 PASS。
 2026-10-14 12:05:21 +08:00
wandering1 df13dec479 refactor(net): 挂起 recv 模型拆出 net_pending.c/h + 留痕探针编译门控 + E15 归因修正
CI / L0 静态门禁 (pre-commit) (push) Failing after 2m14s
Details
CI / L0.5 主机侧单测 (MSVC) (push) Successful in 22s
Details 
- E15 归因修正：幽灵状态 0x04+旧端口 = 芯片如实报告拆除中的旧连接
  （文档化行为，非芯片故障；bit3=1 为我方设置（ver>=0x46）、
  RFC 9293 §3.3.2 Fig5 拆除顺序、WCH 官方博客方案 = close 完成后重开监听）
- 术语统一：全库"了结"→"结束"（约 45 处）；阻塞模型 §4 首次出现处定义"五路"
- 注释清理：删孤儿函数头注释、考古叙事改现在时、去不可检索内部编码"L3"
  （33 处 6 文件）、banner 去重（唯一理由移到分支现场）
- 挂起超时留痕探针：编译期开关 NET_PENDING_TRIPWIRE（默认 0 = 编译剔除，
  省约 150B Flash；排查调用方挂死时置 1，只留痕绝不强制结束）
- 拆模块：net_pending.c/h（363/94 行）承载挂起 recv 模型，
  net_socket.c 4059→3661 行；tick 收控制块表参数、settle_close 双参显式传；
  net_pending_active 声明移配对头（S17 2.2）；仅注册 uvprojx +
  check_registration MCU-only 白名单（同 net_listener.c 机制，
  模拟器走 net_socket_sim.c 按外部语义模拟）
- 文档：阻塞模型新增全过程小节（单主干流程图）+ §9 排查辅助；
  NET README / 函数调用关系 / 自愈架构 / BSD 指南同步；引用关系图重生成
- 台架回归：启动闭环 PASS（[ERR]/Fault 零命中、回读一致）、
  :7003 重连探针 10/10、FTP 50 连接 STOR 50/50、回归窗口串口日志无异常
- RAM：ER_IROM1 230004B（探针门控后约 -150B），台账已回填
 2026-10-14 09:53:38 +08:00
wandering1 a12367981d fix(N34): E14 丢中断复核——芯片不丢事件；listen 排事件挪至 LISTEN 前+全局读收口+全库归因更正 
48 轮直读 SINT 矩阵（8 周期×6 变体）复核历史"丢中断"说法：芯片侧事件
丢失 = 0。归类：drain 读清消费 3/48（drain-int 探针现场抓获）、门控
竞态 2/48、主机同步 1/48、幽灵态 0/48 未复现。

根除性修复：net_listen_locked / net_listener_try 的排事件读清从
listen 后挪至 LISTEN 命令之前——新连接 CONNECT 落进该窗即被本方读清
吞掉，即"数据被吞"的生产侧自伤机制（台架 3/48 为同形态放大版）。

全局读收口：全局中断寄存器唯一读者 = net_poll（I7）；生产/测试/台架
游离全局读全部删除，ch395f.h 声明处加护栏注释。

归因更正：17 文件约 40 处"丢中断"措辞改为"事件未收到/读清消费竞态"
（机制全部保留，仅归因更正）；设计文档 §5.2 新增 E14 锚点；Trap
Records TRAP-NET-17/-20/B3 归因更正段；配图生成器与 SVG 重生成。

台架：事件未收到复核探针保留（drain-int / SINT 补读×3 / 超时归类），
下次跑矩阵自动归类；实验注册（main.c/uvprojx）已完全还原。

验证：@build 0 错误 0 警告；ci_local L0 32/0 + gitlint + L0.5
953/953；doc-links --all --sections-strict 通过；@test PASS（无
[ERR]，net init 619ms）；回归 :7003 300ms×10 = 10/10、:21 n30×50 =
0/50 失败。
 2026-10-14 02:48:50 +08:00
wandering1 1a35b3684c docs(N34): 自愈审计目录 7 份文档合并为单文档，全库引用同步
CI / L0 静态门禁 (pre-commit) (push) Failing after 44s
Details
CI / L0.5 主机侧单测 (MSVC) (push) Failing after 43s
Details 
- `docs/网络/N34-自愈审计/` 目录 7 份文档（根因总览 / net 层盘点 /
  驱动层审计 / 主流对照 / 汇总裁决 / 实施方案 / 实验方案）合并为
  `docs/网络/N34-自愈审计.md`（§0~§6），原目录删除；docs/README.md
  索引与变更日志登记归档
- 全库引用同步：4 篇文档 + 驱动/NET/test 代码注释 + 配图生成器与 SVG
- 内容零丢失抽查：E0~E13 实验记录、E6 裁决（命中=0 不立项）、
  提交表（含 `925058a` 收口行）均在位
- 门禁：@build 0/0（注释级路径更新）；check_doc_links --all 143 文档
  通过（净 −6 = 删 7 增 1 吻合）；ci_local L0+L0.5 全绿
 2026-10-13 23:23:55 +08:00
wandering1 925058a5ae fix(NET)+docs: lftpd 对端地址修复、E6 裁决收口、陷阱编号迁移重排 TRAP-NET-01~21 
- lftpd：net_inet_ntoa 段序改 MSB 首 + 新增 net_getpeername，FTP 日志打印
  真实对端地址（真机实证 192.168.1.2:55524，登记 TRAP-NET-21）
- E6：NET_U15_PROBE 命中=0（含压测）→ 阶段 3 项 4 不立项，U15 登记观察项；
  插桩留仓（宏=0 零成本），soak 驱动 test/host/e6_soak.py 入库
- 编号：全库 Trap NN → TRAP-NET-<nn> 迁移并重排连续 01~21（单调映射，
  沿革见 CH395F_Trap_Records.md 头注）；死号 12/13/19/21 引用全部清除；
  GD5F 域引用补正为 TRAP-GD5F-NN
- 陷阱文档全新化：索引 21 行行行真陷阱；删误判存档/发现时间/git 考古/
  FTP 附录；台架纪律教训沉淀第六章方法论
- RAM：Code 211348→211456（+108 lftpd 修复），RW+ZI 净增 +4B；
  优化方案/台账受管区/tsv 同笔同步
- ftp_abort_probe.py 挪 test/host/；引用关系图重生成
- 回归：@build 0/0；@test PASS；ftp_abort 10/10；relisten :7003 20/20；
  ci_local L0+L0.5 全绿；E6 窗口零复位，7 条 WD stall 登记压测假象备查
 2026-10-13 20:54:31 +08:00
wandering1 c7459b393f docs(N34): 网络不稳根因复盘总览（比喻版）+ 全景图 SVG 生成器 
- 新增 网络不稳根因总览.md：七个误会（传达室比喻+机制+证据出处）→
  环↔拆法↔落点对照表 → E13 僵尸会话 Mermaid 时序图 → 一句话总结
- 新增 tools/arch_diagram/gen_net_instability_svg.py（draw-diagram 规范，
  纯标准库）与产物 docs/images/网络不稳根因总览.svg（headless Edge 目检两轮）
- N34 README：实施状态表补全阶段 1.5/2/3 与 E6 插桩行（原「阶段 2/3
  未开始」陈旧口径修正）；挂复盘总览为第一入口；§5.56 改紧邻写法
- 门禁：check_doc_links --sections-strict 本批 4 文件通过
 2026-10-13 17:12:36 +08:00
wandering1 c9aa12e8bd fix(arch_diagram): 生成器自写尾换行（gen_net_pending/gen_memory） 
gen_*.py 里 8 个已自带尾换行（'...</svg>\n'），仅
gen_net_pending_svg.py 少一个尾 \n → 每次重跑都被 pre-commit 的
end-of-file-fixer 补回，产生无意义的 1 行尾差异。

- gen_net_pending_svg.py: return "\n".join(svg) + "\n"，
  并把 open(...) 补 newline="\n"（与其余生成器一致）
- gen_memory_svg.py: open(...) 补 newline="\n"（输出本已带尾换行）

重跑验证：Net层阻塞模型.svg 与已提交 blob 逐字节一致
（hash-object --path 相同、git diff 为空）；内存 3 张 SVG 亦无差异。
 2026-10-12 19:26:28 +08:00
wandering1 01b9a90f45 docs(net): 同步 docs/网络 之外残留旧函数名（测试说明 + 生成图） 
docs/网络/ 主体已在 1a17d73 更新。自查发现两处「现状性」引用
仍用旧函数名（历史记录类保持原样，不改）：

- docs/测试说明/链路延迟测试说明.md §8 D10 排障行：
  net_relisten_try/retry_tick → net_listener_try/retry_tick
- tools/arch_diagram/gen_net_pending_svg.py 主循环标签
  net_relisten_retry_tick() → net_listener_retry_tick()，并重跑
  生成 docs/images/Net层阻塞模型.svg（该图被 Net层阻塞模型架构设计.md 内嵌）
 2026-10-12 19:18:38 +08:00
wandering1 f0300761ae 串口采集/测试去重：删 tools/serial_tool 与 test/host run_boot_test/verify_log 副本，引用改指 .dsh/skills 串口 skill 2026-10-10 15:13:23 +08:00
wandering1 aac5f99fe9 移除 OpenCode 配置与命令，技能与串口单一配置源迁移至 .dsh/skills 与 .serialtest，同步更新全部文档引用 2026-10-10 14:05:36 +08:00
wandering1 0779d3a075 栈整改不抬栈：删旧档迁移、FIL静态化、日志行缓冲按模块收紧、钩子脱离HAL，defaultTask链5312→2776B 2026-10-10 10:17:00 +08:00
wandering1 61a6061950 串口助手补残行封顶与会话边界复位、截头按行对齐、open 保持 dtr/rts；判定加命中行/顺序/耗时/JSON 与产物清理 2026-10-10 03:17:16 +08:00
wandering1 b37fdea21b 修复串口助手6处采集缺陷：wait-idle no_data与首字节门、log先过滤后截尾、HTTP独占绑定修正、超时不再误拉daemon、配置BOM容错 2026-10-10 02:33:44 +08:00
wandering1 554b2e88da 方案文档改造为机制说明：删除规划/盘点/阶段/风险/任务拆分章节，保留变量清单/解析语义/配置方法/验收判据，外部引用同步重编号 2026-10-02 23:21:25 +08:00