Each site here is one where JaCoCo reported mi > 0 — a concrete instruction no test runs — rather than a partial branch on a compound condition. That filter is why the group is seven and not fifteen. Six are closed; one turns out not to be a gap.
Site
Outcome nothing produced
Mutation → red
AndroidDeviceCodecs:35
the UNPARSEABLE sentinel, refused where a merely unknown name is waved through
delete the early return
ContainerCapabilities:94
accepts(container, VideoCodec.NONE, mode)
NONE -> false
ContainerCapabilities:323
repairVideo's keep-the-requested-codec arm
fall through to the container's first encodable
ContainerCapabilities:348
firstContainerHolding's fallback container
drop the elvis
OutputPublisher:230
the resolver call that throws
?: false → ?: true
JobSnapshots:31
a job that recorded no output path at all
drop the ?.
Every one was mutated, confirmed red, and restored.
Two of these are worth reading about
The firstContainerHolding test was vacuous on its first draft. It asserted the refusal still offered something, and deleting the fallback left it green — the source container is a candidate in its own right, so the list stays non-empty and only its contents change. Rewritten around AVI, which has no mapping for H.265: without the fallback the app quietly offers H.264 instead, which is the actual loss. The test now asserts the codec survives. This is the failure mode CLAUDE.md records from the mutation review, met head-on rather than in the abstract — and the reason the "revert the line, watch it go red" step is not ceremony.
OutputPublisher:230 needed one line, not a test.a destination whose size cannot be determined is never deleted already walked three RowShapes. QUERY_THROWS is the fourth case that method's own KDoc names — "a resolver call that throws" — and the only one reaching ?: false through runCatching rather than through a cursor answer. Getting it wrong deletes a file the user already had, on a save that failed.
One that is not a gap
ContainerCapabilities:282's .filter { it != exclude } is not closed here, because nothing can make it drop anything:
on the shared container repair always changes at least one codec — a codec it left alone is one validate would not have refused;
every other candidate differs by container;
the single call site passing a non-default exclude (validateVideo:186) excludes a spec carrying VideoCodec.COPY, while every repaired candidate carries NONE.
F4-shaped: recorded rather than covered. 555 tests agree with the reading.
Gate
Full gate green. 550 → 555 JVM tests, 0 failures. Five new tests rather than six — OutputPublisher:230 is one line inside an existing test. No production code changed. Line 2087/2348 → 2090/2348, branch 1011/1340 → 1022/1340.
Closes #172. Stacked on #179.
Each site here is one where JaCoCo reported `mi > 0` — a concrete instruction no test runs — rather than a partial branch on a compound condition. That filter is why the group is seven and not fifteen. Six are closed; one turns out not to be a gap.
| Site | Outcome nothing produced | Mutation → red |
|---|---|---|
| `AndroidDeviceCodecs:35` | the `UNPARSEABLE` sentinel, refused where a merely unknown name is waved through | delete the early return |
| `ContainerCapabilities:94` | `accepts(container, VideoCodec.NONE, mode)` | `NONE -> false` |
| `ContainerCapabilities:323` | `repairVideo`'s keep-the-requested-codec arm | fall through to the container's first encodable |
| `ContainerCapabilities:348` | `firstContainerHolding`'s fallback container | drop the elvis |
| `OutputPublisher:230` | the resolver call that throws | `?: false` → `?: true` |
| `JobSnapshots:31` | a job that recorded no output path at all | drop the `?.` |
Every one was mutated, confirmed red, and restored.
### Two of these are worth reading about
**The `firstContainerHolding` test was vacuous on its first draft.** It asserted the refusal still offered *something*, and deleting the fallback left it **green** — the source container is a candidate in its own right, so the list stays non-empty and only its contents change. Rewritten around AVI, which has no mapping for H.265: without the fallback the app quietly offers H.264 instead, which is the actual loss. The test now asserts the codec survives. This is the failure mode `CLAUDE.md` records from the mutation review, met head-on rather than in the abstract — and the reason the "revert the line, watch it go red" step is not ceremony.
**`OutputPublisher:230` needed one line, not a test.** `a destination whose size cannot be determined is never deleted` already walked three `RowShape`s. `QUERY_THROWS` is the fourth case that method's own KDoc names — *"a resolver call that throws"* — and the only one reaching `?: false` through `runCatching` rather than through a cursor answer. Getting it wrong deletes a file the user already had, on a save that failed.
### One that is not a gap
`ContainerCapabilities:282`'s `.filter { it != exclude }` is **not** closed here, because nothing can make it drop anything:
- on the shared container `repair` always changes at least one codec — a codec it left alone is one `validate` would not have refused;
- every other candidate differs by container;
- the single call site passing a non-default `exclude` (`validateVideo:186`) excludes a spec carrying `VideoCodec.COPY`, while every repaired candidate carries `NONE`.
F4-shaped: recorded rather than covered. 555 tests agree with the reading.
### Gate
Full gate green. 550 → 555 JVM tests, 0 failures. Five new tests rather than six — `OutputPublisher:230` is one line inside an existing test. **No production code changed.** Line 2087/2348 → 2090/2348, branch 1011/1340 → 1022/1340.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #172. Stacked on #179.
Each site here is one where JaCoCo reported
mi > 0— a concrete instruction no test runs — rather than a partial branch on a compound condition. That filter is why the group is seven and not fifteen. Six are closed; one turns out not to be a gap.AndroidDeviceCodecs:35UNPARSEABLEsentinel, refused where a merely unknown name is waved throughContainerCapabilities:94accepts(container, VideoCodec.NONE, mode)NONE -> falseContainerCapabilities:323repairVideo's keep-the-requested-codec armContainerCapabilities:348firstContainerHolding's fallback containerOutputPublisher:230?: false→?: trueJobSnapshots:31?.Every one was mutated, confirmed red, and restored.
Two of these are worth reading about
The
firstContainerHoldingtest was vacuous on its first draft. It asserted the refusal still offered something, and deleting the fallback left it green — the source container is a candidate in its own right, so the list stays non-empty and only its contents change. Rewritten around AVI, which has no mapping for H.265: without the fallback the app quietly offers H.264 instead, which is the actual loss. The test now asserts the codec survives. This is the failure modeCLAUDE.mdrecords from the mutation review, met head-on rather than in the abstract — and the reason the "revert the line, watch it go red" step is not ceremony.OutputPublisher:230needed one line, not a test.a destination whose size cannot be determined is never deletedalready walked threeRowShapes.QUERY_THROWSis the fourth case that method's own KDoc names — "a resolver call that throws" — and the only one reaching?: falsethroughrunCatchingrather than through a cursor answer. Getting it wrong deletes a file the user already had, on a save that failed.One that is not a gap
ContainerCapabilities:282's.filter { it != exclude }is not closed here, because nothing can make it drop anything:repairalways changes at least one codec — a codec it left alone is onevalidatewould not have refused;exclude(validateVideo:186) excludes a spec carryingVideoCodec.COPY, while every repaired candidate carriesNONE.F4-shaped: recorded rather than covered. 555 tests agree with the reading.
Gate
Full gate green. 550 → 555 JVM tests, 0 failures. Five new tests rather than six —
OutputPublisher:230is one line inside an existing test. No production code changed. Line 2087/2348 → 2090/2348, branch 1011/1340 → 1022/1340.🤖 Generated with Claude Code