Existing proposals
Problem
Agent Zero currently centers its source-control workflows around GitHub. That limits adoption for teams using GitLab, Bitbucket, self-hosted Git platforms, or mixed environments. The agent runtime should not depend on GitHub-specific event shapes, authentication, review primitives, or pull-request terminology.
Parent roadmap: #5
Desired outcome
Deliver a provider-neutral source-control integration layer with GitHub as the first adapter and additional providers implemented behind the same contracts.
Initial provider targets:
- GitHub / GitHub Enterprise
- GitLab / GitLab Self-Managed
- Bitbucket Cloud
- Bitbucket Data Center
- Gitea / Forgejo where practical
Acceptance goals:
- define provider-neutral repository, branch, review, comment, status/check, issue, and merge-request/pull-request contracts
- move GitHub-specific behavior behind an adapter boundary
- normalize inbound webhook/event payloads before they reach the agent runtime
- support provider-specific authentication without leaking credentials into agent state or prompts
- map equivalent concepts such as pull requests, merge requests, reviews, approvals, checks/pipelines, and issue references
- preserve the same find → fix → verify workflow regardless of provider
- allow one deployment to connect repositories from multiple providers
- expose provider capability detection so unsupported features degrade explicitly instead of silently
- keep provider-specific URLs, IDs, and metadata at the integration boundary
- add conformance tests that every provider adapter must pass
Likely area
GitHub adapter
The current feature template names the existing area as GitHub adapter; this milestone should evolve that boundary into a generic source-control provider package with GitHub, GitLab, Bitbucket, and other adapters underneath it.
Safety and compatibility
High impact. Repository permissions, branch protections, approval semantics, webhook verification, merge rules, and status APIs differ between providers. Agent Zero must never infer that one provider's authorization model applies to another. Provider credentials must remain outside model prompts and task logs. Read-only/observe mode and write authorization must behave consistently across all adapters.
Alternatives considered
Adding GitLab or Bitbucket logic directly beside GitHub-specific code was rejected because that would duplicate business logic and leak provider semantics into the agent runtime. Maintaining separate agent implementations per source-control platform was also rejected. A capability-aware provider abstraction with conformance tests is preferred.
Existing proposals
Problem
Agent Zero currently centers its source-control workflows around GitHub. That limits adoption for teams using GitLab, Bitbucket, self-hosted Git platforms, or mixed environments. The agent runtime should not depend on GitHub-specific event shapes, authentication, review primitives, or pull-request terminology.
Parent roadmap: #5
Desired outcome
Deliver a provider-neutral source-control integration layer with GitHub as the first adapter and additional providers implemented behind the same contracts.
Initial provider targets:
Acceptance goals:
Likely area
GitHub adapter
The current feature template names the existing area as GitHub adapter; this milestone should evolve that boundary into a generic source-control provider package with GitHub, GitLab, Bitbucket, and other adapters underneath it.
Safety and compatibility
High impact. Repository permissions, branch protections, approval semantics, webhook verification, merge rules, and status APIs differ between providers. Agent Zero must never infer that one provider's authorization model applies to another. Provider credentials must remain outside model prompts and task logs. Read-only/observe mode and write authorization must behave consistently across all adapters.
Alternatives considered
Adding GitLab or Bitbucket logic directly beside GitHub-specific code was rejected because that would duplicate business logic and leak provider semantics into the agent runtime. Maintaining separate agent implementations per source-control platform was also rejected. A capability-aware provider abstraction with conformance tests is preferred.