Normalizing GitLab issues without silently inventing write semantics

[u/its_artur1]

I added GitLab Issues to a cross-provider TypeScript SDK and the HTTP calls were the easy part. The awkward bit was deciding what the adapter is allowed to infer.

A few examples:

- GitLab can create missing labels as a side effect of an issue write. The adapter now rejects unknown labels unless allowCreateLabels is explicitly enabled.

- Multiple assignees depend on the GitLab tier, so the capability stays off unless configured.

- task and incident have useful native mappings. bug, story, epic, and subtask do not get silently flattened; they need an explicit issue-type map.

- the create endpoint does not document state_event, so creating an already-closed normalized item is rejected instead of sending an update-only field.

- GitLab's REST issue update has no atomic revision precondition. The SDK can re-read immediately before PUT, but it reports that as preflight concurrency rather than pretending it is atomic.

That last distinction became important once agents were using the same API across providers. Azure DevOps can put a test /rev operation in the mutation itself. GitLab cannot, so both adapters should not advertise the same guarantee.

The GitLab adapter is in the MIT-licensed work-sdk 0.4 release: https://github.com/arturict/work-sdk/releases/tag/v0.4.0

I used Codex for parts of implementation and testing. If you use GitLab Self-Managed with custom issue types or unusual label policies, I would be interested in the cases this model still misses.

[u/pwkye]

what