Decide: should pr-status.sh drive GitLab merge requests, or does netresearch-gitlab own that driver?

[CybotTM]

The question

Should pr-status.sh speak GitLab too, or is the boundary stated in #250 the end state?

This needs a decision rather than a patch, which is why it is not folded into #250: the boundary there is closed and measured, and adding a second forge to this script is a different commitment.

What option 1 would mean

pr-status.sh detects the host and, for GitLab, reads merge_requests/<iid> — detailed_merge_status, which unlike GitHub's mergeStateStatus names the reason — plus /discussions for unresolved threads, and emits the same NEXT: vocabulary. The merge and rebase steps map to glab mr merge and glab mr rebase.

The argument for it: pr-status.sh is the only merge-gate and watch driver in the fleet, and half the fleet's work happens on git.netresearch.de. Every GitLab MR in the session that produced this issue was watched by a hand-rolled glab api poll loop written per task — exactly the shape the skill's own references/merge-gate-watcher.md warns against.

The argument against: two forges in one script means two gate vocabularies to keep in step, and netresearch-gitlab already owns GitLab conventions — the driver could live there instead and reuse this script's ladder rather than its code.

What would settle it

Whether GitLab MR cycles are meant to be driven by this skill at all, or by netresearch-gitlab. That is an ownership question about the two skills, not a technical one about the script.

Assisted by claude-code:claude-opus-5 — Session

[CybotTM]

Decided in favour of option 1, with a boundary: vendor behaviour belongs here, instance behaviour stays in the netresearch-* skills. GitLab's own semantics are true of any GitLab and have no other home, because no gitlab-workflow skill exists; git.netresearch.de as a host, our CI components and our group names are a different thing and do not move.

The separable half is already out: #334 removes the four places where this public skill named an internal one — the description, the body paragraph, and both die() messages in pr-status.sh, which is the line a stranger sees when they point the script at their own GitLab.

The mapping, before any code

The risk in a second forge is two gate vocabularies. pr-merge.sh and the watcher consume .next.action, so GitLab has to land on the rungs that exist rather than bring its own.

The vocabulary is not guessed: introspected from the running instance's GraphQL schema, DetailedMergeStatus has 24 values.

glab api --hostname git.netresearch.de -X POST graphql \
  -f query='{ __type(name: "DetailedMergeStatus") { enumValues { name description } } }'

detailed_merge_status	rung	why
MERGEABLE	merge	the gate is open
UNCHECKED, CHECKING, PREPARING, APPROVALS_SYNCING	wait	the server has not decided yet
CI_STILL_RUNNING	await-checks
CI_MUST_PASS	fix-ci / triage-ci	split on head_pipeline.status, the same way the GitHub path splits a red check from an undispatched one
CI_STILL_RUNNING + failed job	fix-ci
DISCUSSIONS_NOT_RESOLVED	resolve-threads	blocking_discussions_resolved is the aggregate
REQUESTED_CHANGES	address-comments
NOT_APPROVED	request-review	GitLab approvals are the reviewDecision equivalent
DRAFT_STATUS	ready	the rung already exists and means exactly this
CONFLICT	resolve-conflicts
NEED_REBASE	rebase
NOT_OPEN	none	merged or closed
COMMITS_STATUS, BLOCKED_STATUS, LOCKED_PATHS, LOCKED_LFS_FILES, SECURITY_POLICIES_VIOLATIONS	blocked	a human decides; the reason string carries the detail
EXTERNAL_STATUS_CHECKS, SECURITY_POLICY_PIPELINE_CHECK	await-checks
MERGE_TIME	wait	merge train / scheduled window

Two values have no GitHub counterpart at all: JIRA_ASSOCIATION (title or description must reference a Jira issue) and TITLE_NOT_MATCHING (title fails a required regex). Both are "the merge request's own text fails a server-side rule", both need a human, and neither is worth a new rung — they map to blocked with the reason string saying which. That keeps ACTIONABLE closed and pr-merge.sh forge-blind, which was the thing worth protecting.

Nothing in the table needs a rung that does not exist, so the ladder stays as it is.

What the reference already carries

references/pull-request-workflow.md § GitHub only has the field mapping (merge_status + has_conflicts, /discussions → notes[0].resolved, /approvals, /protected_branches) and the reply-and-resolve recipe. The work is the executable path in pr-status.sh, not the knowledge.

Assisted by claude-code:claude-opus-5 — Session