wandering1
511fd30cc6
用户裁定：文档只写现状，历史流水一律删掉，过程查 git log。 - 43 篇「变更记录 / 修订记录」整节删除：继电保护规划 12.6 KB、产品 需求 11.8 KB、项目部署环境 5.5 KB、BSD Socket 指南 5.3 KB、架构 总览 5.0 KB、实机测试实施指南 3.8 KB 等 - 23 篇别处仍有指向：只留节名 + 一行「本文件不再记流水账，过程查 git log」，节号与锚点不位移（doc-links 不因此断链） - 5 篇整表保留（被当唯一证据 / 活台账引用）：看门狗设计说明、配置 文件设计说明、RAM预算台账、内容页架构、本地工具路径环境变量方案 - 规范同步：文档规范 §5.1 改新裁定；测试文档模板规范删示例节与 登记句；测试开发标准流程 / UI 两篇 / 实机测试实施指南 / 四篇单测 说明 / 并行任务工作树方案 / 编号规范 的「登记变更记录」改「写进 正文」 - 技能同步：stale-doc-count-sweep / ui-verify / id-family 三个 SKILL 正文不再要求追加流水行（顺带消掉 SKILL.md:121「产品需求 §12」 失效引用） - 修 5 处悬空指针：采样有效性校验目录锚点、BSD 指南「文末变更 记录」、docs/README 过期描述、网络自愈架构两处指向面 72 篇文档净减 600 余行；check_doc_links --all --sections-strict 可判 定比例 61% → 78%、失效引用 0；静态门禁 passed=50 failed=0；gitlint 10 条历史提交信息 0 failed。 未提交他人在飞改动：.dsh/skills/keil-build/*（%SystemDrive% 守卫）。
3.4 KiB
3.4 KiB
no-mojibake — 禁止 U+FFFD（编码损坏的不可逆痕迹）
一句话：文件里只要出现
U+FFFD（替换字符），说明某段中文已经被按错误的编码解码过一轮， 损坏不可逆——它必须被拦在提交之外。
- 配置：
entry: python scripts/check_mojibake.py、language: system、types: [c]（只跑 C/H）、pass_filenames: true（只查本次改动的文件）。 - 脚本只有 17 行：读字节 → 数
EF BF BD→ 有则退出码 1。
1. 它在查什么
- 唯一判据：字节序列
EF BF BD（UTF-8 编码的U+FFFD）。 - 它不试图判断"这是不是故意的"——按 AGENTS 铁律，字符串字面量必须纯 ASCII，中文只写注释， 所以正常代码里出现替换符一定是损坏。
2. 为什么要它
- 本仓最常见的不可逆事故：用
Get-Content/Set-Content/cmd重写含中文的文件，整文件按 系统默认代码页重解码 → 中文变 ``，而且原内容再也拿不回来（AGENTS 列为 Never）。 - 它是那条铁律唯一机械化的部分：其它铁律（只用 Edit 工具、怀疑乱码先数
EF BF BD）都靠人。
3. 触发面 / 看不见什么
- 只看本次改动的 C/H 文件：
types: [c]+pass_filenames: true两重限制叠加。 - 因此
.md、.py、.txt、.yml里的U+FFFD不报——而本仓文档量远大于代码量， 乱码最容易发生在文档上（这是本门最主要的盲区）。文档侧目前靠人工字节卫生检查。 - 只查
EF BF BD这一种形态：别的损坏（GBK 字节直接落进 UTF-8 文件、无 BOM 文件里奇数个 汉字吞掉结束引号）它认不出。
4. 报错怎么读
Forbid U+FFFD mojibake.......Failed
Drivers/BSP/X/x.c: 3 处 U+FFFD
-
处置：立刻用 Edit 工具只修坏行；不要
git checkout（会丢掉本次全部未提交工作）。 -
若整文件已损坏且未提交，唯一救援是编辑器/系统的本地历史（未跟踪副本），否则只能重写该文件。
-
典型报错：
U+FFFD replacement chars found (encoding corrupted, irreversible!): path/to/file.c。 -
修复路径：从 git 历史里找到最后一个干净版本，只把损坏区域搬回来（整文件 checkout 会连本次 改动一起丢掉，属 AGENTS 的 Never）。
-
修完必须回头查写入方式（
Get-Content/Set-Content/cmd重写含中文文件），否则修好还会再来。
5. 好处
- 一条命令、零依赖、零误报地挡住不可逆损失；成本几乎为零（17 行、不解析语义）。
6. 限制与盲区
- 不覆盖文档与脚本（
types: [c]）。写.md时的乱码不会被拦——这是本目录里"覆盖面与 需求错配"最明显的一例。 - 只查改动文件：历史里已存在的 `` 不会被追溯（存量不报）。
- 不判断"是否故意的"：真要在注释里写替换符做样例，会被拦（本仓没有这种需求）。
- 不检测编码本身（BOM 有无、CP936 内容）——BOM 丢失由构建期
#870-D暴露，不在本门。
7. 豁免与基线
- 没有豁免：出现即失败。这是有意的——不可逆损失不值得讨论。
8. 改这个门禁本身
- 若把覆盖面扩到
.md/.py：先全库扫一遍存量数（历史上文档里可能已有），有存量就别直接挂 硬拦截（会把所有人卡在提交外），要么先清要么走基线式增量拦截。