brake1 findings routed through parent

brake 1 の findings は親を経由し、PR には統合コメント1本だけが載る

Question

brake 1 の evaluator が出した findings は、どの経路で著者に届くか。評価者が PR コメントへ直接投稿して著者がそれを読むのか、親が受け取って統合し1本のコメントとして投稿するのか。

Current resolution

評価者は findings を親に返し、PR には何も書かない。親が N 件の報告を統合して PR に1コメント投稿し、そのコメントを著者が読む。 著者の裁定理由（accept / reject とその理由）は PR コメントではなく commit body に記録する。

親の取り分は統合と投稿までで、取捨選択はしない。同意しない指摘を落とすことも、順位を付けることも、指摘に回答することもしない。accept / reject は著者の権限であり、この段階で落とされた指摘はその権限を持つ主体に届かないため、禁止3件のうち drop だけが痕跡を残さない。

親から著者への修正指示の往復に回数上限は置かない。 収束判断は skills/model-loop-safety に従い、その判断を保持するのは親である。二者間ループのため、actor を明記しないと双方が相手が数えていると仮定する。この往復は evaluator を再 spawn しないため brake1-single-round-cap の単巡打ち切りには抵触しない。

findings が親のコンテキストを通ることが、監督を買う対価である。 指摘を一度も読んでいない親は、それがどう処理されたかを判断できない。

分岐ごとの durable な着地面:

分岐	着地面
accept あり	commit body（accept / reject の理由を記載）
全 reject（commit が発生しない）	著者の停止条件報告 → 親のセルフレビュー
findings なし	PR コメント自体を投稿しない

Edges

• supersedes（部分） brake-adjudication-by-resumed-author — 同 entry の Current resolution のうち「評価者は指摘を PR コメントに直接投稿し、親への戻り値は1行に絞る」という転送経路の節のみを置き換える。裁定主体（著者）・親の取り分（セルフレビューとマージ判断）・エージェント深さ1・再構成フォールバックはいずれも不変で、そちらは生きている。同 entry が置いた根拠「findings を親の文脈に通しても何も買えない」は、監督能力を買うという対価へ反転した
• depends on brake1-single-round-cap — 単巡打ち切りは evaluator ラウンドに掛かる。親→著者の修正往復は evaluator を spawn しないため cap の外側にあり、cap 自体は不変
• depends on brake1-operational-copy-target-conditional — rules/** を対象とする変更では operational copy の適用が必須であり、適用後の evaluator の injected context は新経路を載せる。この判断自身の brake 1 が新経路で走った根拠がこれ
• conflicts with （現時点で対立 entry なし）

背景

2026-08-12、Master の起点は GitHub への連続書き込みによるレート制限であり、コンテキスト経済ではなかった。実際に制限に当たっている状態で、原因は未特定のまま「とりあえず書き込みを減らす」方向の要求として出された。

調査の結果、前提は部分的に外れていた。core REST レート制限は 5000/5000 未使用、GitHub が文書化する content-generating の上限は 80/min・500/hour。brake 1 の旧形は1 PR あたり5回であり、総量では桁で届いていない。危険なのは総量ではなくバースト形状で、evaluator 3体が同一 PR へ数秒以内に並列投稿する形がそれに当たる。変更は正しいが、要求された理由とは別の理由で正しい。

途中経過の喪失も論点になった。親と著者の往復をコンテキストだけに置く設計は skills/operations-handoff-continuity の「意味のある途中経過をローカル／チャット記憶だけに置かない」に反する。ただし durable な置き場はコメントである必要がない。git push は content-generating リクエストではなくレート制限に乗らず、commit body は rules/operations/operations.md により内容を要求される既存の durable 面である。裁定理由をそこに置けば、API コストゼロで完全に durable になる。

制約

Loop Safety の射程外を承知の上で受け入れる。 同 invariant は Persistence with axis switch is outside this safeguard と明記しており、親が毎回異なる欠陥を名指し続ける限り発火しない。無制限ループの最もありそうな形が射程の外にある。それでも上限を置かないのは、毎回異なる実在の欠陥を修正している往復はループではなく収束作業であり、止めるべきものではないため。新しい cap 軸を足さず既存 invariant を指すだけに留めた。

セルフレビューは削除しない。 rules/operations/main-agent-procedures.md Self-review formal record により3モードすべてで必須であり、かつ本判断の後は brake 1 の verdict の唯一の外部化先になる（評価者が PR に書かなくなるため）。置き場も分かれており、統合コメントは Conversation タブ、セルフレビューは Reviews タブに載る。

結論

採用：評価者 → 親 → PR 統合コメント1本 → 著者 → commit body。GitHub 書き込みは1 PR あたり5回から2回（指摘なしなら1回）に減る。

却下した案：著者の accept / reject も PR に残す形（書き込み3回）。親がハブになる以上、親は修正指示のために裁定を読む必要があり、PR にも書かせると同じ内容が二度書き込まれる。却下理由が「指摘の隣」に残らなくなる損失は、セルフレビュー1本への集約で human 可視性が保たれるため受容した。

関連

• issue #1732 / PR #1733
• GitHub REST API rate limits