Parent: #1936
Problem
planAgentMaintenanceActions sets mergeMethod: autoMaintain.mergeMethod (src/settings/agent-actions.ts:465) from the repo's settings at staging time, and this value is persisted into the pending row and replayed unchanged by pendingActionToPlanned at accept time. decidePendingAgentAction (src/services/agent-approval-queue.ts:70) does re-fetch settings fresh on accept (getRepositorySettings), but never uses the live settings.autoMaintain.mergeMethod to override the stale persisted value — it's fetched only to build the executor's autonomy/pause/dry-run context and is otherwise discarded.
Failure scenario: a maintainer changes the repo's default merge method from squash to merge (or vice versa) between when an action was staged and when they accept it. The accepted merge executes with the old, superseded method, producing a merge-commit topology on the default branch the maintainer no longer wants. Not a safety issue in the sense of merging the wrong PR, but a real config-staleness bug — notably inconsistent with how the same function already re-checks autonomy/pause/dry-run live at accept time.
Requirements
- The merge method used at accept time must reflect current repo configuration, not a staging-time snapshot.
- The head-SHA pin (which should stay frozen — it's the reviewed commit) must not be affected by this fix.
Deliverables
- In
decidePendingAgentAction, after re-fetching settings, override mergeMethod in the replayed action's params with the current settings.autoMaintain.mergeMethod for merge-class actions only, leaving other staged params (notably expectedHeadSha) untouched.
- Add a regression test: stage a merge with
mergeMethod: "squash", change the repo's autoMaintain.mergeMethod to "merge" before accept, assert the executed mergePullRequest call uses "merge".
Acceptance criteria
- A merge accepted after the repo's default merge method changes uses the new method.
- The pinned
expectedHeadSha freshness guarantee is unaffected.
Expected outcome
Accepting a staged merge always honors the repo's current merge-method configuration, matching how autonomy/pause/dry-run are already re-checked live at accept time.
Parent: #1936
Problem
planAgentMaintenanceActionssetsmergeMethod: autoMaintain.mergeMethod(src/settings/agent-actions.ts:465) from the repo's settings at staging time, and this value is persisted into the pending row and replayed unchanged bypendingActionToPlannedat accept time.decidePendingAgentAction(src/services/agent-approval-queue.ts:70) does re-fetch settings fresh on accept (getRepositorySettings), but never uses the livesettings.autoMaintain.mergeMethodto override the stale persisted value — it's fetched only to build the executor's autonomy/pause/dry-run context and is otherwise discarded.Failure scenario: a maintainer changes the repo's default merge method from
squashtomerge(or vice versa) between when an action was staged and when they accept it. The accepted merge executes with the old, superseded method, producing a merge-commit topology on the default branch the maintainer no longer wants. Not a safety issue in the sense of merging the wrong PR, but a real config-staleness bug — notably inconsistent with how the same function already re-checks autonomy/pause/dry-run live at accept time.Requirements
Deliverables
decidePendingAgentAction, after re-fetchingsettings, overridemergeMethodin the replayed action's params with the currentsettings.autoMaintain.mergeMethodfor merge-class actions only, leaving other staged params (notablyexpectedHeadSha) untouched.mergeMethod: "squash", change the repo'sautoMaintain.mergeMethodto"merge"before accept, assert the executedmergePullRequestcall uses"merge".Acceptance criteria
expectedHeadShafreshness guarantee is unaffected.Expected outcome
Accepting a staged merge always honors the repo's current merge-method configuration, matching how autonomy/pause/dry-run are already re-checked live at accept time.