Class
Pre-existing over-block (cardinal-sin direction) on the merge-guard — a #1064-class gated-but-unmintable state on the API-based PR-merge spelling. Surfaced by the adversarial security review of PR #1095 (#1087/#1086 cross-leg completion); proven base-identical to origin/main (read=DENY, mint=0 on both base and HEAD), so it is NOT introduced by #1095 — it was correctly excluded from that PR's charter and filed here.
The gap
gh api -X PUT /repos/:o/:r/pulls/:n/merge (and the curl -X PUT .../pulls/N/merge equivalent) is gated-but-unmintable:
- The read floor classifies it dangerous → the operator gets an approval prompt (
read = DENY without a token).
- The mint side cannot produce a token for it (
mint = 0) — the API-merge target is not enumerable by the mint's _target_value.
Net: a faithful API-based merge command can never be authorized — approving it mints nothing, so it stays permanently blocked. Under the honest-mistake threat model, a faithful single-command click must always mint and merge; a gated-but-unmintable state is a permanent over-block — the inviolable/cardinal-sin direction — exactly the #1064 pattern (#1064 was the lease-push variant; this is the API-merge variant).
Why filed separately (not a #1095 blocker)
The adversarial reviewer ran a base-vs-HEAD delta and proved the behavior byte-identical on origin/main — #1095 does not change it. #1095's charter is #1087+#1086; per the tracked-follow-up discipline (cf. #1085 → #1086/#1087), a pre-existing over-block on a different surface is a standalone follow-up, not a merge blocker.
Fix direction
Bring the mint side's target enumeration (_target_value / _is_api_form recognition) to parity with the read floor for the API-merge spelling, so an approved API-merge command mints a token that authorizes its own faithful execution — closing the gated-but-unmintable over-block. Same shape as the #1064/#1077 mint/read-parity fixes in the v4.4.51 batch. Requires the standard no-new-under-block sweep (the fix must not make a non-faithful API-merge mintable).
Related
Class
Pre-existing over-block (cardinal-sin direction) on the merge-guard — a #1064-class gated-but-unmintable state on the API-based PR-merge spelling. Surfaced by the adversarial security review of PR #1095 (#1087/#1086 cross-leg completion); proven base-identical to
origin/main(read=DENY, mint=0 on both base and HEAD), so it is NOT introduced by #1095 — it was correctly excluded from that PR's charter and filed here.The gap
gh api -X PUT /repos/:o/:r/pulls/:n/merge(and thecurl -X PUT .../pulls/N/mergeequivalent) is gated-but-unmintable:read = DENYwithout a token).mint = 0) — the API-merge target is not enumerable by the mint's_target_value.Net: a faithful API-based merge command can never be authorized — approving it mints nothing, so it stays permanently blocked. Under the honest-mistake threat model, a faithful single-command click must always mint and merge; a gated-but-unmintable state is a permanent over-block — the inviolable/cardinal-sin direction — exactly the #1064 pattern (#1064 was the lease-push variant; this is the API-merge variant).
Why filed separately (not a #1095 blocker)
The adversarial reviewer ran a base-vs-HEAD delta and proved the behavior byte-identical on
origin/main— #1095 does not change it. #1095's charter is #1087+#1086; per the tracked-follow-up discipline (cf. #1085 → #1086/#1087), a pre-existing over-block on a different surface is a standalone follow-up, not a merge blocker.Fix direction
Bring the mint side's target enumeration (
_target_value/_is_api_formrecognition) to parity with the read floor for the API-merge spelling, so an approved API-merge command mints a token that authorizes its own faithful execution — closing the gated-but-unmintable over-block. Same shape as the #1064/#1077 mint/read-parity fixes in the v4.4.51 batch. Requires the standard no-new-under-block sweep (the fix must not make a non-faithful API-merge mintable).Related