Make Claude Code write tests that hunt for breakage, not confirm the happy path

You are writing tests whose job is to find where the code below breaks, not to confirm that it works. A suite that only exercises the happy path has failed this task even if every test in it passes.

TARGET
parseDiscountCode(code, cart) in lib/checkout/discount.ts, returns a DiscountResult

TEST FRAMEWORK AND CONVENTIONS
Vitest, using describe/it blocks and the existing test/factories/cart.ts builder for fixture data.

KNOWN EDGE CASES ALREADY IN THIS CODEBASE'S HISTORY
expired codes, codes with leading or trailing whitespace, valid codes where the cart total is below the minimum spend

REQUIRED COVERAGE — CONSIDER EVERY CATEGORY, EVEN IF THE ANSWER IS 'DOES NOT APPLY, BECAUSE...'
- Boundary values: empty, zero, negative, maximum length, exactly one element versus many.
- Null, undefined, or partially malformed input, including an object missing a field the type signature promises will be present.
- Type edge cases the type system does not actually prevent at runtime, such as JSON parsed from an external API or a form field that arrives as a string when a number was expected.
- Error and exception paths — does the function fail loudly and specifically, or silently produce a wrong-but-plausible result?
- Concurrency or repeat-call cases, if the function touches any shared, cached, or module-level state.
- Adversarial input if this function ever receives anything from outside a fully trusted boundary, such as a string long enough to test a length limit, or a value shaped like an injection attempt even if the function is not directly a security surface — a test suite that never tries an unexpected shape cannot tell you whether the function degrades safely or not.
- Every item listed under known edge cases above, even one that seems unlikely to matter today.

FORMAT
- Table-driven or parametrized tests, one assertion pattern reused across many named cases, not a wall of near-identical copy-pasted test functions where a missing row is invisible.
- Name each case after the behavior it verifies, not test1, test2, or a description of the input alone with no stated expectation.
- Do not write a snapshot test unless explicitly asked for one.
- Follow the existing conventions in Vitest, using describe/it blocks and the existing test/factories/cart.ts builder for fixture data. for fixtures and setup rather than inventing a parallel pattern this codebase does not already use elsewhere.

AFTER THE TESTS
List any coverage gap that could not be closed in this pass and exactly why — it needs a live network call, a fixture that does not exist yet, or a dependency this environment cannot exercise — rather than silently shipping a suite that looks complete but is not.

If 85% line coverage on lib/checkout/, enforced in CI states a required coverage threshold and this suite would not meet it, say so explicitly rather than presenting the suite as sufficient by omission, and name specifically which untested branch would need a case added to close the gap.