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

1. 全体構造図

本システムは、OS のシステムトレイに常駐する「ホストプロセス（Tauri 2）」と、推論を担う「サイドカープロセス（llama-server）」、および外部エージェントとの通信を担う「MCP サーバ（Axum）」の 3 つが有機的に連携する構造です。

graph TD
    subgraph "Presentation Layer (Webview2)"
        UI["Glassmorphism 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)"]
        Broadcast["Tokio Broadcast Bus"]
    end

    subgraph "Infrastructure Layer"
        DB["SQLite + sqlite-vec (telos.db)"]
        LS["Sidecar: llama-server (Port 8080)"]
        M["Gemma-3 Model (Local inference)"]
    end

    UI -- "IPC: Invoke" --> Tauri
    Tauri -- "IPC: UI Update" --> UI
    Axum -- "SSE: Status Events" --> UI
    Axum -- "Internal Notif" --> Broadcast
    Broadcast -- "Internal Notif" --> Axum
    Tauri -- "SQL" --> DB
    DB -- "SQL" --> Tauri
    Axum -- "SQL" --> DB
    DB -- "SQL" --> Axum
    Tauri -- "HTTP/Embedding" --> LS
    LS -- "Inference" --> M
    Tray -- "Command" --> UI

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

2.1 Tauri Core と Axum (MCP) の連携

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

2.2 推論サイドカー (llama-server) の制御

Embedding 計算を行う llama-server は、Tauri のサイドカー機能によって起動・管理されます。

• 起動時: lib.rs の setup フックでサイドカーをスポーン。
• 通信: Rust バックエンドが reqwest を用いてローカルポート 8080 へ HTTP 要求を送信。
• 終了時: Tauri のプロセスマネージャにより、アプリ終了と同時にサイドカーも安全にクリーンアップされます。

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