bug(pr_merge): skip_train: true on GitLab returns platform_unsupported and SKIPS the merge — contradicts /wavemachine skill spec

[bakeb7j0]

Summary

mcp__sdlc-server__pr_merge({number, skip_train: true}) on GitLab returns {ok: true, platform_unsupported: true, hint: "merge trains are auto-managed by GitLab; skip_train is GitHub-merge-queue-only"} without performing the merge. This contradicts the /wavemachine skill spec, which says the flag should be silently dropped by the adapter and the merge should still proceed.

Environment

• Where observed: /wavemachine kahuna gate auto-merge of !72 (kahuna→release/2.2.0, Plan feat(wave-mcp): implement flight_overlap + lib/flight_overlap #74) on analogicdev/internal/tools/wellofsouls, 2026-05-06
• Project: GitLab, merge_trains_enabled: false, merge_method: merge

Steps to Reproduce

1. Open a kahuna→release/N.N.N MR on a GitLab project.
2. Call mcp__sdlc-server__pr_merge({number: <iid>, skip_train: true}).
3. Observe: {"ok": true, "platform_unsupported": true, "hint": "..."} — merged field absent. MR is NOT merged.
4. Retrying without skip_train succeeds ({ok: true, merged: true, ...}).

Expected Behavior (per /wavemachine skill spec, "Platform note: skip_train semantics")

GitLab (merge train): skip_train is a no-op. ... The flag is silently dropped by the adapter; the kahuna→main MR enrolls in the train and waits for the train cycle to complete. ... Net effect: kahuna→main lands when the train says it lands

pr_merge({number, skip_train: true}) on GitLab should:

• Drop the flag silently
• Proceed with the merge (subject to project merge-method settings: queue / train / direct)
• Return {ok: true, merged: true, ...} with possibly a warnings: ["skip_train ignored on GitLab"] for visibility

The current shape — eager platform_unsupported return without performing the merge — forces every GitLab caller to handle this as a special case and retry without the flag, which is exactly the friction the skill spec was trying to avoid.

Actual Behavior

{"ok": true, "platform_unsupported": true, "hint": "merge trains are auto-managed by GitLab; skip_train is GitHub-merge-queue-only"}

No merge happened. The kahuna MR sat open until I retried pr_merge({number}) without skip_train, which then succeeded.

Severity

severity::major — /wavemachine's gate auto-merge passes skip_train: true unconditionally per the skill body's R-23 + non-negotiables. The current adapter behavior breaks the autopilot's all-green-merge path on every GitLab project.

Workaround

Conditional invocation: if (platform == "gitlab") pr_merge({number}); else pr_merge({number, skip_train: true});. But this defeats the point of the skill spec's "pass unconditionally; adapter handles asymmetry" contract.

Acceptance Criteria

• pr_merge({number, skip_train: true}) on GitLab silently drops skip_train and proceeds to merge.
• Response shape matches the GitHub-merge-queue-disabled response shape: {ok: true, merged: true, merge_method, pr_state: "MERGED", url, merge_commit_sha, warnings: [...possibly note skip_train ignored...]}.
• /wavemachine skill body's "Platform note: skip_train semantics" remains accurate.
• Regression test: GitLab fixture, pr_merge({skip_train: true}) returns merged: true.

Dependencies

• None.