ticket: accept file mutation serialization

2026-06-10 18:19:18 +09:00
parent 5e716fb351
commit 536ff4dd57
3 changed files with 39 additions and 2 deletions
@@ -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.
+
 ---