Hide the Reference and Build the Cart Again
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.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
If the reference, the tutorial and the chat history were gone, could you produce a cart with the same behaviour — and which step would you stall on, and what does that stall name?
You built the cart with the concept builder open beside you, checking every step against the reference. It passed. Asked to write addItem on a whiteboard the next day, you write the signature and stop, and you cannot tell whether you have forgotten syntax or never knew the algorithm.
Re-read the reference to refresh, then try. It is only checking your work against the answer key; you did the work yesterday, and reading it once more before attempting cannot hurt.
Reading it first means the attempt tests short-term memory of the text. It comes out nearly verbatim, including the parts you never derived, and the stall you were looking for is papered over by recall.
- Reading it first means the attempt tests short-term memory of the text. It comes out nearly verbatim, including the parts you never derived, and the stall you were looking for is papered over by recall.
- The stall was the information. Whether you stop at "what is the state?" or at "how do I find the existing entry?" says which stage was received; re-reading erases the signal before it is read.
- A rebuild from a fresh reading is the same cart with the same holes. Nothing was learned about where understanding ended, so the next concept starts with the same reflex.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Close everything. Start from the sentence the concept starts from: "a temporary collection of products the user intends to purchase, held between browsing and checkout." From it, derive the state — items with a product id and a quantity, and the verdicts on what not to store. Then the operations, then the rules, then the examples, then the structure, then one operation in pseudocode, then in code, then its test from an example. The order is the loop; the rebuild is the loop run without the answer key (The Implementation Loop).
- Aim for the behaviour, not the text. A rebuilt addItem that uses a loop where the reference used find is the same operation; a rebuilt cart that stores the product name is a different state and the stall is at the state stage, even though the code runs. Compare against the examples, then against the reasoning, and only last against the reference's lines.
- Record every stall as a stage name. "Stopped at: which fields" is a state gap; "stopped at: what happens on a repeat add" is a rules gap; "stopped at: how to find the entry" is a primitives gap, and each has a lesson to return to (Go One Primitive Lower). The list of stalls is the output of the exercise; the cart is the by-product.
- This is the discovery stage's build-from-memory applied to an implementation. That lesson rebuilds a design and compares architectures; this one rebuilds one concept and compares behaviour, and the unit of comparison is an example — before, operation, after — rather than a diagram (Build From Memory).
The rebuild, level by level
The ladder is the loop as it is run with nothing open. Every level says why it comes before the next — which is the argument against starting at the signature. The bottom rung is where most rebuilds stall, and the reason is written there.
- MeaningOne sentence: a temporary collection of products the user intends to purchase, held between browsing and checkout. — Everything below is derived from it; a rebuild that skips it has nothing to derive the state from and falls back on recall.
- Stateitems, each with productId and quantity. Not name, not price, not total — and a verdict for each of those. — The verdicts are where received carts differ from derived ones: a stored total appears by habit and is caught only by asking what it protects.
- Operations and rulesadd, remove, change, view, total; quantity > 0; one entry per product; unknown product rejected. — The rules are discovered by writing the examples — add-again is where one-entry-per-product comes from — so this level and the next are done together.
- ExamplesThe six before / operation / after pairs, including the invalid one. — They are the comparison for the whole exercise: a rebuild passes when the examples pass, whatever the lines look like.
- StructureAn array of entries, with the O(n) find named and the reason it is fine. — Choosing it again, with the reason, is the representation stage derived; choosing it because the reference did is the stage recalled.
- One operation and its testaddItem in pseudocode, then in code — loop or find — then the add-again test. — The stall, if there is one, appears here and has a name from the levels above; the other four operations would repeat it.
The rebuilt addItem, and the reference, on one example
The rebuild used a loop; the reference used find. The trace of the same call through both is identical at every stop, which is the definition of "same behaviour" this lesson uses. A diff would flag six lines; the trace flags nothing.
- inputcart.items = [ { productId: "laptop", quantity: 1 } ]; productId = "laptop"; quantity = 1.
- lookupquantity > 0 → true (the rebuild checked quantity first; the reference checks the catalog first — a decision, not a behaviour, for valid input). The loop visits the single entry; "laptop" == "laptop" → the entry, returned early.
- branchexisting is present → increase. The append path does not run — identical to the reference's branch line.
- mutationitems[0].quantity: 1 → 2; items.length unchanged.
- outputthe cart, [ Laptop × 2 ]. Same five stops as the reference; different lines; the rebuild passes.
What the stall is called
The decision maps each kind of stall to the stage it names and the lesson to return to. The exercise is only useful if the stall is classified; "I got stuck" is the vague form and "I stalled at what identifies an entry — a rules gap" is the specific one.
Which stage does this stall name, and where do you go?
when The state came out with fields the concept dropped, and you could not say why they were wrong until an operation exposed them.
cost State: the challenge for each field, with the failure it prevents. Short, and it stops the same fields returning in the next concept.
when The examples were written and the rule did not appear from them, or the find compared the wrong thing.
cost Rules and examples: normal / edge / invalid for one operation, and rule → validation → code for the one that stalled.
when The pseudocode was right and the code would not come.
cost Primitives: go one rung lower, write the loop, climb back. The shortest stall to fix and the one most often mistaken for a bigger gap.
when Within a day of reading it, verbatim, including the check order.
cost Suspect recall. Rebuild again in a week, or change the concept: rebuild the todo list with the same loop and see whether the stages transfer.
The implementation ladder
Concept, examples, pseudocode, code, tests, production — for the concept this lesson is about. Code is the fourth tab, not the first.
Shopping Cart = A temporary collection of products the user intends to purchase, held between browsing and checkout.
- Does a cart have identity? Yes, weakly. Two carts with the same items are still two carts, because each belongs to someone and will become a different order. It needs an id once it leaves memory; in memory the variable is the identity.
- Who owns it? A shopper — a logged-in user or an anonymous session. The owner is part of the state because "my cart" has to be findable again.
- How long does it exist? From the first add until checkout or abandonment. Whether it survives a reload, a closed browser or a login is not a property of the concept; it is a persistence decision made later, and each answer changes where the cart lives.
- Should it survive reload? Usually yes for a store, usually no for a demo. V1 in memory says no; V2 browser storage says yes on one device; V3 server storage says yes everywhere the user is logged in.
- Should it survive login? Only if an anonymous cart and a logged-in cart are merged — a rule that does not exist in V1 and appears as a modification later.
- itemscollection of CartItemkeepThe cart is its items; without them nothing else means anything.
- items[].productIdidkeepThe reference to what is being bought. The catalog owns the product; the cart only points at it.
- items[].quantityinteger > 0keepTwo laptops is one entry with quantity 2, not two entries — the rule "one entry per product" needs a quantity to hold.
- owneruser id or session iddependsSo the cart can be found again by the person it belongs to.
- items[].productNamestringderiveIt would be convenient to render the cart without a catalog lookup.
- items[].pricemoneydependsThe total needs a price per item.
- totalmoneydropEvery screen shows the total.
- currencycodedependsPrices need a currency to be added.
- createdAttimestampdropAbandoned carts might be expired or emailed about.
- update Add item — the updated cart
- delete Remove item — the updated cart
- update Change quantity — the updated cart
- read View items — the list of entries — product id and quantity — for rendering
- domain Calculate total — the sum of price × quantity over the entries
- delete Clear cart — the empty cart
- • Every quantity is greater than zero.
- • One logical entry per product.
- • The total is never negative.
- • An unknown product cannot be added.
- • Quantity cannot exceed available stock — if inventory is enforced here.
How to do it
Most important first.
- Do it a day later, not an hour later, and with the concept builder closed. The lab's Type-It-Yourself mode is the same exercise with the reference hidden until you ask.
- Write the meaning sentence first and the state second; if the state comes out with a stored total or a stored name, stop and ask what the field protects, before writing an operation (Challenging Unnecessary State).
- Write the six examples before any code. If you can write add-again — [ Laptop × 1 ] + add Laptop → [ Laptop × 2 ] — you have the rule, whether or not you can yet write the find.
- Implement one operation only, and its test, then stop and compare. The other four are the same primitives; the comparison on one is the information.
- Keep the stall list with the concept in your notes: "cart, rebuild 1: stalled at find; rebuild 2: stalled at the zero case". The list shrinking is the measurement (The Engineering Notebook).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Rebuild, day two. Meaning: written. State: items of { productId, quantity } — and a
totalfield, added by habit. Caught at the rules stage: "the total is computed", so the field goes; that stall is recorded as state. Operations: add, remove, change, view, total. Rules: positive quantity, one entry per product — the second only after writing the example add-again and seeing two Laptop rows. Examples: six, close to the concept's. - Pseudocode for addItem: the checks, then "find the entry" — and a stall. Not syntax: the question was whether to compare on productId or on the whole entry. Recorded as: rules (what identifies an entry). Resolved by the example: two entries with the same product id are the same entry; compare ids. Then the loop, then the branch, then the return. Code written with a for loop, not find; behaviour identical on all six examples.
- Compared to the reference afterwards: the reference validates the catalog before the quantity; the rebuild did the reverse. Both pass the examples; the order is a decision, and the flowchart lesson has the argument (Draw the Branches Before You Trust Them). The rebuild differs from the reference in two lines and in zero behaviours — which is the result the exercise wanted.
- Stall list: state (stored total), rules (what identifies an entry). Neither is syntax. Both are stages that had been read rather than derived, and both are one lesson each. The second rebuild, a week later, stalled on neither and on nothing new.
How you know it worked
What now exists that did not before, and what question you can now ask.
- The rebuild happened with nothing open, and it produced a cart that passes the concept's examples.
- The code differs from the reference in style and not in behaviour, and you can say which differences are which.
- The stall list has stage names on it, and each one points at a lesson rather than at "practice more".
- The second rebuild's list is shorter than the first's.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?With nothing open, can I write the meaning, the state and the six examples — and at which one do I stop?
- ?Is the stall syntax, or is it a stage — and which stage?
- ?Does my rebuild differ from the reference in behaviour, or only in lines?
- ?What is on the stall list, and is it shorter than last time?
What can go wrong
- Rebuilding immediately. An hour later the text is still in short-term memory and the rebuild is dictation; the stalls do not appear.
- Grading on the diff. A rebuilt addItem with a loop instead of find is not a defect; a rebuilt state with a stored name is. The diff shows the first loudly and the second quietly.
- Rebuilding all five operations. The stall appears in the first; four more are the same primitives and the same information, and the time is better spent on the stall.
- Skipping the meaning sentence and the state. Starting at "function addItem" is the reflex in a new costume; the point of the rebuild is to run the whole loop, and the stages before code are the ones most often received.
- Rebuilding costs a sitting and produces a cart you already had; the value is entirely in the stall list, which is a few lines.
- A rebuild that produces a different but correct design — a map cart — takes longer to compare and teaches more; a rebuild that matches the reference is quick to check and says less.
- Doing this for every concept is unsustainable; doing it for the first concept of each level — cart, then authentication, then job queue — is where the stalls change character.
- "If I can rebuild it, I have memorised it." A rebuild that goes through meaning, state, rules and examples is derivation; a rebuild that starts at the signature and reproduces lines is recall. The order you rebuilt in tells you which you did.
- "Getting stuck means I failed." Getting stuck at a named stage is the exercise producing its output. Not getting stuck and not being able to say why a line exists is the failure, and it is silent.
- "This is build-from-memory again." That lesson rebuilds a system design and compares the architecture; this one rebuilds one concept and compares behaviour example by example. The move is the same; the unit and the comparison are not.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALRebuilding from the meaning sentence with the reference hidden tests derivation for any concept in the catalog; the stages, and therefore the stall names, are the same for a cart and a rate limiter.
- STAGE-SPECIFICFor a learner, a day's gap and one operation; for an engineer checking their own understanding of an unfamiliar module, the same exercise on a whiteboard in a review, with the module closed. Under deadline it is skipped, and the stall shows up as a modification that took a day.
- ILLUSTRATIVEDay two, the week later and the two-line difference are invented to show the shape of the exercise; the examples and rules are the concept's own.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto's Build Without AI mode at /manifesto/without-ai is this exercise for a whole feature: the reference, the assistant and the tutorial closed, and the stall list as the output.