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

1. 全体構造

本システムは、Tauri 2 をホストとしたマルチプロセス・マルチレイヤー・アーキテクチャを採用しています。

graph TD
    subgraph "Presentation Layer (Webview2)"
        UI[Frontend UI: HTML/CSS/JS]
    end

    subgraph "Application Layer (Rust / Tauri Core)"
        Tauri[Tauri Backend]
        Axum[Axum MCP Server]
        Llama[Llama Client / HTTP]
        Sidecar[Sidecar Process Manager]
    end

    subgraph "Infrastruture Layer"
        DB[(SQLite / sqlite-vec)]
        LS[Sidecar: llama-server]
        M[Gemma-3 GGUF]
    end

    UI <-->|IPC: Invoke/Events| Tauri
    Tauri <--> Axum
    Tauri <--> DB
    Axum <--> DB
    Tauri <--> Llama
    Llama <-->|HTTP| LS
    Sidecar -->|Life Cycle Control| LS
    LS -->|Inference| M

2. 各層の定義

2.1 Presentation Layer

技術: Vanilla HTML, CSS, JavaScript (Vite ベース)
役割: システムステータスの可視化、データベース閲覧機能の提供。
通信: invoke コマンドによる非同期通信。

2.2 Application Layer

Tauri Core: アプリのライフサイクル、トレイ、ウィンドウ制御、環境変数の管理。
Axum (MCP Server): Model Context Protocol (MCP) に準拠した SSE (Server-Sent Events) サーバー。
Llama Client: reqwest を使用した API 通信。Sidecar との疎通とリトライを制御。
Sidecar Manager: llama-server バイナリの起動、DLL パス解決、子プロセスの死活監視。

2.3 Infrastructure Layer

SQLite: SeaORM を介したリレーショナルデータ管理。
sqlite-vec: vec0 仮想テーブルによるベクトル検索エンジン（DLL 拡張）。
Sidecar (llama-server): llama.cpp ベースの推論エンジン。

3. プロセス同期モデル

処理	同期/非同期	説明
UI 更新	非同期 (Event)	バックエンドからの非同期メッセージ受信により更新。
API リクエスト	非同期 (Async/Await)	`tokio` ランタイム上でのノンブロッキング I/O。
DB トランザクション	原子性 (Atomic)	`items` と `vec_items` の一貫性は Rust 側トランザクションで保証。

4. ライフサイクル管理

Setup: Tauri 起動時に Sidecar フォルダを特定し、DLL パスを補強。
Spawn: llama-server プロセスの起動とヘルスチェック待機。
Running: MCP サーバーと UI が連携。
Shutdown: アプリケーション終了時に子プロセス (Sidecar) を確実にシグナル通知ののち Kill。