throughline 0.10.2 → 0.10.5

package/docs/archive/12_desktop_clear_handoff_plan.md

@@ -0,0 +1,218 @@
+# 12 — Desktop /clear 引き継ぎ + L2 捕捉完全性 改良プラン
+
+> **履歴文書**: この計画は 2026-07-12 に実装・実測・公開まで完了した。
+> 現行契約は [../02_clear_auto_handoff_plan.md](../02_clear_auto_handoff_plan.md) を参照する。
+
+<!-- 前提: Fable級統括／実装は codex_work・composer 委譲主体（2026-07 時点） -->
+
+status: **承認済み・実装中**（2026-07-11 オーナー承認。本文書が正本＝チェックボックスが TODO を兼ねる）
+
+## 統括の型（orchestrate スキル準拠。配置は 02_models.md 決定表の引用必須 — 2026-07-11 オーナー裁定の書式）
+
+配置宣言は正典 dotagents/docs/02_models.md を開いて該当行を写す。引用なしの配置は書かない。本プランの根拠行（引用・2026-07-11 時点）:
+
+- **実装物量**（02_models.md:40）:「中位=`gpt-5.6-terra`×medium・codex_work」＋「`grok-composer-2.5-fast`＝並ぶ第一選択（仕様固定＋検証コマンド必須の委譲契約を厳守）」
+  → 波の割当: 既存ファイル編集を含む波（install/doctor/bin 配線、既存テスト更新）= codex_work（隔離 worktree）。独立新規ファイル生成の波（session-end.mjs 本体・spike ロガー・新規テストファイル）= composer も第一選択、統括が波ごとに選び理由を残す。
+- **監査・発見**（02_models.md:36）:「`sonnet`×low・Workflow で明示」「中位=`gpt-5.6-terra`×medium・codex_auditor/explore」「`grok-4.5`・grok_agent / `grok -p`（並列 finder に好適）」
+  → B-2 の保存構造棚卸しは grok 並列 finder + codex_explore の多角スイープ。
+- **反証・検証**（02_models.md:37）:「主 継承×high・refuter」→ B-1 着手前 refuter・A 設計の追加反証に適用（model 省略=主継承が許されるのは検証・反証・裁定系のみ）。
+- **裁定・契約クリティカル**（02_models.md:35）:「主 直轄（F）」→ schema v9・バトン上書き規則・捕捉契約変更・settings.json 操作・最終レビュー・コミット。着手前 refuter 1 回（ガードレール常時ON）。
+- **オーナー実機操作 = H**（Desktop/VSCode での /clear 操作・最小再現）。
+
+委譲は orchestrate スキル references/delegation-contract.md の 8 点セット（file:line 仕様・罠リスト・検証コマンド・合格条件・報告フォーマット・前提再検証義務）。委譲物は統括が diff レビュー + ゲート再実行してから採用。各 Workstream は独立に revert 可能な単位で刻み、波ごとに pathspec 明示コミット。エージェントに branch 切替・commit をさせない。
+
+## Context
+
+発端は「Claude Code Desktop の `/clear` で自動引き継ぎが発火しない」引き継ぎ書（Caveat: `claude-code-desktop-clear-sessionstart-source-startup-throughline`）。調査の過程で、発火しても**注入の中身が欠ける**別問題（L2 捕捉欠落）をオーナーの実機テストが炙り出した。オーナー裁定により両方を本スコープとする（2026-07-11）。
+
+- **A: Desktop /clear 引き継ぎ発火** — Desktop は `source:"clear"` を送らない（VSCode 2.1.207 は送る。クライアント実装差で確定、バージョン交絡は棄却済み）。SessionEnd(reason='clear') バトン方式で解決する。
+- **B: L2 捕捉の完全性** — 完了済み論理ターンの L2 欠落率: Desktop 27%・VSCode 41%（実会話の欠落例を目視確認済み）。二系統に分解:
+  - **B-1（Throughline 側で直せる）**: transcript に本文はあるのに bodies に無い欠落。原因は turn-processor が各 Stop で「最後の 1 ペア」しか保存しない設計（[src/turn-processor.mjs](../../src/turn-processor.mjs) の `getLastTurnPair` 単発保存）＝Stop 不発/空振りが永久穴になる。→ 全ターンスキャン・バックフィル型に再設計。
+  - **B-2（原因未特定・CC/Desktop 側の可能性）**: Desktop で assistant 本文が transcript にそもそも書かれない/大幅遅延する。バグか仕様か未確定。最小再現で条件特定 → upstream 報告はその後に判断（オーナー承認制）。
+
+## 調査で確定した事実（2026-07-11 実測・反証済み）
+
+### 1. `/clear` はどのクライアントでも UserPromptSubmit hook に届かない
+
+commit 75d79d7（2026-05-08「/clear writes baton」）は実運用ゼロ発火。決定的証拠は同一セッション内 /tl 対照実験 ×2:
+
+- 2026-06-28 Novel（VSCode 2.1.195）: `/tl` 06:15:38 バトン書込 → 27 秒後 `/clear`。届いていれば trigger:"clear" で上書きされるはずが、後継が消費したバトンは `baton_age_ms:26777` ＝ /tl 時点のまま。
+- 2026-07-11 Caveat（Desktop 2.1.205）: `/tl` 11:51:21 → `/clear` → 後継 65a01d22 の消費バトンは `baton_age_ms:35591` ＝同型。
+- 2026-07-11 Throughline（VSCode **2.1.207**）: `/clear` 3 連発（13:15:46 / 13:16:18 / 13:16:54）でも baton-write.log に trigger:"clear" ゼロ（/tl の 1 件のみ）。最新版でも変わらず。
+
+docs 整合: ビルトインコマンドは UserPromptSubmit（prompt 送信時）にも UserPromptExpansion（skill / custom command / mcp_prompt 展開時）にも乗らない。prompt-submit.mjs の /clear 分岐は無害な保険として残置。
+
+### 2. VSCode と Desktop の /clear 挙動差（クライアント実装差で確定）
+
+| クライアント | 実測バージョン | /clear の SessionStart | 検証方法 |
+|---|---|---|---|
+| VSCode (`entrypoint: claude-vscode`) | 2.1.195 / 2.1.199 / **2.1.207** | `source:"clear"` → auto path 発火・merged:true | inheritance-decision.log の source:"clear" 11+3 件、残存 transcript 8 件の entrypoint 実測 |
+| Desktop (`entrypoint: claude-desktop`) | 2.1.205 | `source:"startup"`。旧/新どちらの transcript にも /clear 痕跡なし。**後継セッションは /clear 時でなく初回プロンプト送信時に生成**（65a01d22: SessionStart 11:51:56.968 → 初 user prompt 11:51:57.035、/clear はその 16 秒以上前） | 2026-07-11 の Desktop 実測ペア + 当日全 Desktop セッション |
+
+バージョン交絡（2.1.200+ リグレッション説）は VSCode 2.1.207 実測で棄却。クライアント判別は hook から env `CLAUDE_CODE_ENTRYPOINT`（`claude-desktop` / `claude-vscode`）で可能。
+
+### 3. 案A（startup 時間窓フォールバック）不採用の根拠
+
+- 幽霊セッション: 2026-07-11 だけで user home直下のproject_pathのstartupが **182 件**（03:02〜12:56、最短間隔 0.001 秒、全て bodies=0）。haiku-workdir に 207 件＝headless `claude -p` も SessionStart hook を発火する。
+- 幽霊がチェーンに入ると MAX_CHAIN_DEPTH=10（[src/session-merger.mjs](../../src/session-merger.mjs):14）へ数時間で到達し resolveMergeTarget throw → ターン捕捉が恒久停止＝ここで記憶が本当に失われる。
+- source='startup' は「/clear の後継」と「並行して開いた別窓」を原理的に区別できず、稼働中セッションのレコードを relabel して記憶を split する。「bodies>0 の前任だけ選ぶ」は前任側フィルタなので無効（refuter 検証済み）。
+
+### 4. SessionEnd hook 仕様（公式 docs live fetch 2026-07-11）
+
+- SessionEnd は実在し、matcher が `reason` でフィルタ可能。reason enum: **`clear` / `resume` / `logout` / `prompt_input_exit` / `bypass_permissions_disabled` / `other`**。
+- SessionStart source enum: `startup` / `resume` / `clear` / `compact`。
+- **SessionEnd hook のデフォルト timeout は 1.5 秒**（/clear にも適用）→ per-hook timeout 明示が必須（サイレント kill によるバトン喪失対策）。
+- Desktop が /clear 時に SessionEnd(reason='clear') を実際に発火するかは**未検証**（source を誤ラベルするクライアントなので要実測）→ A Phase 1 spike。
+
+### 5. オーナーの 4 セッション連続 /clear テスト（2026-07-11 13:15-13:17, VSCode 2.1.207）
+
+チェーン 4ef0d886 → c3e4e5d8 → ea60a1c9 → 9e74467d。マージは 3 回全部成功（auto ×2 + baton ×1）だが、**テスト全体で捕捉された L2 は 1 ターンのみ**（書込 13:16:45）。clear #1 (13:15:46)・#2 (13:16:18) の注入時点で DB は空 → 空の記憶を注入 → 体感「引き継げてない」で正解。3 回目の成功は /tl ではなく捕捉が追いついたため。state ファイルの 299 bytes（usage 無し＝[src/turn-processor.mjs](../../src/turn-processor.mjs) の `!assistantTurn` 早期離脱痕跡）vs 397 bytes（フル実行）が Stop 空振りの証拠。
+
+### 6. L2 捕捉欠落の全域調査（論理ターン単位・完了ターンのみ・haiku-workdir 除外）
+
+| クライアント | セッション | 完了論理ターン | 未捕捉 | 率 |
+|---|---|---|---|---|
+| claude-desktop (2.1.205) | 13 | 133 | 36 | **27.1%** |
+| claude-vscode (2.1.199-206) | 6 | 155 | 63 | **40.6%** |
+
+- 論理ターン＝「user テキスト → 後続 assistant 断片群の最後の断片」。捕捉判定は bodies の (origin_session_id, turn_number=最終断片 index, role='assistant') 存在。
+- VSCode 側の欠落は **transcript に本文が現存する**（調査自体が transcript から読めている）＝ Throughline 側の捕捉漏れ → B-1 で修正可能。
+- 実在確認済みの欠落例: f1ad5b6f (WebAICoding) の実会話ターン #1/#3/#6 等。
+- 注意: queued メッセージ（連続 user テキスト）が論理ターンを水増しする可能性は残る＝率は上限値の目安。
+
+### 7. Desktop transcript の assistant 本文欠落（B-2・unconfirmed）
+
+本調査セッション自身（d7650b10, Desktop 2.1.205）の実測: assistant エントリ 93 件の内訳 thinking 48 / tool_use 36 / **text 9**。12:44〜13:15 の長いターンには本文断片が約 8 個あったが、transcript に着地したのは 1 個だけ、しかも発話から**約 16 分遅れ**（13:12:48）。残りは transcript・プロジェクトディレクトリ・~/.claude 全域・Desktop の local-agent-mode-sessions のどこにも grep ヒットせず＝ローカル永久欠落。短いターン（13:17 以降）の本文は着地している。バグか仕様か（正本がサーバ/アプリ側にある可能性）は未確定。
+
+---
+
+## Phase 0 — 同期・安全網・正本化（憲法1/2）
+
+- [x] git 同期状態の確認（origin/main と 0/0・stash なし・untracked `.agents/` は端末ローカル残置がオーナー裁定済み＝触らない）
+- [x] ベースラインゲート green 確認: `npm test` 549 pass / 0 fail（2026-07-11）
+- [x] 本プランを docs/12 として正本化（本文書）
+- [x] rag/01-hooks に SessionEnd reason enum を還流（[session-end-reasons.md](../../rag/01-hooks/raw/session-end-reasons.md)）、rag/INDEX.md に Finding 8 追記
+- [x] 今日の調査を caveat に記録: public `claude-code-clear-userpromptsubmit-hook`（confirmed）/ private `claude-code-desktop-assistant-transcript-jsonl`（tentative・B-2 で更新）
+- [x] 実稼働デプロイ（2026-07-12）: ローカルcheckoutをglobal install（symlink化＝リポ変更が即時反映。リリース時はregistry版へ戻す）
+
+## Workstream B-1 — 捕捉のバックフィル化（先行。A の E2E 品質の前提。挙動修正レーン＝挙動差を明文化して個別承認）
+
+- [x] **B-1 設計の着手前 refuter**: 判定「目的は正当・原設計のままでは採用不可」。修正 7 件を採用: ①群レベル dedup 必須（部分捕捉済み群への再挿入は同一発話の重複ペアを 110 件量産——実在確認: d7650b10 turn14/15。割り込みは tool_result 内に埋まり user 境界として不可視のため 1 群複数 Stop が日常）②前任 transcript path は project_path から決定的導出（state は Stop 不発前任で存在しない）③junk 代表除外（session limit 通知等）④INSERT を 1 トランザクション ⑤created_at は transcript timestamp（now は一括回収で同一 ms に潰れ L2 窓・現在地アンカーの順序が tie で不定化）⑥readTranscript に isSidechain 防御 ⑦resume 直後 transcript の実測 1 回を検証項目に追加。棄却された懸念: 注入肥大化（20 ターンキャップで構造上起きない）・SessionStart レイテンシ（58MB transcript でも 155ms）
+- [x] **turn-processor 再設計**: [src/turn-backfill.mjs](../../src/turn-backfill.mjs) 新設（全論理ターン群走査 + 群レベル dedup + junk 除外 + timestamp created_at + 単一トランザクション）、turn-processor は毎 Stop でこれを呼ぶ。回収実績は `~/.throughline/logs/backfill.log`。機能検証済み: 実 transcript × 隔離 DB で回収 12 群・冪等（2 回目 0 挿入）・部分捕捉群の重複ガード・junk 0 行・created_at 順 = 会話順 【F: 統括直轄】
+- [x] queued メッセージの扱いを明文化: 群 = 「user テキスト → 後続 assistant 断片群」なので、応答前に積まれた先行 queued user は断片 0 の群となり捕捉されない（現行 getLastTurnPair と同等の非対応。将来課題）
+- [x] session-start のマージ直後にも同じバックフィルを前任 transcript に対して実行（project path からの決定的導出を優先し、state file は Stop 不発前任のため補助）→ 「/clear 直前ターンの取りこぼし」を注入前に回収。失敗は stderr + `backfill.log` に明示し、注入は継続
+- [x] 診断ログ: バックフィルで回収したターン数を stderr ではなく `~/.throughline/logs/backfill.log` に記録（Stop / session-start 共通）
+- [x] テスト: 全ターンスキャンの単体（群レベル dedup、冪等性、junk、timestamp、sidechain、path munging）と hook subprocess（multi-turn / state 無し前任）の特性化を追加。`npm test`: 559 pass / 0 fail（2026-07-12）
+- [ ] 検証: 欠落率調査スクリプト（付録）を再実行し、新規セッションで欠落 0% を確認
+
+## Workstream A — Desktop /clear 引き継ぎ発火（SessionEnd バトン方式）
+
+### A Phase 1 — spike 実測（Desktop の SessionEnd 白黒判定）
+
+- [x] spike ロガー hook（`spike/session-end-logger.mjs`）: stdin 全 payload + `CLAUDE_CODE_ENTRYPOINT` + 受信時刻を記録 【A → codex_work `gpt-5.6-terra`×medium で実装、統括が検証 3 本再実行済み。sidecar 側 PROTOCOL_ERROR（報告 envelope の schema 不一致）が出たが成果物は worktree から採用】
+- [x] `~/.claude/settings.json` に SessionEnd を一時登録（絶対パス node + 絶対パス spike・timeout 10 明示。バックアップ: `~/.claude-settings-backup-20260711-235419.tar.gz`。撤去 = SessionEnd ブロック削除 + spike ファイル削除）【F: 統括直轄】
+- [x] 実測プロトコル 【H: オーナー操作 2026-07-12 15:00-15:10 UTC】: ①Desktop /clear（③はアプリ終了の代わりにセッション削除で実施）②放置 ③削除 ④VSCode /clear。結果:
+
+  | 操作 | SessionEnd 発火 | reason | 備考 |
+  |---|---|---|---|
+  | Desktop `/clear`（d93b0d5f） | **即時**（返答 15:05:52 → 15:05:59） | **`other`** | payload は session_id/prompt_id/reason/cwd/transcript_path のみ・判別子なし |
+  | Desktop 放置（a8ece26f） | 発火せず | — | |
+  | Desktop セッション削除（675493fb） | 発火（12 秒後） | **`other`** | payload 構造は /clear と完全同一 |
+  | VSCode `/clear`（fa43271f） | 即時 | **`clear`** | 42ms 後に後継 SessionStart(source=clear)→auto merge。仕組み自体は健全 |
+
+  副次発見: Desktop のuser home直下の幽霊セッションも SessionEnd(other) を高頻度で発火する。
+- [x] 判定: **NO-GO**。Desktop は /clear で SessionEnd を即時発火するが reason を `other` にラベルし、**セッション削除（明示的破棄）と区別不能**。reason=other でバトンを書くと削除セッションの記憶が次セッションに蘇る誤注入 + 幽霊バトン汚染。reason 不問の退行案は不採用（計画どおり）。→ A Phase 2 は実装せず停止、fallback 裁定へ
+- [x] spike 撤去: settings.json から SessionEnd 登録を削除（JSON 検証済み）、spike ファイル削除（git 履歴に残存）。実測ログ `~/.throughline/logs/session-end-spike.log` は証拠として保全
+
+### A Phase 2 — 本実装（GO の場合のみ。refuter で出た穴 4 件の対策込み）
+
+> **2026-07-12 NO-GO につき凍結**。Desktop が SessionEnd reason を正しくラベルする（または SessionStart source='clear' を送る）ようになった時点で解凍可。fallback は Phase 1 実測表とともにオーナー裁定: 案C（明文化 + /tl 運用）+ upstream 報告（証拠は二重: SessionStart source=startup 誤ラベル + SessionEnd reason=other 誤ラベル、VSCode 対照つき）。オーナー裁定 (2026-07-12): fallback 案C 採用・upstream 報告提出済み https://github.com/anthropics/claude-code/issues/76704 （修正が入れば auto path がそのまま Desktop で復活する）。
+
+- [ ] schema v9: `handoff_batons.origin` 列（`'tl' | 'clear-prompt' | 'clear-session-end'`）【F: 統括直轄】
+- [ ] バトン上書き規則: 明示 /tl は TTL 内なら自動バトンに上書きされない（明示意思 > 自動）。consumeBaton は origin を返し inheritance-decision.log に `baton_origin` 記録 【F: 統括直轄】
+- [ ] `src/session-end.mjs` 新設: reason==='clear' かつ `THROUGHLINE_DISABLE_AUTO_HANDOFF !== '1'` で writeBaton。全イベントを session-end.log に記録。import-safe run() 型 【A: 実装物量 → 02_models.md:40】
+- [ ] bin dispatch / install.mjs SC_HOOKS 追加（**per-hook timeout 明示** — 既定 1.5 秒 kill 対策）/ uninstall / doctor 表示 【A: 実装物量 → 02_models.md:40】
+- [ ] テスト: baton origin 規則・session-end subprocess・db-schema v9・install 冪等 【A: 実装物量 → 02_models.md:40 → 統括 diff レビュー + ゲート再実行】
+- [ ] TTL は /tl と同じ 1 時間（一貫性優先。短縮代替案: clear 由来のみ 5〜10 分に絞る案があったが、Desktop は後継生成が初回プロンプト時なので取りこぼしリスクと引き換え＝不採用の記録）
+
+### A Phase 3 — E2E・後始末
+
+- [x] spike hook 撤去（settings.json 復元確認）
+- [x] E2E（2026-07-12 実機・緑）: Desktop `/tl`（前任 6c58be18）→ `/clear` → 後継 e8bb5bd3 が `triggered_path:"baton"`・merged:true。`backfill.log` に `hook:"session-start" origin:6c58be18`。後継 bodies に前任の全ターン（turn 1/3/5/8、`/tl` 直前の turn 5 含む）。後継モデルが「前のセッションから記憶を引き継いだ」と自覚。→ 0.6.0 リリースへ
+- [x] `npm test` 全緑、CLAUDE.md / README / docs 更新、caveat_update で `claude-code-desktop-clear-sessionstart-source-startup-throughline` の resolution 更新（2026-07-12 更新済み）
+
+## Workstream B-2 — Desktop transcript 本文欠落の条件特定（調査のみ。実装なし）
+
+- 2026-07-12 追試 — 本調査セッション自身で欠落が継続再現（15:20 以降の本文 ~8 個中 5 個のみ着地・中間分析テキストが欠落）。短ターン（オーナーのテストセッション 4 本）は全て着地 → 「長い tool 連発ターンで欠ける」仮説と整合。保存構造棚卸しは Claude レーンで実行中（会話実データを外部枠に流さないプライバシー優先の逸脱 — 02_models.md:36 の既定から明示逸脱）。
+- [x] 最小再現・条件特定（2026-07-12）: 短ターン（1 往復）は本文が必ず着地（オーナーのテストセッション 4 本 + 過去実績）。欠落は**長い tool 連発ターンの中間テキスト**で発生し、同一セッションで 2 回ライブ再現（12:44-13:15 は本文 8 個中 1 個のみ・16 分遅延着地／15:20-15:35 は ~8 個中 5 個）。厳密な断片選択規則は Desktop 内部実装依存で外部から特定不能と判断
+- [x] 保存構造の read-only 棚卸し（Claude レーン Explore agent。会話実データを外部枠に流さないプライバシー優先の逸脱）: **Desktop の App Support ストア（LevelDB / IndexedDB / SQLite / session JSON）は会話本文を一切保持しない**。3 エンコーディング全域走査で、JSONL に実在する対照プローブすら 0 件。session JSON はメタデータのみ。→ `~/.claude/projects/*.jsonl` が唯一のローカル本文ストアで、**書かれなかった本文はサーバ側のみ＝ローカル回収経路なし**（確度: 高）
+- [x] 結論を caveat（`claude-code-desktop-assistant-transcript-jsonl`、confidence: reproduced へ更新）と本文書に記録
+- [x] **upstream 報告 #2 提出済み**（2026-07-12・オーナー承認済み）: [anthropics/claude-code#76706](https://github.com/anthropics/claude-code/issues/76706)（長い tool 連発ターンで assistant text ブロックが transcript JSONL に永久欠落・ローカル回収経路なし・VS Code は正常）
+
+## 実装しないこと
+
+- 案A startup 時間窓フォールバック / reason 不問バトン / prompt-submit の /clear 分岐削除（無害残置）
+- B-2 の「修正」実装（原因が CC 側なら Throughline では直せない。B-1 のバックフィルが Throughline 側でできる最大限）
+
+## 検証コマンド
+
+```bash
+npm test
+node bin/throughline.mjs doctor
+tail -f ~/.throughline/logs/session-end-spike.log      # A Phase 1
+tail -f ~/.throughline/logs/inheritance-decision.log   # A Phase 3 (baton_origin)
+```
+
+## 付録 — 欠落率調査スクリプト（B-1 検証用・read-only）
+
+```javascript
+// node --input-type=module < この内容 （リポジトリルートで実行）
+import { getDb } from './src/db.mjs';
+import { readTranscript } from './src/transcript-reader.mjs';
+import { existsSync, readFileSync } from 'node:fs';
+import { join } from 'node:path';
+import { homedir } from 'node:os';
+
+const db = getDb();
+const sessions = db.prepare(`
+  SELECT session_id, project_path FROM sessions
+  WHERE merged_into IS NULL AND session_id NOT LIKE 'codex:%'
+  ORDER BY updated_at DESC LIMIT 300
+`).all();
+const projRoot = join(homedir(), '.claude', 'projects');
+const tPath = (p, sid) => {
+  const f = join(projRoot, p.replace(/[\/.]/g, '-').replace(/^-?/, '-'), sid + '.jsonl');
+  return existsSync(f) ? f : null;
+};
+const logicalTurns = (turns) => {
+  const r = []; let cur = null;
+  for (let i = 0; i < turns.length; i++) {
+    if (turns[i].role === 'user') { if (cur) r.push(cur); cur = { lastAsstIdx: -1 }; }
+    else if (turns[i].role === 'assistant' && cur) cur.lastAsstIdx = i;
+  }
+  if (cur) r.push(cur);
+  return r.filter(lt => lt.lastAsstIdx >= 0);
+};
+const byClient = {};
+for (const s of sessions) {
+  if (s.project_path.includes('haiku-workdir')) continue; // 再帰ガードで捕捉しない設計
+  const tp = tPath(s.project_path, s.session_id);
+  if (!tp) continue;
+  const lts = logicalTurns(readTranscript(tp));
+  if (lts.length < 2) continue;
+  let ep = null;
+  for (const line of readFileSync(tp, 'utf8').split('\n')) {
+    try { const e = JSON.parse(line); if (e.entrypoint) { ep = e.entrypoint; break; } } catch {}
+  }
+  if (!ep) continue;
+  const cap = new Set(db.prepare(
+    `SELECT turn_number FROM bodies WHERE origin_session_id = ? AND role = 'assistant'`
+  ).all(s.session_id).map(r => r.turn_number));
+  const scanned = lts.slice(0, -1); // 最終ターンは進行中の可能性 → 除外
+  const miss = scanned.filter(lt => !cap.has(lt.lastAsstIdx)).length;
+  byClient[ep] ??= { sessions: 0, turns: 0, missing: 0 };
+  byClient[ep].sessions++; byClient[ep].turns += scanned.length; byClient[ep].missing += miss;
+}
+for (const [k, v] of Object.entries(byClient))
+  console.log(k, v, `${(100 * v.missing / v.turns).toFixed(1)}%`);
+```

package/docs/{14_observer_completed_turn_feed_plan.md → archive/14_observer_completed_turn_feed_plan.md}

@@ -38,7 +38,7 @@ MCP serverはObserverが所有する。Throughlineは既存の外部依存ゼロ
 - `src/codex-rollout-memory.mjs`は`task_complete`を解釈し、`includeInFlightTurn:false`で進行中turnを除外できる。
 - `src/codex-thread-index.mjs`はproject配下のrollout候補を解決できるが、現在の並び順はmtimeであり、feedの親選択には使わない。
 - `src/auditor-context.mjs`はread-only DB、schema v8、project、origin session、user / assistant hashによるfreshness照合を持つ。
-- Claude transcript／sessionと既存Stop hookはfirst-classのまま維持し、Observer用の「完了turn」境界は[ADR 0002](adr/0002-observer-claude-completion-receipt.md)のThroughline所有Stop receiptへ固定した。
+- Claude transcript／sessionと既存Stop hookはfirst-classのまま維持し、Observer用の「完了turn」境界は[ADR 0002](../adr/0002-observer-claude-completion-receipt.md)のThroughline所有Stop receiptへ固定した。
 - 現行DB projectionは進行中turnを含みうるため、`sessions.updated_at`、body ID、body件数をcursorにできない。
 
 ## 公開CLI
@@ -157,7 +157,7 @@ turn本文は既存auditor projectionと同様に件数、各body、総文字数
 - [x] rollbackでordinalが変わってもpair hash prefixで検出できるtestを置く。
 - [x] project配下cwdと別projectの候補分離を固定する。
 - [x] Claude transcript、Throughline DB projection、Stop hookの順序を実hostで観測し、完了turnを進行中turnから分ける正式証拠を裁定する。
-  - Claude Code 2.1.207／Haiku 4.5／plan権限で、final assistant後にStop hooksが走ることを実hostで確認した。final assistant、process exit、mtimeを証拠にせず、Throughline Stop hookがpair capture成功後に書く製品所有receiptを採用する。正本は[ADR 0002](adr/0002-observer-claude-completion-receipt.md)。
+  - Claude Code 2.1.207／Haiku 4.5／plan権限で、final assistant後にStop hooksが走ることを実hostで確認した。final assistant、process exit、mtimeを証拠にせず、Throughline Stop hookがpair capture成功後に書く製品所有receiptを採用する。正本は[ADR 0002](../adr/0002-observer-claude-completion-receipt.md)。
 - [x] Claudeのthread identity、project解決、continuation後の完了境界、再起動／resumeをfixtureと実測で固定する。
   - headless `result/end_turn`と同じ`session_id`の`--resume`、`SessionStart:resume`を確認した。backgroundは`--print`と両立せず、`claude --bg '<task>'`がjob handleを返す。`agents --json`、`logs`、`stop`で`busy/working → idle/done → stop`を回収できた。
 - [x] ClaudeとCodexの候補が同じprojectにある場合のhost switchと曖昧性を固定する。
@@ -217,7 +217,7 @@ turn本文は既存auditor projectionと同様に件数、各body、総文字数
     `observer-o1-live-fixture-adr-20260715` revision 3。可変planを参照した旧receiptは使わない。
 - [x] Claude hook、Codex capture、auditor-context、token monitorの回帰を通す。
   - 関連6 test fileを一度だけ実行し、130/130 green、失敗・skip・cancel・todo各0、807.298ms。
-    受入は[ADR 0009](adr/0009-observer-integration-regression-and-docs.md)へ固定した。
+    受入は[ADR 0009](../adr/0009-observer-integration-regression-and-docs.md)へ固定した。
 - [x] README、CLAUDE.md、docs overview、CHANGELOGを実装済み挙動に同期する。
   - commit `fb558d7`。JSON-only CLI、opaque cursor、read/wait状態、3600秒上限、host固有completed証拠、
     DB/WAL/rollout直接監視へfallbackしない境界を同期した。Control `observer-feed-20260715` revision 60で
@@ -231,10 +231,10 @@ turn本文は既存auditor projectionと同様に件数、各body、総文字数
     commit `02a809f`、focused gate 28/28成功。
   - [x] P2: Codex project resolverでPOSIX pathのcaseを保持する。
     commit `88fafaf`、focused gate 28/28成功。
-  - Phase受入Decisionは[ADR 0010](adr/0010-observer-o1-phase-acceptance.md)。
+  - Phase受入Decisionは[ADR 0010](../adr/0010-observer-o1-phase-acceptance.md)。
   - 監査修正Control `observer-feed-o1-audit-fixes-20260715`はbehavior-change revision 15、
     元Control `observer-feed-20260715`はclosure revision 78でfinalizeした。lane境界は
-    [ADR 0011](adr/0011-observer-o1-control-lane-reconciliation.md)。
+    [ADR 0011](../adr/0011-observer-o1-control-lane-reconciliation.md)。
 
 ### Phase 4: queue 19e live defect correction
 
@@ -247,7 +247,7 @@ turn本文は既存auditor projectionと同様に件数、各body、総文字数
     永続化されたことを確定するbounded barrierにだけ使う。古い同文answer、前turn、DB本文へfallbackしない。
   - markerがあるStopでdeadlineまで一致しなければ`HOOK_PROCESS_TURN_FAILED`として明示失敗し、
     completionなしへ丸めない。markerを持たない旧hostだけは既存one-shot parser契約を維持する。
-  - 正本Decisionは[ADR 0012](adr/0012-claude-stop-transcript-flush-barrier.md)。
+  - 正本Decisionは[ADR 0012](../adr/0012-claude-stop-transcript-flush-barrier.md)。
 - [x] delayed assistant append、古い同文answer＋current user-only、deadline、通常同期flushをfocused testで固定する。
   - `node --test src/turn-processor.test.mjs`: 14/14成功。
   - `node --test --test-name-pattern='process-turn subprocess' src/hook-entrypoints.test.mjs`: 2/2成功。
@@ -259,7 +259,7 @@ turn本文は既存auditor projectionと同様に件数、各body、総文字数
     私有driverでも同じ書込み瞬間の単発nonzeroを再現した。
   - completed projectionのread-only接続だけにbounded SQLite busy waitを設定する。lock解消後の同じ
     snapshotを読むか、上限超過なら従来どおりDB I/O hard failureとする。stale本文、別DB、CLI再spawnへ
-    fallbackしない。正本Decisionは[ADR 0013](adr/0013-observer-read-busy-writer-gate.md)。
+    fallbackしない。正本Decisionは[ADR 0013](../adr/0013-observer-read-busy-writer-gate.md)。
   - [x] `readCompletedPairProjection`だけに1秒のSQLite busy timeoutを設定した。別processのexclusive
     writerを200ms後に解放するfocused testは修正前15/16、修正後16/16。Observer read／wait、
     auditor、receipt、Codex hook／captureのrelated gateは78/78、構文・新規ADR lint・diff checkはgreen。

package/docs/archive/15_windows_ci_release_latency_plan.md

@@ -0,0 +1,89 @@
+# Windows CI・リリース待ち時間改修計画
+
+## 目的
+
+ThroughlineのWindows CIがLinux／macOSの約1分に対して16〜18分かかり、定型releaseを
+実用不能な長さへ押し上げている。Windows互換性matrixとowner-only ACL契約を維持したまま、
+unit testを5分以内（目標3分以内）へ短縮し、release前の同一candidateに対するCIを1回へ
+集約する。
+
+## 現状の実測
+
+GitHub Actions run `29722650046`（Windows Node 22.13.0）のTAP計測では、次の3テストが
+突出していた。TAP durationはwall timeとして加算せず、job全体の実測約18分をbaselineとする。
+
+| テスト | `duration_ms` |
+|---|---:|
+| observer feed: Claude history floor, host/thread switch, cross-host tie, and opaque cursor | 568,093 ms |
+| completed turn receipt: bounded store drops only oldest receipts | 559,807 ms |
+| completed turn receipt: noisy project cannot evict another project anchor | 436,267 ms |
+
+3テストはいずれも256件境界を作るため公開APIを257回呼び、その各mutationでWindows
+PowerShellを複数回起動してdirectory／lock／temporary／final storeのACLを検証している。
+境界計算の反復とACL実機検証が結合されていることが主因で、runner一般の遅さではない。
+
+また現行workflowはmainへのpushごとに9 matrixを新規起動し、同じbranchの旧runをcancelしない。
+短時間の段階commitでWindows 18分runが重複する。
+
+## 決定
+
+1. completed-turn receiptの大量境界テストは、正規schemaの境界直前storeをfixtureとして用意し、
+   最後の1 mutationだけ公開APIで実行する。limit超過、history floor、project分離、cursor判定の
+   受入条件は変更しない。
+2. Windows owner-only ACLは専用integration testでdirectory、SQLite lock、final storeを
+   `windows-acl-test-helper`から外部検証する。大量境界テストからPowerShell反復を除いても、
+   production ACL契約の実機coverageを失わない。
+3. CIのunit test stepへ`timeout-minutes: 8`を設定する。SLOは5分、目標3分としrunner遅延と分離する。
+4. workflowへevent／ref単位の`concurrency`を設定し、新しいcommitが来た時は同一event／refの
+   古いrunだけをcancelする。手動runとpush／PRは相互cancelしない。
+5. OS 3種 × Node `22.13.0`／`22.x`／`24.x`の9 matrixは維持する。互換範囲を速度対策のために
+   縮小しない。
+6. `0.8.7`の最終candidateへ実装・version・CHANGELOG・README・正本文書をまとめ、push後CIを
+   1回だけrelease gateとして使う。公開後のSHA／CI番号はGitHub Releaseを正本とし、証拠追記だけの
+   追加commit／追加CIを作らない。
+
+## 非目標
+
+- Windows ACLの適用・read-back検証、atomic rename、失敗時の旧store保持を弱めない。
+- Windows testをskipしない。matrixのOS／Node versionを減らさない。
+- completed-turn receiptの256件limit、history floor、cursor、project分離契約を変えない。
+- Claude hooks、Codex adapter、DB migration、handoff契約を変更しない。
+- release自動publishやcredential保管をworkflowへ追加しない。
+
+## 既知の罠
+
+- fixtureを直接書くだけでは公開APIの境界mutationを検証できない。必ずlimit直前から最後の1件を
+  `writeCompletedTurnReceipt`で追加する。
+- Windowsでfixtureを書き換える時も既存owner-only ACLを保持し、専用ACL testはproduction APIが
+  作った実pathを外部helperで検査する。
+- `concurrency.cancel-in-progress`は別branch／別PRをcancelしないref単位にする。
+- test timeoutはunit test stepへ8分で置き、5分SLOにrunner一時遅延の余白を持たせる。
+- 進行中の旧CIを新しいcandidateの成功証拠として流用しない。
+
+## 受入条件
+
+- [ ] 3つの大量境界テストが公開契約を維持したままPowerShell反復を行わない。
+- [ ] Windows専用ACL testがdirectory／lock／storeのowner-only ACLを外部検証する。
+- [ ] focused testとfull `npm test`がgreen。
+- [ ] CI定義にunit test 8分上限とevent／ref単位concurrencyがある。
+- [ ] 最終GitHub Actionsで9/9 green、Windows各jobのunit testが5分以内（目標3分以内）。
+- [ ] `npm pack --dry-run --json`で公開物を確認する。
+- [ ] npm `throughline@0.8.7`、tag／GitHub Release、registry由来global install、
+  `throughline --version = 0.8.7`、配置skill／hooks／doctorを確認する。
+
+## 敵対的検証の反映
+
+read-only refuterはP0なし、P1を4件報告した。TAP durationをwall timeとして加算しないこと、
+temporary ACL失敗時の旧store保持testを加えること、concurrencyへ`event_name`を含めること、
+5分SLOとtimeoutを分離することを採用した。fixture seedと本体の重複ACL検証削減は、最後の公開API
+mutation、native final-path ACL test、atomic failure testを同時に置く条件で妥当と裁定した。
+
+## 工程
+
+工程状態と完了証拠の正本はLattice storeとし、この文書は目的、判断、非目標、受入条件を所有する。
+
+1. ベースライン計測と原因同定
+2. 敵対的検証と設計裁定
+3. 安全網とfixture分離
+4. workflow・文書統合
+5. push後CI、npm公開、global install

package/docs/archive/16_readonly_handoff_context_plan.md

@@ -0,0 +1,40 @@
+# Read-only handoff context
+
+## 目的
+
+通常 handoff が使う `buildBudgetedResumeContext` の出力を、DB 所有権を変えずにローカルプログラムが
+取得できる read-only CLI として公開する。最初の consumer は AIterm の portable fork だが、I/F は
+特定 consumer や harness に依存させない。
+
+実行 ToDo、依存、状態、完了証拠の正本は Lattice plan `readonly-handoff-context` とする。
+
+## 完了
+
+2026-08-04に`throughline@0.9.0`としてnpm、tag、GitHub Release、global installまで公開した。
+focused契約testと全回帰は729 pass／1 skip／0 fail。AIterm v0.23.0の代表cross-harness smokeでは
+Codex source memoryをClaudeへ注入し、前後でsource session、`sessions.merged_into`、L1/L2/L3 row所属が
+完全一致することを確認した。公開後の現行ドキュメント全域監査は、Latticeの終端ToDoを再openして
+README、作業者入口、配布Codex skill、docs索引、計画、CHANGELOGへ同期した。変更Markdownの
+相対リンク監査とCLI help／handoff-contextのfocused test 5/5を通過した。
+
+## 契約
+
+- `throughline handoff-context --session <id> --json` は session を明示必須とする。
+- 既存 DB を `DatabaseSync(..., { readOnly: true })` で開き、作成・migration・書込みをしない。
+- `buildBudgetedResumeContext(db, { sessionId, isInheritance: true })` をそのまま使う。
+- 成功 JSON は schema、status、sessionId、context だけを返す。renderer 統計は公開しない。
+- 引数不正、DB open 失敗、context 不在は非 0 終了とする。
+
+## 非目標
+
+- baton、pending handoff、merge、backfill、通常 SessionStart / UserPromptSubmit の変更。
+- Observer projection、Codex 専用 renderer、latest session 推測、project/cwd 照合。
+- DB schema 全面診断、hash、cursor、暗号化、daemon、network I/O、retry、cache。
+- budget や `excludeOriginId` を CLI option として公開すること。
+
+## 受入条件
+
+- CLI の context が同じ DB に対する既存 budgeted renderer の出力と完全一致する。
+- 実行前後で `sessions.merged_into` と L1/L2/L3 の `session_id` が変わらない。
+- DB 不在時に DB や親ディレクトリを作らない。
+- focused test と全回帰が成功し、公開 package と global install から新 command を実行できる。

package/docs/archive/README.md

@@ -1,22 +1,35 @@
 # docs/archive/
 
-このフォルダの内容は **歴史的資料**。現行実装を説明していない。
+ここは完了済み計画、置換済み設計、過去の実装・受入記録の保管場所である。
+現行仕様の入口ではなく、通常作業では読まない。現行文書は
+[docs overview](../00_overview.md) から辿る。
 
-現行の設計仕様は一つ上のディレクトリの [01_l1_l2_l3_redesign.md](../01_l1_l2_l3_redesign.md) を参照。
+## 完了済み計画・実装記録
 
-## このフォルダにあるもの
+| 文書 | 履歴として残す内容 |
+|---|---|
+| [02_clear_auto_handoff_plan.md](02_clear_auto_handoff_plan.md) | v0.4系のauto-handoff実装計画と当時のTODO |
+| [03_inheritance_on_clear_only.md](03_inheritance_on_clear_only.md) | 2026-04 時点の handoff 方式検証 |
+| [07_codex_trim_implementation_plan.md](07_codex_trim_implementation_plan.md) | Claude/Codex両対応とrollback trimの旧統合計画 |
+| [10_transcript_injection_plan.md](10_transcript_injection_plan.md) | transcript injection経路の実機検証 |
+| [11_codex_monitor_implementation_plan.md](11_codex_monitor_implementation_plan.md) | Codex monitor実装記録 |
+| [12_desktop_clear_handoff_plan.md](12_desktop_clear_handoff_plan.md) | Desktop `/clear` の実測、NO-GO判断、L2 backfill実装・受入 |
+| [13_native_factory_diagnostics_plan.md](13_native_factory_diagnostics_plan.md) | native factory diagnostics実装記録 |
+| [14_observer_completed_turn_feed_plan.md](14_observer_completed_turn_feed_plan.md) | Observer completed-turn feedの設計・受入 |
+| [15_windows_ci_release_latency_plan.md](15_windows_ci_release_latency_plan.md) | Windows CI latency修理・受入 |
+| [16_readonly_handoff_context_plan.md](16_readonly_handoff_context_plan.md) | read-only handoff-context v0.9.0設計・受入 |
+| [BUGHUB_RUNTIME_ERROR_STORE_PLAN.md](BUGHUB_RUNTIME_ERROR_STORE_PLAN.md) | local runtime error store実装計画 |
+| [plan_grok-successor-launch.md](plan_grok-successor-launch.md) | Grok successor launch v0.10.0設計・受入 |
+| [room-log_throughline_20260830-155052.md](room-log_throughline_20260830-155052.md) | Grok successor launch時のPeertable円卓ログ |
 
-| ファイル | 当時の位置づけ | 現在 |
-|---|---|---|
-| CONCEPT.md | Throughline の初期コンセプト文書。L2 = 判断 (judgment) 抽出という構造化方式を想定していた | schema v4 で judgments テーブル廃止、L2 は「会話本文そのまま」に再定義。本文書の L2 節以降は実装と乖離している |
-| EXPERIMENT.md | `/clear` 跨ぎで旧/新 session_id を紐づけるための命題 A〜X と実機検証の記録 | 結論として記憶張り替え方式 (merged_into + origin_session_id) が採用され、本実験結果は歴史記録としてのみ価値がある |
-| SESSION_LINKING_DESIGN.md | 命題 X（ファイルベース紐付け）の実装設計書。時間窓＋ state ファイル方式 | 同上。最終的に記憶張り替え方式に置き換えられ、spike コードも破棄済み |
-| THROUGHLINE_NEXT_STEPS.md | 2026-04-17、npm publish 直前の優先順位メモ（publish 済ませろ / awesome-claude-code 登録 / HN 投稿）| npm publish は v0.1.0 〜 v0.3.x まで複数回実施、awesome-claude-code は未提出。現在の未完タスクは [../04_public_release_plan.md](../04_public_release_plan.md) に集約 |
+## 置換済みの初期資料
 
-## なぜアーカイブするか
+| 文書 | 履歴として残す内容 |
+|---|---|
+| [CONCEPT.md](CONCEPT.md) | judgments tableを想定した初期コンセプト |
+| [EXPERIMENT.md](EXPERIMENT.md) | `/clear` 跨ぎのsession linking実験 |
+| [SESSION_LINKING_DESIGN.md](SESSION_LINKING_DESIGN.md) | 置換済みのファイルベース紐付け設計 |
+| [THROUGHLINE_NEXT_STEPS.md](THROUGHLINE_NEXT_STEPS.md) | v0.1.0公開前の優先順位メモ |
 
-- コンセプトの根幹（3 層メモリ、SQLite 退避、/clear-safe）は生きている
-- 具体的なスキーマ、層の中身、フック構成はすべて実装中に改訂された
-- 最新の正と歴史が同じフォルダに並ぶと読み手が混乱する
-
-新規に仕様を読む場合は必ず [../01_l1_l2_l3_redesign.md](../01_l1_l2_l3_redesign.md) から始めること。
+履歴から得た現行判断は、README、CLAUDE.md、現行docs、ADRへ統合する。
+archive文書を更新して現行契約へ戻さない。

package/docs/archive/plan_grok-successor-launch.md

@@ -0,0 +1,99 @@
+# Grok successor launch — Throughline 所有の最小起動
+
+Date: 2026-08-17
+Status: Accepted（v0.10.0）
+Lattice plan: `grok-successor-launch`
+対象 repo: Throughline だけ。aiterm は依存にも実装の借り先にもしない。
+
+t1-contract（2026-08-17）で起動核の CLI名・初手文面・非目標・受入を固定した。
+以降の工程は本ファイルと [ADR 0021](../adr/0021-grok-host-capture.md) の現在地を正とする。
+
+2026-08-17 実機: Dotagents 棚の `grok:01a00ff1-3f97-70e2-ba76-5acd90561a84` で
+`handoff-context` が `ready` のあと `/tl`。後継
+`~/.grok/sessions/%2FUsers%2Fkite%2FDeveloper%2Fdotagents/c01a2689-5b4f-4977-97ce-f73fcf317f94/`
+が立ち、初手末尾は待機行、モデルは仕事を始めず待った。源の `merged_into` 空席
+（`01a00b38`、L2 0 件）では spawn しない。
+
+## 目的
+
+Grok Desktop の UserPromptSubmit はモデルへ本文を渡せない。`/tl` のあと人が新窓を開いても記憶は載らない。代わりに Throughline 自身が、handoff-context を**最初の user 文の前**に置いた普通の Grok 席を一本立てる。
+
+## 非目標
+
+次は成功条件にも実装手段にもしない。
+
+- aiterm / tmux / PTY 完了待ち / `role=subagent` を Throughline に持ち込む
+- `grok` 起動に `--rules` を付ける（dashboard の top-level から外れる）
+- `--system-prompt-override` / `--agent` で初手 user 文を代替する
+- Claude / Codex の `/tl` 契約を変える
+- UserPromptSubmit stdout や `chat_history.jsonl` への再注入で Desktop 新窓を直す
+- 実装キャンペーン中の Spotter 作業（npm 公開は製品完遂であり禁止ではない）
+
+## 固定契約
+
+### CLI
+
+名前と引数は次に固定する。
+
+```
+throughline grok-continue --session <id>
+```
+
+- `<id>` は Throughline の session id であり、Grok 由来なら `grok:` 接頭辞を含む。
+- 既存の `handoff-context --session` と同じ flag 名を使う。`--from` は採用しない。
+- この CLI は `handoff-context --session <id> --json` を読む。`status` が `ready` でない、終了が非 0、または context が空なら **spawn しない**。fallback 禁止。
+- JSON envelope（`schema` / `status` / `sessionId`）は初手文へ載せない。載せるのは `context` 文字列だけ。
+
+### spawn
+
+- 源セッション（`--session` の Throughline 行）の `project_path` で立てる。呼び出し元の cwd は使わない。`project_path` が無い・読めない・ディレクトリが無いときは spawn しない。
+- 共有 `GROK_HOME`（上書きしない）のまま `grok` を人の席として立てる。
+- 起動は対話セッションである。`-p` / `--prompt` / `--prompt-file` / `--prompt-json` の単発終了経路は使わない。
+- 初手は `grok` の位置引数 `[PROMPT]` に渡す。`--rules` は付けない。
+- hook から呼ぶので対話 TTY は無い。macOS では新しい Terminal 窓で grok を前面に出す。立てた session id が分かれば標準出力にも出す（`grok --resume` できるようにする）。両方できることが受入の強い形である。
+
+### 初手文面
+
+初手 user 文は次の 4 段だけとする。前後の飾り文を足さない。`{context}` は handoff-context が返した `context` 文字列そのもの。末尾の待機が無いと、要約を新しい仕事の着手と誤る。
+
+```
+この発言は直前 Throughline 席の履歴を前提とする。
+
+{context}
+
+直前の作業の自然な続きとして応答すること。
+
+この後ユーザーが指示を出す。何もせず待機すること。
+```
+
+### `/tl` 配線
+
+- Grok envelope の `/tl` 成功後に、上記 CLI を副作用で起動する。baton は今どおり書く。
+- Claude / Codex ではこの CLI を起動しない。
+
+### 一覧
+
+- 新席は `~/.grok/sessions/<encodeURIComponent(cwd)>/<id>/` にトップレベルとして残る。
+- aiterm の Inactive/subagent 隠しを再現しない。
+- Desktop roster が別プロセスを Inactive に畳むのは Grok 側の仕様。受入は session ディレクトリと `grok --resume` 一覧を正とする。
+
+## 受入
+
+### focused（t2 / t3）
+
+- `handoff-context` 失敗では `grok` を spawn しない。
+- 初手文面は上の 4 段で、2 段目に `context` 文字列がそのまま含まれ、末尾が待機である。
+- spawn argv に `--rules` が無い。
+- spawn 経路に aiterm / tmux / `role=subagent` が無い。
+- Grok 以外の `/tl` では `grok-continue` を呼ばない。
+
+### 実機（t4 / t5）
+
+- この Mac の Grok `/tl` から新席が立ち、session ディレクトリに載る。
+- `grok --resume` 一覧にトップレベルとして見える。Desktop Inactive 畳みは成功条件にしない。
+- その席の最初のモデル応答が前文の記憶を使う。宣言または L2 固有事実が出ること。
+- `chat_history.jsonl` への後書きや hook stdout を成功に数えない。
+
+## 円卓
+
+工程正本は Lattice plan `grok-successor-launch`。実装は Throughline のみ。