light-consistency

# 跨材料一致性维护 ## 工作方式（常驻） 在任何产出材料的任务中后台运行：每生成或修改一份材料，比对项目库 db09 的"统一定义"，发现偏差即纠正或提示。 ## 单一事实源：项目术语与定义表（存 db09） 借鉴 content-strategy 的"先定义后生产"：所有材料从一份定义文件派生，禁止下游各写各的。 **事实源的两种形态（同一份真相，机读 ⊃ 人读）：** - **人读真相（每个项目必有）**：`databases/db09-projects/projects/<项目>/terminology.md`——Markdown 术语表（类别/标准叫法/缩写/英文/备注），由 a02 memory-pm 维护，是 db09 项目卡的固定组成。审计脚本可直接读它做**覆盖缺口**检测。 - **机读增强（需严格校验时再生成）**：下面三份 YAML schema 模板（`assets/`），比 Markdown 多出 `forbidden`/`confusable`/权威数值列，支撑**受控术语替换**与**指标数值冲突**检测。把项目的 terminology.md 扩写成这三份即可启用全部四类检测，仍存回该项目的 db09 目录（与 terminology.md 并列），保持 db09 是唯一物理位置。 - **`db09_glossary.yaml`** 受控术语表：`canonical`/`aliases`/`forbidden`/`case_lock`/中英对照。 - **`db09_method_lock.yaml`** 方法名锁定清单：`abbr`/`full`/`forbidden`/`first_use_rule`。 - **`db09_metric_registry.yaml`** 指标登记表：`canonical`/`aliases`/`confusable`/`unit`/`decimals`/`records`(权威值)。 > `assets/` 下的三份是**空白模板/示例**；真实项目的事实源永远落在 `databases/db09-projects/projects/<项目>/`，避免"db09 指两个地方"的歧义。 维护要点： - **方法名称**：模型/算法的统一叫法(含缩写)，列入"禁改清单"——润色/翻译不得替换。 - **数据集名称**：统一全称+简称。 - **指标名称**：统一符号与单位(如 F1 vs F-score)，连同定义与单位一并锁定。 - **创新点表述**：3 条贡献的标准措辞，论文/PPT/软著/竞赛一字对齐。 - **关键术语**：中英对照、专有名词译法、大小写与连字符(如 fine-tune 不写 finetune)。 - **视觉规范**：落成 DTCG 风格命名 token——主色/语义色、字族字重、模块化字号、间距阶梯(4/8pt)、圆角阴影。视觉 SSOT 锚点为 db05 的 `design_tokens.template.json`，论文图(db07)/PPT(db06)/前端(db05)/海报全部从同一份取值。**当前以人工/清单对照执行,非脚本自动核对。** - **变更广播**：定义一旦修改，立即触发对所有已产出材料的回扫，避免下游过期。 ## 审计脚本：consistency_audit.py `scripts/consistency_audit.py` 读取上述 db09 三件套，扫描一组材料文本，自动检测并**定位到 `材料...