zerocoolailabs/zeroskills/test-terminator

Analyze the test suite and its coverage gaps for assumptions that fail in production.

Only report issues that can cause loss or theft of funds, locked assets, authorization bypass, broken accounting, denial of service, or another concrete security impact. Tests and missing coverage are clues, not proof. Confirm every finding in reachable production code.

Applicability gates

Proceed only when the repository contains unit tests, integration tests, or fuzz and invariant suites, and at least one of these signals is present:

• assertions, expected reverts, fixtures, mocks, or comments that encode intended behavior
• important public or external functions with no tests or only happy-path coverage
• security-relevant state transitions that the suite never completes
• filtered, skipped, commented, flaky, or deliberately avoided cases
• test names or comments that promise behavior the assertions do not establish

Otherwise do not force findings.

High-signal probes

1) Extract the invariants encoded by tests

Read assertions, expected reverts, invariant properties, and postcondition checks. Record what the tests claim about balances, supply, solvency, authorization, prices, state transitions, and withdrawal safety.

Trace each claim to the production functions and guards responsible for enforcing it.

Report when an attacker can reach a production path that violates the test-encoded invariant and causes concrete security impact.

2) Treat fixtures and mocks as assumptions

Identify setup that grants roles, seeds liquidity, preloads balances, fixes timestamps, configures trusted dependencies, or forces the protocol into a convenient starting state.

Review mocks and stubs for external behavior that production dependencies do not guarantee. Ask whether a user can reach the same production function without satisfying the fixture's preconditions.

Report when production relies on an assumption created only by the test setup and an attacker can violate it.

3) Investigate missing and one-sided coverage

Map important public and external functions to their tests. Prioritize functions with no coverage, value-bearing paths with only happy-path tests, and operation sequences that stop before their final state.

Look for one-sided transitions such as deposit without full withdrawal, queue without execution or cancellation, creation without closure, and loss handling without recovery.

Report when the uncovered production path contains a reachable vulnerability. Do not report missing tests by themselves.

4) Hunt filtered and deliberately avoided inputs

Inspect fuzz filters such as assume, bound, and custom guards. Review skipped tests, TODOs, commented assertions, known-flaky workarounds, seeded minimum balances, and thresholds chosen by fixtures.

For each excluded class, determine whether it is reachable in production and what happens when it reaches the real implementation.

Report when an excluded or avoided input reaches production and causes harmful behavior.

5) Compare what a test promises with what it proves

Compare test names and comments with the calls and assertions in the test body. Watch for tests named "full," "all," "final," "zero," "unauthorized," or "reverts" that stop short of the stated condition.

Treat a misleading or incomplete test as an investigation lead. Trace the promised behavior into production.

Report when production violates the promised behavior through a reachable path with concrete security impact. Do not report a bad test alone.

6) Cross-check assumptions across test suites and components

Compare unit, integration, invariant, and end-to-end suites that exercise the same state from different components. One suite may assert a transition that another component assumes cannot occur.

Trace conflicting assumptions across contracts, services, nodes, keepers, routers, and settlement code.

Report when the conflict can break a production flow, corrupt shared state, or make a required operation fail.