prompt: clarify orchestrator branch base

.yoi/tickets/00001KTX1QMG9/item.md

@@ -1,8 +1,8 @@
 ---
 title: '実装ブランチをOrchestrator branch HEADから切る'
-state: 'inprogress'
+state: 'closed'
 created_at: '2026-06-12T04:34:05Z'
-updated_at: '2026-06-12T08:11:52Z'
+updated_at: '2026-06-12T08:15:54Z'
 assignee: null
 queued_by: 'yoi ticket'
 queued_at: '2026-06-12T08:11:52Z'

.yoi/tickets/00001KTX1QMG9/resolution.md

@@ -0,0 +1 @@
+Orchestrator が implementation worktree を original workspace 配下に作成する場合でも、implementation branch は Orchestrator workspace current HEAD / orchestration branch HEAD を base とするよう、role prompt / routing prompt / merge completion prompt に明記した。検証は cargo fmt、cargo test -p client ticket_role、cargo check --workspace、nix build .#yoi、git diff --check、target/debug/yoi ticket doctor で完了。

.yoi/tickets/00001KTX1QMG9/thread.md

@@ -39,4 +39,52 @@ Ticket を `yoi ticket` が queued にしました。
 State changed to `inprogress`.
 
 
+---
+
+<!-- event: implementation_report author: hare at: 2026-06-12T08:15:54Z -->
+
+## Implementation report
+
+実装報告:
+- Orchestrator role prompt の workspace routing context に、implementation worktree の配置先と branch base を分離して明記した。
+- Orchestrator worktree routing prompt に、implementation branch は Orchestrator workspace current HEAD / orchestration branch HEAD から切ると明記した。
+- Merge completion prompt に、implementation branch -> orchestration branch -> merge target の順序を明記した。
+- client prompt generation test に branch base guidance の assertion を追加した。
+
+検証:
+- cargo fmt
+- cargo test -p client ticket_role
+- cargo check --workspace
+- nix build .#yoi
+- git diff --check
+- target/debug/yoi ticket doctor
+
+
+---
+
+<!-- event: state_changed author: "yoi ticket" at: 2026-06-12T08:15:54Z from: inprogress to: done reason: cli_state field: state -->
+
+## State changed
+
+State changed to `done`.
+
+
+---
+
+<!-- event: state_changed author: hare at: 2026-06-12T08:15:54Z from: done to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-12T08:15:54Z status: closed -->
+
+## 完了
+
+Orchestrator が implementation worktree を original workspace 配下に作成する場合でも、implementation branch は Orchestrator workspace current HEAD / orchestration branch HEAD を base とするよう、role prompt / routing prompt / merge completion prompt に明記した。検証は cargo fmt、cargo test -p client ticket_role、cargo check --workspace、nix build .#yoi、git diff --check、target/debug/yoi ticket doctor で完了。
+
+
 ---

crates/client/src/ticket_role.rs

@@ -707,7 +707,7 @@ fn append_workspace_routing_context(out: &mut String, context: &TicketRoleLaunch
         &target_workspace_root.display().to_string(),
     );
     out.push_str(
-        "- Treat `role_workspace_root` as the launched role runtime workspace/Ticket backend root. Create implementation worktrees under `implementation_worktree_root`, not relative to the role cwd, and run merge-completion against `merge_target_workspace_root`.\n",
+        "- Treat `role_workspace_root` as the launched role runtime workspace/Ticket backend root. Create implementation worktrees under `implementation_worktree_root`, not relative to the role cwd, and run merge-completion against `merge_target_workspace_root`. `implementation_worktree_root` is placement authority only; implementation branches are based on the Orchestrator workspace current HEAD / orchestration branch HEAD, not the merge-target workspace or `develop` HEAD.\n",
     );
 }
 
@@ -1351,6 +1351,9 @@ workflow = "ticket-review-workflow"
         assert!(text.contains("implementation_worktree_root"));
         assert!(text.contains("merge_target_workspace_root"));
         assert!(text.contains("not relative to the role cwd"));
+        assert!(text.contains("`implementation_worktree_root` is placement authority only"));
+        assert!(text.contains("implementation branches are based on the Orchestrator workspace current HEAD / orchestration branch HEAD"));
+        assert!(text.contains("not the merge-target workspace or `develop` HEAD"));
         assert!(text.contains("Orchestrator merge-completion guidance"));
         assert!(text.contains("`inprogress` Ticket with a merge-ready dossier"));
         assert!(text.contains("Conservative or missing authorization mode stops at the dossier"));

resources/prompts/ticket_role/orchestrator_merge_completion.md

@@ -3,6 +3,7 @@ Orchestrator merge-completion guidance:
 - Required dossier fields before merge: Ticket id; branch/worktree; commits; intent/invariant check; implementation summary; coder/reviewer Pods; blockers fixed or rejected findings with reasons; validation performed; residual risks; dirty state; parent/human decision needs if any.
 - Before merging, verify the dossier branch/worktree/commits match the branch to merge, independent reviewer approval exists in the dossier or an explicit human override decision is recorded, the merge target workspace is safe, and unrelated dirty changes are understood.
 - If the Orchestrator is running from a dedicated orchestration worktree, do not infer the merge target from process cwd. Use the recorded `merge_target_workspace_root` / original workspace root, and ensure cleanup removes only the child implementation worktree/branch intended by the dossier.
+- The implementation branch should have been created from the Orchestrator workspace current HEAD / orchestration branch HEAD, then merged back into the orchestration branch before the orchestration branch is merged or fast-forwarded into the recorded merge-target workspace/branch. Do not base implementation branches directly on a stale merge-target workspace or `develop` HEAD.
 - Merge only when dogfooding/workspace policy grants merge authority. If authority is unavailable, record/return the dossier and stop without merge, close, final main Ticket approval, or cleanup.
 - Preserve the boundary: branch-local reviewer verdicts are dossier evidence; final main-branch Ticket approval or close happens only during authorized merge-completion after merge and validation evidence.
 - Authorized sequence: stop/reclaim coder and reviewer Pods where appropriate; merge with `git merge --no-ff <branch>` or the project-agreed method from the target workspace; run post-merge validation appropriate to the change; record review, merge, and validation outcomes in the Ticket thread during merge-completion; transition `inprogress -> done` or close according to typed Ticket workflow rules; then remove the merged child worktree and delete the merged branch unless explicitly kept.

resources/prompts/ticket_role/orchestrator_worktree_routing.md

@@ -1,6 +1,6 @@
 Orchestrator worktree + agent routing guidance:
 - Treat `ticket-orchestrator-routing` as the routing gate. Read the Ticket and workspace state first; `ready -> queued` authorizes routing, not implementation side effects.
-- Keep the launched Orchestrator runtime workspace/Ticket backend root distinct from the original/merge-target workspace root. If the launch context includes `original_workspace_root` or `implementation_worktree_root`, create implementation worktrees under that original root (for example `<original_workspace_root>/.worktree/<task-name>`), not under the Orchestrator's current working directory.
+- Keep the launched Orchestrator runtime workspace/Ticket backend root distinct from the original/merge-target workspace root. If the launch context includes `original_workspace_root` or `implementation_worktree_root`, create implementation worktrees under that original root (for example `<original_workspace_root>/.worktree/<task-name>`), not under the Orchestrator's current working directory. Treat that root as placement authority only: the implementation branch base is the Orchestrator workspace current HEAD / orchestration branch HEAD, not the merge-target workspace or `develop` HEAD.
 - Create worktrees or spawn coder/reviewer Pods only after `state = inprogress` is already recorded and accepted. If the Ticket is still queued and unblocked, record `queued -> inprogress` before any worktree/SpawnPod side effect.
 - Use `worktree-workflow` for the mechanical worktree plan: create the child implementation worktree under the recorded original workspace root, keep tracked `.yoi` project records visible in the child worktree, exclude `.yoi/memory` plus local/runtime/log/lock/secret-like `.yoi` paths, and keep active orchestration progress plus final review/approval/close in the Orchestrator workspace unless explicitly designed otherwise.
 - Use `multi-agent-workflow` for the sibling loop: coder and reviewer are siblings under this Orchestrator; coder gets narrow write scope to the child worktree; reviewer is read-only by default.