Cart Lab
A real cart in two representations. Write the state you expect, run a script, and see every step as before / operation / after with its execution trace — then find the bug in a variant that is the reference minus one line.
Predict before you run. If your prediction matches, you understand the operation; if it does not, the trace shows which branch executed and which assumption was wrong — which is the whole of debugging, on a cart small enough to see all of it.
The script
One operation per line: add <product> [qty], remove <product>, change <product> <qty>, clear.
Catalog: laptop (1000), mouse (20), keyboard (50), monitor (300) · 3 operations parsed
The V1 choice: items: CartItem[]. Finding an existing product is a scan, order is preserved for free, and "one entry per product" is a line of code, not a property of the structure.
Predict
Write the final state before you press Run. Then compare.
The flowchart
impl §62 — one operation as decisions and actions, before any code.
Draw it yourself first: which checks, in which order, and what happens on each no.
The engine is the exemplar's rules — catalog check, quantity > 0, one entry per product, change-to-0 is a removal, absent removal is a no-op — and not every possible cart. A cart that keeps quantity 0, errors on absent removal, or snapshots prices would be a different derivation with different traces. The buggy variants are the reference minus one line, so a script that never triggers that line runs cleanly on them; the bug is only visible on the example that discovered the rule.