[index] インデックス層の真の抽象化（C++20 concept IndexConcept / PhantomStrategy）

[thawk105]

親イシュー: #27 / #27「MasstreeWrapper をトップレベルの index/ ディレクトリに移動する」を分割したうちの 1 つ (旧ステップ5)。

目的

masstree と yakushima の 2 バックエンドが揃った段階で、インデックス層を C++20 concept で真に抽象化する。各 CC プロトコルが <IndexConcept, PhantomStrategy> をテンプレートパラメータとして受け取れるようにし、将来の第3インデックス追加コストを下げる。

依存

• [index] index/ ディレクトリへの masstree_wrapper 移設とインデックスエイリアス層の導入 #88 (index/ 移設 + エイリアス層) に依存 — DefaultIndex<T> / index/index.hh が前提。
• [index] 第2インデックス yakushima の統合（ビルド統合 + YakushimaWrapper 実装） #89 (yakushima 統合) に依存 — masstree + yakushima の 2 実装が揃ってから着手する。1 実装だけで concept を切ると「1 点しか通らない」間違った抽象化になりやすい。2 点を通る抽象にする。

現状 (2026-05-15)

• このイシュー着手時点では [index] index/ ディレクトリへの masstree_wrapper 移設とインデックスエイリアス層の導入 #88 / [index] 第2インデックス yakushima の統合（ビルド統合 + YakushimaWrapper 実装） #89 が完了し、index/masstree/wrapper.hh と index/yakushima/wrapper.hh が同じ public API 面 (get_value / insert_value / remove_value / scan / thread_init / table_init / 共通 insert_info_t / node_type / ScanCallback) を提供しているはず。
• 7 プロトコル (cicada / ermia / mocc / oze / si / silo / tictoc) が node-version ベースの phantom 回避 (scan_callback.hh の on_resp_node / transaction.hh の node_map_ / transaction.cc のコミット時再検証) を使っている。d2pl / mvto / ss2pl は node-version phantom 回避を使っていない。
• masstree も yakushima も「ノードバージョン + tx ローカル version map のコミット時再検証」という同じ phantom 回避モデルを持つ (yakushima の node_version64 は masstree の version と同型 — [index] 第2インデックス yakushima の統合（ビルド統合 + YakushimaWrapper 実装） #89 で確認済み)。

やること

• get / insert / remove / scan を要求する C++20 concept IndexConcept を定義。
• PhantomStrategy を独立した concept として切り出す:
  • masstree / yakushima 共通の「ノードバージョン版」phantom 回避戦略。
  • 将来の非ノードバージョン系インデックス向けに「レンジロック / 述語ロック版」の余地を残す。
• 各プロトコルが <IndexConcept, PhantomStrategy> をテンプレートパラメータとして受け取る形にリファクタ。
• static_assert / concept で API 契約をコンパイル時に強制 ([P1] TxExecutorコントラクトをC++20 conceptで明示する #31 の TxExecutor concept 化と同じ思想)。

設計上の論点 (このイシューで決める)

• インデックス選択の粒度: per-protocol (テンプレートパラメータ) / per-binary (cmake オプション) / per-workload のどれにするか。当面は [index] index/ ディレクトリへの masstree_wrapper 移設とインデックスエイリアス層の導入 #88 で導入した per-binary -DCCBENCH_INDEX を維持しつつ、concept 化で per-protocol テンプレート化への道を開くのが現実的。
• PhantomStrategy を concept として本当に分離する価値があるか (現状 2 実装とも同じノードバージョン版なので、3 つ目の非ノードバージョン系インデックスが現れるまでは YAGNI の可能性もある — 着手時に再評価)。

スコープ外

• 新規バックエンドの追加そのもの。
• tpcc_silo/ の旧ユニットテスト復活 (インデックス層と独立した論点、必要なら [P6] テストインフラを機能させる + 分離レベル正当性を椚認するテストを追加する #35 系で別途)。

完了条件

• IndexConcept / PhantomStrategy concept が定義され、masstree / yakushima の両 wrapper がそれを満たす。
• プロトコルがテンプレートパラメータでインデックスを受け取れる。
• 2 バックエンドで全プロトコルがビルド・動作する。

優先度

高リスク・将来。masstree + yakushima の 2 実装が安定稼働してから着手する。急がない。