Sabotage
Sabotage finds the errors that needlessly stop a product and the silent fallbacks that make broken behavior look successful.
Fifty microseconds stopped playback
Sabotage began when Pixel Brite rejected a playable episode because an optional chapter endpoint extended 50 microseconds beyond the video. Ancillary data turned into an HTTP 500 and made playback unavailable. The incident exposed a broader problem: locally tidy error handling can defeat the product it is meant to protect.
Audit both failure directions
A failed chapter lookup should not stop playable video. At the other extreme, an HDR request that silently returns SDR can look successful to a test that only checks for decoded frames. One path blocks useful behavior; the other hides a change to what the user requested.
Sabotage follows a real user action through its dependencies and asks what each failure actually prevents. It identifies the responsible branch, the user-visible consequence, and the smallest correction at that boundary.
Keep the result and the diagnosis
Optional chapter damage can be recorded while video continues. A decoder failure still matters because there is no picture to play. The boundary follows the product’s job, rather than treating every exception as fatal or every fallback as success.
The agent then checks the normal and failed paths through the same runtime. A successful HDR test must inspect HDR output. A failed chapter lookup must leave playback working and expose the chapter error. The checks confirm both what the user received and what went wrong.