intermediateInvariants

Checkout Invariants Under a Deadline

Work from the brief alone. Write what you would produce — actors, requirements, data, a first slice, your unknowns — before opening anything below it; the exercise stops working if you read the reality first.

The brief you were given

You inherit the store's untested checkout a week before a campaign that will double traffic (illustrative). Produce the list of invariants, a test for each that passes or fails today, and the order you would fix failures in. You may not rewrite checkout.

Your attempt

Nothing here is checked. It exists so that the reveal below is a comparison rather than a reading.

The trap — the move that looks like progress and is not

Reading the whole checkout module to understand it before writing a test. It feels like diligence and consumes the week; at the end the engineer understands the code and has checked no invariant, and the campaign runs against a checkout that is exactly as untested as it was — but now with a confident owner.

Read this even if you are confident. It is here rather than behind a button because it is the move most people actually make, it produces things that look like a project, and its cost arrives when the first hard requirement has nowhere to go.