RISK_BYPASS: reducing opens all three gates at once, including push-past-CI
RISK_SCORES carries three independent numbers. RISK_BYPASS carries one token with no tier qualifier, and the mark hook fans it out to all three markers. So there is no way to say "this commit is risk-reducing" without also asserting it of the push and the release.
The mechanism
hooks/risk-score-mark.sh (verified on 0.18.6, lines 61-65):
reducing)
touch "${RDIR}/reducing-commit"
touch "${RDIR}/reducing-push"
touch "${RDIR}/reducing-release"
;;reducing-push is then read in hooks/git-push-gate.sh at line 43. The CI-status precondition (P208) is at line 61. So the bypass is checked eighteen lines before the thing it was never meant to bypass, and it persists for the full marker TTL against a hash that is deliberately invariant across commit and push (P054).
A bypass issued to unstick a commit hands back an open master-push gate that skips CI, for the rest of the TTL. Nothing in the emitted verdict says so.
How we found it
A deploy/** change scored commit=4 push=6: commit within appetite, push above it. The commit gate blocked on a stale higher score and the obvious unsticking move was a reducing bypass.
Your own scorer refused, and its reasoning was exactly the defect. It observed that one bypass line touches all three markers; that reducing-push is read at git-push-gate.sh line 43, ahead of both the CI-status check and the risk gate; that it persists for the full TTL against an invariant hash; and that emitting reducing to unstick the commit would therefore hand back an open master-push gate skipping both CI and the 6/25 score. In its words, that would arm precisely the unplanned production apply the exercise existed to prevent.
That is the right call. We did not take the bypass. We ran the two-run terraform plan protocol on a throwaway ref instead, which took the push tier to 4/25 on evidence. But it only held because the agent read its own hook source and reasoned about it. That is not a control. It is luck with good instincts.
In our repo the push tier arms a full-root-module production terraform apply, so the opened gate reaches live infrastructure.
Two asks, separable
1. Make the bypass tier-qualified. Either accept RISK_BYPASS: reducing-commit and write only that marker, or have the mark hook infer the tier from which of the three RISK_SCORES the verdict was actually issued against. Either shape removes the fan-out.
2. Independently: move the reducing-push check after the CI-status precondition. A risk bypass is a claim about risk. Whether the build passes is a different claim, and satisfying one should not silently satisfy the other. We would argue this holds even if the fan-out is fixed. The incident-release short-circuit is deliberately ahead of CI per JTBD-201 and that is well-reasoned, but reducing is not an incident path and does not need the same placement.
Say which shape you would take and we will send the PR.
RISK_BYPASS: reducingopens all three gates at once, including push-past-CIRISK_SCOREScarries three independent numbers.RISK_BYPASScarries one token with no tier qualifier, and the mark hook fans it out to all three markers. So there is no way to say "this commit is risk-reducing" without also asserting it of the push and the release.The mechanism
hooks/risk-score-mark.sh(verified on 0.18.6, lines 61-65):reducing) touch "${RDIR}/reducing-commit" touch "${RDIR}/reducing-push" touch "${RDIR}/reducing-release" ;;reducing-pushis then read inhooks/git-push-gate.shat line 43. The CI-status precondition (P208) is at line 61. So the bypass is checked eighteen lines before the thing it was never meant to bypass, and it persists for the full marker TTL against a hash that is deliberately invariant across commit and push (P054).A bypass issued to unstick a commit hands back an open master-push gate that skips CI, for the rest of the TTL. Nothing in the emitted verdict says so.
How we found it
A
deploy/**change scoredcommit=4 push=6: commit within appetite, push above it. The commit gate blocked on a stale higher score and the obvious unsticking move was areducingbypass.Your own scorer refused, and its reasoning was exactly the defect. It observed that one bypass line touches all three markers; that
reducing-pushis read atgit-push-gate.shline 43, ahead of both the CI-status check and the risk gate; that it persists for the full TTL against an invariant hash; and that emittingreducingto unstick the commit would therefore hand back an open master-push gate skipping both CI and the 6/25 score. In its words, that would arm precisely the unplanned production apply the exercise existed to prevent.That is the right call. We did not take the bypass. We ran the two-run terraform plan protocol on a throwaway ref instead, which took the push tier to 4/25 on evidence. But it only held because the agent read its own hook source and reasoned about it. That is not a control. It is luck with good instincts.
In our repo the push tier arms a full-root-module production
terraform apply, so the opened gate reaches live infrastructure.Two asks, separable
1. Make the bypass tier-qualified. Either accept
RISK_BYPASS: reducing-commitand write only that marker, or have the mark hook infer the tier from which of the threeRISK_SCORESthe verdict was actually issued against. Either shape removes the fan-out.2. Independently: move the
reducing-pushcheck after the CI-status precondition. A risk bypass is a claim about risk. Whether the build passes is a different claim, and satisfying one should not silently satisfy the other. We would argue this holds even if the fan-out is fixed. Theincident-releaseshort-circuit is deliberately ahead of CI per JTBD-201 and that is well-reasoned, butreducingis not an incident path and does not need the same placement.Say which shape you would take and we will send the PR.