概要
現在issueコマンドはIssue番号を引数に取るが、インデックス内にどのIssueが含まれるかを知る手段がない。Issue番号を知らないユーザーやAIエージェントはissueコマンドの入口がない。
現状
commandindexdev issue 299 # Issue番号を知っていれば使える
commandindexdev issue ??? # 何番があるか知る方法がない
期待される結果
commandindexdev issue list
# Issue #47 (5 docs) terminal-search
# Issue #99 (5 docs) markdown-editor-display-improvement
# Issue #104 (7 docs) ipad-fullscreen-bugfix
# Issue #112 (6 docs) sidebar-transform
# ...
# Total: 142 issues
commandindexdev issue list --format json
# [{"number": 47, "doc_count": 5, "label": "terminal-search", "has_design": true, "has_workplan": true, "has_review": true, "has_progress": false}, ...]
CLI設計方針
既存の issue コマンド(issue <number>)をサブコマンド構造に変更する:
issue list — インデックス内の全Issue一覧を表示
issue show <number> — 既存の Issue 詳細表示(現在の issue <number> を移行)
- Config コマンドと同様の IssueCommands enum パターンを使用
- Breaking Change:
issue <number> → issue show <number> に変更(旧構文は完全廃止、clapのサブコマンドエラーが返る)
データ取得方法
knowledge_nodes テーブルで type='issue' のノードを取得
knowledge_edges テーブルと JOIN し、各Issue に紐づくドキュメントを集計
doc_count のカウント対象: has_design, has_review, has_workplan, has_progress リレーションのみ(modifies は対象外)
SymbolStore に list_all_issues() メソッドを追加
- ソート順: Issue番号の昇順(自然数順)
SQLクエリ設計
SELECT
kn_issue.identifier AS issue_number,
COUNT(CASE WHEN ke.relation IN ('has_design','has_review','has_workplan','has_progress')
AND kn_doc.type = 'document' THEN 1 END) AS doc_count,
COUNT(CASE WHEN ke.relation = 'has_design' THEN 1 END) > 0 AS has_design,
COUNT(CASE WHEN ke.relation = 'has_review' THEN 1 END) > 0 AS has_review,
COUNT(CASE WHEN ke.relation = 'has_workplan' THEN 1 END) > 0 AS has_workplan,
COUNT(CASE WHEN ke.relation = 'has_progress' THEN 1 END) > 0 AS has_progress
FROM knowledge_nodes kn_issue
LEFT JOIN knowledge_edges ke ON ke.source_id = kn_issue.id
LEFT JOIN knowledge_nodes kn_doc ON ke.target_id = kn_doc.id AND kn_doc.type = 'document'
WHERE kn_issue.type = 'issue'
GROUP BY kn_issue.identifier
ORDER BY CAST(kn_issue.identifier AS INTEGER)
パフォーマンス: knowledge_nodes の idx_kn_type インデックスが活用される。現在の規模では問題ないが、Issue/edge数が大幅に増えた場合は EXPLAIN QUERY PLAN で確認し、必要に応じて --limit オプション追加を検討する。
label取得ロジック
- 設計書ファイル名から正規表現で抽出(
issue-{number}-{label}-design-policy.md の {label} 部分)
- 設計書がない場合は空文字列
- 正規表現は静的に再利用(毎回組み立てない)
出力フォーマット
| format |
出力内容 |
human |
Issue #N (M docs) label 形式 + Total行 |
json |
[{"number": N, "doc_count": M, "label": "...", "has_design": bool, "has_review": bool, "has_workplan": bool, "has_progress": bool}, ...] |
path |
Issue番号を1行1つで出力 |
llm |
Markdownテーブル形式 |
0件時の挙動
- 終了コード: 0(成功)
human: No issues found.\nTotal: 0 issues
json: []
path: 空出力
llm: No issues found.
symbols.db 未作成時の挙動
issue list: 既存の issue show と同様にエラー終了(DBファイルが見つからないエラー)
- 0件とDB未作成は明確に区別する
影響範囲
変更が必要なファイル
| ファイル |
変更内容 |
src/cli/issue.rs |
サブコマンド構造化、list 関数追加 |
src/main.rs |
IssueCommands enum 定義、ディスパッチャー変更 |
src/indexer/symbol_store.rs |
list_all_issues() メソッド追加 + 単体テスト |
src/cli/help_llm.rs |
LLMガイダンスの issue コマンド説明・全参照箇所を更新 |
src/cli/suggest.rs |
生成コマンドを issue show <number> に更新 |
tests/e2e_issue.rs |
全テスト issue show 形式に更新 + issue list テスト追加 |
tests/cli_args.rs |
全テスト更新 + issue list パーステスト追加 |
機能本体は影響なし(ヘルプ/ガイダンス文脈の整合確認は必要)
src/cli/before_change.rs, src/cli/why.rs — SymbolStore API を直接利用
受け入れ基準
実装案
- Config コマンドと同様の IssueCommands enum パターンでサブコマンド化
SymbolStore に list_all_issues() メソッドを追加(条件付きJOIN + GROUP BY、1クエリで集計)
- 各Issueのドキュメント件数、設計書の有無、ラベルを表示
--format human/json/path/llm 対応
list_all_issues() はページネーションやフィルタ追加に拡張しやすい設計にする
対象バリュー
- Issue中心: Issue番号を知らなくても、インデックス内の全Issueを俯瞰できる
概要
現在
issueコマンドはIssue番号を引数に取るが、インデックス内にどのIssueが含まれるかを知る手段がない。Issue番号を知らないユーザーやAIエージェントはissueコマンドの入口がない。現状
期待される結果
CLI設計方針
既存の
issueコマンド(issue <number>)をサブコマンド構造に変更する:issue list— インデックス内の全Issue一覧を表示issue show <number>— 既存の Issue 詳細表示(現在のissue <number>を移行)issue <number>→issue show <number>に変更(旧構文は完全廃止、clapのサブコマンドエラーが返る)データ取得方法
knowledge_nodesテーブルでtype='issue'のノードを取得knowledge_edgesテーブルと JOIN し、各Issue に紐づくドキュメントを集計doc_countのカウント対象:has_design,has_review,has_workplan,has_progressリレーションのみ(modifiesは対象外)SymbolStoreにlist_all_issues()メソッドを追加SQLクエリ設計
パフォーマンス: knowledge_nodes の
idx_kn_typeインデックスが活用される。現在の規模では問題ないが、Issue/edge数が大幅に増えた場合はEXPLAIN QUERY PLANで確認し、必要に応じて--limitオプション追加を検討する。label取得ロジック
issue-{number}-{label}-design-policy.mdの{label}部分)出力フォーマット
humanIssue #N (M docs) label形式 + Total行json[{"number": N, "doc_count": M, "label": "...", "has_design": bool, "has_review": bool, "has_workplan": bool, "has_progress": bool}, ...]pathllm0件時の挙動
human:No issues found.\nTotal: 0 issuesjson:[]path: 空出力llm:No issues found.symbols.db 未作成時の挙動
issue list: 既存のissue showと同様にエラー終了(DBファイルが見つからないエラー)影響範囲
変更が必要なファイル
src/cli/issue.rslist関数追加src/main.rssrc/indexer/symbol_store.rslist_all_issues()メソッド追加 + 単体テストsrc/cli/help_llm.rssrc/cli/suggest.rsissue show <number>に更新tests/e2e_issue.rsissue show形式に更新 +issue listテスト追加tests/cli_args.rsissue listパーステスト追加機能本体は影響なし(ヘルプ/ガイダンス文脈の整合確認は必要)
src/cli/before_change.rs,src/cli/why.rs— SymbolStore API を直接利用受け入れ基準
issue listで全Issueが番号昇順で表示される--format jsonで有効なJSON配列が出力される(has_design, has_review, has_workplan, has_progress を含む)--format humanで Total行が表示されるNo issues found.+Total: 0 issuesが表示され、終了コード0symbols.db未作成時にエラー終了する--format pathでIssue番号が1行ずつ出力される--format llmでMarkdownテーブル形式で出力されるissue show <number>が従来と同じ動作をするissue <number>がclapのサブコマンドエラーを返すissue --helpが list/show サブコマンドを表示するsrc/cli/suggest.rsの生成コマンドがissue show <number>に更新されているhelp_llm.rsのLLMガイダンスが全箇所更新されている(旧構文の参照がコードベース内に残っていない)tests/e2e_issue.rsの全テストがパスするtests/cli_args.rsのissue関連テストがパスするsrc/indexer/symbol_store.rsのlist_all_issues()単体テストがパスする(modifies混在ケース含む)実装案
SymbolStoreにlist_all_issues()メソッドを追加(条件付きJOIN + GROUP BY、1クエリで集計)--format human/json/path/llm対応list_all_issues()はページネーションやフィルタ追加に拡張しやすい設計にする対象バリュー