[Feature] Support GitLab (merge requests + issues) as a first-class provider alongside GitHub

[CrystalMethod]

Summary

opencode-swarm currently integrates exclusively with GitHub through the gh CLI for every PR/issue workflow. Many teams use GitLab — including self-hosted instances — with the separate glab CLI. This issue proposes making GitLab a first-class, parity-supported provider across the same workflows GitHub enjoys, selected automatically from the repository remote or by explicit configuration.

Motivation

• Teams on GitLab (gitlab.com or self-hosted) cannot use the PR/MR + issue workflows: /swarm pr-review, pr-feedback, issue, ci-monitor, pr-subscribe, pr-unsubscribe, publication recording, and event delivery.
• Users should be able to choose which provider/CLI to use, with the provider auto-detected per repository.
• gh and glab differ in hostname, URL shape, CLI flags, and JSON schemas — not a trivial alias swap.

Key requirements / facts from brainstorming

GitHub vs GitLab differences driving the design

• Hostname: github.com vs gitlab.com or any self-hosted instance host (variable — must be derived, not assumed).
• URL shape: PR/MR owner/repo/pull/N vs owner/repo/-/merge_requests/N; issues owner/repo/issues/N vs owner/repo/-/issues/N.
• CLI: gh pr view vs glab mr view; flags differ (--head/--base vs --source-branch/--target-branch); JSON field names/schemas differ (GitHub synthesizes statusCheckRollup, reviewDecision, mergeStateStatus).
• Remote: git@github.com:owner/repo.git vs git@gitlab.com:owner/repo.git.

Functional requirements

• Support gitlab.com and self-hosted GitLab instances; the instance host is derived from the git remote, the explicit base_url config, or configuration — never assumed fixed public host.
• Provider auto-detection from the git remote plus explicit configuration (github | gitlab | auto, default auto); explicit config overrides auto-detection.
• Fail closed when undeterminable: ambiguity (mixed/multiple remotes), a generic self-hosted host matching no provider, or no workflow-relevant remote must NOT silently assume a provider — they require explicit provider configuration.
• Full functional parity across the workflow surface: PR/MR reference resolution, publication recording, unsubscribe, issue ingestion, PR review workflow + gates, PR feedback workflow + gates, subscription + event delivery, and CI monitoring.
• Preserve every existing security control for every provider and origin: HTTPS-only, private/localhost-host rejection, IDN homograph protection, credential stripping, bounded URL length, control-character sanitization. The base_url override is NOT a trust whitelist — it must never bypass any security guard.
• Honest capability reporting: where GitLab lacks an equivalent that GitHub synthesizes (e.g. aggregated status/review-state fields), surface a clear "not supported / unavailable" result — never fabricate or substitute a false-positive equivalent.

Proposed architecture

Layered and reversible (core → adapter → workflow):

1. Layer 1 — Provider core: shared provider model/registry with concrete github/gitlab providers; a provider-aware hardened CLI binary resolver (same provenance hardening as the gh resolver, for glab, with an env-only override + version probe); remote-based auto-detection; and configuration (provider selection + base_url).
2. Layer 2 — Provider-aware URL validation + core commands: validate provider-specific resource URL shapes for the active provider while preserving all security controls; make issue, PR/MR reference, publication-record, and unsubscribe flows provider-aware.
3. Layer 3 — Workflow parity: make PR review/feedback workflows + gates, subscription + event delivery, auto-subscribe, and CI monitoring provider-aware, surfacing honest "not available" where GitLab lacks an equivalent.

Acceptance criteria

• GitLab MR URL (https://<host>/owner/repo/-/merge_requests/N) and issue URL (https://<host>/owner/repo/-/issues/N) are accepted and operated on by the corresponding workflows.
• Self-hosted GitLab is handled with the correct instance host.
• Auto-detection selects GitLab for gitlab.com and clear GitLab-indicating hosts; ambiguous/generic/mixed-remote/no-remote cases fail closed requiring explicit config.
• Every security control applies equally to every provider and to the base_url override.
• Workflows surface honest "not supported / unavailable" for fields GitLab cannot synthesize.

Appendix — built with opencode-swarm itself

I've started developing this feature using opencode-swarm itself — eat-your-own-dogfood, in the truest sense. The specification, provider model, and layered architecture above were produced through opencode-swarm's brainstorm/plan/critic/execute workflow, and the implementation is being built the same way. Honestly, though, this is more than a good-first-issue: it touches deep, security-critical integration points (the hardened CLI resolvers, URL validation, PR review/feedback gates, subscription and event delivery), each surrounded by hard-won engineering invariants. It deserves a careful review and a committed maintainer — the kind of change that should be implemented deliberately and validated thoroughly, not treated as a quick win.

[zaxbysauce]

Verified against the code — the issue's premise is accurate. GitHub is hardwired at every integration point it lists: validateAndSanitizeGithubUrl and parseGitRemoteUrl in src/commands/_shared/url-security.ts accept only github.com URLs and remotes (HTTPS and SSH forms); the PR/issue command parsers construct https://github.com/... literals; the PR event delivery, feedback queue, subscriber, and workflow-gate normalization paths reject anything that isn't a github.com host with a /pull/N path; publication recording requires a canonical GitHub PR URL; and every process invocation flows through the hardened gh resolver with GitHub-synthesized fields (statusCheckRollup, reviewDecision, mergeStateStatus) that the review gates and monitor explicitly depend on. The only GitLab references today are a token-redaction pattern and a knowledge-tag host entry — no provider support exists.

The layered proposal in the issue matches the actual seams in the code, and I agree with its self-assessment: this is a deliberate, multi-layer change touching security-critical invariants (env-only binary override, version-probed resolution, HTTPS-only, private/localhost-host rejection, IDN protection, credential stripping, bounded URLs, control-character sanitization). The fail-closed auto-detection requirement and the rule that base_url must never bypass any guard are the right calls — an alias swap for glab would silently break the URL validators and the gate paths that hard-require github.com.

Recommended sequencing if accepted: start with the provider core (a provider model/registry, a glab resolver built to the same contract as src/utils/gh-executable.ts, remote-based detection with explicit-config override, and config schema additions), since the URL-validation and workflow layers both consume it. Capability-honest reporting matters too: the review/monitor gates currently treat reviewDecision/mergeStateStatus as load-bearing, so GitLab parity requires surfacing 'not available' rather than fabricating equivalents. This deserves a design review and a committed maintainer before implementation begins — it is not a quick win, and the issue says as much itself.