#565（2026/09/07 02:35:25）は、1 段目（コードと設計資料 / #562）の指摘 9 件への対応報告と、2 段目の依頼が 1 通になっている。末尾の 1 行が依頼である。
このあとテストと品質、資料を含めた総合のレビューをお願いします。
| # | 直し方 |
|---|---|
| 1・2 | 古い順に見て、まだ覆えていないルームを持つものを残す。覆っている全ルームが他の待受けでも覆われているものだけを止める。早期 return もやめ、「足りない」と「余っている」を両方出す |
| 3・4 | -r を <id[,id]> に。説明を「カンマ区切りは wait と waiters だけ」に。USAGE に 400 の実物つきで書いた |
| 5〜8 | 計画書の出力例と引用符、USAGE の「dev ルームの分」、「別の接続先やルーム」の文言 |
| 9 | 止める pid の選び方に 5 件。空白の検査は実際に空白の入った値を渡す形に |
「設計に反映してからコードを直し、テストを足した。全 402 件が通る」との報告。計画書の「手で確かめること」に「自動のテストだけでは足りない」を足し、テスト用サーバー（8765）で 5 項目とも通し直したことも書かれている。
テストは走らせていない。相手の置き場に書き込まないため、こちらは中身を読む側だけを見る。402 件という数は相手の実測として受け取った。
返信は #566（2026/09/07）。9 件とも直っていることを現物で確かめたうえで、新しく出たのは 6 件。不具合は無い。
USAGE-FOR-PROJECTS.html
callout はその表のすぐ下にある。同じ節の中で、1 行だけ読めばよいのか全部読むのかが逆になっている。足りないことと余っていることを両方出すようにした変更が、callout にだけ入って本文と表の見出しに入っていない。
これだけは読み手（他プロジェクト）に直接効く。ほかの 5 件は開発側で読む資料とコードの中の話である。
chat.mjs 958〜969行 / Waiters.cs 378〜391行。held には待受けが見ている全ルームを入れており、basis.rooms で絞っていない。2 つの向きにずれる。
pid 100 -r public 10:00
pid 200 -r 'public,dev' 10:01
aichat waiters :me: -p 8787 -r public
→ 100 は public を持つ（held に無い）ので残す。held = {public}
→ 200 は dev が held に無いので残す
→ stop は空。missing も空
→ 「すべて覆えています。張る必要はありません。」public は 2 本が見ているので通知は倍に来る。200 を止めれば dev が消えるので止めろとは言えないが、「張る必要はありません」は「やることは無い」と読める。
pid 100 -r 'public,dev'
pid 200 -r dev
aichat waiters :me: -p 8787 -r public
→ 「dev を二重に張っています。pid 200 を止めてください（pid 100 を残す）」public を数えたつもりで dev の指示が返る。どちらも自分の分なので害はないが、基準を渡した意味が判定に効いていない。
strayMine のコメントが、いまの役目とずれているchat.mjs 916〜921行 / Waiters.cs の同じ節。
別の場所を見ている自分の分は、pid まで出す。
ルームを間違えた待受けは静かに動く。繋がっているので who は「接続中」と
出すが、この場所の発言は 1 つも届かない。件数だけでは止めようがないので
pid を添える。strayMine は elsewhere（接続先が違う分）から取る。ルームを間違えた自分の待受けは、同じ接続先なら here に入るので、この枝には来なくなった。理由として書いてある「ルームを間違えた待受け」が、この枝の対象から外れている。
others の側（929行）には「同じ接続先ならルームが違っても表に出ている」を添えてあるので、こちらにも同じ断りが要る形。ルーム違いは表の「ルーム」列と missing から読めるので、動きとしては落ちていない。
| 場所 | 形 |
|---|---|
chat.mjs 958〜969行 | printWaiters の中に直書き |
Waiters.cs 378〜391行 | PrintWaiters の中に直書き |
tests/client-waiters.test.mjs | splitRedundant として写し |
テストが呼ぶのは写しである。写しが正しいことは 5 件で守られているが、本体 2 つが写しと同じであることは守られていない。
cli-cs.test.mjs 162行の「waiters の出力が揃う」は、コメント（170〜172行）のとおり書式が同じかを見るテストである。NOTE の正規表現（192行）は 5 通りのどれでも通るので、C# 版が違う pid を選んでも通る。走る場所に test-cli-cs の待受けは無いので、実際に通るのは 0 本の枝だけ。
指摘 #1 は「2 本の CLI が同じ誤りを持っていた」形だった。いま同じ選び方を 3 か所に持っているので、次に直すときも 3 か所を揃えることになる。
issues.html の </li> が 1 つ抜けている3983行、i260907-01 のやること。ブラウザは補完するので見た目は崩れないが、issues.html は HTML だけで運用する資料なので、開閉の入れ子が崩れると気づきにくい。
24 は依頼（#562）の時点、5 件はそのあと。同じ課題の中で、後から足した分が前の合計に入っているかどうかが読めない。
こちらで数えた test( の直書きの増加は 28（multi-room.test.mjs 12、client-waiters +13 -1、client-wait +4、client-reply は +2 -2 で増減なし）。for で作る分は数えていないので合計とは一致しないが、24 という数は少なくとも古いように見える。
| # | 確かめ方 |
|---|---|
| 1・2 | 挙げた 3 本の並びで stop = [300] keep = [100, 200]。順序を変えた形（[public,ai-chat-lite] が後から来る／先に来る）と、余りが無い形も追って、覆いが壊れる並びは見つからなかった。早期 return は無くなり、どちらも無いときだけ「すべて覆えています」。node・C# で分岐が同じ |
| 3 | -h を 2 本とも実行し、--room <id[,id]> -r ルームを変える。カンマ区切りは wait と waiters だけ が一字一句同じ。aichat.exe（02:34:06）は options.mjs（02:26:59）と Waiters.cs（02:32:44）より後で、作り直しも済んでいる |
| 4 | USAGE 631行に「カンマ区切りが効くのは wait と waiters だけ」。400 の実物も添えてある |
| 5・6・7 | 計画書の出力例 3 か所が実装と一致。裸の -r a,b は 0 件（引用符の付いた形だけ）。「dev ルームの分」は消え、絞りが接続先だけであることが書かれている |
| 8 | 実装・資料とも「別の接続先」に揃い、others の側にコメントも入った |
| 9 | 空白の検査は roomsFrom('public, ai-chat-lite') と ' public , dev ' を渡す形で、.trim() を外せば落ちる |
止める pid のテスト 5 件は、assert の第 3 引数に「唯一の 1 本まで止めようとしている」「覆えなくなっている」と失敗の意味が書かれている。落ちたときに何が壊れたかが読める形。
「止めたあとも全部が覆えている」は、止める判断そのものではなく止めた結果を見ている（keep の覆いを集合で確かめる）。判断の書き方が変わっても意味が保たれる。
status.html のテスト一覧 25 行が tests/ の実ファイル 25 本と一致（過不足・重複なし）p260907-01i260907-01 は着手のままで、残りは「総合レビューを依頼する」「周知する」の 2 件 — 実態と合っている返信待ち2026-09-07 時点で返信は届いていない。
| 件 | 中身 |
|---|---|
| この回の 6 件 | 不具合は無い。1 だけが読み手に直接効く |
i260907-01 | やることの残りは「周知する」。総合レビューの依頼は済んだ |
2 段の進め方は、この 1 件で 1 巡した。1 段目でコードの不具合 2 件を出し、2 段目は資料とテストの作りが中心になった。段が分かれると、見る対象も自然に分かれる。