Reasoning Checkpoint
A design challenge, worked through in writing — no auto-grading, just a real attempt.
The Challenge
Samantha has a new rule for the City Music Festival: each fan can hold at most 4 seats at a time, and the seats in one order must be held and paid together — all or nothing.
John asks Anna to design it the way this Act taught: no code at all. Use the five steps — understand, examples, steps, dry run — and hand in your plan on paper.
What Your Plan Needs
- Understand: write the input and output of "hold these seats for this fan" in one or two sentences each.
- Examples: list at least five test examples, including at least three edge cases (think: exactly 4 seats, 5 seats, one of the seats already taken, an empty selection, holding again after 10 minutes).
- Steps: write the algorithm in pseudocode, including validation (the bouncer) and the seat states FREE / HELD / SOLD.
- All or nothing: explain what happens if 3 of the 4 chosen seats are free but 1 is taken.
- Dry run: trace one example in a small trace table (step, what happens, seats' states).
- Name one risk you can't fully solve on paper, and say which later Act will help.
Stuck? A Few Hints
- "All or nothing" means: check every seat first, and only hold them if all of them pass.
- Count the seats this fan already holds before adding new ones.
- Reuse the state rules from the third chapter: only FREE → HELD is allowed when picking.
Before You Move On
Notice that the most important line in the plan is "check all first, change nothing until every check passes." That one idea — validate everything, then act — prevents a whole class of half-finished, inconsistent results. You'll see it again in databases (Act 13) and payments (Act 23).