Context
Ctx exposes a first-class f.gitlab helper, packages/surface/src/helpers/providers.ts:95-100 marks GitLab supported: true in exactly the same shape as GitHub at lines 89-94, and the trigger surface is generous — 50-plus sources including issue_open, issue_update, merge_request_*, pipeline_*. All of that reads as parity.
The writeback catalog does not match. Per the Relayflows v2 Field Report (2026-09-18, Julian Fann), who dumped it while building a GitLab-sourced factory:
| Provider |
Writeback resources |
github |
issues, pull-requests, issue-comments, replies, refs, merge, close-pull-request, ... |
gitlab |
comments, discussions |
f.gitlab can post to an issue or an MR. It cannot list issues, read an issue, or open a merge request — which is every read a GitLab-sourced factory needs. They used glab for all of it, including the write-back, rather than split one journalled comment across two mechanisms.
What to change
Either is a fine resolution; the status quo is not, because nothing signals the gap at the point an author reaches for the helper.
- Reach parity on
issues and merge_requests for f.gitlab, at least list/read/create.
- Make the gap visible. If comment-only is the intended roadmap position, say so where an author looks: a
supported value that distinguishes full from partial, a note in the provider catalog, and a refusal from f.gitlab.<unavailable resource> that names what is available rather than failing generically.
Acceptance
- Either
f.gitlab can list issues, read an issue, and open a merge request; or reaching for one of those produces a refusal naming the available resources, and the provider catalog distinguishes partial support from full.
- A GitLab-sourced flow does not need a second mechanism (
glab) to perform its reads without the author first discovering this by dumping a catalog.
Out of scope
- Other partially-supported providers, unless the same catalog change covers them.
- Trigger-side work; triggers are already good.
Context
Ctxexposes a first-classf.gitlabhelper,packages/surface/src/helpers/providers.ts:95-100marks GitLabsupported: truein exactly the same shape as GitHub at lines 89-94, and the trigger surface is generous — 50-plus sources includingissue_open,issue_update,merge_request_*,pipeline_*. All of that reads as parity.The writeback catalog does not match. Per the Relayflows v2 Field Report (2026-09-18, Julian Fann), who dumped it while building a GitLab-sourced factory:
githubgitlabf.gitlabcan post to an issue or an MR. It cannot list issues, read an issue, or open a merge request — which is every read a GitLab-sourced factory needs. They usedglabfor all of it, including the write-back, rather than split one journalled comment across two mechanisms.What to change
Either is a fine resolution; the status quo is not, because nothing signals the gap at the point an author reaches for the helper.
issuesandmerge_requestsforf.gitlab, at least list/read/create.supportedvalue that distinguishes full from partial, a note in the provider catalog, and a refusal fromf.gitlab.<unavailable resource>that names what is available rather than failing generically.Acceptance
f.gitlabcan list issues, read an issue, and open a merge request; or reaching for one of those produces a refusal naming the available resources, and the provider catalog distinguishes partial support from full.glab) to perform its reads without the author first discovering this by dumping a catalog.Out of scope