why/issueのJSON出力に日付情報を付与する

[Kewton]

概要

why --format json と issue --format json の出力に日付情報がなく、判断の時系列を追えない。

現状

{
  "file_path": "dev-reports/design/issue-123-sample-design-policy.md",
  "relation": "has_design",
  "doc_subtype": "DesignPolicy"
  // 日付なし
}

期待される結果

why --format json

{
  "file_path": "dev-reports/review/2026-02-18-issue299-security-review-stage4.md",
  "relation": "has_review",
  "doc_subtype": "SecurityReview",
  "date": "2026-02-18"
}

日付が取得できない場合:

{
  "file_path": "dev-reports/design/issue-123-sample-design-policy.md",
  "relation": "has_design",
  "doc_subtype": "DesignPolicy",
  "date": null
}

issue --format json（破壊的変更あり）

変更前（カテゴリ別文字列配列）:

{
  "issue_number": 299,
  "designs": [
    "dev-reports/design/issue-299-sample-design-policy.md"
  ],
  "reviews": [
    "dev-reports/review/2026-02-18-issue299-security-review-stage4.md"
  ]
}

変更後（カテゴリ別オブジェクト配列 {file_path, date}）:

{
  "issue_number": 299,
  "designs": [
    { "file_path": "dev-reports/design/issue-299-sample-design-policy.md", "date": "2026-02-15" }
  ],
  "reviews": [
    { "file_path": "dev-reports/review/2026-02-18-issue299-security-review-stage4.md", "date": "2026-02-18" }
  ]
}

⚠ 破壊的変更: issue --format json のカテゴリ値が文字列配列からオブジェクト配列に変わる。既存のJSONパーサーに影響する。

受け入れ基準

1. why --format json の出力に date フィールド（string | null）が含まれること
2. issue N --format json の出力に date フィールド（string | null）が含まれること
3. ファイル名に日付パターン（YYYY-MM-DD-*）が含まれる場合、そこから抽出されること
4. ファイル名に日付がない場合は git log --format=%ai -1 -- <path> から取得すること
5. いずれの方法でも取得できない場合は null を返すこと

日付の取得方法

優先順位（2段階）:

1. ファイル名から抽出: 2026-02-18-issue299-*.md → 2026-02-18
   • 現状、日付プレフィックスがあるのは Stage Review ファイル（YYYY-MM-DD-issue*-*-review-stage*.md）のみ。Design Policy や Work Plan 等は日付プレフィックスを持たないため、この方法では取得できない
2. git log由来（フォールバック）: git log --format=%ai -1 -- <path> の結果をインデックス時に保存
   • ファイル名に日付がないすべてのケースで使用

日付フォーマットは ISO 8601（YYYY-MM-DD）とする。取得不可の場合は null。

影響範囲

変更対象の構造体一覧

構造体	ファイル	変更内容
WhyDocumentEntry	src/output/mod.rs	date: Option<String> フィールド追加。group_knowledge_results で日付取得ロジック追加（M1）
IssueDocumentEntry	src/indexer/knowledge.rs	date: Option<String> フィールド追加。find_documents_by_issue では None 設定し、呼び出し側で付与（M2）
KnowledgeEntry	src/indexer/knowledge.rs	ナレッジグラフのエントリ（インデックス時に日付を保存）
KnowledgeDocResult	src/indexer/symbol_store.rs	ナレッジグラフクエリの結果

破壊的変更

• issue --format json のJSONスキーマが変更される（M3）
  • カテゴリ別の値が string[] → {file_path: string, date: string | null}[] に変わる
  • 既存のJSONパーサーは修正が必要

新規実装

• 日付取得ユーティリティ関数（M4）
  • ファイル名からの正規表現抽出（YYYY-MM-DD パターン）
  • git log フォールバック
  • 配置先: 新規モジュールまたは既存ユーティリティ内

テスト修正箇所（約20箇所）

• IssueDocumentEntry の初期化箇所に date: None 追加（S1）
• WhyDocumentEntry の初期化箇所に date: None 追加（S2）
• issue --format json の e2e テストでスキーマ更新（S3）
• why --format json の e2e テストでスキーマ更新（S4）

将来的な拡張候補

• KnowledgeRelatedResult にも date 追加の可能性あり（N3）

実装方針

1. 日付取得ユーティリティ関数の設計

/// ファイルパスから日付を取得する
/// 1. ファイル名の先頭 YYYY-MM-DD パターンを正規表現で抽出
/// 2. マッチしなければ git log --format=%ai -1 -- <path> にフォールバック
/// 3. いずれも失敗した場合は None
fn extract_date_from_path(file_path: &str) -> Option<String>

• 初期実装では個別に git log を実行する方式で十分（N1: パフォーマンス最適化は後回し）

2. メタデータ格納方式

• KnowledgeEntry / KnowledgeDocResult に date カラムを追加
• SQLite マイグレーション: 既存テーブルに ALTER TABLE ... ADD COLUMN date TEXT で nullable カラム追加
• 再インデックス（commandindexdev index）で日付情報が生成される

3. 出力時の日付付与フロー

• why コマンド: group_knowledge_results 内で KnowledgeDocResult から日付を取得し WhyDocumentEntry.date に設定
• issue コマンド: find_documents_by_issue は date: None で返却 → 呼び出し側で日付取得ユーティリティを使って付与

マイグレーション戦略

• 既存インデックスに date カラムが存在しない場合は null として扱う
• commandindexdev index を再実行することで日付情報が再生成される
• DBスキーマ上は nullable カラム追加のため後方互換性あり
• ただし issue --format json のJSON出力は破壊的変更 となる（上記「破壊的変更」セクション参照）

対象バリュー

• 透明性: 「なぜそう判断したか」を追うには時系列が不可欠。設計(2/15)→レビュー(2/18)→実装(2/20)の順序がわかって初めて判断の経緯が見える

追加: issue --timeline オプション（別Issue検討）

Note: --timeline オプションは本Issueのスコープ外とし、別Issueとして検討する。本Issueでは日付フィールドの付与までを対象とする。

日付情報が付与されれば、将来的に issue 299 --timeline で時系列順に文書を並べ替えることも可能になる。

commandindexdev issue 299 --timeline
# 2026-02-15  [design]   issue-299-sample-design-policy.md
# 2026-02-16  [review]   2026-02-16-issue299-design-principles-review-stage1.md
# 2026-02-18  [review]   2026-02-18-issue299-consistency-review-stage2.md
# 2026-02-18  [review]   2026-02-18-issue299-impact-analysis-review-stage3.md
# 2026-02-18  [review]   2026-02-18-issue299-security-review-stage4.md
# 2026-02-19  [workplan]  work-plan.md
# 2026-02-20  [progress]  progress-report.md

[Kewton]

Closed via PR #183 merged to main.