bot-resolve-conflicts: a git commit failure can bypass the escalation marker (re-dispatch risk)

[bpamiri]

Summary

In the loop-safe verify step added in #2847, the resolver completes the merge with git commit --no-edit, then escalates (posts the conflict-attempted marker + conflict:needs-human label) if no new commit exists. If git commit --no-edit itself exits non-zero (e.g. a pre-commit hook rejects it), set -euo pipefail aborts the step before the escalation block runs — so no marker is posted and the freshen sweep can re-dispatch the resolver.

Likelihood

Very low: CI checkouts have no executable git hooks, and timeout-minutes: 60 is a backstop. Flagged by Reviewer A on #2847 as a non-blocking, theoretical edge. Tracking so it isn't lost.

Where

The Verify resolution, push, or escalate (loop-safe) step in .github/workflows/bot-resolve-conflicts.yml.

Acceptance criteria

• Any failure on the resolve path (including a failed commit) leaves a conflict-attempted marker so freshen never re-dispatches indefinitely.
• A trap-on-exit that posts the marker, or restructuring so the commit failure falls through to the escalation path, would both satisfy this.

Priority: low. Surfaced during the #2847 review cycle.

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

Suspected layer

cli — though the actual file is a bot workflow, not framework code. Canonical reference is .ai/wheels/wheels-bot.md; none of the .ai/wheels/<layer>/ docs cover GitHub Actions YAML directly.

Fix sketch

Edit the Verify resolution, push, or escalate (loop-safe) step in .github/workflows/bot-resolve-conflicts.yml (around line 138). Two satisfying shapes per the acceptance criteria: (a) install a trap '<post-marker-and-label>' EXIT at the top of the step body so any non-zero exit — including a hook-rejected git commit --no-edit — still posts the conflict-attempted marker and applies conflict:needs-human before the step aborts; or (b) restructure so the commit invocation is if \! git commit --no-edit; then <escalate>; fi rather than a bare statement, letting set -euo pipefail ignore that one failure and fall through to the existing escalation block. The trap form is more defensive (covers any future commands added to the step too); the conditional is more localized. Either change is single-file, single-step.

Confidence: medium

Fix shape is mechanical, but the change touches bot-pipeline infrastructure that orchestrates the bot itself — a wrong edit affects every conflict-resolution run — and the reporter flagged it as low-priority/non-blocking, so I'm not rating this high.

<!-- wheels-bot:triage:2849 -->
<!-- wheels-bot:triage-class:bug -->
<!-- wheels-bot:triage-confidence:medium -->

[wheels-bot]

Wheels Bot — Fix on hold for human review

The proposed fix touches a sensitive area (.github/workflows/bot-resolve-conflicts.yml) and the bot's safety net requires a human in the loop before any code is written.

GitHub Apps need an explicit workflows permission to push edits to files under .github/workflows/, and the wheels-bot[bot] App does not currently hold it — the push was rejected by GitHub:

remote rejected: refusing to allow a GitHub App to create or update workflow
`.github/workflows/bot-resolve-conflicts.yml` without `workflows` permission

The fix shape from the triage is sound and would land in three pieces:

1. New script tools/bot/finalize-resolution.sh — owns the local verify-or-finalize logic (the part the workflow used to inline). Drops set -e and wraps git commit --no-edit in an if ! block so a pre-commit hook rejection aborts the merge in place and falls through to exit 1.
2. Workflow edit in .github/workflows/bot-resolve-conflicts.yml — the "Verify resolution, push, or escalate (loop-safe)" step delegates to bash tools/bot/finalize-resolution.sh and treats any non-zero exit as escalation. The marker (wheels-bot:conflict-attempted:<pr>) and conflict:needs-human label always land.
3. Regression spec vendor/wheels/tests/specs/cli/BotResolveConflictsLoopSafeSpec.cfc — asserts the script has no unguarded git commit --no-edit, that it uses if ! or a trap, and that the workflow delegates to the script and keeps the marker on the escalation path.

This is mechanical to apply manually, or can be unblocked by granting wheels-bot[bot] the workflows permission so the bot can ship workflow-targeting PRs in future.