ticket: use base32 project record ids

.yoi/tickets/00001KTNVGT8G/artifacts/orchestration-plan.jsonl

@@ -0,0 +1 @@
+{"id":"orch-plan-20260609-100341-1","ticket_id":"00001KTNVGT8G","kind":"before","related_ticket":"00001KTNSA2K0","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/00001KTNVGT8G/item.md

@@ -0,0 +1,92 @@
+---
+title: 'Tool実行にToolExecutionContextを渡す'
+state: 'closed'
+created_at: '2026-06-09T09:30:50Z'
+updated_at: '2026-06-09T10:46:50Z'
+assignee: null
+queued_by: 'workspace-panel'
+queued_at: '2026-06-09T10:01:00Z'
+---
+
+## 背景
+
+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/00001KTNVGT8G/resolution.md

@@ -0,0 +1,29 @@
+Implemented, reviewed, merged, and validated.
+
+Summary:
+- Added `ToolExecutionContext` with `call_id`, `batch_id`, and `call_index`.
+- Changed Tool execution APIs so `Tool::execute` / `ToolServer::call_tool` receive execution context.
+- Worker assigns one response-local batch id per approved tool-call batch and preserves LLM-returned call order with `call_index`.
+- Approved tool calls still execute in parallel; no scheduler, same-file mutex, mutation queue, conflict solver, or `parallel_tool_calls=false` behavior was added.
+- `ToolCallInfo` / `ToolResultInfo` expose context metadata.
+- Macro-generated tools can receive `ToolExecutionContext` as a non-schema parameter; context is not exposed as an LLM JSON argument.
+- Built-in tools and tests were migrated to the new API.
+
+Implementation:
+- Coder commit: `d8aed7b tool: add execution context`
+- Reviewer approved with no blocking findings.
+- Merge commit: `4744548 merge: add tool execution context`
+
+Validation after merge:
+- `cargo test -p llm-worker --test parallel_execution_test test_tool_execution_context -- --nocapture`
+- `cargo test -p llm-worker --test parallel_execution_test test_parallel_tool_execution -- --nocapture`
+- `cargo test -p llm-worker --test tool_macro_test -- --nocapture`
+- `cargo check -p llm-worker -p tools -p ticket`
+- `cargo fmt --check`
+- `git diff --check`
+- `cargo run -q -p yoi -- ticket doctor`
+- `cargo check --workspace`
+- `nix build .#yoi`
+
+Residual note:
+- `batch_id` is Worker-local and not a durable/global external artifact key.

.yoi/tickets/00001KTNVGT8G/thread.md

@@ -0,0 +1,268 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-09T09:30:50Z -->
+
+## 作成
+
+LocalTicketBackend によって作成されました。
+
+---
+
+<!-- event: intake_summary author: intake at: 2026-06-09T09:55:00Z -->
+
+## Intake summary
+
+既存 Ticket を確認し、同目的の未完了重複は見当たりません。要件は Tool 実行 API に `ToolExecutionContext` を導入し、`call_id` / response-local `batch_id` / `call_index` を Tool 実装へ渡すことです。Worker は従来どおり approved tool calls を並列実行し、resource scheduling policy は持たないこと、old Tool API 互換層を長期維持しないこと、Interceptor / hook に lock lifecycle を持たせないことが binding decision です。実装側には `batch_id` 生成方式や session log への記録有無の裁量があります。関連し得る Ticket として `00001KTNS9B50` は response 単位の batching analytics であり、目的が異なるため重複ではありません。リスク/レビュー焦点は public API 変更、Worker tool execution path、Interceptor/hook 意味論、並列実行維持、既存 built-in tools の一括移行です。受け入れ条件と validation が明確なため implementation_ready と判断します。
+
+---
+
+<!-- event: state_changed author: intake at: 2026-06-09T09:55:00Z from: planning to: ready reason: intake_ready field: state -->
+
+## State changed
+
+Intake により要件・非目標・受け入れ条件・レビュー焦点が routing 可能な状態で確認されたため、planning から ready にします。
+
+---
+
+<!-- event: state_changed author: workspace-panel at: 2026-06-09T10:01:00Z from: ready to: queued reason: queued field: state -->
+
+## State changed
+
+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: `00001KTNVGT8G`, `00001KTNSA2K0`, and `00001KTNS1AA8`.
+- 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`.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-09T10:05:03Z -->
+
+## Implementation report
+
+Implementation routing started.
+
+Worktree/branch:
+- Worktree: `.worktree/tool-execution-context`
+- Branch: `tool-execution-context`
+- Base/routing commit: `b21fab8 ticket: route tool execution context`
+
+Spawned sibling Coder Pod:
+- `coder-tool-execution-context`
+- Scope: non-recursive read on parent workspace root plus recursive write limited to the child worktree.
+
+Routing context:
+- This is the active implementation work.
+- `00001KTNSA2K0` (`TicketListの出力を軽量化する`) is intentionally left queued until this core Tool execution API migration lands.
+- `00001KTNS1AA8` is also left queued for capacity/sequencing while this core migration is active.
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-09T10:33:45Z -->
+
+## Implementation report
+
+Coder implementation completed and is ready for sibling review.
+
+Coder Pod:
+- `coder-tool-execution-context`
+- Commit: `d8aed7befe6ff739cbee1b49221d3b8be35a57d7 tool: add execution context`
+- Worktree status before review: clean branch `tool-execution-context`
+- Stopped after collecting output to reclaim delegated worktree scope.
+
+Selected design:
+- Added `llm_worker::tool::ToolExecutionContext` with `call_id`, `batch_id`, and `call_index`.
+- `batch_id` is Worker-local monotonic (`tool-batch-{n}`) and shared across one `execute_and_commit_tools` batch.
+- `call_index` is 0-based order from the LLM-returned tool call array.
+- `call_id` is synchronized to any pre-interceptor-mutated tool call id before execution/post context.
+
+Implementation summary:
+- `Tool::execute` and `ToolServer::call_tool` now receive `ToolExecutionContext`.
+- Worker assigns context while preserving parallel approved tool execution via `join_all`.
+- `ToolCallInfo` / `ToolResultInfo` expose context.
+- skipped / synthetic / post-tool paths have context available.
+- Built-in tools, Ticket tools, Memory tools, Pod tools, test fixtures, and macro-generated Tool implementations were migrated.
+- `llm-worker-macros` excludes `ToolExecutionContext` parameters from JSON schema and supplies them from execution context.
+- Added direct/default context helpers for low-level direct tests; Worker path passes explicit batch context.
+
+Validation reported passed:
+- `cargo test -p llm-worker --test tool_macro_test`
+- `cargo test -p llm-worker --test parallel_execution_test`
+- `cargo test -p llm-worker`
+- `cargo test -p tools -p ticket`
+- `cargo test -p memory`
+- `cargo test -p pod --tests --no-run`
+- `cargo test --workspace --no-run`
+- `cargo fmt --check`
+- `git diff --check`
+- `cargo check --workspace`
+- `cargo run -q -p yoi -- ticket doctor`
+- `nix build .#yoi`
+
+Residual notes:
+- `batch_id` is not globally durable.
+- Resumed pending tool calls receive a fresh execution batch id.
+- No scheduling, serialization, per-resource locks, same-file queueing, or `parallel_tool_calls=false` equivalent was added.
+
+---
+
+<!-- event: review author: reviewer at: 2026-06-09T10:41:41Z status: approve -->
+
+## Review: approve
+
+## Review result: approve
+
+Reviewed commit `d8aed7befe6ff739cbee1b49221d3b8be35a57d7` on branch `tool-execution-context`.
+
+Evidence:
+- `ToolExecutionContext` is added as a small value object with `call_id`, `batch_id`, and `call_index`, and `Tool::execute` / `ToolServerHandle::call_tool` now receive it.
+- Worker assigns `tool-batch-{n}` once per `execute_tools` invocation, enumerates model-returned tool calls for 0-based `call_index`, synchronizes `call_id` after pre-interceptor call mutation, and passes the context into execution and post interceptors.
+- Approved calls are still executed through `join_all`; no serial/resource scheduling policy, same-file mutex/queue, `parallel_tool_calls=false`, or conflict solver was introduced.
+- Interceptor info structs expose context only as metadata; no lock/permit lifecycle is introduced into interceptors.
+- Macro generation filters `ToolExecutionContext` out of JSON arguments while passing it as a non-schema parameter; built-in/manual tools were migrated to the new signature and no old `Tool::execute(input_json)` implementation remains.
+- Context contains only response-local ids/order and does not expose Worker/history/session mutable handles; existing scope/host-authority/Ticket/web checks remain in the migrated tool bodies.
+
+Focused validation run by reviewer:
+- `cargo test -p llm-worker --test parallel_execution_test test_tool_execution_context -- --nocapture` — passed (3 tests).
+- `cargo test -p llm-worker --test parallel_execution_test test_parallel_tool_execution -- --nocapture` — passed.
+- `cargo test -p llm-worker --test tool_macro_test -- --nocapture` — passed (9 tests).
+- `cargo check -p llm-worker -p tools -p ticket` — passed.
+- `git diff --check && cargo fmt --check` — passed.
+- `cargo run -q -p yoi -- ticket doctor` — `doctor: ok`.
+
+Residual risk:
+- `batch_id` is Worker-local (`tool-batch-{n}`), not a durable globally unique id across process/session reconstruction. That matches the implementation report and is acceptable for this ticket, but should not be treated as persistent cross-session identity.
+
+---
+
+<!-- event: review author: reviewer-tool-execution-context at: 2026-06-09T10:43:02Z status: approve -->
+
+## Review: approve
+
+Review result: approve
+
+Evidence:
+- `ToolExecutionContext` carries `call_id`, `batch_id`, and `call_index` as response-local execution context.
+- `Tool::execute` / `ToolServerHandle::call_tool` receive context.
+- Worker assigns one `tool-batch-{n}` per tool batch and 0-based `call_index` in LLM-returned tool-call order.
+- `call_id` is synchronized after pre-interceptor mutation before tool execution and post-interceptor reporting.
+- Approved tool calls continue to execute in parallel with `join_all`; no serial policy, resource scheduler, same-file mutex, mutation queue, or `parallel_tool_calls=false` equivalent was introduced.
+- `ToolCallInfo` / `ToolResultInfo` expose context as metadata without lock/permit lifecycle.
+- Macro-generated tools treat `ToolExecutionContext` as a non-schema parameter, not an LLM JSON argument.
+- Built-in/manual tools are migrated to the new API and the old `Tool::execute(input_json)` implementation pattern is not retained as a compatibility surface.
+- Context carries response-local identity/order only and is not Worker/history/session mutable access; scope, host-authority, Ticket, and web safety boundaries are not weakened.
+
+Reviewer validation:
+- `cargo test -p llm-worker --test parallel_execution_test test_tool_execution_context -- --nocapture`
+- `cargo test -p llm-worker --test parallel_execution_test test_parallel_tool_execution -- --nocapture`
+- `cargo test -p llm-worker --test tool_macro_test -- --nocapture`
+- `cargo check -p llm-worker -p tools -p ticket`
+- `git diff --check && cargo fmt --check`
+- `cargo run -q -p yoi -- ticket doctor`
+
+All passed. Residual note: `batch_id` is Worker-local (`tool-batch-{n}`), not a durable/global identity across process/session reconstruction. This is acceptable for this Ticket but should not be treated as a persistent external artifact key without a future design.
+
+---
+
+<!-- event: state_changed author: hare at: 2026-06-09T10:46:50Z from: inprogress to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-09T10:46:50Z status: closed -->
+
+## 完了
+
+Implemented, reviewed, merged, and validated.
+
+Summary:
+- Added `ToolExecutionContext` with `call_id`, `batch_id`, and `call_index`.
+- Changed Tool execution APIs so `Tool::execute` / `ToolServer::call_tool` receive execution context.
+- Worker assigns one response-local batch id per approved tool-call batch and preserves LLM-returned call order with `call_index`.
+- Approved tool calls still execute in parallel; no scheduler, same-file mutex, mutation queue, conflict solver, or `parallel_tool_calls=false` behavior was added.
+- `ToolCallInfo` / `ToolResultInfo` expose context metadata.
+- Macro-generated tools can receive `ToolExecutionContext` as a non-schema parameter; context is not exposed as an LLM JSON argument.
+- Built-in tools and tests were migrated to the new API.
+
+Implementation:
+- Coder commit: `d8aed7b tool: add execution context`
+- Reviewer approved with no blocking findings.
+- Merge commit: `4744548 merge: add tool execution context`
+
+Validation after merge:
+- `cargo test -p llm-worker --test parallel_execution_test test_tool_execution_context -- --nocapture`
+- `cargo test -p llm-worker --test parallel_execution_test test_parallel_tool_execution -- --nocapture`
+- `cargo test -p llm-worker --test tool_macro_test -- --nocapture`
+- `cargo check -p llm-worker -p tools -p ticket`
+- `cargo fmt --check`
+- `git diff --check`
+- `cargo run -q -p yoi -- ticket doctor`
+- `cargo check --workspace`
+- `nix build .#yoi`
+
+Residual note:
+- `batch_id` is Worker-local and not a durable/global external artifact key.
+
+---