 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 |
|
|
wandering1
|
e1967cf2ea
|
chore(size): A5 合入后重盖体积同码凭证
合并 task/A5-size-gate 后主干指纹前进（凭证停留在分支基线），
按门禁指引 @build 0/0 后 ram_baseline.py --update 重盖：
Code=214,104 / RO=20,388 / RW=1,204 / ZI=131,852（A5 零体积增量，
数字与 d9ab955 台账行一致）。
|
2026-10-25 03:59:00 +08:00 |
|