 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
|
15aa08552c
|
docs(问题记录): 删除项目审查与优化建议报告，结论并入模块文档与编号规范
用户裁定：该报告大部分内容已闭环，可删除；仍有价值的迁到合适文档。删前逐条核对，
确认绝大多数结论在仓内早已有权威副本（LV_DRAW_SW_COMPLEX / osFlagsNoClear / SPI 分频 8
/ 分层反向依赖存量基线等），只迁真正独有的四类内容：
1. 暂缓理由与重开条件（三条量化门槛）→ RAM 使用分析与优化方案 §4，并明确「本节是唯一
权威」，其它文档只留指针；同时把 10 处指向报告 §5.3 的重开条件引用改指该节。
2. 2026-10-22「常驻 vs 动态」三项诊断（静态前五块 43,462 B = 58%；动态面只有 heap_4，
故栈余量=CCM 余量；栈深主因是日志/配置写链）→ 同文档 §2.5。
3. `_fp_digits` 1,018 B 删不掉的机理与 F-6 根因修法（Q10 宏改单精度，−332 B，4.49e6 例
逐位等价）→ §2.6.4。
4. 「UI 侧缓冲进 CCM」要按 DMA 可达性二分（LVGL 池可进，帧缓冲/推流缓冲不可）→ 暂缓清单。
编号侧（报告曾是 6 个族的属主登记处）：
- 原报告 §9 的 26 行「号 → 现在详述于」对照表迁到 docs/编号规范.md 新增 §4.5，6 族
owner_docs 改指该节。规范正文含大量写法示例，直接当定义集会误伤，故 check_ids.py
新增 `_def_owners`：snapshot_only 族剔除规范正文，只恢复可判定、不参与悬空/撞号/裸形
/紧邻判定（实测若不分，裸形 S1 误报 238 条、S-3 与登记簿 S-3 误判重复定义）。
- 11 个已死号（N-03b/N-10~N-13/N-20/N-21/N-24/N-26/S-1/S-2）在 id_aliases.json 登记
status=void 并写明去处——它们被约 110 处代码注释与文档引用，原先只靠「报告里顺带提过
一句」才算有定义，报告一删就集体悬空。N-21/S-1/S-2 一号两义，注记已分别标明。
- 顺带修 id_aliases.json 的 note 被脚本累积重复 26 次；修 registry 里 3 处仍指向改名前的
任务卡文件名（W1-采集保护收尾.md / W8-数据可信.md），以及 iec104_master.py 两处同类注释。
门禁：check_ids --strict 通过（可判定 8747/10410 = 84.02%，基线由 82.6% 抬到 84.0%）；
check_doc_links --all --sections-strict 通过（177 文档）；pre-commit 相关钩子全过。
|
2026-10-25 02:08:58 +08:00 |
|
|
wandering1
|
2bfa09ed15
|
feat(门禁): 主机单测覆盖率脚本与口径落地（销报告 §4.8 空白 ①）
落地物：
- scripts/check_test_coverage.py：发现规则与 L0.5 同一条（test/host/**/
run_unit_test.py），直接 import 各运行器复用其 TestBuild 与
unit_test_harness._BASE_FLAGS —— 配置零复制，不会漂出第二套口径；
只算自研生产源码（App/**、Drivers/BSP/**）的行/函数、多套取并集、
生成物（文件头写"自动生成/请勿手改"）不进分母、分母一律来自插桩
报告不猜行数；中间物全在 %TEMP%，不新增 .gitignore 规则。
- scripts/test_coverage_baseline.json：增量拦截台账（只拦回退不拦进步，
与 layer-deps / bsp-err 同姿态）；ci_local.py 加 opt-in --coverage。
- docs/测试说明/主机单测覆盖率口径.md：口径 + 工具链实测 + 九条盲区。
- 报告 §0.1 / §0.4 / §4.8 / §5.5 / §7 改写 + 变更记录 + 去处表。
工具链是实测出来的（换机必读）：Windows 原生侧无任何 gcc/gcov（全盘扫
Program Files*、msys64、scoop、choco、.platformio、LocalAppData = 0 处）；
MSVC 14.51 已砍 /coverage，且只报 D9002 后照常编译成功 = 静默假数据；
CodeCoverage.exe 17.0 三个子命令只打印用法。最终用 mscoverage 18.x
（Microsoft.CodeCoverage.Console.exe）collect -f cobertura 做加载期动态
插桩，并实测它透传子进程退出码 → "插桩运行下仍必须 PASS"可当硬条件。
首登数字：16/16 套插桩下全绿，并集 line=2552/2893（88.2%）、
func=193/207（93.2%）、19 个文件在测、**未触及 125 个生产源文件 /
约 11,839 行**——最后一栏才是这套口径真正照出来的东西。
门禁自证：人为抬高基线后 行/函数/总计 三条回退路径都报 REGRESS 且
退出码 1；--module 子集跑不再假报总计回退（首版会，已修：并集口径下
子集必然变小，全部回退判定只在全量跑时生效）。
GCC 追问的复测结论（口径文档 §2.1 决策记录）：本机 WSL2 Ubuntu 确实有
gcc/gcov 15.2.0，16 套单测在 gcc 下全部编过、用例数与 MSVC 逐个一致，
gcov -b -c 也确实给出分支覆盖（nand_ftl.c 分支至少走过一次 41.40%）；
但换编译器=换分母（sha256.c gcc 105 行 vs MSVC 114 行；adc_input.c 101
vs 120）。**用户裁定：本仓只留 MSVC 一条覆盖率通道**，不建第二条——
多一套工具链就多一套分母、多一本台账、多一个"这台机器到底有没有 WSL/
gcov"的未决项，换来的只有分支这一维。分支覆盖因此**记为已接受缺口**
（不是待办）：绿灯只证明行与函数被测到，补偿判据 = TC 双向追溯 +
用例显式列边界值；§8 写明重开该裁定的前提是先答"两份分母怎么对齐"。
刻意未挂 pre-commit：16 个单测钩子已经跑过同一批测试；依赖 VS 可选
组件（缺组件时 skip 会静默失效、FAIL 会拦换机）；待一个真实回退事件。
YAML 片段与理由写在口径文档 §8。
自查：pre-commit run --files（6 个改动文件）全 Passed；check_doc_links
--all 回到存量 35 处（本分支贡献 0）；check_ids.py --strict PASS；
check_mojibake + BOM/CR/U+FFFD/行尾卫生逐项自查全净。本轮零 .c/.h 改动
（纯 .py/.json/.md），故未跑 @build、未占 build/bench 锁。
|
2026-10-23 23:44:45 +08:00 |
|