既読スレッド再注入機構 — M層の「1ヶ月前のスレッド記憶喪失」解消

1. 目的

M層は route ごとに単一のローリング常駐セッション（PersistentSession）で動く。 セッションは --resume で会話継続し、トークン超過で rotate()、さらに Claude 側の自動コンパクションで文脈を圧縮する。 その結果、数週間前のスレッドの文脈は現行の生きたセッションには載っておらず、再読込もされないため、 古いスレッドに話しかけると「記憶がない」応答になる。

本設計は、CEO と合意済みの「既読スレッドリスト＋未読時のみ再読込」方式を、既存の記憶モデル（--resume / rotate / build_context_summary 注入）を壊さずに最小実装へ落とす。

2. 現状の構造（なぜ忘れるのか）

スレッド履歴の注入は現在 bot/router.py:581 の一箇所で、かつ「セッションが記憶を持っていない時だけ」行われる。

# bot/router.py L580-584（現状）
# 記憶消失時（初回・再起動・ローテーション後）のみ thread_context 注入
if not tmux._has_memory and thread_context:
    initial_prompt = _build_thread_section(thread_context) + base_prompt
else:
    initial_prompt = base_prompt        # ← 生存セッションは常にこちら

さらに bot/app.py:1452-1465 で、既にルート確定済みスレッド（cached_route）の場合の thread_context は、 Slack本文ではなくローカルの軽量 intent ログ（build_thread_context）から作られる。

3. 合意方針（これを設計に落とす）

1. 生きているM層セッションが「記憶に取り込んだ thread_ts」の軽量リストを保持する。
2. メッセージ到来時、その thread_ts がリストに無ければ、当該スレッドの Slack 履歴を読み直してM層へ注入し、リストに追加する。
3. リストはセッションが切り替わるたびにクリアする。契機は3つ:
   (1) トークン超過による rotate / (2) Claude の自動コンパクション / (3) --resume 再開・アカウント切替。
4. 「毎回読み直す」のではなく「記憶に無い時だけ読み直す」。

4. 設計詳細（論点 a〜f）

(a) 既読リストの保持場所とデータ構造

# bot/persistent_session.py __init__ (L256付近に追加)
self._known_threads: set[str] = set()

(b) 3つのクリア契機の具体的フック位置

クリア契機は「現行文脈がリセット/圧縮される瞬間」。物理的な追加はわずか2箇所で3契機を全てカバーする。 なぜなら rotate・restart・アカウント切替は全て _do_start() を通って新プロセスを spawn するため。

(c) 「記憶があるか」の判定方法

リスト照合のみで十分。タイムスタンプやトークン按分は不要。

• クリアはあらゆる文脈リセット事象の保守的な上位集合で発火する（rotate / compaction / resume / account-switch 全て）。
• 従って「既読と誤判定して実は消えている（＝記憶喪失の再発）」は原理的に起きない。消える事象では必ず先にクリアされる。
• 逆の誤り「未読と判定したが実は残っている」は、無害な二重注入（トークン微増のみ、Claude は意味的に重複を吸収）で済む。

# bot/persistent_session.py に追加するメソッド
def knows_thread(self, thread_ts: str) -> bool:
    return bool(thread_ts) and thread_ts in self._known_threads

def mark_thread_known(self, thread_ts: str) -> None:
    if thread_ts:
        self._known_threads.add(thread_ts)

(d) Slack履歴再読込の注入方法（既存ロジック再利用）

• 再読込は既存 fetch_thread_history()（bot/thread_history.py:34）をそのまま再利用。ページネーション・Bot発言のタグ除去・話者解決・文字数上限を既に実装済み。
• 注入整形は既存 _build_thread_section()（bot/router.py:413）を再利用。
• 注入サイズ上限は既存の適応制限をそのまま使う: MAX_HISTORY_CHARS=16000、メッセージ数に応じて 4000/2000 に自動縮小（thread_history.py:23-31）。新規上限は設けない。

判定と再読込の配置（採用: app.py ゲート方式）。app.py は既に Slack client/channel/bot_user_id を保持しており、そこで「生存セッションがこのスレッドを知っているか」を問い合わせて分岐する。

# bot/tmux_session.py に非生成の覗き見ヘルパを追加
def peek_session(key: str):
    return _sessions.get(key)   # 生存セッションが無ければ None

# bot/app.py cached_route 分岐（L1452-1465 を置換）
cached_route = tracker.get_thread_route(thread_ts)
if cached_route:
    route = cached_route
    sess = peek_session(cached_route)
    if sess is not None and sess.knows_thread(thread_ts):
        thread_context = ""                       # 生存セッションが既に記憶 → 従来通り --resume に委ねる
    else:
        await _ensure_bot_user_id(client)         # 既存の auth_test ロジックを共通化
        thread_context = await fetch_thread_history(
            client, channel, thread_ts,
            bot_user_id=_bot_user_id, user_resolver=resolve_user_name,
        )                                         # 未読 → Slack全文を再読込

# bot/router.py 注入ゲート（L581）を「thread_context があり かつ 未読/記憶なし」に緩和
if thread_context and (not tmux._has_memory or not tmux.knows_thread(_thread)):
    initial_prompt = _build_thread_section(thread_context) + base_prompt
else:
    initial_prompt = base_prompt

# 初回送信の直後（L635付近）で既読化
result = await tmux.send_prompt(initial_prompt, task_id=task_id, route=route, thread_ts=_thread)
if _thread:
    tmux.mark_thread_known(_thread)               # 処理済みスレッドを既読に

(e) 自動コンパクション / --resume と二重管理でバッティングしない根拠

• 既読リストは助言的な最適化フラグであり、Claude の実文脈を一切書き換えない（削除も編集もしない）。実文脈の管理は従来通り --resume と自動コンパクションが100%担う。
• リストは「Claude 文脈がリセット/圧縮される事象」と同時にクリアされるため、常に「本当に載っているスレッド」の保守的な部分集合に保たれる。
• desync の最悪ケースは (c) の通り無害な二重注入のみ。破壊的な競合（記憶の消失や context 破壊）は発生しない。
• build_context_summary による rotate 時の要約注入（router.py:592-598 / persistent_session.py:478-490）は既読リストと直交。rotate はまず _do_start でリストをクリアし、その後に要約を注入するだけで、両者は干渉しない。

(f) スレッドが溜まり続ける懸念への対処

• リストは単一セッションの寿命の間だけ増える。rotate / 自動コンパクション / resume のたびに全消去される。
• 実運用ではこれらは数時間〜のオーダーで頻発するため、リストは無限に伸びない。1セッション寿命で触れるスレッドはたかだか数十。
• フットプリントは 13 文字前後の文字列の集合で無視できる。クリアで解決するため、上限やLRU退避は不要（Thin）。将来必要なら maxlen 相当の上限を足せるが本設計では入れない。

5. 変更ファイル一覧

再利用（変更なし）: thread_history.py fetch_thread_history / router.py _build_thread_section / session_log.py build_context_summary。

6. 新データフロー（メッセージ到来時）

1. app.py: cached_route を取得。生存セッションを peek_session で覗く。
2. 既読（knows_thread=True）→ thread_context=""。従来通り --resume の連続性に委ねる（Slack 再読込しない ＝ 毎回読まない）。
3. 未読（False / セッション無し）→ fetch_thread_history で当該スレッドの Slack 全文を取得。
4. router: thread_context があり未読/記憶なしなら _build_thread_section で初期プロンプト先頭に注入。
5. router: send_prompt 実行 → 応答後 mark_thread_known(thread_ts) で既読化。
6. セッション切替（rotate / 自動コンパクション / resume / account切替）→ 既読リスト全消去 → 以後そのスレッドは再び未読扱いで読み直される（自己修復）。

7. 代替案（ブレインストーミング）

8. 設計完了チェックリスト

前提条件

• _sessions（route→PersistentSession）が生存セッションの単一保持元であること（tmux_session.py:346で確認済み）。
• rotate / restart / account切替が全て _do_start() を経由すること（persistent_session.pyで確認済み）。
• 自動コンパクション検知イベントが _log_auto_compact() に到達すること（L747-752で確認済み）。外部依存: Claude CLI が compact_boundary/system(pre_tokens) を送出し続けること。

副作用・影響範囲

• router 注入ゲートの条件を1行緩和する。従来 _has_memory=True で注入されなかった経路が、app.py が非空 thread_context を渡した時のみ注入されるようになる（app.py 側でゲート済みのため過剰注入は起きない）。
• 既読スレッドは Slack API 呼び出しを削減する（cached_route で毎回 build_thread_context を作っていたのを、既読なら空に）。パフォーマンスは改善方向。
• セキュリティ影響なし（新たな外部入力・権限拡大なし。Slack 本文は既存経路で既に取得済みの範囲）。
• 既存の記憶モデル（--resume/rotate/build_context_summary）は不変。既読リストは助言フラグで実文脈を触らない。

リスク・懸念事項

• !同一ターン rotate の順序ズレ: app.py が「未読」と判定して thread_context を用意した後、router 内でトークン超過 rotate が起きると _do_start で既読リストがクリアされる。この時は build_context_summary（全体要約）が注入され、当該スレッド全文の注入は次ターンに回る。影響は限定的で、次メッセージで自己修復（未読扱いで再読込）。厳密化が必要なら案Bへ移行。
• !コンパクションイベント非送出: Claude CLI が圧縮イベントを送らないバージョンだと (2) のクリアが漏れる。その場合でも実害は「圧縮で消えたスレッドを既読と誤認」＝記憶喪失の再発可能性。監視として _auto_compact_count のログで検知可能。将来 CLI 挙動変化時は再検証すること。

9. 実装Issueドラフト

設計のみ。実装（コード変更・コミット・PR）は含まない。実装は本 Issue 起票後、ベンダー(Web Claude) または W層 coder が担当する。