diff --git a/README.md b/README.md index 4a19478..2dae2f8 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # TelosDB -**Version 0.3.2** — ローカル完結型セマンティック検索基盤 & MCPサーバー +**Version 0.3.3** — ローカル完結型セマンティック検索基盤 & MCPサーバー --- diff --git a/docs/README.md b/docs/README.md index 90b5491..78be9ec 100644 --- a/docs/README.md +++ b/docs/README.md @@ -7,6 +7,7 @@ | ディレクトリ | 内容 | |-------------|------| | **specification/** | システム仕様・設計。アーキテクチャ、DB、MCP API、UI、開発ガイド、埋め込み・エディション、モノリシック化、KPI・検証、UI テスト、OpenAPI / MCP スキーマ。 | +| **plans/** | 今後の実装計画。計画ごとにサブフォルダを切る（例: `plans/folder_monitor/`）。 | | **issues/** | Issue 同期用の Markdown（Git 追跡外。`node tools/scripts/sync_issues.mjs` で同期）。 | | **references/** | 調査メモ・外部資料の参照。ベクトル化手法、BM25、Elasticsearch 等。 | @@ -28,4 +29,17 @@ - **12_ui_testing_options.md** — UI をテストに組み込む方法（E2E / Playwright 等） - **mcp.json**, **openapi.yaml** — MCP / API スキーマ +**plans/** は計画ごとにサブフォルダを置く。 + +- **plans/auto_start/** — ユーザーログイン時に自動起動する仕組み。検討事項別に分割（スコープ・技術方針・UI 改造・実装ステップ・注意事項・参照）。 +- **plans/folder_monitor/** — 指定フォルダ監視（追加・削除・更新の検出→DB取り込み・ベクトル化） +- **plans/lda/** — LDA（潜在的ディリクレ配分）の扱い。**v0.3.3 Community 版**で実装。LSA と LDA を切り替え、規定 128 次元・ユーザー指定で再構成。検討事項別に分割（スコープ・技術・**UI 改造**・実装ステップ・注意事項・参照）。 + - **folder_monitor.md** — 計画トップ（目的・目次） + - **folder_monitor_01_scope.md** — 01 スコープ + - **folder_monitor_02_tech.md** — 02 技術方針（notify・デバウンス・ネットワーク・Config 等） + - **folder_monitor_03_os_protocol.md** — 03 OS・ファイルプロトコル別実装方針 + - **folder_monitor_04_phases.md** — 04 実装ステップ（Phase 1〜5） + - **folder_monitor_05_considerations.md** — 05 注意事項・未決定 + - **folder_monitor_06_references.md** — 06 参照・調査元 + 運用ルール（Issue 管理・Git 運用など）は `.agent/rules/` にあります。 diff --git a/docs/plans/auto_start/auto_start.md b/docs/plans/auto_start/auto_start.md new file mode 100644 index 0000000..a9565d2 --- /dev/null +++ b/docs/plans/auto_start/auto_start.md @@ -0,0 +1,29 @@ +# 計画: ユーザーログイン時に自動起動する仕組み + +## 1. 目的 + +OS にユーザーがログインしたタイミングで TelosDB を自動的に起動し、システムトレイで待機させる。ユーザーが手動で起動しなくても MCP サーバーや検索機能を利用可能にする。 + +```mermaid +flowchart LR + subgraph ユーザー操作なし + A[OS ログイン] --> B[TelosDB 自動起動] + B --> C[トレイで待機] + C --> D[MCP / 検索 利用可能] + end +``` + +--- + +## 2. 検討事項別ドキュメント + +各検討事項は別ファイルに分割している。 + +| No. | 項目 | ファイル | 内容 | +|-----|------|----------|------| +| 01 | **スコープ** | [auto_start_01_scope.md](auto_start_01_scope.md) | 対応プラットフォーム、トリガー、起動後挙動、設定保存。 | +| 02 | **技術方針** | [auto_start_02_tech.md](auto_start_02_tech.md) | tauri-plugin-autostart、API、設定との連携。 | +| 03 | **UI 改造** | [auto_start_03_ui.md](auto_start_03_ui.md) | 設定パネルにトグル追加、配置・ラベル、仕様書更新。 | +| 04 | **実装ステップ** | [auto_start_04_phases.md](auto_start_04_phases.md) | Phase 1〜4 の実装順序。 | +| 05 | **注意事項・未決定** | [auto_start_05_considerations.md](auto_start_05_considerations.md) | トレイ起動、権限、競合。 | +| 06 | **参照** | [auto_start_06_references.md](auto_start_06_references.md) | プラグイン・Tauri 公式・06 仕様。 | diff --git a/docs/plans/auto_start/auto_start_01_scope.md b/docs/plans/auto_start/auto_start_01_scope.md new file mode 100644 index 0000000..fac2f4d --- /dev/null +++ b/docs/plans/auto_start/auto_start_01_scope.md @@ -0,0 +1,14 @@ +# 自動起動計画: 01 スコープ + +[計画トップ](auto_start.md) + +--- + +## スコープ + +| 項目 | 内容 | +|------|------| +| **対応プラットフォーム** | **Windows**（現行）、**macOS**、**Linux**。Tauri 2 の対応 OS に合わせて自動起動も各 OS で有効にする。 | +| **トリガー** | ユーザーが OS にログイン（サインイン）したとき。 | +| **起動後の挙動** | 通常起動と同様（ウィンドウまたはトレイで待機）。設定で「自動起動」のオン・オフを切り替え可能とする。 | +| **設定の保存** | 自動起動の有無はアプリ設定に永続化し、次回起動時にも反映する。 | diff --git a/docs/plans/auto_start/auto_start_02_tech.md b/docs/plans/auto_start/auto_start_02_tech.md new file mode 100644 index 0000000..da1cf21 --- /dev/null +++ b/docs/plans/auto_start/auto_start_02_tech.md @@ -0,0 +1,54 @@ +# 自動起動計画: 02 技術方針 + +[計画トップ](auto_start.md) + +--- + +## 3.1 採用: tauri-plugin-autostart + +- **プラグイン**: [tauri-plugin-autostart](https://github.com/tauri-apps/tauri-plugin-autostart)（[crates.io](https://crates.io/crates/tauri-plugin-autostart)）を採用する。 +- **対応 OS**: Windows / macOS / Linux でログイン時起動をサポート。Android / iOS は非対応（Tauri のデスクトップ用途と一致）。 +- **実装の裏側**（プラグインが担当）: + - **Windows**: レジストリ `HKCU\Software\Microsoft\Windows\CurrentVersion\Run` にアプリパスを登録。 + - **macOS**: Launch Agent（`~/Library/LaunchAgents/` に plist を配置）。 + - **Linux**: XDG Autostart（`~/.config/autostart/*.desktop` に .desktop ファイルを配置）。 + +```mermaid +flowchart TB + subgraph プラットフォーム別の実体 + W[Windows: レジストリ Run] + M[macOS: LaunchAgents] + L[Linux: autostart .desktop] + end + P[tauri-plugin-autostart] --> W + P --> M + P --> L + U[ユーザー: enable/disable] --> P +``` + +## 3.2 API（フロント／バック） + +- **enable()**: 自動起動を有効にする。 +- **disable()**: 自動起動を無効にする。 +- **isEnabled()**: 現在自動起動が有効かどうかを返す。 + +設定 UI のトグルや起動時の読み込みで上記を呼び出す。設定の永続化（localStorage や Tauri の app 設定）と連携し、「自動起動オン」のときだけプラグインの `enable()` を呼ぶ。 + +## 3.3 設定との連携 + +- 設定項目「ログイン時に自動起動する」を追加する（現状は [06 UI 仕様](../../specification/06_ui_design_spec.md) 上で非表示のため、本機能実装時に設定パネルに表示する）。 +- オンにした場合: 設定を保存し、`tauri-plugin-autostart` の `enable()` を実行。 +- オフにした場合: 設定を保存し、`disable()` を実行。 +- アプリ起動時: 保存済み設定を読み、`isEnabled()` と一致していなければ `enable()` / `disable()` で同期する（他ツールでレジストリ等をいじった場合のずれを吸収）。 + +```mermaid +stateDiagram-v2 + [*] --> 設定読み込み + 設定読み込み --> 同期: 設定値と isEnabled() が不一致 + 設定読み込み --> 待機: 一致 + 同期 --> enableまたはdisable + enableまたはdisable --> 待機 + 待機 --> ユーザーがトグル変更 + ユーザーがトグル変更 --> 保存してenable/disable + 保存してenable/disable --> 待機 +``` diff --git a/docs/plans/auto_start/auto_start_03_ui.md b/docs/plans/auto_start/auto_start_03_ui.md new file mode 100644 index 0000000..51e4086 --- /dev/null +++ b/docs/plans/auto_start/auto_start_03_ui.md @@ -0,0 +1,41 @@ +# 自動起動計画: 03 UI 改造 + +[計画トップ](auto_start.md) + +--- + +本機能を有効にするには、**設定 UI の変更**が必要である。現状 [06 UI 仕様](../../specification/06_ui_design_spec.md) では「ログイン時起動・フォルダモニタリングのパネルは UI に含めない」とされているため、自動起動用の項目を表示する改造を計画に含める。 + +## 4.1 設定パネルに追加する項目 + +| 項目 | 内容 | +|------|------| +| **表示するコントロール** | 「ログイン時に自動起動する」の **トグル（スイッチ）** 1 つ。 | +| **配置** | 設定パネル内。検索まわり（スコア足切り・取得件数）の上または下に、明確に区切って配置する。 | +| **ラベル** | 短く分かりやすい文言（例: 「ログイン時に自動起動する」）。必要なら補足テキスト（「OS にサインインしたときに TelosDB を起動します」）を小さく表示。 | +| **見た目** | 既存の [06 コンセプト](../../specification/06_ui_design_spec.md)（ハイコントラスト・ミニマリズム）に合わせる。装飾を抑え、トグルは既存の設定項目とスタイルを統一する。 | + +## 4.2 画面フロー + +```mermaid +flowchart LR + subgraph 設定パネル + A[設定ボタン] --> B[パネル開く] + B --> C[検索設定] + B --> D[ログイン時自動起動 トグル] + D --> E[ON: enable] + D --> F[OFF: disable] + end + E --> G[設定保存] + F --> G +``` + +## 4.3 仕様書の更新 + +- **06_ui_design_spec.md**: 「非表示: ログイン時起動・フォルダモニタリングのパネル」を、**自動起動については「表示する」** に変更する。フォルダモニタリングは別計画のため、当面は非表示のままでもよい。 +- **設定の永続化**: 自動起動のオン・オフは、既存の `telosdb_settings`（localStorage）に含めるか、別キーで保存するかを実装時に決める。いずれにしても「設定パネルを開いたとき・起動時に読み込み、トグルとプラグイン状態を一致させる」。 + +## 4.4 考慮事項 + +- **初回表示**: これまで非表示だった項目を出すため、設定パネルの高さやレイアウトが変わる。小さいウィンドウでもはみ出さないよう、スクロールや折りたたみを検討する。 +- **他計画との関係**: フォルダモニタリングもいずれ設定パネルに出す場合、同じ「起動・動作オプション」として自動起動と並べて配置する構成が分かりやすい。 diff --git a/docs/plans/auto_start/auto_start_04_phases.md b/docs/plans/auto_start/auto_start_04_phases.md new file mode 100644 index 0000000..cf4a476 --- /dev/null +++ b/docs/plans/auto_start/auto_start_04_phases.md @@ -0,0 +1,14 @@ +# 自動起動計画: 04 実装ステップ + +[計画トップ](auto_start.md) + +--- + +## 実装ステップ（案） + +| 段階 | 内容 | +|------|------| +| **Phase 1** | `tauri-plugin-autostart` を導入。Rust でプラグイン登録、フロントまたは Tauri コマンドから `enable` / `disable` / `isEnabled` を呼べるようにする。手動で有効化したときに OS ログイン後に実際に自動起動することを確認。 | +| **Phase 2** | 設定の永続化と連携。「ログイン時自動起動」のオン・オフを保存し、起動時に設定を読み込んでプラグインの状態と同期する。 | +| **Phase 3** | **UI 改造**（[03 UI 改造](auto_start_03_ui.md)）。設定パネルに「ログイン時に自動起動する」トグルを追加し、表示・トグル操作で enable/disable と設定保存を行う。06 仕様の「非表示」を自動起動分だけ「表示」に更新する。 | +| **Phase 4（任意）** | macOS / Linux ビルドで自動起動の動作確認。 | diff --git a/docs/plans/auto_start/auto_start_05_considerations.md b/docs/plans/auto_start/auto_start_05_considerations.md new file mode 100644 index 0000000..33930f9 --- /dev/null +++ b/docs/plans/auto_start/auto_start_05_considerations.md @@ -0,0 +1,11 @@ +# 自動起動計画: 05 注意事項・未決定 + +[計画トップ](auto_start.md) + +--- + +## 注意事項・未決定 + +- **トレイ起動**: 自動起動時にウィンドウを表示しない「トレイのみ」で起動するか、通常どおりウィンドウを出すか。仕様で決める。 +- **権限・ユーザー操作**: Windows では Run キーはユーザー単位。macOS の Launch Agent もユーザー単位。管理者権限は不要の想定。 +- **競合**: 既に別の方法（タスクスケジューラ等）で同じアプリをログイン時に起動している場合、二重起動にならないか確認する。プラグインは一般的な 1 エントリ追加なので、他で同じ実行ファイルを登録していなければ通常は 1 つだけ起動する。 diff --git a/docs/plans/auto_start/auto_start_06_references.md b/docs/plans/auto_start/auto_start_06_references.md new file mode 100644 index 0000000..23c784a --- /dev/null +++ b/docs/plans/auto_start/auto_start_06_references.md @@ -0,0 +1,11 @@ +# 自動起動計画: 06 参照 + +[計画トップ](auto_start.md) + +--- + +## 参照 + +- [tauri-plugin-autostart](https://github.com/tauri-apps/tauri-plugin-autostart) — 公式プラグイン +- [Tauri v2 Autostart プラグイン](https://v2.tauri.app/plugin/autostart/) +- 既存仕様: `docs/specification/06_ui_design_spec.md`（設定パネル・ログイン時起動の「非表示」記載） diff --git a/docs/plans/folder_monitor/folder_monitor.md b/docs/plans/folder_monitor/folder_monitor.md new file mode 100644 index 0000000..afa7699 --- /dev/null +++ b/docs/plans/folder_monitor/folder_monitor.md @@ -0,0 +1,28 @@ +# 計画: 指定フォルダ内のファイル追加・削除・更新を監視する仕組み + +## 1. 目的 + +ユーザーが指定したフォルダを監視し、以下のイベントを検知する仕組みを用意する。 + +- **ファイル追加**: フォルダ内に新規ファイルが作成されたとき +- **ファイル削除**: フォルダ内のファイルが削除されたとき +- **ファイル更新**: 既存ファイルの内容が変更されたとき + +検知した結果を TelosDB の文書取り込み（ドキュメント・チャンクの登録・更新・削除）に連携し、指定フォルダと DB の内容を同期させることを想定する。 + +**リリース目標**: **Windows 版の実装を v0.3.3 に含める**。Phase 1〜3（単一フォルダ監視・DB 連携・設定 UI・永続化）を Windows で実装し、0.3.3 で出荷する。macOS / Linux およびネットワークフォルダの検証・ポーリングフォールバックは Phase 5 として以降のバージョンに回す。 + +--- + +## 2. 検討事項別ドキュメント + +各検討事項は別ファイルに分割している。 + +| No. | 項目 | ファイル | 内容 | +|-----|------|----------|------| +| 01 | **スコープ** | [folder_monitor_01_scope.md](folder_monitor_01_scope.md) | 対応プラットフォーム、監視対象の種類・パス・深さ、対象ファイル、動作タイミング。 | +| 02 | **技術方針** | [folder_monitor_02_tech.md](folder_monitor_02_tech.md) | notify、デバウンス、ネットワーク・フォールバック、プラットフォーム別注意点、Config、既存機能連携、設定保存。 | +| 03 | **実装方針（OS・プロトコル別）** | [folder_monitor_03_os_protocol.md](folder_monitor_03_os_protocol.md) | OS × ファイルプロトコル別の Watcher 選択、判定、共通処理。 | +| 04 | **実装ステップ** | [folder_monitor_04_phases.md](folder_monitor_04_phases.md) | Phase 1〜5 の実装順序。 | +| 05 | **注意事項・未決定** | [folder_monitor_05_considerations.md](folder_monitor_05_considerations.md) | 権限、パス正規化、ネットワーク制約、大容量フォルダ、UI。 | +| 06 | **参照・調査元** | [folder_monitor_06_references.md](folder_monitor_06_references.md) | notify / debouncer / inotify / macOS 等の公式ドキュメント・リンク。 | diff --git a/docs/plans/folder_monitor/folder_monitor_01_scope.md b/docs/plans/folder_monitor/folder_monitor_01_scope.md new file mode 100644 index 0000000..17c5d7e --- /dev/null +++ b/docs/plans/folder_monitor/folder_monitor_01_scope.md @@ -0,0 +1,17 @@ +# フォルダ監視: 01 スコープ + +[計画トップ](folder_monitor.md) + +--- + +## スコープ + +| 項目 | 内容 | +|------|------| +| **対応プラットフォーム** | **Windows**（現行）、**macOS**、**Linux**。Tauri 2 の対応 OS に合わせて監視機能も各 OS で動作させる。 | +| **監視対象の種類** | **ローカルフォルダ**（各 OS の通常のパス）に加え、**ネットワークフォルダ**（SMB/CIFS・NFS 等でマウントされたパス）も対象とする。ネットワークパスは OS がマウント済みであれば、ローカルと同様に指定可能とする。 | +| **監視対象** | ユーザーが設定で指定する 1 つ以上のディレクトリパス（例: Windows `C:\Users\...\Documents\TelosDB-watch`、macOS `/Users/.../Documents/TelosDB-watch`、Linux `/home/.../Documents/TelosDB-watch`、ネットワーク `//server/share/watch` や `/mnt/nfs/watch` など）。 | +| **監視の深さ** | 指定フォルダ直下のみ / サブフォルダ再帰のいずれかを設定で選択可能とする（案）。 | +| **対象ファイル** | 拡張子でフィルタ（例: `.txt`, `.md`, `.json` など）。MIME 対応済みの形式を優先。 | +| **動作タイミング** | アプリ起動中の常時監視。設定で監視のオン・オフを切り替え可能とする。 | +| **MCP・API との関係** | **能動的なプッシュは不要**。監視で検出した変化は DB 取り込み・ベクトル化まで内部で完結する。MCP クライアント（Cursor 等）や HTTP API は従来どおり「検索」「件数取得」などで**現在の DB 状態を参照する（プル）**だけ。 | diff --git a/docs/plans/folder_monitor/folder_monitor_02_tech.md b/docs/plans/folder_monitor/folder_monitor_02_tech.md new file mode 100644 index 0000000..3dc591b --- /dev/null +++ b/docs/plans/folder_monitor/folder_monitor_02_tech.md @@ -0,0 +1,80 @@ +# フォルダ監視: 02 技術方針 + +[計画トップ](folder_monitor.md) + +--- + +## 3.0 設計: 監視プロトコルとドライバ + +**方針**: 監視の「やり方」を共通プロトコル（トレイト／インターフェース）で定義し、OS・ファイルシステム・ネットワーク種別ごとに**ドライバ**を用意する。 + +- **プロトコル（共通インターフェース）** + - 監視の開始・停止、イベントの購読など、呼び出し側が依存する操作だけを定義する。 + - 例: `watch(path, recursive)` → ハンドル、`EventStream` またはコールバックで `Create` / `Remove` / `Modify` を受け取る、`unwatch` / `stop`。 +- **ドライバ** + - 上記プロトコルを実装する。中身は [03 OS・プロトコル別](folder_monitor_03_os_protocol.md) のマトリクスに沿い、**ネイティブ監視**（RecommendedWatcher）か**ポーリング**（PollWatcher）のどちらか＋設定で表現する。 + - 実装の切り口は「OS×ネットワーク」の全組み合わせを個別クラスにする必要はなく、**バックエンド 2 種**で足りる: + - **ネイティブドライバ**: `notify::recommended_watcher()` ＋ デバウンス。中で OS 別 API（ReadDirectoryChangesW / FSEvents / inotify）は notify が担当。 + - **ポーリングドライバ**: `PollWatcher` ＋ `Config`（poll_interval, 必要なら compare_contents）。ネットワーク FS・WSL・擬似 FS 等で使用。 + - **ドライバ選択**（セレクタ）: パスと実行環境（OS・マウント情報など）から、上記どちらのドライバ（およびオプション）を使うかを決める。選択ロジックは [03](folder_monitor_03_os_protocol.md) の「プロトコル・ストレージ種別の判定」にまとめる。 +- **効果** + - 上位（DB 連携・設定 UI）はプロトコルだけに依存し、OS やネットワークの違いを意識しない。 + - 新たな環境（別 OS や新しいネットワーク FS）への対応は、セレクタの判定と必要なら新ドライバ（または既存ドライバの設定）の追加で済む。 + +--- + +## 3.1 監視ライブラリ: notify + +- **採用**: Rust の **`notify`** クレート（現行安定版 8.x、[crates.io](https://crates.io/crates/notify)、[docs.rs](https://docs.rs/notify/latest/notify/)）を採用する。クロスプラットフォームで同一 API が使え、各 OS のネイティブ API を利用する。 +- **バックエンド（プラットフォーム別）**: + - **Windows**: `ReadDirectoryChangesW` + - **macOS**: FSEvents（デフォルト）。feature `macos_kqueue` で kqueue に切り替え可能。 + - **Linux / Android**: inotify + - **BSD 系**: kqueue +- **推奨 Watcher**: `notify::recommended_watcher()` で、そのプラットフォームに最適な実装（`RecommendedWatcher`）を取得する。イベント駆動で CPU 負荷が低い。 +- **イベント種別**: `EventKind` の `Create`, `Remove`, `Modify` 等を区別して扱う。`RecursiveMode::Recursive` でサブディレクトリも監視可能。 + +## 3.2 デバウンス + +- **目的**: 同一ファイルへの短時間の連続変更（エディタの自動保存・一括書き換え等）を、1 回の「更新」にまとめる。 +- **手段**: **`notify-debouncer-mini`**（[docs.rs](https://docs.rs/notify-debouncer-mini/latest/notify_debouncer_mini/)）を利用する。`new_debouncer(Duration::from_secs(2), callback)` のように時間幅を指定し、その間のイベントを集約してコールバックに渡す。 +- **代替**: より高度な処理（Rename の追跡・重複 Create の除去等）が必要なら `notify-debouncer-full` を検討する。TelosDB では「追加・削除・更新」の 3 種で十分な場合は mini で足りる。 +- **注意**: debouncer-mini は内部でスレッドを使いブロッキング受信するため、Tauri の async ループからは `spawn_blocking` や専用スレッドでラップし、結果をチャンネルで async 側に渡す構成が無難。 + +## 3.3 ネットワークフォルダ・フォールバック + +- **公式の既知問題**（[notify Known Problems](https://docs.rs/notify/latest/notify/)）: + - **ネットワークマウント（NFS 等）**: 多くのネットワーク FS ではネイティブの変更通知が発火しない。WSL 上で Windows パスを監視する場合も同様（issue #254）。 + - **対処**: **`PollWatcher`** バックエンドを使う。`notify::Config::default().with_poll_interval(Duration::from_secs(30))` でポーリング間隔を指定し、`notify::WatcherKind::PollWatcher` で明示的に PollWatcher を生成する。デフォルトのポーリング間隔は 30 秒。大容量ツリーでは負荷が高いため、間隔の調整や「ネットワークパス用」の別ワッチャーとして扱う設計がよい。 +- **その他で PollWatcher が推奨されるケース**: Docker on macOS M1（Function not implemented）、`/proc` や `/sys` などの擬似 FS、macOS で「自分が所有していないファイル」を FSEvents で追う場合（[FileSystemEventSecurity](https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/FSEvents_ProgGuide/FileSystemEventSecurity/FileSystemEventSecurity.html)）。 +- **実装方針**: まずは `RecommendedWatcher` で監視を開始し、ネイティブ監視が失敗するか、ネットワークパスであることを検出した場合に、同じ設定オブジェクトで `PollWatcher` に切り替えるフォールバックを用意する。ネットワークパスかどうかは、パスがマウントポイントか、または `watch` 登録時のエラー種別で判断する。 + +## 3.4 プラットフォーム別の注意点 + +- **Linux: inotify の上限** + - `max_user_watches`（デフォルト 8192、カーネルによっては 1048576）を超えると「No space left on device」や「upper limit on inotify watches reached」が出る。再帰監視では「監視対象ディレクトリ内のファイル・フォルダ数」がそのまま watch 数に効く。 + - 対処: ユーザーに `sysctl fs.inotify.max_user_watches=524288` 等の増設を案内するか、監視対象が大きい場合は初めから **PollWatcher** を使う選択肢を設ける。PollWatcher は inotify の上限に縛られない。 +- **macOS: サンドボックス** + - サンドボックス環境では、監視できるパスが権限付与された範囲に限られる。[Accessing files from the macOS App Sandbox](https://developer.apple.com/documentation/security/accessing_files_from_the_macos_app_sandbox) に従い、必要なら `com.apple.security.temporary-exception.files.home-relative-path.read-only` 等の entitlement を検討する。Tauri アプリがサンドボックスを有効にする場合、ユーザーが「監視フォルダ」を選択したパスがその例外に含まれるようにする必要がある。 +- **エディタの保存挙動** + - 編集ツールによっては「上書き保存」で truncate して書き直すため、Notify では Remove + Create や複数回の Modify に見えることがある。デバウンスと「同一パスは最後のイベントで 1 回だけ再取り込み」とする方針で吸収する。 + +## 3.5 Config とオプション（notify） + +- **`Config::with_poll_interval(dur)`**: PollWatcher 用。再スキャン間隔（デフォルト 30 秒）。ツリーが大きい場合は 60 秒などに延ばす検討。 +- **`Config::with_compare_contents(true)`**: PollWatcher 用。変更検知を mtime ではなくファイル内容のハッシュで行う。`/proc` 等で有効。通常のローカル/ネットワークではオフでよい（パフォーマンス影響大）。 +- **`Config::with_follow_symlinks(bool)`**: シンボリックリンクをたどって監視するか。デフォルトは true。同一実体の二重登録を防ぐなら false にする選択肢がある。 + +## 3.6 既存機能との連携 + +- **方向**: 監視 → DB の**一方向**。検出イベントを内部の取り込みパイプラインに渡すだけでよく、MCP や HTTP API へ「新規追加しました」などを能動的に通知（プッシュ）する仕様は設けない。クライアントは必要時に `search_text` や `get_document_count` 等で現在状態を取得すれば足りる（[01 スコープ](folder_monitor_01_scope.md#スコープ)）。 +- **追加**: 新規ファイル検知 → 既存の文書取り込みパイプライン（チャンク分割・ベクトル化・`documents` / `items` / `vec_items` / FTS 登録）を呼び出す。 +- **更新**: 変更検知 → 当該パスに紐づく既存ドキュメントを更新（再取り込み）する。 +- **削除**: 削除検知 → 当該パスに紐づくドキュメントを `documents` から削除（関連 `items` / `vec_items` / FTS も連動削除）。 +- **親フォルダ削除**: notify の仕様上、`/a/b/` 以下の削除イベントを受け取るには親 `/a` を watch する必要がある。再帰監視では通常その前提が満たされるが、直下のみ監視する場合は注意する（[notify ドキュメント](https://docs.rs/notify/latest/notify/)）。 + +## 3.7 設定の保存 + +- 監視対象フォルダパス・再帰の有無・対象拡張子・監視オン/オフは、アプリの設定（Windows は `%APPDATA%\com.telosdb.app\`、macOS/Linux は各 OS のアプリ設定ディレクトリ、または既存の localStorage と連携する API）に永続化する。 +- 設定変更時に、監視ワッチャーを再起動（購読パスの付け替え）する。 +- **パス表記**: プラットフォームごとのパス形式（Windows の `C:\`、macOS/Linux の `/`、ネットワークの `//` や `/mnt/` 等）をそのまま保存し、実行環境に応じて正しく解釈する。 diff --git a/docs/plans/folder_monitor/folder_monitor_03_os_protocol.md b/docs/plans/folder_monitor/folder_monitor_03_os_protocol.md new file mode 100644 index 0000000..c4127ea --- /dev/null +++ b/docs/plans/folder_monitor/folder_monitor_03_os_protocol.md @@ -0,0 +1,58 @@ +# フォルダ監視: 03 実装方針（OS タイプ・ファイルプロトコル別） + +[計画トップ](folder_monitor.md) + +--- + +監視対象を **OS** と **ファイルプロトコル（ストレージ種別）** の組み合わせで分類し、それぞれの実装方針を定める。共通の[監視プロトコルとドライバ設計](folder_monitor_02_tech.md#30-設計-監視プロトコルとドライバ)は [02 技術方針](folder_monitor_02_tech.md) に記載。本ドキュメントは「どの組み合わせでどのドライバ（ネイティブ or ポーリング）を使うか」のマトリクスと判定方針。 + +## 4.1 マトリクス概要 + +| OS | ローカル FS | SMB/CIFS（ネットワーク共有） | NFS | その他（擬似 FS・WSL 等） | +|----|-------------|------------------------------|-----|---------------------------| +| **Windows** | RecommendedWatcher（ReadDirectoryChangesW） | 要検証。失敗時は PollWatcher。 | 同上。 | WSL で Windows パス監視は PollWatcher。 | +| **macOS** | RecommendedWatcher（FSEvents）。非所有ファイルは PollWatcher。 | PollWatcher 推奨。 | PollWatcher 推奨。 | Docker M1 等は PollWatcher。 | +| **Linux** | RecommendedWatcher（inotify）。watch 数上限に注意。 | PollWatcher 推奨。 | PollWatcher 推奨。 | /proc, /sys は PollWatcher（compare_contents 検討）。 | + +## 4.2 OS タイプ別 + +### Windows + +| プロトコル・種別 | 実装方針 | 備考 | +|------------------|----------|------| +| **ローカル** | `RecommendedWatcher`（ReadDirectoryChangesW）。デバウンスは `notify-debouncer-mini`。 | ネイティブで安定。パスは `C:\` 等。 | +| **SMB/CIFS** | まず `RecommendedWatcher` で `watch`。失敗またはイベントが来ない場合は **PollWatcher** に切り替え。`with_poll_interval(Duration::from_secs(30))` 等。 | `\\server\share\...` や マッピンドライブ（`Z:\`）はネットワーク経路のため、多くの環境でネイティブ通知が発火しない。 | +| **NFS** | 同上。ネイティブが効かない前提で **PollWatcher** を優先してもよい。 | マウント済み NFS パスを指定された場合。 | +| **WSL 内で Windows パス** | **PollWatcher** を最初から使用。 | notify の既知問題（issue #254）。 | + +### macOS + +| プロトコル・種別 | 実装方針 | 備考 | +|------------------|----------|------| +| **ローカル** | `RecommendedWatcher`（FSEvents）。「自分が所有していないファイル」のみ監視する場合は **PollWatcher** にフォールバック。 | サンドボックス利用時は entitlement で監視パスを許可。 | +| **SMB/CIFS（マウント済み）** | **PollWatcher** を推奨。ネイティブは多くの場合発火しない。 | `/Volumes/ShareName` 等。 | +| **NFS** | **PollWatcher** を推奨。 | 同上。 | +| **Docker on M1 等** | **PollWatcher**。ネイティブは "Function not implemented" になる。 | コンテナ内で監視する場合。 | + +### Linux + +| プロトコル・種別 | 実装方針 | 備考 | +|------------------|----------|------| +| **ローカル** | `RecommendedWatcher`（inotify）。再帰監視時は **watch 数** が `max_user_watches` を超えないよう注意。超過時は PollWatcher に切り替えまたはユーザーに sysctl 案内。 | デフォルト 8192。大容量ツリーは PollWatcher の選択肢を用意。 | +| **SMB/CIFS（cifs-utils 等でマウント）** | **PollWatcher** を推奨。inotify は多くのネットワーク FS で効かない。 | `/mnt/smb/...` 等。 | +| **NFS** | **PollWatcher** を推奨。 | `/mnt/nfs/...` 等。 | +| **擬似 FS（/proc, /sys）** | **PollWatcher**。必要なら `with_compare_contents(true)` を検討（mtime が信用できないため）。 | 通常の文書監視では対象にしなくてよい。 | + +## 4.3 プロトコル・ストレージ種別の判定 + +- **ローカルかネットワークか**の判定は、実装時に次のいずれかで行う想定とする。 + - **パス prefix で推定**: Windows の `\\\\`（UNC）、Linux の `/mnt/` や `/media/` の下、macOS の `/Volumes/` の一部など。 + - **watch 登録結果**: `RecommendedWatcher` で `watch()` した直後や、一定時間イベントが来ない場合に「ネイティブが使えない」とみなし、PollWatcher に切り替える。 + - **OS のマウント情報**: 各 OS の API（例: Linux の `/proc/mounts`、macOS の `getfsstat`）でマウントポイント一覧を取得し、監視パスがネットワーク FS 上かどうかを判定する（任意の拡張）。 +- 判定結果に応じて **Watcher 種別**（RecommendedWatcher または PollWatcher）と **Config**（poll_interval の有無など）を決め、同一の「監視エンジン」インターフェースで扱う。 + +## 4.4 共通処理 + +- 上記どの組み合わせでも、**デバウンス**は `notify-debouncer-mini` で統一する（PollWatcher は元から間隔が空くため、デバウンス時間は 2〜5 秒程度でよい）。 +- **イベントの解釈**（Create → 追加、Modify → 更新、Remove → 削除）と **DB 連携**は、OS・プロトコルに依存せず共通ロジックとする。 +- **設定の保存**・**パス表記**は [02 技術方針 3.7](folder_monitor_02_tech.md#37-設定の保存) のとおり。プロトコル別の特別な設定項目（例: 「ネットワークパス用ポーリング間隔」）は必要に応じて追加する。 diff --git a/docs/plans/folder_monitor/folder_monitor_04_phases.md b/docs/plans/folder_monitor/folder_monitor_04_phases.md new file mode 100644 index 0000000..1b46424 --- /dev/null +++ b/docs/plans/folder_monitor/folder_monitor_04_phases.md @@ -0,0 +1,17 @@ +# フォルダ監視: 04 実装ステップ + +[計画トップ](folder_monitor.md) + +--- + +## 実装ステップ（案） + +| 段階 | 内容 | v0.3.3（Windows） | +|------|------|-------------------| +| **Phase 1** | 単一フォルダの監視のみ。`notify` で Create/Remove/Modify を検知し、ログ出力またはイベント送信まで。DB 連携は行わない。 | ✅ 含める | +| **Phase 2** | 検知イベントと既存の文書取り込み（MCP 経由または内部 API）を接続。追加・更新・削除それぞれのハンドラを実装。 | ✅ 含める | +| **Phase 3** | 設定 UI（監視フォルダパス・オン/オフ・対象拡張子）の追加と、設定の永続化・ワッチャー再起動。 | ✅ 含める | +| **Phase 4** | 複数フォルダ対応・再帰監視オプション・デバウンス時間の調整など、運用面の拡張。 | 以降 | +| **Phase 5（任意）** | macOS / Linux ビルドでの動作確認と、ネットワークフォルダ監視の検証。ネイティブ通知が使えない場合のポーリングフォールバック実装。[03 OS・プロトコル別方針](folder_monitor_03_os_protocol.md)のマトリクスに沿った Watcher 切り替えの実装。 | 以降 | + +**v0.3.3 の範囲**: Windows 上で Phase 1〜3 までを実装・出荷する。ローカルフォルダを RecommendedWatcher（ReadDirectoryChangesW）で監視し、設定 UI と DB 連携まで含める。 diff --git a/docs/plans/folder_monitor/folder_monitor_05_considerations.md b/docs/plans/folder_monitor/folder_monitor_05_considerations.md new file mode 100644 index 0000000..b664578 --- /dev/null +++ b/docs/plans/folder_monitor/folder_monitor_05_considerations.md @@ -0,0 +1,13 @@ +# フォルダ監視: 05 注意事項・未決定 + +[計画トップ](folder_monitor.md) + +--- + +## 注意事項・未決定 + +- **権限**: 監視対象フォルダへの読み取り権限が無い場合のエラー表示と、設定画面での再指定を促す動線。ネットワークフォルダでは、マウント時やログオン時の認証・再接続が必要な場合がある。 +- **パス正規化**: Windows の短いパス・ジャンクション・シンボリックリンク、macOS/Linux のシンボリックリンク・バインドマウントの扱いをどうするか（同一ファイルの二重登録を防ぐ）。ネットワークパスは OS ごとのマウントポイントの違い（例: Windows `\\server\share`、Linux `/mnt/smb/share`）を考慮する。 +- **ネットワークフォルダの制約**: 一部のネットワーク FS は inotify/FSEvents/ReadDirectoryChangesW をサポートしない。その場合はポーリング間隔の設定や「ネットワークパスでは監視が限定的」である旨の UI 表示を検討する。 +- **大容量フォルダ**: 監視開始時に既存ファイルを一括スキャンするか、監視開始後の変更のみ扱うか。既存ファイルの初回同期は別機能（「フォルダをインポート」）に任せる案もある。 +- **UI の扱い**: 現状、設定画面の「モニター先フォルダ」は非表示。本機能を有効にする際に、当該パネルを再度表示するか、別タブ・別画面にするか。 diff --git a/docs/plans/folder_monitor/folder_monitor_06_references.md b/docs/plans/folder_monitor/folder_monitor_06_references.md new file mode 100644 index 0000000..afa1b84 --- /dev/null +++ b/docs/plans/folder_monitor/folder_monitor_06_references.md @@ -0,0 +1,16 @@ +# フォルダ監視: 06 参照・調査元 + +[計画トップ](folder_monitor.md) + +--- + +## 参照・調査元 + +- **notify**: [notify 8.2.0 - docs.rs](https://docs.rs/notify/latest/notify/)、[Known Problems](https://docs.rs/notify/latest/notify/#known-problems)（ネットワーク FS、Docker M1、macOS 非所有ファイル、Linux 上限、エディタ挙動、親フォルダ削除）。 +- **notify Config**: [Config - docs.rs](https://docs.rs/notify/latest/notify/struct.Config.html)（poll_interval, compare_contents, follow_symlinks）。 +- **notify-debouncer-mini**: [notify-debouncer-mini - docs.rs](https://docs.rs/notify-debouncer-mini/latest/notify_debouncer_mini/)。 +- **Linux inotify**: [Watchexec - inotify limits](https://watchexec.github.io/docs/inotify-limits.html)、`max_user_watches` / `max_user_instances` の意味と増やし方。 +- **macOS**: [File System Event Security](https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/FSEvents_ProgGuide/FileSystemEventSecurity/FileSystemEventSecurity.html)、[Accessing files from the macOS App Sandbox](https://developer.apple.com/documentation/security/accessing_files_from_the_macos_app_sandbox)。 +- 既存の文書取り込み: MCP ツール `add_item_text`、ドキュメント登録のフロー（`documents` / `items` の作成）。 +- データベース仕様: `docs/specification/03_database_specification.md`。 +- 設定の永続化: 現状の検索設定（localStorage）との棲み分け。 diff --git a/docs/plans/lda/lda.md b/docs/plans/lda/lda.md new file mode 100644 index 0000000..58a5782 --- /dev/null +++ b/docs/plans/lda/lda.md @@ -0,0 +1,40 @@ +# 計画: LDA（潜在的ディリクレ配分）の扱い + +## 1. 目的と背景 + +**LSA と LDA はコミュニティ版専用**の実装とする。Pro 版は埋め込みモデルのみでベクトル化し、LSA/LDA のコードは含めない。 + +現在の Community 版は **LSA（Latent Semantic Analysis）** のみで文書チャンクをベクトル化している。ここに **LDA（Latent Dirichlet Allocation）** を追加し、**LSA と LDA を切り替えて使える**ようにする。設定で「ベクトル化: LSA」か「ベクトル化: LDA」を選び、選択した方だけを学習・検索に用いる。LDA のトピック数 K は**規定 128 次元**とし、ユーザー指定で再構成可能とする。 + +**リリース目標**: **v0.3.3 の Community 版**で LDA 対応を実装・出荷する。Pro 版は従来どおり埋め込みのみ。 + +```mermaid +flowchart LR + subgraph 現状 + A1[文書・チャンク] --> B1[TF-IDF] + B1 --> C1[LSA / SVD] + C1 --> D1[50次元ベクトル] + D1 --> E1[検索] + end + subgraph 追加したい + A2[文書・チャンク] --> B2[語彙・カウント] + B2 --> C2[LDA] + C2 --> D2[トピック分布 128次元 規定] + D2 --> E2[検索 or トピック表示] + end +``` + +--- + +## 2. 検討事項別ドキュメント + +各検討事項は別ファイルに分割している。 + +| No. | 項目 | ファイル | 内容 | +|-----|------|----------|------| +| 01 | **スコープ** | [lda_01_scope.md](lda_01_scope.md) | 対象エディション、役割、LSA/LDA 切り替え、LDA 次元数（規定 128・ユーザー再構成）。 | +| 02 | **技術方針** | [lda_02_tech.md](lda_02_tech.md) | LDA の性質、Rust 実装候補、ストレージ（items_lda）。 | +| 03 | **UI 改造** | [lda_03_ui.md](lda_03_ui.md) | 設定パネルにベクトル化切り替え・LDA 次元数 K・再構成の追加。 | +| 04 | **実装ステップ** | [lda_04_phases.md](lda_04_phases.md) | Phase 1〜5 の実装順序。v0.3.3 に含める範囲。 | +| 05 | **注意事項・未決定** | [lda_05_considerations.md](lda_05_considerations.md) | K の範囲、学習コスト、切り替え時再学習、Pro 版方針。 | +| 06 | **参照** | [lda_06_references.md](lda_06_references.md) | LDA 論文、Rust クレート、既存コード参照。 | diff --git a/docs/plans/lda/lda_01_scope.md b/docs/plans/lda/lda_01_scope.md new file mode 100644 index 0000000..a166435 --- /dev/null +++ b/docs/plans/lda/lda_01_scope.md @@ -0,0 +1,30 @@ +# LDA 計画: 01 スコープ + +[計画トップ](lda.md) + +--- + +## スコープ + +| 項目 | 内容 | +|------|------| +| **対象エディション** | **Community 版のみ**。LSA と LDA の両方とも Community 版専用であり、Pro 版には含めない（Pro は埋め込みモデルのみ）。 | +| **リリース目標** | **v0.3.3 の Community 版**で LDA 対応を実装・出荷する。 | +| **役割** | LSA と同様に「ベクトル化の一方式」として扱う。トピック分布を K 次元ベクトルとみなし、検索時はクエリのトピック分布とチャンクのトピック分布の類似度（例: コサイン）でランキングする。必要に応じて「トピック一覧」「この文書の主トピック」表示なども検討する。 | +| **切り替え** | 設定で **「LSA」と「LDA」を切り替えて使用**する。いずれか一方を選択し、その方式で学習・検索を行う。同時に両方は動かさない（ハイブリッドは将来の拡張として検討可）。 | +| **語彙・前処理** | LSA と同じ日本語トークナイザ・語彙を使い、学習コーパスも同じ（全チャンク）とする。 | +| **LDA 次元数（K）** | **規定は 128 次元**。設定でユーザーが K を指定でき、変更時は再学習・再構成して items_lda をその K で作り直す。 | + +```mermaid +flowchart TB + subgraph Community["Community 版のみ（v0.3.3）"] + S[ベクトル化: LSA / LDA 切り替え] + S --> LSA[LSA 学習・検索] + S --> LDA[LDA 学習・検索] + LSA --> R[検索結果] + LDA --> R + end + subgraph Pro["Pro 版"] + E[埋め込みモデルのみ] + end +``` diff --git a/docs/plans/lda/lda_02_tech.md b/docs/plans/lda/lda_02_tech.md new file mode 100644 index 0000000..d83e582 --- /dev/null +++ b/docs/plans/lda/lda_02_tech.md @@ -0,0 +1,41 @@ +# LDA 計画: 02 技術方針 + +[計画トップ](lda.md) + +--- + +## 3.1 LDA の性質 + +- **入力**: 文書ごとの語の出現回数（Bag of Words）。LSA で使っている TF-IDF 行列の「TF 部分」や、二値/カウント行列を LDA 用に用意する。 +- **出力**: + - 文書-トピック分布 θ（文書数 × K）。**K の規定値は 128**。ユーザー指定で変更可能で、変更時は再学習・再構成する。 + - トピック-語分布 φ（K × 語彙数） +- **推論**: 新規クエリ文を「既存の φ で固定」してトピック分布だけ推定し、その分布と各チャンクの θ で類似度を計算する。 + +## 3.2 Rust 実装の候補 + +- **latentdirichletallocation**（[crates.io](https://crates.io/crates/latentdirichletallocation)）: 純粋な LDA。学習・推論の API を確認し、語彙を LSA と揃えられるか検討する。 +- **自前実装**: Collapsed Gibbs Sampling や Variational Bayes を ndarray で実装。既存の `utils::lsa` と同様に `utils::lda` を用意する案。 +- いずれにしても **語彙は LSA の TermDocumentMatrixBuilder と共通化**し、LDA 用の BoW 行列を同じ語彙で作る。 + +## 3.3 ストレージ + +- **items_lda**: チャンク ID と K 次元のトピック分布（blob または vec0 の 1 行）を保存。**K の規定値は 128**。ユーザーが K を変更したら再学習し、items_lda を新しい K で再構成する。 +- 検索時は **現在の設定が「LSA」なら items_lsa / vec_items（LSA）、「LDA」なら items_lda** を参照する。切り替え時は選択中の方式のインデックスのみを使う。 + +```mermaid +flowchart TB + subgraph 学習 + M[全チャンク BoW] --> LDA[LDA 学習] + LDA --> phi[φ: トピック×語] + LDA --> theta[θ: 文書×トピック] + theta --> DB[(items_lda)] + end + subgraph 検索 + Q[クエリ文] --> Qbow[BoW] + Qbow --> inf[θ_q 推定 φ 固定] + inf --> sim[コサイン類似度] + DB --> sim + sim --> rank[ランキング] + end +``` diff --git a/docs/plans/lda/lda_03_ui.md b/docs/plans/lda/lda_03_ui.md new file mode 100644 index 0000000..7cc46a7 --- /dev/null +++ b/docs/plans/lda/lda_03_ui.md @@ -0,0 +1,41 @@ +# LDA 計画: 03 UI 改造 + +[計画トップ](lda.md) + +--- + +LDA を「切り替えて使う」「規定 128 次元・ユーザー指定で再構成」するため、**設定 UI の改造**を計画に含める。既存の [06 UI 仕様](../../specification/06_ui_design_spec.md)（ハイコントラスト・ミニマリズム）に合わせる。 + +## 3.1 設定パネルに追加する項目 + +| 項目 | 内容 | +|------|------| +| **ベクトル化の選択** | **LSA** と **LDA** の**単一選択**（ラジオまたはドロップダウン）。選択した方式で学習・検索を行う。Community 版の設定パネルに表示する。 | +| **LDA 次元数（K）** | LDA 選択時のみ表示。**規定値 128**。数値入力またはスライダーでユーザーが K を指定可能。許容範囲（例: 16〜512）は実装時に決め、範囲外はバリデーションで弾く。 | +| **再構成** | K を変更したあと、または「LDA で再構築したい」ときに実行する**再構成ボタン**（例: 「LDA を再構築」）。押下で LDA の再学習と items_lda の再構築を開始し、進捗を表示する。既存の RE-INDEX（lsa_retrain）と同様にバックグラウンド実行＋SSE で状態通知を検討する。 | +| **表示条件** | これらは **Community 版のときのみ**表示する。Pro 版では「ベクトル化」は埋め込み固定のため、LSA/LDA の選択・K の設定は出さない。 | + +## 3.2 画面フロー + +```mermaid +flowchart TB + subgraph 設定パネル_Community + A[設定を開く] --> B[ベクトル化: LSA / LDA] + B --> C{LDA 選択?} + C -->|Yes| D[LDA 次元数 K 表示] + D --> E[K 入力 規定 128] + E --> F[再構成ボタン] + F --> G[再学習・items_lda 再構築] + C -->|No| H[LSA のまま] + end +``` + +## 3.3 設定の永続化 + +- **ベクトル化方式**（LSA / LDA）と **LDA の K** は、既存の `telosdb_settings`（localStorage）に含めるか、別キーで保存する。起動時に読み込み、検索・再学習で参照する。 +- K を変更して保存しただけでは即座に再構成は走らせず、「再構成」を実行したタイミングで items_lda を更新する設計とする（任意で「K 変更時に確認ダイアログで再構成を促す」も可）。 + +## 3.4 仕様書の更新 + +- **06_ui_design_spec.md**: Community 版の設定パネルに「ベクトル化（LSA / LDA）」および「LDA 次元数 K」「再構成」を追加する旨を追記する。 +- **ステータス表示**: ヘッダーやステータスで「LSA インデックス構築の状態」と同様に、「LDA 選択時は LDA インデックス構築の状態」を表示するか検討する。 diff --git a/docs/plans/lda/lda_04_phases.md b/docs/plans/lda/lda_04_phases.md new file mode 100644 index 0000000..010e847 --- /dev/null +++ b/docs/plans/lda/lda_04_phases.md @@ -0,0 +1,17 @@ +# LDA 計画: 04 実装ステップ + +[計画トップ](lda.md) + +--- + +## 実装ステップ（案） + +| 段階 | 内容 | v0.3.3 Community | +|------|------|-------------------| +| **Phase 1** | LDA 学習・推論のモジュールを用意する。既存語彙（LSA と共通）で BoW を組み、LDA を学習して θ・φ を取得。クエリの θ 推定と、θ 同士の類似度計算まで。DB は触らない。 | ✅ 含める | +| **Phase 2** | `items_lda` テーブルを追加し、学習後の θ を保存。起動時・再学習時の同期（heal / retrain）で LDA ベクトルを更新する。 | ✅ 含める | +| **Phase 3** | 検索パスで「LSA / LDA の切り替え」を反映。設定が LSA なら既存の LSA 検索、LDA なら items_lda とクエリ θ で類似度検索。再学習（retrain）も選択中の方式のみ実行する。 | ✅ 含める | +| **Phase 4** | **UI 改造**（[03 UI 改造](lda_03_ui.md)）。設定パネルに「ベクトル化: LSA / LDA」の単一選択、LDA 時のトピック数 K（規定 128、ユーザー指定可）、再構成ボタン。K 変更時の再構成実行。設定の永続化。 | ✅ 含める | +| **Phase 5（任意）** | トピックラベル表示（各トピックの代表語から φ で取得）、文書の主トピック表示。 | 以降 | + +**v0.3.3 の範囲**: Community 版で Phase 1〜4 までを実装する。LSA と LDA の切り替え、規定 128 次元・ユーザー指定での再構成、およびそれに必要な UI 改造を含める。 diff --git a/docs/plans/lda/lda_05_considerations.md b/docs/plans/lda/lda_05_considerations.md new file mode 100644 index 0000000..639ab13 --- /dev/null +++ b/docs/plans/lda/lda_05_considerations.md @@ -0,0 +1,12 @@ +# LDA 計画: 05 注意事項・未決定 + +[計画トップ](lda.md) + +--- + +## 注意事項・未決定 + +- **トピック数 K**: **規定は 128 次元**。ユーザーが設定で K を変更した場合は、再学習（retrain）で LDA モデルと items_lda を新しい K で再構成する。K の許容範囲（例: 16〜512）は実装時に決める。 +- **学習コスト**: LDA は反復計算（Gibbs や VB）のため、文書数が多いと LSA より重い。バックグラウンド実行・進捗表示が必要。[03 UI 改造](lda_03_ui.md)の再構成ボタン押下時や起動時の LDA 学習で、SSE 等で状態を通知する。 +- **切り替え時の再学習**: LSA → LDA に切り替えたときは LDA を学習し、LDA → LSA に切り替えたときは LSA を再学習する。両方のインデックスを事前に持っておくか、選択時のみ必要側を学習するかは実装で決める。 +- **Pro 版**: LSA・LDA は **Community 専用**とする。Pro では埋め込みモデルのみでベクトル化し、LSA/LDA のビルド・実行パスは含めない。設定 UI でも LSA/LDA の項目は Pro 版では表示しない。 diff --git a/docs/plans/lda/lda_06_references.md b/docs/plans/lda/lda_06_references.md new file mode 100644 index 0000000..677fd12 --- /dev/null +++ b/docs/plans/lda/lda_06_references.md @@ -0,0 +1,12 @@ +# LDA 計画: 06 参照 + +[計画トップ](lda.md) + +--- + +## 参照 + +- LDA: [Latent Dirichlet Allocation (Blei et al.)](https://www.jmlr.org/papers/volume3/blei03a/blei03a.pdf) +- Rust: [latentdirichletallocation - crates.io](https://crates.io/crates/latentdirichletallocation) +- 既存: `src/backend/src/utils/lsa.rs`（語彙・TF-IDF・SVD）、`docs/specification/03_database_specification.md`（items_lsa, vec_items） +- UI: `docs/specification/06_ui_design_spec.md`（設定パネル・コンセプト） diff --git a/docs/specification/04_mcp_api_specification.md b/docs/specification/04_mcp_api_specification.md index 0bff3cd..2895710 100644 --- a/docs/specification/04_mcp_api_specification.md +++ b/docs/specification/04_mcp_api_specification.md @@ -36,7 +36,7 @@ | メソッド | パス | 説明 | |----------|------|------| | GET | `/edition` | 起動中エディション（`community` / `pro`）。 | -| GET | `/version` | アプリバージョン（例: `{"version":"0.3.2"}`）。 | +| GET | `/version` | アプリバージョン（例: `{"version":"0.3.3"}`）。 | | GET | `/heal` | FTS 同期実行。`{"synced": n}`。 | | GET | `/model_name` | Pro 時は埋め込みモデル名等。 | diff --git "a/journals/202603-011-\350\250\210\347\224\273\346\225\264\345\202\231\343\203\2730.3.3\343\203\273LDA\343\203\273\350\207\252\345\213\225\350\265\267\345\213\225\345\210\206\345\211\262.md" "b/journals/202603-011-\350\250\210\347\224\273\346\225\264\345\202\231\343\203\2730.3.3\343\203\273LDA\343\203\273\350\207\252\345\213\225\350\265\267\345\213\225\345\210\206\345\211\262.md" new file mode 100644 index 0000000..2cec667 --- /dev/null +++ "b/journals/202603-011-\350\250\210\347\224\273\346\225\264\345\202\231\343\203\2730.3.3\343\203\273LDA\343\203\273\350\207\252\345\213\225\350\265\267\345\213\225\345\210\206\345\211\262.md" @@ -0,0 +1,31 @@ +# 2026年 計画整備・バージョン0.3.3・LDA・自動起動計画の分割 + +## サマリー + +- **バージョン**: 0.3.2 → **0.3.3** に更新（README、package.json、Cargo.toml、tauri.conf.json、04_mcp_api_specification、package-lock.json）。 +- **計画ドキュメント**: `docs/plans/` を計画ごとにサブフォルダ化し、フォルダ監視・自動起動・LDA の各計画を検討事項別に番号付きファイルへ分割。 +- **フォルダ監視**: `folder_monitor/` に 01 スコープ〜06 参照を分割。**v0.3.3 Windows 版**で Phase 1〜3（単一フォルダ監視・DB 連携・設定 UI）を実装する目標を明記。 +- **自動起動**: ログイン時自動起動の計画を `auto_start/` に作成し、01 スコープ〜06 参照に分割。tauri-plugin-autostart、設定連携、UI 改造（トグル表示）を含む。 +- **LDA**: LSA と LDA を切り替えて使う計画を `lda/` に作成。**Community 版専用**、規定 128 次元・ユーザー指定で再構成、**v0.3.3 Community 版**で実装する目標。01 スコープ〜06 参照に分割し、**03 UI 改造**で設定パネル（ベクトル化 LSA/LDA、LDA 次元数 K、再構成ボタン）を記載。 +- **ルール**: `.cursor/rules/markdown-mermaid.mdc` を追加。Markdown 作成時に必要に応じて Mermaid 図を入れるようルール化。 +- **docs/README.md**: plans の構成説明を更新（各計画のサブフォルダ・分割方針を記載）。 + +--- + +## 主な変更ファイル + +| 種別 | パス | +|------|------| +| バージョン | README.md, package.json, package-lock.json, src/backend/Cargo.toml, src/backend/tauri.conf.json, docs/specification/04_mcp_api_specification.md | +| 計画トップ・目次 | docs/plans/folder_monitor/folder_monitor.md, docs/plans/auto_start/auto_start.md, docs/plans/lda/lda.md | +| 計画 01〜06 | docs/plans/**/***_01_scope.md 〜 **_06_references.md（各計画） | +| ルール | .cursor/rules/markdown-mermaid.mdc | +| ドキュメント索引 | docs/README.md | + +--- + +## 計画の構成（現時点） + +- **plans/auto_start/** — ログイン時自動起動。検討事項別 01〜06。 +- **plans/folder_monitor/** — 指定フォルダ監視。v0.3.3 Windows で Phase 1〜3。01〜06。 +- **plans/lda/** — LDA 対応。v0.3.3 Community、規定 128 次元・UI 改造含む。01〜06。 diff --git a/package-lock.json b/package-lock.json index 2228110..d0fac35 100644 --- a/package-lock.json +++ b/package-lock.json @@ -1,12 +1,12 @@ { "name": "telos-db", - "version": "0.3.2", + "version": "0.3.3", "lockfileVersion": 3, "requires": true, "packages": { "": { "name": "telos-db", - "version": "0.3.2", + "version": "0.3.3", "dependencies": { "@modelcontextprotocol/sdk": "^1.26.0", "@tauri-apps/api": "^2.10.1", diff --git a/package.json b/package.json index 708efd1..6ea22d4 100644 --- a/package.json +++ b/package.json @@ -1,7 +1,7 @@ { "name": "telos-db", "private": true, - "version": "0.3.2", + "version": "0.3.3", "type": "module", "scripts": { "tauri": "tauri", diff --git a/src/backend/Cargo.toml b/src/backend/Cargo.toml index 45c02d7..5396f8c 100644 --- a/src/backend/Cargo.toml +++ b/src/backend/Cargo.toml @@ -1,7 +1,7 @@ [package] name = "app" -version = "0.3.2" +version = "0.3.3" description = "A Tauri App" authors = ["you"] license = "" diff --git a/src/backend/tauri.conf.json b/src/backend/tauri.conf.json index f78a3dc..869b83f 100644 --- a/src/backend/tauri.conf.json +++ b/src/backend/tauri.conf.json @@ -1,7 +1,7 @@ { "$schema": "../../node_modules/@tauri-apps/cli/config.schema.json", "productName": "TelosDB", - "version": "0.3.2", + "version": "0.3.3", "identifier": "com.telosdb.app", "build": { "frontendDist": "../frontend",