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

695 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
wandering1 2e608118ce feat(对时): 8888 对时补一条操作记录留痕——与 104 对时对称，被拒不落痕 
task-49 盘点盘出的唯一供给缺口，task-50 实现（道H 交付）。为什么这算缺陷而不是「维护工装不值得留痕」：
对时改变的是**其后每一条记录**的时标，而 104 侧的对时**已经留痕** —— 同一类行为两种结果，这个不对称
本身就是缺陷。FTP 上传不留痕则维持原状（那是传输动作，与「装置时钟被改了」不同类），本笔
刻意不扩面到它。

实现：`time_sync_handle_conn` 里 `sys_clock_set_unix` 的返回值原先是**裸丢弃**，现改为接住判
0，==0 才
投 `SYSLOG_OPER`（走 quiet 口，netTask 侧纪律，栈成本已在注释写明）；**被拒零投**（不把失败记成改过时
钟）；无合并锁存（连续两次对时留两条，不折叠）；**epoch 语义零触碰、零时区补偿** —— 时基口径仍在用
户手里，本笔不替产品决定。

新用例四组十二断言：成功恰一条 / 被拒不落痕 / 连续两次两条 / 魔术字不符皆零。假件把 rc 做成可脚本，
并专门钉「文案出现次数」以证不合并；`sys_log.h` 用真实头（纯 stdint，走 task_watchdog 先例），零桩漂移面。

**停发口径的第一批**：新断言**不配 TC 号**，改用语义化用例名 + 函数名追溯，注释里标了口径出处 —— 裁定
能不能落地看的就是第一批，这条留在这里给后来者当样例。

证据：time_sync 92/92（存量 82 零回归）；@build **0 错 0 警**，Code=235268 RO=26308 RW
=1572 ZI=136924
（与上一笔的差值是 728d6067 合账所致，不是本笔）；栈**以表为证**：timeSyncTask 链 1272→1272 B 零增
量，own frame 152 不变，handle_conn 200 / post_quiet 40 / post 264 逐函数帧全等 ——
按今天刚定稿的栈判
据，「零增量」这句话必须是表，不能是论证。id-check --strict 0（零新号零裸形）、乱码/嵌套/BOM 净。

台账：`ram_baseline.py --update` 已记当日行（IRAM1 61.9% / CCM 87.9%）。覆盖率基线**留给 L
ead 重建** ——
上一版基线是在 time_sync 套件编译不过的破树下打的，少算了该套件的覆盖。

台账同步：本笔代码改了体积（Code=235268），RAM 预算台账受管区与文档快照区按 12:46 那次权威构建回填（ram_baselin
e --write 加 check_mem_numbers --write）。代码与数字不同笔，就是下一次 mem 钩子假红的来源——上一笔 d
ocs 提交被 mem-numbers 与 mem-budget 双双拦下，正是这个原因。
 2026-10-27 13:49:38 +08:00
wandering1 13001f2ae4 feat(门禁): 栈判据定稿——静态 margin 唯一拦提交、运行时水位只告警、采集不健康整轮作废 
task-32 裁定落成可执行件（道F 交付）。不是二选一而是**分权**：静态最坏链 margin 仍是唯一拦提交项（由
`stack_report.py` 守，它本就把运行时峰值取进 max）；新增 `stack_gate.py` 管台架侧——趋势只出 WARN，
**绝对底线**（free_min < 25% cfg）是运行时唯一有 FAIL 权限的一档，**采集健康门不过 = VOID / exit 2**，
不红不绿、不进台账。把「daemon 死了 status 仍报正常、rx_lines=0」那类事故机械化：门不过与设备故障
exit 1 分开记，按码聚合的人不会把端口没开当成又崩了一次栈。

容差是推导的：tol = 上取整到 16 B 的 max(128 B, 2×实测摆动)，实测 80 B ⇒ 统一 160 B，登记进
`scripts/stack_tolerance.tsv` 带来源列；**改数权限写死**——只有台架重测后才允许回填，禁止为让某轮变绿
而调大容差（被这把尺考核的人不得当场决定尺子的松紧），且这句话**紧贴数值写**。

`--selftest` 14 条能红，开发中抓到作者三个真错（身份戳正则把 __DATE__ 月份写成三位数字、一度把跨轮戳
不同当 VOID 会让判据永不可用、文档 §4.0.2 被 doc-links 抓跨文档串号）。**不接 pre-commit**：它的输入
是台架串口采集，提交时既无设备也无当轮日志，挂上去要么永远 SKIP、要么拿上一轮日志判这一轮的码（与
体积门禁那条假凭证同族）。
 2026-10-27 11:31:53 +08:00
wandering1 728d60675f feat(UI/采集/104): 通讯设置页 + 开机账本 + adc_cal 可诊断化——三车道同树一次构建入库 
三条道在同一棵树上交付，故合并成**一次权威构建**（@build 0 错 0 警，Code=235236 RO=26308 RW=1572
ZI=136924）后同笔入库；台账已按该构建回填（`ram_baseline.py --update` + `--write`、`chec
k_mem_numbers.py
 --write`），凭证与实际 .map 同源。归属如下：

· **通讯设置页**（道G task-9）：新增 `Drivers/BSP/UI/ui_page_comm.{c,h}`（通道六注入，与死
区页同骨架同纪
  律），`#page=comm` 绑定使 bound **21 → 22**、内容页黄金 **47 → 53**（旧 47 页字节零变化，
新增六态含
  WAIT/OK 两张）；`iec104_comm` 脏位 + store_save（**无事件位**）挂 defaultTask 同点位
轮询；`port_104` 由
  宏改走 getter、`IEC104_SERV_PORT` 删除；字体 +听/监（185 字全覆）。**实机链已闭环**：FTP 外改
[comm]
  的 ca/port → 复位 → 串口出现 `section 'comm' (2 keys)` 与 `i104: listening o
n 9004` → 还原 2404，全程无
  FAIL ⇒「重启即生效 + 端口真值」不是推断是实测。上限核对 6/8 段、2/16 键，超限现象由 TC-CONFIG-056/057
  钉死（注册 -1 + `comm init: FAIL` 锚 + getter 回 ROM），**不抬宏**。
· **开机账本**（道F task-12）：新增 `App/util/boot_stats.{c,h}`——上电次数落 SD2506 用户
 SRAM（magic +
  小端计数 + 版本 + 异或校验），一次上电 = 1 读 + ≤1 写，**零 NAND、零卷锁、零配置段**；四态互斥
  UNKNOWN / FRESH / CONTINUED / RESTARTED（BLF=1 才算电池域掉过电），**读失败绝不回写**；
文案口径「自 RTC
  电池周期起」，**禁写终身次数**。复位原因优先级链从 `app_main.c` 的 if-else 收进一份真源（串口与屏幕同
  源）；104 四个只增不清计数 + `iec104_serv_get_stats()` 留在 serv、未塞进 link（会被 open
/close 洗掉）。
  运行时长按用户裁定 = **只报本次开机以来**，零新增代码。新套件 `test/host/boot_stats` 21/21，五处注入
  **全部有牙**（含「漂一字节被校验和挡下而不是报 256 倍错账」）。
· **adc_cal 可诊断化**（道E task-43）：三个 volatile 计数 + `adc_cal_get_stats()`
/ `adc_cal_note_persisted()`
  （水位**盖写非自增**，因为一次 save 覆盖整档，数 save 会留假未落盘）；「差额 × 脏位」三态语义唯一落在
  `adc_cal.h`，其中「差额 > 0 且脏位恒 0」= 绕过语义 setter 的静默丢失；TC-ADCCAL-019~023。

三条**必须留档的自纠**（都是执行道自己报的，我不替他们润色）：
① stdint 那条断链是**宿主套件抓到、通讯道先修**，采集道承认自己是重复添加者并删掉自己那份；
② 「exit 2 不是证据，断言变红才是」——采集道第一版反证注入了未声明标识符导致编译错，差点当成功；
③ 套件汇总行原写 `s_total/s_total`，失败时会打印「21/21 PASSED (failed=1)」这种自相矛盾的行，已改。

另修：`check_registration.py` 的 `SIM_EXEMPT` 加一行豁免 `App/util/boot_stats.c
`（依赖 I2C 与 RCC 位掩码，
MCU 专属；核过 `sys_clock.c`/`sha256.c` 同形态先例），注册反向校验 exit 1 → 0。发号 TC-IEC1
04-034、
TC-UIDATA-029 已实抬游标（`TC-IEC104-033→034`、`TC-UIDATA-026→029`）。

门禁：id-check --strict 与 plain 均 rc=0、doc-links --all rc=0、注册校验 0、cppche
ck / coding-standard /
bom-drift 0；iec104 179/179、ui_data 295/295、boot_stats 21/21、adc_cal 11
7/117、run_par 67/67；菜单 8 状态
池 5368 不变、内容页 53/53。**已知遗留**：内容页数 47 → 53 的全仓文本同步尚未做（另卡跟踪），本笔只保
证代码与黄金一致；面板注键真机那一腿缺 CLI，交台架道补。
 2026-10-27 11:29:23 +08:00
wandering1 0ae9c10f24 docs(时间): 时基口径定稿——内部一律本地钟面（用户裁定「时基先本地为准」），并纠正本文自相矛盾 
用户裁定原文：「**时基先本地为准**」。这条定的是**冲突时谁赢**：面板时钟页与 8888 对时把「本地钟面当
epoch」写入，而 104 的 `C_CS NA` 对时命令携的是 UTC，两条写入口**后写者赢** ⇒ 装置墙钟与主机本地时刻
恒差 8 小时。裁定结束「后写者赢」：**内部真源 = 本地钟面**，任何来源写入前都先换算成本地钟面再落库。

**顺手挖出这条 8 小时的真正根因：本文自己就是矛盾的**——§2 的术语表把 epoch 定义成「自 1970-01-01
00:00:00 **UTC** 起的秒数」，而 §15 网络校时协议字段写的是「**本地** Unix 时间戳，与电脑显示一致」；代码
按后者实现。所以「恒差 8 小时」不只是两条写入口打架，**规范文本也没统一过**。现在 §2 改成「本地时间戳：
把本地钟面按 UTC 记法数出来的秒数，内部不加任何时区偏移」，§13 那行旧建议「如需 UTC/时区可在 API 层
加偏移参数」一并标作废（它会把「装置不存时区」这个优点拆掉）。

**为什么选本地**：日志时标、UI 显示、FAT 文件时间三者都是**给现场电气工程师读的**，跟装置所在地钟面
一致才没有解释成本；装置不存时区、不做夏令时，也就没有「时区参数配错」这一类故障。

⚠ **本笔刻意不做的一件事，也是本笔唯一需要人看的地方**：104 **上行**时标 `CP56Time2a` 按标准应发 UTC，
而 `iec104_epoch_ms_to_cp56()` 现在是把内部值**直接按 UTC 分解**发出——即发出去的是本地钟面值。两条出路
要么给装置一个时区常量并上行前减偏移（标准符合，但与「不存时区」相冲），要么维持发本地值（同时区现场
看着正确，第三方主站按 UTC 解读会差 8 小时）。**这不是 bug 修复，是产品对外语义决定，牵动送检与第三方
主站验收**，所以本轮**一行代码都不改**，只把分岔与后果写进 §1.1 末，等单独裁定。

自查：`check_doc_links --all` exit 0（198 篇）、本篇 `--sections-strict` 通过、noBOM
 / LF / U+FFFD=0 / 结尾
换行齐、不可判定绝对数 979 未变；本笔**纯文档**，零代码零编号。此刻另有五条道在飞（通讯页 / 计数器 /
对时留痕 / 台架判据文档 / 记录页设计），故只提交这一只文件，其余按道分笔。
 2026-10-27 10:50:16 +08:00
wandering1 a10d24c09c docs(任务规划): 运行时长口径落定——用户裁定只报本次开机以来，清单项去掉「待裁定」 
用户裁定原文：「**A 只报本次开机以来**」。本笔把这条裁定写进 `UI补齐.md` 三处（§2 第 3 项判据、状态列、
§3 数据源对照行），并把它**能省掉什么**与**不能顺手砍掉什么**分开写清——这是本笔唯一需要动脑的地方：

· **省掉的**：跨开机累计要自造正源（往 RTC 芯片用户 SRAM 存累计秒数、处理电池失效判读、文案还得写「自
  RTC 电池周期起」）。选了 A，这一整套都不做；UI 那一栏改为**明写「本次开机以来」**，免得读者误以为是
  累计值——清单里那句「新计数器要明确掉电保持还是本次运行、不得含糊」是靠**把口径印在屏幕上**兑现的，
  不是靠注释或文档。
· **不能顺手砍掉的**：上电次数是**另一个数**（次数 ≠ 时长），它的正源问题一点没变——仍无现成计数器、仍
  建议 RTC 用户 SRAM、文案仍**禁写「终身次数」**、仍要处理电池没装或失效时读回全 1 / 全 0 的判读。派给
  执行道的卡片里同样写明「本裁定不覆盖上电次数，要捆在一起砍先问 Lead」，免得一次裁定被下游合并解释。
· **不受影响的**：复位原因（RCC 标志读后即清 ⇒ 必须开机快照驻留）与 104 统计（现有量全是控制量 ⇒ 需新增
  只读计数与 getter，就近留 `iec104_serv.c`、不并进通用统计模块）。

流程说明：这只文件此刻还带着通讯道在飞的另一处改动，本笔只提我这一处（登记簿归 Lead）。不等通讯道交回
的理由是——**这条未决口径正被另一条道当作开工前提在读**（task-12 已派出去，那半边判据要照这一行写），
把它留在工作区里等合并，等于让裁定晚于使用。

自查：全文再无「待用户裁定」残留；noBOM / LF / U+FFFD=0 / 结尾换行齐；`check_doc_links --all` e
xit 0（198
篇）、本篇 `--sections-strict` 通过；本笔零代码、零编号增删，`id-check` 与不可判定绝对数不受影响。
 2026-10-27 10:25:50 +08:00
wandering1 4c4c1d2168 docs(编号): 批次三裁定「不做」入档——TC 族保留现状但即日停发 
用户裁定原文：「**批次三，不坐**」（即不做）。本笔把裁定连同**理由与后续硬口径**一起写进 `docs/编号规范.md`，
而不是只把那一行划掉——因为「不做」最容易被误读成「那就可以继续发 TC 号」，必须把它关死。

**为什么留着 TC 族与今天的定调不矛盾**：§4.1 那条判据是「有脚本按字面量匹配它」，而 `TC-*` 是**唯一真正
满足这条判据的族**——追溯门禁与 40 套主机单测按字面量读它，C 断言标签、测试函数名、文档用例表三处同
一号，是「代码 ↔ 文档」双向核对的机器把手。清它的代价不是改文本，而是**换掉追溯机制**（候选方案「用
例名即标识」要把追溯门禁重写并重打基线），期间测试与文档的对应关系会处于**断裂态**，而测试本身就是提
交门禁（跑全部 40 套并守覆盖率基线回退）——拿它做不可逆试验不值。**结论写进文档**：机器面自解释的族
可以保留；字母号的痛在「人读」侧，解法是**别再造给人读的号**，而不是把机器面的把手也拆掉。

「不做」之后跟着两条硬口径（这才是本笔的实际效力）：
① **本族即日停发**：游标冻结、现存号只减不增，**新用例一律用语义化测试函数名 + 文档表格行名，不再配
   `TC-` 号**——已作为一行加进 §4.1 的『已停发』栏，并在『允许继续发号』栏开头写明「该族虽仍被脚本读，
   但发号已停，其余 7 族不受影响」，免得两栏看起来互相打脸；
② 将来真要清，走 `scripts/rename_ids.py` + §7.3 五步**单独开卡**，前提是先让追溯器**同时认新旧两种形态**、
   并行核对通过再谈切换；**不许先改文档再改代码**（凭空造出悬空号，校验 3 会当场拦）。

三处口径同步：§9.1 批次三正文（裁定 + 理由 + 两条口径）、§9 存量表该行的处置列（「需要先裁定」→「保留、
即日停发」）、§9 顶部执行结果表的批次三行。复核：全文再无「等你裁定 / 需要你裁定」这类悬空表述（唯一
命中的是 `UI补齐.md` 里**运行时长口径**那条，是另一件仍未决的事，没动）。

自查：`check_doc_links --all` exit 0（198 篇）、本篇 `--sections-strict` 通过（新加的「§
8 校验 3」是紧邻本文
自引用，符合紧邻写法）、noBOM / LF / U+FFFD=0 / 结尾换行齐；本笔零代码、零编号增删，`id-check --strict` 与
不可判定绝对数不受影响。
 2026-10-27 09:56:05 +08:00
wandering1 c0d7bb9c8e docs(门禁): mem-budget 第 6 节补一条盲区——同码凭证按 git 索引生成，多人同树时必红 
今天道G 报出 `check_size_gate.py --local` 单跑 exit 1（代码指纹与体积测量指纹不一致），我复核后确认这不是
预算问题、也不是谁改坏了台账，而是**该凭证的定义在多人同树下必然不成立**：代码指纹取的是 **git 索引里的
blob**，而此刻工作区里有别的任务在飞、尚未入索引的改动 ⇒ 两边算出来的东西本来就不是同一份内容。

写进 §6 的三点判据：
· 它**只挂在 `scripts/ci_local.py` 的 L0c，不在这 51 条 pre-commit 钩子内** ⇒ 红它不等于提交
会被拦，别在
  提交被拦的清单里找它；
· 报错若同时列出「未入索引的文件」而那些文件正被别的任务改 ⇒ 等它们入库后统一 `@build` →
  `ram_baseline.py --update` 补凭证；**绝不为把它调绿去 `git add` 别人在飞的改动**（这条比前两条更要紧，
  今天就这样发生过一次：别人已 staged 的文件会被我的 add 顺手卷进我这一笔）；
· 本节写作时凭证**仍是红的**（回填发生在通讯卡入库之后）——我只写成因与判据，**不预告还没发生的结果**，
  这正是 `pre-commit使用说明.md` §2.5 那条「注释陈述事实不陈述意图」在同一天的第二次应用。

自查：`check_doc_links --all` exit 0（198 篇）、本篇 `--sections-strict` 通过、noBOM
 / LF / U+FFFD=0 / 结尾
换行齐；`id-check` 未受影响（本笔零编号）。本笔零代码，且此刻两条道正在写 `Drivers/BSP/UI/` 与
`App/algo/`，故只提这一只文档文件。
 2026-10-27 09:47:23 +08:00
wandering1 f5d524fdde feat(门禁): 把「钩子跑在谁身上」机械化——ci_local 新增 L0a 解释器预检 + 环境动手术的顺序与回滚 
task-33 诊断结论的落地（道G 执行，环境**一个字节没动**：不装包、不重建、不改 requirements 约束）。

**要防的是什么**：`.git/hooks/pre-commit` 把 `INSTALL_PYTHON` 钉在 `.venv`，而 43 条
`language: system` 用
裸 `python` ⇒ pre-commit 本体走 `.venv`(3.12.4)、钩子 entry 走 PATH 首位(3.14.7，零第
三方包)。今天
不炸是**巧合**（那 43 条模块级 import 全是标准库，唯一要 fontTools 的那条自己解析解释器）。真正的危
险形态是：某条钩子在**跑到它那一刻**才报 `No module named ...`——一次提交里前 14 条已经改写完工作区、
第 15 条才崩，现场最难看，也最容易被误当成代码问题。L0a 把这件事提前到门禁第一段。

**FAIL 判据刻意收窄成三事齐备**：模块级第三方 import + 该脚本不自解析解释器 + PATH 首位那个解释器
真缺包。惰性/条件导入（`make_font` 的 fontTools 在函数体内）只列为**候选**、不判决——否则就是假阳性
（见下）。退出码 2 = 环境错误，已写进文件头退出码段与用法。

**道G 自己推翻过自己两处，都留在文档里没删**：
① 上一版诊断说「42 条里唯一需要第三方包的那条自带解析」是**宽松正则**审出来的（把注释与字符串里的包
   名也算命中），机械口径下按模块级 import 判是 **0 条**，条目数也因 nested-comment 落地从 42 变 43；
② 第一版 L0a 把 font-charset 判成 FAIL，他拿真解释器实跑反证（`C:\Python314\python.exe
   scripts/check_font_charset.py` = exit 0，因为 fontTools 的导入在函数体内、加载期不执行）
⇒ 判据改窄。
**红-绿自证**：临时假仓库三条钩子（要 fontTools 且不自解析 / 同样要但自解析 / 纯标准库）→ 坏的那条判
FAIL、好的判 OK、整体 rc=2；真实仓 → 43 条、forced 缺包 0、候选 fontTools、exit 0；同一预检在 .venv 与
PATH 首位两个解释器下都 exit 0。

文档 §5 重排成**依赖表(§5.2) → 动之前死顺序(§5.3) → 遗留账(§5.4)**（原文按追加顺序把失效顺序插成了
§5.4，读起来先结论后依据；重排时同步修掉块内那条会指错的「见下面 §5.3 第三条」，以及 ci_local 里指向
死顺序却写着 §5.2 的指针——这两处 doc-links 都**静默放过**，因为本文恰好有同号小节，见 §3.5 盲区）。
四种现场（删/换 `.venv`、只换包、换 PATH 首位、改 requirements 约束）逐行钉死「第一现场 / 症状 / 还能
动什么」，回滚按现场分条不混用：freeze 备份放仓外、只 `--force-reinstall --no-deps` 单包不 `-U`、
`pre-commit clean` 会重建别人的钩子环境所以必须先要窗口、最后手段才删 `.venv`（删前记住基底是 Anaconda，
换机复制不出来）。

⚠ 一条与本笔无关的既有红灯（道G 报出，我核过成因）：`check_size_gate.py --local` 现在 exit 1 —— 它按
**git 索引 blob** 生成代码指纹，而工作区正有 comm 道在飞的 `App/protocol/iec104/iec104_comm
.{c,h}` 未入
索引，「同码」必然不成立；**该脚本不是 pre-commit 钩子**（只挂在 ci_local），所以不拦提交，但别人跑
ci_local 会看到它，别误判成 L0a 新加的东西。台账回填等这批在飞代码提交后统一做一次。

自查：py_compile 0、`--preflight-only` exit 0（两个解释器下都是）、`check_doc_links --a
ll` exit 0（198 篇）、
本篇 `--sections-strict` 通过、`id-check --strict` exit 0 且不可判定绝对数 **978 未变**
（写文档没吃余量）、
mojibake / bom(81) / nested-comment(409) 全 0、尾随空白 0。
 2026-10-27 09:42:20 +08:00
wandering1 251268992e docs(skills): 收录陈旧计数同步流程 + 补台账回填动作 + 去掉技能文里自伤门禁的裸形 
三只 skill 文件收口（队友写成，Lead 核后入库）：

· 新增 `stale-doc-count-sweep`：把今天做的「一个事实数变了之后全仓同步」钉成流程——从权威来源**实测**真值
  → 全形态扫描并**逐条分类**（当前态改 / 变更记录历史行只加当日新行 / 同数不同义的误报不动 / 带日期戳的
  测量只加「当时」锁口径）→ 逐条字面替换且每处断言命中数 → 被改文件全文通读核各小节 → 复扫残留归零 →
  跑门禁分笔提交。这份流程的价值全在**分类**那步：今天有 5 处「27 → 40」是历史事实、1 处「< 40KB」是同数
  不同义（绘制缓冲红线），一并替换就会毁掉它们。
· `mem-budget`：补上 `ram_baseline.py --update`（只往 tsv 追加趋势行）与 `--write`（才同
步台账受管区）的区别、
  以及「提交前台账怎么回填」的动作——这个坑是 Lead 本人 05:0x 踩的（用错一枚参数造出一次真的 mem-budget
  FAIL），写下来比口头转告可靠。
· `task-worktree`：把文中 4 处**自伤**的裸形改成形态描述——该节讲的正是「单字母紧跟数字」这类形态怎么被
  校验 2 计数，结果例子自己就是那种形态，等于技能文自己吃门禁余量。改完不可判定绝对数 **982 → 978**
  （余量 +4），叙述信息量不减：形态与属主都还写清。

⚠ 这条教训值得单记：**文档在讲某个反模式时，自己不要用那个反模式的字面量**——否则每次读它的人都得替它
付余量。同批 `docs/编号规范.md` §4.4 也已登记这类误判面。

自查：`check_ids --strict` exit 0、不可判定绝对数 978 / 上限 1,166；三文件 noBOM / LF / U
+FFFD=0 / 结尾换行齐。
 2026-10-27 09:11:18 +08:00
wandering1 c457da0210 docs(编号): 批次二结果写回规范——存量清点改执行态、护栏不下调、位号误判面登记 
§9 顶部加执行结果表（原清点表保留并**标明是动手前基线**，不然下一个人会拿它当现状）：
· 批次一（登记簿旧号 / 阶段号 / 台架阶段裸形 / 网络条目号）：活文档清零，顺带清 3 处裸形，位号目录整目录排除；
· 批次二（保护功能号 28 个）：代码与测试 215 处 + 文档 194 处 + 配置注释 3 处 + 入口文档 2 处；活文档里该
  族只剩**冻结的变更记录行 40 处**与**一处原始串口日志**（真机抓包证据，改它等于篡改现场 ⇒ 永久保留）；
· 批次三（测试用例族 561 站点）：**未动**，等用户裁定——清它等于换追溯机制，要重写追溯门禁并重打基线。

账面（门禁自身接口实测，非估算）：编号字面量 **8,787 → 7,828**，不可判定绝对数 **1,161 → 978**（上限 1,166，
余量从 5 格宽到 188 格）。§8.1 与 §9 里三处 8,783 同步为终值 7,828（8,783 是批次二中途的读数，留着会让人
以为那是最终态）。

两条口径裁定写进文档，免得下次重辩：
① **不下调 `decidable_ratio_baseline`**：这批删的都是可判定引用，分子分母同缩 ⇒ 比值 86.79% → 87
.46% 是
   **纯稀释**（绝对数反而还掉 183 处）。护栏是**地板不是 KPI**，跟着稀释往下挪等于每次清号都把闸门压下一格。
② **位号与记号误判面**补进 §4.4：位号目录整目录排除（那类 `T1` 是变压器位号）、`N-1` 是傅氏公式求和上界
   （清了会破坏公式）、以及今天新踩到的——**裸正则会把它自己的版本号当成功能号**（某第三方库版本号里
   含形似功能号的片段，实测误报 10 处 / 2 只文件）。清号必须带**左边界**并跳过反引号代码段。

自查：`id-check --strict` exit 0（校验 1~6 无错误）、`doc-links --all` exit 0（198 篇
）、本篇 `--sections-strict`
通过、字节卫生干净；本笔零代码。
 2026-10-27 09:11:11 +08:00
wandering1 0054ae629a refactor(编号): F-* 网络设计条目号转语义说明——批次一收尾，代码注释 43 处 + 文档 9 处 
批次一（不碰门禁即可清）的最后半批，原派道中途失败且**未留任何改动**（Lead 核实那批文件零 diff 后重派
setpage 执行，14 只文件 / 46 处），测试侧与一张生成器共 9 处由 Lead 收尾。

做法：**逐处先读属主文档 §7 速查表里那条的语义**，再改写成「一句话结论 + §指针」，同号跨文件同一措辞，
无一处机械删号（例：`F-NET-7` → 「唯一读者红线（docs/网络/网络自愈架构设计.md §7 I7）」）。属主登记处
**12 条定义行原样保留**、不删登记族（删了历史行会报未登记前缀），只在该章加停发句。

顺带清掉 **3 处裸形**（`T6` → 「台架实测」、`M4-lite`、`Q1` 语义化）——裸形正是 id-check 校验 2 抓的形态，
属净减。测试侧收尾时两条纪律：主机侧**断言字符串必须保持 ASCII**（`ns_s3_msg.c` 等三处的号在 CHECK 文本
里，改成 `sole reader of the global register` 而不是中文）；板端注释可用中文。

生成器 gen_net_instability_svg.py 文案改动 → 同批重跑产物 `docs/images/网络不稳根因总览.svg`：只有那一
行的**框宽随文字自适应**（526 → 551，右缘 1411 未越界），画布 1560x1468 不变，无溢出告警。

⚠ 本笔**只含代码注释面**：该半批的文档面（BSD 函数调用关系 9 处、属主文档 §7 停发句、
生成器与产物那张网络不稳图）已被上一笔 `git add docs tools` 一并收走，两笔合起来才是完整的 F-* 批次。
自证：@build **0 错 0 警**且 Program Size 与改前**逐字节同数**（Code=233900 RO=26104 RW=1
536 ZI=136808，
注释无误伤的机器证据）；net_socket 457/457、iec104_serv / net_pending 两套 exit 0；cppchec
k 钩子参数零
发现、coding-standard 0（lftpd_inet.c 那 4 条是存量且该目录本在钩子 exclude 内，用 HEAD 副本对照
甄别过）。
 2026-10-27 09:05:27 +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 b7c0889cc7 refactor(编号·批次二): 代码与测试侧 215 处保护功能号改成功能名，零行为改动 
用户裁定「不要用字母加数字的编号，语义标识是最好的」后的批次二代码半（道 ui-param 执行，逐文件站点数与
自证见其交付）。唯一口径 = 映射表 ci-artifacts/lprot_map.tsv 的功能名列原文，**零自造同义词**；L2.5 与
L-TEST 经实测各 0 处（不是本族），TC 族一字未动。

固件 22 文件 128 处（adc_task.c 21、phasor.c 22、phasor.h 13…），主机测试 13 文件 87 处（pha
sor_test.c
57…）；设计文档指针新增 19 行，另 16 只文件本来就写着规划文档 ⇒ 不重复加。

**两条只有真改过 215 处才会踩到的坑，都写进注释规范实践**：
· 指针**不能接在原句尾部**——那会替原文一个未闭合的半括号封口，实测咬坏 App/algo/sample_ring.h 这类
  跨行句 ⇒ 指针一律**单独成行**；
· 号删掉会留下**叠词**（「自检失败闭锁 闭锁判定」「定值校验和 定值巡检」）⇒ 复扫并收口 4 处，措辞只用
  映射名本身；具体对象需要留住时写成「自检失败闭锁（采样故障闭锁）」。

自证（不靠嘴说）：改前把 35 只文件原文备份到仓外 temp，逐文件比 `/*`、`*/` 计数、三类括号计数、行数增量
恰等于指针行数、全角括号增删相等、残留号 0 ⇒ **35/35 通过**；Lead 复核后跑权威 @build **0 错 0 警**，
Program Size `Code=233900 RO=26104 RW=1536 ZI=136808` —— **与三条道各自改前改后测的四数逐
字节同数**，
这就是「只动注释与文本」的机器证据；八套主机单测 exit 0，cppcheck 按钩子参数零发现，coding-standard 0。

文件头「修改记录」里的号**一并换名、不还原**（Lead 裁定）：这些号是全仓退役的，留一个查无此号的引用比
留一条改过名的条目更坏——「冻结历史不回改」保护的是**别替历史改口**，不是保护一个再也查不到的字符串；
id-check 对变更记录行本就豁免，两种选择都不影响门禁。
 2026-10-27 08:59:26 +08:00
wandering1 26a97e99f9 chore(门禁): 配置注释里的三个功能号改成功能名（批次二范围内、由 Lead 改的 config） 
批次二（保护功能号转语义名）的范围按写域切给两条道，但 `.pre-commit-config.yaml` 里也挂着三处号，而
配置是 Lead 写域——注释归注释，不占任何钩子行为，改动不影响 YAML 解析的 51 条口径。

· `7h) ADC 采样有效性校验（L1-6）` → 去掉号，条目名本身已完整；
· `7i) 保护定值模型（P1 / L5-1 载体）` → 「定值校验和载体」（P1 同时是 gitlint 规则名的撞形，一并去掉）；
· `规划 §3.3 L3-5` → 「规划 §3.3 过频 / 低频」（按 ci-artifacts/lprot_map.tsv 的唯一口径，未自造词）。

validate-config 退出 0；改后本文件内 `L<层>-<号>` 正则命中 0。其余 219 处代码/测试与文档侧由两条道并
行处理中，措辞同表；`tools/arch_diagram/` 生成器 5 处已转给文档道与三张 svg 同笔（动 docstring 不重跑
生成器会破 generated-fresh——这正是该钩子存在的意义）。
 2026-10-27 08:02:22 +08:00
wandering1 c121eb9773 docs(任务规划): 复核菜单树叶数（42 节点 / 33 叶 / 已绑 21 / 未绑 12）并写清判定方法 
按 ui_menu_tree.txt 用生成器自己的解析器（tools/menu_gen/gen_menu.py 的
parse_tree）重算：节点行 42、叶 33、已绑 #page 21、未绑 12；与生成物
UI_MENU_TAB_COUNT=42、UI_PAGE_MAP_COUNT=21 逐项对上。两份规划文档现有的
33/42/21/12 表述全部成立，故只补判定方法与复核命令，不改数字。

原 §1 写「重算方法见本节末」是悬空引用——§1 末尾并没有这一段。本次补
「叶数判定与复核」子节：节点行定义（非空、非注释行）、叶的缩进判据
（等价 ui_menu_tab_has_children==false）、#page 绑定判据、可重跑的复核
命令与预期输出，并记下三个错算法：把 42 个节点行当叶（多算 9 个菜单）、
grep -c 取 #page= 得 22（文件头注释里的示例字样也被算入）、按叶子名去重
得 29（参数/定值/控制字/软压板 在「整定」「查看」下各一份）。

README §1 同批加方法指针。只改这两份文档，未动代码与生成物，未推送。
 2026-10-27 07:45:11 +08:00
wandering1 13f784430d docs(UI): 内容页黄金参考 40 → 47 页补齐剩余当前态（模拟器 README 与 lvgl-simulator skill） 
上一笔 31ca4a1f 的「全仓同步」漏了几处当前态计数，按实测真值补齐：
simulator/tests/ref/shot_*.bin 实测 47 张、check_content_pages.py 的 PAGES 47 项。

· simulator/README.md 文件职责表「内容页 40 页」→ 47 页
· simulator/README.md 脚本表「③ 40 页无头截图」→ 47 页
· simulator/tests/README.md 文件表「40 页 × 3200 B」→ 47 页
· .dsh/skills/lvgl-simulator/SKILL.md 五步门禁「11 页黄金参考」→ 47 页
  （同一计数的更早残留，一并改成真值）

不改：各文档变更记录里的「27 → 40」历史行，以及 UI_自动化测试流程里
「覆盖当时 40 页中的 37 页」的 2026-10-26 测量口径——当时就是那个数。
零源码改动，golden 参考本体未动。
 2026-10-27 07:43:46 +08:00
wandering1 95beaab313 refactor(编号): 第一批清号——登记簿旧号/阶段号/台架阶段裸形三族清零，位号目录排除 
按 §9 批次一执行。**这批的关键发现是「看着像 62 处编号，实际能算编号的只有一小半」**，所以先分类再动手，
没有按站点数硬清：

· **真·编号（已改名）**：`N-6`（`MDK-ARM/tcp_reconnect_probe.py` 的「TRAP-NET-17 / N-6
」→ 只留 TRAP 锚点
  + 中文说明）；台架阶段裸形 `T0`~`T3` 全部转成场景名——`e11_keepalive_probe.py` 的「静默对端 / 正常空闲存活」、
  `ftp_auth_bench.py` 的「匿名登录 / 未登录直接 NLST / 错口令锁定」、`serial_tool.py` 自检里的「行拆分 /
  解码回退链 / 时间戳行格式 / 端口建议」、`net_test_task.c` 与 `CH395F_Test_Guide.md` 的「空闲存活场景」、
  网络自愈设计里的「三路审计」。另把 `test/host/iec104_master.py` 的变量 `T0` 改成 `t_start`（那是起始时刻
  变量，被裸形族误抓）。
· **不是编号、但被误判（按 §4.4 处理，不改语料）**：`tools/netlist_semantics/` 里的 `T1` 是**网络变压
器位号**
  （硬件知识库），整目录进 `excluded_paths`，与 `docs/硬件平台/` 同口径；`BSD_Socket_API_函数调用关系.
md` 的
  `T1/T2/T3` 是 **Mermaid 节点名**，已改成语义节点（`RetryTick`/`PendTick`/`PendShimTic
k`/`ReconcileTick`）——
  图本身没变，只是节点不再叫字母号；`docs/门禁说明/gitlint.md` 里的 `T2` 是 **gitlint 自己的规则名**（不是本仓
  的号），已改写成规则描述；`docs/算法/傅氏算法详解.md` 的 `N-1` 是**数学记号**（求和上界 `x(N-1)`），保留不动，
  并在 §4.4 登记为「唯一已知误判」。
· **规范自身两处示例**顺手去掉字面量：`S3 / TM-PHY-01 / DP-03` → `S3 / TM-… / DP-…`；「报告 N-
16」→「报告 +
  登记簿旧号」。

结果（用门禁接口复测）：`TM` 族 0 引用、`T-TEST` 族只剩规范自身 2 处示例、`N` 族只剩数学记号 1 处；
`F-*`（38 站点 / 12 个号，代码注释里的网络设计条目号）**留下批单独做**，因为每处要读懂语义、不能替换字面量。

口径变更已写进 §4.4：位号目录 `tools/netlist_semantics/` 进排除面；`N-1` 声明为已知误判。歧义面收窄后，
新错误级仍为 0、`id-check --strict` exit 0。

⚠ 这批**刻意没有复活「别名表洗白」那条路**：`N-6` 这类死号不进 `id_aliases.json`，让门禁继续咬将来的残留
引用（与 FTP 死号同一处理，见 §5.7）。
 2026-10-27 07:39:00 +08:00
wandering1 8bac9869c7 docs(编号): 语义标识定为唯一默认形态，并把「还有多少号可清」写成存量清点与三批计划 
用户原话定了调子：**不要用字母加数字的编号，简直太难以理解了，语义标识是最好的**。本文此前的立论是
「默认不用编号、例外只有 8 族」，方向对但不够硬，而且**有一处真缺陷**——§4.1 那张表自称「穷举」，实测
却发现有四类**仍在用**的族不在表里：登记簿旧号残留（4 站点）、阶段号（1）、台架阶段裸形（19）、网络设计
条目号（38）。自称穷举而实际漏登，比没有表更坏：下一个人会拿它当「这些都可以用」的依据。

本笔四件事：
① 定调改硬：语义标识是唯一默认，编号是**例外**，例外只留「有脚本按字面量匹配」的那几种；
② §4.1 拆两栏：『允许继续发号』8 族（逐条给脚本依赖理由）与『已停发、存量待清』4 族——后者登记未删只是
   为了让历史行不报「未登记前缀」，**不得再新增引用**；
③ 新增 §9 存量清点，数字全部用门禁自己的接口实测、非估算：**26 个族仍有引用、565 个不同字面量、
   1,108 个引用站点**；其中 TC 族 561 站点 / 472 字面量 / 77 文件、保护功能号 184 / 28 / 58、
   TRAP 族 134 / 25 / 51、网络设计条目号 38 / 12 / 20、代码规范条款号 35 / 20 / 13、台架阶段裸形
   19 / 4 / 12、登记簿旧号 4 / 3 / 3、阶段号 1 / 1 / 1；
④ 三批计划按「值不值得动门禁」排序：批次一 62 站点不碰门禁即可清（那四族没有任何脚本按字面量匹配、
   纯人读）；批次二 184 站点把保护功能号改成功能名（「过流Ⅰ段」这类，须按功能逐个改、不能全局替换）；
   批次三 TC 族 561 站点**不是改文本而是换追溯机制**（用例名即标识 + 断言标签改短语），代价是追溯门禁
   重写并重打基线、当天在飞分支全要跟改 ⇒ 建议单开一张卡，等你裁定再动。

§8.1 基线按今日复测重打：784 文件 / **8,787 字面量**（两批清理前 10,956 → 8,230，此后新代码新文档回涨），
比例 86.79%（基线 86.0%）。自查：doc-links --all exit 0（195 文档）、本篇 --sections-strict 通过、
check_ids --strict exit 0、不可判定绝对数 1,161 / 上限 1,166（本笔新增的是可判定引用）；
文件 noBOM / LF / U+FFFD=0 / 结尾换行齐。
 2026-10-27 07:36:19 +08:00
wandering1 d7762b339d docs(任务规划): 通读补齐 UI 清单——叶数口径改对、通讯设置改「配置层已落地」、运行报告写死四数事实 
先认一笔自己的错：上一笔我宣称「实测」得出未绑 21 叶，那是**探针错**——`ui_menu_tree.txt` 文件头自己写着「缩进
即层级」，我把 42 个**节点行**全当成叶子数了。按缩进重判（有更深缩进后继者即非叶子）后的真值是 **33 叶 / 节点
行 42 / 已绑 21 / 未绑 12**，而未绑 12 = 待做 7（通讯设置 1 + 记录 5 + 运行报告 1）+ §5 不做的 5 ⇒ 与分类表
7/3/2 逐项对得上。原文的 33 反而是对的，只有 16/17 陈旧；这条错口径与正确重算方法都写进了 §1，免得下一个人
再用错算法。

§2 与 §3 按已落地事实改写：
· **通讯设置**状态从「未开始」改成「配置层已落地，页面未开始」——`[comm]` 段与端口真源已在
  `App/protocol/iec104/iec104_comm.{c,h}`，服务端口不再抄 `IEC104_SERV_PORT` 字面量，这
一项原本的第①条判据
  已完成；还缺的是页面、「改后重启即生效」的真机判据、配置段数与键数上限核对。§3 数据源表同步。
· **运行报告**把四个数的事实写进完成判据，不给人留含糊空间：复位原因解析有但 **RCC 标志读后即清** ⇒ 需开机快照
  驻留；上电次数**无现成计数器**，正源建议 RTC 芯片的用户 SRAM（电池保持、零 NAND 磨损），**文案禁写「终身
  次数」**、写「自 RTC 电池周期起」；运行时长只有**本次开机内有**，跨开机累计口径**待用户裁定**；104 现有的量
  全是控制量 ⇒ 需新增只读计数与 getter。落点 `App/util/boot_stats.{c,h}` 双端注册同笔，104 计数就近留
  `iec104_serv.c` 不并进。
· §4 生成器入口统一走 `.venv`（并注明 gen_menu 本身只用标准库、字库链才依赖 fontTools ⇒ 指 font-regen
 skill），
  避免下一个人按裸 `python` 跑字库链踩解释器坑。

新增两条防越界的口径：§4 **时基口径未定，勿顺手统一**（面板与 8888 写本地钟面、104 时标写 UTC，后写者赢 ⇒
恒差 8 小时；裁定前不要动 RTC/epoch 语义，也不要把时钟页的「回读 RTC」判据改成按时区补偿，那等于替产品做掉
一个未定的决定）；§5 增列「RTC 时基统一」并写明重开条件 = 用户裁定后作为跨模块变更单独立项。

README 同步同一口径（§1 首段与顺序表第 1 行）。

自查：**净室逐文件注入**（仓外 detached worktree，一次只放一份在飞文件）证明本笔两只规划文档对不可判定绝对数
是 **+0**（HEAD 基线 1,156 → 注入后仍 1,156）；`check_doc_links.py --all` exit 0（195
 文档）、两篇
`--sections-strict` 通过、`check_ids --strict` exit 0；文件 noBOM / LF / U+FFFD=
0 / 结尾换行齐。本笔零代码。
另注：同一轮净室测出当前绝对数 1,156 → 1,161 的 +5 全部来自 `.dsh/skills/task-worktree/SKILL.m
d` 的新增段落
（作者另治，不在本笔、也不由我代改 skill 写域）；`mem-budget` skill 为 +0。
 2026-10-27 07:32:05 +08:00
wandering1 8ae6a6e715 docs(任务规划): 补齐 README §1 的 UI 顺序表——上一笔只改了 §2，留下文档自我矛盾 
我上一笔宣称同步了登记簿，实际只动了 §2 顺序表与开篇那一句，**漏了 §1 自己的表格与叶数**：结果同一份文档
里 §1 写「16 叶 / 5 项待做」、§2 写「剩余 3 项」，读者按哪一节排工都会错。这属于我刚写进规范的那类问题
（文档陈述与仓库真值脱节），而且是**我自己造成的**，所以补一条更正记录而不是悄悄改掉。

本次改正三处，全部按实测：
· §1 首段：33/16/17 换成按行内 `#page=` 的实测口径 —— 已绑 **21** / 未绑 **21**（清单行合计 42），未绑里
  纳入当前执行的是 **7** 叶（通讯设置 1 + 记录 5 + 运行报告 1），不做的 5 叶不变；
· §1 顺序表：删掉已落地的第 1 项（装置维护 3 页，52e28885，真机验过时钟回读与执行页默认拒绝）与第 2 项
  （遥测死区与系数 2 页，48a8ef05，WAIT/OK 双黄金），剩余三项重编为 1 通讯设置 / 2 记录 5 页 / 3 运行报告，
  与 `UI补齐.md` §2 完全同序；
· §2.1 关键依赖的 UI 一句：把「写路径与整定 4 页已收口」补成也含装置维护 3 页与遥测两页（含真机回读判据）。

自查：§1 与 §2 现在同序同数（剩余 3 项）；check_doc_links.py --all exit 0、check_ids --stri
ct exit 0 且
不可判定绝对数 **1,156 未变**（没吃余量、零新增编号）；文件 noBOM / LF / U+FFFD=0 / 结尾换行齐；本笔零代码。
 2026-10-27 07:20:43 +08:00
wandering1 31ca4a1faa docs(计数): 内容页黄金参考 40 → 47 页全仓同步，登记簿剩余项与顺序一并更新 
上一笔 UI 落地时我把「文档计数与真值同源」这件事留在了别人身上（setpage 的移交项写得很明白：内容页 40→47
的全仓计数改写由 Lead 派）。这一笔把它做完，**只改当前态陈述，历史不动**：

· **改成 47 的判据**：simulator/tests/ref/ 实测 47 张 .bin（7 张新增、存量 40 张逐字节零漂移），共 1
6 处当前态
  陈述跨 11 只文件同步——含 AGENTS 的 ui-golden 条目、**钩子显示名**（.pre-commit-config.yaml）
、门禁索引与
  ui-golden 详解的标题与正文、UI 自动化流程的页数与 PASS 文案与快检张数、内容页架构回归段、覆盖率口径的
  「不做 UI 单测」理由、启动自动化流程回归段、导航器脚本 docstring。
· **不改的两处，理由写明**：5 只文件里的历史变更记录行「27 → 40 页」是当天事实，原样保留，只在各文件
  变更记录顶部加一行 2026-10-27 的 40 → 47；UI_界面制作流程 的「< 40KB」是绘制缓冲红线，与本数无关，
  属扫描误报，不动。
· **一处加限定语而不是改数**：UI_自动化测试流程 的「文本断言 310 条、覆盖 40 页中的…」带 2026-10-26 实跑
  日期戳，那是那天的测量口径 ⇒ 改成「覆盖**当时** 40 页」，310 条不臆改，等下一次实跑回填真值。

顺带同步 docs/任务规划/README.md（登记簿销项，用户授权）：开篇「第一项是实现 param_request 写路径、然后做
整定 4 页」早已完成 ⇒ 改为剩余三项「通讯设置 → 记录 5 页 → 运行报告」；§2 顺序表「按 §1 的 1→5 推进」改为
「剩余 3 项按 1→3 推进（原第 1、2 两项已落地）」，与上一笔 UI补齐.md 的销项结果对齐。

三数同源自查：AGENTS 钩子数 51（YAML 解析口径）、内容页 47 页、门禁索引 27 篇均与配置一致；
check_doc_links.py --all exit 0、check_ids --strict exit 0 且不可判定绝对数 **1,156
 未变**（本笔没吃余量、
没新增编号引用）；13 只文件全部 noBOM / LF / U+FFFD=0 / 结尾换行齐。本笔零固件源，不改构建产物。
 2026-10-27 07:16:32 +08:00
wandering1 475885d621 docs(任务规划): UI补齐 销项两项并同步全部计数——登记簿不再与仓库真值矛盾 
这一笔是补一次**该问而没问的疏漏**：AGENTS 把登记簿删行销项列在 Ask first，用户此前只授权过上一批的具体
范围，所以之后两项落地时我只关了看板卡、没动这份执行清单——结果文档与仓库开始互相矛盾。本次按用户指示做
全量销项 + 同步计数。

删掉的已完成行：装置维护 3 页（48a8ef05 之前的 52e28885，真机验过：时钟页按回读 RTC 出真判据、清除与强制
复归默认拒绝）、遥测死区与系数 2 页（48a8ef05，三态用脏位、WAIT 与 OK 各一张黄金）。§2 剩余三项顺次重编为
1 通讯设置 / 2 记录 5 页 / 3 运行报告，开篇指针同步改成「从第 1 项通讯设置开始」。

同步的真值（不再抄旧数）：菜单树按行内 #page= 实测**已绑 21 叶 / 未绑 21 叶**（清单行合计 42），页面映射
UI_PAGE_MAP_COUNT = 21，内容页黄金 47 页；旧写的 33/16/17 是两项落地前的数，已注明覆盖来源与重测时刻。
§1 分类表删掉「数据源已就绪 5」这一类（已做完），§3 数据源表删掉那 5 页已完成行；§1「这些基础当前没有完整
页面消费者」一句也已改成真话——ui_data 现在有四通道，装置维护与遥测两批已经把这套基础接上了真实消费者。

依赖关系一节没有直接删掉旧判据，而是把它们**留成后续项沿用的口径**：执行类页面不得做成「点了个按钮但没效
果」；清除记录必须按 syslog_clear_state() 出真反馈；三态区分「已受理」与「已落盘」，黄金必须出 WAIT 与 OK
两张（假件保留脏位、只由 headless pump 清），否则真机的 WAIT 态永远不会被像素回归覆盖。

自查：check_doc_links.py --all exit 0（195 文档、2,673 处章节引用、无法判定 0）；本篇 --section
s-strict 通过；
check_ids --strict exit 0 且不可判定绝对数 **1,156 未变**（本笔没吃余量、没新增编号引用）；无 BOM / LF /
U+FFFD=0 / 结尾换行齐。⚠ 全仓其他文档里「内容页 40 页」那类计数仍是旧值，属 task-39 同族的独立改写，不在本笔。
 2026-10-27 07:02:06 +08:00
wandering1 d286b69a2d chore(工具,文档): 台架 rc 语义与导航硬闸用例、门禁环境诊断、护栏还债算法、mem-budget 跨树口径 
四条道的收尾件同笔（全是 python 工具与文档，零固件源；各段归属按道署明）。

· **台架（bench-runner）**：verify_log.py 新增 classify_measurement() 与 measureme
nt.* 字段，零行/零锚点
  判 exit 2 并打 [MEASUREMENT-BROKEN]，**但同帧有 Forbidden 命中或自检故障仍判 1**（专门造了「零锚点 +
  [ERR] MEMFAULT」的陷阱日志实测——崩溃不许被降级成「没数据」）；--selftest 16 → 22 条。board_ui_nav.py
  把两条执行页安全闸做成 7 条常驻用例接进提交钩子跑的快检档，作者把自己用例**证伪三轮**（测试强制上限、
  清单清空时是崩不是判定、出厂默认被翻允许也照样绿）后三条危险改动逐条能红。台架卫生清单落 §7：每圈复位
  前 open + 断言 ready + 看 rx 增长（今晚 daemon 死了 status 自愈把它遮住）、**Forbidden 令牌不得落在
  英文单词内部**（裸 Fault 命中 default 两次假红）、改判定语义前先 grep 消费者。
· **环境（ui-param-writer）**：证伪卡片前提两处——identify 那个版本根本没有 tags 模块（RECORD 与磁盘逐项
  一致，pre-commit 自己也从 identify.identify 取 ALL_TAGS，全仓零引用），真问题是 44 条 system 钩子里
  42 条 entry 用裸 python → PATH 首位那个零第三方包解释器，今天没炸纯靠两件事同时成立。交付是**新增 entry
  硬规则 + 修复死顺序与回滚并标注等静默窗口**，没有动共享环境（此刻重装会让别人的钩子在半途换解释器）。
· **门禁（gate-docs-fixer 已入库的 51 号钩子）**：本篇带上 host-unit-tests 的裁定句落点说明。
· **内存（comm-config-writer）**：mem-budget skill 补跨树测量身份口径（脚本按 __file__ 定位产物、什么才算
  一次新测量、多链同涨同一数值的共享帧/幻影环归因法）+ 看门狗说明的指针行。

实测：verify_log --selftest 22/22、board_ui_nav --selftest-quick rc=0（硬闸 7/7）、
doc-links --all exit 0、
check_ids --strict exit 0 且绝对数 1,156 **未被本笔吃掉**；全部文件 LF / 无 BOM / U+FFFD=0
；本笔零固件源,
随上一批权威构建验证过（0 错 0 警），故不再单独 @build。
 2026-10-27 05:16:58 +08:00
wandering1 f1d0b5c2d9 docs(规范,门禁): 卷锁五态去裸形——本仓第一次真正还第二根护栏的债，并写清还债的算法 
最反直觉的是结果里的差值：36 处裸形态号全部清零，绝对数只从 1,162 降到 1,156（−6，余量 4 → 10 格）。
作者没把差值糊过去而是查到底：check_ids 只在字面量**落不进任何已登记族**时才计不可判定，撞进已登记族的
23 处本来就记在可判定侧，删它们分子分母同缩、比例反而从 86.74% 涨到 86.77%；真正在盲区里的只有族外
7 处，其中 1 处还被变更记录行豁免 ⇒ 账面 −6，算式对平（±1 属同窗别道在飞）。**这四条机制我写进
docs/门禁说明/id-check.md §6.10 并署名作者**——它是「怎么还这根护栏的债」的第一份操作口径。

改动面：App/fs/vol_lock.c 10 处、.h 6 处、vol_lock_test.c 14 处、卷锁单元测试说明.md 3 处 ⇒ 同口径
改后 0 处。四态语义只留 vol_lock.h 的 vol_lock_stats_t 注释一处，其余三处只描述断言并指回头文件，
不抄第二真源。除 4 行声明外全是注释文字，代码行为零改动。顺带消掉一个**同形两义**的撞号源。

实测：1,162（03:15:08）→ 1,156（03:21:56），写变更记录后复量仍 1,156（本笔没吃余量）；--strict exit
0；vol_lock 套件 45/45；**上限未动、刻意不跑 --update-baseline**（作者反对成立：重锚会把只减不增的线
按这次 −6 重画，白丢一次真还债的账面记录）；未改 id_registry.json / 台账，未跑 --all-files。
 2026-10-27 05:14:11 +08:00
wandering1 b1494eb10c feat(固件): 标定值语义 setter + 卷锁 fail-open 自检留痕 + 控制台编号写法整理 
三批同笔的理由：它们是同一份权威构建（Linker run 04:5x，Code=233,900 / RW=1,536）里的内容，中间态从未
单独编译过，拆开提任何一段都没有对应的构建凭证。按道分述如下。

**① 算法层（ui-maint）：写值与置脏成对，不留可单独调用的置脏口**。新增 run_par_cal_k_set() /
run_par_cal_b_set()，被拒时副本不动也不置脏（= 不承诺持久化）；104 的 run_par_104_write() k/b 两支
同批改调 setter，函数内自己碰 s_dirty 的两处删净——**消除两份置脏逻辑才是本段的目的**。刻意**没有**新增
公开 run_par_mark_dirty()：作者的理由我采纳并原文保留——「一旦存在就一定有人只调它」，与今天删掉的零消费
者接口是同一失效机理。另新增合法域唯一出口 run_par_db_range()、粗守上限 RUN_PAR_K_MAX_UV、毫→工程换算
单点 s_milli_to_eng()，并改正了头文件里「除以 1000 唯一在此」那条在加 db_range 后会变假陈述的说法。
**顺带满足 task-43 第①项**：adc_cal 落盘口的缺口由本段 setter 解决（写值必置脏），task-43 剩余项 = 可诊断
性与文档。

**② 日志层（log-maint）：卷锁 fail-open 的 defaultTask 侧边沿留痕**。syslog_drain() 尾部紧跟既有
s_quiet_
drop 差值块之后读 vol_lock_get_stats()，水位新增才算一个 episode、每上电一条，投 SYSLOG_SELFTEST，文本
vollock failopen=%lu。三条硬约束都落了且**有牙**：失败调用点零改动（wdev.log 自己也要这把非递归卷锁）；
不打错级、**不打 [ERR]**（断言里 g_sys_err_count == 0 就是机器判据，把「改成 DBG_ERROR」注入后四条用例
全红）；锁层只自增、唯一写者消费。作者一度按我的要求准备造 obs_first_ms/obs_last_ms 字段，我撤了那条
要求——记录自带 ts 就是被观测时刻，**再造一个时间戳字段等于造第二个「看起来像发生时刻」的东西**。
成本 .bss +48 B、**零栈增量**（缓冲全静态），已由本笔权威构建的 after 表证实：9 条链全 PASS，
iec104Task 1,464 / margin 1,096、defaultTask 3,040 与提交态逐项一致。

**③ 控制台与中断（log-maint，纯注释/文档）**：b623a406 之后的编号写法整理，把裸形态号改为可校验形式，
零代码行为改动。

实测：@build 0 错误 0 警告；run_par 67/67、sys_log_mcu 141/141、console_log 套件零回归
覆盖率只增不减
（sys_log_mcu.c 410/413 = 99.3%、函数 22/22）；cppcheck / coding-standard /
doc-links / bom / mojibake /
nested-comment 全 0；编号五项式错误差值 0、不可判定绝对数 **1,156**（上限 1,166 未动，本笔没吃余量）。
台账随本笔回填：ram_baseline --write 与 mem-numbers --write 同批（RW_IRAM1 80,920 B 61.7%
/
RW_CCM 57,376 B 87.9% / ER_IROM1 260,004 B 24.8%）。
 2026-10-27 05:10:11 +08:00
wandering1 48a8ef0564 feat(UI): 遥测死区与系数 2 页——注入表第四张、三态用脏位、WAIT 与 OK 各出一张黄金 
这两页是「UI补齐」里唯一带**持久化语义**的一档，所以整笔的设计重心不在画面上，而在**页面如何诚实表达
「已受理」与「已落盘」**——这一点由 setpage-scout 在开工前的只读查实钉下来：cfg_file_save() 全仓唯一调用
者是 run_par_store_save()，而 default_task.c:246 **每轮无条件**调它、函数首行 s_dirty==0 就直接返回
⇒
落盘动力本来就在 defaultTask，不在 104 会话、也不在事件位。因此本笔走 A2（UI 不当授权写者），不需要
新事件位、不需要新同步口。

页面三态判据 = run_par_dirty_peek()：ENTER / WAIT（脏位仍在 = 已受理未落盘）/ OK（脏位归零 = 整档已外科
保存成功）/ 写被拒 = ERR。两条限制写在页面注释里没藏：脏位是**整档全局**的（一趟落 [run_par] 9 键 +
[adc_cal] 两段，归零只证明「这一档落盘了」，不证明「我这一项单独落盘」）；他人随后再改会重新置脏 ⇒ 沿用
clear/clock 页的结果锁存，把「我这次动作的结果」与「档位此刻的状态」分开。

**为什么黄金必须出两张**（这条是本轮最有价值的防假证据规则）：模拟器假件**保留脏位**、全仓唯一的
s_yt_dirty=0 写点是 sim_yt_pump()（setter 只置不清），于是 WAIT 与 OK 各出一帧——两组同键序、唯一差别是
EXTRA 里的 --yt-nopump。若假件同步清脏位，真机的 WAIT 态永远不会被像素回归覆盖，黄金就成了「只钉住最
好看那一帧」。TC-UIDATA-028o 另钉住 ui_data 层零缓存。

形状：新增 ui_data 第四张注入表（八字段整表校验、拒残表），实现落在装配层 App/app/ui_data_feed.c，
页面零 App include（分层方向 + 模拟器不链 run_par 两条老理由都成立）；共用视图模型 ui_w_ytview 承载两页。
合法域一律由执行侧出口给（run_par_db_range / RUN_PAR_K_MAX_UV），页面不抄第二真源——系数页 v1 只用粗守
并在注释写明两层守卫互不掩盖，µV/码 ×[0.5,2.0] 那条真带的出口器归 task-43，**没有**在页面里抄常量。

取舍与遗留（如实）：系数行 d=0 整 µV（1e9 装不下两位小数，注释写了「要小数改哪、不收紧假上限」）；b 覆盖
无口未做；徽标只画系数页；行名因「率」缺字改为 Hz死区（font-charset 机器先抓到的，不是我目测判的）。

实测：@build 0 错误 0 警告（Code=233,900 / RW-data=1,536）；ui_data 单测 277/277、run_par
67/67 零回归；
内容页黄金 47 页全过、**存量 40 张逐字节零漂移**（git 里只有 7 张新增）；menu_rows / 池水位 / font-charset
/
bom / mojibake / nested-comment / cppcheck / coding-standard / layer-deps /
bsp-err 全 0 新增；编号五项式
refs 8,778 / dec 7,622 / und **1,156**（上限 1,166）/ 比值 86.83%（基线 86.0% 之上）/ 错误差值
0，注释零裸形
字母+数字。generated-fresh 与 registration-check 本地 PASS；新增 6 只源文件按规矩**双端注册同笔**（叶子
+
registry 19→21 + uvprojx + CMakeLists），uvprojx 这次属「真的增删源文件」才入库。

移交三条不混进本笔：① 全量 --selftest 现 exit 1 是 task-41 硬闸在模拟器上也拒 reset/clear（既有红，快检档
不受影响），归台架道定夺；② 内容页 40→47 的全仓文档计数改写由 Lead 派；③ run_par_deadband_set 的限定
条件语措辞（「iec104Task 上下文」已被装配层裁定覆盖）归算法层下一笔。
 2026-10-27 05:07:18 +08:00
wandering1 1d39571114 feat(门禁): 第 51 条 nested-comment——把 ARMCC #9-D 的按包含者刷屏拦在提交前 
动机是今天一天复发三次的同一形态：在块注释里写作用域路径，那个 `/*` 被 ARMCC 当第二次注释起点（诊断 9-D），
而且**按包含者数量刷屏、只在重编译那个 TU 时才暴露**——本仓的诱因就是「注释里写 Drivers/BSP/UI/**」。
AGENTS 早就写了这条铁律（写全目录或用尖括号），但它一直是纯口头纪律，所以同一天还是复发三次。

新脚本 scripts/check_nested_comment.py：纯标准库、只读、五状态机（代码 / 行注释 / 块注释 / 字符串 / 字符
字面量），**只有块注释体内的 /* 才算问题**——字符串里的、行注释里的、未闭合判定都不误报。口径上刻意与钩子
的 types: [c] 对齐（403 个 .c/.h 同面），避免「手跑面 ≠ 提交面」这类我们今天就踩过的错位；零第三方依赖是
刻意的，为了让 generated-fresh 那天的解释器假红不长第二遍（实测 .venv 与机器级 C:Python314 两种解释器结论
一致）。

存量口径：全仓实扫**新发 0、存量 2 处**（test/host/common/ch395f_fake.h:7 与 fatfs_fake.h:9，同一形态
「注释里写作用域 test/host/**」）。两份假件头不参与 MCU 构建所以今天不报，一旦被 include 进板端 TU 就会
按包含者刷 9-D——属 test/ 写域，作者**没代改**，而是钉进 BASELINE 走只减不增，**其余零豁免**。

自证有一条必须写清的诚实边界：作者想「拿旧字节回放今天那三处真复发」，实测**做不到**——近 150 个提交里被
改过的 281 份 .c/.h 旧字节**零命中**，因为那三处同类从来没有一处在 HEAD 里留过字节（全靠人工编译后清掉）。
于是改测**形态**（这是能证的部分）：10 项形态电池 10/10，含把已入库的尖括号写法退回星号形态 → 命中 1 处；
另用现存两份真字节做双跑：空基线 → 2 条 [NEW] + exit 1，加基线 → exit 0，证明**基线只决定算不算新的，
不掩盖有没有**。编译器侧原文（run_par.c(267) #9-D）冻结抄进新文档 §2.1——构建日志每次 @build 被覆盖且不入库，
所以文档里刻意没写「最近一次日志里仍有」这种会过期的话。

计数三处同批：AGENTS「共 **51** 个钩子」、门禁索引「51 个 hook → 27 篇 + 1 指针 + 1 外置」、配置声明；并记
文本 grep「 - id:」= 52 的成因（第 65 行被注释掉的 clang-format 候选），收紧行首口径 = 51。作者顺带自打了
一次：在配置注释里复述了那个 grep 字面量 → 文本计数当场虚高 1，已改写并把「配置注释里别复述字面量」写进
README §2 与 AGENTS。

同笔带上 task-28 的裁定句（AGENTS 一只文件里两卡改动天然混在一起，拆开会多两次改写与一次风险）：不补第
23 根 ui-sink 专属钩子——22 根的唯一意义是秒级归因，而 ui_sink 失败面全落在 test-coverage 总闸必跑路径、
失败照样拦；读「这套跑没跑」去看总闸输出，别数钩子。

实测与本笔自查：validate-config = 0；nested-comment --selftest 4/4、--all = 403 / 新发 0 /
存量 2 → exit 0；
doc-links --sections-strict（4 篇）= 0；gen_task_table --check = 0；generated-fresh
PASS（5 处存量走 WARN）；
check_ids --strict exit 0，**不可判定绝对数全程未被本闸吃掉**（作者开工 1,162、写完新闸与新文档仍 1,162；
现 1,156 是队友还清的）；全部改动文件 noBOM / LF / U+FFFD=0。未跑 pre-commit --all-files（只跑本闸）。

**本笔使用 --no-verify 的凭证（唯一允许的两条之一，按 MEMORY 台账例外口径）**：把本批 6 只文件单独
staged 后跑 `pre-commit run --files <这 6 只>` → **13 条 Passed / 1 条 Failed**
唯一失败的是 `mem-budget`
（RAM 92% 阈值，**全树检查**）。本批**零固件源、零 .map 变更**，该红来自其他队友在飞的固件改动造成的 .map
漂移（当前树 Code=231,952 / RW=1,528 / ZI=136,264，在库台账 231,712 / 1,504 / 136,216
差 = run_par setter
与 vol_lock 计数两笔，均未提交）；台账回填由我在树能编后统一 `--write`，不在分支上跑（避免多分支同改受管表）。
gate: only mem-budget pending lead ledger backfill。字节卫生本笔自查：6 只文件均 noBOM / L
F / U+FFFD=0，
新脚本纯 ASCII 输出路径无关，AGENTS 与索引两处计数与配置 YAML 解析口径 51 一致。

另收一条今天反复出现的元教训（Lead 与作者各错过一次、方向相反）：**`pre-commit run` 与 git 钩子不是同一根
探针**——config 处于 modified-unstaged 时只有后者 [ERROR] 拒绝，前者与 validate-config 都 Passed
。它与「stash
只覆盖已跟踪未暂存」「未跟踪文件永不进 stash」同族：手跑的探针不能替真提交的探针作证。
 2026-10-27 03:44:18 +08:00
wandering1 9a231831bc test(台架): HEAD 固件仅复位 4/4 全绿——两条曾被啃的行逐字节完整，并拿修复前归档反证 
这是今天第一份**硬件侧**证据（此前所有绿色都只到静态与主机侧为止）。身份按新口径钉：
以固件身份戳为准、SHA 只当坐标——**fw build: Oct 26 2026 22:52:09 suite=NONE dstr=off**
（坐标 HEAD b24b2b5f；该像与在库固件源同一棵树已由两条机械判据证过）。

计数严格按两句并列，不合并：**烧录启动 1 次**（00:25:06，@test rc=0，不进仅复位序列）+
**仅复位 4 次**（01:46~01:52，serial gen 273→276 单调递增，逐圈自证窗口不重叠、零重烧），4/4 PASS：
· [ERR] / CONSOLE dropped / 任一 Fault 令牌 / ERROR / assert 全部零命中；
· 两条历史受害行逐字节完整：[PROT] 91 px、[NAND_FTL] 56 px（行首 '[' 齐全、loose_neighbours=0、
  head_bad=0）——这正是「未注册期裸发丢行首」那一类缺陷的正面判据；comm init 57 px；
  prot set loaded ×4、CORRUPT ×0；boot→net init 733~786 ms；
· **反证**：同一把尺指向修复前归档 → rc=1 FAIL 并打回缺行首的邻居 ⇒ 四个 PASS 不是空跑；
· 锚定用的是仓内 verify_log.py --exact（b1280e3c 并进的那半，今晚第一次自用）；
· 堆与栈：heap free=15624 / min_ever=8464 与 task-30 逐字节相同；ui 峰值 4188 四轮内部零摆动、
  与上轮 max 持平（按 task-32 未定稿口径只报数、不做单次比较）；
· -CmpFile 排在全部采集之后（它会导致目标复位）→ No difference found。

**执行类页面的硬闸在真机上证死了**：--to clear / --to reset 在下钻前就拒绝（非零退出、连轨迹
文件都不生成、理由文本点名「第二次 ENTER 即真执行」）；--to clock 正常到达（9 步，ENTER 全落在
菜单上下文），时钟页渲染无缺字白框（年月日时分秒与页码行全显）。帧与判定已归档。

作者自报两次测量错误（都不是板子的问题，也都没有产出假绿，处理方式正是本仓要的）：
① 01:34 头一圈采到 0 字节。根因在测量侧：**常驻 serial daemon 已经死了**，而 serial_tool.py 的
   status 会自动拉起一个新 daemon，于是它一直「正常」地报 port.ready=false / rx_lines=0、日志只剩
   58 B——**status 的自愈把端口是死的这件事遮住了**。已立口径：每圈复位前 open + 断言 ready + 观察
   rx_lines 增长，不假设 @test 留下的端口状态能过夜。该圈按两条独立理由排除（前面有烧录、实际
   零字节），不进任何计数。
② 我自己加的 Forbidden 令牌 Fault 是**假红**：子串命中 de**fault**，打到 factory default password
   与 [STACK] default peak_used。已换成显式故障令牌（四个 Fault 本来都以 [ERR] 开头，裸 Fault 只是
   噪声）。这条口径移交 task-32：**Forbidden 令牌要短到不落在英文单词内部**。

一条观察移交（不下结论、不属台架职责）：装置墙钟显示 2026-10-26 18:00:35，而主机记录是当日
01:5x +08:00，固件日志时标与 daemon 时标也恒差 8 小时——**RTC 与 UTC/本地时区的语义归谁**由 Lead
路由（已立案，见 task-44）。

归档物：boot_log_data 下 20261027_bench42_{reset_only_boots_r1_r4,verdicts}.txt
与 _ui_clock_page.png；
README 台账行按新口径书写。编辑 README 前重读、编辑后复核：其他两条道的「证据可达性」规则与 §2.1
都还在，无 BOM / 无 U+FFFD / LF。
 2026-10-27 02:29:10 +08:00
wandering1 563737f39c docs(规范): 立两条协作纪律——归因必须带可复核证据、注释必须陈述事实而非意图 
§2.4 讲的是「抢跑之前自己该跑哪些等价门禁」，那一节管形态；这一节管另一类钩子拦不住的东西：
**归因与陈述的正确性**。今天一天里，这类错误造成的代价不比任何一个编译错误小，所以四条规则
每条都配着当天真实发生过的一次返工：

1. 数字必须钉产物身份（路径 + 构建/运行时刻）；**重跑同一个报告脚本不算新测量**——产物没变、
   数字必然不变，写成「我复验过」就是假凭证。附带本仓实测坑：stack_report.py 的 REPO_ROOT 跟着
   __file__ 走，cd 进别的 worktree 跑主仓脚本量的还是主仓产物（今天就栽过一次，据此错怪了一笔
   清白的提交，公开更正了两次）。
2. hash 不是稳定身份，tree + 父提交才是；出回执前先核 reflog，**先请人按 hash 复算、自己再重写
   hash** 是顺序错误（今天真发生过，让队友的回执一出生就过期）。
3. 归因前先确认数字来自哪棵树、哪一次运行——并发时序不是谁的错。当天把「文件 mtime 晚于构建」
   误判成某个道「删实现后注册」，实际只是两条道同时在写、构建读到中间态；更正时两个道都点到名。
4. 「我核过」不等于机器核过：「6 个文件 BOM 逐个核过」被 bom-guard 证伪；自写扫描脚本报「0 处
   嵌套注释」是脚本自身 bug 的假绿。结论必须附可复跑的命令与退出码。

同族第二条是「**注释与文档必须陈述事实，而不是意图**」：ui_data_maint_ready() 的头注释写着「页面用
它决定这页能不能操作」，而页面从没用过它（全仓零消费者）。它解释了为什么假接口能活过一整轮评审：
**评审读意图陈述，门禁读可达路径，两者都不反驳「意图未实现」**。写法要求与机器兜底的分界也写清了：
死代码有 bsp-err 的 consume-result 与覆盖率总闸兜，**意图陈述没有任何钩子能证伪**，只能靠写的人，
所以才必须落在文档里。

自查：check_doc_links.py --all exit 0（186 个文档）、本篇 --sections-strict exit 0（新增引用全部写成
可校验形式）；check_ids.py --strict exit 0，不可判定绝对数 1162 **未变**（本笔没吃余量、没新增编号）；
字节卫生 bom=false / CRLF=0 / U+FFFD=0 / 结尾换行齐，新增行最长 79 字符。

看板：本笔收口 task-35。其余任务仍在五条道手上，我只暂存本篇。
 2026-10-27 02:06:14 +08:00
wandering1 c90380bf9c docs(门禁): 拆开「不可判定绝对数」的真实构成，并写下每批自证没吃余量的做法 
起因是今天下午我自己给三条道下过一条错指令：「编号余量只剩 4，别新增 TC 号、优先用母号加小写子项」。
刚才用检查器自己量了一遍，**那条指令的机制是错的，而且方向危险**：

  refs_total 8,744 − decidable 7,582 = 1,162，逐项拆开精确闭合、无第四类：
  · skip_bare_unmanaged 834 —— 裸形盲区（同字母多义的裸号出现在属主登记处之外，§6 明令不判）
  · noise_allowed        326 —— 命中 id_registry.json 的 noise_literals 白名单（不是编号
形态像）
  · undecidable            2 —— 真·硬不可判定：族还登记着、属主登记处已空（清号批次遗留）

也就是说这 1,162 里约 99.8% 是**设计上的豁免**，而带属主登记处的族无论加多少引用都是「可判定」，
一点不吃这根护栏。更要紧的是：我那条指令会把人推向「把编号改写成语义短语/散文」——**那恰好是
§7.6 加这根绝对数护栏要防的稀释**（比值会被清号动作稀释，绝对数不会）。等于我让团队去撞自己立的闸。
指令已向五条道撤回，并写进新增的 §7.7 第 3 条读法里，免得下一个人再走一遍。

§7.7 同时把「每批自证没吃余量」写成可复制的五项式：改前先记三个数 → 改后逐数比对（⚠ --strict 只
回答有没有新错误级，不回答可判定占比动没动，不能当替身）→ 若涨了用 git show HEAD:<路径> 取临时副本
或开一棵 worktree **只回退自己名下文件**再跑同一扫描器（明令禁止用 git stash / checkout 回退，那会
把别人在飞的改动一起收走，本仓同一天刚为此踩过）→ 报告写全 refs/dec/und/比值/错误 五项差值，
不许只写「跑过没问题」→ 真还掉一块后用 --update-baseline 同步下调上限（脚本自己拒绝上调；
手工调高上限等于自废这道闸）。

另澄清一处容易误读的地方：本文件打印的「校验 1 未登记前缀：0 处」与这 1,162 不矛盾——校验 1 报的是
**新增错误级行为**，护栏统计的是**分母水位**，一个是行为一个是水位，别互相替换。

实测与本笔自查：check_ids.py --strict exit 0（可判定 7,582/8,744 = 86.71%、不可判定绝对数 1,162
**未变**，本笔没吃余量，也没新增任何编号引用）；check_doc_links.py --all exit 0（186 个文档）；
本篇 --sections-strict exit 0（新增引用一律写成可校验的紧邻形式：docs/文档规范.md §3.5，并把草稿里
指向不存在的 §5.2 改对——编号规范只有 5.1/5.3/5.5/5.7）；字节卫生 bom=false / CRLF=0 / U+FFFD=0 /
结尾换行齐。裸形与噪声样例没有写进正文（[示例] 行虽在进分母前就豁免，但把野形态抄进文档没有收益）。

看板：本笔收口 task-34。其余在飞任务由五条道继续，我只暂存本篇一个文件。
 2026-10-27 01:59:28 +08:00
wandering1 b24b2b5f31 docs(计数): 内容页黄金参考 27 → 40 全仓同源改写，含钩子显示名这最后一处不同码
CI / L0 静态门禁 (pre-commit) (push) Failing after 49s
Details
CI / L0.5 主机侧单测 (MSVC) (push) Failing after 45s
Details 
UI 三页落地后机器真值变了，文档却还写着 27 页——这不是笔误，是会骗人的现在时。
作者（batch-auditor）先自己从机器面取数再动笔：git ls-files 里 ref/*.bin = 40、
PAGES 40 项、TEXTS 37 页 310 条、ABSENT 16 页 29 条、池 5448 B 与常驻堆 5368 B 未变、
字库 183 字未扩。**它还纠了我一个数**：我报 ABSENT +19，实测 11 → 29 = +18；作者按
实测写文档，并且不在文档里写 ABSENT 总数，免得把我这个差 1 的数固化成第二真源。

改写面（现在时陈述，共 12 + 3 处）：AGENTS.md 的 ui-golden 半句、门禁说明 ui-golden.md
（标题与「拦不住什么」段）与索引行、simulator/tests/README.md、simulator/README.md 两处、
UI_自动化测试流程.md（310 条 / 40 页 / PASS 文案 / 覆盖面）、内容页架构.md、页面补齐规划.md、
主机单测覆盖率口径.md、自动化测试流程.md、测试开发标准流程.md，外加
.pre-commit-config.yaml 里 ui-golden 的显示名——那是「声明 / 文档 / 实跑」三数同源的最后
一处不同码：AGENTS 与门禁说明都已 40，配置里还写着 27。

两条纪律作者都自证了，不是口头：
· **历史数字一律保留**：8 处变更记录行里的 27 / 242 / 24 / 11 原样未改；两处带日期的
  验证记录只加限定语（「该下限此后已扩至 40 页，双次逐字节一致需按同口径重跑回填」），
  没有把 27 改成 40 去造连续性。
· **同名不同义的数字不许全局替换**：页面补齐规划.md:12 与 :157、页面扩充详细方案.md:649
  里的「27」是**空叶子口径**，与黄金参考数无关——三处故意没动。这条比改对更值钱。
· 余量自证（回退名下 12 文件复跑同一扫描器）：refs +0 / dec +0 / und +0 / 比值 +0.00pp /
  错误 +0，本笔零消耗，也未新增任何编号引用；simulator/tests/ref/ 下 40 个 .bin 零改动。

闸线现状照实挂着：id-check 不可判定 1,162 / 上限 1,166，**余量只剩 4**（吃进者是今天
UI 那笔的注释引用，账在 Lead）。清账之前任何人新增编号都可能直接撞闸。
 2026-10-27 00:16:07 +08:00
wandering1 ac9ca33f0f fix(台架脚本): 导航器加两条硬闸——执行类页面默认不进、未知屏 ENTER 最多一次 
bench-runner 在给 UI 窗口做准备时报出一条**三段叠加就会真执行破坏性动作**的路径，
而我就是其中一段的作者：496b4dc5 把 e 放进 UNKNOWN 屏的回退键序（当时的动机是真的
——本机待机态按 s/l 无效，冷启动落在待机态时闭环导航直接开不了工）。叠加面在这里：
· 导航器每进一个叶子就发一次 ENTER，且会替「查看密码」自动确认；
· 装置维护的 强制复归 / 清除记录 已进菜单树；
· 这两页是**两段式确认**——第一次 ENTER 只把该行标成「确认?」，第二次 ENTER 就真的
执行（复归全部保护动作位并写 SOE / 清 SOE·运行·操作记录）。
单个 ENTER 安全，但**同一屏上第二次 ENTER 不安全**；而退避键序是循环消费的，第一次
按 e、第四次又按 e。更要命的是：新字库缺字、白框、状态行变化恰恰最容易让页面被判成
UNKNOWN——那正是我们最想在 UI 窗口里抓的东西。**越是显示异常，越容易被脚本按执行**。

两条硬闸（不改任何固件、只动这一只台架脚本）：
① to_root() 内 ENTER **最多按 BACKOFF_MAX_E 次**（默认 1）；还需要第二次就当场报错
停机、并把 dump 的帧留在盘上，而不是把第二个 ENTER 投出去。报错文案直接点名执行类
风险与放行方式（改用无 ENTER 的键序 --backoff-keys sl）。
② 执行类页面 EXEC_PAGE_IDS = clear / reset **默认拒绝下钻**；确有真机需要才显式加
--allow-exec-pages，且运行时打印警告。要看这两页的显示正确性，正路是模拟器黄金参考——
同一份 UI 源码、零真机副作用。

通用口径一并写进文件头：**导航类自动化脚本默认零 ENTER**，ENTER 只允许出现在明确
指定的、非执行类的用例步骤里。「靠按 ENTER 从未知状态脱身」这个前提本身就与执行类
页面冲突，不该由脚本替你承担后果。

行为验证（假设备，绝不连真机、绝不注键）：clear / reset 均被拒且理由含「真执行」；
clock 不受该闸影响（走到设备层才失败）；持续 UNKNOWN 的循环实际按键序列是 e-s-l 后
在第 2 次 ENTER 前停机，实测 ENTER 计数 = 1 = BACKOFF_MAX_E，报错理由点名执行类风险。
5/5 通过；py_compile 通过；--help 可跑。临时脚本没留在仓库里，__pycache__ 已清。

另两处纯计数更正（与文档道 task-39 同批真值：黄金参考 40 页）：本文件 selftest_refs
的 docstring 27 → 40；.pre-commit-config.yaml 里 ui-golden 的显示名 27 → 40（这是
「声明 / 文档 / 实跑」三数同源的最后一处不同码）。
 2026-10-27 00:13:41 +08:00
wandering1 41c277a8ae docs(门禁): 抢跑等价门禁自查表落地——把「谁漏跑一次，这道检查这次就不存在」写死 
今天三次 --no-verify 共放过三类真问题：5 条 CODE-RULE-17（.c/.h 配对）、2 个缺尾换行加
1 个漏提文件（HEAD 一度是「代码已整行独占、旁边 runner 文档串还写着无锁直发」）、
以及共享尾段 +80 B 把 iec104Task 压到 1,024 B ISR 底线之下。根因不是「不该抢跑」，
而是**抢跑时只跑了部分等价门禁**——doc-links、id-check、字节卫生都跑了，唯独漏了
stack_report，而它恰恰是数字与安全边界那一类。

§2.4 三组清单（任何人可用，不是 Lead 特权说明）：A 抢跑前必跑（stack_report、
ram_report、ram_baseline --gate 含「跳过不等于有余量」、coding-standard、bom-drift
含「别用有 BOM 就是错的外行判据」、mojibake、受影响模块单测、test-coverage、id-check、
doc-links、generated-fresh 必须 .venv、ci_local 并注明它**不含** stack_report 与
ram_baseline 所以不能当替身）；B 手跑代替不了真提交的三类（改写型钩子、要靠 stash
才能正确归因的、只有真提交才碰到的 gitlint 与正文每行 80 列）；C 抢跑之后：
git show --stat 对交付清单 + git status 里不该再出现声明过的文件（含 ??，漏提 runner
就是这么发现的），并强制在正文点名「哪些没跑、为什么、谁在飞」。

一条结构性说明：stack_report 与 ram_baseline **不在钩子清单里**，所以「人漏跑一次 =
这道检查这次不存在」；要机械化得先解决「磁盘 .htm/.map 属于最后一次构建的那个人」
——与 stash 覆盖面那条同源，不是加一根钩子就完事。另写明 --all-files **也不 stash**，
会让改写型钩子当场改全库，只能在静默窗口跑、跑完复核。

文档里的命令必须能直接跑：只读等价那条一行式刻意纯 ASCII——Windows PowerShell 5.1 按
ANSI 读无 BOM 的 .ps1，带中文标签的版本会碎成 SyntaxError（作者踩过并复现），改完后
从文档里抽出来重跑验证：checked 40 files (incl untracked)，problems 0。

同篇顺手核掉的同源不同源（可单独回滚）：§6 钩子数 40 → 50（口径 = YAML 解析条目；
直接 grep 声明行会多算一条被注释掉的候选 = 51）、主机侧单测「16 个合一篇」→ 22 根
专属钩子 + 18 套走 test-coverage 总闸；两处跨行断行的表格行修好，全文 8 个表格块
列数一致（脚本核过）。generated-fresh.md §4 补上解释器解析口径与 [ENV] 输出。
 2026-10-26 23:42:41 +08:00
wandering1 b1280e3cd1 feat(台架工具): 原子性复验能力并进既有 verify_log 并接进 @test——旧口径判 PASS 的缺陷新口径判 FAIL 
关键决定是**不造第二只校验器**：卡片原建议把校验器放进 scripts/，但「标记校验」这个
能力已归 .dsh/skills/serial-boot-test/scripts/verify_log.py，再造一只就是本仓反对的
实现漂移（reset.bat 折进技能是同一类判断）。改为扩展它 + 把开关接进 run_boot_test.py
——**不接就等于吸收了没人用得到**；默认路径逐字节不变（不传开关时 exact_check 根本不进）。

新增：--exact 整行锚定（并把「含最长字面串却未整行命中」的邻居原样打出来，那就是
行级交错的特征）、--pair 跨复位配对、--allow-residual 与 --head-char 服务崩溃注入腿、
--include-comments 复现旧行为、--selftest 判别自检。钉长度改成显式 @@LEN=<n> 逃生口，
**不再是默认**。

最硬的一条实证（进文档表格，也钉成一条 selftest 用例）：同一份缺陷捕获——行首被吃、
尾巴完好的那行 NAND_FTL——旧 --required 子串口径判 **PASS（假绿）**，--exact 判 **FAIL
并打出缺行首的邻居**。口径据此改写：凡是这一行可能丢行首或被插字节的标记，一律
--exact，不许只用子串。

实测不是声称：--selftest 16/16；真日志三向（修复后 PASS / 修复前 FAIL+邻居 / 带 ASCII
溯源头不再被头里的 [ERR] 误报）；被动烟测（--flash-cmd 置空 = 不烧录、不动板上镜像、
只采 60 行空闲流量，bench 锁取了即还）证明四个开关在 @test 闭环里**真的执行了**；
空闲流量里 PROF 行长 124/78/123 交替，顺手再证一次「钉长度当默认」会天天假红。

作者自报四个自己的问题（都被自测抓到并修掉，卡里也写了）：残留行被重复计成交错邻居
（会假红）、一条断言写反、**CLI 参数忘了接进 verify()——最危险那种：功能静默空跑而
外面看着全绿**、以及误报 run_boot_test.py 变 CRLF（实为自己的检查把换行符写成了字面
量，两个文件复核均为纯 LF，别按那句去查）。

boot_log_data/README.md 里同时有两个道的内容：bench23 的台账行，与 task-25 那条道写的
「证据可达性」规则与 force-add 定案——autostash 往返后两侧都逐一确认仍在。三份 bench23
证据 txt 首次入库（可再生的采集文本；两张非再生 .bin 已随前一笔入库）。
 2026-10-26 23:42:34 +08:00
wandering1 496b4dc5e2 fix(台架脚本): board_ui_nav 的 UNKNOWN 回退键序改为 e-s-l，冷启动落在待机态不再空转 
旧逻辑 UNKNOWN 分支里的 l 条件**永不可达**：classify 只在 MENU 态填 cols，UNKNOWN 恒
cols=None ⇒ 回退实际等于静默连按 s。而本机待机态按 s/l 无效、要按 e 才进菜单 ⇒
冷启动恰好落在待机态时，闭环导航直接开不了工（症状是界面点不动，脚本却报正常）。

现在 BACKOFF_KEYS 默认 esl、--backoff-keys 可覆盖（要旧行为填 sl），回退时**循环消费
键序、绝不连按同一键**，并新增 _dump_unknown 把认不出的帧存证下来，免得下次只能靠
复述。同笔带上 task-24 在 19:41:56 重跑产生的 trace 归档（1 行，不是本次手改）。
 2026-10-26 23:42:27 +08:00
wandering1 8ff2743374 chore(台账): RAM 基线、体积凭证与覆盖率基线随 22:52 构建回填 
三个基线文件与一篇内存文档表格同步到同一事实源（MDK-ARM 下 .map，mtime 2026-10-26
22:52:12；.map/.htm 按约定不入库，故把身份写进正文）：
· Code 231,712 B / RO 25,560 B / RW 1,504 B / ZI 136,216 B
· ER_IROM1 257,272 B（24.5%）、RW_IRAM1 80,312 B（61.3%）、RW_CCM 57,376 B（87.9%）、
  Flash 合计 258,792 B（24.7%）
· scripts/size_attestation.json 记录索引指纹 06808c35e47b…（1430 个文件），把「这份
  体积数出自哪一份工作树状态」变成机器凭证，而不是口头

覆盖率基线登记两条 [NOTE]（此前挂着不登记就是在攒债）：
· Drivers/BSP/UI/ui_data.c 65 → 316 行——账在 Lead：task-1 那笔改了装配层却没回填
  基线，此后每次提交都打印同一条 NOTE；一条长期存在的 NOTE 等于没有 NOTE。
· App/protocol/iec104/iec104_comm.c 36/36 行——task-8 搬家新增模块，作者已自测，
  登记归共享台账（我串行改，避免两个道同改一份门禁账）。
当前口径：line 6854/7626（89.9%）、func 505/542（93.2%）、suites 40/40、
tested_files 45、untested_files 142。

为什么这一笔能走真钩子：这是今天第一个静默窗口——四条道全部 PAUSED，全量
pre-commit 实跑（改写型钩子在没人写盘时才安全），因此这一笔不需要任何 --no-verify
例外。今天前三次 --no-verify 共放过三类真问题（5 条 CODE-RULE-17、2 个缺尾换行加
1 个漏提文件、共享尾段 +80 B 把 iec104Task 压到 ISR 底线之下），根因都是「抢跑时
没跑等价门禁」；task-37 把那张自查表写进了 pre-commit 使用说明，这一笔是还清的债。

仍然挂着的一条闸线：id-check 不可判定引用 1,162 处 / 上限 1,166，余量只剩 4。
主要吃进者是今天 UI 那笔（三页与其 68 条文本断言的注释引用），账在 Lead。
清账之前任何人新增编号都可能直接撞闸——已记进 task-34：要么把裸 TC 引用改成指向
属主登记处的写法让 und 掉头，要么把余量当硬约束写进协作口径。
 2026-10-26 23:39:08 +08:00
wandering1 b623a406ad fix(栈·存储·UI 收尾): 断掉临界区↔断言幻影环回到 1,464，标定门控单点化，卷锁五态可观测 
这四笔在主树里已经互相纠缠（同一次 @build 编译、同一份 .htm 度量），拆成四笔就不
存在任何一个被真编过的中间态，所以合一笔入库；下面按模块分段陈述，作者与出证归属
逐段写明。

—— 一、崩溃证据路径的整行独占收尾（log-maint-writer，task-26）——
上午那笔 1d4b6a17 之后，stack_report 报 iec104Task 静态最坏链 1,544 / margin 1,016，
低于 1,024 的 ISR 底线。真因不是新增局部缓冲，而是本模块与内核临界区之间新长出
一条环：taskEXIT_CRITICAL ⇒ vPortExitCritical ⇒ configASSERT ⇒ vApplicationAssertFailed
⇒ dbg_console_write_raw ⇒ 回到本模块。armlink 把这一整坨计入**每一个含临界区的
任务链**（vApplicationAssertFailed 的 Max Depth 由约 40 B 涨到 128 B + In Cycle），
所以九条链同涨约 80 B——同涨本身就排除了任何单个调用方。
改法两处：① 本模块三处窗口（取凭证 / 还凭证 / 整行入环）改用 CON_CRIT_ENTER/EXIT
（PRIMASK 保存恢复到局部变量；注释写全为什么不能直接 __enable_irq()——嵌套时会
替别人打开任务级临界区——以及屏蔽面变宽是有意为之）；② 异常/终点钩子里那对
自证空转的 begin/end 摘掉（异常态 begin 放行但不持有、end 是幂等空操作，调它只有
成本没有收益），任务态 STALL 行保留 begin/end，这个区分写进两处注释与文档 §4.4.1。
实测四棵树逐个 .htm 解析（身份钉 tree + Linker run 时刻 + 产物来源）：A=77779d49
链 1,456；B=1d4b6a17 链 1,464 / margin 1,096 PASS；C=含未提交钩子接线的工作树
1,544 / 1,016 FAIL；D=本轮修复后（Linker run 22:52）回到 **1,464 / 1,096 PASS**，
九条链齐降 80 B。断环图证：vPortExitCritical 由 136 B + In Cycle 变 8 B 且不再
In Cycle，con_tx_release 子树 152→8；Error_Handler 回到 280 + In Cycle = A 树同值
（既有发送环无人拆动）。顺带删掉 Src/freertos.c 崩溃路径里最后一个 HAL_Delay(200)
（该文件真实调用现为 0）。
测试：console_log 152→**153** 条（只增不减）；换钉不删防——015 现在钉「PRIMASK
窗口 2 次、深度 1、内核临界区 0 次」，新钉 015c 绝不等待，160 注入点搬到
con_pm_hook，176 强化到未调度路径连 PRIMASK 窗口都不开；红线水位
con_pm_at_tx_max 与 con_uart_crit_at_tx_max 双 0；判据⑦（延后的行与当场直发逐
字节相同）170b/171/178 仍全绿。作者自报并纠正一处：换钉时曾把 TC-CONLOG-015b 改
编号，而 015b 在生产注释与文档里都被引用——已恢复「编号不退役、语义搬过去」。
覆盖率 App/log/console_log.c 199/200 → 256/257 行、21/21 函数（只增）。

—— 二、未标定闭锁判据收成单点访问器（ui-param-writer，task-16）——
「UA/UN/IA 三相 VALID 全置位才允许跑判据」这条门控原先在两处各自镜像实现
（protect_task.c 的 s_cal_locked 与 ui_data_feed.c 的 feed_cal_block），改一处另一处
静默失效且无门禁可照。现新增 adc_cal_prot_blocked() 落在 App/algo/adc_cal，DTU_BENCH
特例收进一处；两个消费者同批改调、本地副本删除。作者还查实并纠正了我先前一句
错判：全仓 App/app→App/task 的 include 实为 0 条，故访问器不能落在 protect_task。
新增 TC-ADCCAL-018 八条（含冷启动即闭锁），adc_cal 套件 99/99。

—— 三、共享卷锁五态可观测性（ui-param-writer，task-17）——
原状比登记簿写的更糟：五个可区分态（未调用 / try 超时 / 分片超时 / fail-open /
未持锁却 release）生产侧零留痕，且 vol_lock.c 的返回值注释与代码相反——
fail-open（锁没建成、互斥已失效却在读写盘）被返 1 **谎报成取到锁**，而那正是
vol_lock.h 记录的台架实证故障（并发写坏 FTL → 喂狗点饥饿 → IWDG 误复位）的前置。
锁层加四个 volatile 计数（16 B 静态，零新局部、零新 callee、零日志、零 FatFs）与
不取锁的 vol_lock_get_stats()；13 处 try 调用点一字未动。**刻意不在锁层记时刻**：
记时刻要读 tick，等于给 defaultTask 取锁链添帧——诊断不值那几个字节；消费方若
自盖时间戳，那只能是被观测到的时刻而非发生时刻，.h 里已写明不得写成首次/末次。
四套本地假件各加 s_last_wait_to（字段名逐字一致），把「喂狗点取锁一律 timeout=0」
与「ftpTask 分片一律 100 ms」从注释纪律升级成会 FAIL 的断言；红-绿反证：临时把
sys_log_mcu.c 的 0u 改 50u → TC-SYSLOG-010/012 双红，把 lftpd_io.c 的 100u 改 0u →
TC-LFTPIO-034 红，两处按原串改回并用 SHA-256 证明逐字节还原。TC-VOLLOCK-015~019
共 45/45（无新桩）。

—— 四、UI 死接口清理（ui-maint-writer，task-6 收尾）——
删掉 ui_data_maint_ready()：全仓零消费者、只有它自己的用例在读。**更值得记的是
它为什么能活过一整轮评审**：头注释写的是「页面用它决定这页能不能操作」，而页面
从来没用过它——注释陈述的是意图，评审读的是意图，门禁读的是可达路径，两者都不
反驳「意图未实现」。作者对「连用例一起删」做了显式抗命：TC-UIDATA-025 的 13 条里
只有 4 条读那个死口，另 9 条钉的是真防线（六口未注入安全返回 / 残表整表拒绝 /
被拒不覆盖已生效的好表），故删冗余的 025a、把 025i/025k/025m 换成用 reset_req()
的可观察返回值判定，性质不丢。ui_data 套件 244 → 243（净减 1），黄金 40 页与
池 5448 B 未变（该刀零像素影响，参考图无 diff）。

—— 门禁与未跑项（本笔如实留账）——
cubemx-survival 基线已 --write（漂移 6 项全部是上述意图内区域：断言/栈溢出钩子
实现、看门狗模块行等），基线文件同笔入库，随后 --check 通过。
本笔未跑的钩子只有两条：mem-numbers 与 mem-budget——磁盘 .map 出自 22:52 那次
构建、含尚未入库的 UI 与工具改动，与 HEAD 台账必然不同码；按仓库既有约定允许
--no-verify + 正文留证，回填在紧随的台账一笔统一做（含 ram_baseline --update 与
覆盖率基线两条 [NOTE]：ui_data.c 65→316、iec104_comm.c 36/36）。
两条已挂着的账：① id-check 不可判定引用 1,162 / 上限 1,166，**余量只剩 4**，
主要吃进者是我今天推进的 UI 那笔（68 条文本断言的注释引用），账在 Lead；
② 崩溃注入腿（故意复位）台架复验未跑，需先由代码道提交触发器，且判据只判原子性
不判 [ERR]=0——IPSR 路径的主张归主机侧套件，硬件照不出来。

产物身份（按 D 表要求钉死，避免数字与树脱钩）：本笔包含的固件树就是那张 D 表对应的
那一棵——MDK-ARM/.../STM32F407-Demo.htm 的 mtime = 2026-10-26 22:52:12（.htm/.map 按
约定不入库，故把时刻写进正文）。提交前在本树复跑 stack_report.py：exit 0，
iec104Task 1,464 / margin 1,096（42%）PASS、defaultTask 3,040 / 2,080（40%）PASS，
与 D 表逐项一致；本次运行不含任何未提交固件源码之外的新改动。
 2026-10-26 23:31:05 +08:00
wandering1 52e28885cb feat(UI): 装置维护 3 页落地（时钟 / 强制复归 / 清除记录），内容页黄金 27→40 
三个薄页面模块 ui_page_clock / ui_page_reset / ui_page_clear，页面注册由生成器
自动写双端（裁定 A-1：「三叶各绑一页」与「零新增 .c」不可兼得，选薄页面加生成器，
不写手写 node switch——那种分发在增删叶子时会静默换功能，且没有任何门禁照得到）。

数据侧是注入式函数表：UI 不 include App 层的头。两条硬理由都实测过——分层方向
（layer-deps）之外，模拟器根本不链 sys_clock，ALLOW 豁免挡得住 layer-deps，
挡不住模拟器链接期。面板对时的唯一真判据是回读 RTC：sys_clock_set() 恒返 0
（RTC 写失败只打日志），所以真机侧写 1 后回读 1，最坏约 200 ms 落在一次「保存」
按键上，IWDG 800 ms 窗有余；上界与依据都写进注释。

「无时钟」徽标位置有两个像素级实测坑：放标题带右侧会被 4 字标题连成「时钟设置
无时钟」一句话；放页脚带左侧 x=7 会压住页脚——页脚从 x=6 起排，不是居中。
最终落在清单末行与页脚之间的空带 y=124。clear_done 那张顺带给出像素证据：
清 run.log 之后「操作记录」那一行从 2 变 3，页面上没缓存、没撒谎。

ui_w_records 的 UI_W_REC_LOG_* 顺序必须等于 syslog_id_t 顺序（7 类，只准尾追加），
已加编译期顺序守卫；执行侧 7 条映射表同样带编译期守卫。

测试与真值：内容页黄金 27 → 40 页（+13），文本断言 +68、反向断言 ABSENT +19；
27 张旧参考 git diff 为空 = 逐字节未变。往返池 5448 B 与菜单常驻堆 5368 B 均未变；
字库未扩（源码在用 171 并 KEEP_EXTRA 39 = 清单 183），font-charset 与 cn-chars、
cn-font 字节一致。@build 0 错误 0 警告；uiTask 静态最坏链 1,336 B / 16,384
（余 91%）与基线相同，页面钩子没进最坏链。

一条测试学结论单独留痕：反向断言不能当「位置不重叠」的证据——本脚本的字形匹配
把 y 带判得比字面宽（徽标在 125..136、页脚在 144..155，仍被 (140,160) 判命中）。
该防线改由正向断言「页脚未被徽标压住」承担（压字那一版实测过不了它）。

两条自我更正一并记档（作者自报，按真值而非原口径）：
① 先前报「文案零新增汉字」是错的——观测行拟用「动作元件」，「元」不在子集，
cn-chars 与 font-charset 如实红；最终改「保护动作 N」才让「零新增」成为事实。
顺序是：先按机器红，再按真值写结论。
② 先前报「6 个文件 BOM 逐个核过」被 bom-guard 证伪：丢 BOM 发生在上一次编译之后，
正是 AGENTS 那句「历史 0 警告不代表安全」的活例；此后一律以退出码为准。

未覆盖项不假装：台架「N>0 → N=0」在产品构建的未标定闭锁期拿不到（闭锁期 N 恒 0），
判据显式退化为「页面受理 + 落一条操作记录」，写在 rs_watch 注释里。

生成物入库例外照用：uvprojx 只加 3 个 ui_page_ 的 FilePath（真增删源文件），
CMakeLists 同批；两处都由 gen_menu.py 自己写，没手写。

本笔先走了一次真钩子：20 条钩子实跑通过（ui-golden 菜单 8 状态加内容页 40 页、
generated-fresh、registration-check、font-charset、ui-data 单测、cppcheck、
coding-standard、bom、mojibake、id-check、doc-links 等），只有 mem-numbers 与
mem-budget 两条红——磁盘上的 .map 出自 20:39 那次构建、含三条在飞道的代码，
与 HEAD 台账必然不同码。按仓库既有约定（这两条等台账回填时允许 --no-verify 并
正文留证）落这一笔；回填由我统一在收尾一笔做。

三条在飞道（task-26 崩溃证据路径、task-16 与 task-17 谓词收敛和卷锁观测、
task-36 台架工具）的未暂存改动被 autostash 暂时收走，钩子看到的是 HEAD 加本笔；
过程中曾把 comm 道未跟踪的 iec104_comm.c 临时移出（它不在 stash 覆盖面内），
那次移出反而让 ui-golden 撞见 CMake 缓存里的悬空引用而红——已改用「先落 comm
那笔、再落本笔」的顺序消掉这个中间态。ui_data_maint_ready() 待删（只有测试在读
的自检口），排在本笔之后单独一笔。
 2026-10-26 22:43:54 +08:00
wandering1 45086cf5f9 refactor(104): [comm] 段实现搬进配对模块 iec104_comm.c 并同笔补双端注册 
上一笔 e7136cbe 把 [comm] 段实现写在 iec104_pts.c、契约放在 iec104_comm.h，
撞上 coding-standard 的 CODE-RULE-17 (2.2)：非 static 函数必须在按文件名配对的
头文件里声明，于是 iec104_comm_init / _ca / _port / _ca_set / _port_set 五条判违规。
这 5 条本该被钩子拦下——是我用 --no-verify 放进主干的，成因与处置都记在案。

正解不是把声明抄进 iec104_pts.h（那会让一个函数有两个属主头文件，比原状更糟），
而是让模块名与文件配齐：新建 App/protocol/iec104/iec104_comm.c 承接实现体，
逐字迁移、零逻辑改动；iec104_pts.c 里 comm 符号清零，回落到 task-8 之前的基线。

实测（作者自跑，两版 .map 逐对象对账，不是「应该不变」）：纯搬家净差值 Code −8 B、
RO 0、RW +4 B（s_comm 从对齐余量改为显式计量）、ZI 0；iec104_comm.o = Code 120、
RO 45、RW 4、ZI 0。@build 0 错误 0 警告（Linker run 20:39:43，符号级证明
app_main.o 与 iec104_serv.o 现在指向 iec104_comm.o）。三套主机单测复跑：
cfg_file 207/207、iec104 174/174、iec104_serv 37/37，断言数零掉；
coding-standard 对 7 个固件文件 exit 0（5 条随配对成立自然消掉）；
registration-check PASS（唯一 WARN 是存量 rs485_task）。

注册与实现同笔落库，不留两种中间态：uvprojx 的 <File> 块（「真增删源文件」才入库
那条例外）+ simulator/CMakeLists.txt 的 IEC104_SOURCES 与 add_executable 接线。
今天已被中间态咬过两次——「有声明无定义」让别人撞 L6218E，「存在未注册」把别人的
提交拖红；而未跟踪文件不在 autostash 覆盖面内，藏不住。

本笔走 --no-verify 的理由与已跑的等价门禁：本笔与紧邻的下一笔（UI 装置维护 3 页）
在同两个构建文件里各有 hunk，只能拆开分笔；若此刻走真钩子，UI 道未跟踪的页面模块
会让 generated-fresh 与 registration-check 红在别人的半成品上（红的内容对、
账不该记这笔）。逐条手跑：check_coding_standard、check_bom_drift、mojibake、
check_ids --strict、check_doc_links --all，以及 cfg_file、iec104、iec104_serv、
console_log、ui_data 五套单测。

一条必须如实挂着的账：stack_report 现在 exit 1（iec104Task 静态最坏链 1,544、
margin 1,016 < 1,024 ISR 底线，差 8 B）。那不是本笔、也不是 HEAD：那是主干里
未提交的 task-26 钩子接线展开的新环（con_tx_release ⇒ vPortExitCritical ⇒
configASSERT ⇒ vApplicationAssertFailed ⇒ tx_end），三条任务链同涨 80 B。
证据用双指纹钉产物：HEAD=1d4b6a17 的仓外树用该树自己的脚本实测 1,464 /
margin 1,096 PASS（Linker run 19:43）；本笔所在工作树的 .htm 出自 20:39 那次
构建、含在飞代码。修复由日志道在做。
 2026-10-26 22:43:54 +08:00
wandering1 1d4b6a17ce fix(控制台): 未注册期裸发加"整行独占"，让路整行入环不丢，修掉 O1 第二实例 
台架一手证据（boot_log_data/20261026_prod_console_interleave_evidence.txt）：两次
「仅复位不重烧」启动里，[PROT] 未标定 INFO 行内分别多出 3 个和 1 个字节，而紧邻其后
的 [NAND_FTL] 行正好缺自己行首同样数量的字节（"[20" 与 "["）——串口 framing 错不会
让行变长，字节按原序出现在邻居里 ⇒ 两个写者并发逐字节写 USART1->DR。写者对：
protectTask 的未标定闭锁边沿 × defaultTask 的 storage_bring_up()，两者都落在
dbg_console_writer_attach() 之前（attach 排在存储 bring-up 之后），该窗口
s_con_writer_up == 0 ⇒ 任何任务的整行都走零互斥裸发。这是控制台单写者设计说明在册
O1 的**第二个实例**；2026-10-12 那次只补了"自愿门控"，而自愿门控挡不住业务边沿留痕
（业务无法预知某条边沿落在哪个窗口），所以这次被同一窗口第二次咬到。

修法是**非阻塞整行独占**：con_tx_try_claim/release 只在几条指令的临界区里
test-and-set，绝不把 7.8 ms 的逐字节发送包进关中断区、绝不等待；IPSR 上下文与调度
器未启动两种情况显式放行（崩溃遗言必须能出去；早期本就单执行流，一条不丢）；同任务
按深度嵌套。抢不到独占的那条行**原文入环**延后发——前缀与时间戳在 DBG_* 调用点就
格式化进调用方缓冲，本模块与 drain 都不补前缀、不重打时间戳，所以延后发出的行与当场
直发逐字节相同；[ERR] 只在「抢不到独占且环也放不下」时才红，按 3 次启动命中 2 次的
频率，让路若计 [ERR] 就会把静默缺陷换成常红门禁。顺带堵掉第二处洞：drain 每轮先取
凭证，拿不到就让位且 tail 不推进（旧写法 attach 可以撞上别人已发出的半行）。
新导出 dbg_console_tx_begin()/tx_end() 供 task-26 收口故障钩子的多段裸发。

否决过的两条路写进文档 §4.4.1：提前 attach 会把等串口塞进 mount/mkfs 时序敏感段
或让生产者在整个 bring-up 里堵在满环上；整段进环会让「无看门狗窗口」死机时一个字都
不出（2026-10-02 那几轮正是靠 bring-up 期流式日志取证的）。

判据：test/host/console_log 127 → 152 全绿（M 族 TC-CONLOG-170..179 共 +25，既有
127 条零删除）。唯一换钉法的是 TC-CONLOG-015——旧断言钉的正是缺陷机理本身（裸发 0
次临界区 = 零互斥），现改钉「恰 2 次几条指令的临界区 + 每个上线字节都在临界区之外 +
零等待」；硬红线由假 USART 在每个上线字节处记录临界区深度水位恒 0 来机器守住。四处
注入反证各自转红 11 / 5 / 1 / 3 条并逐字节还原复跑；覆盖率 console_log.c 199/200 行
→ 256/257 行、16/16 → 21/21 函数。邻域复跑：task_prof 27/27、sys_log_mcu 137/137、
iec104_serv 37/37。CONLOG 游标抬到 179。

台架复验判据（**本笔尚未上机**，下一轮请台架跑）：连续 3~5 次「仅复位不重烧」启动
日志 [ERR] 零命中，且 [PROT] 未标定与 [NAND_FTL] Initializing 两行都完整。
成本：.bss +5 B、Flash 估 +100~150 B，零新增 DBG_* / 零新增缓冲 / 零堆 / 零内核对象。
文档：控制台单写者日志设计说明.md 升 v1.6（O1 改「已处置」含两实例与字节账、新增
§4.4.1、§3.4 并发区间、§4.4 取消「不加锁」口径、§7 失效表、§11 变更记录、API 表）。
 2026-10-26 19:34:29 +08:00
wandering1 e7136cbea3 feat(104): [comm] 配置段落地，公共地址与端口由 defaultTask 读、iec104 服务端消费 
新增 App/protocol/iec104/iec104_comm.h + iec104_pts.c 内的 [comm] 段实现：内核前由
app_main.c 调 iec104_comm_init()（H1，与 run_par_init 同批），合法带自愈、非法回退
出厂值并留痕；ca 在任务启动时填一次、port 每次 bind 现取（H2，iec104_serv.c/.h 共 6
处取值来源），iec104_link.h 里那个从不生效的死 define IEC104_PORT 删除并改为指向真
源的注释。零新增 .c 之外的注册面（.h 不进注册钩子）；s_src_yk_exec / s_clock_sync
两个记录投递点一字未动。

主站地址白名单本批**不做**并写明理由：CH395F 单连接 socket 上「拒绝即 close + 重
listen」等于给扫描风暴开门，且该值当前没有任何既有消费点（详见网络配置说明 §3.6）。
生效方式是重启生效，不新增事件位。

三套主机单测：cfg_file 207/207、iec104 174/174、iec104_serv 37/37；断言只增不减，
逐字节对账（HEAD 161/155/35 → 168/175/38，测试文件 diff 删行数为 0）。编号形态已
整改：4 处裸号改成带模块码（TC-IEC104-031~033），新用例的属主登记处定义补进配置文
件单元测试说明.md（TC-CONFIG-056/057），模块游标抬到 TC-IEC104-033。

改后实测（作者自跑 @build：0 错误 0 警告，Code 228,812 / RO 25,060 / RW 1,456 /
ZI 135,976）：RW_CCM 57,376 = 87.9% 未动、RW_IRAM1 +16 B（61.0% 不变，来源是
s_cfg 去 const 的 RO→RW 搬家，s_comm 那 4 B 吃进 pts .data 原有对齐余量）、ZI 增量
0；静态最坏链 iec104Task 1,456 → 1,464 / 2,560（余 42% PASS）、defaultTask 3,040
（40% PASS）。本笔净增：RAM ≈16 B、CCM 0、ROM ≈0.4 KB，与立项预估同级。

越域两处按纪律点名：App/app/app_main.c 与 App/task/iec104_serv.c/.h 属 H1/H2 批准
钩子（各 3 行与 4~6 行），其余改动都在 iec104 目录与本模块测试内。
ui_data_feed.c 切 getter 留给 task-9（serv.h 注释已埋交接痕）。

编号游标本笔一次抬三处（TC-IEC104-033 / TC-CONLOG-179 / TC-UIDATA-026）：后两个是
为**已在飞的两条道**预留，号都已由各自用例落定义，先抬是为了避免它们提交时再撞一
次门禁；游标只表示"已发出"，不代表对应用例已入库。

为什么本笔与下一笔（控制台）也走 --no-verify：UI 道正在写 task-6（页面实例已落盘但
还没在 ui_menu_tree.txt 绑叶子），此刻任何 staged 组合下 generated-fresh 都会红在别
人的半成品上，而 stash 又会把人家在飞的整棵树打回 HEAD——两害相权，改为逐条实跑相
关门禁 + 留证，**全量钩子实跑放到 UI 落地后的收尾一笔**（届时工作树静默，才是有意义
的那一次）。已逐条跑过：@build 0 错误 0 警告（作者自跑，与本侧构建逐字节同码）、
check_ids.py --strict **退出码 0**（不可判定 1,154 / 上限 1,166、可判定 86.63%）、
bom-guard 无红（本笔不碰 BOM 名单文件）、mojibake 无 U+FFFD、三套主机单测全绿。
mem-budget 会红的成因是磁盘 .map 混着 UI 道在飞代码与 HEAD 台账不同码，按约定由收
尾一笔统一回填。
 2026-10-26 19:34:28 +08:00
wandering1 0f8b88337e docs(门禁): 主机侧单测覆盖面改写成口径陈述，第三处计数不同源一并修 
「22 根专属钩子」是**口径**不是缺口：test/host 实测 42 个目录去掉 common/__pycache__
= 40 套带 run_unit_test.py，配置里带 -unit-test 后缀的只有 22 根 ⇒ 其余 18 套
（含 ui_sink、console_log、net_socket、lftpd 三兄弟、sys_log_mcu、iec104_serv、
task_prof…）没有独立 files: 触发面，但每次提交都被 test-coverage 总闸全量真跑，
失败照样拦——执行面无洞的证据核到源码：check_test_coverage.py:134 用 rglob 发现
全部 40 套，:44-46 的退出码语义写死「有单测失败即 1」。缺的只是秒级归因。

补钩子的判据也现成：pre-commit 4.x 移除了 always: true，没有 files: 触发面就等于
永不跑，所以**不能**靠"补第 23 根"解决，要补就得先给该模块划触发面。

顺带查出同类的第三处不同源（也在 docs/门禁说明/ 内）：host-unit-tests.md 自己还写
着「16 个钩子 / 另有 12 套 / 总闸跑 28 套」，三个数全部过期，已改成 22 / 18 / 40，
§1 表补齐 2026-10-25 增补的六行，§6 第 4 条重写成覆盖面台账，§9 留变更记录。
另用 git log -S 核实原句「23 个 / 含 ui-sink 七个」是双重错：ui-sink-unit-test、
iec104-serv-unit-test、console-log-unit-test 在配置历史里**从未存在**过。
页数不变（26 篇），钩子数不变（声明 50 / 实跑 50 / 专属单测钩子 22）。
 2026-10-26 19:27:01 +08:00
wandering1 7d9db33a25 chore(门禁+文档): 生成器幂等钩子落地，文档真值与 UI 清单销项同步 
新增 generated-fresh 钩子（scripts/check_generated_fresh.py，只读）：把 gen_menu.py、
中文字库链、tools/arch_diagram/gen_*.py 拷进系统临时目录重跑，与工作区逐字节必须
一致；钩子本身不写仓库、不 stash 别人在飞的改动。实证起点是上一笔 0f7b5a87 改了
模板文字却没重跑生成物，接线前实测另有 5 张 docs/images 配图已漂（文档挪目录只改了
生成器里的路径）——那 5 张按既有范式钉成只减不增基线，业务生成物零豁免面。

计数三数同源核查：文本 grep 配置得到 51 是把第 63 行**注释掉的** clang-format 候选
算进去了，口径统一为「YAML 解析后的 hook 条目数」= 50（实跑 49 + gitlint = 50），
AGENTS 与 docs/门禁说明/README.md §2 用同一条自查命令。顺带更正「主机侧单测 23 个
（含 ui-sink）」：实为 22 个，test/host/ui_sink 有 run_unit_test.py 却没有 per-module
钩子，只有覆盖率总闸跑得到它（已另立待办，不当既成事实写进文档）。

文档真值一批（都按脚本/仓库实测取数，不抄旧文档）：内容页黄金 11/18 页 → 27 页
（8 处，含 ui-golden 钩子显示名）、文本级断言 50 条 → 242 条、池容量 4784/4864 →
5368/5448（含菜单页面设计.md 与同文档 1.5 节自相矛盾的那处）、页面补齐规划的立项
快照加限定语（日期按该文档自身标题 2026-10-23，不臆造现值）。变更记录里的历史数字
（11 页、50 条、老基线时代的绝对峰值）一律不改；无法实测的绝对峰值改成增量口径并
标注「待按新基线重测」。

销项（用户裁定 2026-10-26）：UI补齐.md 与 README §1 删除「param_request 写路径」
与「整定 4 页」两行并重排序号，叶数口径 12/21/16 改 16/17/12；定值项数按
App/algo/prot_set.h 的 PS_ID_COUNT 更正为 40（原写 31 是旧口径）；「主站地址白名单」
移入当前不做并写明理由：CH395F 单连接 socket 上「拒绝即 close+重 listen」等于给扫描
风暴开门，且该值现在没有任何既有消费点。

台架证据入库（像 = 77779d49，仓外 detached worktree 只读出像）：启动日志、仅复位不
重烧日志、104 定值写读腿、控制台交错一手字节证据与四张板照，boot_log_data 台账登记。
.gitignore 兜一条 %SystemDrive%/：子进程环境缺 SystemDrive/ProgramData 时 UV4 会按
字面量在仓库根建字体缓存目录，本会话实测复发两次，不兜住某次 git add -A 就进历史。

自证：改前后编号门禁 refs / 不可判定 / 比例 / 错误级逐项差值为 0（未把可判定引用改成
散文）；check_doc_links --all 无法判定 0；文档路径检查通过 177 篇。

本笔不含三条在飞源码道与板端导航脚本修复，它们各自单独一笔。

为什么本笔走 --no-verify（按仓库既有约定，非偷懒）：本笔内容是**纯文档 + 门禁脚本/配置 +
台架证据**，不含任何业务代码；而工作树里同时压着三条在飞源码道（UI 装置维护 3 页、
[comm] 配置段、控制台行级原子性）。pre-commit 跑钩子前会 stash 未 staged 改动，那
等于把别人未完成的代码算进本笔账——console_log 套件的属主自己就报告过「当前还没跑过
该套件」。逐条相关门禁已单独实跑：check_doc_links --all（无法判定 0）、check_ids
（余量差值为 0）、generated-fresh 用 .venv 解释器直跑 PASS（4 项 / 一致 3 / 存量基线
1 / 报错 0）、validate-config 0、BOM 漂移与 mojibake 干净、YAML 解析条目 50 与文档
及实跑三数同源。唯一会红的是 mem-budget：磁盘上的 .map 含上述在飞代码，与 HEAD 台账
不同码；台账与体积凭证由我在源码道全部落地后统一重建回填。证据文件：
ci-artifacts/commitA2.log（上一次尝试的完整钩子输出）。

另记一条本笔实测到的坑（已写进 AGENTS「Python 环境」与 docs/门禁说明/generated-fresh.md
§4）：钩子 entry 的裸 python 会被 pre-commit 解析成机器级解释器（本机 = C:\\Python314，
无 fontTools）→ 字体链生成器报 No module named fontTools、generated-fresh 假红。修法
是脚本内自己按「显式 var > 当前解释器 > 仓库 .venv > PATH」解析并做探针校验（装了
pre-commit 不等于装了 fontTools），但 entry 不写死绝对路径，否则门禁被绑死在一台机器。
这与 scripts/ci_local.py 文件头记的 2026-10-11「L0 全灭」是同一族问题的第二次发作。

台架证据补两行：板端 UI 导航脚本修复的真机冷启动闭环 PASS（首帧待机页 UNKNOWN →
按 e → 9 步到 view_set，终帧墨量与黄金 shot_vset 一致），存证同目录；该脚本本身的
改动留给下一笔。
 2026-10-26 18:26:47 +08:00
wandering1 77779d49d6 feat(ui+记录): 整定写路径与四类页落地，五类记录写入方补齐 
UI 面：ui_data 增加深度 4 参数写队列（请求 168 B、队列 .bss 672 B）与状态机
OK/ERR_RANGE/ERR_LOCKED/ERR_BUSY，ui_data_feed 出队后按注入 ops 走「闭锁 → 整批
预检 → 逐项 prot_set_set_sealed」，只提交改动位图；par 帧尾追加 cal_block
（口径 = UA/UN/IA 三路 ADC_CAL_F_VALID，与 protect_task 判据同构，不用 rt.eng
反推，V0.1 下 eng 恒 0）、UI_DATA_VER 升到 2。参数/定值/控制字/软压板四叶绑定
内容页（UI_PAGE_MAP_COUNT 12→16，复用四个查看模块，零新增 .c），编辑态按
is_editable 分派，LOCK（写不进去）与「未标定」（仍可改值）两源两通道两词。

记录面：syslog_request_clear/state/apply 三段式删除 API（UI 只发请求，落地在
defaultTask 的 drain 尾部且必须后置，卷锁一律 try，幂等只认 FR_NO_FILE）；
事故/告警/启动/操作/遥控五类各有一个真实写入点，记录类型 = 日志 ID 本身
（一类一个 /log 严格 8.3 文件；64B 定长体没有类型字段位，塞字段会砸掉既有读者）。
为守 protectTask 872 B 静态最坏链另拆 syslog_post_quiet()（无 DBG 的投递核，
丢弃留痕挪到 drain 侧差值补发），syslog_post 对外语义逐字不变。

为什么两道合成一笔而不是各一笔（实测，不是省事）：simulator/main.c 同时消费
两道新增 API（整定 pump 与 logtest 清除用例），按道切文件会让中间提交编不过；
RAM 受管快照与体积同码凭证描述的是合并后的 .map，拆开必落在「台账与 .map 不同
码」这条红线上。pre-commit 跑钩子前会 stash 未 staged 部分，这类耦合没法绕。

实测：@build 0 错误 0 警告；Code 228,260 / RO 24,960 / RW 1,440 / ZI 135,976 B；
RW_IRAM1 79,992 B = 61.0%、RW_CCM 87.9%（阈值 92%）；九个任务静态最坏链全 PASS，
protectTask 872 B / 57% 改前后逐字节不变（记录投递没垫栈）。主机单测 ui_data 82→
164、sys_log_mcu 106→137、prot_elm 47→60、iec104 141→154、iec104_serv 28→34，
既有断言零删改；48 个钩子 --all-files 全绿；编号门禁可判定 86.34%（基线 86.0%）、
不可判定 1,153 处低于上限 1,166；doc-links 无法判定 0；UI 黄金 18 页扩到 27 页
连跑两次逐字节一致；字库 diff 空。

顺手修掉三处既有缺陷（都是本轮第一个消费者才暴露）：sim_syslog.c 的 s_paths 行宽
16 而 "sim_selftest.log" 正好 16 字符没有 NUL 位（stat/remove 读越过数组尾，此前
靠后面 .rodata 碰巧为 0）；ui_w_setlist 二态行 ENTER 不回绕（控制字与软压板出厂值
全在最后一项，按了像没反应而叠层里已是越界值）；生成物 ui_menu_tab.h 与 gen_menu.py
模板漂移（上一笔改了模板没重跑生成器），现随生成器输出对齐。

未收口（不算完成）：保存后重启值保持与主站 C_RD 读回两条只能上板，台架窗口执行；
LOCK 屏显与越界反显的页面侧在模拟器造不出来（模拟器不跑定值自检、无 NAND），
已由生成侧单测与代码注释点名差距；同类页数与钩子数陈述残留另立待办。
 2026-10-26 15:51:12 +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 7635480e06 docs(任务规划): 清掉删卡后残留的悬空卡号引用 
上一提交删掉数据可信.md 的卡 1~11 行后，遗留四处指向已删卡号的引用，
按「销项即清理跨文档引用」补掉：

- 卡 0 硬依赖列原是「1」（卡 1 量程口径定死，已闭环）→ 改 —
- §6 顺序图「0 ─→ 5 闭锁验证」→「0 ─→ 闭锁验证」，去掉裸卡号
- §7 已定案行三处「（卡 5 实现）/（卡 3）/（卡 8）」→ 去掉卡号，
  保留结论本身（cfg_file.c 引用的「§7 决策 3」锚点是 CFG_VAL_INT 文本，不受影响）
- §8 风险表「卡 8 明确唯一发布者」→「设计约定」；「卡 0 设为卡 4 的硬
  前置」改写为「ROM 默认系数已冻结、卡 0 仍未跑」的既成事实表述

剩余卡号引用只有 卡 0 / 0b / 12 三种，均与 §5 任务卡表对得上。
代码注释与 App/algo/README.md 里的「数据可信」卡 N 属实现溯源，按惯例保留。

门禁：check_ids --strict 增量拦截通过（84.73%，基线 84.0%）；
check_doc_links --all --sections-strict 通过；pre-commit 关键钩子全过。
 2026-10-25 22:53:35 +08:00
wandering1 50e5877882 docs(任务规划): 只留待办——删除已完成条目与变更记录 
「只保留待办」此前只落了一半：UI补齐 / 排期详述 / 测试专项已瘦身，并行分道
方案与数据可信还留着批 1/批 2 的收口说明、销项括注与里程碑达成记录。本次按
README.md §3 清干净。

并行分道方案.md（353→238 行）：
- 删「批 1/批 2/批 2.5 全部收口」块、道A~道D 表行、11 张已销项数据可信卡
- 删 L1-5 通道标定 / L5-2 码值越界两条已落项、§5 批 1 三道详解（5.1~5.5）
- 删 §6.1 冲突矩阵；章节重编号 9→8，并修 §9→§8 自引用
- §4.3 删「ui_data 为什么当初排批 2」历史插叙

数据可信.md（384→290 行）：
- 删 §1「为什么是这一波」、§2.2 量纲错配、§2.4 点表现状、§2.5 引擎约束
- §5 任务卡表只剩 0 / 0b / 12；§3 里程碑只剩 M4 未收口行，M5/M6 压成一行口径
- §6 顺序图只留剩余三张；§8 删两张已销风险行；§4.4 落地注改为现状口径
- §2.1/§2.3/§2.6/§4.1~§4.5/§7/§8/§9/§10 与卡 0/0b/12 全部保留：它们是
  adc_cal.* / meas.* / cfg_file.* / protect_task.c / ui_data* 头注释引用的
  口径出处，不是"已完成记录"
- §2 编号不连续是刻意的（被代码引用故不重排），已在节首加注说明

README.md / docs/README.md：
- 文件地图去掉「卡 1~11 已销项」「八条道」等历史表述
- §1 网络行删掉三处 merge 号与批 1/批 2 销项经过
- 道A~道H 改为道E~道H，与并行分道方案一致

排期详述.md / 采集保护收尾.md / 登记簿.md / UI补齐.md：
- 删 N-2/N-17/N-22 销项注、M1/M2 已达成括注、批 1/批 2 道名
- 修 E-27/28「批 3」与「批 4」自相矛盾；B10 硬依赖改指卡 12

未动：测试与架构专项.md——S12 / A-5 / P1-10 三节分别是 net_socket.c、
check_size_gate.py、ch395f_test.h 与门禁说明引用的锚点，删了会断校验 6。

门禁：check_ids --strict 通过（可判定 84.73%，基线 84.0%）；
check_doc_links --all --sections-strict 通过（180 文档 / 2691 处章节引用）。
 2026-10-25 22:47:54 +08:00
wandering1 68cbf8ea75 docs(任务规划): 按现状重排波次——UI 补齐转为当前波次，数据可信转收口态 
用户要求按现状重新规划。盘点后现状与文档已有实质偏差，本次一并纠正。

一、盘点结论（2026-10-25）
- 批 1 / 批 2 / 批 2.5 全部收口，工作树清零、两锁空闲。
- 数据可信：软件侧 100%（卡 1~11 全销项；M4 ②③④⑥、M5 ①②③、M6 全达成），
  只剩卡 0（万用表）/ 0b（子板变比）/ 12（标准源）三张台架与外部卡。
- UI：33 叶已绑 12、剩 21。原口径「余批 5 = 整定 4 页」按页面批次统计，
  漏了批 1 剩的 3 页（时钟/复归/清除记录）与批 3 的 12 页，实际差 17 叶。
- 结构债：剩 net 收口、白名单、性能簇、dhara、卷锁、USART1 六项。
- 工具链 S12 / A-5 / P1-10 / S1-c 全销项。

二、关键发现：保护整条链现在是闭锁态
protect_task.c:98 要求 UA/UN/IA 的 ADC_CAL_F_VALID 全置位才走判据，而 VALID 只在
两点标定写入 [adc_cal] valid 后才置位（adc_cal.c:338）。产品构建（非 DTU_BENCH）
下保护不动作——这是卡 5 的有意设计，但意味着核心功能当前关闭，解锁只有
卡 0 -> 0b -> 12 一条路。已写进 README §1.1、数据可信 §3、采集保护收尾、AGENTS.md。

三、三条用户判断（2026-10-25）
1. 台架不在手边 -> 卡 0 顺延，本波整体不占编码道。
2. 保护保持未标定闭锁到标准源到位，不用万用表标定走捷径。
3. 下一波只做 UI 补齐，结构债押后。

四、新波次顺序（README §2.0）
采集保护收尾 -> 数据可信（收口态）-> UI 补齐（当前）-> 结构债（押后）->
预算与内存（暂缓）-> 验证常态 -> 仓库决策 -> 暂缓 -> 硬件改版。
排序原则补一条元规则：优先级只在「能开工」的项之间比较——高优先级波次全被
外部资源或硬件代次卡住时，按「现在能整波闭环」重排，阻塞原因写进「为什么在这」列。

五、新增 UI补齐.md（当前波次任务卡）
21 叶按数据源就绪度分三梯队：第一梯队 9 叶零依赖（整定 4 + 维护 3 + 遥测 2）、
第二梯队 4 叶需新配置段（通讯设置 + 遥信 3，后者无开入硬件不立卡）、
第三梯队 6 叶需写入方或计数器（记录 5 + 运行报告）；不排 2 叶（手动录波 / SNTP）。
共 7 张任务卡，单道串行——ui_menu_tree.txt 与 ui_page_registry.c 是单写者生成物。

六、顺带清掉的文档漂移
- 排期详述 §1/§2 还挂着 3 条已销项条目（日志管线 N-2、写回 flush N-22、
  探针心跳 N-17），与 README §2 自相矛盾 -> 删除并补销项说明。
- 测试与架构专项：§1 P1-10 与 §2.1 S12、§2.3 A-5 已销项却仍留详述 -> 压缩成证据指针。
- README §1「网络 4」只列 3 条（漏 N-30）-> 补齐。
- docs/README 文件夹地图与登记簿卷首仍称「数据可信 = 当前波次」-> 改指 UI补齐.md。
- 页面补齐规划的就绪度表：遥测死区/系数随卡 10/卡 2 已具备数据层、SOE 页已落地，
  三行状态更正；统计口径改为「27 叶中 6 叶已落地，剩 21 叶」。

七、踩到的坑（写进日志备查）
测试与架构专项卷首那段「已完成事项的证据沉淀」清单是 S4/S5/S7/S9/S11 的**定义出处**，
压缩时一并删掉会让校验 2 在 6 个文件上爆 14 类新账（实机测试实施指南 S4x7/S5x5、
check_test_traceability.py S4x5 等）。清单已原样恢复——它看着像历史，实际是门禁的锚点。

八、门禁
check_ids --strict 通过（可判定 9306/11003 = 84.58%，基线 84.0%）；
check_doc_links --all --sections-strict 通过（180 文档 / 2684 处章节引用）。
 2026-10-25 22:07:29 +08:00
wandering1 17ece864d1 docs(登记): F2/F3 台架分箱定案销项 + 饿死型签名新行（并档 E-27/28 批 3）
CI / L0 静态门禁 (pre-commit) (push) Failing after 45s
Details
CI / L0.5 主机侧单测 (MSVC) (push) Failing after 43s
Details 
台架两轮（1a624b1，v1.1 判据）分箱结论落账：
- 销「复合连击串窗」：按位分账 66f862e，轮①复合零误报 + 轮②真单串 8 行
  零漏报，DoD 双向达成
- 销「重建窗内回执排队拖 800ms」：sink 往返喂位 9d90e00，:7003 churn 轮
  2200 周期 stall=0、uisn 在途峰从 154s 级收敛到 103ms（阻塞型射程内治愈）
- 新增「reconcile 突发饿死 uiTask」：探针轮 3 事件 8 行全 UI 单串 ≥8 连窗、
  cf=0 seg=1、uisn=0、uip 在途 1083ms 而 uis 峰 183ms——被拖的是 feed/port
  纯计算段墙钟，§11.3 脆弱点 1 首个实测样本；处置并档 E-27/28 批 3 两案并评
证据 = boot_log_data 两 gz（a92baa2 入库）；README 网络行同步 4→3 条目
 2026-10-25 20:57:34 +08:00
wandering1 ac51ff2154 merge: task/v5arch-logs 合入 v2-on-ui 
任务 v5arch（1 个提交）经 task-worktree 回收：
- docs(boot_log_data): f3rounds 验收两轮日志存档 + id-check 二进制工件跳过
 2026-10-25 20:52:43 +08:00