Review the result, then change the conditions
A completed screen is not the final evidence. Explain how it behaves when the assumptions change. Ask a peer to run the project from the README, or use a clean working copy and follow only those instructions yourself.
Start with the published baseline. Verify the reference totals, reload, a failed catalogue request, an out-of-order response and a repeated confirmation. Inspect the Network panel to confirm the route and payload match the described contract.
A new business request
"Premium customers should receive the discount from exactly 100.00, not only above it. Existing confirmed orders must keep their accepted amounts."
Before editing, separate two decisions: new quote eligibility and historical accepted values. Changing > to >= updates new calculations, but recalculating an accepted order under the new policy can rewrite history.
For this review exercise, work on a branch or copy. Update the new-quote threshold and its tests: a premium 10000-cent subtotal now yields 1000 discount, 1800 tax and 10800 total. Standard remains 12000. Keep the main course baseline unchanged outside this exercise so the earlier acceptance examples stay meaningful.
Extend the server fixture to capture an accepted quote snapshot and policy version when confirming. Return that snapshot on same-key replay. Do not recalculate it when reading an already confirmed order. Explain what durable storage would be required beyond this in-memory demonstration.
A usability request
"When the catalogue refresh fails, keep the previous products visible."
This changes the earlier clear-on-load policy. Define a stale state and label it visibly. Decide whether stale products can be selected; for this exercise, allow inspection but require a successful refresh before selecting a new product for a remote quote. The server still reprices every request.
Update the controller tests and rendering checks. A failure must no longer be visually indistinguishable from current successful data. Old requests must still be unable to replace newer state.
Assessment rubric
| Area | Evidence of understanding |
|---|---|
| Business decisions | Written rules, boundary examples, changed expectations |
| State and time | Invalid, pending, stale, conflicting and unknown states are distinct |
| Authority | Server-owned values are rebuilt and validated |
| Usability | Keyboard completion and actionable errors |
| Verification | Tests fail for plausible wrong implementations |
| Maintainability | Changes stay within explained boundaries |
| Honesty | Local, simulated and durable guarantees are distinguished |
Use "demonstrated", "partly demonstrated" or "not yet demonstrated" for each area, with a concrete observation. Do not average away a broken authority boundary because the layout looks good.
Final explanation
In five minutes, walk through one user intention from form input to state, domain decision, adapter, response and rendering. Name the source of truth at each step and the evidence for one failure case. If you can do that and implement the change requests without scattering rules across handlers, you are ready to evaluate what a framework would actually help you manage.