A surviving mutant un-gates the single-operator box: AT_RISK -gt 0 is not pinned #78

Closed
opened 2026-07-19 23:59:23 +00:00 by dan-claude-bot · 0 comments
dan-claude-bot commented 2026-07-19 23:59:23 +00:00 (Migrated from github.com)

Non-blocking finding from claude-bot-andresmgsl's review of #73, filed so it does not rot in a PR thread.

The surviving mutant

Changing the gate condition in commands/users-apply.sh:

-if [ "$AT_RISK" -gt 0 ]; then
+if [ "$AT_RISK" -gt 1 ]; then

passes all 419 tests.

That mutation silently un-gates the single-operator box — a users file that revokes the last remaining operator would proceed without confirmation. For small teams that is not an edge case, it is the common one, and it is the most consequential instance of exactly what #65 is about.

Why the existing pins miss it

Two pins cover the neighbourhood and neither bites here:

  • The condition-line grep pins the gate's trigger (${#USERS[@]} -eq 0 && -r $LEDGER), not the at-risk comparison.
  • The deferred-threshold negative grep (which keeps #65's N-of-M question deferred) only matches -gt/-ge against a $-variable, so a literal 1 slips through.

So the tests pin that the gate exists and that no threshold was introduced, but not where the gate's floor sits.

Suggested pin

One line, in the house grep-pin style:

check "users apply: one at-risk operator is enough to gate" 0 "" \
  grep -qF 'if [ "$AT_RISK" -gt 0 ]; then' "$ROOT/commands/users-apply.sh"

Why filed rather than fixed in #73

#73 had three head-current approvals and the code is correct — this pins against future regression rather than fixing a live defect. The reviewing bot's framing was "fine as a follow-up; it does not block a correct implementation."

Worth doing soon, though: it is one line, and the thing it protects is the gate's entire reason for existing.

Refs

#73 (where it was found), #65 (the parent issue; its N-of-M threshold remains deliberately deferred)

Non-blocking finding from `claude-bot-andresmgsl`'s review of #73, filed so it does not rot in a PR thread. ## The surviving mutant Changing the gate condition in `commands/users-apply.sh`: ```diff -if [ "$AT_RISK" -gt 0 ]; then +if [ "$AT_RISK" -gt 1 ]; then ``` **passes all 419 tests.** That mutation silently un-gates the single-operator box — a users file that revokes the last remaining operator would proceed without confirmation. For small teams that is not an edge case, it is the common one, and it is the most consequential instance of exactly what #65 is about. ## Why the existing pins miss it Two pins cover the neighbourhood and neither bites here: - The condition-line grep pins the gate's *trigger* (`${#USERS[@]} -eq 0 && -r $LEDGER`), not the at-risk *comparison*. - The deferred-threshold negative grep (which keeps #65's N-of-M question deferred) only matches `-gt`/`-ge` against a `$`-variable, so a literal `1` slips through. So the tests pin *that* the gate exists and *that* no threshold was introduced, but not *where* the gate's floor sits. ## Suggested pin One line, in the house grep-pin style: ```sh check "users apply: one at-risk operator is enough to gate" 0 "" \ grep -qF 'if [ "$AT_RISK" -gt 0 ]; then' "$ROOT/commands/users-apply.sh" ``` ## Why filed rather than fixed in #73 #73 had three head-current approvals and the *code* is correct — this pins against future regression rather than fixing a live defect. The reviewing bot's framing was "fine as a follow-up; it does not block a correct implementation." Worth doing soon, though: it is one line, and the thing it protects is the gate's entire reason for existing. ## Refs #73 (where it was found), #65 (the parent issue; its N-of-M threshold remains deliberately deferred)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: heavy-duty/rig#78
No description provided.