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

813 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
wandering1 2c69a6ca07 docs(屏板): 订正 CRC 字节序口径（低字节在前） 
写 1-1 时用屏板自己的算法复算了线上字节，发现文档里"CRC 高字节在前"的说法
与真实顺序相反，一并订正。

事实：屏板 Calculate_CRC() 返回的不是标准 CRC-16/MODBUS 值，而是高低互换后
的「线上字」（"123456789" 它返回 0x374B，标准值 0x4B37）。于是
RS485_RefreshScreenCMD() 里 cmdbuf[4] = crc>>8（注释写"CRC校验高字节"）
实际写出去的是低字节——两处命名都反，线上字节是对的（标准 Modbus 低字节在前）。

照字面实现会让屏板把每一帧都判成 CRC 错，而它的超时判定只看"收没收到一整
包"、不看 CRC，现场只表现为画面不刷新，极易误判成波特率或时序问题。

- 产品需求 §5.16.2：帧 A 表的 4/5 偏移改成低/高，补一段字节序说明与实测值；
  帧 B 的 CRC 行、§5.16 的通道概述、实施清单第 11 条同步。
- 产品需求 §5.16.2：RT_CMD 周期 275 -> 280 ms（判据 RT_count > 55 即第 56
  拍 x 5 ms；屏板源码注释里的 275 是少算一拍）。
- 屏板链路.md：4.2 的帧 B 布局与 0-3 的验收命令示例同步，并指向单测向量；
  1-1 标完成。
 2026-10-29 19:18:11 +08:00
wandering1 16048140fd chore(体积): 重盖同码凭证（sb_proto 进索引） 
上一条提交漏带 scripts/size_attestation.json。指纹按 git 索引内容生成，
sb_proto.c/h 进索引后指纹从 bfe075e7 变为 df1c01ab，凭证不跟着走就会
判"不同码"。

Code=236,460 B 不变（新模块尚无调用者），RW_IRAM1 81,536 B / RW_CCM
57,376 B 均未动。
 2026-10-29 19:17:56 +08:00
wandering1 b25d70e962 feat(屏板): 协议层 sb_proto（帧 A 解析 / 帧 B 组帧 / CRC-16） 
批 1 的 1-1：新建 Drivers/BSP/ScreenLink/sb_proto.c/h，纯逻辑、无 HAL 依赖，
可主机侧单测。屏板侧的协议事实源是 DTU-LCD 的 CRC16.c / MODBUS.c / rs485.h。

- CRC-16/MODBUS 用一张 16 位合并表（512 B，与屏板两张 8 位表同量）。可逐项
  验证的关系：s_crc_table[i] == (auchCRCLo[i] << 8) | auchCRCHi[i]——屏板把
  低字节表叫 Hi、高字节表叫 Lo，这正是下面那个字节序陷阱的根源。
- 帧 A 解析：先校 CRC 再看字段。地址/功能码/命令类型不符报 BSP_ERR_PARAM，
  CRC 不符报 BSP_ERR_CRC（调用方据此决定"计数"还是"静默丢"）。RT_CMD 带
  非 0 key 不报错、按 0 收——为这一项丢一帧等于丢一次刷新，代价不对等。
- 帧 B 组帧：普通图（掩码小端）+ LOGO（宽高大端 + 魔数 0x89 0x45），整帧
  4208 B 重写（998 B 填充固定 0x00 且参与 CRC），组完即自校验。
  LOGO 容量按字节数判（((w+7)/8)*h <= 3200）而不是像素数：161x159 只有
  25599 像素，却要 3339 B 才装得下。
- 主机单测 59/59 PASSED（test/host/sb_proto/），覆盖率 74/74 行、6/6 函数。
  其中两条向量是屏板自己算出来的线上字节（01 03 01 00 F0 48 与
  01 03 00 09 31 DE），并按屏板 Check_CRC 的口径反查"它会认这一帧"。
- 双端注册：uvprojx 加 File + IncludePath；模拟器侧走 check_registration.py
  的 MCU-only 豁免（纯逻辑，模拟器无消费路径）。
- Keil 构建 0 错误 0 警告；Code 不变——尚无调用者，链接器按未用节丢弃。

文档侧的 CRC 字节序订正见下一个提交。
 2026-10-29 19:17:28 +08:00
wandering1 71b6a5fa14 docs(屏板): 批 0 的 0-3 接法落纸 
0-3 的交付物是"接法与验收方式写清楚"。网表核对结果：ST_TX0 / ST_RX0 只连
U5.A10 / U5.B10 与 MCU 的 101/102 脚（U17 就是 MCU 本体，101/102 = PA9/PA10），
CN1 上没有任何 USART1 端子——USART1 的 TTL 唯一出口是 U5 子板连接器。

- 决策一下方新增「接法与验收」：三行接线表（U5.A10 -> 屏板 PA3、
  U5.B10 -> 屏板 PA2、共地），加三条易错点（必须交叉、别去 CN1 找、
  别抓错同一连接器上 USART3 的 ST_TX2 / ST_RX2）。
- 验收方式写死：无实物时用 PC + USB 转 TTL 顶替屏板发 6 B RT_CMD 帧，
  判据 Size==6 / CRC 100% / 10 min 无丢帧 / 拔插 TX 线后自愈。
  "6 B 能被收到"这条要等 1-3 的接收中断落地，实测随 1-3 做。
- 0-3 标记完成（落纸部分），§0 的执行顺序段落改成已完成口径。
 2026-10-29 19:04:20 +08:00
wandering1 6531c4a4bc chore(台架): 台架串口默认口改 COM3 
日志口迁到 RS232#1/UART5 之后，台架那根线接在 CN1 的 RS-232 端子上，枚举
出来是 COM3；.serialtest/config.json 还写着 COM6，@test / @build /
serial-assistant 不显式指端口时就会去开一个已经没人说话的口，抓到空日志。

- .serialtest/config.json：portName COM6 -> COM3。
- 产品需求 §9.13：物理前置改成已完成口径，写明台架口由 COM6 变 COM3。
- 数据可信：资源图例里的台架串口同步成 COM3。

docs/测试说明/m2_data/README.md 里的 COM6 是 2026-09-22 那次运行记录，按当时
事实保留不改。
 2026-10-29 19:04:08 +08:00
wandering1 8a0cb464c0 test(日志): 主机单测桩跟到 UART5 
生产源 f5161e15 已把控制台端口收口到 CON_UART(=huart5)，桩若还停在
huart1 / MX_USART1_UART_Init，主机单测会因符号缺失编不过；更要紧的是
huart1.Instance = 0 那几组用例会失去"串口未初始化"的原意——改成填一个
生产代码根本不碰的句柄，短路照样命中，但测的已经不是真实那条路径。

- stub/usart.h：暴露 huart5 + MX_UART5_Init，并按真实 Inc/usart.h 校正
  "真实那份还声明哪些"的描述（huart1~4、MX_USART1~3_UART_Init、
  MX_UART4_Init）。
- stub/stm32f4_fake.h：USART1_IRQn -> UART5_IRQn，
  __HAL_RCC_USART1_CLK_DISABLE/ENABLE -> __HAL_RCC_UART5_*；假外设块的
  标题与位注释去掉具体实例号（它本来就是通用模型，不是某个实例）。
- console_log_test.c：huart1 -> huart5（19 处）、
  MX_USART1_UART_Init -> MX_UART5_Init，含一条用例的打印文案。

纯桩与测试改动，不碰生产源；153/153 PASSED。
 2026-10-29 18:56:55 +08:00
wandering1 7dbc8f8676 docs(屏板): 批 0 的 0-1 / 0-2 标记完成 
0-1：台架线已换成 USB 转 RS-232 适配器，接 CN1.10 / CN1.12 / CN1.8，
COM3 在 RS-232 侧可读可抓。

0-2：提交 f5161e15，控制台端口收口到 huart5。判据全部实测：
开机日志 8 个锚点全中、启动到 net init: OK 用时 661 ms、
连续 10 分钟 1218 行零 [ERR] 零 dropped、USART1 已无控制台写入。
 2026-10-29 18:46:25 +08:00
wandering1 f5161e1567 feat(日志): 控制台迁到 RS232#1/UART5，USART1 让位给屏板链路 
批 0 的第 2 项。USART1 是唯一 MCU 引脚直出的 TTL 通道，700 kbaud 的屏板
链路要用它，控制台必须先让开。

console_log.c 加一处端口收口块，换口只改这一段：

  CON_UART / CON_UART_IRQN / CON_UART_CLK_DISABLE/ENABLE / CON_UART_INIT

代码实际改动 4 处：con_tx_bounded 的 huart1.Instance（NULL 判据、counted
回退、赋值）与 con_uart_reinit 全函数体。其余是把描述当前行为的注释里的
USART1 换成「控制台串口」；历史变更记录（2026-10-02 / 10-24）里的 USART1
保持原样，那是当时的实况。

注意事项：UART5 在 APB1、USART1 在 APB2，时钟宏不能照抄；
__HAL_RCC_UART5_CLK_ENABLE 定义在 stm32f4xx_hal_rcc_ex.h。

不改 UART 模式（2026-10-26 裁定：保持 UART_MODE_TX_RX，不动 RX 配置）。
MX_UART5_Init 在 Src/main.c:135，比 MX_USART1_UART_Init 晚几个初始化调用，
该窗口内的日志由 CON_UART.Instance == NULL 短路接住（记 dropped，不崩）。

构建：Code=236,460 RO=28,124 RW=1,876 ZI=137,084（Code 较迁移前 +4 B）。

台架验证（COM3 @115200，RS232#1 经 CN1.10/CN1.12）：
- 烧录回读 no difference found；8 个 required 锚点全中，无 forbidden；
  启动到 net init: OK 用时 661 ms
- 连续 10 分钟长稳：1218 行，零 [ERR]、零 dropped、零 tx_fault，
  末行仍在正常 PROF 输出
- USART1 已无任何控制台写入（全文件 grep 只剩历史注释）
 2026-10-29 18:45:59 +08:00
wandering1 27a700b0d8 docs(屏板): 删掉「日志口改 UART_MODE_TX」的说法 
2026-10-26 已裁定不改 RX 配置，ORE 由 console_log.c 既有的 drain 预算与
300 ms 冷却兜住（docs/子系统设计/控制台单写者日志设计说明.md §4.4.1、§12）。
两处文档仍在要求把新日志口设成 UART_MODE_TX，会误导实现，直接删除：

- 屏板链路.md 批 0 的 0-2 第 ② 项、风险表「日志口又染上 ORE 锁存」整行、
  验收清单第 0 条的「无 ORE 锁存」
- 产品需求设计文档.md 的 §5.16 硬要求 ②、端口重排第 2 条、
  §9.13 第 16 条的第 ② 项

0-2 因此只剩「把 huart1 收口成一处端口宏指向 huart5」。
判据里的「无 ORE 锁存」一并去掉——ORE 是已知残余，不按它判。
 2026-10-29 18:21:17 +08:00
wandering1 50c75eb516 docs(屏板): 批 0 日志口定为 RS232#1（UART5），落定 CN1 端子与适配器要求 
2026-10-29 用户裁定：台架线走 ST_TX1 / ST_RX1 这一对，即 RS232#1，
对应 UART5（PC12 / PD2）。此前文档把默认日志口写成 USART2（RS232#3），
与这次裁定不符，一并改掉。

网表核对（docs/硬件平台/V0.1.tel 逐段可查）：

  PC12 -ST_TX1- U9.3 -> U9.6 -TX1- U13.11 -> U13.14 -RS232_TX1- CN1.12
  PD2  -ST_RX1- U9.2 <- U9.7 -RX1- U13.12 <- U13.13 -RS232_RX1- CN1.10

由此落定三件事：

1. 台架端子：适配器 TXD 接 CN1.10、RXD 接 CN1.12、GND 接 CN1.7 或
   CN1.8（CGND）。方向是交叉的——CN1.10 是板子的接收端。
2. RS232#1 没有 TTL 出口：ST_TX1 / ST_RX1 在网表里只连 U9 的 3 脚 /
   2 脚与 MCU 两个脚，既无连接器也无测试点。唯一外部出口是 CN1 的
   RS-232 端子，所以必须换 USB 转 RS-232 适配器；现有那根 TTL CH340
   直连不了，接上去轻则不通信、重则打坏 U13 或适配器。
3. U14 是 RS232#3 的网口座（3 脚 RS232_TX3 / 6 脚 RS232_RX3），本通道
   用不上。原文「改接 CN1（或 U14）」会把接线引到错误的通道上，删掉。

0-2 的目标端口随之从 huart2 收窄为 huart5（不再二选一）。huart5 现为
115200 8N1 / UART_MODE_TX_RX，业务代码无人使用，仅 Src/stm32f4xx_it.c:565
挂着 IRQ 入口；改 UART_MODE_TX 要在 .ioc 里做，Src/usart.c 是生成物。

改动面：屏板链路.md（决策二表、批 0 的 0-1 / 0-2、台架步骤 0、风险表各
一条）与产品需求设计文档.md 的 §9.13 物理前置段（原文同样写着「或 U14」）。
 2026-10-29 18:14:44 +08:00
wandering1 9191c1d966 取窗竞态的原因 2026-10-29 18:06:33 +08:00
wandering1 0c8fb5e1b6 chore(体积): 合并后重盖同码凭证（指纹 d9848eb1，体积零变化） 
X-20261029 合入 v2-on-ui 后体积门禁报「不同码」，原因是凭证按 git 索引
blob 计算指纹，纯注释改动也会改变文件哈希，尽管链接产物一字未变。

@build 已在合并提交 c51ac2e8 上跑过 0 错误 0 警告，.map 为 17:50:23 的
产物、晚于最新受管源码，前置条件满足，故按门禁自身给出的修复路径重盖：

  ram_baseline.py --update

check_mem_numbers.py --write 与 ram_baseline.py --write 均报「已是最新」，
tsv 今日行数字相同未变，本次只改凭证四个字段（fingerprint / built_at /
git_head / map_mtime），sizes 与 pct 保持原值：

  Code=236,456  RO-data=28,124  RW-data=1,876  ZI-data=137,084
  RW_IRAM1 81,536 B (62.2%) / RW_CCM 57,376 B (87.9%)

check_size_gate --local 现已通过：同码 + 受管区 <= 92%。
 2026-10-29 17:52:33 +08:00
wandering1 c51ac2e8ef merge: task/X-20261029-ring-comment 合入 v2-on-ui 
任务 X-20261029（5 个提交）经 task-worktree 回收：
- docs(algo): 5.3 节补窗首下标的圆周图（三种写法对照）
- docs(algo): 5.3 节补窗首下标的圆周图（三种写法对照）
- docs(algo): sample_ring_window 注释收敛，长推导移到设计说明
- docs(algo): 采样环缓冲补「为什么需要/设计思想」两节与两张配图
- docs(algo): 补 sample_ring_window 注释，详解窗首下标推导

备注：sample_ring_window 详细注释（纯注释，不改逻辑）
 2026-10-29 17:47:20 +08:00
wandering1 126c4bf57f 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:29: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 929cacbd72 docs(algo): sample_ring_window 注释收敛，长推导移到设计说明 
- 设计说明第 5 节已详述「为什么需要 / 设计思想 / start 推导」，函数内不再复述：
  环内布局示意、两条坑的逐句论证、取值范围推导全部删去，改为一句结论 + 指针
  （docs/算法/采集与算法层设计说明.md §5 与 §5.3）。
- 留在代码里的都是「就地可判」的落地要点：通道号为何先转 unsigned、
  n 的两条拒收理由、-2 与 -1 的语义区分、先加 DEPTH 的同余理由、逐点取模。
- .h 的指针从 .c 改指设计说明，避免同一事实两处详述。
- 净减 81 行；去注释后代码 token 与 HEAD 逐字相同；@build 0 错 0 警。
 2026-10-29 17:19:42 +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 de512a0db8 docs(algo): 补 sample_ring_window 注释，详解窗首下标推导 
- 补环内布局示意与 s_head 语义（下一待写位置，非最后写入位置），
  据此推出窗首 = s_head - n、窗尾 = s_head - 1。
- 重点解释 start 为何写成 (s_head + DEPTH - n) % DEPTH：
  加 DEPTH 不改变同余类；规避 16 位下溢后再取模不等价（65536 不是
  40 的倍数）；规避有符号负取模（-17 % 40 == -17）。
- 补限定条件：仅 adcTask 上下文，写者与读者同任务串行，故不加锁。
- .h 只加一行指针指向 .c 的推导，避免同一事实两处详述。
- 纯注释改动：去注释后代码 token 与 HEAD 完全一致；@build 0 错 0 警。
 2026-10-29 17:06:28 +08:00
wandering1 cdf88a7121 chore: run_boot_test 文档串引号改中文引号——代为提交他人在飞内容 
同样是本会话开始前就在工作区的未提交改动（非本次编辑），按用户指示代为提交。
内容逐字节未变：在飞时与工作区的 git hash-object = 369380ca8eb024b593d872455b6a020797abcd8d，
本笔提交里的 blob 同一个（本会话早些时候核对过两次，值一致）。

改动性质：_split_cmd() 的 docstring 里两处示例路径的 ASCII 单/双引号换成中文引号，
共 2 行、全在 docstring 内，函数行为不变（仍 shlex.split(posix=False) 后逐段剥引号）。
动机与 AGENTS「字符串字面量必须纯 ASCII」同源：中文语境里的 ASCII 引号容易被误当
代码边界（这条陷阱在本仓的 shell 混用历史里反复出现）。

核验：.venv 解释器 python -m py_compile 通过；git diff 仅 4 行、无逻辑行改动；
no-mojibake / trailing-whitespace 无问题（同样因全局 exclude 挡掉，手工跑过）。
 2026-10-29 16:39:58 +08:00
wandering1 c66b5ad40d gate: draw-diagram 技能正文扩写——代为提交他人在飞内容 
本文件在本会话开始前就已是工作区未提交状态（疑似技能自进化或另一会话所写，
非本次编辑）。按用户指示代为提交；提交前后逐字节核验内容未被改动、也没被
pre-commit 的改写型钩子动过：
- 提交前工作区 git hash-object = a6bdc570fe
- 本笔提交里的 blob                 = a6bdc570fe

内容（4,227 → 14,364 B，+129/−32 行）：
- 工具选型补「为什么不用 Mermaid」的实测教训（台阶图被压成同一高度）
- 新增「二、从零新写生成器」：抄骨架三条约定、预检三件套 OVERFLOW / check_fit /
  wrap、emit() 按目标编码打印（generated-fresh 把脚本拷进临时目录重跑时不因
  GBK 终端崩）、路径锚在脚本自身而非 cwd
- 新增「三、目检」：Windows 无 SVG 渲染器时用本机 headless Chrome/Edge 截图回读
- 新增「五、generated-fresh 逐字节幂等」与「六、提交」，陷阱与验证清单同步

核验（手工跑，理由见下一段）：skill-size Passed（14,364 B 远低于 65,536 写侧
上限，正文无 reference/ 指针故无悬空）；trailing-whitespace Passed；无 BOM、
CR 0、U+FFFD 0、单个 LF 结尾、无三连空行。

⚠ 顺带发现（本笔未修）：本仓 .pre-commit-config.yaml 的全局 exclude 含 .dsh/，
而钩子的 files: ^\.dsh/skills/ 打不过全局 exclude → **只碰 .dsh/skills/ 的提交
一条钩子都不会跑**（这两笔提交期全部钩子显示 no files to check Skipped 即此因；
手工 run --files 会绕过全局 exclude，所以能 Passed）。skill-size 因此目前拦不到
任何真实提交，需要单独裁定怎么接（去全局 exclude 还是给它单独道）。
 2026-10-29 16:28:21 +08:00
wandering1 f08b12a46c docs(技能渐进展开): 五个技能正文逐字外置到 reference/，主文只留索引与指针 
按「主文留头量、深规程外置」重写本仓技能，全部是逐字搬移：
搬移前断言原文每条非空行必须出现在新主文或 reference 文件里，
0 丢失才落盘；步骤编号一律不重排（正文有「第 12 步」交叉引用）；
每个切点保留原小标题 + 索引（加粗引导句与步骤标题）+ 指针行。

主文变化（上限口径 = 插件写侧 65536 字节，见上一笔 skill-size 钩子）：
- id-family-semantic-migration 33392 -> 10968（17%），reference 3 篇
- stale-doc-count-sweep 19811 -> 6945（11%），reference 2 篇
- mem-budget 19963 -> 13042（19%），reference 3 篇
- keil-build 12917 -> 8879（14%），reference 2 篇
- task-worktree 72601 -> 28139（42%），reference 8 篇

task-worktree 本笔同时收录另一会话已写完的 C2/D/G 三节正文——那
三处手改与我的拆分落在同一份文件改动里，不可分离；其内容同样已
随 reference/ 外置，主文只剩标题、索引与指针。

外置语料合计 122211 字节 / 30 篇：围栏数逐篇为偶，无 BOM/CR/U+FFFD。
draw-diagram 与 serial-boot-test 脚本是另一会话的在飞改动，本笔未含。

skill-size 钩子在本笔首次真跑（前一笔无 .dsh/skills 文件可触发）。

gate: pre-commit 全绿（doc-links、id-check-new、check-yaml、
      skill-size、check-added-large-files）；30 篇 reference 手工字节
      体检 clean；skill() 逐个复载确认加载的是拆分版。
 2026-10-29 15:03:12 +08:00
wandering1 c63bd029a9 feat(门禁): 新增 skill-size 钩子——SKILL.md 不得超插件写侧上限 65536 
dsh-mnemon 的 MAX_SKILL_BYTES = 65536 只在写侧校验，加载侧从不检查，
所以正文越界的技能照常加载、却永远生成不出草案：同日两次卡死
（83194 字节与 72601 字节）都是这个形态，复位台账无效，只能瘦身。
故把上限机械化，越界与悬空指针在提交期就拦下。

- scripts/check_skill_size.py：纯标准库（裸 python 也能跑，故不解析
  .venv）；FAIL >65536、FAIL reference/ 指针悬空、FAIL UTF-8 BOM、
  WARN ≥49152（75%——实测一次「采纳」把主文从 49821 顶到 62806）；
  总是全树扫，只拿 reference/x.md 触发的提交正是漏网场景；
  --root 可复指到用户级 ~/.dsh/skills；--selftest 五形态（干净 0 /
  临界 0+WARN / 超限 1 / 悬空+BOM 1 / 根不存在 2）全过
- .pre-commit-config.yaml 加 skill-size，files: ^\.dsh/skills/
- 新增 docs/门禁说明/skill-size.md，含盲区：拦不住插件自身的采纳写盘、
  用户级技能目录不在触发面、不解析 frontmatter、不查 U+FFFD
- 计数同步 51 -> 52（实跑 48 -> 49，索引 28 -> 29 篇）：AGENTS.md 与
  门禁索引，另 7 处文档旧计数改写、CI 指南带日期实测行只加注

本笔先落地，技能正文的渐进展开拆分在下一笔。
 2026-10-29 15:02:23 +08:00
wandering1 325abe4337 merge: task/screenlink-doc-factfix 合入 v2-on-ui 
按代码实况校正屏板链路方案文档（docs/任务规划/屏板链路.md）决策三的三处
口径，并补 DMA 收尾必须自写的三个全局回调、新建任务的正确落点、第四名目
「数秒量级的等待」及其推导/实测区分，另按「文档只写现状」清掉三处自我纠错措辞。

31c71295 单笔提交，1 文件 +30 / -12；树内逐文件门禁 RC 0。
 2026-10-29 13:30:35 +08:00
wandering1 31c7129562 docs(屏板链路): 按代码实况校正决策三的三处口径 
三处口径按仓库实况改写：
- 看门狗必需位掩码现值是 0x1F7（App/util/task_watchdog.c 的
  wd_required_mask：default/net/ftp/ui/timesync/adc/iec104/protect），
  本项的口径是「一个位都不加」，不是引用某个掩码常量。
- RTOS 堆是「紧张」不是「动态任务必然创建失败」：抬栈后台架实测
  free 16,400 / min_ever 8,464 B（口径 内存使用分析 §2.3）；768 字的
  退路任务只剩几 KB 余量，所以仍首选不新建。
- uiTask 那族阻塞里的「约 4 s」标成**推导上界**（netTask 内
  ch395f_poll_cmd_status(4000U) 六处调用 + 调用方 portMAX_DELAY），
  并补实测锚点：uis 峰 183 ms、uip 地板 61.3 ms、对时突发单轮 800 ms+。

补 DMA 收尾的现实约束：全工程没有任何 HAL_UART_TxCpltCallback /
RxCpltCallback 实现，HAL_UART_ErrorCallback 只有一处且只分发它自己
那条通道的句柄 → 三个回调都得自写并按 huart 句柄分发（写进 §1.3、
批 2 的 2-4、§6 风险行）。另记 .ioc 在仓库根、DMA2_Stream7 三处自洽。

§1.1 补新建任务的正确落点：Src/freertos.c 的 USER CODE 区 osThreadNew
是仓内先例，app_main_init 跑在 osKernelStart 之前、禁调创建类 API。

名目表加第四名目「数秒量级的等待」；defaultTask 的否决理由改挂到这
一族；§6 补一行采纳方案继承的 uiTask 挤占面（250 ms 日志排空、对时
突发）；§7 加第三条另测：7003 拥塞时串口侧照常应答。

同时按「文档只写现状」清掉决策三里三处自我纠错措辞。

只改方案文档一份；需求文档不含这三处口径，本轮未动。
gate: 逐文件 check_doc_links --sections-strict（29 处引用 / 27 可判定）
      与 check_ids_new 均 RC 0；合并后全量 ci_local 待他人技能文件
      提交后补跑（主树仍有他人未提交的在飞文件）。
 2026-10-29 13:30:06 +08:00
wandering1 f251162593 merge: task/data-trust-restructure 合入 v2-on-ui 
任务：数据可信文档台阶化重构（含信号发生器动态波形验证方案）+ 故障录波立项。
两笔提交共 19 个文件：新增两份录波文档与三张配图的生成器，重写数据可信并同步
索引、登记簿、需求与 UI 状态行。代码一行未动。

主工作树在本次合并前压着四个并发会话留下的未提交项（三个 skill 文件、AGENTS.md）
与一个未跟踪目录（task-worktree 的 reference/），本任务全部未触碰；合并前后用
blob id 与 diff --stat 对账，证据在 ci-artifacts/ext-blob-before/after.txt。

跳过的 done 前置由以下证据逐项补回：merge-tree 预演打出结果树且 RC=0；两笔树内
提交已过全部门禁（doc-links / id-check-new / generated-fresh / gitlint）；合并后
在主树跑全库 check_doc_links.py --all。
 2026-10-29 13:20:05 +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 4d68a614b7 merge: task/screenlink-doc-dma-host 合入 v2-on-ui 
屏板链路决策三改判：uiTask 组帧 + USART1 空闲中断点 DMA 起发，不新建任务。
只改两份文档；主树里他人未提交的三份技能文件由 pre-commit 自动 stash/restore，
合并后逐字节核对未变。
 2026-10-29 12:53:20 +08:00
wandering1 93e057abf2 docs(屏板链路): 决策三改判为 uiTask 组帧 + 中断点 DMA 起发 
用户问「那 200 ms 的阻塞一定存在吗」→ 逐条核屏板固件与主机侧观测面后改判。

- 拆名目：约 60 ms 是整帧的线上占用时间（硬），任务态轮询才是实现选择（可归零），
  200 / 280 ms 是屏板自己的计时器，不是成本
- §1.3：DMA 从「不是必须的」改为「整帧不断帧的唯一保证」，补 USART1 TX DMA 现成、
  全工程无人用、Stream7 无冲突的证据；缓冲必须落 SRAM 不落 CCM
- 决策三：采纳 uiTask 组帧 + USART1 空闲中断点 DMA 起发；不新建任务、不占堆，
  看门狗位掩码不动。原否决理由换成「起发不能挂在有 portMAX_DELAY 等待的循环里，
  抬优先级无效」——业务归属 uiTask 是对的，错的只是把起发挂在它的循环里
- 批 1 / 批 2 判据同步：起发在中断、整帧 59.6 ms 且无 2 字符以上间隙、组帧 ≤0.3 ms，
  2-4 由建任务改为帧缓冲归属与 DMA 收尾
- §4.4 补三条「不要做」、§6 补五行风险、§7 补两项实测；周期口径 275 → 280 ms
- 需求文档 §5.16.2：200 ms 由「硬指标」改为软放弃计时，硬约束改为零间隙 /
  正好 4208 B / 绝不让屏板溢出；补屏板实跑 705 882 bps（BRR=0x33，+0.84 %）
- 需求文档：时序表补第 41 / 56 拍与「有按键待报时最早 205 ms 再召唤」的撞总线窗口，
  判据 8、FR-UI 判据与 §9.13 批次表同步 280 ms 与主机侧计数口径
 2026-10-29 12:52:40 +08:00
wandering1 4da31c93c3 merge: task/screenlink-doc-history-cleanup 合入 v2-on-ui 
屏板链路两份文档删历史纠错叙述与冗余论证（27 + 7 处替换）。
只改文档，不动代码；构建与台架门禁不涉及。
 2026-10-29 11:16:47 +08:00
wandering1 fb359af5f6 docs(屏板链路): 删除自我纠错叙述与冗余论证，文档只写现状 
范围：产品需求设计文档 §5.16 全节（另清 §5.9 一处旧口径、
§9.13 一处旧阻塞）+ 方案文档 §0/§1.3/决策一/批 0/§5 收尾表。

删掉的历史错误叙述：
- 旧版本 BRR 推算写错那一整块（42 000 000 / 700 000 = 60 → 0x3C0）；
- "PA10 未接线这条旧结论已撤销"三段 → 压成一句现状；
- "原四项未知已消解"三处、"上表保留作为取证过程"；
- 调用契约表里四行已被屏板源码推翻的条目（下行长度、按键 TAG、
  面板指示灯、背光对比度）与"四项未知消解"块；
- 上行表键号 1~10 就地改成语义正确的 1~9，不再用更正注解释；
- 待确认清单里已定版的帧长一条（5 项 → 4 项，重新编号）；
- "第 14 条从待决定改为已决定不做" → 只写"已决定不做"；
- §9.13 末尾"已消解的旧阻塞"整块；§5.9 "旧口径…作废" 一句。

压缩：readme 3208 B 冲突注 5 行 → 4 行；16 B/29 B 论证 15 行 → 6 行。
顺带修掉上一轮删除后留下的三处悬空表述（"比换收发器便宜"、
"原来的速率死结因此消失"、"§0 第 2 行"）。

刻意保留：屏板固件源码符号与常量（275 ms / 200 ms / 4208 B /
700000 8N1 的出处）、UART4 冻结簇那一行与"为什么是 USART1"的
选型依据——它们是依据不是历史。

口径依据：docs/文档规范.md 已裁定"新文档不再设变更记录节，
文档只写现状"。

核验：doc-links --sections-strict 两份文件均 RC 0（161 处章节引用，
98 % 可判定）；新增行编号门禁 [OK]；无 BOM / CR 0 / U+FFFD 0 /
无连续空行 / 单个 LF 结尾；表格列数与 HEAD 逐项比对 0 处不一致。

净变化：需求文档 +36 −73，方案文档 +7 −9。
 2026-10-29 11:16:19 +08:00
wandering1 beeb8059c1 merge: task/screenlink-doc-scope-cleanup 合入 v2-on-ui 
任务 screenlink（1 个提交）：屏板链路规划只讲屏板通道本身，
删除与本方案无关的其它串口通道对照内容。纯文档改动，
提交期钩子全绿（文档链接 / 新增行编号门禁 / gitlint）。
 2026-10-29 09:29:40 +08:00
wandering1 1c39785b72 docs(屏板链路): 删除与本方案无关的其它串口通道对照内容 
用户裁定：屏板链路方案只讲 USART1 屏板通道本身，全文不得再
出现另一条采集通道的任何内容。四类处理：

- 整段删除：外部总线模块的条件任务（原 1-4）、总线极性与
  方向切换两条风险行、方向控制「并进 sb_link.c」一句、两条
  以另一通道驱动为对象的禁区（改它的缓冲常量、用 HAL_Delay
  做建立延时）、§8 开头「与暂缓专项无关」的对照说明、决策二
  表里另一通道那一行及其网表考据警示、决策一里两条已作废的
  历史换方案与选型告诫。
- 改为不点名表述：全局 UART 回调的现有分发对象（给按回调名
  全库检索的定位方法）、屏板接收侧 CRC 错静默丢弃。
- 术语平实化：半双工方向控制 → TX / RX 两根独立线（全双工）。
- 顺带修 4 处批 0 序号引用（0-1 挪线、0-2 迁日志口），其中
  2 处是本次删除后暴露的前后不一致。

校验：被删主题的全部关键词（通道名、驱动文件名与常量名、
器件型号、总线与方向术语）全文 0 命中；Markdown 表列数一致；
UTF-8 无 BOM / LF / 无 U+FFFD；check_doc_links 逐文件通过、
check_ids_new 通过；333 → 310 行。纯文档，不动代码，不涉及
RAM / Flash 数字与 @build。
 2026-10-29 09:25:26 +08:00
wandering1 49cddac0dd docs(门禁计数): 工作树方案的「31 钩子」改回声明的 51——同文件第 22 行本就写着 51 
真值三源互证：YAML 解析条目数 51（仓库口径的自查命令）、带 stages:[manual] 的 3 根、AGENTS.md 的
「共 51 个钩子 / 提交期实跑 48 根」、门禁说明 README 的「声明的 51」与「51 个 hook → 28 篇」、
pre-commit 使用说明的「51 声明数，一次 git commit 实跑 48 根」——全部一致，唯一离群值就是方案文档
那条表格行里的 31；而同一份文档第 22 行自己写着 51，属文档内部自相矛盾，这是最硬的判据。

:248 取 51 而不是 48：该行主语是 ci_local，本次实跑日志实证它覆盖静态 passed=47 + manual 三根 rc=0
+ gitlint 十条，正好是声明的 51 根全跑；48 是「一次 git commit 实跑」的口径（47 静态 + gitlint），
两个数分列、不许混写。同时把裸数字改成带出处指向的写法，下次加钩子这里少一个查不到来源的数。

远程CI 指南那处只加「当时」两个字：26 是 2026-10-12 那次 gitlint 环境事故的观测值，数字本身不算错，
但句子是现在语气，会被读成今天静态段的条数（现 47）。按计数同步 playbook 的最小动作加注，不重述数字。

冻结并写明类别：pre-commit 使用说明的「当时 40 个 hook」、主机单测覆盖率口径的 39/16（句中已有
「当时」）；同数不同义不动——run_boot_test.py 的「31 份 boot_log」是日志份数、verify_log.py 的
rec[31:59] 是字节偏移；命中面之外不动——.venv/ 与 Lib/ 第三方、.git/ 内的 stray 报告。
邻族实测自洽、本轮未碰：22 根专属钩子 + 19 套无专属 = 41 套、28 篇索引、51/48/47 三分列。

门禁：编号门禁 [OK]；doc-links --all --sections-strict RC=0（2602 处引用、无法判定 0、194 文档，
章节引用 +1 就是新增的这处 §2 指向）；两文件无 BOM、CR=0、无 U+FFFD、无行尾空格、结尾单 LF、
表格仍为 5 列；旧形态复扫「31 钩子 / 31 个钩子 / 31钩子」全仓命中 0。改动不落体积门禁指纹面，
不需要 @build。
 2026-10-29 08:54:41 +08:00
wandering1 8cab390aa7 chore(task-worktree): 活跃任务上限 3 提到 8——磁盘不是依据，锁排队才是（引用面 15 处同步） 
唯一事实源是脚本常量 MAX_CONCURRENT（task_worktree.py:30），报错文案与 new 的插件树提示都插值它；
其余全是引用面同步：SKILL.md 12 行（含 frontmatter 的 description 与 whenToUse——它会进技能目录）、
方案文档表格行 + 依据段重写、启动日志原子性复验流程 1 行去掉数字。

依据段按今天的实测重写，不再拿磁盘当理由：一棵纯净检出 84.0 MiB / 2857 个受控文件（docs 独占
46 MiB），.venv 与 simulator/SDL2 走目录联接共享、不随树复制，D 盘余 1.4 TB → 8 棵全开最坏约
3.2 GB（每棵再叠一次构建产物：Keil 中间件 289 MB + 模拟器 35 MB）。真正随并行数上涨的是排队：
build 锁 TTL 1.0h、bench 锁 TTL 6.0h 分别串行化 @build 与 @test，done 的合并也必须串行——8 棵是
8 个空间，仍是一套 Keil 授权 + 一块板。

扫描按全形态跑（上限 3 / 最多 3 / 第 4 棵 / MAX_CONCURRENT = 3 / 硬上限 3 / 名额），整行打印后
另抓到两处只按数字搜不到的形态：whenToUse 里的「白占 3 个名额之一」、「确实要同时开第 4 棵」
（上限变了它必须跟着变第 9 棵，否则自相矛盾）。

冻结不改并写明类别：带日期戳的历史测量（2026-10-28 一次回收 3 棵、各 89 MB）、用户原话引语、
列表与步骤序号。「83 MB」是当时 du 口径、与本次内容字节和 84.0 MiB 同数不同义 → 只补口径注并
指回方案 §4，不合并成同一个数；方案 §2 的「对象库 234 MB」保留——今天的 294 MB 含待两周宽限期
过期的不可达对象，不把临时态钉进文档。

本轮我自己写错并已改掉：新段落引用了不存在的子命令 lock list，真命令是 lock status（全仓零残留）。

验证：上限生效用 %TEMP% 隔离小仓实测（脚本按同深度拷贝，因 REPO_ROOT 由 __file__ 反推）——前 8 棵
全成功，第 9 棵 exit 2 且文案为「已有 8 个活跃任务（上限 8）」，--force 照旧放行，list 9 行；真仓
零副作用（worktree list 仍 1 条、同级 _wt 无新建目录、无 t0* 残留）。门禁：doc-links --all
--sections-strict RC=0（2601 处、无法判定 0）、编号门禁 [OK]、py_compile RC=0、四文件无 BOM、
纯 LF、无 U+FFFD、无行尾空格。改动不落体积门禁指纹面，不需要 @build。
 2026-10-29 08:44:03 +08:00
wandering1 1576d7b709 fix(task-worktree): 联接列改三态点名——半联树不再被说成已联，adopt 没补齐不许报就绪 
同一个谎有两处，根因是「联没联上」有两套判定：列表只取样 JUNCTION_SPECS 首项
（.venv），而 adopt 填两条。于是「有 .venv、缺 simulator/SDL2」的半联树被报成已联，
adopt 遇主线缺 SDL2 走 skip、联接失败走 warn，回来照样打「现在可以跑」——宣布就绪。

改法是把判定收成一处：
- 新增 junction_states() 三态（link / real 实体内容 / absent 真缺）与 junction_label()，
  plugin_trees() 改读三态；adopt_junctions() 也改读同一函数，消除两处逻辑分叉。
- 列表按缺的那一样分别说后果：缺 .venv 会**静默**落到机器级解释器（无 fontTools，
  即 generated-fresh 假红的老根因）；缺 simulator/SDL2 是模拟器当场报错（CMakeLists.txt
  的 SDL2_DIR 是裸 set，没有环境变量逃生口）。实体目录单列齐(实体SDL2)，不算共享。
- adopt 补完复算一次，仍缺就打「还不能算就绪」，不再打「现在可以跑」；锁归属与
  锁命令照常打印。
- SKILL.md 同步四处措辞，并把「adopt 之前跑不了 Python」这条不准确的说法换成上面
  两种真实失败方式（一条是静默错解释器、一条是响亮报错）。

验证：scratch 仓 16 条断言全 PASS（全联 / 只摘 SDL2 那条 → 缺 SDL2 且不得再出现已联 /
实体目录不被覆盖 / unadopt 只摘联接 / 主线缺 SDL2 时 skip + 不报就绪 / 已联的 .venv
不误报 / 两样都缺 → 缺 .venv+SDL2），同一半联态上新旧对照 = 缺 SDL2 vs 已联。
py_compile 通过；doc-links --all --sections-strict 与编号门禁绿；两文件无 BOM、无
U+FFFD、纯 LF、无行尾空格。改动只落在 .dsh/，不进体积门禁指纹面，也不需要 @build。
 2026-10-29 08:18:49 +08:00
wandering1 db5109e41d chore(size): 重打体积同码凭证——补上一笔注释收尾提交的同码缺口 
@build 0 错误 0 警告之后跑 ram_baseline.py --update：新增 2026-10-29 趋势行，并由它
自动 --stamp 重打 scripts/size_attestation.json。

数字与 2026-10-28 那行逐项相同（Code 236,456 / RO 28,124 / RW 1,876 / ZI 137,084；
RW_IRAM1 62.2%、RW_CCM 87.9%，红线 92%）——所以缺的不是体积变化，是"这份源码对应
一次真实链接"的同码性：上一笔收尾提交改了保护任务源文件（纯注释）却没有重测，凭证
自那次起一直红着，主干 push 会被它拦下。

现在 check_size_gate --show 与 --local 均判同码通过；本地 CI（含体积步）全绿。
 2026-10-29 07:50:33 +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 5f69f38dfd chore(term): 并发会话收尾四处——注释术语、引用路径、计数解绑 
这四处是并发会话留在工作区的完成态改动，按用户「全部都提交」一并
入库，逐项依据如下。

- App/task/protect_task.c：三处静态变量注释「上拍」→「上一拍」，
  纯注释无语义变化。@build 实测 0 错误 0 警告（Code=236456
  RO-data=28124 → ER_IROM1 264580，与 scripts/size_attestation.json
  同数；RW=1876 / ZI=137084）。
- docs/UI设计/RemoDispBus协议与接收设计说明.md：补术语同义说明
  （「远程显示」与「远程画面推送」同义，都指 RemoDispBus 推流）。
- docs/测试说明/m2_data/README.md：对端脚本路径改为
  test/host/latency_peer.py——原写的 test\latency_peer.py 已不存在
  （实测 No such file，脚本现落在 test/host/ 下）。
- docs/环境与部署/并行任务工作树方案.md:408：索引行改为「提交门禁
  钩子逐项详解」，不在文档里写死钩子条数（声明数唯一口径源 =
  docs/门禁说明/README.md §2，加钩子时少一处必改点）。

门禁：pre-commit run --all-files = 47 根 Passed、0 Failed，rc=0。
 2026-10-29 00:58:23 +08:00
wandering1 41670a1cc6 docs(gates): 主机单测套数复点同步——41 套 / 无专属钩子 19 套 
第 41 套 boot_stats 由 728d6067（2026-10-27 11:29）入库，全仓写的
「40 套 / 18 套无专属钩子」从那天起过期；本轮按实测复点同步。

真值双源互证：test/host/*/run_unit_test.py 实数 41（43 个目录，除
common 与 __pycache__）＝ scripts/check_test_coverage.py 自报
suites=41/41。专属钩子 22 根（YAML 解析 id 以 -unit-test 结尾，
22 条全对得上有 runner 的目录）⇒ 无专属钩子 19 套 = 41 − 22。

改当前态共 18 处：AGENTS.md 提交门禁节三处、.pre-commit-config.yaml
test-coverage 注释、docs/门禁说明/host-unit-tests.md §6 第 4 条六处
（无钩子名单首位补 boot_stats、目录数 42→43、裁定句改「裁定当时
18 套，2026-10-28 现值 19 套」）、docs/门禁说明/README.md、
docs/代码规范/pre-commit使用说明.md 两处、docs/编号规范.md、
scripts/README.md、docs/任务规划/分工说明-20261028 一条、
docs/测试说明/主机单测覆盖率口径.md 追加 2026-10-28 = 41 套 ~105 s
新实测点、test/host/sys_log_mcu/sys_log_mcu_test.c 注释行。

刻意不动：带日期戳的历史耗时与套数行（只追加新的实测点，不覆写）、
host-unit-tests.md 里「22 根 / 40 套 / 18 套无专属钩子」这句复核原文
（只在后面追加更正）、scripts/archive/id_gate/ 留档两处、
同数不同义的五处（40KB 级 / −20~40% / 不到 40 行 / 18 断言点 /
板端 RTC 套件）。钩子数 51、专属 22 根、提交期实跑 48 根本轮实测
未变，相关句一字未动。

门禁：doc-links --all --sections-strict / id-check-new --worktree /
no-mojibake / bom-drift / validate-config 全 rc=0，
test/host/sys_log_mcu 单测 rc=0；改后复扫「40 套」仅剩 3 处
（1 处刻意保留 + 2 处留档）、「42 个目录」0 处、「18 套」仅剩 2 处
（都带「当时」口径）。
 2026-10-29 00:58:23 +08:00
wandering1 295eb9911f ci(gates): 覆盖率总闸与全量 cppcheck 移到远端 CI 强制（提交期实跑 48 根） 
用户裁定 2026-10-28：慢钩子不再压在每个 git commit 上，由远端
CI 强制；本地等价入口 = scripts/ci_local.py 的 manual 段。

实测三根耗时：cppcheck 20.5 s、test-cppcheck 38.1 s、
test-coverage 105.2 s，合计 ~165 s ≈ 一次带代码提交耗时的
三分之二（test-coverage 的 files: 覆盖 App/，改一行就跑光 40 套）。

- .pre-commit-config.yaml：cppcheck / test-cppcheck /
  test-coverage 加 stages: [manual] + 理由注释；替换掉
  test-coverage 上方「没写 stages → 所有阶段都跑、输出出现两次」
  的旧坑注释（固定 manual 后不再有这一坑）。
- .gitea/workflows/ci.yml：static-gates job 在静态门禁步之后
  新增「手动阶段门禁（覆盖率总闸 + 全量 cppcheck）」步，
  if: always()，逐根 --hook-stage manual（pre_commit run 不支持
  多 id），日志 ci-artifacts/manual-stage.log + 归档 + STEP_SUMMARY，
  rc≠0 即失败；run 块纯 ASCII。
- scripts/ci_local.py：新增 MANUAL_STAGE_HOOKS 与 run_manual_stage()
  （静态段之后默认跑），删 run_coverage() 死代码，--coverage
  降级为兼容别名。
- AGENTS.md + 12 篇 docs/scripts/README：三数同源口径改为
  声明 51 / 提交期 --all-files 实跑 47 / +gitlint = 48，
  其余 3 根在 manual 阶段；历史测量数字只加「当时」不回改。

验证：pre-commit run --all-files = 47 Passed / 0 Failed rc=0；
manual 三根 Passed（test-coverage line 89.8% func 93.2% 41/41 套）；
ci_local.py --static-only 全绿；check_doc_links --all
--sections-strict rc=0、mojibake / bom-drift / id-check-new rc=0；
ci.yml yaml.safe_load 通过。未改任何 .c/.h，故未跑 @build。
 2026-10-28 23:04:59 +08:00
wandering1 e9cae5fdcd chore(size): 重打体积凭证（合树后同码 @build 0/0，数字未变） 
前面几笔（含并发会话那两笔）改动了在册文件，凭证指纹还停在 21:41 的
索引上，体积门禁因此报「代码与测量不同码」。现在按合树后的状态重打：
@build 0 错 0 警，Program Size Code=236456 RO=28124 RW=1876
ZI=137084，与 scripts/ram_baseline.tsv 的 2026-10-28 行完全一致，
所以台账不追加新行（ram_baseline.py --update 自行判定同码不重复登记）。

check_size_gate.py --stamp / --local 均 rc=0。
 2026-10-28 22:24:33 +08:00
wandering1 261bd9fd31 fix(keil-build): 定性并挡住 %SystemDrive% 字面量垃圾目录（并发会话在飞工作） 
@build 与 fontTools 类脚本在残缺环境里起子进程时（run_code 的 Node
进程 process.env 为空），Windows known-folder 的**可展开串**展开不了
→ 变成相对路径，于是仓库根长出 %SystemDrive%/ProgramData/Microsoft/
/Windows/Caches/（约 1 MB 缓存的字面量复刻），它不是任何人在飞的改动。

- SKILL.md：新增「构建副产物」一节——症状 / 根因（三条现场证据）/
  清理（只用 bash 引号形态，明令禁止 rd /s /q %SystemDrive%，cmd 会
  把它展开成 C: 等于对系统盘下令递归强删）/ 两层防复发（.gitignore
  已入库 + 脚本守卫），并在坑表加一条速查
- keil_build.py +115 行：拉起 UV4 前 harden_windows_env() 回填缺失的
  SystemDrive/SystemRoot/ProgramData/USERPROFILE/TMP 等并就地展开残留
  的 %VAR% 字面量，命中打 WARN: ENV_SPARSE；构建后
  check_percent_literal_junk() 见到字面量目录只打 WARN: JUNK_DIR 并
  给出安全删除命令（守卫是兜底不是许可：@build 仍须走继承完整环境
  的 shell，删目录也不由构建脚本代劳）

py_compile 通过、--help 正常。本笔是并行会话在飞的改动，按用户
「把所有内容都 commit」的指示代为落盘；要退回：git reset --soft HEAD~1。
 2026-10-28 22:22:59 +08:00
wandering1 16be01915d chore(docs): 补齐文件末尾换行（end-of-file-fixer 实测 18 篇）
CI / 静态门禁 (pre-commit) (push) Failing after 46s
Details
CI / 主机侧单测 (MSVC) (push) Failing after 43s
Details 
提交后台跑 scripts/ci_local.py 时 end-of-file-fixer 报 Failed 并就地修复：
17 篇补文件末尾换行、1 篇去掉行尾空行。

内容零变化：git diff --ignore-all-space 只有 1 处空行删除；18 篇均在
上一笔流水清理里被改过，恢复补丁时把上一轮的 EOF 修复冲掉了，这一
笔补回。
 2026-10-28 22:12:59 +08:00
wandering1 94cce8b615 docs+scripts: 删除测试与架构专项文档并把引用改成就地口径 
这是并行的另一路在飞的改动（本会话按用户「全部提交」指示代为落盘）：
移除 docs/任务规划/测试与架构专项.md，并把指向它的引用改成就地口径
（app_assert.h / net_socket.c / ch395f_test.h 头注释改指本文件注释或
对应文档，check_size_gate.py 与 ram_baseline.py 的出处改指 CI 文档，
RAM预算台账、暂缓-RS485、采集与算法层设计说明、cubemx-survival、
id-check、两份 README 同步改引）。

如要拆回：git reset --soft HEAD~1 即可把这一笔退回工作区。
合树后 @build 0 错 0 警（Code=236456 RO=28124 RW=1876 ZI=137084）。
 2026-10-28 22:00:34 +08:00
wandering1 511fd30cc6 docs: 清理全仓变更记录流水（43 篇整节删 / 23 篇留一行 / 5 篇保留） 
用户裁定：文档只写现状，历史流水一律删掉，过程查 git log。

- 43 篇「变更记录 / 修订记录」整节删除：继电保护规划 12.6 KB、产品
  需求 11.8 KB、项目部署环境 5.5 KB、BSD Socket 指南 5.3 KB、架构
  总览 5.0 KB、实机测试实施指南 3.8 KB 等
- 23 篇别处仍有指向：只留节名 + 一行「本文件不再记流水账，过程查
  git log」，节号与锚点不位移（doc-links 不因此断链）
- 5 篇整表保留（被当唯一证据 / 活台账引用）：看门狗设计说明、配置
  文件设计说明、RAM预算台账、内容页架构、本地工具路径环境变量方案
- 规范同步：文档规范 §5.1 改新裁定；测试文档模板规范删示例节与
  登记句；测试开发标准流程 / UI 两篇 / 实机测试实施指南 / 四篇单测
  说明 / 并行任务工作树方案 / 编号规范 的「登记变更记录」改「写进
  正文」
- 技能同步：stale-doc-count-sweep / ui-verify / id-family 三个 SKILL
  正文不再要求追加流水行（顺带消掉 SKILL.md:121「产品需求 §12」
  失效引用）
- 修 5 处悬空指针：采样有效性校验目录锚点、BSD 指南「文末变更
  记录」、docs/README 过期描述、网络自愈架构两处指向面

72 篇文档净减 600 余行；check_doc_links --all --sections-strict 可判
定比例 61% → 78%、失效引用 0；静态门禁 passed=50 failed=0；gitlint
10 条历史提交信息 0 failed。

未提交他人在飞改动：.dsh/skills/keil-build/*（%SystemDrive% 守卫）。
 2026-10-28 22:00:34 +08:00
wandering1 0e4cc03c2d docs(ADC): 更正注入验证口径——已知电压注入 2026-10-27 台架已闭环 
数据可信.md §2.6 原写「ADC 从未采过已知电压」，那是 2026-10-23 挂账
时的现状，与 2026-10-27 的台架实测矛盾——按现状重写：实测 × 判据表 +
④ 段（端子 → AINn 子板变比）缺口 + M4 承诺边界（只到 ADC 引脚电压、
eng = 0）；§2.6 节号与「承诺边界」口径保留，代码头注释的引用不断。

同族陈旧现在时一并更正：继电保护规划「引脚级注入验证仍为待做项」、
ADC通道映射 §7.1「不填任何实测数值」、ADC输入层单测说明「板端无信
号源、无法验证读到的是哪只脚」、adc_input.c 与 test/host/adc_input
两份注释「注入验证做不了」→ 统一改成「台架已一次性验过（§8.1），
主机单测与开机自检仍必要」。首帧悬案等历史叙述删除，只留结论。

顺带：ADC 输入层单测计数 101 → 103（runner 报 103/103 与 CHECK 调用
点 103 处双源互证），test/host/README.md 同数同步。

验证：@build 0 错 0 警（Code=236456 RO=28124 RW=1876 ZI=137084）；
test/host/adc_input 103/103 rc=0；check_doc_links --all 0 处失效；
该批文件里的变更记录节按同日裁定一并清理。
 2026-10-28 22:00:33 +08:00
wandering1 8f8d97b3d8 docs(编号): 批次六余账文档面——CubeMX 层号、双写疤、采集链旧层名共 61 站点
CI / 静态门禁 (pre-commit) (push) Failing after 8m4s
Details
CI / 主机侧单测 (MSVC) (push) Successful in 27s
Details 
- CubeMX 防丢失三层优先级 L1/L2/L3（批次 3c 漏网 30 处）：看门狗设计说明 25、
  门禁说明/cubemx-survival 3（含「优先 L1/L2」→「优先写进 .ioc 与搬进 USER CODE
  区」）、ADC通道映射 2。
- 改名遗留的中文重叠双写 14 处：菜单页面设计「一级菜单菜单」×6、「二级菜单菜单」
  ×2；README「语义取数与有效性」重复；存储架构「3字节字节地址」；链路延迟
  「队列往返队列往返」；继电保护「出口出口与记录层」；产品需求「全周傅氏相量」重复。
- 采集链旧层名 5 处：「L2 相量层」→ 全周傅氏相量、「L0 采样驱动」→ 采样驱动层、
  「L2-x 前缀」→ 相量输出标签前缀、「L1 层 v2.3」→ 语义取数与有效性层 v2.3。
- UI 菜单层级 2 处：产品需求「4 级（L0~L3）」→「4 级（主界面 / 一级 / 二级 /
  三级菜单）」、「主界面 (L0)」→「主界面」。
- 登记簿条目改名「L5 队列往返基线待重验」→「队列往返基线待重验」+ 引用侧 5 处
  同步（登记簿 §1/§7、实机测试实施指南 §7.3 与步骤表、编号规范 §1 好例子清单——
  那个混在短语里的 L5 恰恰是个坏例子）。归档里的历史 note 原文不动。
- 归档 §10.3：四族收口记录 + 边界与裁定（peer JSON 键属冻结证据 schema 不改；
  REQ2FIRST / FULLFRAME 不并入 FRAME_RT；L1-3/L1-4 属不可还原死号，就地删号留
  事实；「原 L2 基线 3/10」按上下文读作主机侧回归的早期基线）。
- 判族保留（永久）：硬件位号与封装尺寸 27 处（网表 L1~L3 磁珠电感、
  SOT-23_L2.9-W1.3、CRYSTAL-L3.2）、芯片手册原文 3 处双写；伪命中 4 条没删
  （「遥测量 测量值」「已登记登记簿」「谁来监视监视者」×2）——那些是正常词组。
- 门禁：check_doc_links --all --sections-strict 通过（195 篇、章节引用 3292 处）；
  git diff --check 干净；逐文件 BOM / U+FFFD / CRLF 与 HEAD 一致。
 2026-10-28 18:57:03 +08:00
wandering1 da36f4ba56 refactor(编号): 自愈层号与 timeSync 挂起、CubeMX 三层、采集链层名清号（代码面） 
批次六余账之二（代码与脚本面）。四族都是「批次一 / 三c 改了文档、漏了代码」的半改
状态。

- 日志自愈：「L1 文件级自愈」→「文件级自愈」、「L2 错误去重」→「错误去重」（正文
  本来就这么叫，层号纯属多余）：App/log/soe_store.c、sys_log_mcu.c 三处、
  test/host/sys_log_mcu 的测试与假件头共 10 处。
- timeSync：「L3 pending 化」→ 挂起请求 / pending 化——这条口径早写在记忆里，
  今天才算全仓一致。App/sync/time_sync.c 3 处。
- CubeMX 防丢失三层优先级：scripts/check_cubemx_survival.py 6 处「由 L3 升级为
  L2」「L2 受保护」「L3 兜底」→ 写进 .ioc / 搬进 USER CODE 区 / 审计兜底；变迁史
  句子按「换号留事实」改写、日期原样保留。
- 采集链旧层名：App/README.md「采集与算法层（L1/L2/L3）」→「采集与算法层」；
  protect_task.c/.h「（L3 板端接线，B5）」→「（板端接线，B5）」。
- phasor 断言文案 19 处：改为 ASCII 的 phasor-in ring（C 字面量必须纯 ASCII）。
  改前先证明这些串无耦合——全仓只有本文件含它们、harness 只看 returncode 与汇总
  标记；改后 phasor 57/57 与基线同数。
- 零行为：剥注释 + 套登记表后与 HEAD 逐字节 / AST 相同；sys_log_mcu 141/141、
  phasor 57/57、watchdog 47/47、freq 46/46 均与动手前基线同数。
- 同一四族的文档面（CubeMX 30、采集链 5、菜单层级 2、双写 14）由下一笔收。
 2026-10-28 18:52:37 +08:00
wandering1 6572591181 refactor(编号): 链路时延段号 L1~L11 → 权威 ASCII 段名（含 C 宏名与 peer 变量） 
批次六余账之一。批次 3b 当时只改了 net_latency_test.c 的日志串与注释，本笔收掉剩下
的：标识符、peer 脚本、其余四个 board 文件。

- 段名映射（权威表在 scripts/archive/id_gate/编号治理历史.md §10）：SPI_CMD /
  SPI_DMA / CHUNK_WAIT / TO_PC / QUEUE_RT / ECHO_RT / FRAME_RT / PROD_CYCLE /
  RELISTEN / LOGTAX / UI_LOOP。C 侧纯 ASCII，文档侧沿用中文段名。
- C 标识符 29 条规则 86 token：LAT_P13_OP_L5_RECV → LAT_P13_OP_QUEUE_RT_RECV、
  P13_ST_L3 → P13_ST_CHUNK_WAIT、LAT_P13_L3_SAMPLES → LAT_P13_CHUNK_WAIT_SAMPLES，
  并把文件内既有的 CW / QRT / LT 三个缩写前缀一并展开成同一套词，不留两套词汇。
- REQ2FIRST / FULLFRAME **不并入** FRAME_RT：它们是整帧往返段内两个不同测量
  （报告标签本就叫 req2first_mcu / fullframe_mcu），并入会撞名并丢掉区分度。
- peer（test/host/latency_peer.py）42 条标识符 + 7 个小写局部量 + 操作表整表重排。
  **JSON 输出键 l5_recv / seg_l6 / frames_l7 等 48 token 刻意不改**——它们是
  docs/测试说明/m2_data/ 五份冻结实测数据的 schema，改名等于让代码与归档证据
  漂移；边界与理由写进归档 §10.3，是**有记录的例外**不是漏网。
- 注释 23 处；顺带修一处上一批路径残留：peer 被写成 test/latency_peer.py，实际
  在 test/host/ 下，三处注释改对。
- 站点：test/board 111 + Drivers/BSP/CH395F/ch395f.h 1 + peer 46（无词边界口径）。
- 零代码生成变化：@build 改前/改后各一次，均 0 错 0 警且 Program Size 完全相同
  （Code=236456 RO=28124 RW=1876 ZI=137084）。被改名的标识符全落在
  ENABLE_PHASE13_TESTS 区间内 → 另开 TEST_SUITE_CH395F + PHASE13 组合编一次
  （0 错 0 警），套件开关事后无条件还原、sha256 与还原前一致，再重建产品构建。
- 等价证明：剥注释 + 套登记表后与 HEAD 逐字节相同（not_equivalent=0）。
- 禁改一字未动：console_log 的 "L1\r\n"（测试数据）、lftpd 与
  ftp_capture 的 "215 UNIX Type: L8"（FTP 应答断言）。
 2026-10-28 18:49:45 +08:00