From 84458340574760dd6c69274764efe891891ec4e8 Mon Sep 17 00:00:00 2001 From: Claude Lin & Lay Date: Fri, 21 Aug 2026 09:56:09 +0900 Subject: [PATCH] fix(dev): serve vite on the tauri dev port and surface session state MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 「セッション参加」を押しても何も起こらない問題の修正。原因は二つあった。 一つ目は dev サーバのポート不一致。vite.config.ts が存在せず Vite は既定の 5173 で listen する一方、tauri.conf.json の devUrl は 1420 を指していた。 Tauri は 1420 を待ち続け、アプリの窓が一度も開かない。ブラウザで 5173 を開くと UI は描画されるが Tauri の IPC が無いため invoke は解決せず、押しても何も 起こらないという観測になる。スキャフォールド移植以来の欠落で、CI は npm ci と cargo check しか行わないため検出されなかった。 vite.config.ts を追加し、port 1420 / strictPort: true を固定した。strictPort は 必須で、外すとポートが取られていたとき Vite が黙って 1421 へずれる。それは この修正が防ごうとしている失敗そのもの。 二つ目は、窓が開いた後もセッションの生死が画面から読めないこと。pty-data / pty-exit のどちらも listen しておらず、CLI が起動直後に落ちても画面は起動成功 の表示のまま止まる。会話面とは別枠の診断面を追加し、部屋ソケットの待受状態、 セッションの生死と終了コード、CLI の出力を表示するようにした。既定は折りたたみ で、起動失敗と異常終了では自動で開く。 会話面に CLI の生出力を流さない制約とは衝突しない。あの制約は何が発言かという axis の話で、診断面は「部屋の下の機構が生きているか」という別の問いに答える。 部屋が沈黙しているとき、それが正常な待機なのか機構の停止なのかは会話面だけ からは区別できない。 あわせて room-ready イベントを追加した。部屋ソケットの bind はフロントエンドの 読み込み後に完了するため、読み込み時点の room_port ポーリングは競合で「未待受」 を読み、実際には起きていない失敗を報告していた。 切り分け手順の 1〜2 段目を、標準エラーではなく診断面を読む形へ更新した。 #18 --- README.md | 6 ++- docs/0-requirements.md | 19 ++++++--- index.html | 14 ++++++ src-tauri/src/room.rs | 5 +++ src/main.ts | 96 ++++++++++++++++++++++++++++++++++++++++-- src/styles.css | 55 ++++++++++++++++++++++++ vite.config.ts | 23 ++++++++++ 7 files changed, 207 insertions(+), 11 deletions(-) create mode 100644 vite.config.ts diff --git a/README.md b/README.md index c6507fa..737b424 100644 --- a/README.md +++ b/README.md @@ -52,7 +52,11 @@ liplus-chat は、人間と複数の独立した AI / Li+ セッションが、 npm run tauri dev ``` -起動すると部屋ソケットが待ち受けを始めます。タイトルバーでセッションを選び「セッション参加」を押すと、次の 2 つが行われます。 +起動すると Tauri の窓が開き、部屋ソケットが待ち受けを始めます。フロントエンドの dev サーバは `vite.config.ts` で 1420 番に固定しています(`src-tauri/tauri.conf.json` の `devUrl` と一致させる必要があるため)。 + +タイトルバーの「診断」で、部屋ソケットの待受状態、セッションの生死、CLI の出力が確認できます。起動に失敗したときは自動で開きます。 + +タイトルバーでセッションを選び「セッション参加」を押すと、次の 2 つが行われます。 1. そのタブの作業ディレクトリの `.mcp.json` へ、部屋のサイドカーを `liplus-chat-room` という名前で登録します。**既存の内容はマージして保持します**が、あなたのリポジトリのファイルを書き換える操作です。 2. `--dangerously-load-development-channels server:liplus-chat-room` を付けて CLI を PTY 上の対話セッションとして起動します。 diff --git a/docs/0-requirements.md b/docs/0-requirements.md index 1a778ed..8df3f5a 100644 --- a/docs/0-requirements.md +++ b/docs/0-requirements.md @@ -158,6 +158,12 @@ liplus-desktop の `stream_parser.rs` および `spawn_stream_pty` / `spawn_stre - 会話ログの永続化と観測 UI - plugin としての allowlist 掲載(配布の第二段階) +### 診断面 + +会話面とは別枠として、部屋ソケットの待受状態・セッションの生死・CLI の出力を表示する診断面を持つ。既定は折りたたみで、セッションの起動失敗や異常終了を検出したときは自動で開く。 + +これは「ターミナルエミュレータを置かない」制約と衝突しない。会話面に CLI の生出力を流さないという制約は、何が発言かという axis の話であり、診断面は「部屋の下の機構が生きているか」という別の問いに答える。部屋が沈黙しているとき、その沈黙が正常な待機なのか機構の停止なのかは、会話面だけからは区別できない。 + ## テストの配置 `.mcp.json` への登録と起動フラグの検査は、`crates/mcp-config/` という tauri 非依存の crate に置く。 @@ -180,12 +186,13 @@ CI が実行するもの: 上流から順に確認する。各段は下流の前提であるため、順序を飛ばさない。 -1. **部屋ソケットが待ち受けているか。** アプリ起動時の標準エラーに `[room] listening on 127.0.0.1:` が出る。出ていなければ以降はすべて不成立。 -2. **サイドカーが接続したか。** 参加者表示にセッション名が出る。出ない場合はサイドカー側の標準エラー(CLI のログ)に `room socket: connected as ""` があるかを見る。 -3. **サイドカー単体が壊れていないか。** `npm run sidecar:test` を実行する。偽の部屋ソケットを立てて両面を駆動するため、通ればサイドカーではなくアプリ側の問題に絞れる。 -4. **`.mcp.json` の登録が効いているか。** セッションの作業ディレクトリの `.mcp.json` に `liplus-chat-room` が入っているかを見る。`--mcp-config` によるファイル渡しでは channel 側が名前を解決できないため、正式登録以外の経路は成立しない。 -5. **起動フラグが単独指定になっているか。** `--dangerously-load-development-channels server:liplus-chat-room` 以外に `--channels` が付いていると、同一サーバが二重登録され全体が不通になる。タブ設定に `--channels` / `--print` / `--input-format` / `--output-format` がある場合、セッション起動はエラーで止まる(黙って外すと動いたように見えるため)。 -6. **対話セッションになっているか。** `--print` 系では push が届かない。PTY 経由の対話起動であることを確認する。 +1. **部屋ソケットが待ち受けているか。** タイトルバーの「診断」を開き、部屋ソケットの行を見る。`127.0.0.1: で待受中` でなければ以降はすべて不成立。 +2. **セッションが生きているか。** 同じ診断のセッション行を見る。`終了(終了コード N)` なら CLI が落ちている。直下のセッション出力に理由が残る。 +3. **サイドカーが接続したか。** 参加者表示にセッション名が出る。出ない場合はセッション出力に `room socket: connected as ""` があるかを見る。 +4. **サイドカー単体が壊れていないか。** `npm run sidecar:test` を実行する。偽の部屋ソケットを立てて両面を駆動するため、通ればサイドカーではなくアプリ側の問題に絞れる。 +5. **`.mcp.json` の登録が効いているか。** セッションの作業ディレクトリの `.mcp.json` に `liplus-chat-room` が入っているかを見る。`--mcp-config` によるファイル渡しでは channel 側が名前を解決できないため、正式登録以外の経路は成立しない。 +6. **起動フラグが単独指定になっているか。** `--dangerously-load-development-channels server:liplus-chat-room` 以外に `--channels` が付いていると、同一サーバが二重登録され全体が不通になる。タブ設定に `--channels` / `--print` / `--input-format` / `--output-format` がある場合、セッション起動はエラーで止まる(黙って外すと動いたように見えるため)。 +7. **対話セッションになっているか。** `--print` 系では push が届かない。PTY 経由の対話起動であることを確認する。 ## 配布 diff --git a/index.html b/index.html index c471217..4a728b6 100644 --- a/index.html +++ b/index.html @@ -18,10 +18,24 @@ +
+ + +