6.2 KiB
6.2 KiB
| title | state | created_at | updated_at | queued_by | queued_at |
|---|---|---|---|---|---|
| セッション解析ツールを追加する | closed | 2026-06-09T03:25:33Z | 2026-06-09T07:40:53Z | workspace-panel | 2026-06-09T06:56:20Z |
背景
ドッグフーディングのセッションが十分に濃くなり、Worker / Pod の挙動を体感だけで調整するのが難しくなっている。永続化された session JSONL から安定した指標を抽出できる基盤が必要。
現時点の懸念:
- prune / compaction によってモデルが有用な文脈を失い、同じファイルを繰り返し読んでいる可能性がある。
Readの繰り返しが、必要な検証なのか、避けられる文脈喪失なのかを観測したい。Editのold_string/new_stringが大きくなり、出力トークンを不必要に増やしている可能性がある。- 広すぎる
Bash/Grep/Glob/Readの結果が history / context を膨らませている可能性がある。 - 同じファイルへの編集 churn から、非効率な workflow や tool guidance の問題を見つけたい。
まずは再利用可能な解析ライブラリとして作り、その上に CLI surface を薄く載せる。挙動を「無駄」と断定するのではなく、観測事実と suspicious pattern を報告する。
ゴール
専用 crate session-analytics を作り、session JSONL log を解析して tool / session metrics を抽出できるようにする。その後、薄い yoi session analyze CLI として公開する。
要件
ライブラリ crate
- 専用の解析 crate を追加する。例:
crates/session-analytics。 - 1つの session file を解析する再利用可能 API を提供する。将来的には複数 session の集約も可能にする。
- 例:
analyze_session(path) -> SessionReportまたは同等の API。 - 大きい session file を不必要に全読みしなくて済むよう、可能な範囲で streaming parse する。
- 例:
- TUI rendering や Pod runtime side effect から独立させる。
- 既存の session / log schema 型は適切に再利用してよいが、runtime crate が analytics に依存する形にはしない。
最初に抽出する metrics
- Tool usage summary:
- tool name / kind ごとの呼び出し回数。
- turn ごとの tool call 数。
- failed tool call 数。
- 検出可能なら、より具体的な tool があるのに
Bashで file inspection しているような broad tool usage pattern。
- File read duplication:
- file path ごとの repeated
Read。 - 同じ path + offset/limit の repeated
Read。 - repeated read の間に対象ファイルへの write/edit があったかどうか。
- 観測可能なら compaction / prune event 後の repeated read。
- file path ごとの repeated
- Edit / write churn:
- file path ごとの
Edit/Write回数。 - 同一ファイルへの repeated edit。
old_string/new_string/ edit argument 全体のおおよその byte size。- 出力トークンを増やし得る大きな replacement argument。
replace_allの使用。
- file path ごとの
- Tool result size:
- 取得可能な範囲で output bytes / lines。
- truncated / saved Bash output indicator。
- large
Read/Grep/Bash/ web result の観測。
- Context lifecycle correlation:
- session log に存在する prune / compaction 関連 event を記録する。
- その後の repeated read / tool call と相関を取る。ただし因果として断定しない。
Report model
- 後続の CLI / TUI / report rendering に使える構造化
SessionReportを定義する。 - summary total と suspicious-pattern diagnostics の両方を含める。
- 最初の安定 interface は machine-readable output を優先する。
- default report では user input / file content の raw dump を避ける。
- path、count、byte size、timestamp / turn index、必要なら hash を含める。
- raw snippet / content は default では出さず、必要なら後続で明示 opt-in にする。
CLI integration
- product binary に薄い CLI entrypoint を追加する。例:
yoi session analyze <session-jsonl-or-session-id> [--json]
- 初期版は明示 file path 指定だけでもよい。
- 後続拡張候補:
--latest--pod <name>- directory aggregation
- Markdown / human summary output
- CLI は library crate を呼び、analytics logic を重複実装しない。
意味論と制約
- repeated read を自動的に悪いものとして扱わない。
- mutation 後の再読や validation のための再読は適切な場合がある。
- 事実と bounded suspicious diagnostics として報告する。
- 通常出力で raw session content を露出しない。
- 解析は read-only にする。
- session log は記録済み tool call / history の authority として扱う。ただし context prune の因果は、明示 event がない限り相関としてしか推定できない。
非目標
- この Ticket で Worker の pruning / compaction 挙動を変更すること。
- analytics 用の full TUI dashboard を作ること。
- metrics に基づいて prompt / tool guidance を自動修正すること。
- LLM を使って session content を意味的に要約すること。
- default report で secret や raw file content を露出すること。
受け入れ条件
session-analyticscrate が存在し、tool analytics に必要な current session JSONL entry を少なくとも parse できる。- library が tool counts、repeated reads、edit/write churn、edit argument sizes、large/truncated result observations を含む structured report を返す。
yoi session analyze <path> --jsonまたは同等の CLI が machine-readable output を出す。- report は default で raw user/file content を避ける。
- tests が以下を cover する:
- intervening edit あり/なしの repeated reads。
- large edit argument sizing。
- tool failure counting。
- representative log entry がある場合の basic compaction/prune event correlation。
- malformed / unknown log entry を bounded diagnostics で扱うこと。
- focused tests、
cargo fmt --check、git diff --check、target/debug/yoi ticket doctorが通る。