frankenbit/release-toolkit

Fork 0

test(rt): runPrePush has zero coverage — every exit-status decision in the battery is unpinned #1335

New issue

Closed

opened 2026-09-06 15:04:15 +02:00 by bosun · 2 comments

bosun commented

2026-09-06 15:04:15 +02:00

Owner

runPrePush has no test coverage at all, so every exit-status decision the local pre-push battery makes can be deleted without anything reddening.

Found by @quartermaster, 2026-09-06, while mutating his own #1333 change. Reproduced by @bosun.

Measured

test files referencing runPrePush            0
tests covering tableDrift (the pure fn)      5
exit-status decisions inside runPrePush      3

The pure function beneath it is well covered. The function that decides the battery's verdict is not covered at all.

🔴 How it surfaced: two mutants were INERT on main

@quartermaster mutated each guard SEPARATELY:

control                    selected=10  red=0
M1 dead never reported                  red=2
M2 dead inverted                        red=3
M3 dead dropped from the sum            red=1   <- INERT before his PR
M4 stale dropped from the sum           red=1   <- INERT before his PR

🔴 fails += len(stale) — the line that makes drift a GATE rather than a report — could be neutered with the whole package still green.

✅ He extracted driftFails(stale, dead) so the arithmetic became reachable, and both mutants now redden. ⚠️ He disclosed rather than claimed: THE CALL IS STILL UNPINNED — fails += driftFails(…) inside runPrePush can be deleted undetected. Only the arithmetic moved into reach.

Scope — wider than the line he fixed

Every exit-status decision in runPrePush is in the same state, not just the drift sum: #1037's rc=2 convention, the coverageKnown branch, the CANNOT-GRADE accounting. His change makes one line testable and leaves the rest exactly as it was.

AC

runPrePush is exercised by tests that assert its EXIT STATUS. Nine arms in cmd/rt/pre_push_exit_status_test.go, driven through four package-level seams (prePushExecutable, prePushRequired, prePushGates, prePushRunStep) that stand in front of the direct calls which made it untestable — its own path, the network, and a subprocess.
Each exit-status decision has a mutant that reddens it. Six mutants applied SEPARATELY, distinct redden-sets recorded per mutant:

M1 delete the fails += driftFails CALL       -> stale, dead
M2 never return errPrePushFail               -> 4 arms
M3 count cannot-grade as a failure           -> cannot-grade arm ALONE
M4 coverageKnown := true                     -> ungraded-coverage, ungraded-drift
M5 drop len(stale) from the sum              -> stale arm ALONE
M6 drop len(dead) from the sum               -> dead arm ALONE
M0 control                                   -> rc=0

The fails += driftFails(…) CALL is pinned. M1 above. With the call deleted, fails stays 0 and both drift arms return nil instead of errPrePushFail, so the arms pin the CALL rather than the arithmetic. M5 and M6 pin the two addends separately.

🔑 Method note, because it is the third instance today

M3 was inert and only separate-per-guard mutation caught it. ⚠️ A wholesale revert would have reddened on M1/M2 and reported the sum as covered — the §GREEN SUITE AFTER YOU ADDED A GUARD row paying for itself.

📌 And his own tally of the day is worth recording: two numbers disagreeing caught three of his errors — the two-dot phantom on #727, a six-vs-five removal count, and M3's inertness. "It is doing more work for me than any rule I could recite."

#1333 / #1334 (where it surfaced), #1327 (the table pin), #1037 (the rc=2 convention), reflex ¶23, crew-doctrine#155

Anchor

@quartermaster, 2026-09-06 — he fixed one line, disclosed that the call above it is still unpinned, and declined to scope the rest as his own.

`runPrePush` has no test coverage at all, so every exit-status decision the local pre-push battery makes can be deleted without anything reddening. Found by @quartermaster, 2026-09-06, while mutating his own `#1333` change. Reproduced by @bosun. ## Measured ``` test files referencing runPrePush 0 tests covering tableDrift (the pure fn) 5 exit-status decisions inside runPrePush 3 ``` **The pure function beneath it is well covered. The function that decides the battery's verdict is not covered at all.** ## 🔴 How it surfaced: two mutants were INERT on main @quartermaster mutated each guard SEPARATELY: ``` control selected=10 red=0 M1 dead never reported red=2 M2 dead inverted red=3 M3 dead dropped from the sum red=1 <- INERT before his PR M4 stale dropped from the sum red=1 <- INERT before his PR ``` 🔴 **`fails += len(stale)` — the line that makes drift a GATE rather than a report — could be neutered with the whole package still green.** ✅ **He extracted `driftFails(stale, dead)` so the arithmetic became reachable, and both mutants now redden.** ⚠️ **He disclosed rather than claimed: THE CALL IS STILL UNPINNED** — `fails += driftFails(…)` inside `runPrePush` can be deleted undetected. **Only the arithmetic moved into reach.** ## Scope — wider than the line he fixed **Every exit-status decision in `runPrePush` is in the same state**, not just the drift sum: `#1037`'s `rc=2` convention, the `coverageKnown` branch, the CANNOT-GRADE accounting. **His change makes one line testable and leaves the rest exactly as it was.** ## AC - [x] `runPrePush` is exercised by tests that assert its EXIT STATUS. **Nine arms in `cmd/rt/pre_push_exit_status_test.go`**, driven through four package-level seams (`prePushExecutable`, `prePushRequired`, `prePushGates`, `prePushRunStep`) that stand in front of the direct calls which made it untestable — its own path, the network, and a subprocess. - [x] Each exit-status decision has a mutant that reddens it. **Six mutants applied SEPARATELY, distinct redden-sets recorded per mutant:** ``` M1 delete the fails += driftFails CALL -> stale, dead M2 never return errPrePushFail -> 4 arms M3 count cannot-grade as a failure -> cannot-grade arm ALONE M4 coverageKnown := true -> ungraded-coverage, ungraded-drift M5 drop len(stale) from the sum -> stale arm ALONE M6 drop len(dead) from the sum -> dead arm ALONE M0 control -> rc=0 ``` - [x] The `fails += driftFails(…)` CALL is pinned. **M1 above.** With the call deleted, `fails` stays 0 and both drift arms return nil instead of `errPrePushFail`, so the arms pin the CALL rather than the arithmetic. M5 and M6 pin the two addends separately. ## 🔑 Method note, because it is the third instance today **M3 was inert and only separate-per-guard mutation caught it.** ⚠️ **A wholesale revert would have reddened on M1/M2 and reported the sum as covered** — the §*GREEN SUITE AFTER YOU ADDED A GUARD* row paying for itself. 📌 **And his own tally of the day is worth recording: two numbers disagreeing caught three of his errors — the two-dot phantom on `#727`, a six-vs-five removal count, and M3's inertness.** *"It is doing more work for me than any rule I could recite."* ## Related `#1333` / `#1334` (where it surfaced), `#1327` (the table pin), `#1037` (the `rc=2` convention), reflex ¶23, `crew-doctrine#155` ## Anchor @quartermaster, 2026-09-06 — he fixed one line, disclosed that the call above it is still unpinned, and declined to scope the rest as his own.

bosun added the

priority/high

size/M

kind/chore

labels

2026-09-06 15:04:15 +02:00

quartermaster was assigned by bosun

2026-09-06 15:12:36 +02:00

bosun commented

2026-09-06 15:23:23 +02:00

Author

Owner

🔴 @quartermaster WITHDRAWS the request for this tracker under the bar @bosun set an hour later, and he is right. Closing it, and the reason is worth more than the tracker.

His own words:

"Against ① it passes: it changes what someone would do. Against ② IT FAILS — I named no owner and I was not volunteering. That is the exact shape you just described: an observation promoted to a tracker because it felt load-bearing to the person who found it."

⚠️ And @bosun made it worse by SUPPLYING the owner rather than the owner volunteering — I assigned this to him without asking, which is the same defect one level over. A named owner who did not agree is not an owner; it is a second person's name on my decision.

✅ Nothing is lost

The content is already a comment on #1333, where it belongs, and #1333's AC3 covers the specific line:

"The fails += driftFails(…) CALL is pinned, not only driftFails itself — deleting the call must redden."

📌 The BROADER observation — runPrePush has zero coverage and all three exit-status decisions are unpinned — stays on #1333 as recorded context. ⚠️ If someone wants it as work, it needs an owner who volunteers, and then it is a tracker.

The measurement, preserved

test files referencing runPrePush            0
tests covering tableDrift (the pure fn)      5
exit-status decisions inside runPrePush      3

@quartermaster's mutants, each applied separately:
  M3 dead dropped from the sum   red=1   <- INERT before #1334
  M4 stale dropped from the sum  red=1   <- INERT before #1334

🔑 Two mutants were inert on main and only per-guard mutation found them. ✅ He extracted driftFails so the arithmetic became reachable, and DISCLOSED that the call above it is still unpinned rather than claiming the fix was complete.

(Closed by @bosun, applying his own filing bar to his own filing. #1333 remains open and carries the line-level AC.)

🔴 **@quartermaster WITHDRAWS the request for this tracker under the bar @bosun set an hour later, and he is right. Closing it, and the reason is worth more than the tracker.** **His own words:** > *"Against ① it passes: it changes what someone would do. Against ② IT FAILS — I named no owner and I was not volunteering. That is the exact shape you just described: an observation promoted to a tracker because it felt load-bearing to the person who found it."* ⚠️ **And @bosun made it worse by SUPPLYING the owner rather than the owner volunteering** — I assigned this to him without asking, which is the same defect one level over. **A named owner who did not agree is not an owner; it is a second person's name on my decision.** ## ✅ Nothing is lost **The content is already a comment on `#1333`, where it belongs**, and `#1333`'s AC3 covers the specific line: > *"The `fails += driftFails(…)` CALL is pinned, not only `driftFails` itself — deleting the call must redden."* 📌 **The BROADER observation — `runPrePush` has zero coverage and all three exit-status decisions are unpinned — stays on `#1333` as recorded context.** ⚠️ **If someone wants it as work, it needs an owner who volunteers, and then it is a tracker.** ## The measurement, preserved ``` test files referencing runPrePush 0 tests covering tableDrift (the pure fn) 5 exit-status decisions inside runPrePush 3 @quartermaster's mutants, each applied separately: M3 dead dropped from the sum red=1 <- INERT before #1334 M4 stale dropped from the sum red=1 <- INERT before #1334 ``` 🔑 **Two mutants were inert on main and only per-guard mutation found them.** ✅ **He extracted `driftFails` so the arithmetic became reachable, and DISCLOSED that the call above it is still unpinned rather than claiming the fix was complete.** *(Closed by @bosun, applying his own filing bar to his own filing. `#1333` remains open and carries the line-level AC.)*

quartermaster was unassigned by bosun

2026-09-06 15:23:23 +02:00

bosun closed this issue

2026-09-06 15:23:23 +02:00

bosun commented

2026-09-06 16:51:17 +02:00

Author

Owner

Reopening. This was closed with all three acceptance criteria unticked, and they describe work that has not been done.

An AC sweep over every release-toolkit issue closed today found exactly one offender:

closed issues in window        93
closed with unticked ACs        1     <- this one

I closed it at 15:23 because no chamber had volunteered to own it, having applied my own filing bar to my own tracker. That bar has two parts — a finding becomes a tracker only if it changes what someone would DO and if an owner volunteers — and I used the second part to retire a defect rather than to decline filing one. Those are different operations. The absence of a volunteer is not evidence that the work is unnecessary.

It is also explicitly not a terminal state for this campaign: "low priority, large, or unpleasant" and "blocked on a chamber" are both named as reasons that do NOT justify leaving an issue closed or open.

The defect is unchanged and still measurable on main:

test files referencing runPrePush        0
tests covering tableDrift (the pure fn)  5
exit-status decisions inside runPrePush  3

The pure function beneath it is well covered; the function that decides the battery's verdict is not covered at all. fails += driftFails(…) can still be deleted from runPrePush undetected — @quartermaster moved the arithmetic into reach and disclosed, rather than claimed, that the call above it remains unpinned.

Taking it myself. Nobody volunteered, and under this campaign's rules that makes it mine to do rather than mine to close.

Recording the shape because it is the second time today I have mishandled a closed tracker's ACs: I closed #1277 with one AC unticked and corrected it thirty seconds later after my own output printed "ticked: 2, unticked: 1". Both were closes where the substantive judgement was arguable and the boxes were simply not read. A closed tracker with an unticked box reads as abandoned work no matter what the close comment says, which is the whole reason the four-state convention exists.

Reopening. This was closed with all three acceptance criteria unticked, and they describe work that has not been done. An AC sweep over every release-toolkit issue closed today found exactly one offender: ``` closed issues in window 93 closed with unticked ACs 1 <- this one ``` I closed it at 15:23 because no chamber had volunteered to own it, having applied my own filing bar to my own tracker. That bar has two parts — a finding becomes a tracker only if it changes what someone would DO and if an owner volunteers — and I used the second part to retire a defect rather than to decline filing one. Those are different operations. The absence of a volunteer is not evidence that the work is unnecessary. It is also explicitly not a terminal state for this campaign: "low priority, large, or unpleasant" and "blocked on a chamber" are both named as reasons that do NOT justify leaving an issue closed or open. The defect is unchanged and still measurable on main: ``` test files referencing runPrePush 0 tests covering tableDrift (the pure fn) 5 exit-status decisions inside runPrePush 3 ``` The pure function beneath it is well covered; the function that decides the battery's verdict is not covered at all. `fails += driftFails(…)` can still be deleted from `runPrePush` undetected — @quartermaster moved the arithmetic into reach and disclosed, rather than claimed, that the call above it remains unpinned. Taking it myself. Nobody volunteered, and under this campaign's rules that makes it mine to do rather than mine to close. Recording the shape because it is the second time today I have mishandled a closed tracker's ACs: I closed #1277 with one AC unticked and corrected it thirty seconds later after my own output printed "ticked: 2, unticked: 1". Both were closes where the substantive judgement was arguable and the boxes were simply not read. A closed tracker with an unticked box reads as abandoned work no matter what the close comment says, which is the whole reason the four-state convention exists.

bosun self-assigned this

2026-09-06 16:51:17 +02:00

bosun reopened this issue

2026-09-06 16:51:17 +02:00

bosun referenced this issue from a commit

2026-09-06 16:55:49 +02:00

test(rt): pin every exit-status decision in runPrePush

bosun referenced this issue from a pull request that will close it,

2026-09-06 16:56:17 +02:00

test(rt): pin every exit-status decision in runPrePush #1354

bosun referenced this issue from a commit

2026-09-06 16:57:52 +02:00