[context] セッションが深いほど同じ作業をやり直す（後半 30% で 2.2 倍）

セッションが深くなるほど、エージェントが既にやった作業をやり直す率が上がる。
運用者の体感（「長いセッションほど注意散漫」）を、実際の transcript で測って確認した。

測定

~/.claude/projects の 20 万バイト超・コマンド 80 件以上の transcript 30 本。
各セッション内の位置を 10 分割し、同一コマンド文字列の再実行率を数えた。

修正後にテストを回し直すのは正当なので、検証系コマンド
（pnpm test|check|build、git status|log|diff、pytest 等）は除外している。

内訳（種類別・後半 30%）:

単純なエラー率（is_error の tool_result）はむしろ下がる（3.98% → 2.70%）。
序盤の失敗は探索（grep の空振り、ファイル無し）で想定内のものが多く、
「散漫さ」の指標としては弱い。再実行率のほうが体感に一致する。

限界

• 相関であって、注意の減衰を直接測ったものではない。
  終盤の作業は本質的に反復が多い可能性がある
• 「同一コマンド」には、状態が変わった後の正当な再確認も含まれうる
• n=30 セッション。すべて 1 人の利用者のもの

Ark にとっての含意

Ark はコンテキストの真ん中に触れない。書き込み口は SessionStart（先頭付近）と
hook / メッセージ（末尾）だけで、どちらもモデルが元からよく見ている位置である。
並べ替え・削除・再ランクは Claude Code 側の仕事。

唯一 Ark が所有しているレバーはセッションの境界であり、今回の測定はそこに
初めて根拠を与える。データ自体が「序盤は再実行率が低い」と言っており、
セッションを切り直せばその領域に戻れる。

コストは文脈を失うことだけで、それを安くするのがセッション境界を持つ Ark の役割になる。

次に測ること（実装の前に）

• 切り直した直後のセッションで、再実行率が実際に序盤の水準へ戻るか
• 何を持ち越せば切り直しのコストが割に合うか

この Issue は測定の記録であり、実装の提案ではない。
機構を作る前に .claude/rules/context-engineering.md の検査項目を通すこと
（同種の機構は 4 代作って 4 代とも撤去している）。

Start by reading .claude/rules/context-engineering.md, then review the transcript measurement and its stated limitations. The issue is complete when the proposed follow-up measurements establish whether restarting a session restores early-session rerun rates and what context should carry over; it does not currently define an implementation.