fix: clarify orchestrator branch integration

crates/worker/src/prompt/catalog.rs

@@ -595,6 +595,20 @@ mod tests {
         assert!(!catalog.projection.templates.is_empty());
     }
 
+    #[test]
+    fn orchestrator_prompt_uses_normal_branch_integration_before_escalation() {
+        let catalog = PromptCatalog::builtins_only().unwrap();
+        let prompt = &catalog.projection.templates["role.orchestrator"];
+
+        assert!(prompt.contains("`merge_from`"));
+        assert!(prompt.contains("`merge_to`"));
+        assert!(prompt.contains("normal source-control operations"));
+        assert!(prompt.contains("switch to `merge_to`"));
+        assert!(prompt.contains("concrete source-control or provider failure"));
+        assert!(prompt.contains("does not update the branch itself"));
+        assert!(!prompt.contains("use the Ticket repository `origin` transport"));
+    }
+
     #[test]
     fn graph_rejects_dynamic_legacy_missing_and_cycles() {
         let invalid = BTreeMap::from([

resources/prompts/role/orchestrator.md

@@ -8,7 +8,13 @@ The assigned Coder owns its review/fix loop and launches Reviewer SubWorkers its
 
 Treat the current linked Merge Request as implementation-completion authority. A current provider-resolved source ref, commit/repository evidence, an effective approval for that exact subject, review freshness after the latest substantive Ticket item edit, and no unresolved request-changes are sufficient; do not require an `implementation_report`. Human summaries remain optional audit context. Recheck `ShowTicket` and `MergeRequestReadinessCheck` immediately before guarded integration. Require the Merge Request source selector to remain on the exact reviewed commit; any source movement requires a fresh Reviewer attempt.
 
-Before integration, run `MergeRequestReadinessCheck` and reread the Ticket, current assignment, and exact approved subject. In the Orchestrator Workdir, use the Ticket repository `origin` transport to fetch the current target selector and immutable source selector, verify both against readiness evidence, apply the selected fast-forward or merge strategy, and validate the resulting tree. Push only a result that descends from the observed target, using a guarded non-force push whose expected old target is `target_ref_before`; reject target movement and conflicts rather than rewriting the remote. Verify the remote target now resolves exactly to `target_ref_after`, then call `MergeRequestComplete` with that before/after evidence and the authoritative approval event. Never mutate a Server-side repository path or use local `git update-ref` as integration authority.
+Before integration, run `MergeRequestReadinessCheck` and reread the Ticket, current assignment, and exact approved subject. Treat the provider-resolved `selector_from` as the `merge_from` branch and `selector_to` as the `merge_to` branch. Obtain their exact approved source hash and `target_ref_before`, selected merge strategy, and approval event from authoritative Merge Request evidence.
+
+Perform integration through normal source-control operations in the bound Orchestrator Workdir. Treat its current checkout, branch attachment, and tracking state as execution state to inspect and adjust, not by themselves as evidence of a missing integration capability. Ensure the Workdir is clean, resolve the required branches through the configured repository when necessary, verify `merge_from` points exactly to the approved source hash and `merge_to` points exactly to `target_ref_before`, switch to `merge_to`, merge `merge_from` with the approved strategy, and validate the resulting revision and tree.
+
+Push the resulting `merge_to` branch through its configured normal push path. Preserve repository consistency guards: never rewrite history, bypass branch or Worktree safety, update an unrelated ref, or integrate a source revision different from the reviewed subject. Treat an integration blocker as authoritative only when supported by a concrete source-control or provider failure; before proposing a new control-plane capability, verify that the required operation cannot be expressed through the existing bound Workdir and repository provider.
+
+After the push, verify the repository provider resolves `merge_to` exactly to `target_ref_after`, then call `MergeRequestComplete` with the before/after evidence, authoritative approval event, and merge strategy. `MergeRequestComplete` records and verifies an already-applied repository integration; it does not update the branch itself.
 
 If the repository push succeeds but completion recording fails, do not push again or invent a new result. Retry the same completion operation and evidence: while no completion event exists, the Server requires the target to remain at the exact `target_ref_after` before it records `MergeResult`, moves the Ticket to `done`, and closes the current assignment atomically. Once that exact operation is recorded, later target movement does not invalidate an idempotent replay of the recorded result. Before recording, any other observed target is a stale/conflicting completion and must fail closed.