spec(session): decide whether the resume line should know which situation it is for

[smileygames]

観測

再開の線（アカウントの resume_command）は、もともとスリープ回避策として入れられた（Master 談、2026-08-29）。PC がスリープから復帰したとき webview の再読み込みで部屋が空になる経路（#108、#84）への手当てである。

resolve_launch（src-tauri/src/session.rs:369）はその由来を知らない。分岐の条件は「このトピックにこのアカウントの id が記録されているか」と「アカウントが再開の線を持つか」の二つだけで、どの状況のための線かという軸を持たない。結果、スリープ復帰のために書かれた線がアプリの再起動後の起動でもそのまま発火する。

前提が違う。スリープ復帰では CLI のプロセスが生きており、席の引き取り（#115 決定4C、#84）が繋ぎ直す経路であって --resume を要さない場合がある。再起動後はプロセスが無く、--resume が頼るのは会話が保存されていることだけである。

再現の手がかり

#127 は、その前提が崩れた場合（会話ができる前に終わった起動）の復帰を入れた。死んだ id を捨てて通常起動へ落とす形であり、発火するかどうかの軸には触れていない。この issue はそちらを扱う。

判断が要る点

• 再開の線に適用範囲を持たせるか（例: スリープ復帰時のみ／同一 run 内のみ／常時）。
• 持たせる場合、それを設定の概念として人に見せるか、アプリが状況から決めるか。設定の概念を増やすことの是非そのものが判断対象である。
• そもそも「再起動後は再開しない」を既定にするだけで足りるかもしれない。bug(session): a session id recorded on spawn poisons every later resume when the CLI never created the conversation #127 の復帰が入った後、実際にどれだけ困るかを見てから決めてよい。

急がない。#127 の実機観測を積んでから判断するのが安い。

関連

• bug(session): a session id recorded on spawn poisons every later resume when the CLI never created the conversation #127（死んだ id からの復帰。軸4 をここへ切り出した元）
• feat(history): split the history into topics, resumable from the list #115 決定3 / 決定4 / 決定4B / 決定4C
• bug(room): a refusal throws away the posts it was handed, locking the screen out of speaking #108 / fix(session): a running session becomes unmanageable after the webview reloads #84（スリープ復帰と席の引き取り）

[smileygames]

#131 で整理した。

Codex を参考にしたところ、あちらの resume は**常に「CLI が死んでいる側」**であり、生きているプロセスへ繋ぎ直す道は無い。これと Master の指摘（生きている場合と死んでいる場合を分けて考える）を突き合わせると、この issue の問い（再開の線に適用範囲を持たせるか）は形が変わる。

二つの場面ではなく、二つの別の仕組みが一つの設定欄に相乗りしている。 CLI が生きている側（スリープ復帰）は席の引き取り（#84、#115 決定4C）の担当であり、--resume を元々必要としない。再開の線が持つべき適用範囲は「CLI が死んでいる側だけ」であり、それは新しい設定の概念ではなく、#131 の事前判定（transcript が実在するか）が自然に満たす——生きている CLI を繋ぎ直す場面では、そもそも resolve_launch を通らない。

したがって設定の概念を増やす案は採らない。#131 の結果を見てから、この issue を閉じるか残すかを判断する。