 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
|
7c4628b043
|
fix(A5): 体积凭证指纹改取 git 索引 blob——跨 checkout 稳定，并拦未 staged 改动
现象（道C-3 开工第一步就撞上，属于上一提交 e25e51c 引入的缺陷）：
_wt/P1-10-test-fw 里 check_size_gate --local 报"不同码"，而两棵树 git status 全干净、
HEAD 同为 e1967cf。定位：主工作树的受管源码里 **1046/1388 个文件落成 CRLF**，新建
工作树同一提交落成 **LF**（实测 Drivers/BSP/dbg_cfg.h：1293 B/CRLF vs 1247 B/LF），
但两者的**索引 blob 完全相同**（都是 c39395f7…）。根因是本仓 core.autocrlf=true 与
.gitattributes 的 eol=lf 并存——所以"工作树原始字节"根本不是跨 checkout 的稳定身份。
后果比红一次更糟：主树盖的凭证在**每一条道的平行工作树**里都会误红，runner 上同样
（checkout 出来的行尾取决于那台机器的配置）→ 门禁自己造 false positive。
修法（AGENTS「行尾不依赖 core.autocrlf」的机器化版本）：
- 指纹 = git **索引** blob：`git ls-files -s` 的 path+blob 逐行聚合哈希（v2），
跨 checkout / 跨机器一致；凭证 schema 从 1 抬到 2，旧凭证直接判"不符、重新盖戳"，
不做静默兼容（v1 凭证在别的树里必然误红，留着只会污染判读）。
- 新增第四道前置：**范围内有未 staged 改动/未跟踪文件时拒绝盖戳**——未 staged 的部分
不在索引里，凭证会声称覆盖一份并不存在的代码。已 git add 的不算脏：索引已含其内容，
正是"将要提交并被测量"的那一份。--local/--ci 同样把这类脏单独报出来。
- 新增守卫的机理性说明写在 index_snapshot() 上方与 docstring 的"指纹范围"节（唯一正文）。
- scripts/size_attestation.json：按 v2 重新盖戳（本树产品态实测 Code=214104 /
RW=1204 / ZI=131852 / RW_IRAM1 75,632 B / RW_CCM 57,376 B，与主干 2026-10-25
台账行同源）。
验证：
- 跨树一致性：_wt/P1-10-test-fw 与主工作树分别独立算索引指纹，结果都是
bf6ec94a761e…（1388 文件）→ CROSS-TREE STABLE。
- --stamp / --local / --ci 三态均 rc=0；凭证与 tsv 末行互证同源（Code=214,104 B）。
- 负向：在 test/board/ 放一个未跟踪探针文件 → --local 与 --stamp 双双 rc=1 并点名该
文件；删除后 --local 回到 rc=0（本树已确认干净，探针不留痕）。
- py_compile 通过；门禁实跑：no-mojibake / trailing-whitespace / end-of-file-fixer /
check-added-large-files / id-check 全部 0。
RAM 增量：0 B（凭证与门禁脚本，不进固件）。gate：全过，未用 --no-verify。
⚠ 需要 lead 做一步：合入后主树跑一次 python scripts/check_size_gate.py --stamp
（或 ram_baseline.py --update）把 v1 凭证换成 v2，否则主树的 L0c 会报 schema 不符。
|
2026-10-25 04:18:32 +08:00 |
|