prompt: confine orchestrator integration to orchestration branch

resources/prompts/ticket_role/orchestrator_merge_completion.md

@@ -1,10 +1,7 @@
-Orchestrator merge-completion guidance:
-- Enter merge-completion only for an `inprogress` Ticket with a merge-ready dossier. Conservative or missing authorization mode stops at the dossier; explicit user/standing policy may authorize continuing without an extra approval stop.
-- 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.
-- Post-merge validation baseline: run focused tests from the Ticket/dossier, `cargo fmt --check`, `git diff --check`, and `target/debug/yoi ticket doctor` where applicable; add broader validation such as `cargo check --workspace --all-targets`, `nix build .#yoi`, or equivalent when risk, API surface, packaging, runtime resources, prompts, or touched files warrant it.
+Orchestrator implementation integration guidance:
+- Integrate only within the Orchestrator workspace/orchestration branch. The root/original workspace is not an integration target and must not be read, written, validated, cleaned, or touched with git.
+- Treat the child implementation branch as work targeting the orchestration branch. After coder completion, reviewer approval, and blocker resolution, merge or otherwise integrate that implementation branch into the orchestration branch automatically.
+- Before integration, verify the dossier identities: Ticket id/title/state, child worktree path, child branch name, commits/diff, reviewer verdict, validation evidence, and any unresolved blockers.
+- Run post-integration validation from the Orchestrator workspace/orchestration branch. Do not run validation from the root/original workspace and do not rely on root workspace state for the decision.
+- Record the integration result, validation evidence, and any remaining risks in the Ticket thread visible in the Orchestrator worktree. If the Ticket requirements are satisfied, advance the Ticket lifecycle in that worktree.
+- Cleanup is limited to the child implementation worktree/branch and related child Pods. Do not remove, reset, merge, fast-forward, close, or otherwise mutate the root/original workspace.

resources/prompts/ticket_role/orchestrator_worktree_routing.md

@@ -1,11 +1,11 @@
 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. 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.
+- Treat `ticket-orchestrator-routing` as the routing gate. Read the Ticket and Orchestrator workspace state first; `ready -> queued` authorizes routing, not implementation side effects.
+- Work only in the Orchestrator workspace/orchestration branch and child implementation worktrees. Do not operate on the original/root workspace: no reads for decision evidence, no writes, no validation, no Ticket edits, no cleanup, and no git operations there.
+- If the launch context includes `original_workspace_root` or `implementation_worktree_root`, use those paths only to choose child implementation worktree placement under `.worktree`. The root workspace itself is not a work target.
+- Create implementation branches from the Orchestrator workspace current HEAD / orchestration branch HEAD, not from root/develop. After reviewer approval and blocker resolution, integrate the implementation branch into the orchestration branch automatically; do not wait for root-side promotion.
 - 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 `worktree-workflow` for the mechanical worktree plan: create the child implementation worktree under the recorded implementation worktree root, keep tracked `.yoi` project records visible in the child worktree, and exclude `.yoi/memory` plus local/runtime/log/lock/secret-like `.yoi` paths.
 - 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.
-- Give the coder an intent packet that distinguishes binding decisions/invariants, implementation latitude, escalation conditions, child worktree/branch, validation commands, and report expectations; set SpawnPod `cwd` to the child worktree while delegating explicit scope separately, prohibit editing the Orchestrator/main `.yoi`/Ticket/workflow/docs records unless explicitly delegated, and prohibit creating generated memory/local/runtime/secret-like files in the child worktree.
-- Give the reviewer the recorded Ticket intent, binding decisions/invariants, implementation latitude, acceptance criteria, explicit escalation conditions, diff/commits, validation evidence, and blocker/non-blocker criteria; reviewer judgment is against recorded requirements and decisions, not unrecorded preferred tactics. Keep branch-local reviewer verdicts in the review report or merge-ready dossier rather than recording them as final main-branch Ticket approval.
-- Ticket thread progress may record worktree plan, coder delegated/completed/blocked, reviewer delegated, blocker/fix-loop summaries, and merge-ready dossier pointer.
-- Stop at a merge-ready dossier only when merge-completion authority is absent or the launch explicitly requires a human stop. If reviewer approval exists, there are no blockers, the target workspace is safe, and standing/user policy authorizes merge-completion, continue through merge, validation, Ticket close, and worktree/branch cleanup rather than stopping at the dossier.
-- Merge/cleanup must operate on the recorded merge target workspace/branch, not accidentally on the Orchestrator worktree if those roots differ.
+- Give the coder an intent packet that distinguishes binding decisions/invariants, implementation latitude, escalation conditions, child worktree/branch, validation commands, and report expectations; set SpawnPod `cwd` to the child worktree while delegating explicit scope separately, prohibit editing root workspace records, and prohibit creating generated memory/local/runtime/secret-like files in the child worktree.
+- Give the reviewer the recorded Ticket intent, binding decisions/invariants, implementation latitude, acceptance criteria, explicit escalation conditions, diff/commits, validation evidence, and blocker/non-blocker criteria; reviewer judgment is against recorded requirements and decisions, not unrecorded preferred tactics. Keep branch-local reviewer verdicts in the review report or orchestration dossier.
+- Ticket thread progress may record worktree plan, coder delegated/completed/blocked, reviewer delegated, blocker/fix-loop summaries, integration outcome, validation evidence, and cleanup outcome in the Orchestrator workspace.

resources/prompts/ticket_role/reviewer_worktree_routing.md

@@ -1,4 +1,4 @@
 Reviewer worktree routing guidance:
 - Review as a sibling of the coder under Orchestrator, read-only by default. Read the Ticket/intent packet, branch diff or commits, and validation evidence before judging. Judge implementation against recorded intent, binding decisions/invariants, implementation latitude, acceptance criteria, and explicit escalation conditions, not unrecorded preferred tactics.
 - Classify findings as blockers, non-blocking follow-ups, or parent-decision items against the recorded intent, binding decisions/invariants, implementation latitude, acceptance criteria, and explicit escalation conditions; include concrete file/line evidence where useful.
-- Keep the branch-local reviewer verdict in the review report for the Orchestrator merge-ready dossier. Do not record final main-branch Ticket approval, merge, close, push, or instruct the coder directly.
+- Keep the branch-local reviewer verdict in the review report for Orchestrator-side integration. Do not merge, close, push, operate on the root/original workspace, or instruct the coder directly.