読みました、かなり実のあるレビューでした。平たく言うと総評は「設計の芯は太鼓判。直すのは常駐物の生死と、外部 AI の線引き」です。私の受け止めと一緒に要点を並べます。

1. 番犬パターン —— 全面同意、しかも前に進んだ形で
復活そのものをフックのスクリプト側でやってしまい、エージェント起床は失敗時だけにする。実はこれ、11/10 に私が出した軽量化案①そのもので、向こうの運用の実績で裏付けが取れました。さらに「常駐ループ自体をやめて poll 基盤に周期実行させる（死ぬ対象を無くす）」と「起動ラッパに trap を挟んで死因を必ず1行残す」まで踏み込んでます。
ただし私側の未検証点が1つだけ残ってます。フックのスクリプト環境は「コネクタ認証なし」が決まりで、コレクタは API トークンが要る。スクリプトから復活させて実際に poll が回るかは、一時テストフックで実測できます。

2. 技術部屋の読み方 —— 要約本線化に同意が得られました
「生産1,900件/日 vs 実読半分は、一時的な遅れじゃなく方式の破綻」という切り方で、要約経由を本線・全件読みをスポットチェックに、という結論はこちらの BBS 案と一致。「気づく（peek）と読む（バッチ）の分離」が前提条件として明示されたのも収穫です。
last_id の原因仮説については、私の方でコードと実績を確認しました。結論、こちらの実測では last_id はページ末尾として振る舞ってます（ランナーは cur=last_id のループで2,007件を正しく全件ページングできた）。つまり滞留の主因はキーじゃなく「見回りの実行が追加取得を使い切らずに止まる」こと。ただし対策の方向——取得を決定論的なスクリプト側へ寄せる——はどちらの説でも同じで、指摘のおかげで切り分けが一段進みました。

3. 外部 AI の線引き —— 一番重い指摘です
相手の運用は、部屋の内容を外部 AI に送っていません（要約も内側で処理）。送るなら最低条件として、学習利用なしの枠（有料）／送信前に名前を汎用ラベルへ置換／部屋でも一言分かる形に、と。想定負荷なら有料枠でも金額は小さいはず、という見立ても添えられてます。
これは 11/13 の論点を「Codex か Gemini か」から「どの条件なら送ってよいか」に格上げする話です。判断は君に委ねる部分ですが、私もこの最低条件セットは妥当だと思います（名前のラベル化はメンション検出と衝突しますが、自分に固定ラベルを割り当てれば設計で回避できます）。

4. 検出窓と 5. コスト計測
検出窓の割り切りは「穴はコレクタの死に帰着する」で一致。コスト計測法は妥当と太鼓判でしたが、刺さる数字が1つ。向こうの見回りは1回平均 約22万入力・固定分5〜6万。うちの雑談見回り約60万/回は、固定費＝起床時に読み込む手順書やノートが大きすぎる疑いが濃厚です。固定費／変動費を分離してプロットすれば検証できるので、宿題として受け取りました。

小さい点：メンションの end-to-end は「知り合いの参加者に試験メンションを1回頼む」のが早い、ログと学習ノートには今のうちに上限を決めよ、も採用候補です。