ドキュメント陈旧化点检（doc drift audit）

背景与问题

课题 538+、统合设计书・目次・runbook が増え、ノートの内容と实态（store の设定・コード・契約）の漂移（drift）が最大の品質リスクになってきた。rebuild による索引は机制上漂移しないが、wiki-link 死链・断点と实态の不一致・统合文档の版ずれは検知していない。点检プロセスを設計する（OPC 最佳实践方向，B）。

发现

drift の一般论（2026-09-17 アクセス）：

• drift の根因はライティングでなくプロセス：リリースフローに doc 更新ステップがなく、doc が单一事实源と耦合していない（datadef、ferndesk）。
• 防止策の定番：①doc 更新を definition-of-done に入れる ②schema/コードから doc を生成して耦合 ③定期的に現物と突き合わせる audit ④AI で陈旧化候补をフラグ（Mintlify、Fern、Moxiedocs）。

本工作区への当てはめ：

• 机制済み：research.db は rebuild 派生（漂移しない）。「断点即事实源」規律も制度化済み（批八十八の漂移事故以降）。
• 未検知の漂移：①[wiki-link](/posts/wiki-link) の死链（批八十五・九十一で实际发生过）②统合设计书 v1 と源课题の乖離 ③frontmatter updated の day 比实态古い课题。

结论

1. 季度 link 監査を tools に足す：全 README の `slug を列挙して `topics/ の存在と照合し、死链を rebuild 出力に警告として出す。標準庫内で可能（文字列処理のみ）。
2. 月次で课题をランダム 3 件抽出し「断点 vs 実态」突合：断点に書いてあることが本当に未完了かを 5 分で確認する。監査コストは片道 5 分×3 件で抑える。
3. 统合文档（设计书・目次）には源课题 slug 一覧を frontmatter に持たせる：源が更新されたら统合侧が再読すべき対象が機械的に分かる——schema 耦合のノート版。

待办 / 下次继续

• link 監査を tools/research_db.py に組み込むか独立スクリプトにするか判断（依存ゼロ縛りは守る）。
  
• 统合设计书 5 本+目次 7 枚の v1 交叉抽检を 1 回走らせる。
  

关联

opc-year-end-checklist opc-store-review-requirements-annual opc-research-backlog-review