Write acceptance criteria that cover the edge cases a developer will otherwise guess at

Write acceptance criteria in Given/When/Then format for the story below. Most acceptance criteria stop at the one happy-path scenario and leave every boundary and error condition for the developer to guess at during implementation — I want those made explicit up front instead.

USER STORY
As a customer, I want to apply a discount code at checkout so I can get the promotional price before paying.

INPUT FIELDS OR USER ACTIONS INVOLVED
Discount code text field, max 20 characters, applied via an 'Apply' button.

SYSTEM STATE THAT COULD VARY
Code could be expired, already used by this account, valid but for a different product category, or valid and applicable.

First write the single happy-path scenario. Then, for every input field or user action listed, generate the boundary and error scenarios a developer would otherwise have to guess: an empty or missing value, a value at the edge of an allowed range, a value just past that edge, and a malformed or unexpected value if the field type allows one. For every item listed under system state that could vary, write a scenario for each meaningfully different state (e.g., if the feature depends on account status, write a scenario for each status that would produce different behavior, not just the default one). Do not invent scenarios for conditions that couldn't actually occur given the inputs described — a text field with a hard 50-character limit enforced by the input itself doesn't need a "value has one million characters" scenario if that's physically impossible to enter. For any edge case where the correct behavior genuinely isn't decided yet by the story as written, write the scenario with the Then clause marked "TBD — needs a decision" rather than inventing a plausible-sounding behavior that hasn't actually been agreed to, since a fabricated Then clause here would ship as an assumed requirement no one actually approved.

WHAT NOT TO DO
Do not write vague Then clauses like "the system handles it appropriately" — every Then must state the specific observable outcome. Do not pad the list with scenarios that are trivial restatements of each other differing only in cosmetic wording.

OUTPUT FORMAT
A numbered list of Given/When/Then scenarios, happy path first, then boundary/error scenarios grouped by which input or state condition they test. Mark any TBD scenarios clearly at the end in their own short list so they're easy to route back to whoever owns the decision.