ticket: record tool analytics followups

.yoi/tickets/20260609-082209-001/item.md

@@ -0,0 +1,147 @@
+---
+title: 'Profile feature flagsでtool surfaceを制御する'
+state: 'planning'
+created_at: '2026-06-09T08:22:09Z'
+updated_at: '2026-06-09T08:22:09Z'
+assignee: null
+---
+
+## 背景
+
+最近追加した Ticket tools、Ticket orchestration tools、Pod orchestration tools などにより、Pod に渡される tool schema が増えている。すべての role にすべての tools を渡すと、コンテキストを圧迫し、tool choice の性能低下や role 外行動を誘発する。
+
+現状は core tools、Task tools、Ticket tools、Pod orchestration tools などがかなり広く登録されており、role/profile から feature 単位で tool surface を選ぶ設定がない。
+
+Coder は Ticket 管理や orchestration をしないなら、それらの tools を見るべきではない。SpawnPod などの Pod orchestration tools も、明示的に与えられた role/profile だけが使える optional capability にするべき。
+
+## ゴール
+
+Lua Profile / resolved Manifest に feature 単位の tool selection を導入し、role ごとに不要な high-level tools を登録しないようにする。
+
+## 要件
+
+### Profile syntax
+
+- Lua Profile に `feature.<name>.enabled` を追加する。
+- object の存在確認ではなく、明示 bool を見る。
+  - `feature.ticket = {}` が true 扱いになるような挙動は避ける。
+  - `enabled = true` / `enabled = false` を authority とする。
+- まず対応する feature groups:
+  - `task`
+  - `ticket`
+  - `ticket_orchestration`
+  - `pods`
+  - `memory`
+  - `web`
+- resolved Manifest では各 feature の enabled が concrete bool になるようにする。
+- Profile source layer では optional でもよいが、project role profiles は明示的に設定する。
+
+### Feature group semantics
+
+- `feature.task`:
+  - `TaskCreate`
+  - `TaskUpdate`
+  - `TaskGet`
+  - `TaskList`
+- `feature.ticket`:
+  - Ticket の基本 lifecycle / review / state / close / doctor tools。
+  - access level が必要なら `access` を追加する。
+    - 候補: `read_only`, `intake`, `reviewer`, `lifecycle`。
+- `feature.ticket_orchestration`:
+  - Ticket relation / orchestration plan 系 tools。
+  - 例: `TicketRelationRecord`, `TicketRelationQuery`, `TicketOrchestrationPlanRecord`, `TicketOrchestrationPlanQuery`。
+  - Orchestrator 専用に近い。
+- `feature.pods`:
+  - Pod orchestration / communication tools。
+  - 例: `SpawnPod`, `SendToPod`, `ReadPodOutput`, `StopPod`, `ListPods`, `RestorePod`, `SendToPeerPod`。
+  - disabled の場合は tool schema に出さない。
+- `feature.memory`:
+  - Memory / Knowledge tools。
+  - access level が必要なら後続または同 Ticket 内で `read_only` / `write` を検討する。
+- `feature.web`:
+  - `WebSearch`, `WebFetch`。
+  - existing web provider config と連動する。
+  - `feature.web.enabled=false` なら tools を登録しない。
+  - provider config が不足している場合は、enabled でも existing fail-closed behavior を維持してよい。
+
+### Core tools
+
+- この feature grouping には core filesystem / shell tools を含めない。
+  - `Read`
+  - `Write`
+  - `Edit`
+  - `Glob`
+  - `Grep`
+  - `Bash`
+- これらは workspace scope / tool permission policy の制御対象として扱う。
+- `Bash` は将来的に別途 opt-in/tool permission refinement の対象になり得るが、この Ticket の first pass には含めない。
+
+### Registration behavior
+
+- disabled feature の tools は Worker に登録しない。
+- permission deny で失敗させるのではなく、tool schema から消す。
+- feature disabled によって normal prompt guidance も可能な範囲でその tool group を前提にしない。
+- FeatureRegistry / controller の無条件 registration を profile/resolved manifest に基づく conditional registration に変更する。
+
+### Role defaults
+
+Project role profiles should set feature defaults explicitly.
+
+- Orchestrator:
+  - `ticket = enabled`, lifecycle access
+  - `ticket_orchestration = enabled`
+  - `pods = enabled`
+  - `task = disabled` unless explicitly justified
+  - `memory = enabled` preferably read/query oriented
+  - `web = enabled` if configured
+- Intake:
+  - `ticket = enabled`, intake-oriented access
+  - `ticket_orchestration = disabled`
+  - `pods = disabled`
+  - `task = disabled`
+  - `memory = enabled` preferably read/query oriented
+  - `web = enabled` if configured
+- Coder:
+  - `ticket = disabled` by default
+  - `ticket_orchestration = disabled`
+  - `pods = disabled`
+  - `task = disabled`
+  - `memory = enabled` only if desired for read/query context
+  - `web = enabled` if configured
+- Reviewer:
+  - `ticket = disabled` or reviewer/read-only access depending on chosen review-report flow
+  - `ticket_orchestration = disabled`
+  - `pods = disabled`
+  - `task = disabled`
+- Companion:
+  - `ticket = read_only` if useful
+  - `ticket_orchestration = disabled`
+  - `pods = disabled` unless a specific Companion Pod-management UI/tool role is designed
+  - `task = disabled`
+
+### Access granularity
+
+- If `ticket.enabled=true` is too broad, implement or design `feature.ticket.access` in the same change.
+- Existing `TicketFeatureAccess::ReadOnly` / `Lifecycle` should be reused or extended rather than ignored.
+- `ticket_orchestration` should be separable from basic Ticket read/show/list tools.
+
+## 非目標
+
+- Redesigning core filesystem tools.
+- Removing permission policy.
+- Implementing user approval/ask flow.
+- Making feature object existence imply enabled.
+- Adding a plugin system beyond existing feature registry.
+- Changing the semantics of individual Ticket/Pod tools beyond whether they are registered.
+
+## 受け入れ条件
+
+- Lua Profiles can explicitly set `feature.<name>.enabled` for the six initial feature groups.
+- Resolved Manifest has concrete feature enablement values.
+- Disabled features do not register their tools and therefore do not appear in tool schemas or greetings.
+- Project role profiles set explicit feature defaults.
+- Coder profile does not expose Ticket management, Ticket orchestration, Task, or Pod orchestration tools by default.
+- Orchestrator profile exposes Ticket lifecycle, Ticket orchestration, and Pod orchestration tools as intended.
+- Web tools are omitted when `feature.web.enabled=false` and still fail closed when enabled but provider config is insufficient.
+- Tests cover tool definition lists for at least Orchestrator, Coder, Intake, Reviewer, and Companion profiles.
+- Focused tests, `cargo fmt --check`, `git diff --check`, and `target/debug/yoi ticket doctor` pass.

.yoi/tickets/20260609-082209-001/thread.md

@@ -0,0 +1,7 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-09T08:22:09Z -->
+
+## 作成
+
+LocalTicketBackend によって作成されました。
+
+---

.yoi/tickets/20260609-084725-001/item.md

@@ -0,0 +1,85 @@
+---
+title: 'Improve workspace panel display and composer key handling'
+state: 'ready'
+created_at: '2026-06-09T08:47:25Z'
+updated_at: '2026-06-09T09:50:15Z'
+assignee: null
+readiness: 'implementation_ready'
+risk_flags: ['tui-input', 'ux-consistency']
+action_required: 'User has confirmed Tab replaces Ctrl+T for Panel target switching, with composer completion taking priority if present.'
+attention_required: 'Keep Panel composer editing behavior shared with the normal chat composer rather than adding divergent ad-hoc key handling.'
+---
+
+## Background
+
+`yoi panel` のトップ行と actionbar に `Ctrl+T` の操作ヒントが表示されているが、Panel 表示として目立たせる必要が薄く、情報密度も上げている。
+
+また、Panel composer の入力操作が通常のチャット UI / event view TUI composer と一部異なっている。観測された例として、`Ctrl+Left` / `Ctrl+Right` による単語単位カーソル移動が Panel composer では効かない。現在は `InputBuffer` など低レベルの composer 実装は共有されている一方、key handling dispatcher は通常チャット UI と Panel で分かれており、Panel 側が composer editing keymap を十分に共有していない。
+
+Panel は workspace / Ticket 操作の入口である一方、composer は通常の TUI 入力欄として期待されるため、表示と操作の両方を整理する。
+
+## Requirements
+
+- Panel のトップ行から `Ctrl+T` 表示を削除する。
+- Panel の actionbar / help text から `Ctrl+T` 表示を削除する。
+- Panel の target switching 操作を `Ctrl+T` から `Tab` に変更する。
+- `Tab` の優先順位は composer completion がある場合は completion を優先し、completion がない Panel 状態では target switching として扱う。
+- Panel composer の編集操作は、通常チャット UI composer と可能な限り互換にする。
+- Panel 側で composer 操作を再実装して乖離を増やすのではなく、既存 composer 入力処理・keymap・action model を共有または抽象化し、互換性を維持しやすい構造にする。
+- bare letter shortcuts を復活させない。通常の文字入力は composer text として扱う既存方針を維持する。
+
+## Acceptance criteria
+
+- `yoi panel` のトップ行に `Ctrl+T` が表示されない。
+- Panel の actionbar / help text に `Ctrl+T` が表示されない。
+- Panel で `Tab` により target switching ができる。
+- Panel に completion popup / completion state がある場合、`Tab` は target switching より completion 操作を優先する。
+- Panel composer で、通常チャット UI composer と同等の主要編集操作が動作する。
+  - 例: 左右移動、行頭/行末移動、削除、履歴操作、`Ctrl+Left` / `Ctrl+Right` 等の単語単位移動。
+- terminal / backend が特定 key sequence を送らない場合は、その制約を壊れた実装と誤認しない範囲で扱う。
+- Panel 専用の ad-hoc composer key handling が増えず、通常 composer との互換性を保ちやすい実装になっている。
+- `nix build .#yoi` が通る。
+
+## Binding decisions / invariants
+
+- `Ctrl+T` を Panel の表示要素や target switching 操作として使わない。
+- Panel の target switching shortcut は `Tab` とする。
+- `Tab` は completion が active な場合、target switching ではなく completion 操作を優先する。
+- Composer に入力可能な通常文字キーを Panel 操作用 shortcut として奪わない。
+- bare `j` / `k` / `o` / `r` のような bare letter shortcuts は復活させない。
+- Panel composer は通常チャット UI composer と別物として再実装しない。既存 composer 操作との互換性を保つ方向で実装する。
+
+## Implementation latitude
+
+- composer 操作の共有方法は実装者が選んでよい。
+  - 例: composer input handling の共通関数化。
+  - 例: key event normalization の共有。
+  - 例: Panel 側を既存 composer action model に寄せる。
+- Panel 固有操作は、共通 composer editing layer の上に別レイヤーとして載せてよい。
+- トップ行は `Ctrl+T` 削除に加えて、workspace / Ticket / role Pod 状態の表示を整理してよい。ただしこの Ticket の主目的は大規模な Panel redesign ではない。
+
+## Readiness
+
+- readiness: implementation_ready
+- risk_flags: [tui-input, ux-consistency]
+
+## Escalation conditions
+
+- `Tab` が terminal focus、既存 TUI 操作、accessibility 上の期待、または将来の Panel completion と衝突する場合は、completion 優先の方針を保ったうえで相談する。
+- 通常チャット UI composer 側にも同じ操作欠落がある場合は、Panel 固有修正ではなく composer 共通改善として扱う。
+- key event が terminal / crossterm 側で区別できない場合は、可能な範囲と制約を implementation report に明記する。
+
+## Validation
+
+- `yoi panel` を起動し、トップ行と actionbar に `Ctrl+T` が出ないことを確認する。
+- `Tab` で Panel target switching ができることを確認する。
+- completion が active な状態を実装が持つ場合、`Tab` が completion を優先することを確認する。
+- Panel composer で通常チャット UI composer と同等の主要 key 操作を手動確認する。
+- `nix build .#yoi` を実行する。
+
+## Related work
+
+- `20260606-060548-001` Workspace panel layout and display tuning
+- `20260607-213808-001` Remove bare letter shortcuts from workspace panel
+- `20260607-001651-002` Workspace panel Companion interface
+- `20260601-021104-001` TUI: persist composer input recall history per workspace

.yoi/tickets/20260609-084725-001/thread.md

@@ -0,0 +1,152 @@
+<!-- event: create author: intake at: 2026-06-09T08:47:25Z -->
+
+## 作成
+
+LocalTicketBackend によって作成されました。
+
+---
+
+<!-- event: intake_summary author: intake at: 2026-06-09T08:47:33Z -->
+
+## Intake summary
+
+Panel 表示・操作改善 Ticket を作成した。`Ctrl+T` はトップ行/actionbar/help text から削除し、target switching は `Tab` に変更する。`Tab` は completion が active な場合 completion を優先し、completion がない Panel 状態では target switching として扱う。Panel composer は通常チャット UI composer と低レベル `InputBuffer` は共有しているが key handling が分岐しているため、Panel 専用の ad-hoc 実装を増やさず、composer editing keymap/action model を共有または抽象化して互換性を維持する。
+
+---
+
+<!-- event: state_changed author: intake at: 2026-06-09T08:47:33Z from: planning to: ready reason: intake_ready field: state -->
+
+## State changed
+
+要件・binding decisions・受け入れ条件が揃ったため、Orchestrator が routing できる ready 状態にする。
+
+---
+
+<!-- event: decision author: intake at: 2026-06-09T08:54:26Z -->
+
+## Decision
+
+## Refinement: composer status line and mixed operation model
+
+User clarified an additional UX issue in the Panel composer area:
+
+- The line above the composer currently showing text like `composer Companion · ticket ready · Edit` is redundant and does not make the available action clear.
+- Panel currently mixes two interaction models in the same visual/control area:
+  - when the composer is empty, row selection with Up/Down plus Enter dispatches the selected Ticket action/open behavior;
+  - when the composer has text, Enter sends the text to the selected composer target, either Companion or new Ticket Intake.
+- The implementation should make this separation visible and understandable instead of presenting row action state and composer target/edit state as one ambiguous status line.
+
+Additional requirements:
+
+- Rework the composer-adjacent status line so it does not redundantly restate `composer`, target name, Ticket state, and `Edit` without explaining the action.
+- Clearly distinguish selected-row action context from text-composer target context.
+- The UI should make the empty-composer Enter behavior and non-empty-composer Enter behavior understandable at a glance.
+- If the implementation keeps both behaviors, the display should communicate the mode/priority without making it look like the selected Ticket is the composer destination.
+- If the implementation introduces a more explicit focus/mode model, it must preserve the binding decisions already recorded: no bare letter shortcuts, `Tab` target switching with completion priority, and shared composer key handling with the normal chat UI.
+
+Reviewer focus:
+
+- Verify that the final Panel display does not conflate selected Ticket actions with Companion/Intake text submission.
+- Verify that the composer status/help text answers “what will Enter do now?” rather than only listing internal state labels.
+
+---
+
+<!-- event: decision author: intake at: 2026-06-09T08:59:44Z -->
+
+## Decision
+
+## Refinement: selected Ticket while composer has text
+
+Clarified current behavior and resulting UX invariant:
+
+- In the current Panel implementation, a selected Ticket only drives `Enter` actions when the composer is blank.
+- If the composer has text and the target is `Companion`, `Enter` sends the text to the workspace Companion; the selected Ticket is not used as the message destination or action target.
+- If the composer has text and the target is `TicketIntake`, `Enter` launches a new pre-ticket Intake from the typed text; the selected Ticket is not used. Existing-Ticket Intake for a selected `Clarify` action is currently reached only from the blank-composer selected-row action path.
+- Therefore, “composer has text while a Ticket row is selected” currently has no actionable selected-Ticket semantics. The selected row may still be visible/navigation state, but it should not be displayed as if the typed text will act on that Ticket.
+
+Additional requirement:
+
+- The Panel display should avoid suggesting that typed composer text is scoped to or sent to the selected Ticket unless the implementation explicitly adds such a feature.
+- If text composer mode is active, selected-row Ticket action hints should be de-emphasized, hidden, or explicitly separated from the composer destination/action.
+- If the future design wants typed text to refine a selected Ticket, that must be an explicit product decision and not implied by the current mixed UI.
+
+---
+
+<!-- event: comment author: intake at: 2026-06-09T09:35:47Z -->
+
+## Comment
+
+## UX exploration note: contextual input instead of always-visible ambiguous composer
+
+User raised a broader display/operation concern:
+
+- The always-visible bottom composer may be intrinsically ambiguous in the Panel because it is not obvious what the box is for at any moment.
+- The current UI mixes selected-list-item actions with global text submission. Even if labels are improved, a fixed bottom box can still look like it applies to the selected Ticket/Pod when it may actually send to Companion or launch new Intake.
+- A potentially clearer direction is to show an input box contextually for the selected list item/action, rather than keeping one always-visible global box whose meaning changes.
+
+Potential design direction for implementation consideration:
+
+- Default Panel state emphasizes list navigation and selected-row actions; no ambiguous always-active global input is required.
+- Immediate row actions can remain `Enter`-driven when no text is needed.
+- Actions that need text open a contextual input box attached to, or clearly associated with, the selected row/action.
+- Global text destinations such as workspace Companion or new Ticket Intake should be explicit actions/targets, not visually conflated with the selected Ticket action state.
+- If a persistent bottom input remains, it should have one unambiguous purpose, such as “Ask Companion”, and selected Ticket action hints should be visually separate from it.
+
+This is not yet a final binding redesign decision. Treat it as reviewer/orchestrator context for the same Ticket: the implementation should prioritize making the input box’s scope and destination obvious, and should avoid relying only on denser status labels to explain a mixed interaction model.
+
+---
+
+<!-- event: plan author: intake at: 2026-06-09T09:46:50Z -->
+
+## Plan
+
+## Refinement: explicit focus model for row actions vs global composer
+
+User clarified a more concrete interaction model to reduce the ambiguity between selected list actions and global text submission.
+
+Desired direction:
+
+- The Panel should distinguish at least two visible interaction states:
+  - row/list focus: the user is hovering/selecting a Ticket/Pod/list item and can inspect or choose actions for that item;
+  - global composer focus/no selection: the bottom composer is used to send text to a global target such as Companion or new Ticket Intake.
+- `Esc` should be able to clear the current row/item selection or action focus and return to the global composer/no-selection state.
+- When selection is cleared, the bottom composer can be used for Companion or new Intake target submission without implying that text applies to a selected Ticket.
+- For a selected Ticket/list item, Left/Right should navigate into or out of the item’s available actions.
+- Pressing Right while hovering a Ticket should expand or focus the available actions for that item.
+- The action-focused display should make available actions selectable, such as text-related actions, `Queue`, or other valid item actions.
+- Up/Down should continue to navigate list items in list focus; when action focus is active, implementation may define whether Up/Down changes focused action or returns to item navigation, but the resulting behavior must be visible and predictable.
+- Text submission for a selected item should be explicit through an item/action-focused UI. Typed text in the global bottom composer should not silently apply to a selected Ticket.
+
+Implications / reviewer focus:
+
+- Avoid a mixed state where a Ticket is visually selected, a bottom composer has text, and the UI does not clearly say whether Enter affects the selected Ticket or the global target.
+- The display should make focus explicit: selected item, selected item action, or global composer target.
+- `Esc` behavior must be specified carefully because current Panel uses `Esc` as quit. A reasonable implementation may make `Esc` clear action/list focus first and reserve quit for `Ctrl+C`/`Ctrl+D`, or quit only when already in no-selection/global state, but the chosen behavior must be clear and tested.
+- `Tab` remains the target-switching key for global composer targets, with completion priority if completion is active.
+- Bare letter shortcuts must not be reintroduced.
+
+This refinement supersedes the earlier weaker idea of only improving labels around an always-visible ambiguous composer. The preferred UX direction is an explicit focus/action model: list hover -> Right opens item actions -> choose action; Esc backs out to global composer/no-selection; global composer sends only to explicit global target.
+
+---
+
+<!-- event: decision author: intake at: 2026-06-09T09:50:15Z -->
+
+## Decision
+
+## Decision: Panel quit key and Esc focus behavior
+
+User decided that Panel quit should be available through `Ctrl+C`.
+
+Binding decision update:
+
+- `Ctrl+C` is the Panel quit key.
+- `Esc` should not be the primary quit action in the redesigned Panel interaction model.
+- `Esc` should be available for backing out of UI focus states, such as item action focus or selected-row focus, toward the no-selection / global composer state.
+- If the implementation preserves any `Esc` quit behavior for compatibility, it must not conflict with the new focus-clear/back-out behavior and must be clearly justified in the implementation report.
+
+Reviewer focus:
+
+- Verify that `Esc` does not unexpectedly exit the Panel when the user is trying to leave item/action focus.
+- Verify that `Ctrl+C` exits reliably from the redesigned Panel states.
+
+---

.yoi/tickets/20260609-085148-001/item.md

@@ -0,0 +1,76 @@
+---
+title: 'session analyticsにresponse単位のbatching指標を追加する'
+state: 'planning'
+created_at: '2026-06-09T08:51:48Z'
+updated_at: '2026-06-09T08:51:48Z'
+assignee: null
+---
+
+## 背景
+
+`session-analytics-tooling` を実際の Coder / Reviewer セッションに適用したところ、tool call の総数だけではなく、assistant response 単位の batching が重要だと分かった。
+
+観測例:
+
+- Coder session では `avg tools / tool response = 1.16`、`p90 = 1` で、ほぼ 1 response = 1 tool call だった。
+- `Edit` は 40 responses すべてが `1 response = 1 Edit` だった。
+- 同じ response 内で同一ファイルに複数 `Edit` している例はなかった。
+- その一方で、同じファイルへの edit-only response が 2〜4 回連続している箇所があり、round-trip latency の観点では batching opportunity の可能性がある。
+- Reviewer session では編集はないが、tool calls per response は同様に低く、探索時に Read/Grep/Bash の result size と response batching を見る価値がある。
+
+Edit batching 自体の是非は追加調査するが、analytics 側には response 単位の指標が必要。
+
+## ゴール
+
+`session-analytics` に assistant response 単位の tool batching / edit round-trip 指標を追加し、tool call の使い方を速度面から評価できるようにする。
+
+## 要件
+
+- Session JSONL から assistant response / tool result cycle 単位を推定する。
+  - 1 assistant response に含まれる tool call 群を集計する。
+  - user turn 単位とは別に response 単位の metrics を持つ。
+- Tool calls per response を集計する。
+  - total responses
+  - tool-call responses
+  - total tool calls
+  - avg / p50 / p90 / max
+  - histogram
+  - top responses by tool call count
+- Edit batching metrics を追加する。
+  - Edit calls per response
+  - responses containing Edit
+  - same-file multiple Edit calls in one response
+  - files touched per edit response
+  - large edit arguments との相関が取れる形にする。
+- Consecutive edit round-trip metrics を追加する。
+  - 同一ファイルに対する連続 edit-only responses を検出する。
+  - streak length / file path / response range / line range を報告する。
+  - 間に Read/Bash/test/tool result dependent step がある場合と、pure edit-only streak を区別する。
+- Suspicious diagnostics は断定しない。
+  - 連続 Edit が必ず悪いとは言わない。
+  - "possible batching opportunity" として報告する。
+  - Edit の成功/失敗や前回 result を見て次を決める必要がある場合は正当な分割であり得る。
+- JSON report に machine-readable field として追加する。
+- Human summary mode がある場合は、top-N の batching observations を表示する。
+  - まだ human summary が無い場合は、少なくとも JSON schema に追加し、後続で CLI summary に出せるようにする。
+
+## 非目標
+
+- この Ticket で prompt / workflow を変更して batching を強制すること。
+- 複数 Edit を同一 response に並べる方針を決めること。
+- ordered patch / EditBatch tool を実装すること。
+- Edit が小さいこと自体を悪いと判定すること。
+
+## 受け入れ条件
+
+- `session-analytics` report に response-level tool batching metrics が含まれる。
+- Coder session のような `1 response = 1 Edit` 傾向を数値で確認できる。
+- 同一ファイルへの consecutive edit-only response streak を検出できる。
+- Same-response same-file multiple Edit がある場合に検出できる。
+- Tests cover:
+  - single response with multiple tools;
+  - single response with multiple same-file edits;
+  - consecutive edit-only responses to the same file;
+  - interleaved Read/test step that breaks or annotates a streak;
+  - sessions with no edits.
+- `cargo fmt --check`, focused tests, `git diff --check`, and `target/debug/yoi ticket doctor` pass.

.yoi/tickets/20260609-085148-001/thread.md

@@ -0,0 +1,7 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-09T08:51:48Z -->
+
+## 作成
+
+LocalTicketBackend によって作成されました。
+
+---

.yoi/tickets/20260609-085212-001/item.md

@@ -0,0 +1,70 @@
+---
+title: 'TicketListの出力を軽量化する'
+state: 'planning'
+created_at: '2026-06-09T08:52:12Z'
+updated_at: '2026-06-09T08:52:12Z'
+assignee: null
+---
+
+## 背景
+
+実セッションを `session analyze` で確認したところ、Orchestrator / Companion 系のセッションで `TicketList` の tool result が大きくなりやすいことが分かった。
+
+観測例:
+
+- `TicketList` result が 20KB〜65KB 程度になるケースがある。
+- 一覧系 tool は頻繁に使われるため、1回の大きな summary が history/context を圧迫しやすい。
+- Coder / Reviewer では `TicketList` は主因ではなかったが、Orchestrator / Companion では Ticket 一覧が routing / cleanup / backlog 判断の起点になりやすい。
+
+TicketList は人間/AI の探索入口として必要だが、default output はもっと bounded にしてよい。
+
+## ゴール
+
+`TicketList` の default output を減量し、必要十分な bounded summary にする。詳細は `TicketShow` に委ねる。
+
+## 要件
+
+- `TicketList` default output の情報量を再設計する。
+- default では item body / thread / artifacts の詳細を含めない。
+- 1 Ticket あたりの summary を短くする。
+  - canonical id
+  - title
+  - state
+  - priority 相当が残る場合のみ
+  - updated_at または queued_at など、必要な最小 timestamp
+  - attention/blocking hint がある場合の短い indicator
+- title や diagnostics が長い場合は bounded に切り詰める。
+- `limit` の default / max を見直す。
+  - default は current UI/LLM usage に適した小さい値にする。
+  - max も context blow-up を起こしにくい上限にする。
+- `state=all` / closed を含む一覧は特に慎重に制限する。
+- 必要なら detail-heavy mode を明示 opt-in にする。
+  - 例: `--verbose` / `--json-full` / separate command。
+  - ただし default tool result は軽量に保つ。
+- Tool output と CLI human output の両方を確認する。
+  - LLM-facing TicketList tool は特に bounded であるべき。
+  - CLI は人間可読性を保ちつつ、巨大 JSON/Markdown を default で出さない。
+- Orchestrator が詳細判断する場合は `TicketShow <id>` を読む前提にする。
+  - List は selection / triage / backlog overview 用。
+  - routing / close / planning return / implementation acceptance の authority にはしない。
+
+## 非目標
+
+- TicketShow の詳細を削ること。
+- Ticket backend schema を変更すること。
+- Ticket relation / Objective / OrchestrationPlan の設計を変えること。
+- List だけで Orchestrator が routing 判断できるようにすること。
+
+## 受け入れ条件
+
+- `TicketList` default result が現在より明確に小さい bounded summary になる。
+- Large open/all Ticket set でも tool result が context を過度に圧迫しない。
+- `TicketList` は detail authority ではなく selection/overview 用であることが docs/tool description/workflow guidance から分かる。
+- `TicketShow` は詳細確認の authority として引き続き使える。
+- Tests cover:
+  - long title truncation;
+  - large list limit behavior;
+  - all/closed state listing cap;
+  - JSON/tool output shape;
+  - no body/thread leakage in list output.
+- `target/debug/yoi ticket doctor`, focused tests, `cargo fmt --check`, and `git diff --check` pass.

.yoi/tickets/20260609-085212-001/thread.md

@@ -0,0 +1,7 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-09T08:52:12Z -->
+
+## 作成
+
+LocalTicketBackend によって作成されました。
+
+---

.yoi/tickets/20260609-093050-001/item.md

@@ -0,0 +1,90 @@
+---
+title: 'Tool実行にToolExecutionContextを渡す'
+state: 'planning'
+created_at: '2026-06-09T09:30:50Z'
+updated_at: '2026-06-09T09:30:50Z'
+assignee: null
+---
+
+## 背景
+
+LLM-Worker は tool calls を並列実行する前提で作られている。Worker 側に tool/resource scheduling policy を持たせるのではなく、順序性や排他が必要な tool は tool 実装側で待つ設計にしたい。
+
+そのためには tool 実装が、現在の tool call がどの LLM response / tool batch に属し、response 内で何番目の call なのかを知る必要がある。
+
+現状の `Tool::execute(input_json)` には以下の情報が渡らない:
+
+- tool call id;
+- response/tool-batch identity;
+- response 内の tool call order;
+- LLM call / turn に紐づく実行文脈。
+
+Hook / Interceptor ではこの用途をきれいに満たせない。`pre_tool_call` で lock を取ると、全 pre hooks が tool execution 前に走る構造のため deadlock し得る。また guard を tool execution future の lifetime に渡す API もない。
+
+## ゴール
+
+Tool 実行 API に `ToolExecutionContext` を導入し、tool 実装が response-local order / call identity を参照できるようにする。Worker は並列実行を維持し、scheduling policy は持たない。
+
+## 要件
+
+### API 変更
+
+- 既存 API 互換を優先せず、`Tool::execute` を context 付き signature に置き換える。
+- 例:
+
+```rust
+async fn execute(&self, input_json: &str, ctx: ToolExecutionContext) -> Result<ToolOutput, ToolError>;
+```
+
+- `ToolServer::call_tool` / Worker の tool execution path も context を渡す形に更新する。
+- 互換 wrapper や default old-API bridge は原則作らなくてよい。既存 tools を一括更新する。
+
+### ToolExecutionContext
+
+- `ToolExecutionContext` に少なくとも以下を含める:
+  - `call_id`: provider/tool call id;
+  - `batch_id`: 1つの assistant response / tool-call batch を識別する id;
+  - `call_index`: batch 内の tool call order;
+  - 必要なら `llm_call_index` / `turn_index` 相当。ただし first pass では過剰に増やさない。
+- `batch_id` は tool execution batch ごとに stable であればよい。
+  - random UUID でも Worker-local increment でもよい。
+  - session log に出す必要があるかは実装時に判断する。
+- `call_index` は LLM が出した tool call order を反映する。
+- Context は Worker の scheduling 判断に使わない。tool が必要に応じて利用する metadata とする。
+
+### Worker behavior
+
+- Worker はこれまで通り approved tool calls を並列実行する。
+- Worker は per-tool parallel-safe / serial / resource conflict policy を持たない。
+- Worker は各 tool call に context を付与して並列実行するだけ。
+- `pre_tool_call` / `post_tool_call` interceptors の既存意味論は極力維持する。
+  - 必要なら `ToolCallInfo` / `ToolResultInfo` に context 相当の情報を追加する。
+  - ただし lock/permit lifecycle を interceptor に持たせない。
+
+### Tool update
+
+- 既存 built-in tools を新 signature に更新する。
+- 初期段階では多くの tools は context を無視してよい。
+- Context を使う具体的な same-file mutation queue / Edit-Write serialization は別 Ticket で扱う。
+
+## 非目標
+
+- Worker に resource scheduling policy を実装すること。
+- `Edit` / `Write` の same-file mutex をこの Ticket で実装すること。
+- `parallel_tool_calls=false` の導入。
+- Hook / Interceptor で lock lifecycle を管理すること。
+- Backward-compatible old Tool API を長期維持すること。
+
+## 受け入れ条件
+
+- `Tool::execute` が `ToolExecutionContext` を受け取る。
+- Worker が 1 assistant response / tool batch ごとに `batch_id` と `call_index` を付与して tools を並列実行する。
+- `call_index` は response 内の tool call order と一致する。
+- 既存 built-in tools が新 API に移行され、context を無視しても動作する。
+- Interceptor / hook の意味論が壊れていない。
+- Tests cover:
+  - multiple tool calls in one response receive same `batch_id` and increasing `call_index`;
+  - separate tool batches receive distinct `batch_id`;
+  - synthetic / skipped / aborted tool calls の context handling が破綻しない;
+  - parallel execution is still used for approved calls.
+- Focused tests, `cargo fmt --check`, `git diff --check`, and `target/debug/yoi ticket doctor` pass.

.yoi/tickets/20260609-093050-001/thread.md

@@ -0,0 +1,7 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-09T09:30:50Z -->
+
+## 作成
+
+LocalTicketBackend によって作成されました。
+
+---