Prove You Understand It
Why this state? Why this data structure? What breaks if persistence disappears? Rebuild it from nothing; modify it under a new requirement; and the questions that catch code you pasted but cannot explain.
A cart that runs proves the code works. Whether you understood it is a different question, and the concept carries six that only understanding can answer: why this state, why this structure, what happens on a repeat add, what does it cost, what breaks without persistence, what changes under a new rule.
The only test of whether the cart was derived is to derive it again with nothing in front of you: meaning, state, operations, rules, examples, structure, one operation, its test. Not the same code — the same behaviour, reached by the same reasoning, and the places where you got stuck are the places you had not understood.
Five new requirements — a maximum of 5 per product, several carts per user, a cart that survives reload, an anonymous cart merged at login, inventory checked on add. Each breaks a named assumption and touches a named set of artefacts. If you can say which before touching the code, you understood the cart; if you can only find out by breaking it, you received it.
One sentence from the product owner and three assumptions the cart was built on stop being true: one device, one writer, the browser as the truth. Training for requirement change is learning to hear the sentence as a list of assumptions and to find, in the worksheet, every artefact that encoded them.
A learner pastes a cart that works and cannot say why it uses a Map, why the quantity changes on that line, or what the function returns and why. The guided flow is not a scolding: reasoning step, learner attempt, the smallest useful hint, another attempt, and the reference only when nothing else moved — and when the answer is a blank, a route back to the concept stage that owns it.