ticket: accept file mutation serialization

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

@@ -1 +1,2 @@
 {"id":"orch-plan-20260610-083728-1","ticket_id":"00001KTR83D6E","kind":"waiting_capacity_note","note":"Panel launch did not specify a target Ticket and instructed Orchestrator to wait for explicit follow-up before spawning role Pods. Queue acceptance was not recorded yet. Bounded check: Ticket body/thread show implementation_ready, relation query has no blockers, orchestration plan has no existing records, main workspace is clean, and active worktrees are prompt-resource-centralization plus tui-model-setup-wizard. Waiting reason: human gate/explicit target authorization.","author":"orchestrator","at":"2026-06-10T08:37:28Z"}
+{"id":"orch-plan-20260610-091909-2","ticket_id":"00001KTR83D6E","kind":"accepted_plan","accepted_plan":{"summary":"Implement same-file Edit/Write serialization for built-in filesystem mutation tools using `ToolExecutionContext` batch/call order and canonical target path. Same-batch same-file mutations execute by `call_index`; different files remain parallel; different batches maintain per-file exclusion without distributed locking. Add focused tests for Edit/Edit order, Write+Edit order, different-file concurrency, failure release, and path equivalence.","branch":"serialize-file-mutations","worktree":"/home/hare/Projects/yoi/.worktree/serialize-file-mutations","role_plan":"Orchestrator implements directly in a dedicated worktree because coder write-scope delegation is unavailable in this session; reviewer will be spawned read-only after implementation. Keep Worker parallel execution intact and confine ordering logic to built-in file mutation boundary/shared tooling rather than a general Worker scheduler."},"author":"orchestrator","at":"2026-06-10T09:19:09Z"}

.yoi/tickets/00001KTR83D6E/item.md

@@ -1,8 +1,8 @@
 ---
 title: 'Edit/Writeの同一ファイル変更をToolExecutionContextで直列化する'
-state: 'queued'
+state: 'inprogress'
 created_at: '2026-06-10T07:49:10Z'
-updated_at: '2026-06-10T08:37:28Z'
+updated_at: '2026-06-10T09:19:09Z'
 assignee: null
 queued_by: 'workspace-panel'
 queued_at: '2026-06-10T08:10:58Z'

.yoi/tickets/00001KTR83D6E/thread.md

@@ -29,4 +29,40 @@ LocalTicketBackend によって作成されました。
 Ticket を `workspace-panel` が queued にしました。
 
 
+---
+
+<!-- event: state_changed author: orchestrator at: 2026-06-10T09:19:09Z from: queued to: inprogress reason: orchestrator_queue_acceptance field: state -->
+
+## State changed
+
+Queue acceptance: relation query has no blockers, orchestration-plan query only has prior human-gate waiting note, workspace is clean, and user explicitly requested continuing inprogress/queued consumption. Implementation side effects will proceed in a separate worktree/branch before reviewer evidence and merge-completion.
+
+---
+
+<!-- event: plan author: orchestrator at: 2026-06-10T09:19:09Z -->
+
+## Plan
+
+Routing decision: implementation_ready
+
+Reason:
+- Ticket is `queued`, relation query has no blockers, and existing orchestration plan only contains a prior human-gate waiting note.
+- User explicitly requested continuing inprogress/queued work; this satisfies the prior human gate.
+- Requirements and acceptance criteria are concrete: same-file `Edit`/`Write` ordering by `ToolExecutionContext.call_index` within a batch, no Worker-wide scheduler, different-file parallelism, guard release on error, and path equivalence coverage.
+
+Evidence checked:
+- Ticket body/thread/artifacts.
+- `TicketRelationQuery`: no relations/blockers.
+- `TicketOrchestrationPlanQuery`: one waiting note from prior target-unspecified routing pass.
+- Code map: `crates/tools/src/edit.rs`, `crates/tools/src/write.rs`, `crates/tools/src/tracker.rs`, `crates/tools/src/scoped_fs.rs`, `crates/llm-worker/src/tool.rs`, `crates/llm-worker/src/worker.rs`.
+- Workspace state is clean; existing separate setup-wizard worktree is independent.
+
+IntentPacket:
+- Intent: serialize same-target-file built-in mutations so `Edit`/`Write` calls for one file in one response execute in model call order while preserving Worker parallel tool execution.
+- Binding decisions / invariants: Worker must not become a general resource scheduler; do not disable provider/Worker parallel tool calls; do not serialize unrelated tools or different files; preserve existing scope/read-before-edit behavior; path keying must not weaken scope validation; no distributed lock across Pods/processes.
+- Requirements / acceptance criteria: same-batch same-file `Edit` order; same-batch same-file `Write` + `Edit` order; different files remain concurrent; failure releases guard; path equivalence behavior fixed by implementation/test; targeted tests and standard validation pass.
+- Implementation latitude: exact guard placement may be a shared file-mutation coordinator in `tools` as long as both `Edit` and `Write` share it and Worker remains parallel; for different batch same-file mutations, a simple per-file exclusion is acceptable if reason is recorded.
+- Escalate if implementation requires changing Worker execution semantics, tool result ordering/history semantics, permission/scope model, or broad distributed locking.
+- Validation: `cargo fmt`, `cargo test -p tools mutation`, focused `cargo test -p tools`, `git diff --check`, `target/debug/yoi ticket doctor`, and broader build before merge if touched surfaces require it.
+
 ---