[BUG] --with-snippet が空文字列を返す（related/impact）

[Kewton]

再現手順

commandindexdev index --path .
commandindexdev search --related src/components/worktree/TerminalDisplay.tsx --format json --with-snippet --limit 3

期待される動作

各結果の snippet フィールドにファイル本文の先頭部分（デフォルト500文字/10行）が含まれる。
また、file_path フィールドにはインポートパスではなく実ファイルの相対パスが含まれる。

実際の動作

{"path":"@/components/worktree/TerminalSearchBar","relations":["import_dependency"],"score":1.3,"snippet":""}
{"path":"react","relations":["import_dependency"],"score":0.9,"snippet":""}
{"path":"@/hooks/useTerminalSearch","relations":["import_dependency"],"score":0.9,"snippet":""}

全結果で snippet が空文字列 ""。--format llm でも同様にスニペットが含まれない。
さらに、path フィールドがインポートパス（@/components/..., react）のまま返され、実ファイルパス（src/components/...）に変換されていない。

根本原因

問題1: related検索結果の file_path がインポートパスのまま

score_import_deps() (related.rs:181) が imp.target_module.clone() をscores HashMapのキーとして使用。
target_module はTypeScriptパーサから直接取得したインポートパス（例: @/components/worktree/TerminalSearchBar, react）であり、
tantivyインデックスに保存された実ファイルパス（例: src/components/worktree/TerminalSearchBar.tsx）と一致しない。

問題2: 逆方向ルックアップの不一致

find_imports_by_target(target) (related.rs:194) は正規化された実ファイルパスでSQLiteを検索するが、
dependencies.target_module にはインポートパス形式で格納されているため、逆方向の依存関係（「このファイルをimportしているファイル」）も常に0件になる。

問題3: snippet空はパス不一致の副作用

fetch_snippet() が search_by_exact_path() でtantivy TermQuery完全一致検索を行うが、
インポートパス形式のキーでは実ファイルパスにマッチせず、空文字列が返される。

影響範囲

related サブコマンド

• commandindex search --related <file> --with-snippet でsnippetが空
• file_path がインポートパスのまま返される
• enrich_related_with_snippets() (snippet_helper.rs:66) が影響

impact サブコマンド

• commandindex impact <file> --with-snippet でもsnippetが空
• enrich_impact_with_snippets() (snippet_helper.rs:47) が影響
• aggregate_impact() (impact.rs) が find_related の結果をそのまま使用するため、impacted_files にインポートパスが出力される

context サブコマンド

• context.rs の enrich_entry 内 find_imports_by_source(path) も影響
• ImportDependency 関連のエンリッチメント（symbols フィールド）が不正確になる可能性

影響を受けないコマンド

• keyword search (run) — score_import_deps を経由しない
• symbol search (run_symbol_search) — score_import_deps を経由しない
• semantic search (run_semantic_search) — score_import_deps を経由しない
• 出力フォーマッタ (json/llm/human/path) — file_pathを受け取って表示するだけ

LLMコンテキスト提供

• CommandIndexの差別化機能（コード内容付きの関連ファイル出力）が機能しない
• LLMエージェントへのコンテキスト提供において、パス一覧のみになり file.read の代替にならない

受け入れ基準

1. --with-snippet 指定時、相対パスインポート（./xxx, ../xxx）の結果で snippet が非空であること
2. エイリアスインポート（@/xxx）の結果でも snippet が非空であること（パスエイリアス解決により）
3. 外部パッケージ（react 等、tantivyインデックスに存在しないもの）は snippet 空文字列を許容する
4. --format json と --format llm の両方で snippet が正しく出力されること
5. related検索結果の file_path が実ファイルの相対パスで返されること
6. impact検索結果のimpacted_filesも実ファイルパスで返されること
7. 既存テスト（cargo test --all）が全てパスすること
8. cargo clippy --all-targets -- -D warnings が警告0件であること
9. import依存関係のE2Eテスト（--with-snippet付き）が追加されていること

解決方針

案A（推奨）: score_import_deps 内で、インポートパスからtantivyインデックスのファイルパスをマッチングで解決する

• 最も局所的かつ安全
• パフォーマンス: resolve結果のキャッシュまたはメモリ上マッチングで軽微
• M1修正でsnippet問題（M3）も連鎖的に解決

案B（将来対応）: インデックス時にインポートパスを実ファイルパスに解決してSQLiteに保存

• スキーマ変更が必要（dependencies テーブルに resolved_file_path カラム追加）
• 既存インデックスとの互換性問題
• 根本的解決だが初期リリースでは案Aを優先

環境

• commandindex 0.1.0
• 対象リポジトリ: 388ソースファイル（TypeScript/Next.js）

深刻度

高

[Kewton]

追加調査結果: 根本原因の多角的分析

1. 直接原因: file_linksテーブルのtarget_fileがtantivyインデックスのパスと不一致

file_links.target_file:  ./ci-cd-plan.md
tantivy index path:       workspace/v0.0.0/ci-cd-plan.md

fetch_snippet() が search_by_exact_path("./ci-cd-plan.md") で検索するが、tantivy内には workspace/v0.0.0/ci-cd-plan.md として格納されているため0件 → 空文字列。

file_linksの全target_fileがtantivyにマッチしないことを確認済み。

2. 根本原因: インデクサのリンクパス未正規化

src/cli/index.rs:440 でMarkdownリンクの target をそのまま保存している:

target_file: l.target.clone(),  // "./ci-cd-plan.md" がそのまま入る

正しくは、source_fileの親ディレクトリからの相対パスを解決すべき:

• source: workspace/v0.0.0/README.md
• link target: ./ci-cd-plan.md
• 解決後: workspace/v0.0.0/ci-cd-plan.md

3. 影響範囲: related search自体のパス問題

snippet以前に、search --related の結果パス自体が不正:

{"path":"./ci-cd-plan.md","relations":["markdown_link"],"score":1.0}

このパスでは commandindex context ./ci-cd-plan.md も失敗する。
snippetだけでなく、related searchの結果パスが実ファイルと対応しない点が本質的な問題。

4. 副次的問題: パーサーの誤抽出

file_linksに意味のないエントリが存在:

source_file	target_file	link_type	原因
scenario.md	sources	WikiLink	# [[sources]] コメント見出し
issue-52-*.md	b.md	WikiLink	テストデータ例 [[b.md]]
issue-51-*.md	wiki-link	WikiLink	説明テキスト中の [[wiki-link]]
issue-51-*.md	path	MarkdownLink	説明テキスト中の [text](path)
issue-52-*.md	../src/c.ts	MarkdownLink	テストデータ例

コードブロック(```) 内やインラインコード内のリンク構文を除外するフィルタが不足。

5. import依存との対比

score_import_deps() では resolve_import_path() により @/components/Foo → src/components/Foo.tsx のようにインデックス内パスに解決しているが、score_markdown_links() には同等の解決処理がない。

修正提案

優先度	箇所	修正内容
P0	src/cli/index.rs:440	リンクtargetをsource_fileの親ディレクトリからの相対パスとして正規化してからDB保存
P0	src/search/related.rs:252	score_markdown_linksでtarget_fileをインデックス済みパスに解決（resolve_import_path相当の処理）
P1	src/cli/snippet_helper.rs:18	fetch_snippetでパス不一致時に./除去やサフィックスマッチによるフォールバック検索
P2	src/parser/link.rs	コードブロック・インラインコード内のリンク構文を除外するフィルタ追加

[Kewton]

追加調査結果（修正後の再テスト）

パス正規化の修正は有効

修正前: target_file = ./ci-cd-plan.md
修正後: target_file = workspace/v0.0.0/ci-cd-plan.md  ✅

related searchの結果パスも正しく正規化されていることを確認。

残存問題: snippetが依然一部空文字列

修正後の実機テスト結果:

ファイル	snippet	原因
repository-layout.md	✅ 41文字	最初のセクションにbodyあり
ci-cd-plan.md	✅ 46文字	最初のセクションにbodyあり
claude-code-setup.md	❌ 空	最初のセクション(heading=Claude Code 統合計画)のbody=0文字
initial-implementation-slice.md	❌ 空	TermQueryのスコア順で返される最初の結果のbodyが空
dev-environment-plan.md	❌ 空	同上

根本原因: fetch_snippet が最初の1セクションのみ参照

src/cli/snippet_helper.rs:20-21:

if let Some(first) = docs.first()
    && !first.body.is_empty()

search_by_exact_path() は同一pathの全セクション（複数heading）を返すが、最初の1件のbodyのみチェック。Markdownファイルは「H1見出し → body空」「H2見出し → bodyあり」のパターンが一般的で、最初のセクション（H1タイトル）はbodyが空になりやすい。

修正提案

fetch_snippet を修正して、bodyが非空の最初のセクションを使用する:

// 修正前
if let Some(first) = docs.first() && !first.body.is_empty() {

// 修正後
if let Some(doc) = docs.iter().find(|d| !d.body.is_empty()) {

これにより、H1タイトルセクション（body空）をスキップして、最初のコンテンツ付きセクションからsnippetを取得できる。

[Kewton]

残存不具合: snippetが一部ファイルで空文字列

事象

パス正規化修正後も、一部ファイルで --with-snippet のsnippetが空文字列を返す。

実機テスト結果（5件中3件が空）:

workspace/v0.0.0/repository-layout.md  → snippet=41文字 ✅
workspace/v0.0.0/ci-cd-plan.md         → snippet=46文字 ✅
workspace/v0.0.0/claude-code-setup.md  → snippet=空     ❌
workspace/v0.0.0/initial-implementation-slice.md → snippet=空 ❌
workspace/v0.0.0/dev-environment-plan.md → snippet=空   ❌

原因

src/cli/snippet_helper.rs:20 の fetch_snippet() が docs.first() で最初の1セクションのbodyのみを参照。

Markdownファイルは「H1タイトル → body空」「H2以降 → bodyあり」が一般的。tantivyは同一pathに対して複数セクション（heading単位）を返すが、最初のセクション（H1）のbodyが空の場合、後続のコンテンツ付きセクションを無視して空文字列を返す。

// 現在のコード
if let Some(first) = docs.first()
    && !first.body.is_empty()  // H1のbodyが空 → false → 空文字列

対策

docs.first() を docs.iter().find(|d| !d.body.is_empty()) に変更し、bodyが非空の最初のセクションからsnippetを取得する。