[English](../handoff-protocol.md) | 日本語

# セッション引き継ぎプロトコル

GitHub Issue を介して Claude のセッション間で長期作業を引き継ぐための
プロトコル。

## 前提

- **スコープ**: 複数セッションにまたがる、また場合によっては複数の
  インタフェース (claude.ai ↔ Claude Code) にまたがる長期作業。
- **媒体**: `session-handoff` ラベルを付与した GitHub Issue。
- **粒度**: ワークストリーム 1 つにつき Issue 1 つ。セッション 1 つに
  つき Issue 1 つではない。
- **破壊的な履歴喪失の回避**: Issue 本文は現在の状態を保持し、各
  セッションで上書きする。履歴は "Session log" という名前で固定された
  コメントに追記専用で蓄積する。

## 送信側手順 (セッション終了時)

1. 未完了の作業をコミットしてプッシュする。作業ツリーをクリーンにする
   か、汚れた状態であれば明示的に記録する。
2. `.github/ISSUE_TEMPLATE/handoff.md` の書式に従って Issue 本文を上書
   きする。
   - **Snapshot**: ブランチ + 最新コミット SHA + タイムスタンプ。
   - **Next action**: 次セッションがただちに着手できる程度の粒度。
   - **Failed approaches**: 試みて諦めたものを記録する。これを省くこと
     が労力の二重投入の最大の原因となる。
3. 今回セッションの結果を、固定された "Session log" コメントに日付付き
   の段落 1 つとして追記する。
4. 最終メッセージで Issue 番号を参照する。

## 受信側手順 (セッション開始時)

1. `session-handoff` ラベルの付いた open Issue を一覧し、該当の
   ワークストリームを特定する。
2. Issue 本文を読む。Snapshot、Next action、Failed approaches を内面化
   する。
3. Snapshot が現実と一致することを確認する。
   - `git log -1 origin/<branch>` を記録されたコミット SHA と比較する。
   - クリーンと記載されていれば作業ツリーの状態を確認する。
4. ドリフトがあれば、行動の前にユーザーに報告し (例: "Issue では
   `<sha-A>` だが origin は今 `<sha-B>` で次の変更がある: ...")、指示
   を仰ぐ。
5. ドリフトがなければ、**Next action** をユーザーに読み上げ、実行前に
   合意を得る。
6. 実行する。**Verification** フィールドに照らして検証する。続いて送信
   側手順に従って Issue を更新する。

## 昇格ルール

Issue 内の Decision が 2 回以上後続セッションで参照された場合、それを
`docs/decisions/*.md` 配下の ADR に昇格させる。Issue 本文の該当エント
リは ADR へのリンクで置き換える。これにより Issue 本文のサイズを抑え、
Issue が閉じられたときに知見が失われることを防ぐ。

## SSOT (単一の真実の源) の優先順位

情報源が矛盾した場合の優先順位:

1. `CLAUDE.md` (プロジェクト全体の不変条件)
2. `.claude/rules/` (パス範囲指定)
3. `docs/decisions/` の ADR (確定した判断)
4. 引き継ぎ Issue 本文 (現在のワークストリーム状態)

引き継ぎ Issue が最も流動的です。`CLAUDE.md` と矛盾する場合は後者が
勝ちます。

## アンチパターン

- 本文をチャットログとして扱う。履歴はコメント ― 特に固定された
  "Session log" ― に書く。
- 大きなログやコード片を本文にインライン化する。代わりに「ファイル
  パス + SHA + 行範囲」のポインタを使う。
- 具体的な Next action なしでセッションを終える。
- タイトルを更新したが本文を更新しない。
- Decision を ADR に移行しないまま Issue を閉じる ― 閉じられた Issue
  が前面に出なくなった瞬間に知見が失われる。
- claude.ai と Claude Code から同じ Issue を並行編集する。両インタ
  フェースが活動中であれば、片方を書き手、もう片方を読み手として
  指定する。

## 並列ワークストリーム

並行する複数の Issue は問題ありません。依存関係は GitHub の Issue 参照
(`#NN`) で表します。依存グラフが複雑になった場合は専用のトラッカーを
検討してください ― ただし「個人 + AI」ワークフローでは、この粒度の
GitHub Issue で通常十分です。
