HAL9000
67617f6a6e
CI / build (push) Successful in 24s
CI / lint (push) Successful in 25s
CI / helm (push) Successful in 31s
CI / quality (push) Successful in 33s
CI / typecheck (push) Successful in 47s
CI / security (push) Successful in 1m3s
CI / benchmark-regression (push) Has been skipped
CI / push-validation (push) Successful in 46s
CI / e2e_tests (push) Successful in 4m25s
CI / integration_tests (push) Successful in 4m26s
CI / unit_tests (push) Successful in 4m55s
CI / docker (push) Successful in 10s
CI / coverage (push) Successful in 10m10s
CI / status-check (push) Successful in 1s
CI / benchmark-publish (push) Has been cancelled
The forgejo_merge_pull_request MCP tool returns 'Pull request merged successfully' even when the merge silently fails (e.g. branch behind base). This caused the PR merge supervisor to post false 'Automatically merged' comments on PRs that were never actually merged (e.g. #6726, #6695, #5276, #6571). Three interconnected fixes: - pr-merge-pool-supervisor: Always verify merge via forgejo_get_pull_request_by_index (merged==true, state==closed) before posting success comments. Check merge_base vs base.sha before merge and auto-rebase when branch is behind. Handle silent merge failures with rebase-and-retry on next cycle. - shared/merge_safety: safe_merge_pr() now verifies merge completed by checking PR state after the API call. Returns failure when PR is still open despite the tool claiming success. - implementation-worker: Add rebase-before-merge check and verification rules to the ready-to-merge workflow. ISSUES CLOSED: #6726