wandering1
20617a33f7
用户裁定（2026-10-29）：「啥号都不发」= 任何族都不再新增编号， 含 §4.1 那五个原本"有脚本按字面量匹配"的存量族；既有号只读引用， 族里新增内容一律写语义行名。 规范本体： - §1 由「先问三句」改成「默认答案：不发号」，三问表换成场景对照表； - §4.1 由「允许用号的族」改成「存量族」，第四列改「既有号被谁读 / 新写怎么办」，逐行写明新写怎么做（TRAP 写语义行名、FR 用 §5 行名、 CODE-RULE / MENU-STATE 先问用户、P-n 只读存量页号）； - 末框四条对照 + 唯一例外入口（确需机器按字面量匹配 → 先问用户）； - 新增族 = 一律不许；批准后顺序：本文 §4.1 → 属主文档 → 才动 registry。 跨文件同步（12 份）：门禁说明 id-check-new / id-check / host-unit-tests （把"校验 5/3 拦新号"这类现状叙述历史化）、两份 TRAP 记录的编号口径、 开机账本用例号说明、AGENTS 两处、id-family 技能与其 steps-alpha 模板、 归档 README 与两份归档脚本 docstring。 AGENTS 主题表那行原写「允许用号的 7 个族」，与规范的 5 行本就对不上， 旧计数一并消掉。 未做：pre-commit 的 default_stages 一行——用户对该项未置可否。 验证：py_compile 与 check_ids_new.py --self-test 均 rc=0；逐篇 check_doc_links.py --sections-strict rc=0（编号规范 70 处引用 / 68 可判定 / 无法判定 0）；13 份改动文件表列数与字节体检相对基线零新增。
6.3 KiB
id-check-new — 编号门禁·新增行（零语料）——已退役（2026-10-29）
⚠ 本文是退役留档，不要照着它去改门禁。 2026-10-29 用户裁定：这道门禁整体去掉——钩子从
.pre-commit-config.yaml摘除（YAML 解析口径 52 → 51），脚本移入scripts/archive/id_gate/check_ids_new.py（仍可手工跑，--self-test保留）。 此后编号形态没有任何机器面：判据只剩docs/编号规范.md§1 的默认答案（一律停发）、§4.1 存量族 （穷举）与人工评审。前辈id-check（全库八项校验）已于 2026-10-28 退役 →docs/门禁说明/id-check.md； 两步合起来的路线 →docs/编号规范.md§8.5。 下面 §1~§6 是退役前的原样描述，只在手工复查「这批改动 / 这段历史里有没有野生编号」时用得上。
1. 它当初在查什么
拿 git diff 的新增行，只做三件事：
| 形态 | 例子（形态描述，不是本仓号） | 判据 |
|---|---|---|
| 破折形态 | 两字母前缀 + 连字符 + 数字 | 首段不在 KNOWN_DASH → FAIL；在 RETIRED_DASH（已停发族）→ 只 WARN |
| 裸形态 | 大写字母串紧跟数字（外设 / 器件 / 点号写法） | 前缀不在 KNOWN_BARE → FAIL |
| 单字母 + 数字 | C12 / U15 / L3 / R3 这类元件位号与层次号同形 |
一律放行（已知盲区，与旧门禁的"裸形盲区"同源） |
判据全文只有两张前缀表（退役时 KNOWN_DASH 11 条、KNOWN_BARE 90 余条）与一张算术排除表
（SIZE / LEN / MAX 之类后面跟 -数字 是减法不是编号）。没有族形态正则、没有游标、没有属主
登记处、没有比例基线——这就是它相对 id-check 的全部区别，也是它当初被选为接班件的理由。
豁免三档：行内含 [示例] / [计划] 按冻结口径跳过；确需保留的字面量（如冻结的现场日志）在同一行
写 [编号豁免]；脚本自身、scripts/archive/、docs/芯片手册/、docs/硬件平台/、Lib/、
Middlewares/ 等在排除清单里。加白名单是唯一的放宽手段——没有"整库豁免"入口，也没有 --write
现状洗白（与旧门禁同一条纪律）。
2. 为什么当初要它
id-check 要养 99 族语料（id_registry.json 87.6 KB + id_aliases.json 187 KB）：单次运行只有
1.8 s，贵的是"每笔提交都要维持语料自洽"——近 80 笔提交里 61 笔动了语料 / 门禁 / 规范。
而它真正有用的那一小块（拦住"新写一个自造编号"）根本不需要语料：只要知道"这个前缀我从没见过"。
所以 2026-10-28 的分工是：id-check 管存量一致性（当日退役），id-check-new 管增量不许新增。
落地前测过噪声：拿最近 80 笔真实提交回放，未知形态只有 15 种，其中 12 种是设备 / 协议名 （已进白名单）、3 种是已停发族（只告警）→ 白名单调好后回放 0 误报。
3. 退役的理由（这一节是本文的重点）
- 它咬的是形态，不是语义：白名单是"形态"级不是"号"级——前缀合法则
TIM3放行、TIM99同样 放行；同形多义（历史上S3三义那类撞车）它照不出来。这与旧门禁id-check.md§6 记的盲区同源， 只是范围缩到新增行。 - 白名单就是它的维护面：每遇到一类合法字面量（新型器件、协议名、固件生成的产物文件名）就要加
一条；不加就误拦，加了就把该前缀后头的所有数字永久放宽。2026-10-29 当天就撞过一次：文档里写
录波段文件名
WAVE00.BIN被拦，先改写成WAVE<NN>.BIN绕行、再登记WAVE前缀（KNOWN_BARE最后一次改动）。这类"合法新词撞形态门"是常态，不是意外。 - 默认形态早就是语义短语（
docs/编号规范.md§1 与 §3.3；登记簿新条目一律写语义短语，docs/任务规划/README.md§0），新造号在评审里本来就看得见，机器面的边际收益低于误拦成本。 - 与 2026-10-28 摘掉全库审计是同一条判断的延续：编号体系不再产生价值。留着这道门只让"要不要 再登记一个前缀"变成反复出现的小额开销。
- 别往"轻量版"方向找补：改成只告警（退出码恒 0）等于把形态判断变成没人看的滚屏；转
stages: [manual]又因为它是 diff 型脚本、脱离提交时机基本扫不到东西。两条都是留着成本、 去掉收益，所以整体退役。
4. 退役后手工怎么用
& '.venv\\Scripts\\python.exe' scripts/archive/id_gate/check_ids_new.py --self-test # 正反例自检（5 正例 / 29 反例）
& '.venv\\Scripts\\python.exe' scripts/archive/id_gate/check_ids_new.py --range A..B # 复扫一段提交的新增行
& '.venv\\Scripts\\python.exe' scripts/archive/id_gate/check_ids_new.py --worktree # 查未提交的改动
跑不跑都不影响提交。真正还用得上它的场合是编号清退批次：拿它当"形态普查"的尺子，比自己临时
写正则省事（做法 → .dsh/skills/id-family-semantic-migration/SKILL.md）。
5. 此后靠什么守着
docs/编号规范.md§1「默认答案：不发号」+ §4.1 存量族（穷举）+ §3.3 禁发范围——新增族不再需要 登记机器白名单，那个"唯一口子"随门禁一起消失；答不出"哪个脚本要按字面量匹配它"就别建族。- 评审与销项纪律：
docs/任务规划/README.md§0（已随销项消失的号永久作废、不得复用）。 - ⚠ 要认下丢了什么："销项删行后号被重新取走"这类事故当初正是靠机械牙发现的（2026-10-14 撞号 事故 → 语义标识裁定）。此后提交期不再有这类警报，只剩规范与人工核。
6. 改这个脚本本身要注意什么（历史留笔）
- 改完必跑
--self-test（正例漏拦 / 反例误拦都会红）；退役后这条纪律只对手工复查生效。 - 别把白名单做成"按字面量枚举"的账本——那就退化成
id_aliases.json的老路（187 KB 维护负担）， 前缀级枚举才是它便宜的原因。 - 归档位置的
REPO_ROOT与原位不同（深两级，取parents[3]）；再挪目录要一起改。