---
name: sabotage
description: Audit a product workflow for self-inflicted failure gates and silent fallbacks that block the primary user outcome for ancillary reasons or conceal that the intended behavior failed. Use when explicitly asked to find systemic fragility, resilience failures, fallback masking, or product self-sabotage. Do not use for security sabotage, ordinary bug fixes, or generic code review.
metadata:
  short-description: Find self-inflicted product failure paths
---

# Sabotage

Find where a product defeats its own user outcome.

Audit from the outcome inward, not from an error site outward. Look for both symmetric failure classes:

- **Hard sabotage:** something that is not necessary for the primary outcome prevents it anyway.
- **Soft sabotage:** a fallback keeps the surface alive while concealing that the requested or intended behavior failed.

Do not assume that every error should be ignored. Authorization, safety, integrity, and truly required inputs may need to fail closed. Rank each dependency by its effect on the product outcome instead of applying one error-handling rule everywhere.

## Establish the audit boundary

Read the repository instructions and canonical product contracts first. Identify:

- the concrete user entry point;
- the primary outcome the user expects;
- safety, authorization, integrity, and durability requirements that are part of that outcome;
- the terminal states that count as success, degraded success, cancellation, or failure.

For a repository-wide request, partition the product into named user workflows and audit them one at a time. State which entry points and terminal states were covered. Never call a pass exhaustive merely because keyword searches are clean.

The audit is read-only unless the user also asks for implementation.

## Trace every outcome-changing branch

Follow the real call path from entry point to terminal outcome. Inventory every fallible transition that can:

- prevent or terminate the primary outcome;
- replace the requested result with another result;
- destroy a working result before its replacement is accepted;
- turn an error into pending, retrying, success, or silence;
- widen one local failure across unrelated variants, resources, or users;
- report success after the intended behavior failed.

Include validators, parsing, numeric comparisons, timers, cancellation, retries, caches, persistence, enrichment, discovery, cleanup, telemetry, rollback, asynchronous callbacks, and cross-process or cross-device coordination. Searches help locate candidates; call-path evidence determines whether they are findings.

## Classify dependencies by product consequence

Classification is contextual. A database write is ancillary to watching a video but outcome-critical to saving a document.

- **Admission-critical:** required to begin safely and legitimately. Failure blocks admission.
- **Outcome-critical:** required to produce or deliver the primary result. Failure blocks only when no acceptable existing result can continue.
- **Variant-local:** required for one candidate, rendition, provider, track, or route. Failure should normally remove that candidate, not every alternative.
- **Ancillary:** enrichment or convenience such as optional metadata, chapters, artwork, telemetry, discovery, or analysis. Failure should normally preserve the primary result and record degradation.
- **Durability:** caches, preferences, history, resume state, or other persistence. Decide whether durability is the requested outcome or a side effect before allowing it to veto success.
- **Replacement or recovery:** a transition from an acceptable current result to a proposed new one. Preserve the current result until the replacement is accepted.
- **Cleanup or finalization:** work after the primary result. Do not retroactively erase success unless cleanup is explicitly part of the product contract.
- **Proof or diagnostics:** evidence about exact behavior. It may reject a proof claim; it must not become an accidental runtime admission gate.

## Look for recurring inversions

Treat these as audit prompts, not automatic findings:

- **Authority inversion:** optional or derived data outranks a usable primary artifact.
- **Precision inversion:** representation noise is judged more strictly than the domain's meaningful precision.
- **Lifetime inversion:** an arbitrary timeout kills work that is progressing normally or already has an owning cancellation boundary.
- **Replacement inversion:** working state is torn down before its replacement proves usable.
- **Blast-radius inversion:** one malformed item, variant, or endpoint disables unrelated valid ones.
- **Side-effect veto:** cache writes, preferences, history, telemetry, logging, or cleanup can cancel core success.
- **Error laundering:** distinct failures are flattened into pending, retry, success, or an empty result.
- **Fallback camouflage:** a fallback is treated as proof that the intended path worked.
- **Proof contamination:** deep validation or exactness checks run in the ordinary serving path.
- **Partial-operation amnesia:** a multi-resource operation loses or hides its resumable partial state when rollback also fails.
- **Async ownership loss:** a late callback, retry, or cancellation from an older attempt corrupts the current attempt.
- **Duplicate authority:** independent validators or readiness checks disagree about the same artifact.

For every candidate, ask two questions: “Could the user still receive a safe, honest primary outcome?” and “Would we know that the intended path did not happen?” A yes followed by a no is soft sabotage even when availability is preserved.

## Keep runtime and proof honest

Do not solve the testing problem with a strict test mode that changes production behavior. Use the same runtime contract in both contexts:

- Runtime preserves the primary outcome when doing so is safe and records every unexpected degradation or fallback in a bounded, structured form.
- Exact-success proof asserts the intended output, route, variant, or protocol and requires no unexpected degradation.
- Failure-injection proof asserts both continuity of the primary outcome and the expected degradation record.
- Admission-critical failure proof asserts that the product fails at the correct boundary.

A degradation record should identify a stable code, phase, cause, and chosen alternative without leaking sensitive data. Logging alone is insufficient when automated proof must distinguish correct behavior from fallback behavior.

If exact inspection requires expensive or destructive validation, expose it through a read-only diagnostic surface or proof tool that observes the result without controlling ordinary serving.

## Report evidence, not taste

For each confirmed finding, report:

- the entry point and exact code path;
- the triggering condition;
- the primary user outcome affected;
- the dependency classification;
- whether behavior is blocked, corrupted, replaced, or silently masked;
- the product contract that establishes the expected behavior;
- the smallest correction;
- the runtime diagnostic and proof assertion needed to keep the correction honest.

Separate confirmed findings from unresolved candidates. Rank severity by user consequence: unavailable or destructive outcomes first, incorrect results second, hidden degradation third, and maintainability concerns only when they create a concrete failure path.

Do not propose broad exception swallowing, universal fail-open behavior, speculative compatibility layers, or unrelated hardening. When implementation is requested, make the smallest changes that restore the product outcome and its observability.

## Stop condition

Finish when every fallible transition on the stated in-scope paths has been classified, every terminal outcome has been accounted for, every fallback is observable or reported as a finding, and every untraceable dynamic or external boundary is listed as an uncertainty. Report that bounded coverage; do not imply that uninspected workflows are clean.