The prose gate diffs against the base tip rather than the merge base, so another change's lines can fail this pull request #1658

The prose gate's CI scope can include lines somebody else merged, and with a refusing rule in the default set that now fails a pull request over them.

.github/workflows/validate-task.yml passes base: ${{ github.event.pull_request.base.sha }} to the prose-gate action. That is the base branch's tip at the moment the event fired, while actions/checkout builds the pull request's merge ref. Anything that lands on the base between the event and the run therefore sits inside the diff the gate reads as this pull request's added lines.

Until now the consequence was bounded: the rules in the default set report on prose shape, so the worst case was a finding on a line somebody else wrote, on a file this pull request also touched. comment-added changes the consequence, because its remedy is deleting the line or labeling the pull request, and neither is right for a line another change merged.

The correct base is the merge base between the head and the base branch, git merge-base origin/<base> HEAD, which is what scripts/local_review.py and the local-strict-review skill already use for exactly this reason. The action resolves refs itself and retries on replication lag, so it has the history to compute one.

Worth checking before changing it

• Whether the composite action should compute the merge base itself, which keeps every caller correct with no caller change, or take it from the caller, which keeps the action's input honest about what it is given.
• A downstream repository consuming the action at a pin keeps the current behavior until the pin moves, so the two halves disagree in the interim, per docs/reusable-workflows.md.

Found by the local review pass on the comment-added branch. The scope semantics predate that change, so it blocks nothing there.