markharness

0001: Version DAGの主張を「ChangeEventモデル」表記に縮小する(方針A)

ステータス

Accepted

背景

docs/テスト知識管理のGit-nativeモデル_統合版.mdは、derived_fromを持つ版ノード・辺の永続的なグラフ(Version DAG)を中核貢献として位置付けていた(§1.1図1、§1.2 RQ1、§3.4図3ほか)。

一方、CLI実装(src/changes.rs)のChangeEvent構造体にderived_fromフィールドは存在せず、実際に保存されるのはfrom_tree_sha/to_tree_sha(2マイルストーン間の線形差分)とtrue_divergences(2親マージ時の監査情報)のみである。版ノード・辺を持つ独立した永続DAGは実装されていない(2026-08-12時点の外部評価レビューのP0指摘)。

この不一致を解消する方針として、以下の2案を検討した。

• 方針A(採用)：実装済みの機能には手を加えず、論文側の主張を実装に合わせて縮小する。「derived_from DAG」「Version DAG」という表現を「Git履歴から導出するマイルストーン区間のChangeEventモデル」に統一する。
• 方針B(不採用、将来課題として保留)：版ノード・辺を持つ永続的なグラフ構造を実際に実装し、論文の主張と実装を一致させる。

決定内容

方針Aを採用した。

• 論文全体(§0・§1.1〜1.3・§3.1〜3.5・§4.1・§4.5・§7・§8)の「版履歴DAG」「Version DAG」表記を、実際の実装(マイルストーン境界のfrom_tree_sha/to_tree_sha比較、true_divergences)に対応する「ChangeEventモデル」表記に置き換えた。
• derived_fromという語自体は、Featureが前後のマイルストーンでどう変化したかを指す概念名として残す。ただし、FEATUREの自己参照エッジとして永続化されるわけではなく、ChangeEventのtree SHA比較として都度導出される関係であることを、ER図直後の注記・§3.2(B)・図3説明の3箇所で明記した。
• forked_from(Git履歴に現れないドメイン知識として人間が手動記述する概念的分岐)は、derived_from(自動導出される版履歴)とは異なる概念であり、今回の修正対象外として維持した。
• 図1・図3をChangeEventの線形/分岐差分ログとして描き直した。
• 方針B(永続DAGへの拡張)は却下ではなく、§7 Future Workに将来課題として1文で記録した。

採用理由

• 実装済みの機能(現状の実装価値)には手を加えず、未実装のDAGを実装済みであるかのように主張するリスクを解消できる。
• 方針Bは版ノード・辺を持つ永続的なグラフ構造の新規実装を要し、工数・設計判断ともに本レビュー対応の範囲を超える。

影響・将来の再検討条件

• docs/テスト知識管理のGit-nativeモデル_統合版.mdの§1.3(貢献)・関連研究比較(改善プロンプト項目2・8)の記述は、本決定で確定した「ChangeEventモデル」という用語を前提に書く。
• PROJECT.mdのderived_from関連記述(改善プロンプト項目5)も、本決定に合わせて実装実態(from_tree_sha/to_tree_sha/true_divergences)に修正する。
• 将来、版ノード・辺を持つ永続的なグラフ構造(方針B相当)を実装した場合は、本決定を上書きする新しい判断記録を作成し、論文側の記述を再度実装に合わせて拡張すること。

追記(2026-08-12)：改善プロンプト項目11「単なるgit diff/logラッパー」懸念への対応

項目11の背景

方針AでVersion DAGの主張をChangeEventモデルに縮小した結果、外部レビューで「論文が単にgit diff/git logをラップしただけに見える」という新たな懸念が指摘された。実装(src/id_cache.rs)を確認したところ、単純なパスベースのgit diff/git log –followとは異なる、実装済みのアルゴリズム的な仕組みが既に存在することを確認した。

強調する核として選んだ3点

1. パス独立なID解決：Featureのidをディレクトリ名やパスではなくfeature.ymlのid:フィールドから読むため、ディレクトリのリネーム・再配置後もGitのパス追跡(git log --follow)に頼らず同一Featureとして追跡できる(id_cache.rs 10〜22行目・84〜97行目)。
2. ディレクトリ単位のtree SHA比較：比較対象をFeatureディレクトリ全体のtree SHAとし、feature.yml自身のblob SHAとしないため、Condition/ExpectedResultのみの変更もfeature.yml非経由で検知できる。
3. 内容アドレス方式のid解決キャッシュ：キャッシュキーがknowledge/のtree SHA＋ルール/スキーマ/ツールの各バージョンで構成され、Gitのcommit-graph補助キャッシュと同じ設計思想を採る(第3.3節)。

これら3点はいずれも既存実装(src/id_cache.rs)で検証済みであり、新規実装は行っていない。

選定した語彙とその理由

「理論的コア」という表現は避け、「設計上の中核メカニズム」「アルゴリズム的な核」を採用した。理由：本節で述べる工夫は、コンテンツアドレッシング(Gitのblob/tree SHA)とgit merge-baseによる祖先探索という既知の技術の組み合わせであり、形式的な証明や計算量解析を伴う理論的成果ではない。「理論的」と呼ぶと、項目1(Version DAG)・項目2(既存TMS断定)で是正した過大表現を、別の語彙で再発生させることになるため避けた。

反映箇所

§1.3(貢献)の記述を上記3点の明示形に書き直し、パスベース履歴追跡(git diff/git log --follow)との対比を1文追加。§1.1(Abstract相当)・§3.1(構造)・§3.3(id解決)の各導入部にも同じ対比を1文ずつ追記した(既存の技術的記述自体は変更していない)。

This site is open source. Improve this page.