 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 |
|