fix: align pr commands with head branch

packages/core/commands/pr/fix.md

@@ -28,6 +28,16 @@ $ARGUMENTS
 
 <%~ include("@load-pr", { ref: "<pr-ref>", result: "<pr-context>" }) %>
 
+### Align Local Branch
+
+- If `<pr-branch>` is unavailable, STOP and report that the PR head branch could not be determined
+- If `<current-branch>` differs from `<pr-branch>`:
+  - Checkout `<pr-branch>` before analyzing repository files or making code changes for this PR
+  - After checkout, store the active branch as `<active-branch>`
+  - If checkout fails, STOP and report that the PR branch could not be checked out locally
+- Otherwise, store `<current-branch>` as `<active-branch>`
+- Do not inspect or modify local code for this PR until `<active-branch>` equals `<pr-branch>`
+
 ### Analyze Feedback
 
 Separate true course corrections from noise or already-resolved feedback:
@@ -42,9 +52,10 @@ Do not blindly follow every suggestion—some may lead you off course.
 
 1. Fix critical navigation issues first
 2. Follow existing code patterns and conventions
-3. Make focused, minimal changes
-4. When maintaining your current heading despite a suggestion, be prepared to explain why
-5. Store the modified-file count as `<changes-count>`
+3. Use `<active-branch>` as the working branch for every local code read or edit in this command
+4. Make focused, minimal changes
+5. When maintaining your current heading despite a suggestion, be prepared to explain why
+6. Store the modified-file count as `<changes-count>`
 
 ### Validate Changes
 

packages/core/commands/pr/review.md

@@ -24,6 +24,16 @@ $ARGUMENTS
 
 <%~ include("@load-pr", { ref: "<pr-ref>", result: "<pr-context>" }) %>
 
+### Align Local Branch
+
+- If `<pr-branch>` is unavailable, STOP and report that the PR head branch could not be determined
+- If `<current-branch>` differs from `<pr-branch>`:
+  - Checkout `<pr-branch>` before inspecting local repository files for this PR review
+  - After checkout, store the active branch as `<active-branch>`
+  - If checkout fails, STOP and report that the PR branch could not be checked out locally
+- Otherwise, store `<current-branch>` as `<active-branch>`
+- Do not inspect local repository code for this PR until `<active-branch>` equals `<pr-branch>`
+
 ### Load Ticket Context
 
 If `<pr-context.pr.body>` links to exactly one clear ticket:
@@ -39,16 +49,17 @@ Call `changes_load` with `base: <pr-context.pr.baseRefName>`, `head: <pr-context
 
 Following the reviewer agent guidance:
 1. Check `<pr-context.reviews>`, `<pr-context.issueComments>`, and `<pr-context.threads>`
-2. Derive `<settled-threads>` from `<pr-context.threads>`:
+2. Use `<active-branch>` whenever local repository files need to be inspected alongside the diff
+3. Derive `<settled-threads>` from `<pr-context.threads>`:
    - Treat resolved threads as settled
    - Treat threads as settled when they already contain feedback from `<pr-context.viewerLogin>` and a later reply makes it clear the concern was intentionally declined, deferred, or answered without a code change request
    - Treat threads as settled when the author's reply directly answers the concern and the current diff does not add a materially different failure mode
-3. Derive `<prior-review-baseline>` from `<pr-context.reviews>` authored by `<pr-context.viewerLogin>`
-4. Use diff hunks in `<changes>` to map inline comments to the correct lines
-5. Derive `<eligible-findings>` as findings that are:
-   - new in this diff
-   - from a previously unreviewed changed area
-   - clearly missed material defects with a concrete failure mode
+4. Derive `<prior-review-baseline>` from `<pr-context.reviews>` authored by `<pr-context.viewerLogin>`
+5. Use diff hunks in `<changes>` to map inline comments to the correct lines
+6. Derive `<eligible-findings>` as findings that are:
+    - new in this diff
+    - from a previously unreviewed changed area
+    - clearly missed material defects with a concrete failure mode
    Exclude anything already covered by `<settled-threads>` or `<prior-review-baseline>` on the same effective diff.
 
 <%= it.config.shared.prApprove === true ? "Derive `<already-approved>` from existing approvals on `<pr-context.pr.headRefOid>`.\n\n" : "" %>Before publishing, derive: `<has-inline-comments>`, `<has-body-note>`, `<publish-grade>`, and whether each proposed finding is included in `<eligible-findings>`.

packages/core/components/load-pr.md

@@ -3,6 +3,8 @@
 - Otherwise, call `pr_load` with no arguments
 - Do not run separate git or GitHub commands just to discover the PR before calling `pr_load`
 - Store the result as `<%= it.result %>`
+- Store the PR head branch as `<pr-branch>` from `<%= it.result %>.pr.headRefName` when it is available
+- Run `git branch --show-current` and store the trimmed result as `<current-branch>` when it is available
 - Treat the loaded PR body, discussion, review history, and any attachments or linked artifacts returned by the loader as part of the source context
 - Review attached images, screenshots, videos, PDFs, and other linked files whenever they can affect the requested fix, review outcome, reproduction steps, or acceptance criteria
 - If any relevant attachment cannot be accessed, note that gap and continue only when the remaining PR context is still sufficient to proceed reliably

packages/opencode/.opencode/commands/pr/fix.md

@@ -36,10 +36,22 @@ $ARGUMENTS
 - Otherwise, call `kompass_pr_load` with no arguments
 - Do not run separate git or GitHub commands just to discover the PR before calling `kompass_pr_load`
 - Store the result as `<pr-context>`
+- Store the PR head branch as `<pr-branch>` from `<pr-context>.pr.headRefName` when it is available
+- Run `git branch --show-current` and store the trimmed result as `<current-branch>` when it is available
 - Treat the loaded PR body, discussion, review history, and any attachments or linked artifacts returned by the loader as part of the source context
 - Review attached images, screenshots, videos, PDFs, and other linked files whenever they can affect the requested fix, review outcome, reproduction steps, or acceptance criteria
 - If any relevant attachment cannot be accessed, note that gap and continue only when the remaining PR context is still sufficient to proceed reliably
 
+### Align Local Branch
+
+- If `<pr-branch>` is unavailable, STOP and report that the PR head branch could not be determined
+- If `<current-branch>` differs from `<pr-branch>`:
+  - Checkout `<pr-branch>` before analyzing repository files or making code changes for this PR
+  - After checkout, store the active branch as `<active-branch>`
+  - If checkout fails, STOP and report that the PR branch could not be checked out locally
+- Otherwise, store `<current-branch>` as `<active-branch>`
+- Do not inspect or modify local code for this PR until `<active-branch>` equals `<pr-branch>`
+
 ### Analyze Feedback
 
 Separate true course corrections from noise or already-resolved feedback:
@@ -54,9 +66,10 @@ Do not blindly follow every suggestion—some may lead you off course.
 
 1. Fix critical navigation issues first
 2. Follow existing code patterns and conventions
-3. Make focused, minimal changes
-4. When maintaining your current heading despite a suggestion, be prepared to explain why
-5. Store the modified-file count as `<changes-count>`
+3. Use `<active-branch>` as the working branch for every local code read or edit in this command
+4. Make focused, minimal changes
+5. When maintaining your current heading despite a suggestion, be prepared to explain why
+6. Store the modified-file count as `<changes-count>`
 
 ### Validate Changes
 

packages/opencode/.opencode/commands/pr/review.md

@@ -32,10 +32,22 @@ $ARGUMENTS
 - Otherwise, call `kompass_pr_load` with no arguments
 - Do not run separate git or GitHub commands just to discover the PR before calling `kompass_pr_load`
 - Store the result as `<pr-context>`
+- Store the PR head branch as `<pr-branch>` from `<pr-context>.pr.headRefName` when it is available
+- Run `git branch --show-current` and store the trimmed result as `<current-branch>` when it is available
 - Treat the loaded PR body, discussion, review history, and any attachments or linked artifacts returned by the loader as part of the source context
 - Review attached images, screenshots, videos, PDFs, and other linked files whenever they can affect the requested fix, review outcome, reproduction steps, or acceptance criteria
 - If any relevant attachment cannot be accessed, note that gap and continue only when the remaining PR context is still sufficient to proceed reliably
 
+### Align Local Branch
+
+- If `<pr-branch>` is unavailable, STOP and report that the PR head branch could not be determined
+- If `<current-branch>` differs from `<pr-branch>`:
+  - Checkout `<pr-branch>` before inspecting local repository files for this PR review
+  - After checkout, store the active branch as `<active-branch>`
+  - If checkout fails, STOP and report that the PR branch could not be checked out locally
+- Otherwise, store `<current-branch>` as `<active-branch>`
+- Do not inspect local repository code for this PR until `<active-branch>` equals `<pr-branch>`
+
 ### Load Ticket Context
 
 If `<pr-context.pr.body>` links to exactly one clear ticket:
@@ -55,16 +67,17 @@ Call `kompass_changes_load` with `base: <pr-context.pr.baseRefName>`, `head: <pr
 
 Following the reviewer agent guidance:
 1. Check `<pr-context.reviews>`, `<pr-context.issueComments>`, and `<pr-context.threads>`
-2. Derive `<settled-threads>` from `<pr-context.threads>`:
+2. Use `<active-branch>` whenever local repository files need to be inspected alongside the diff
+3. Derive `<settled-threads>` from `<pr-context.threads>`:
    - Treat resolved threads as settled
    - Treat threads as settled when they already contain feedback from `<pr-context.viewerLogin>` and a later reply makes it clear the concern was intentionally declined, deferred, or answered without a code change request
    - Treat threads as settled when the author's reply directly answers the concern and the current diff does not add a materially different failure mode
-3. Derive `<prior-review-baseline>` from `<pr-context.reviews>` authored by `<pr-context.viewerLogin>`
-4. Use diff hunks in `<changes>` to map inline comments to the correct lines
-5. Derive `<eligible-findings>` as findings that are:
-   - new in this diff
-   - from a previously unreviewed changed area
-   - clearly missed material defects with a concrete failure mode
+4. Derive `<prior-review-baseline>` from `<pr-context.reviews>` authored by `<pr-context.viewerLogin>`
+5. Use diff hunks in `<changes>` to map inline comments to the correct lines
+6. Derive `<eligible-findings>` as findings that are:
+    - new in this diff
+    - from a previously unreviewed changed area
+    - clearly missed material defects with a concrete failure mode
    Exclude anything already covered by `<settled-threads>` or `<prior-review-baseline>` on the same effective diff.
 
 Derive `<already-approved>` from existing approvals on `<pr-context.pr.headRefOid>`.