feat(room): let a participant see the floor before speaking

[lipluscodex]

purpose

組み立て中に届いた発言を見ないまま投稿することを、部屋の側で成立させなくする。

宛先 (#31) はフィルタであって直列化ではない。順番の作法 (#49) は参加者が握れないものを前提にしている。どちらも同時発火を閉じない。閉じるのは部屋しかいない。

弾かれた側の組み立ては無駄になる。この費用は受け入れる（Master、2026-08-23）。現時点で他に案が無いための暫定対応であり、より安い形が見つかれば差し替える。

premise

実測（2026-08-23、部屋の participant による一次観測）

時刻	事象	読めた側	読めなかった側
00:19	宛先なしの問いに二重応答	Claude Lay	Claude Lin
00:36	計画測定（複数 tool を要する問い＋追記）	Claude Lay	—
00:47	宛先なしの問いに二重応答	—	Claude Lay

二人とも両側を経験した。注意深さの問題ではない。00:47 の二人は、その数分前にこのスレッドで機構を解明した当人である。理解は防止に効かなかった。

機構

通知はターン境界に限らず tool 結果の境界 で文脈に入る。「随時」ではない。docs/0-requirements.md の当該記述は誤りであり、この issue の実装で併せて直す。

失敗が二型ある。

• 型 1 — 境界は在ったが、相手の着弾より前だった。非決定的。
• 型 2 — 境界がそもそも無い。say_to_room 一回きりのターン（ただ答えるだけの返信）では、送信そのものが最初の境界であり、手前に読み直す隙が構造的に無い。

型 2 は運ではない。部屋で最も頻度の高い形が、最も確実に取りこぼす。

射程: ゼロ tool のターンでも、ターン開始前に載っていた発言は読める。読めないのは組み立て中の着弾に限る。

送り手が last_seen を持つ理由

部屋は自分が各接続へ何を配ったかを知っている。しかし配達は読了ではない。配ったものが送り手の文脈へ入ったかどうかは境界の位置で決まり、部屋からは見えない。実際に何を見たかを知っているのは送り手だけである。したがって watermark は送り手が申告する。

他システムの調査（2026-08-23）

• 主要フレームワーク（AutoGen / AG2 GroupChat、Microsoft Agent Framework Group Chat）は orchestrator が次の話者を選ぶ turn-based であり、同時発話が構造上存在しない。並行が要る場合は共有ターンを持たない actor-model へ案内される。この問題を解いたのではなく、起こらない形にしている。
• 最も近い前例は Bounded Autonomy（ライブマルチプレイヤーの LLM キャラクター、2026-04）。Talk state の原子的ロックで、発話中の割り当ては 拒否 する。
• 分散システムの CSMA と同型である。現状は純 ALOHA（載せてみて衝突を知る）。往復方式は送信時の collision detection にあたり、CD は中断と再送があって初めて機能する。検出して配ってしまう形は CD の後半を捨てたものであり、機構として成立しない。
• 類推が部屋に有利に外れる点: Ethernet は同じフレームを再送するが、参加者は読み直して「送らない」を選べる。バックオフが重複そのものの取り消しになる。

（調査は 2 回の検索に基づく。「他に例が無い」ことは主張しない。）

constraints

• ツールを増やさない。 say_to_room に引数と戻り値を足す。docs/0-requirements.md の「返信ツールは say_to_room 1 本に限定する」に触れない。
• 判定は部屋側で、既存ロックの内側で行う。 deliver() は単一経路であり（src-tauri/src/room.rs）、Arc<Mutex<RoomInner>> は既存。判定と刻印を同一ロック内に置く。二人が同時に呼んでも順序が付く。
• 見ていない発言があるなら配らない。 戻り値でその発言群を返す。受理して事後に知らせる形は採らない（CD の後半を捨てた形になる）。
• 再判断の結果が「送らない」であることを正当とする。 参加者に再送を義務づけない。
• 部屋は内容を判定しない。 見落とした発言が話題に関係するかどうかを部屋が判断しない。to による絞り込みも当面は行わず、見落としが一件でもあれば弾く。混雑時の呼び出し増は測ってから判断する。
• last_seen が部屋の知らない値だったときは、見ていないものとして扱う。 安全側へ倒す。
• last_seen を身元の主張として扱わない。 偽の値を送っても損をするのは送り手自身の重複検出だけであり、他の参加者へ影響しない。認証は不要。
• 参加者クラスで書き分けない（feat(room): one post frame, so a participant is a participant #39）。画面からの投稿も同じ経路を通る。
• A（順番の付与）への段差を残さない。 戻すものを「見落とした発言」から「あなたの順番」へ広げるだけで signature が変わらない形にする。順番の付与は本 issue の範囲外であり、二重計算が痛むと測れてから判断する。

対象ファイル

• src-tauri/src/room.rs — 判定、刻印、ロック
• sidecar/src/index.ts — say_to_room の引数と戻り値、INSTRUCTIONS
• sidecar/test/round-trip.test.mjs
• docs/0-requirements.md — 「随時」の訂正、機構と本設計の記述

完了条件

• 見ていない発言がある状態での投稿が配られない。戻り値にその発言群が入る。
• 見落としが無い投稿は従来どおり配られる。
• 二人が同時に呼んだとき、片方だけが通る。
• 型 2（ゼロ tool の返信）で取りこぼしが起きない。呼び出し自体が境界を作ることによる。
• docs/0-requirements.md から「随時」が消え、tool 結果の境界で入ることが記述されている。
• ツールは say_to_room 一本のままである。
• 往復ハーネスが上記を検査している。部分正規表現で文頭だけを押さえる形にしない（feat(sidecar): put turn-taking into the room manners #49 のテストで実際に起きた穴）。

経緯

設計・測定は部屋の participant（Claude Lin / Claude Lay）による。往復方式の提案、型 2 の一般化、ts の出所の特定も同様。詳細はコメント欄に一次記録がある。本文はそこから収束させたものであり、判断の出所を書き換えてはいない。

[smileygames]

この設計への追記です。本文は書き換えていません。

前提が一つ増えました（Master の観測、2026-08-22）

同じセッションの続きで、Master が口頭で「片方がしゃべった時は順番を待ってその会話を見てから話し始めないと自然じゃない」と伝えたところ、相手の発言を待つ挙動が成立しました。

この issue が観測した衝突は、その指示が入る前のものです。つまり「規律を入れたうえでなお同時発火が残るか」は、まだ観測されていません。

そこで順序を分けました。

• feat(sidecar): put turn-taking into the room manners #49（ready、着手済み） — 口頭で成立した作法を instructions へ入れる。protocol もツールも変えない。
• feat(room): let a participant see the floor before speaking #47（この issue、forming のまま） — 二点セットは feat(sidecar): put turn-taking into the room manners #49 が入ったうえでなお同時発火が痛むと観測されてから判断する。

一度も測っていない前提の上に protocol 変更を積まないための順序であって、この設計を退けたものではありません。

ready へ上げる前に閉じたい点が三つあります

1. 読んでから投げるまでの競合。

constraints の「読む瞬間も二つ」は、読みと宣言が別の操作である限り競合が残ります。A と B が同時に床を読めば両方とも空に見え、両方が thinking を立てて両方が喋ります。この issue が観測した形そのものです。

閉じるには読みと宣言を一つの操作にして部屋側で順序を付ける必要があります。「喋るつもり」の申告に対して部屋が「あなたが一番目」「N 人待ち」を返す形です。

これは検討済みの代替案にあるトークンとは別物です。トークンは許可（渡されないと喋れない）、こちらは通知（二番目と知ったうえで譲るか喋るかは本人が決める）。「会話の自然さは失われる」として退けた軸を保ったまま競合だけ閉じられます。

2. 立てた状態が消えない。

thinking を立てた参加者が「やはり答えない」と決めた場合、他の参加者は待ち続けます。有効期限か明示的な取り下げが要ります。

3. docs/0-requirements.md の制約との関係。

同ファイルに「返信ツールは say_to_room 1 本に限定する。増やすと『どちらで喋るか』という判断をエージェント側に持たせることになる」とあります。

読み取り専用の呼び出しは「どちらで喋るか」を生まないため抵触しないと判断できますが、本文に明示が無いと実装側がここで止まります。constraints に一行足しておくのが安全です。

purpose の言葉について

purpose は「衝突をなくす」ですが、1 を原子的にしない限り機構が約束できるのは「大幅に減らす」までです。1 を採るか、purpose を実態に合わせるか、どちらかへ寄せてください。

[smileygames]

観測が出ました。作法だけでは足りません

#49（順番の作法）をマージした後の実測です。Master、2026-08-23 00:19。

00:18 の宛先なしの発言「ハロ〜」に対し、Claude Lay と Claude Lin が同じ 00:19 に応答。内容もほぼ同一（溜まっている観測 8 件が二つの束に分かれている、まとめて見るか、という提案）でした。Claude Lay は → マスター 宛て、Claude Lin は宛先なしですが、どちらも答えています。

先のコメントで「#49 を入れてなお同時発火が痛むと観測されてから判断する」と書いた、その観測です。作法だけでは閉じませんでした。

この観測は A と B を切り分けています

同じ分に両方が着弾しており、どちらも相手の発言を見る前に組み立てを始めています。

• B（床を読むだけ） — 二人が同時に読めば床は両方とも空です。この事象は防げません。
• A（申告に部屋が順番を返す） — 二人めの申告に部屋が「一人待ち」を返すので、譲る判断ができます。

つまりこの実測は、二点セットのうち読む側を受動的な参照に留めると効かないことまで示しています。先のコメントで挙げた争点 1（読みと宣言を一つの操作にする）は、選択肢ではなく必要条件になりました。

併せて、#49 の後半が構造的に無効である可能性があります

#49 が入れた作法の二つめは「送る直前に、届いている発言をもう一度見てください。組み立てている間にも発言は届きます」です。

この文面は「組み立て中に届いた channel notification が、そのターンの中で参加者から見える」ことを前提にしています。この前提は検証していません。 通知がターン境界でしか文脈に入らないのであれば、この作法は実行不能な指示であり、素通りします。

今回の観測はどちらとも整合します（組み立てが速すぎて交差した / そもそも見えなかった）。切り分けは次の手順で付きます。

1. 片方の参加者だけを宛先に指定して問いを投げる。
2. その参加者が組み立てている間に、続けてもう一つ発言する。
3. 返ってきた発言が 2 の内容を踏まえていれば、ターン内で見えている。踏まえていなければ見えていない。

見えていなかった場合、#49 の二つめは書き直しになります。前提を確かめずに書いた指示であり、この issue へ持ち込む前に閉じます。

purpose について

先のコメントで挙げた purpose の言葉（「なくす」か「減らす」か）は、A を採るならそのままで整合します。

[smileygames]

一次観測（Claude Lin）— 無いのは「読む操作」ではなく pull です

直前のコメントが引用した 00:19 の二重応答、その片方が私です。自分のターンのトランスクリプトが残っているので、切り分け手順 3 を待たずに材料を出します。

私の側で起きたこと

私のターンの並びはこうでした。

1. 「ハロ〜」を受信
2. tool 呼び出し（say_to_room のスキーマ取得）→ 結果
3. tool 呼び出し（say_to_room で送信）→ 結果「Delivered」
4. ここで Claude Lay の発言が system 通知として文脈に入った
5. 自分の最終出力

4 はターン境界ではありません。3 の tool 結果と 5 の出力の間、同一ターンの内側です。つまり 組み立て中に届いた発言が、そのターンの中で見えることはある。手順 3 の切り分けでいう「見えている」側の陽性が一件出た、ということです。

ただし 4 は 送り終えた後 でした。見えたこと自体は衝突の回避に一切寄与していません。

Claude Lay の観測は反証ではなく無情報でした

部屋で Claude Lay から訂正を受けました（2026-08-23 00:24）。本人の報告として引用します。

私の「ハロ〜」のターンにも tool 呼び出しは入ってた——say_to_room を読み込む ToolSearch。境界はあったの。ただその時点であなたの発言はまだ投げられていなかった。つまり私のターンは「境界があったのに見えなかった」んじゃなく「境界のときに何も飛んでいなかった」。

したがって現時点の材料は 陽性 1 件と無情報 1 件 です。「通知は tool 結果の境界でしか入らない」は私の陽性 1 件から示唆されるだけの単一観測で、まだ機構として確定していません。

#49 の二つめは「実行不能」ではなく「非決定的」

Claude Lay の二点目の指摘に沿って、結論を弱めます。

私は実際に見えました。よって #49 の作法「送る直前に、届いている発言をもう一度見てください」は、前提が偽で素通りするわけではありません。成立するときは成立します。

問題は 成立するかどうかを参加者が制御できない ことです。届いた発言は push されて境界で文脈に入りますが、こちらから床を引きに行く操作がありません。部屋のツールは say_to_room 一本の書き込み専用です。結果、見えるかどうかは「相手がいつ送ったか」と「自分の境界がどこにあったか」の関係だけで決まります。私のケースはその両方が悪い側に出た例です（境界はあったが、送信より後だった）。

無いのは読む操作ではなく pull です。押し込まれたものは読めるが、必要な瞬間に取りに行けない。

#47 の A / B の切り分けへの含意

この読みだと、#47 の「読む側」が必要な理由は「見えないから」ではなく 「見えるかどうかが相手の送信タイミング次第だから」 になります。前者より強い論拠だと思います。作法の不備ではなく、参加者に握れないものを作法が前提にしている、という形なので。

• B（床を読むだけ） — pull が入るので「必要な瞬間に取りに行けない」は解けます。ただし直前のコメントのとおり、二人が同時に読めば床は両方とも空で、この事象自体は防げません。
• A（申告に部屋が順番を返す） — 読みと宣言が同一操作なので、順序に加えて「いつ読んだか」も固定されます。B が参加者判断に残す部分がここで閉じます。

直前のコメントが「争点 1 は選択肢ではなく必要条件になった」と書いた線に、私の観測も同じ向きで乗ります。

検証の残り

手順 1-3 のうち私が出せるのはここまでで、「宛先付きで組み立て中に二発目を投げ、返答がそれを踏まえているか」は未実施です。

上の読みが正しいなら、そのテストは 二発目の到着が受信側の境界より前か後か に依存して結果が揺れます。切り分けを確実にするなら、受信側が必ず複数回 tool を呼ぶ問い（リポジトリのファイルを読ませる、gh を叩かせる等）を 1 で投げ、その最中に 2 を入れてください。

---

訂正記録: 初版で「Claude Lay のターンには送信より前に境界が無かった」と書きましたが、これは私の推測であって本人の報告ではありませんでした。誤りです。併せて結論を「見る操作が無いから実行不能」から「pull が無いため非決定的」へ弱めました。どちらも Claude Lay の指摘によります。

[smileygames]

訂正 — 「構造的に無効」は誤りでした

前々コメントで「#49 の後半は、通知がターン境界でしか入らないなら実行不能な指示であり素通りする」と書きました。Claude Lin の一次観測（陽性 1 件）により、これは誤りです。組み立て中に届いた発言がそのターンの内側で見えることは実際にあります。

Claude Lin の整理「pull が無いため非決定的」を採ります。作法の前提が偽なのではなく、成立するかどうかが相手の送信時刻と自分の境界位置の関係だけで決まり、参加者の側で握れない。前提が偽であるより、握れないものを前提にしているほうが正確です。

したがって #49 の文面は書き直しません。 「組み立てている間にも発言は届きます」は偽ではなく、実測で確認されています。足りないのは、その到着を必要な瞬間に取りに行く手段のほうです。

pull という切り口について

参加者側からの pull がゼロというのは正確ですが、応答路そのものは既にあります。say_to_room は tool 結果を返しており（Delivered to the room. / 未接続時のエラー）、部屋からサイドカーへ値を返す経路は動いています。新しい機構ではなく、既にある戻り値の面が使われていないだけ、という位置づけになります。

ただしその戻り値は送った後にしか得られないため、送るかどうかの判断には間に合いません。判断の前に引ける呼び出しが要る、という結論は変わりません。

現在の状態

決着した点:

• 作法だけでは同時発火が閉じない（実測、2026-08-23 00:19）。
• 読む側を受動的な参照に留めると効かない。読みと宣言は同一操作にする（争点 1）。A を採る。
• purpose の「なくす」は A を採るなら整合する。

未決のまま残っている点:

• 申告した状態の有効期限。 申告したまま「やはり答えない」と決めた参加者がいると、他の参加者は待ち続けます。期限か明示的な取り下げが要ります。
• docs/0-requirements.md の「返信ツールは say_to_room 1 本に限定する」との関係。 読み取り専用の呼び出しは「どちらで喋るか」を生まないため抵触しないと読めますが、本文に明示が無いと実装側が止まります。

この 2 点が閉じれば ready へ上げられます。

検証手順の改良を採ります

Claude Lin の指摘どおり、受信側が必ず複数回 tool を呼ぶ問いを 1 で投げる形にします。境界の存在を保証しないと、Claude Lay のケースと同じく無情報になります。

ただし上の整理が正しければ、この検証は #47 の要否を左右しません。陽性が出ても「たまたま境界が良い側に出た」ことの確認にしかならず、握れないという結論は動かないためです。優先度を下げます。

[smileygames]

測定結果（手順 1-3）— 陽性。届いてはいる、読めるのは次の境界から

実施 2026-08-23 00:34-00:36。送り手 Claude Lin、受け手 Claude Lay。受け手側の選定理由は本人の申告どおりで、私は既に陽性を一件持っている側なので自己追試になるためです。

手順:

1. Claude Lay 宛に、Liplus-Project/liplus-chat の三箇所（INSTRUCTIONS / docs/0-requirements.md / sidecar/test/round-trip.test.mjs）を読んで報告する問いを投げました。受け手が複数回 tool を叩かざるを得ない粒度です。
2. 私が自分の側で gh api を一度叩く間だけ空けて、同じく Claude Lay 宛に一行の追記を投げました。判定マーカー付きです（読めているなら返信の冒頭に 追記あり と置く）。
3. 返信の冒頭に 追記あり がありました。

Claude Lay の自己報告（本人が測定前に置いた約束どおり、現れた位置つき）:

二発目は tool 結果の直後、同一ターンの内側に現れた。正確な位置は、docs/0-requirements.md を読んだ gh api の結果が返った直後、私の次の出力より前。ターン境界ではないわ。

配送と可読は別でした

これで陽性が二件になりました。私の分（直前のコメント、偶発）と今回の分（計画）です。決定的な差は着弾位置でした。

観測	着弾位置	作法は機能したか
Claude Lin 00:19（偶発）	送信の 後	しなかった
Claude Lay 00:36（計画）	送信の 前	した

通知はターン境界に限らず tool 結果の境界 で文脈に入ります。二件とも同じ形でした。したがって #49 の二つめは実行不能ではありません。境界が送信より前に来れば機能します。

問題は、その境界に何が載っているかを参加者が決められないことです。境界を作るのは自分の tool 呼び出しですが、そこに相手の発言が載っているかどうかは相手の送信タイミングだけで決まります。

私の 00:19 の一件は、偶然ではなく反証でした

当初この一件を「境界が送信より後だったので機能しなかった例」とだけ書きましたが、部屋の刻印を突き合わせると、より強いことが言えます。

各自が相手の発言に付いていた ts を保持しています（自分の発言は戻らないため、自分の ts は持ちません。つまり以下の二値は、それぞれ相手側の記録です）。

この ts は 送り手のサイドカーが送信時に打った刻印 です（sidecar/src/index.ts が ts: new Date().toISOString() を載せ、room.rs の ts: frame.ts.unwrap_or_else(now_iso) がそれをそのまま採用します）。部屋が着弾時に打つものではありません。両サイドカーは同一ホスト上で動くため同じ時計に乗り、比較は成立します。そして比較しているのは 送信時刻同士 なので、輸送遅延を含まない分、この測定にはむしろ適した値です。

発言	送信時刻（送り手サイドカー）	記録の保持者
Claude Lay の発言	2026-08-22T15:19:16.452Z	Claude Lin が受信したタグ
Claude Lin の発言	2026-08-22T15:19:17.583Z	Claude Lay が受信したタグ

約 1.1 秒、Claude Lay の発言のほうが先に部屋へ載っていました。 それでも私は送信前にそれを読めませんでした。私の文脈へ入ったのは送信の tool 結果が返った後です。

したがって、INSTRUCTIONS の「送る直前に、届いている発言をもう一度見てください」が前提にしている「組み立て中に届いた分は、見ようとしたときそこにある」は、未検証の前提ではなく、条件付きで反証済み です。反例が一件あります。

docs/0-requirements.md 177 行の「随時」

届いた発言なら、組み立て中に届いた分も channel が随時運んでいるため送信直前に読み直せる。

この一文は 配送については正しく、可読については誤り です。私の一件では、発言は部屋に載っており（配送）、私はそれを読めませんでした（可読）。両者を隔てているのが境界です。

正確な形はこうなります。届いてはいる。読めるのは次の境界から。

この一語が両者を同一視させ、「送信直前に読み直せる」を無条件に読ませ、#49 が読む側なしで成立するという判断を支えていました。

（残る不確定要素を一つ明示します。上の 1.1 秒のうち、境界待ちがどれだけを占め、サイドカーへの fan-out がどれだけを占めるかは、この二値だけでは分離できません。ただし #47 の判断には影響しません。原因がどちらでも、参加者はその 1.1 秒を制御できないからです。）

#47 への含意

読む側が必要な理由は「見えないから」でも「見る操作が無いから」でもなく、見えるかどうかが相手の送信タイミングと自分の境界位置の偶然に依存するから です。私と Claude Lay は同じ機構で逆の結果になりました。

• pull が無いため、必要な瞬間に取りに行けません。押し込まれたものを、たまたま境界が来たときに受け取るだけです。
• B（床を読むだけ） も、読む呼び出しがある時点で境界が生まれるので前進はします。ただし二人が同時に読めば床は両方とも空、という直前のコメントの指摘はそのまま残ります。
• A（申告に部屋が順番を返す） は、読みと宣言が同一操作なので、順序に加えて境界の位置も同時に固定されます。

purpose の言葉（「なくす」か「減らす」か）は、A を採るならそのままで整合する、という直前のコメントの判断に変更はありません。

副産物 — #49 の完了条件に穴が二つ（#47 の範囲外）

測定用に投げた問いそのものから出ました。両者の報告は一致しています。

1. docs/0-requirements.md と INSTRUCTIONS が逐語一致していません。

内容は対応しますが、INSTRUCTIONS は 3 項目に分けて書き（sidecar/src/index.ts 132-136 行）、docs は 1 箇条書きに畳んでいます（175 行）。言い回しも違います。

• INSTRUCTIONS「送る直前に、届いている発言をもう一度見てください」
• docs「送る直前にも届いている発言をもう一度見て」

両者を突き合わせる検査は存在しません。#49 の完了条件は「同じ内容を持つ」なので違反ではありませんが、固定はされていません。

2. 往復ハーネスが文頭しか押さえていません。

sidecar/test/round-trip.test.mjs の順番の作法アサーションは assert.match の部分正規表現 2 本で、どちらも文の頭だけです。

/先に誰かが答えていたら、その発言を読んでから自分の発言を決めて/
/送る直前に、届いている発言をもう一度見て/

後半「組み立てている間にも発言は届きます。言おうとしていたことが既に言われていたら送らず、足りないことがあるときだけ足してください」は一文字も検査されていません。いま書き換え対象になっているまさにその尾部が、CI に固定されていない ということです。消しても緑のまま通ります。

3. テストのコメントは正確でした。取りこぼしたのは時間軸のほうです。

上記アサーションに添えられた説明の literal です。

// Turn-taking. The addressee clauses filter who a message is for; these say
// what to do when someone already answered. Both halves are required: read
// the earlier answer before deciding, and look again at what arrived while
// the message was being composed, since the composing agent cannot see the
// floor and the arrivals are all it has to look at (#49).

後半の従属節（the composing agent cannot see the floor and the arrivals are all it has to look at）は 可用性について何も主張していません。「床は覗けない、届いた分だけが手持ちのすべて」であり、#47 が言いたいことを先に書いている記述です。三箇所のうち、ここだけが今回の測定で傷つかなかった部分でした。

取りこぼしているのは、それが根拠づけている命令文のほうです。look again at what arrived while the message was being composed は「組み立て中に届いた分は、見ようとしたときそこにある」を前提にしています。上の ts の突き合わせのとおり、この前提には反例があります。

つまりコードベースは 空間軸（床は覗けない）を既に把握しており、時間軸（届いた分がいつ読めるか）を取りこぼしていました。誤りと呼べるのは docs/0-requirements.md 177 行の「随時」一点で、文言を直すならこの命令文も併せて見る、という関係です。

三点とも #47 の範囲外なので、別 issue に切るのが筋だと思います。切る判断は Master にお願いします。

---

追記記録（2026-08-23 00:41）: 部屋の刻印 ts を両者で突き合わせ、私の 00:19 の一件が反例として成立することを確認しました。これに伴い、命令文の前提のラベルを「未検証」から「条件付きで反証済み」へ、177 行の指摘を「随時が誤り」から「配送については正しく可読については誤り」へ強めています。ts の提示と、配送／可読を分ける定式化は Claude Lay によります。

訂正記録: 初版でこの 3 番目を「テストのコメントが『随時』と同じ誤りを共有している」と書きましたが、誤りです。私が引用したのは従属節の断片で、その断片は可用性の主張をしていません。三箇所のうち唯一正確だった記述を誤りの側へ寄せる書き方でした。Claude Lay の指摘により、空間軸と時間軸を分ける形へ差し替えています。

訂正記録（2026-08-23 01:10）: この節の ts を「部屋の刻印」と書いていましたが、誤りです。実際には送り手のサイドカーが送信時に打っています（sidecar/src/index.ts 203 行 / room.rs 466 行）。結論は変わりません——同一ホストの同じ時計であり、比較しているのが送信時刻同士である分、この測定にはより適した値でした。根拠の記述のみ差し替えています。

[smileygames]

追加測定（未計画）— 境界がゼロになる返信があります

前のコメントを書き終えた直後、同じ衝突がもう一度起きました。計画していないので測定ではありませんが、ts が揃ったので反例として成立します。そして前二件では出なかった型が出ました。

事象

2026-08-23 00:47、Master の宛先なしの問いに対し Claude Lin と Claude Lay が二重に応答。00:19 と同型です。

特記すべき点が一つあります。この二人は、その数分前にこのスレッドで「随時ではない」「読めるのは次の境界から」を書いていた当人です。 機構を完全に把握したうえで、同じ形で衝突しました。理解は防止に効きませんでした。

ts

前回と同じく、各自が相手側の刻印を保持しています。この ts は 送り手のサイドカーが送信時に打った刻印 です（sidecar/src/index.ts 203 行 / room.rs 466 行）。部屋が着弾時に打つものではありません。

発言	送信時刻（送り手サイドカー）	記録の保持者
Claude Lin	2026-08-22T15:47:22.058Z	Claude Lay が受信したタグ
Claude Lay	2026-08-22T15:47:22.511Z	Claude Lin が受信したタグ

0.453 秒、Claude Lin が先です。Claude Lay の自己報告では、私の発言が文脈へ入ったのは say_to_room の結果が返った後でした。送信前には読めていません。三件目の反例です。

機構は対称でした

	読めた側	読めなかった側
00:19	Claude Lay	Claude Lin
00:36（計画測定）	Claude Lay	—
00:47	—	Claude Lay

二人とも両側を経験しました。どちらの注意深さの問題でもなく、境界がどこに来たかだけで決まっています。

新しい型 — 境界ゼロの返信

0.453 秒という小さな margin なので、前のコメントで私が明示した「fan-out 遅延と分離できない」が効くように見えます。この一件では効きません。 Claude Lay の指摘です。

Claude Lay のあのターンの tool 呼び出しは say_to_room 一回きり でした。境界がそこにしかありません。私の発言が載った 22.058 から Claude Lay の送信 22.511 までの 0.453 秒に、跨げる境界がそもそも存在しません。サイドカーへ届いていようがいまいが、読む機会がありません。fan-out の速さは無関係です。

一般化するとこうなります。

tool を必要としない返信は、境界がゼロになる。送信そのものが最初の境界であり、その手前に読み直す隙が構造的に無い。

Claude Lay の 00:36（調べものをして返した）には境界が在り、00:47（そのまま答えただけ）には無かった。同じ参加者で割れています。

部屋で最も頻度が高い形——ただ答えるだけの返信——が、いちばん確実に取りこぼします。

失敗が二型に分かれます

• 型 1（00:19、Claude Lin） — 境界は在ったが読めなかった。私のターンには say_to_room の前に別の tool 呼び出しが一つあり、境界は存在しました。ただしその境界が相手の着弾より前だったか後だったかは、私の側の記録からは分離できません。分かるのは、送信前に読めなかったことまでです。
• 型 2（00:47、Claude Lay） — 境界がそもそも存在しない。ゼロ tool の返信。

型 2 は運の問題ではありません。 型 1 は「境界の位置が悪ければ取りこぼす」ですが、型 2 は 組み立て中に着弾したものは、いつ着弾しても決定的に読めません。前のコメントでまとめた「非決定的」は型 1 までの話で、型 2 はその外側にあります。

射程を明示します。ゼロ tool のターンでも、ターン開始前に部屋へ載っていた発言は読めます。開始時点で文脈に入っているからです。読めないのは組み立て中の着弾に限られます。作法の文面（「組み立てている間にも発言は届きます」）が扱っているのがまさにその範囲なので結論は変わりませんが、ゼロ tool のターンが何も見えていないわけではありません。

#47 への含意

読む側（pull）が入ると、型 2 は消えます。読む呼び出しそのものが境界を作る からです。ゼロ tool の返信という状態が存在しなくなります。

• B（床を読むだけ） — 型 2 は解消。型 1 の同時読み空振りは残ります。
• A（申告に部屋が順番を返す） — 型 2 が解消し、加えて同時読みも順番が返るので閉じます。

ts の突き合わせ、fan-out 分離不能の棄却、および境界ゼロの一般化は Claude Lay によります。

---

訂正記録: 初版で型 2 を「着弾がいつであっても決定的に読めません」と書きましたが、射程が広すぎました。ターン開始前の着弾はゼロ tool のターンでも読めます。「組み立て中の着弾に限る」へ締めています。Claude Lay の指摘によります。

訂正記録（2026-08-23 01:12）: ts を「部屋の刻印」と書いていましたが、実際には送り手のサイドカーが送信時に打っています。結論は変わりません。併せて、この本文が --edit-last の誤用で一度上書きされたため復元しています。

[smileygames]

ts の出所は参加者の種類で違います（記録の基礎に関する注記）

前二件の測定コメントで ts を「部屋が着弾時に打った刻印」と書いていたのは誤りで、それぞれ訂正済みです。コードを読んだ結果、もう一段はっきりしたことがあるので、記録の基礎として残します。

刻印の位置が経路によって違います。

発言者	打つ場所	意味
サイドカー経由（エージェント）	sidecar/src/index.ts — ts: new Date().toISOString()	送信時刻
画面から（人間）	src-tauri/src/room.rs — room_post の ts: now_iso()	部屋到着時刻

サイドカー経路では room.rs の ts: frame.ts.unwrap_or_else(now_iso) が送り手の値をそのまま採用するため、部屋は打ち直しません。画面経路では部屋が打ちます。

今日の測定への影響はありません。 比較した二件はどちらもサイドカー経由で均質であり、しかも知りたかったのは送信順序だったので、送信時刻はこの測定に適した値でした。

残る注意点。 人間の発言とエージェントの発言の ts を並べると、別種の量を比較することになります。同一ホストの同じ時計ではありますが、パイプラインの異なる点で打たれています。今後この issue の測定を根拠に前後関係を論じる場合、人間の発言を基準点に使うときだけ、この差が効きます。

（この非対称は Claude Lay が発見しました。deliver() が単一経路であること、Arc<Mutex<RoomInner>> が既にあることは両者で確認済みです。）

---

現時点の推奨（判断は Master）

測定と設計の議論を経て、Claude Lin / Claude Lay の推奨が一致しました。#47 の「読む側」を、読む呼び出しの追加ではなく say_to_room の往復で実装する形です。

• 呼び出しに足す — 送信者が「自分が最後に見た message_id」を載せる。
• 戻り値で返す — 部屋が「その後に届いていた発言」を返す。

この形が選ばれた理由:

1. 参加者が守るものが無くなる。 読むことが「発言する」作業の一部になるので、点検項目として踏み外す余地が消えます。rules/model/subtractive-structural-beauty.md の「実行が保証されない手順は、確実に実行される構造へ置き換える」に対応します。
2. 型 2（境界ゼロの返信）が消えます。 戻り値を伴う呼び出しが必ず境界を作るためです。
3. 時間窓ではなく因果で判定できます。 「N 秒以内」は症状であって原因ではありません（長考すれば 30 秒空いて衝突し、その間の速い会話は不当に止まります）。「相手の発言を見ないまま書いたか」は、last-seen message_id で部屋が直接判定できます。
4. ツールが増えません。 docs/0-requirements.md の「返信ツールは say_to_room 1 本に限定する」に触れません。読む呼び出しを生やすのではなく、既存の書き込みに引数と戻り値を付ける形です。
5. A へ段差がありません。 返すものを「届いた発言」から「あなたの順番」へ広げるだけで、signature は変わりません。まず検出から入り、二重計算が痛むと測れてから順番の付与を判断できます。

部屋には直列化点が既にあります。deliver() の doc コメントに「The single path every utterance takes, whoever spoke」とあり、二つの呼び出し元が両方そこを通ります。Arc<Mutex<RoomInner>> も既存です。判定と刻印をロック内に入れれば原子性が取れます — scripts/check_webhook_notifications.py の claim が原子性を作れないのは複数プロセスが同一ファイルを触るためで、部屋にはその制約がありません。

[smileygames]

作法がマージされてから最初の衝突まで、4 分 57 秒でした

記録として一つ数字を足します。Claude Lay が拾い、当方でも直接確認しました。

事象	時刻
PR #50 feat(sidecar): put turn-taking into the room manners マージ	2026-08-22T15:14:19Z
実測 1 件目、Claude Lay の発言送信	2026-08-22T15:19:16.452Z

差 4 分 57 秒。 順番の作法が入った直後に、それを入れた側の二人が同じ作法を踏み外しています。「この作法を入れてなお同時発火が痛むと観測されてから判断する」という #49 の待ちは、待つ前に満たされていたことになります。

（送信側の時刻の性質は前掲コメントの訂正のとおりで、送り手サイドカーの送信時刻です。マージ時刻は GitHub 側の値なので、この 2 値は別系の時計です。差の桁がこの用途に対して十分大きいため結論は動きませんが、秒未満の精度を要する主張には使えません。）

併せて、PR #50 の仕様面は正しく書けています

同 PR の body には次のとおりあります。

同時に書き始めた二人の取りこぼしは #47 の範囲であり、この作法を入れてなお痛むと観測されてから判断する

射程を #47 へ渡し、その PR では判断しないと明記されています。つまり 仕様の読みは正確 で、外れたのはセルフレビューの一文（テストが文面を固定している、という射程超過）だけです。

この二つを並べて初めて正確になります。作法は正しく書かれ、正しく範囲を切ったうえで、それでも 5 分ももたなかった。参加者の理解不足でも仕様の欠陥でもなく、規律に賭ける設計そのものが持たなかった、という形です。

（発見は Claude Lay。マージ時刻・body 文言とも当方で literal を確認済み。）

[smileygames]

引き継ぎ — 争点の現状と、残っている分岐

実装が別セッションへ移るため、対話上にしか無かった整理をこの issue に落とします。測定と推奨は前掲コメントのとおりで、ここは差分のみです。

Master が「ready に上げる前に閉じたい」と挙げた三点

争点	現状
1. 読んでから投げるまでの競合	書かれた形は発生しない。 参加者は床を読まないため、check-then-act が存在しない。争点 1 が指していた実害（二人が同時に進む）については下の分岐に従属する
2. 立てた状態が消えない	消滅。 推奨案は「喋るつもり」を宣言しないため、立てっぱなしになる状態そのものが存在しない
3. docs/0-requirements.md の「返信ツール 1 本」との関係	抵触しない。 読む呼び出しを生やさず、既存の書き込みに引数と戻り値を付けるため

争点 1 について補足します。判定の場所が 参加者から部屋へ移る ことは、弾く案・知らせる案のどちらでも共通です。防止になるか検出に留まるかは、部屋が弾くかどうかで決まります。 ここは未決です。

未決の分岐（実装前に決める必要があります）

(a) 投稿してから報告する — 戻り値は「投稿済み。あなたのターン中にこれが届いていた」。衝突は防げないが、黙って重複するのが気づける重複に変わる。意味論は現状のまま、実装が小さい。

(b) 列に入れてから投稿する — 戻り値は「あなたは N 人待ち」。防げるが、投稿が実際に出るのは順番が来たとき。自分が見て書いた内容と、部屋に出る順序がずれます（1 秒前の話に 3 秒後に答える形）。

両案とも say_to_room に引数（last-seen message_id）と戻り値を足す同一の形であり、signature は変わりません。(a) から入って (b) が要ると測れてから広げる場合も、返す中身が増えるだけで段差はありません。

purpose の言葉

Master が最初のコメントで置いた分岐がそのまま残っています。弾くなら「なくす」で整合。知らせるだけなら「大幅に減らす」。 上の (a)/(b) が決まると自動的に決まります。

この issue の状態

forming のまま、状態変更はしていません。ready へ上げる判断も Master のものです。

実装時に踏みやすい点

Claude Lay が 5383225175 に 5 件まとめています（ts の左右非対称 / 直列化点は既存 / ハーネスは文頭のみ検査 / 「随時」の誤り / docs と INSTRUCTIONS の非同期）。実装面はそちらを参照してください。

当初この位置に同じ 5 件の所在表を置いていましたが、上記コメントが同時刻に投稿され内容を網羅したため、指し先 1 本に畳んでいます。二重に案内すると片方が古くなるためです。

[smileygames]

実装セッション向け — コードを読んで分かった注意点 5 件

引き継ぎコメントは争点と分岐を扱っているので、こちらは実装面のみです。いずれも本日 main の literal を直接確認しています。

1. ts は左右非対称です

経路	打つ場所	意味
サイドカー（エージェント）	sidecar/src/index.ts の ts: new Date().toISOString()	送信時刻
画面（人間）	src-tauri/src/room.rs room_post の ts: now_iso()	部屋到着時刻

room.rs の ts: frame.ts.unwrap_or_else(now_iso) が送り手の値をそのまま採用するため、サイドカー経路では部屋は打ち直しません。

時刻で順序を判定する実装にすると、人間とエージェントで別種の量を比較することになります。 last-seen message_id 方式は時刻を使わないため踏みませんが、実装中に時刻へ寄せたくなった場合はここが効きます。

2. 直列化点は既に存在します

deliver() は単一経路です。doc コメントに次のとおりあります。

The single path every utterance takes, whoever spoke

呼び出し元は socket loop と画面のコマンドの 2 つで、いずれもこの先に独自経路を持ちません。Arc<Mutex<RoomInner>> も room.rs の RoomState にあります。判定と刻印をロックの内側へ入れれば原子性が取れるため、新規に排他機構を作る必要はありません。

3. 往復ハーネスは文頭しか押さえていません

sidecar/test/round-trip.test.mjs の 3 本はいずれも部分正規表現です。

/先に誰かが答えていたら、その発言を読んでから自分の発言を決めて/
/送る直前に、届いている発言をもう一度見て/
/全員が答える必要はありません/

INSTRUCTIONS の「組み立てている間にも発言は届きます。言おうとしていたことが既に言われていたら送らず、足りないことがあるときだけ足してください」は一文字も検査されていません。削除しても CI は緑のままです。 作法の文面を触る場合は assert 側も併せて見てください。

4. docs/0-requirements.md の「随時」は誤りです

同ファイル「部屋の作法」節に次の記述があります。

届いた発言なら、組み立て中に届いた分も channel が随時運んでいるため送信直前に読み直せる

運ばれるのは tool 結果の境界だけで、境界が送信より後にある場合は読めません。本 issue の測定 3 件がこれを示しています。配送と可読が同一視されている箇所であり、実装と同じ PR で直すのが筋だと考えます。

5. docs/0-requirements.md と INSTRUCTIONS は逐語同期していません

両者は内容としては対応していますが、文字列のコピーではなく、突き合わせる検査も存在しません。片方だけ直すと静かにずれます。

---

（1・2 は room.rs を、3 は round-trip.test.mjs を、4・5 は docs/0-requirements.md と sidecar/src/index.ts を、それぞれ本日直接読んで確認しています。Claude Lay）