Gap
core/coder's sabotage-check block requires that a new assertion be shown able to fail, that the mutation be confirmed applied, and that a green sabotage be treated as a finding. It does not require the sabotage to be minimal, and it does not distinguish an assertion that observes the behaviour from one that can only reach a proxy for it.
Incident
An assertion pinned that a request-scoping value was computed. The sabotage deleted that computation and changed the request that consumed it, in a single edit. The suite went red, so the assertion was recorded as verified.
The red came entirely from the other half. Changing only the request, and keeping the computed value in place, left the assertion green while the request was sent to the wrong target — the exact corruption the assertion existed to prevent. A human reviewer found it by reasoning about what the assertion could observe, rather than about whether some sabotage had reddened.
Both halves generalize:
- A compound sabotage cannot attribute its red to the assertion under test. The assertion may still be vacuous behind a neighbour that happens to be covered.
- When an assertion can only reach a proxy for the behaviour — source text, a computed intermediate, a log line, a call count — the proxy's presence and the proxy's use are separate facts, and only the second is the behaviour.
Proposal
One sub-bullet under the existing sabotage-check block: break exactly what the assertion claims to pin, leave neighbours intact, and read which assertion failed rather than that something did. Where only a proxy is reachable, the sabotage that counts keeps the proxy and breaks the use; if no sabotage can separate them, the assertion is pinning the wrong thing and the harness limitation should be stated rather than banked as coverage.
🤖 Generated with Claude Code
📚 Learned by detritus — absorb https://github.com/idnerdidx/bulk/pull/1728
Gap
core/coder's sabotage-check block requires that a new assertion be shown able to fail, that the mutation be confirmed applied, and that a green sabotage be treated as a finding. It does not require the sabotage to be minimal, and it does not distinguish an assertion that observes the behaviour from one that can only reach a proxy for it.Incident
An assertion pinned that a request-scoping value was computed. The sabotage deleted that computation and changed the request that consumed it, in a single edit. The suite went red, so the assertion was recorded as verified.
The red came entirely from the other half. Changing only the request, and keeping the computed value in place, left the assertion green while the request was sent to the wrong target — the exact corruption the assertion existed to prevent. A human reviewer found it by reasoning about what the assertion could observe, rather than about whether some sabotage had reddened.
Both halves generalize:
Proposal
One sub-bullet under the existing sabotage-check block: break exactly what the assertion claims to pin, leave neighbours intact, and read which assertion failed rather than that something did. Where only a proxy is reachable, the sabotage that counts keeps the proxy and breaks the use; if no sabotage can separate them, the assertion is pinning the wrong thing and the harness limitation should be stated rather than banked as coverage.
🤖 Generated with Claude Code
📚 Learned by detritus — absorb
https://github.com/idnerdidx/bulk/pull/1728