forked from mosaicstack/stack
mos-dt-0andClaude Opus 5
f3c100f814
merge-gate.md says it outright: a successful merge is NOT evidence the pin worked, only the negative case is. On mosaicstack Gitea a merge against a WRONG head_commit_id has never been attempted, so every head-pinned merge to date is equally consistent with the pin working and with the pin being ignored. That is D-23's class — the queue guard "ran" and returned pass for every possible input; the pin "holds" on every merge that would have succeeded anyway. By the mission's own standard (every gate-introducing task carries a registered must-fail negative control; a gate with no proven failure path manufactures evidence) the head-pin is unregistered in substance however it reads in the runbook. Not blocking #1033: that head is coordinator-frozen with both the orchestrator and coder-mos1 holding, so there is no concurrent pusher for the pin to defend against — its protection is only load-bearing on a contested head. Raised by Mos while assigning the merge; Mos owns it and has filed it as an infra task in the D-37/D-41 cluster, to be proven before any contested-head merge. Requirement on RM-02: the negative-control clause must cover provider-side enforcement mechanisms, not only in-repo checks. "The API accepted our parameter" is not evidence the API honours it — the same true-answer-to-a-different-question shape as D-24 and D-38. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>