diff --git a/tickets/tui-knowledge-completion.md b/tickets/tui-knowledge-completion.md deleted file mode 100644 index 0013c052..00000000 --- a/tickets/tui-knowledge-completion.md +++ /dev/null @@ -1,63 +0,0 @@ -# TUI `#` Knowledge 補完の未実装解消 - -## 背景 - -TUI 入力欄で `#` を打つと `CompletionKind::Knowledge` で Pod に `ListCompletions` を投げる導線は既にある（`crates/tui/src/input.rs`、`crates/tui/src/app.rs`）。一方 Pod 側 IPC は `crates/pod/src/ipc/server.rs:105` で - -```rust -protocol::CompletionKind::Knowledge => Vec::new(), -``` - -と無条件に空ベクタを返しており、ワークスペースに knowledge エントリがあっても TUI 上では候補が一切出ない。`#` で何も出ないのはフロントマター（`model_invokation`）の問題ではなく、補完経路そのものが未配線。 - -Workflow 側は同じ構造で既に動いている： - -- `Pod::workflow_completions()` → `Vec`（`crates/pod/src/pod.rs:1236`） -- `PodController::start` で `PodSharedState::set_workflows()` に投入（`crates/pod/src/controller.rs:385`） -- IPC が `shared_state.list_workflow_completions(prefix)` を引いて返す - -Knowledge も同じ形に揃えれば足りる。 - -## 前提 - -- knowledge の物理レイアウトは `/.insomnia/knowledge/.md`（`crates/memory/src/workspace.rs`）。 -- memory クレートには `collect_resident_knowledge` があるが、これは `model_invokation: true` のみを返す resident-injection 用 API で、補完用途には不適。 -- `#` 補完では「ユーザーが参照可能な knowledge slug すべて」を返したい（`model_invokation` は resident 注入対象のフラグであって参照可否ではない）。 -- workflow の `list_user_invocable` に相当する「列挙 API」が memory クレートに無いので追加が要る。 - -## 方針 - -- memory クレートに「knowledge slug 一覧を返す」公開 API を追加する。`collect_resident_knowledge` とは別関数とし、`model_invokation` でフィルタしない。frontmatter が壊れているファイルは silently skip する（`collect_resident_knowledge` と同じく Linter が write 時に shape を保証する前提）。 -- `PodSharedState` に knowledge 候補スロット（`workflows` と同形の `OnceLock>`）を追加し、`PodController::start` で memory layout から列挙して投入する。memory layout 未設定の Pod（`Pod::memory_layout` が `None`）では空のまま残す。 -- IPC server の `CompletionKind::Knowledge` 分岐を、`shared_state.list_knowledge_completions(&prefix)` を引いて `CompletionEntry { value: slug, is_dir: false }` に詰める実装に置き換える。 -- 補完結果の並びは slug 昇順、prefix マッチは `starts_with`（workflow と揃える）。 - -## 要件 - -- TUI で `#` を入力した状態で、ワークスペース `.insomnia/knowledge/` 配下に存在する slug（`model_invokation` の真偽に関わらず）が候補として列挙される。 -- `#foo` のように prefix 入力中の場合、prefix にマッチする slug のみが返る。 -- memory layout が無効な Pod（`memory_layout: None`）では空ベクタが返り、エラーにはならない。 -- 確定時の挙動（`replace_with_knowledge_ref` → `Segment::KnowledgeRef` 化、`#slug` チップ表示）は既存の TUI 側の実装をそのまま使う。Pod 側補完を埋めるだけで TUI 改修は不要。 -- 単体テストで以下をカバーする - - 全件列挙（複数 slug、`model_invokation: true/false` 混在で全部返る） - - prefix フィルタ - - knowledge ディレクトリ不在時の空ベクタ - - 壊れた frontmatter / `.md` 以外のファイルがスキップされる - -## 範囲外 - -- knowledge のフロントマター仕様変更や、補完候補に description / model_invokation を載せて TUI で表示する強化（`CompletionEntry.value` 以外の表示は別チケットで検討） -- workflow / file の補完経路への手入れ -- resident 注入経路（`collect_resident_knowledge` の挙動）の変更 - -## 参照 - -- 未実装箇所: `crates/pod/src/ipc/server.rs:105` -- mirror 対象: `crates/pod/src/pod.rs:1236`（`workflow_completions`）、`crates/pod/src/shared_state.rs:74-89`、`crates/pod/src/controller.rs:385-390` -- TUI 側既存導線: `crates/tui/src/input.rs:260`、`crates/tui/src/app.rs:281,315` -- 列挙対象: `crates/memory/src/workspace.rs`（`knowledge_dir`）、`crates/memory/src/resident.rs`（参考） - -## Review -- 状態: Approve -- レビュー詳細: [./tui-knowledge-completion.review.md](./tui-knowledge-completion.review.md) -- 日付: 2026-05-12 diff --git a/tickets/tui-knowledge-completion.review.md b/tickets/tui-knowledge-completion.review.md deleted file mode 100644 index e3010c4c..00000000 --- a/tickets/tui-knowledge-completion.review.md +++ /dev/null @@ -1,35 +0,0 @@ -# Review: TUI `#` Knowledge 補完の未実装解消 - -対象実装: `7b8eb3a feat(pod): wire knowledge slugs into # completion` (branch `tui-knowledge-completion`) - -## 前提・要件の確認 - -要件4項目すべてを diff 上に対応コードと根拠付きで確認した。 - -- 「`.insomnia/knowledge/` 配下の slug が `model_invokation` の真偽に関わらず列挙される」: `memory::list_knowledge_slugs` が `walk_knowledge` を `model_invokation` フィルタなしで通す（`crates/memory/src/resident.rs:47-52`）。テスト `list_slugs_returns_all_regardless_of_model_invokation`（同 `:196-204`）が `true/false/true` の 3 件を全部返すことを確認している。 -- 「`#foo` の prefix 入力中は prefix マッチのみが返る」: `PodSharedState::list_knowledge_completions` が `starts_with` で絞り込み（`crates/pod/src/shared_state.rs:102-113`）。テスト `knowledge_completions_filter_by_prefix`（同 `:262-287`）が `alpha` prefix で `alpha`/`alphabet` のみ返り、`zzz` で空、空 prefix で全件、を確認。 -- 「memory_layout が None の Pod で空ベクタ、エラーにならない」: `Pod::knowledge_completions` が `memory_layout.as_ref().map(...).unwrap_or_default()` で短絡（`crates/pod/src/pod.rs:1240-1245`）。controller も `Vec` を素通しで `set_knowledge` に渡すだけで panic 経路なし（`crates/pod/src/controller.rs:391-396`）。IPC 側も `OnceLock` 未 set で空を返す（テスト `knowledge_completions_empty_when_unset` `:256-260` で確認）。 -- 「確定時挙動は既存 TUI のまま、Pod 側を埋めるだけ」: TUI クレートには変更なし。IPC server の `CompletionKind::Knowledge` 分岐のみが `Vec::new()` から実装に差し替えられている（`crates/pod/src/ipc/server.rs:105-113`）。`CompletionEntry` の `value` に slug、`is_dir: false` を詰める形は Workflow 分岐と完全に同形。 - -単体テスト 4 項目もすべて存在し、`cargo test -p memory --lib resident::` と `cargo test -p pod --lib shared_state::` でグリーン。 - -## アーキテクチャ・スコープ - -- 列挙 API を `memory` クレート（低レベル workspace 操作の所在）に追加し、Pod 層は Memory layout から「引いて詰めるだけ」というレイヤ分割を保っている。`llm-worker` を巻き込まない、higher-level は上層という方針に合致。 -- `WorkflowCandidate` / `set_workflows` / `list_workflow_completions` と `KnowledgeCandidate` / `set_knowledge` / `list_knowledge_completions` がフィールド順・docstring の有無・実装行数まで揃っており、mirror 対象（`shared_state.rs:74-89`、`controller.rs:385-390`、`pod.rs:1236`）のスタイルと一貫している。 -- `walk_knowledge` の共通化は `FnMut(String, KnowledgeFrontmatter)` 1 つの最小抽象で、2 呼び出し元の重複（`read_dir` のエラー早抜け、非 `.md` スキップ、frontmatter parse スキップ）を素直にまとめている。やりすぎ（Iterator 化、ジェネリック化）はしておらず、CLAUDE.md の「変更量を最小に」「設計を歪めない」に合致する。逆に共通化を見送って書き写すと 30 行程度の同形コード重複になるので、この程度の抽出は妥当。 -- 範囲外は守られている。frontmatter スキーマ、`collect_resident_knowledge` の挙動（`model_invokation: true` のみ返す resident 注入用途）、workflow/file 補完経路、TUI コードへの手入れは一切なし。 - -## 指摘事項 - -### Non-blocking / Follow-up - -- なし。 - -### Nits - -- `crates/memory/src/resident.rs:26-28` の `collect_resident_knowledge` の docstring が `/knowledge/*.md` のままで、実 path `/.insomnia/knowledge/*.md`（`list_knowledge_slugs` 側の docstring `:43-46` では正しく書かれている）と齟齬がある。本チケットの範囲外の既存記述だが、隣接行を編集したついでに同期しておくと整う。今回は追わなくてよい。 - -## 判断 - -Approve — ticket の前提・方針・要件・テスト 4 項目すべてに対応コードとパスする単体テストがあり、範囲外を踏まず、Workflow 経路と整合した最小実装になっている。