devbasex · takemi-ohama · Sep 22, 2026 · Sep 22, 2026 · Sep 22, 2026 · Sep 22, 2026
@@ -112,13 +112,15 @@
 
 | 種別 | 照合の鍵 |
 | --- | --- |
-| `review-post` | 投稿者と、本文の先頭行の `## 🤖 cross-review \| round <R> \| <席> \|` までの前方一致（判定の語を含めない） |
+| `review-post` | 投稿者と、本文の先頭行の `## 🤖 cross-review \| round <R> \| <席> \|` までの前方一致（判定の語を含めない）。ラウンドの開始時刻を持つときは、それ以降に出たレビューに限る |
 | `review-reply` | 返信先の指摘の識別子と、本文の先頭 80 文字 |
 | `thread-resolve` | スレッドの識別子と、すでに決着しているかどうか |
 | `pr-comment` | 投稿者と、本文の先頭 80 文字（ラウンドを含む） |
 
 投稿者はどの席でも同じになる。ラウンドと席を先頭行に持たせることで、同じ投稿者の別の投稿と区別できる。
 
+**レビューの照合は、そのラウンドが始まった時刻（状態ファイルの `rounds[-1].started_at`）以降に出たレビューに限る。** ラウンドの番号は実行ごとに 1 から数え直すため、収束した PR へ回し直すと、ラウンドと席だけの鍵が前の実行のレビューに一致し、新しい指摘を送らずに前の実行の投稿を送れた先として記録する。開始時刻で絞っても同じ実行の中の送り直しは従来どおり見つかり、開始時刻かレビューの時刻を読めないときはラウンドと席だけの照合へ落とす。
+
 ### 決定 6: 投稿済みで記録なしの状態が起きなくなるため、投稿済みのレビューを探して記録だけの起動をする決めを取り下げる
 
 担当が投稿しなくなるため、探す対象が無い。**GitHub からレビューを探す照会も、記録だけを行うプロンプトも作らない。** 止まった担当を起動し直すときは、初回と同じプロンプトをそのまま使う。
@@ -362,12 +364,48 @@ graph TD
 
 **偽の `gh` を使う形は既存のテストにある**（待ち行列の照合と巻き直しの投稿）。同じ仕掛けを使う。
 
-## 未確認のまま残ること
+## 実測で決めた 4 件
+
+設計の時点で未確認だった 4 件を、2026-09-22 に実物の `gh` で 1 度ずつ動かして決めた。対象は
+この束の設計を載せた Pull Request #794（マージ済み、head `233f28ba`）である。拒まれた要求は
+何も作らないため、確かめた跡は残っていない（レビューとレビューのコメントを引いて 0 件）。
+
+### 差分の外を指す指摘が拒まれるときの応答の形
+
+レビューの作成は**要求ごとに全件が拒まれる**。正しいインラインを混ぜても、一部だけが作られる
+ことはない。終了コードは 1 である。
+
+| 何を送ったか | 応答の `errors` |
+| --- | --- |
+| 差分に無いファイルのインライン 1 件 | `["Path could not be resolved"]` |
+| 差分にあるファイルの、塊の外の行のインライン 1 件（正しいインライン 1 件と同時） | `["Line could not be resolved"]` |
+| 塊の外・差分に無いファイル・塊の外の 3 件 | `["Line could not be resolved, Path could not be resolved, and Line could not be resolved"]` |
+| 判定の値に知らない語 | `["Variable $event of type PullRequestReviewEvent was provided invalid value"]` |
+| 基準のコミットに存在しない値 | `["The commitOID is not part of the pull request"]` |
+
+**退避の契機に使う語は `could not be resolved` である。** 判定の値の誤りと基準のコミットの誤りは
+この語を含まないため、決定 9 のとおり失敗として残せる。
+
+### 拒まれた応答から、どのインラインが原因かを 1 件ずつ特定できるか
+
+**特定できない。** 応答は語を `, ` と `and` でつないだ 1 つの文字列で、位置も識別子も持たない。
+拒まれた件数は語の数から読めるが、正しいインラインを混ぜると位置が対応しない。
+
+**決定 9 の落とし先を採る。** 行やファイルを解決できないことを理由に拒まれた要求は、その要求の
+インラインをすべて本文へ退避して送り直す。1 ラウンドの指摘は多くて 10 件前後、1 件の本文は
+数百文字のため、すべてを退避しても数 KB に収まり、投稿の本文の上限（65536 文字）に対して余裕がある。
+
+### すでに決着したスレッドをもう一度決着させたときの応答
+
+**冪等である。** 決着の操作は成功し（終了コード 0）、決着済みであることを返す。失敗にならない。
+決定 5 の照合の鍵（スレッドの識別子と、すでに決着しているかどうか）が送信を止め損ねても、
+二重の決着が失敗にはならない。
+
+### 投稿者のアカウントが席ごとに違う環境があるか
 
-- **差分の外を指す指摘が拒まれるときの応答の形。** HTTP 422 が返ることは GitHub の仕様として知られている。応答の本文が行を解決できないことをどの語で示すかと、本文とインラインを同じ要求で送ったときにどちらが拒まれるかは未確認である。実装の最初の段で、偽ではない `gh` で 1 度確かめ、判定に使う語を契約へ書く
-- **拒まれた応答から、どのインラインが原因かを 1 件ずつ特定できるかどうか。** 特定できなければ、拒まれた要求のインラインをすべて本文へ退避する形へ落とす。落としたときに本文が長くなりすぎないかを、実装の段で 1 度測る
-- **決着の投稿を、すでに決着したスレッドへもう一度送ったときの応答。** 失敗にならないことを前提に置いているが、実行して確かめていない
-- **投稿者のアカウントが席ごとに違う環境があるかどうか。** いまの作業環境では 1 つだが、別の環境で担当ごとに別の認証を使う設定があると、照合の鍵の前提が変わる
+**無い。** 作業環境の `gh` は 1 アカウントだけを持ち、配布物の中に席ごとの認証を切り替える口は
+無い（`plugins/ndf/` を認証の環境変数で引くと 2 行あり、どちらも別の目的の注釈である）。
+要求の前提 1（投稿者アカウントは実質 1 つ）はそのまま成り立ち、照合の鍵に投稿者を含める形を変えない。
 
 ## 申し送り（並行する設計との境界）