docs: record the settled ui direction and what it leaves open

[smileygames]

目的

2026-08-21 の対話で「とりあえずの UI」が決まった。方向と、決まっていない箇所を docs/0-requirements.md に記録する。

前提

設計キャンバス（Artifact）に 2 枚のアートボードとして残っている。

• 次の一手（実装可能な範囲）— 現在の実装 + 参加者パネル + 宛先
• 全体像（到達点）— ルーム一覧 / ダイレクト / 参加者・セッション状態パネル

Master が保存した版を読み直した結果、アートボードの内容に変更は無く、launch が canvas から focused: Main.dc.html（次の一手）へ変わっていた。編集ではなく、開く位置の指定である。

色・寸法は src/styles.css の実値をそのまま使用しており、絵と実装が同じトークンの上に乗っている。

記録する内容

決まったこと

• 会話面はメッセージ単位。端末は診断面側に置き、会話面には置かない（既存の制約の再確認）。
• 参加者パネルを持つ。セッションの接続方法・起動コマンド・作業ディレクトリ・開始時刻・操作（端末 / ミュート / 終了）を出す。
• 発言に宛先を持たせる（feat(room): give utterances an addressee so agents can stay silent #31）。

決まっていないこと（値札付き）

• 複数ルーム — サイドカーの chat_id は 1 つ固定。ルームごとにセッションを立てるか、1 セッションが複数ルームに属するか。前者は利用枠がルーム数ぶん増え、後者はプロトコル変更を伴う。
• システム発言の出所 — エージェントが say_to_room で言うなら可。アプリがファイルや git を監視して言うなら「部屋がランタイムになる」制約に当たる。
• webhook を部屋へ流す案（memo: route webhooks into the room as a participant instead of per-session mcp #32）— 未採用。

この UI は本番向けではない（Master 判断）。段階的に作り、機能と並行して改善する。

制約

• 決定と未決定を混ぜない。未決定を決定として書かない。
• 「とりあえず」であることを残す。確定仕様として書くと、次に変えるとき仕様変更の手続きが要るように読める。

対象ファイル

• docs/0-requirements.md

完了条件

• UI の方向がキャンバスへの参照とともに記録されている。
• 決まっていない三点が、それぞれの費用とともに読める。
• 暫定であることが明示されている。