跨材料一致性维护

工作方式（常驻）

在任何产出材料的任务中后台运行：每生成或修改一份材料，比对项目库 db09 的"统一定义"，发现偏差即纠正或提示。

单一事实源：项目术语与定义表（存 db09）

借鉴 content-strategy 的"先定义后生产"：所有材料从一份定义文件派生，禁止下游各写各的。

事实源的两种形态（同一份真相，机读 ⊃ 人读）：

• 人读真相（每个项目必有）：databases/db09-projects/projects/<项目>/terminology.md——Markdown 术语表（类别/标准叫法/缩写/英文/备注），由 a02 维护，是 db09 项目卡固定组成。审计脚本读它做覆盖缺口检测。
• 机读增强（需严格校验时再生成）：三份 YAML schema 模板（assets/ 的 db09_glossary.yaml/db09_method_lock.yaml/db09_metric_registry.yaml），比 Markdown 多 forbidden/confusable/权威数值列，支撑受控术语替换与指标数值冲突检测；扩写后存回项目 db09 目录（与 terminology.md 并列）。字段清单见文件清单节。

assets/ 三份是空白模板；真实项目事实源永远落在 databases/db09-projects/projects/<项目>/，避免"db09 指两个地方"。

维护要点（锁定口径，配合下方「一致性检查维度」五维）：方法/数据集名称含缩写列入"禁改清单"（润色/翻译不得替换）；指标统一符号+单位+定义（F1 vs F-score）；3 条创新点标准措辞跨论文/PPT/软著/竞赛一字对齐；关键术语锁中英对照+大小写连字符（fine-tune 不写 finetune）；视觉规范：项目有 databases/db09-projects/projects/<项目>/palette.json（论文图 m11/PPT m16/前端 a05 共读的视觉 SSOT 实例）则"跨材料配色一致"直接对照该文件逐项核——四方取色须同源、谁都不另起色板；无 palette.json 时退回 db05 design_tokens.template.json（DTCG 色值锚点真相源），论文图(db07)/PPT(db06)/前端(db05)/海报同取一份值（当前人工/清单对照，非脚本自动核）。

• 变更广播：定义一旦修改，立即触发对所有已产出材料的回扫，避免下游过期。"已产出材料"的权威清单 = orchestrator 维护的 .light/passport.yaml 各阶段 artifacts: 路径并集（§4 产物台账）；无 passport 的轻项目退回 db09 的 version_history.md 列出的产物。回扫即对这份清单逐项跑下方 consistency_audit.py，命中即按"现状→问题→建议"修。

审计脚本：consistency_audit.py

scripts/consistency_audit.py 读取上述 db09 三件套，扫描一组材料文本，自动检测并定位到 材料:行号 的四类不一致，按 ERROR/WARN 分级，每条带"现状→问题→建议"，报告末尾做"条数自检"。