feat(launcher): make the launch options editable and merge the room channel

[smileygames]

Closes #26

変更前後

Master の希望:

claude --dangerously-skip-permissions --dangerously-load-development-channels server:github-webhook-mcp

これを起動オプション欄へそのまま書くと、実際の起動はこうなる。

claude --dangerously-skip-permissions --dangerously-load-development-channels server:liplus-chat-room server:github-webhook-mcp

なぜ統合なのか

第二のフラグとして足すと、同一フラグの二重指定になる。liplus-desktop #90 の実測では --channels 併記による二重登録で全体が不通になっており、同じ形を自分で作ることになる。

上書きでもない。利用者の指定で部屋のエントリを落とせるようにすると、落ちた時点で部屋の入力路そのものが消える。

したがって、利用者が channel フラグを書いていればその直後へ挿入し、書いていなければフラグごと足す。既に部屋のエントリがあれば重複させない。

表示

実際に起動する行を入力欄の右に出す。書いた行と走る行が違う以上、結果を見せるほうが説明より安い。

引数の分割

mcp-config 側に置いてテストで固定した。TypeScript 側に第二の実装を書くとテスト済みの側からドリフトするため、フロントエンドは parse_launch_options コマンド経由で呼ぶ。

二重引用符によるグループ化のみ解釈する。空白分割だけだと "C:\Program Files\..." のような指定が黙って二つに割れる。バックスラッシュはエスケープではなくそのまま。

未検証（重要）

一つのフラグに server: エントリを複数並べられるかは確認できていない。

#90 の実測が確定しているのは「--channels を併記すると二重登録で不通になる」ことであり、同一フラグへの複数エントリは扱っていない。--print での確認は無意味（channel の読み込み自体が走らないため。実測済み）。対話セッションでのみ確かめられる。

したがって Master の次の実行がそのまま検証になる。通らなければ端末にエラーが出るので切り分けられる。docs にも未検証として明記した。

検証

• cargo test（crates/mcp-config、8 → 11 pass）
• npm run build / cargo check --target x86_64-pc-windows-gnu

release type

minor — user/system observable な機能追加（起動オプションの編集と channel の統合）。

[smileygames]

AI self-review (execution_mode = auto)

受け入れ条件の照合（issue #26 完了条件）

条件	結果	根拠
起動オプションを画面から編集でき、保存される	実装済 / 実機未確認	#launch-options 欄、起動成功時に tab.args として save_config
利用者が channel フラグを書いた場合、部屋のエントリがそこへ統合される	pass	merges_the_room_into_a_channel_flag_the_person_already_wrote がフラグ 1 回であることまで assert
部屋のエントリが常に含まれることがテストで固定されている	pass	上記 + the_launch_flag_names_the_server_the_config_registers + does_not_add_the_room_twice
引用符付きの引数が壊れない	pass	splits_launch_options_keeping_quoted_arguments_whole がスペース入り Windows パスと空引数を assert

制約の照合

• 部屋のエントリを利用者の指定で落とせない: pass。channel_launch_args は上書き経路を持たない。
• reject_incompatible_flags は維持: pass。--channels / --print / --input-format / --output-format は引き続きエラーで止まる。
• 分割の実装を二重に持たない: pass。TypeScript 側は parse_launch_options コマンド経由で mcp-config の実装を呼ぶ。#22 で「テストが実装と別の経路を通っていた」ことを踏まえた配置。

実機側の状況

本 PR 作業中に config.json が更新され、Master の希望する args が既に入っていた。

"args": ["--dangerously-skip-permissions",
         "--dangerously-load-development-channels",
         "server:github-webhook-mcp"]

現在の main（#27 前）ではこれが壊れる。channel_launch_args が無条件に追記するため、同一フラグが二回並ぶ。

... server:github-webhook-mcp --dangerously-load-development-channels server:liplus-chat-room

これは #90 が「不通になる」と記録している二重登録と同じ形。本 PR はまさにこの状態を防ぐもので、merge の時機として妥当。

未検証（docs に明記済み）

一つのフラグへ server: エントリを複数並べられるかは未確認。#90 が確定しているのは --channels 併記の失敗であり、同一フラグへの複数エントリは扱っていない。--print での確認は channel の読み込みが走らないため無意味であることを実測した。対話セッションでのみ確かめられる。

推測で「通る」と書かず、未検証のまま実装した。次の実行が検証になる。

検証

• CI 全ステップ pass（cargo test 11 pass）
• ローカルで cargo check --target x86_64-pc-windows-gnu / npm run build

scope deviation

なし。

次の期待

execution_mode = auto のため人間レビューゲートなし。CI green（CI pass / check pass 1m37s）。self-review pass により squash merge へ進む。