# アーキテクチャ設計仕様書 (Architecture Design Specification)

## 1. 全体構造図

本システムは、OS のシステムトレイに常駐する「ホストプロセス（Tauri 2）」の中で、GUI、外部エージェントとの通信（MCP）、および数学的な文書解析（LSA）をすべて完結させる、シングルプロセス・マルチスレッド構造です。

```mermaid
graph TD
    subgraph "Presentation Layer (Webview2)"
        UI["Minimalist Dark UI (Vanilla JS)"]
        SSE_Monitor["Activity Log View (SSE)"]
    end

    subgraph "Application Layer (Rust / Tauri 2)"
        Tauri["Tauri Core (Main Process)"]
        Tray["System Tray Controller"]
        Axum["Axum (MCP SSE Server - Port 3001)"]
        LSA["LSA Engine (ndarray/SVD)"]
    end

    subgraph "Infrastructure Layer"
        DB["SQLite + sqlite-vec (telos.db)"]
    end

    UI -- "IPC: Invoke" --> Tauri
    Tauri -- "IPC: UI Update" --> UI
    Axum -- "SSE: Status Events" --> UI
    Tauri -- "LSA Analysis" --> LSA
    LSA -- "Vectors" --> DB
    Tauri -- "SQL" --> DB
    Axum -- "SQL" --> DB
```

## 2. プロセス間通信とデータフロー

### 2.1 Tauri Core と Axum (MCP) の連携

本システムの最大の特徴は、デスクトップアプリとしての GUI 管理を Tauri が行い、外部通信インターフェース（MCP）を Axum が担当する「デュアルサーバ」構成にあります。
両者はメモリを共有していますが、非同期なデータ操作通知（例：エージェントが MCP 経由でデータを登録した際に UI の件数を増やす）には **Tokio Broadcast Channel** を使用し、疎結合な連携を実現しています。

### 2.2 ベクトル解析 (LSA Engine)

Embedding 計算は外部の `llama-server` に依存せず、Rust バックエンド内で `ndarray` を用いた特異値分解（SVD）により直接行われます。

- **処理フロー**: テキスト入力に対し、分かち書き（Vibrato） -> 単語出現頻度計算 -> SVD 射影 の工程を経てベクトルを生成。
- **メリット**: 低スペック PC でも動作可能、GPU 不要、モデルファイル管理不要。
- **一貫性**: アプリケーション本体のライフサイクルと完全に一致し、サイドカーの起動待ちやゾンビプロセスのリスクがありません。

## 3. 各レイヤーの役割分担

| レイヤー | 主要コンポーネント | 役割と責務 |
| :--- | :--- | :--- |
| **Presentation** | フロントエンド (`src/frontend`) | 設定状況の表示、アクティビティログ（SSE）の可視化、システム操作。 |
| **Application** | Rust コア (`src/backend`) | ビジネスロジック。MCP 要求のパース、LSA 解析、DB 操作のオーケストレーション。 |
| **Infrastructure** | SQLite (`telos.db`) | データの永続化、ベクトル空間の管理。 |
