第8章 改訂と版管理

テキストを正本とする最大の実務的利点は、Git による版管理がそのまま仕様の改訂プロセスになること である。本章は版・改訂の記載規約を定める。

8.1 版は Git とメタデータの二層で持つ

• Git: 行単位の改訂履歴・差分・レビュー・分岐は Git が担う。「いつ・誰が・どこを・なぜ変えたか」は コミット履歴とプルリクエストに残る。仕様書の改訂作業はプルリクエストのレビューとして行う。
• メタデータ: 告示・配布物に印字される正式な版番号は frontmatter の version・spec_date に持つ。 Git のコミットハッシュは版番号ではない。両者は役割が異なる（Git＝作業履歴、version＝公示版）。

8.2 改訂履歴の記載

各文書（特にガイドライン・仕様書）は末尾または index に改定履歴表を持つ。原本の改定履歴を踏襲し、 改定年月日・改定箇所・改定内容の 3 列で書く。

改定履歴はあくまで人間可読の要約である。正確な差分は Git が持つので、改定履歴に全変更を網羅させる 必要はない。公示・配布の単位で意味のある変更を記載する。

8.3 識別子は版をまたいで安定させる

第4章・第6章で述べたとおり、機能 ID・項目 ID・URN・章節番号は参照キーである。改訂で内容が変わっても、 同一概念の識別子は版をまたいで温存する。

• 項目を新設するときは新しい ID を採番する。既存 ID を使い回さない。
• 項目を廃止するときも ID を欠番として残し、別の項目に再割り当てしない。
• 版番号（第2.4版→第4.1版）が変わっても、ファイル名・URL・URN は変えない（第2章 §2.4）。

8.4 「変更箇所記載版」の差分は構造化する

原本には改訂の差分を色分け・取消線で示した「変更箇所記載版」がある。テキスト正本では、この差分は Git の差分が担うのが本筋である。さらに意味的な差分（追加・修正・廃止）を明示したい場合は、 項目に change のような注記を構造化して持たせることを推奨する（具体的キーは別途定義）。色や取消線の ような視覚表現を本文に直書きしない。

8.5 草案の明示

確定前の文書は frontmatter に status: draft を付し、本文冒頭にもドラフトである旨を明記する。 本書（DS 番号未採番、仮置き ds-4xx）自体がその例である。確定時に status を外し、正式な ds_code を採番する。