概要
why コマンドの出力で、pm-auto-dev/iteration-1/progress-report.md が [review] タグで表示される。進捗レポートはレビューとは異なるドキュメント種別であり、分類が不正確。
再現手順
commandindexdev why dev-reports/design/issue-299-ipad-layout-fix-design-policy.md
実際の結果
Issue #299
[review] dev-reports/issue/299/multi-stage-design-review/summary-report.md
[review] dev-reports/issue/299/pm-auto-dev/iteration-1/progress-report.md ← [review]?
[review] dev-reports/issue/299/issue-review/summary-report.md
...
期待される結果
Issue #299
[review] dev-reports/issue/299/multi-stage-design-review/summary-report.md
[progress] dev-reports/issue/299/pm-auto-dev/iteration-1/progress-report.md ← [progress]
[review] dev-reports/issue/299/issue-review/summary-report.md
...
根本原因分析(コードベース検証済み)
根本原因は4層構造:
- パターンルール:
src/indexer/knowledge.rs (384-388行) - progress-report.md が DocSubtype::ProgressReport として分類されるが、relation は HasReview で保存される
- SQLクエリ:
src/indexer/symbol_store.rs (1074行) - find_knowledge_related() が metadata を SELECT せず relation のみ取得
- データ構造:
src/output/mod.rs (409-412行) - WhyDocumentEntry に doc_subtype フィールドがない
- 表示ラベル:
src/output/human.rs (244-250行) - relation_display_label() が relation のみで表示ラベルを決定
参考: find_documents_by_issue() (symbol_store.rs 892-913行) は metadata を正しく取得・利用しており、issue コマンドでは正しく分類される。
実装方針
relation はそのままに、doc_subtype を why コマンドの出力パイプライン全体に伝搬させる:
find_knowledge_related() の SELECT 句に ke2.metadata を追加
KnowledgeRelatedResult に doc_subtype: Option<String> を追加
WhyDocumentEntry に doc_subtype: Option<String> を追加(#[serde(skip_serializing_if = "Option::is_none")])
group_knowledge_results() で doc_subtype を WhyDocumentEntry に伝搬
relation_display_label() を拡張し、doc_subtype が存在する場合はそちらを優先
- LLM出力でも
relation_display_label を適用して全出力フォーマットで一貫性を確保
受け入れ基準
影響範囲
変更対象ファイル
| ファイル |
変更内容 |
src/indexer/symbol_store.rs |
find_knowledge_related() SQL に metadata 追加、KnowledgeRelatedResult にフィールド追加 |
src/output/mod.rs |
WhyDocumentEntry に doc_subtype フィールド追加 |
src/output/human.rs |
relation_display_label() に doc_subtype 優先ロジック追加 |
src/output/llm.rs |
LLM出力で relation_display_label を適用 |
src/cli/why.rs |
group_knowledge_results() で doc_subtype 伝搬、テスト6箇所更新 |
影響を受けないコマンド
search / issue / suggest / impact / before-change / context-pack / diff / symbol / embed
search --related は find_knowledge_related を呼ぶが doc_subtype を参照しないため機能的影響なし
テスト影響
src/cli/why.rs -- 6テストで KnowledgeRelatedResult と WhyDocumentEntry リテラル修正
src/indexer/symbol_store.rs -- 6テストで戻り値検証修正
スコープ外
tdd-result.json / acceptance-result.json のパターンルール追加(別Issue)
テスト環境
- commandindex 0.1.0 (スキーマv4)
概要
whyコマンドの出力で、pm-auto-dev/iteration-1/progress-report.mdが[review]タグで表示される。進捗レポートはレビューとは異なるドキュメント種別であり、分類が不正確。再現手順
実際の結果
期待される結果
根本原因分析(コードベース検証済み)
根本原因は4層構造:
src/indexer/knowledge.rs(384-388行) - progress-report.md がDocSubtype::ProgressReportとして分類されるが、relation はHasReviewで保存されるsrc/indexer/symbol_store.rs(1074行) -find_knowledge_related()がmetadataを SELECT せずrelationのみ取得src/output/mod.rs(409-412行) -WhyDocumentEntryにdoc_subtypeフィールドがないsrc/output/human.rs(244-250行) -relation_display_label()が relation のみで表示ラベルを決定参考:
find_documents_by_issue()(symbol_store.rs 892-913行) は metadata を正しく取得・利用しており、issue コマンドでは正しく分類される。実装方針
relation はそのままに、
doc_subtypeを why コマンドの出力パイプライン全体に伝搬させる:find_knowledge_related()の SELECT 句にke2.metadataを追加KnowledgeRelatedResultにdoc_subtype: Option<String>を追加WhyDocumentEntryにdoc_subtype: Option<String>を追加(#[serde(skip_serializing_if = "Option::is_none")])group_knowledge_results()でdoc_subtypeをWhyDocumentEntryに伝搬relation_display_label()を拡張し、doc_subtypeが存在する場合はそちらを優先relation_display_labelを適用して全出力フォーマットで一貫性を確保受け入れ基準
progress-report.mdが[progress]タグで表示されること[review]/[design]/[workplan]/[modifies]の分類が影響を受けないことdoc_subtypeが反映されること(skip_serializing_ifで後方互換)cargo clippy --all-targets -- -D warnings警告0件cargo test --all全テストパス影響範囲
変更対象ファイル
src/indexer/symbol_store.rsfind_knowledge_related()SQL に metadata 追加、KnowledgeRelatedResultにフィールド追加src/output/mod.rsWhyDocumentEntryにdoc_subtypeフィールド追加src/output/human.rsrelation_display_label()に doc_subtype 優先ロジック追加src/output/llm.rsrelation_display_labelを適用src/cli/why.rsgroup_knowledge_results()で doc_subtype 伝搬、テスト6箇所更新影響を受けないコマンド
search/issue/suggest/impact/before-change/context-pack/diff/symbol/embedsearch --relatedはfind_knowledge_relatedを呼ぶが doc_subtype を参照しないため機能的影響なしテスト影響
src/cli/why.rs-- 6テストでKnowledgeRelatedResultとWhyDocumentEntryリテラル修正src/indexer/symbol_store.rs-- 6テストで戻り値検証修正スコープ外
tdd-result.json/acceptance-result.jsonのパターンルール追加(別Issue)テスト環境