Chain /explain into /fix into /tests instead of running any of them cold

Select the calculateDiscount function in lib/checkout/discount.ts in the editor, open the Copilot Chat panel, and run these
three slash commands in order, feeding each answer forward into the next rather than treating them
as three separate, unrelated questions against the same selection.

WHY THE SELECTION ITSELF MATTERS
Select only the calculateDiscount function in lib/checkout/discount.ts, not the whole file around it — a wider selection gives
all three commands more surface area to wander into, and /fix in particular is more likely to also
touch something adjacent and unrelated to whether expired discount codes are rejected correctly when the cart total changes after the code was applied the larger the selected block is.

STEP 1 — /explain
Ask: /explain what does this do, specifically with respect to whether expired discount codes are rejected correctly when the cart total changes after the code was applied, not a general summary
of the whole selection.

Before moving to step 2, read the answer and check one thing: does it actually address whether expired discount codes are rejected correctly when the cart total changes after the code was applied
by name, or did it summarize the selection in general terms without ever touching the specific
thing you are worried about? If it did not mention whether expired discount codes are rejected correctly when the cart total changes after the code was applied, ask a direct follow-up naming it
explicitly before proceeding — do not move to /fix on an explanation that never actually engaged
with the concern that brought you to this selection in the first place. Cross-check the answer
against calculateDiscount should re-validate against the cart total at checkout time, not the total from when the code was first applied. if you already have a hypothesis about what should happen.

STEP 2 — /fix
Ask: /fix address whether expired discount codes are rejected correctly when the cart total changes after the code was applied specifically, based on what step 1 just explained. Do not change
anything step 1 described as already working correctly.

Check the proposed diff against the step 1 explanation before accepting it: it should map directly
onto the concern step 1 confirmed exists, not an unrelated style change or a rewrite of a part step
1 said was fine. If the diff touches something step 1 explicitly called correct, reject it and ask
for a version scoped only to the confirmed concern.

STEP 3 — /tests
Ask: /tests using Vitest, matching the rest of lib/checkout/'s existing test files., add tests that would have caught whether expired discount codes are rejected correctly when the cart total changes after the code was applied before this fix
existed, in addition to the already-passing behavior step 1 confirmed.

Reject the /tests output if every generated test only re-covers the happy path that was already
working — that is testing what step 1 already confirmed was fine, not the actual regression risk
this whole session exists to close. If the case covering whether expired discount codes are rejected correctly when the cart total changes after the code was applied specifically is missing, ask
for it by name rather than accepting a suite that looks thorough but never actually exercises the
concern that started this.

IF ANY STEP'S ANSWER DOES NOT ACTUALLY BUILD ON THE PREVIOUS ONE
Stop and re-run that step with the previous answer explicitly pasted back in, rather than
continuing the chain on an answer that quietly dropped the thread — each slash command is
effectively a fresh, single-turn invocation, and nothing guarantees it fully carries forward the
nuance of an earlier turn's explanation just because the conversation looks continuous.