Add provider-neutral list_pull_requests and extend conflict resolver to GitLab/ADO#320
Merged
Merged
Conversation
Contributor
|
No new code issues found. See task
Reviewed aa78c4c |
…to GitLab/ADO New list_pull_requests read action across all five source-control providers (server-filtered where the API allows, page-walked with caps and truncation warnings elsewhere; mergeable mapped from GitLab has_conflicts and ADO mergeStatus, null with a warning on GitHub lists, Gitea passthrough, Bitbucket unsupported), exposed through the manage-source-control handler and worker tool alongside repository- scoped dispatchers for automation use. First consumer: the conflict resolver now scans GitLab and Azure DevOps repositories. The GitHub scan path stays byte-identical; the neutral path trusts list-level conflict signals and falls back to single-PR reads, skips the GitHub-only idle-commit guard with documented semantics, and launches with the real provider on the payload/surface/linkage. The resolution skill checks out non-GitHub PRs with plain git fetch/checkout instead of gh. Gitea/Bitbucket stay unsupported for conflict detection (async and absent mergeable signals respectively). ADO list-payload labels are schema-tolerant but unverified live; if absent, the ADO scan is inert until a per-PR labels fetch follow-up. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- findActiveGitHubBranchWork's payload repo/branch fallback now scopes by source-control provider (legacy payloads without the field still count as github), so an active GitHub run can no longer suppress an unrelated GitLab/ADO conflict-resolution launch. - conflict-scan records exactly one combined automation outcome after both scan sections; a GitHub failure is preserved in lastError even when the provider-neutral pass succeeds. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The capability-badge test merged in #319 expected conflict_resolver to read "GitHub only"; it now declares GitHub, GitLab, and Azure DevOps. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
daniel-lxs
force-pushed
the
feat/source-control-list-pull-requests
branch
from
July 14, 2026 16:00
322e9e7 to
aa78c4c
Compare
This was referenced Jul 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
First PR of the shared "list pull requests" primitive workstream — the single missing piece behind four GitHub-only automations (identified while explaining why manager-stats is GitHub-only).
list_pull_requestsread action in the provider-neutral source-control layer, implemented for all five providers with per-provider realities surfaced honestly: GitLab/ADO filter server-side and carry conflict signals (has_conflicts/mergeStatus); Gitea page-walks with caps; Bitbucket cursor-walks with no mergeable signal; GitHub list payloads carry nomergeable(warning points toget_pull_request). Truncation always warns. Exposed via the MCP handler + worker tool and as repository-scoped dispatchers for automations.git fetch/checkoutinstead ofgh.['github','gitlab','ado']— the automations-page capability badge (Show automation destinations and provider capabilities on the automations page #319) renders this automatically.Known caveat (deliberate)
ADO label fields in list payloads are unverified against a live instance; the schema tolerates their absence with a warning. If ADO omits them, the ADO conflict scan finds no labeled candidates (inert, not broken) — the fix is a per-PR labels fetch, kept out of this PR rather than shipped unverified.
Next in workstream
PR B: per-provider
pullRequestFactssync → unlocks both auditors. PR C: review-activity analytics → unlocks manager-stats.Testing
🤖 Generated with Claude Code