fix(consult): correct diff scope on non-default integration branches

codev-skeleton/protocols/air/consult-types/pr-review.md

@@ -34,7 +34,11 @@ If the baked decisions themselves contain contradictions, do not pick one — `R
 5. **PR Quality**
    - Does the PR link to the issue?
    - Is the PR body review section informative?
-   - Is the branch up to date with main?
+   - Is the branch up to date with its base (the integration branch the PR targets)?
+
+## Scope
+
+- **DO NOT** flag the syntax of `git diff` examples that appear in review-file prose (e.g., `git diff ci..HEAD` inside a "Files Changed" caption or "How to Test Locally" section). Quoted diff syntax is documentation, not a command. Apply two-dot/three-dot scrutiny only to diffs you compute yourself.
 
 ## Verdict Format
 

codev-skeleton/protocols/aspir/builder-prompt.md

@@ -74,18 +74,18 @@ The architect MAY request a PR at any point — for spec review, mid-implementat
 Your worktree is persistent — it survives across PR merges. When the architect asks for sequential PRs (e.g., to slice a large spec into shippable pieces), use this loop:
 
 1. Cut a branch, open a PR, wait for merge
-2. After merge: `git fetch origin main && git checkout -b <next-branch> origin/main`
+2. After merge: `git fetch origin <integration-branch> && git checkout -b <next-branch> origin/<integration-branch>` — where `<integration-branch>` is the branch the architect targets PRs at (usually `main`; check the open PR's `baseRefName` if unsure)
 3. Continue to the next slice, open another PR
 
-**Important**: Do NOT run `git checkout main` — git worktrees cannot check out a branch that's checked out elsewhere. Always branch off `origin/main` via fetch.
+**Important**: Do NOT run `git checkout <integration-branch>` — git worktrees cannot check out a branch that's checked out elsewhere. Always branch off `origin/<integration-branch>` via fetch.
 
 Record PRs: `porch done {{project_id}} --pr <N> --branch <name>`
 Record merges: `porch done {{project_id}} --merged <N>`
 
 ## Verify Phase
 
 After the final PR merges, the project enters the **verify** phase. You stay alive through verify:
-1. Pull main into your worktree
+1. Pull the integration branch into your worktree
 2. Run `porch done {{project_id}}` to signal verification is ready
 3. The architect approves `verify-approval` when satisfied
 

codev-skeleton/protocols/aspir/consult-types/pr-review.md

@@ -28,10 +28,14 @@ You are performing a final self-check during the Review phase. The builder has c
    - Are any new APIs documented?
 
 5. **PR Readiness**
-   - Is the branch up to date with main?
+   - Is the branch up to date with its base (the integration branch the PR targets)?
    - Are commits atomic and well-described?
    - Is the change diff reasonable in size?
 
+## Scope
+
+- **DO NOT** flag the syntax of `git diff` examples that appear in review-file prose (e.g., `git diff ci..HEAD` inside a "Files Changed" caption or "How to Test Locally" section). Quoted diff syntax is documentation, not a command. Apply two-dot/three-dot scrutiny only to diffs you compute yourself.
+
 ## Verdict Format
 
 After your review, provide your verdict in exactly this format:

codev-skeleton/protocols/bugfix/consult-types/pr-review.md

@@ -41,7 +41,7 @@ There is **no `codev/specs/`, `codev/plans/`, or `codev/reviews/` file** for a B
 
 6. **PR Hygiene**
    - Commits use the BUGFIX format: `Fix #<N>: ...` or `[Bugfix #<N>] ...` (**not** `[Spec NNNN][Phase]`).
-   - Branch is up to date with main (or close enough for clean merge).
+   - Branch is up to date with its base (or close enough for clean merge).
    - PR is linked to the issue.
 
 ## Out of Scope (Do NOT request changes for)
@@ -54,6 +54,7 @@ The following are **not** part of the BUGFIX protocol and must **not** be cited
 - Commit format `[Spec NNNN][Phase]` — BUGFIX intentionally uses `Fix #N:` / `[Bugfix #N]`.
 - `status.yaml` fields like `build_complete: false` — porch manages `status.yaml`; the builder is **forbidden** from editing it directly. Treat porch state as informational, not a fixable issue.
 - Phase-scoping concerns — BUGFIX is a single-phase protocol; there are no plan phases to scope against.
+- **DO NOT** flag the syntax of `git diff` examples that appear in review-file prose (e.g., `git diff ci..HEAD` inside a "Files Changed" caption). Quoted diff syntax is documentation, not a command. Apply two-dot/three-dot scrutiny only to diffs you compute yourself.
 
 ## Verdict Format
 

codev-skeleton/protocols/maintain/consult-types/pr-review.md

@@ -28,10 +28,14 @@ You are performing a final self-check during the Review phase. The builder has c
    - Are any new APIs documented?
 
 5. **PR Readiness**
-   - Is the branch up to date with main?
+   - Is the branch up to date with its base (the integration branch the PR targets)?
    - Are commits atomic and well-described?
    - Is the change diff reasonable in size?
 
+## Scope
+
+- **DO NOT** flag the syntax of `git diff` examples that appear in review-file prose (e.g., `git diff ci..HEAD` inside a "Files Changed" caption or "How to Test Locally" section). Quoted diff syntax is documentation, not a command. Apply two-dot/three-dot scrutiny only to diffs you compute yourself.
+
 ## Verdict Format
 
 After your review, provide your verdict in exactly this format:

codev-skeleton/protocols/pir/builder-prompt.md

@@ -82,7 +82,7 @@ If you encounter **pre-existing flaky tests** (intermittent failures unrelated t
 If your Claude session crashes mid-flow, Tower's `while true` loop will relaunch you with the same prompt. On startup:
 
 1. Run `porch next {{project_id}}` to learn what phase you're in
-2. If `gate_pending`: read the latest plan file (plan-approval) or `git diff "$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||' || echo main)"` (dev-approval) plus any new GitHub issue comments; check `afx send` queue. Decide whether to revise or just announce you're back.
+2. If `gate_pending`: read the latest plan file (plan-approval) or `DEFAULT_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||'); git diff "$(git merge-base "${DEFAULT_BRANCH:-main}" HEAD)"` (dev-approval) plus any new GitHub issue comments; check `afx send` queue. Decide whether to revise or just announce you're back.
 3. Otherwise: pick up where you left off
 
 ## Getting Started

codev-skeleton/protocols/pir/consult-types/pr-review.md

@@ -57,6 +57,7 @@ KEY_ISSUES:
 - **DO** flag obvious problems the human reviewer at the gate might have missed
 - **DO NOT** redesign the approach — that was settled at `plan-approval` and validated at `dev-approval`
 - **DO NOT** demand changes the human reviewer already accepted at the `dev-approval` gate (the human ran the code and approved it; you didn't)
+- **DO NOT** flag the syntax of `git diff` examples that appear in review-file prose (e.g., `git diff ci..HEAD` inside a "Files Changed" caption or "How to Test Locally" section). Quoted diff syntax is documentation, not a command. Apply two-dot/three-dot scrutiny only to diffs you compute yourself.
 
 ## Notes
 

codev-skeleton/protocols/pir/prompts/implement.md

@@ -17,14 +17,16 @@ Implement the approved plan, write tests, and pause at the `dev-approval` gate s
 
 Run `porch next {{project_id}}`. If the response is `gate_pending` on `dev-approval`, the code is already written and you're awaiting review. In that case:
 
-1. Resolve your repo's default branch (falls back to `main` if `origin/HEAD` isn't set):
+1. Resolve your repo's default branch and the merge-base. The merge-base anchors the diff at the branch's fork point, so commits the base branch picked up *after* you branched don't show up as phantom "scope creep". (`DEFAULT_BRANCH` falls back to `main` if `origin/HEAD` isn't set.)
 
    ```bash
-   DEFAULT_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||' || echo main)
+   DEFAULT_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||')
+   DEFAULT_BRANCH=${DEFAULT_BRANCH:-main}
+   MERGE_BASE=$(git merge-base "$DEFAULT_BRANCH" HEAD)
    ```
 
 2. Check for feedback:
-   - `git diff "$DEFAULT_BRANCH"` — has the reviewer made any direct edits to your code?
+   - `git diff "$MERGE_BASE"` — has the reviewer made any direct edits to your code?
    - `gh issue view {{issue.number}} --comments`
    - `afx send` queue messages
 3. If feedback requires code changes: make them, re-run build + tests, recommit.
@@ -113,7 +115,7 @@ When the gate goes pending, output a short prose summary in the pane to orient t
 
 > **What changed**: 2–3 sentence summary.
 >
-> **Files**: `git diff --stat "$DEFAULT_BRANCH"` style list — paths and +/-. (Resolve `$DEFAULT_BRANCH` once per session: `DEFAULT_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||' || echo main)`.)
+> **Files**: `git diff --stat "$MERGE_BASE"` style list — paths and +/-. (Resolve `$MERGE_BASE` once per session: `DEFAULT_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||'); DEFAULT_BRANCH=${DEFAULT_BRANCH:-main}; MERGE_BASE=$(git merge-base "$DEFAULT_BRANCH" HEAD)`. Anchoring at the merge-base excludes commits the base branch picked up after you branched.)
 >
 > **Test results**: `npm run build` ✓, `npm test` ✓ (X tests, Y new).
 >

codev-skeleton/protocols/pir/prompts/review.md

@@ -38,7 +38,7 @@ Fixes #{{issue.number}}
 
 ## Files Changed
 
-Output of `git diff --stat "$DEFAULT_BRANCH"`, formatted as a list (resolve once: `DEFAULT_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||' || echo main)`):
+Output of `git diff --stat "$MERGE_BASE"`, formatted as a list (resolve once: `DEFAULT_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||'); DEFAULT_BRANCH=${DEFAULT_BRANCH:-main}; MERGE_BASE=$(git merge-base "$DEFAULT_BRANCH" HEAD)`. Anchoring at the merge-base keeps the file list scoped to *your* changes, not commits the base branch absorbed after you branched.):
 
 - `path/to/file.ts` (+12 / -3)
 - `path/to/new-file.ts` (+45 / -0)
@@ -249,7 +249,8 @@ Together with the `--pr` record from step 4a and the `--merged` record from step
 **If the PR cannot be created (e.g., merge conflicts with the default branch):**
 - Rebase on the default branch:
   ```bash
-  DEFAULT_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||' || echo main)
+  DEFAULT_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||')
+  DEFAULT_BRANCH=${DEFAULT_BRANCH:-main}
   git fetch origin "$DEFAULT_BRANCH" && git rebase "origin/$DEFAULT_BRANCH"
   ```
 - Resolve conflicts (do NOT use destructive shortcuts)

codev-skeleton/protocols/spir/builder-prompt.md

@@ -74,19 +74,19 @@ The architect MAY request a PR at any point — for spec review, mid-implementat
 Your worktree is persistent — it survives across PR merges. When the architect asks for sequential PRs (e.g., to slice a large spec into shippable pieces), use this loop:
 
 1. Cut a branch, open a PR, wait for merge
-2. After merge: `git fetch origin main && git checkout -b <next-branch> origin/main`
+2. After merge: `git fetch origin <integration-branch> && git checkout -b <next-branch> origin/<integration-branch>` — where `<integration-branch>` is the branch the architect targets PRs at (usually `main`; check the open PR's `baseRefName` if unsure)
 3. Continue to the next slice, open another PR
 4. Repeat
 
-**Important**: Do NOT run `git checkout main` — git worktrees cannot check out a branch that's checked out elsewhere. Always branch off `origin/main` via fetch.
+**Important**: Do NOT run `git checkout <integration-branch>` — git worktrees cannot check out a branch that's checked out elsewhere. Always branch off `origin/<integration-branch>` via fetch.
 
 Record PRs in status.yaml: `porch done {{project_id}} --pr <N> --branch <name>`
 Record merges: `porch done {{project_id}} --merged <N>`
 
 ## Verify Phase
 
 After the final PR merges, the project enters the **verify** phase. You stay alive through verify:
-1. Pull main into your worktree
+1. Pull the integration branch into your worktree
 2. Run `porch done {{project_id}}` to signal verification is ready
 3. The architect approves `verify-approval` when satisfied
 

codev-skeleton/protocols/spir/consult-types/pr-review.md

@@ -28,10 +28,14 @@ You are performing a final self-check during the Review phase. The builder has c
    - Are any new APIs documented?
 
 5. **PR Readiness**
-   - Is the branch up to date with main?
+   - Is the branch up to date with its base (the integration branch the PR targets)?
    - Are commits atomic and well-described?
    - Is the change diff reasonable in size?
 
+## Scope
+
+- **DO NOT** flag the syntax of `git diff` examples that appear in review-file prose (e.g., `git diff ci..HEAD` inside a "Files Changed" caption or "How to Test Locally" section). Quoted diff syntax is documentation, not a command. Apply two-dot/three-dot scrutiny only to diffs you compute yourself.
+
 ## Verdict Format
 
 After your review, provide your verdict in exactly this format:

codev/protocols/air/consult-types/pr-review.md

@@ -34,7 +34,11 @@ If the baked decisions themselves contain contradictions, do not pick one — `R
 5. **PR Quality**
    - Does the PR link to the issue?
    - Is the PR body review section informative?
-   - Is the branch up to date with main?
+   - Is the branch up to date with its base (the integration branch the PR targets)?
+
+## Scope
+
+- **DO NOT** flag the syntax of `git diff` examples that appear in review-file prose (e.g., `git diff ci..HEAD` inside a "Files Changed" caption or "How to Test Locally" section). Quoted diff syntax is documentation, not a command. Apply two-dot/three-dot scrutiny only to diffs you compute yourself.
 
 ## Verdict Format
 

codev/protocols/aspir/consult-types/pr-review.md

@@ -28,10 +28,14 @@ You are performing a final self-check during the Review phase. The builder has c
    - Are any new APIs documented?
 
 5. **PR Readiness**
-   - Is the branch up to date with main?
+   - Is the branch up to date with its base (the integration branch the PR targets)?
    - Are commits atomic and well-described?
    - Is the change diff reasonable in size?
 
+## Scope
+
+- **DO NOT** flag the syntax of `git diff` examples that appear in review-file prose (e.g., `git diff ci..HEAD` inside a "Files Changed" caption or "How to Test Locally" section). Quoted diff syntax is documentation, not a command. Apply two-dot/three-dot scrutiny only to diffs you compute yourself.
+
 ## Verdict Format
 
 After your review, provide your verdict in exactly this format:

codev/protocols/bugfix/consult-types/pr-review.md

@@ -41,7 +41,7 @@ There is **no `codev/specs/`, `codev/plans/`, or `codev/reviews/` file** for a B
 
 6. **PR Hygiene**
    - Commits use the BUGFIX format: `Fix #<N>: ...` or `[Bugfix #<N>] ...` (**not** `[Spec NNNN][Phase]`).
-   - Branch is up to date with main (or close enough for clean merge).
+   - Branch is up to date with its base (or close enough for clean merge).
    - PR is linked to the issue.
 
 ## Out of Scope (Do NOT request changes for)
@@ -54,6 +54,7 @@ The following are **not** part of the BUGFIX protocol and must **not** be cited
 - Commit format `[Spec NNNN][Phase]` — BUGFIX intentionally uses `Fix #N:` / `[Bugfix #N]`.
 - `status.yaml` fields like `build_complete: false` — porch manages `status.yaml`; the builder is **forbidden** from editing it directly. Treat porch state as informational, not a fixable issue.
 - Phase-scoping concerns — BUGFIX is a single-phase protocol; there are no plan phases to scope against.
+- **DO NOT** flag the syntax of `git diff` examples that appear in review-file prose (e.g., `git diff ci..HEAD` inside a "Files Changed" caption). Quoted diff syntax is documentation, not a command. Apply two-dot/three-dot scrutiny only to diffs you compute yourself.
 
 ## Verdict Format
 

codev/protocols/bugfix/protocol.md

@@ -278,7 +278,7 @@ git commit -m "[Bugfix #N] Test: Add regression test"
    git pull
    ```
 
-2. Verify the fix is on main:
+2. Verify the fix is on the integration branch:
    ```bash
    git log --oneline -5  # Should see the bugfix commits
    ```
@@ -324,7 +324,11 @@ Before marking PR ready, the Builder must verify:
 The "< 300 LOC" threshold is measured as **net diff** (additions + deletions):
 
 ```bash
-git diff --stat main | tail -1
+DEFAULT_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||')
+DEFAULT_BRANCH=${DEFAULT_BRANCH:-main}
+# Anchor at the merge-base so commits the base branch picked up after you
+# branched aren't counted toward this PR's LOC budget.
+git diff --stat "$(git merge-base "$DEFAULT_BRANCH" HEAD)" | tail -1
 # Example: "3 files changed, 145 insertions(+), 52 deletions(-)"
 # Net diff = 145 + 52 = 197 LOC ✓ (under 300)
 ```
@@ -480,7 +484,7 @@ afx send architect "Merged. Ready for cleanup."
 
 # 11. Architect cleans up
 git pull
-git log --oneline -3  # Verify fix is on main
+git log --oneline -3  # Verify fix is on the integration branch
 afx cleanup --issue 42
 # → Removes .builders/bugfix-42/
 # → Deletes origin/builder/bugfix-42-login-fails-when-userna

codev/protocols/maintain/consult-types/pr-review.md

@@ -28,10 +28,14 @@ You are performing a final self-check during the Review phase. The builder has c
    - Are any new APIs documented?
 
 5. **PR Readiness**
-   - Is the branch up to date with main?
+   - Is the branch up to date with its base (the integration branch the PR targets)?
    - Are commits atomic and well-described?
    - Is the change diff reasonable in size?
 
+## Scope
+
+- **DO NOT** flag the syntax of `git diff` examples that appear in review-file prose (e.g., `git diff ci..HEAD` inside a "Files Changed" caption or "How to Test Locally" section). Quoted diff syntax is documentation, not a command. Apply two-dot/three-dot scrutiny only to diffs you compute yourself.
+
 ## Verdict Format
 
 After your review, provide your verdict in exactly this format:

codev/protocols/pir/builder-prompt.md

@@ -82,7 +82,7 @@ If you encounter **pre-existing flaky tests** (intermittent failures unrelated t
 If your Claude session crashes mid-flow, Tower's `while true` loop will relaunch you with the same prompt. On startup:
 
 1. Run `porch next {{project_id}}` to learn what phase you're in
-2. If `gate_pending`: read the latest plan file (plan-approval) or `git diff "$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||' || echo main)"` (dev-approval) plus any new GitHub issue comments; check `afx send` queue. Decide whether to revise or just announce you're back.
+2. If `gate_pending`: read the latest plan file (plan-approval) or `DEFAULT_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||'); git diff "$(git merge-base "${DEFAULT_BRANCH:-main}" HEAD)"` (dev-approval) plus any new GitHub issue comments; check `afx send` queue. Decide whether to revise or just announce you're back.
 3. Otherwise: pick up where you left off
 
 ## Getting Started

codev/protocols/pir/consult-types/pr-review.md

@@ -57,6 +57,7 @@ KEY_ISSUES:
 - **DO** flag obvious problems the human reviewer at the gate might have missed
 - **DO NOT** redesign the approach — that was settled at `plan-approval` and validated at `dev-approval`
 - **DO NOT** demand changes the human reviewer already accepted at the `dev-approval` gate (the human ran the code and approved it; you didn't)
+- **DO NOT** flag the syntax of `git diff` examples that appear in review-file prose (e.g., `git diff ci..HEAD` inside a "Files Changed" caption or "How to Test Locally" section). Quoted diff syntax is documentation, not a command. Apply two-dot/three-dot scrutiny only to diffs you compute yourself.
 
 ## Notes