wandering1
4ac869058d
ci(gates): 自触发已生效；纠正我自己误读提交输出得到的两条假结论
先说结论：**触发面含门禁自身是生效的**。只改 .pre-commit-config.yaml 的两个提交
（e327636、c4ca292）里 test-coverage 都实跑并 Passed（约 45 s、28 套），bsp-err 同样
实跑。上一提交写下的"改 files: 那次由旧配置管辖"是**我误读输出得到的假结论**，
已按事实改写；那条猜测当时被当成"实测语义"写进配置注释，正是本仓反复防的问题，
所以这一批先降级为"待证"、再判定、再落事实。
误读的机制（值得留档，因为它会让人系统性看错门禁状态）：钩子没声明 stages: 就
默认属于**所有阶段**，于是同一次提交的输出里每根钩子出现两次——pre-commit 阶段
那一遍才可能实跑；commit-msg 阶段那一遍拿到的"文件"是提交信息文件，跟这些钩子的
files: 都不匹配，几乎必然 (no files to check)Skipped。我前几次都只 tail 了输出结尾，
看到的就是第二遍，于是连着误判了两次（第一次判成"自触发没生效"，第二次为了自洽
又编出"旧配置管辖"这条规则）。同一批里 bsp-err 的表现也是同一成因。
判据写成一句话：**看某根钩子跑没跑，认它第一次出现的那行**，别读尾巴。已同时补到
pre-commit使用说明 §2.2 的通用机制表里（新增一行），配置注释里也留了实跑证据的提交号。
自查：本提交只改配置与一份机制文档（无代码改动，未跑 @build）；提交自身会触发
test-coverage 实跑一遍作为回归；doc-links 与 id-check 见下条。未 push。
2026-10-24 08:18:45 +08:00
..
2026-09-26 00:51:53 +08:00
2026-10-24 08:18:45 +08:00
2026-10-23 23:44:46 +08:00