ticket: route tool execution context

.yoi/tickets/20260609-084725-001/artifacts/orchestration-plan.jsonl

@@ -0,0 +1 @@
+{"id":"orch-plan-20260609-100341-1","ticket_id":"20260609-084725-001","kind":"waiting_capacity_note","note":"Defer this TUI panel/composer UX work while the core ToolExecutionContext API migration is active. It can be routed after the tool API work lands or if explicitly prioritized; this avoids parallel broad changes across tool/runtime and TUI surfaces.","author":"orchestrator","at":"2026-06-09T10:03:41Z"}

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

@@ -2,7 +2,7 @@
 title: 'Improve workspace panel display and composer key handling'
 state: 'queued'
 created_at: '2026-06-09T08:47:25Z'
-updated_at: '2026-06-09T10:01:08Z'
+updated_at: '2026-06-09T10:03:41Z'
 assignee: null
 readiness: 'implementation_ready'
 risk_flags: ['tui-input', 'ux-consistency']

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

@@ -158,4 +158,25 @@ Reviewer focus:
 Ticket を `workspace-panel` が queued にしました。
 
 
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-09T10:03:41Z -->
+
+## Decision
+
+Routing decision: waiting_capacity_parallelism
+
+This Ticket remains queued for now.
+
+Reason:
+- `20260609-093050-001` is being accepted as the active core tool execution API migration.
+- This Ticket is TUI panel/composer UX work and is implementation-ready, but it is better sequenced after the core tool API migration to keep review/validation focused and avoid broad parallel changes.
+
+State decision:
+- Leave this Ticket `queued`.
+- Do not create a worktree or spawn a coder yet.
+
+Next action:
+- Re-read this Ticket after the ToolExecutionContext API migration lands, or earlier if explicitly prioritized.
+
 ---

.yoi/tickets/20260609-085212-001/artifacts/orchestration-plan.jsonl

@@ -0,0 +1 @@
+{"id":"orch-plan-20260609-100341-1","ticket_id":"20260609-085212-001","kind":"after","related_ticket":"20260609-093050-001","note":"Wait for the ToolExecutionContext API migration before changing TicketList output/tool behavior so the TicketList implementation targets the stable tool execution context interface.","author":"orchestrator","at":"2026-06-09T10:03:41Z"}

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

@@ -2,7 +2,7 @@
 title: 'TicketListの出力を軽量化する'
 state: 'queued'
 created_at: '2026-06-09T08:52:12Z'
-updated_at: '2026-06-09T10:01:28Z'
+updated_at: '2026-06-09T10:03:41Z'
 assignee: null
 queued_by: 'workspace-panel'
 queued_at: '2026-06-09T10:01:28Z'

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

@@ -77,4 +77,27 @@ Intake refinement により、目的・受け入れ条件・binding decisions /
 Ticket を `workspace-panel` が queued にしました。
 
 
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-09T10:03:41Z -->
+
+## Decision
+
+Routing decision: waiting_for_tool_execution_context
+
+This Ticket remains queued for now.
+
+Reason:
+- `20260609-093050-001` (`Tool実行にToolExecutionContextを渡す`) changes the core tool execution API.
+- This Ticket changes `TicketList`, which is an LLM tool surface and should target the stable post-migration execution context API.
+- Running both in parallel would create avoidable conflicts across tool schema/execution code.
+
+State decision:
+- Leave this Ticket `queued`.
+- Do not create a worktree or spawn a coder yet.
+
+Next action:
+- Complete and merge `20260609-093050-001` first.
+- Re-read this Ticket and accept from queued if still unblocked.
+
 ---

.yoi/tickets/20260609-093050-001/artifacts/orchestration-plan.jsonl

@@ -0,0 +1 @@
+{"id":"orch-plan-20260609-100341-1","ticket_id":"20260609-093050-001","kind":"before","related_ticket":"20260609-085212-001","note":"Run the ToolExecutionContext API migration before slimming TicketList output because TicketList is an LLM tool surface that may need to adopt the new execution context API shape.","author":"orchestrator","at":"2026-06-09T10:03:41Z"}

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

@@ -1,8 +1,8 @@
 ---
 title: 'Tool実行にToolExecutionContextを渡す'
-state: 'queued'
+state: 'inprogress'
 created_at: '2026-06-09T09:30:50Z'
-updated_at: '2026-06-09T10:01:00Z'
+updated_at: '2026-06-09T10:03:41Z'
 assignee: null
 queued_by: 'workspace-panel'
 queued_at: '2026-06-09T10:01:00Z'

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

@@ -29,4 +29,67 @@ Intake により要件・非目標・受け入れ条件・レビュー焦点が
 Ticket を `workspace-panel` が queued にしました。
 
 
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-09T10:03:41Z from: queued to: inprogress reason: orchestrator_acceptance field: state -->
+
+## State changed
+
+Accepted queued implementation after reading the Ticket and current workspace state. This is a core tool execution API migration and should land before changing individual tool outputs such as TicketList. No active implementation worktree exists, and the workspace record updates were committed before acceptance.
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-09T10:03:41Z -->
+
+## Decision
+
+Routing decision: implementation_ready
+
+Evidence checked:
+- Ticket body and Intake summary.
+- Current queued set: `20260609-093050-001`, `20260609-085212-001`, and `20260609-084725-001`.
+- Current workspace/worktree state after committing queued record updates: main workspace clean, no active implementation worktree.
+- Relation/order context: `TicketList` output slimming should wait for this core tool execution API migration.
+
+Reason:
+- The Ticket has clear implementation requirements: introduce `ToolExecutionContext`, pass it through Tool execution, and move context-dependent path/working-directory/backend access out of static Tool definitions where appropriate.
+- It is a lower-level API migration that should land before individual tool output/UX changes.
+- No concrete missing decision remains requiring return to planning.
+
+IntentPacket:
+
+Intent:
+- Pass a `ToolExecutionContext` into Tool execution so tool behavior can depend on runtime context without encoding runtime-dependent data in static tool definitions.
+
+Binding decisions / invariants:
+- Static Tool definitions/schemas remain static and reusable.
+- Runtime-dependent values such as cwd/workspace context/backend handles should flow through execution context where appropriate, not through schema metadata or global mutable state.
+- Existing tool behavior must remain compatible unless a tool explicitly needs the new context.
+- Keep capability/authority checks explicit and typed; do not use `ToolExecutionContext` as an unstructured escape hatch.
+- Do not weaken scope, host-authority, Ticket backend, or web/network safety boundaries.
+- Avoid broad speculative refactors beyond the execution-path migration required for this Ticket.
+- Update built-in tools/tests that need context, especially file/path/Ticket/backend-sensitive surfaces.
+- Preserve LLM-facing tool names and schemas unless a specific schema change is required.
+
+Implementation latitude:
+- Coder may choose exact `ToolExecutionContext` fields and lifetimes if they keep ownership/thread-safety practical and avoid leaking runtime/session-private data into static schemas.
+- Coder may introduce default/empty context helpers for tests and tools that do not need context.
+- If a subset of tools must be migrated first, keep a coherent buildable boundary and report remaining follow-up explicitly.
+
+Escalate if:
+- The change requires redesigning the whole ToolRegistry/plugin system.
+- Context fields would need to carry raw Worker/history/session mutable access.
+- Authority checks cannot remain explicit and typed.
+- Too many unrelated tool schema/output changes become necessary.
+
+Validation:
+- Focused Tool trait/ToolRegistry tests for context passing.
+- Focused tests for context-sensitive built-in tools such as Ticket/backend/path tools if affected.
+- Existing tool schema/name tests.
+- `cargo fmt --check`.
+- `git diff --check`.
+- `cargo run -q -p yoi -- ticket doctor`.
+- `cargo check --workspace`.
+- `nix build .#yoi`.
+
 ---