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
|
5f1057ac74
|
test(P1-10): 套件回归 forbidden 换成显式四 Fault 标签 + 台架记录 21/21
台架第一轮(boot log 20261025_050539)判 VERDICT FAIL,命中 469 条 [ERR],两类:
1) [ERR][CH395] ch395f P2 boundary fault @get_state sn —— **设计内**:Phase 15 的
sn 越界负向用例故意命中驱动守卫(Drivers/BSP/CH395F/ch395f.c 的
ch395f_p2_fault_note():首次 DBG_ERROR、之后只计数),用例本身 PASS;
2) [ERR][WD] task stall ×468 —— **设计外**,已在 a9ba8ec 单独修(掩码死分支),
不用豁免去掩盖它。
本笔只管判据:套件回归这条路要豁免的是"设计内守卫 [ERR]",不是崩溃。
为什么不能只是把 [ERR] 从 forbidden 里删掉(核过 verify_log 源码与固件崩溃行):
四种 Fault 的崩溃行是 [ERR] HARDFAULT / MEMFAULT / BUSFAULT / USAGEFAULT
(Src/stm32f4xx_it.c 的 hard_fault_report 先打 "[ERR] " 再打标签),而 verify_log 的
forbidden 是**大小写不敏感的子串匹配**(fl in ln.lower())→ 默认集合
HardFault;assert;[ERR] 里的 HardFault 只兜得住硬Fault,**MEM/BUS/USAGE 三种平时
完全靠 [ERR] 兜**。据此:
- 新增 FORBIDDEN_SUITE =
HardFault;MEMFAULT;BUSFAULT;USAGEFAULT;assert;bring-up FAIL
- CH395F 用它(原来吃默认值,含 [ERR]);
- GD5F 也用它——旧值 "HardFault;assert" 正是上面那个漏法(当初只为豁免
TC-GD5F-704 的设计内 [ERR] 就把整条 [ERR] 摘了,等于顺手放走了三种 Fault),
现在既保留豁免意图,又把崩溃判定补齐;
- STORAGE / RTC 不动(它们没有设计内 [ERR],继续吃含 [ERR] 的默认判据)。
边界写死在注释里:产品 @test 的判据(.serialtest/config.json 的 forbidden 含 [ERR])
**一个字节没动**,豁免只活在"套件回归"这条路上,渗不回产品路径。
test/board/ch395f_test.h:
- Phase 15 汇总实测 21/21(旧注释写"台架 20/20 PASS"是历史记录,已按本轮改正);
- 记一条台架档案:镜像 ch395f_hw_nopc_v2.hex 单次开机跑完 1/12/15,汇总行
9/9、1/1、21/21,failed=0,全程无 Fault;并记下同轮暴露的掩码死分支结论与它的
证据位置,后来人切阶段时不必再踩一遍。
验证:
- py_compile 通过;test/run_all_suites.py --check-build --suites CH395F 走**官方编排**
实跑 PASS(BUILD_OK 0 错 0 警,Code=217468 RO=21452 RW=1268 ZI=134076),脚本自己
还原 test_config.h 并重建产品固件;这个 Code 与上一笔实测表里"默认阶段 11/14"一行
逐项相同 → 两个独立工具互证同一组数字。
- gate:id-check / no-mojibake / trailing-whitespace / end-of-file-fixer /
doc-links / cppcheck(test/) / test-suite-switch(产品态 Skipped)全 0;
未用 --no-verify。
- RAM/Flash 增量:0 B(Python 与注释,不进固件;test/board/*.h 的注释不改代码)。
下一轮台架等 lead:f2 镜像我会在 sync 到 A-3/B-3 之后重编(现在这份
ci-artifacts/p110_fw/ch395f_hw_nopc_f2.hex 戳 05:23:03,若中途主干动过固件就要重编),
判据用上面的 FORBIDDEN_SUITE;请顺手带回两个数:[ERR][WD] 总条数、mask 含 bit4(ui)
缺位的条数。
|
2026-10-25 05:36:25 +08:00 |
|
wandering1
|
5a9988b557
|
chore(注释): 清掉源码里不可检索的过程编码
清掉的(读者无从解析、且所指文档已不存在)
- 已删任务文档的编号:Task #32、其内部 §5 / §4.3、P1-5、P0-2、P1-4a、
"方案 a"、"Lead 批准 2026-10-12"
- 正文里当代词用的文件版本号:"(v2.7 起为 AboveNormal)""已随 v2.0 事件
驱动改造删除""(v2.0:DMA 消费)""见文件头 v1.3 说明"等 → 改写成陈述现状
- 测试与脚本同类:adc_input 桩头"v2.0:DMA 模型"、stub/adc.h 的 v2.0、
check_cubemx_survival.py 段头的"2026-10-10 v2.8"、run_all_suites.py 的"方案 A"
刻意保留
- 可检索登记簿锚点:P-AUDIT 真条目(P0-1/P1-8/P2-1/P2-9/P3-11)、S6/S11、
E-31/E-44、N-18/N-23/N-32、B1/B5/B7/B8、L1-x~L5-x 功能号
- 文件头修改记录块内的 vN.M(规范 V1.0 §2.1/§2.2 要求保留该块;块内编号
在本文件内自洽可读)
顺带纠正注释与代码已经不一致的过时事实
- 仍把 TIM6 写成现行节拍源:Src/main.c 的 include 注释与回调注释、
Src/freertos.c 的 adcTask 块 → 改 TIM3;adc_input.h 修订条目里"ADC1 只认
TIM2/TIM3/TIM8 的 TRGO"不准确 → 换成指向判据(ADC采样节拍设计说明 §3.2)
- App/algo/phasor.c 双区注释称"唯一消费者是 adcTask、为后续保护任务预留",
实际 protectTask 已跨上下文读(prot_elm_run -> phasor_get)→ 改为"读者跨
adcTask 心跳与 protectTask 判据两个上下文,勿改加锁、勿取消双区",并同步
修正 docs/算法/采集与算法层设计说明.md 同一句
- adc_tick_irq_notify() 的"拒绝 ISR 内计算"理由仍写"内含 2 ms 忙等"(DMA 化
后已无忙等)→ 换成三条真实理由:任务级共享数据 / 计算量 / 生成区回调
- 裸 §5(指代不明)与"规划 §1.6 / 规划 §4"昵称式 → 写成完整路径紧邻式
字节卫生(Edit 会静默剥 BOM)
- App/task/ui_task.c 与 Drivers/BSP/UI/ui_net_sink.c 被剥掉 BOM 两次,均按
3 字节 EF BB BF 前缀补回并复验;全部 20 个文件 CR=0、U+FFFD=0、无行尾空白
门禁
- @build 0 错误 0 警告,且 Program Size 与清理前逐项相同
(Code=213356 RO=18580 RW=1184 ZI=131480)→ 纯注释改动、中文未被误重编码
- ui-golden 首跑红:新工作树缺被 gitignore 的黄金参考 simulator/tests/ref/
(不入库、只在主工作树生成过);从主工作树复制该基线后复跑通过 → 注释改动
零像素影响
- 全套 pre-commit 在这 20 个文件上 Passed(coding-standard / cppcheck /
6 个主机单测 / doc-links / task-table / mem-numbers / cubemx-survival /
registration-check / mem-budget / font-charset / ui-golden / id-check)
- id-check 可判定比例 82.71% -> 82.88%(删掉的是"形似 P-AUDIT 但查无定义"的
假锚点),悬空引用 863 -> 854
|
2026-10-21 11:39:53 +08:00 |
|
wandering1
|
d3107f374f
|
docs: 待处理内容.md 解耦为 docs/任务规划/ 文件夹(README 排序权威 + 6 个职责单一文件)
- rename_ref.py 搬迁:git mv + 全库引用改写 33 文件 82 处
- README.md 保留 §0 编号空间 / §1 未闭环一览 / §2 推进顺序权威 / §3 维护约定
- 拆出 6 文件:W1-采集保护收尾(任务卡五字段)、排期详述、暂缓-RS485、
登记簿、测试与架构专项、基线与待确认
- 外部引用重定位 ~50 处:裸「登记簿 §X」、§5.1→基线与待确认 §2.1、
§2.4→暂缓-RS485、§6→基线与待确认 §3、脚本注释 T-x/N-x→登记簿
- 新增并行写纪律:任务分支不改本文件夹,状态列由 Lead 主工作树更新
- 验证:doc-links 141 文档全绿;mem-numbers 一致;refgraph 重生成;
@build 0 错误 0 警告;新文件无 BOM / LF / 零乱码
|
2026-10-12 13:42:47 +08:00 |
|
wandering1
|
5defabcabb
|
build: 删除 MDK-ARM/download.bat,烧录收敛到 stlink-flash skill
- test/run_all_suites.py 是唯一执行它的地方:DOWNLOAD_BAT 改为 STLINK_FLASH
(.dsh/skills/stlink-flash/scripts/stlink_flash.py);直烧改
[py, STLINK_FLASH, "flash"](原先把 .bat 包给命令行解释器执行);
--flash-cmd 改由同一常量拼出,不再硬编码 .bat 路径
- 机制变化(须知晓):原 download.bat 走 UV4 -f(CMSIS-DAP),现走
ST-LINK_CLI -P <hex> -Rst -Run —— 与 .serialtest/config.json 的
flash_cmd、AGENTS.md 烧录铁律、回读 -CmpFile 要求同源;6.5s/1MB
也快于 UV4 路径
- AGENTS.md / 环境与部署 3 篇 / ST-LINK_CLI 复位说明(原文写"正式流程仍以
download.bat 为准",已反转)/ 自动化测试流程 / 串口助手设计说明 /
链路延迟 / m2_data / README / MDK-ARM/README:引用改指 skill
- .gitignore:download_log.txt 条目保留并注明 legacy(他机残留物不变
untracked);build 日志注释同步
- 保留 MDK-ARM/reset.bat:其 hard/halt/run 子命令是 skill 没有的
- 刻意未改:docs/问题记录/项目审查与优化建议报告.md 的 P2-15(史实)
- 验证:run_all_suites.py --dry-run 解析出 skill 路径;doc-links 123 通过
|
2026-10-10 16:28:58 +08:00 |
|
wandering1
|
c77c5824f9
|
build: 删除 MDK-ARM/build.bat,@build 完全收敛到 keil-build skill
- test/run_all_suites.py 是唯一真正执行它的地方:BUILD_BAT 常量改为
KEIL_BUILD(.dsh/skills/keil-build/scripts/keil_build.py);两处构建点
改传 --timeout(脚本内超时先于 _run 超时触发,超时得 rc=1 + BUILD_FAIL
文案,而不是被 _run 杀掉)
- AGENTS.md / keil-build SKILL.md / new-machine-setup SKILL.md:删除
"等价原生入口"口径,改为注明该文件已于 2026-10-10 删除
- 环境与部署 3 篇 / 项目架构总览 / README / MDK-ARM/README /
download.bat 注释 / check_mem_numbers.py 提示串:移除 build.bat 引用
- 刻意未改:docs/问题记录/项目审查与优化建议报告.md 的 P2-14 / N-18
(历史审计条目;doc-links 不校验裸文件名,保留不影响门禁)
- 验证:keil_build.py --timeout 300 -> BUILD_OK / rc=0;
run_all_suites.py --dry-run 正确解析 skill 路径;doc-links 123 文档通过
|
2026-10-10 16:23:54 +08:00 |
|
wandering1
|
f0300761ae
|
串口采集/测试去重:删 tools/serial_tool 与 test/host run_boot_test/verify_log 副本,引用改指 .dsh/skills 串口 skill
|
2026-10-10 15:13:23 +08:00 |
|
wandering1
|
029437be89
|
台架执行《实机测试实施指南》步骤 3~7 并闭环
步骤 3/4(IWDG V2/V4/V5 + 堆低水位 S11):
- V2 任务饿死 stall 后 ≤2.5s IWDG 复位;V4 关中断死循环 ~4.9s 稳定复位;
V5 30min 120×FTP 全 PASS、零 IWDG 复位。堆告警全程未触发(min_ever=4728B)。
- task_watchdog.c:stall 证据写盘会经 nand_ftl_wd_feed 喂狗 → 增 s_stall_evidenced
每次 stall 仅取一次证据,避免"取证据"本身阻止复位。
- default_task.c:堆低水位告警(HEAP_LOW_WATER_B=3072)。
步骤 5(GD5F 错误通道 S9):gd5f2gq5ue.c/.h + nand_ftl.c 错误码统一为 int32_t 并
全量检查返回值;套件回归 16/16 PASSED。
- test/run_all_suites.py:--forbidden 改为按套件覆盖(GD5F 用 "HardFault;assert")——
TC-GD5F-704 故意触发 [ERR] 回落轮询,统一默认值会误判 FAIL。
步骤 6(网络稳定性):7.1 正常路径 ✅(V5 证据);7.2 N-2 丢弃可观测性代码已具备、
49s 静默在 V5 未复现(降级低风险观察项);7.3 N-3 待 PC peer。
步骤 7(工程卫生):
- S5:新增 test-cppcheck 钩子(仅 warning,排除模拟器桩)。
- S4:新增 scripts/check_test_traceability.py(默认仅告警)。
- 待核实项 TEST_SUITE_SELECTED 实机核实 = 死代码(无使用点);RTC 套件实际正常执行,
真缺口 = 缺套件级汇总行 → sd2506_test_task.c 补 === RTC Tests: N/M PASSED === 并
修正 Phase 级汇总累计问题;test_config.h 补齐 RTC 并注释"当前无引用"。
验证:产品 @build 0/0;pre-commit --all-files 17/17 Passed;
run_all_suites.py --suites RTC → PASS。
文档:实机测试实施指南 / SD2506_Test_Guide / 待处理内容 / 测试与架构改进建议 同步。
|
2026-10-04 00:35:06 +08:00 |
|
wandering1
|
d9425ddd23
|
测试:补启动段可观测性与模拟器差距清单,run_all_suites 加只编译模式(S10+S13+S6)
CI / L0 静态门禁 (pre-commit) (push) Successful in 1m10s
CI / L0.5 主机侧单测 (MSVC) (push) Successful in 25s
|
2026-10-02 13:57:25 +08:00 |
|
wandering1
|
2055de0303
|
测试:落地测试架构改进 T-1~T-5(套件开关门禁/汇总行校验/通用 harness/公共断言宏/多套件编排)
背景:L0.5 主机侧单测落地后复审测试架构,给出 6 条改进意见(P0~P3),
登记进 docs/待处理内容.md「测试与验证基础设施」后逐条实施。
- T-1(P0) 测试套件开关门禁:新增 scripts/check_test_suite.py + pre-commit 钩子
test-suite-switch,默认要求产品构建(全部 TEST_SUITE_* 注释),跑套件回归用
--allow-test-build / ALLOW_TEST_BUILD=1 显式放行。顺带把 test_config.h 中长期
开启的 TEST_SUITE_CH395F 改回注释(仓库此前躺着的是测试固件)。
- T-2(P1) verify_log.py 增加 --require-suite-summary:要求
"=== <名称>: N/M PASSED (failed=0) ===" 且 N>0,堵住"套件没跑到汇总行/
断言数为 0 仍判 PASS"的盲区;run_boot_test.py 同名参数透传。不传参向后兼容。
- T-3(P1) 抽取通用 harness test/host/common/unit_test_harness.py(工具链探测/
INCLUDE-LIB 拼接/wd4819/GBK 解码/退出码契约);watchdog 运行器 170→55 行,只声明 TestBuild。
- T-4(P2) 新增 test/board/test_common.h 集中断言内核(TEST_CHECK_IMPL/TEST_REPORT_IMPL),
4 套件各用一行宏绑定自身统计变量(保持 g_xxx_stats 独立、防跨套件串数)。
刻意不 include dbg_log.h——否则冻结 DBG_TAG 默认值触发 #47-D 重定义警告。
- T-5(P2) 新增 test/run_all_suites.py 多套件回归编排,try/finally 无条件还原套件开关。
验证:@build 产品构建 0 错 0 警;4 套件逐一构建均 0/0;看门狗单测 39/39 PASS;
pre-commit 14 钩子全通过;编排脚本 dry-run/开关切换/异常还原均实测通过。
|
2026-10-01 07:28:57 +08:00 |
|