# BF-TC-004: overlap and back-to-back booking design prompt

**Status:** Learner-authored plan reviewed with corrected adjacency expectation and explicit existing-booking precondition. **Run:** BF-RUN-006. **Execution:** Pass. **Requirements:** BF-REQ-04; BF-REQ-06; BF-REQ-07. **Review/execution date:** 2026-10-15.

Supplied goal: compare a truly overlapping booking with a back-to-back booking. The original prompt suggested reset 1.0 with Sam's sample booking as the occupied interval. The learner instead selected **1.1** and proposed times around their current Test01 booking. That is a valid alternative fixture when its saved state is confirmed. This run does not cover 1.0 or its Sam-based fixture.

Known current fixture from completed BF-RUN-005: Alex's **Test01 / BF-003**, Confirmed, **Studio A, November 17, 2026, 12:00–13:00, 8 people**. Alex also has sample BF-002 in Studio B. Preserve these records; do not reset before this case. First verify BF-003's room/date/time/status in My bookings. If it is absent or different, the setup must be restored or the plan revised before drawing the proposed conclusions.

## Learner plan and review

The learner specified release 1.1 and Alex/customer; attempt test02 in Studio A on 2026-11-17 at 12:00 for 60 minutes with 5 people and screenshot; then test03 in the same room/date at 13:00 for 60 minutes with 5 people and screenshot. They expected both to be rejected, reasoning that neither overlap nor back-to-back bookings are permitted.

Review: the overlap rejection expectation matches the current fixture. The back-to-back rejection expectation contradicts BF-REQ-06. The end of Test01 at 13:00 and start of test03 at 13:00 share no occupied interval; test03 must be allowed. Five people is within Studio A's capacity. The coach added an explicit no-reset/fixture-verification precondition and corrected the second expectation; the learner supplied the account/build, titles, date/times/durations/party size, sequence, and screenshot steps.

## Reviewed steps and expected observations

1. Stay on **1.1**, signed in as **Alex Rivera / Customer**, using Practice123 if sign-in is needed. Do not reset.
2. Confirm **Test01 / BF-003** is Confirmed in Studio A on November 17, 12:00–13:00. Keep Show status All.
3. Fill **test02**, Studio A, **2026-11-17**, **12:00**, **60 minutes**, **5 people**. Select Create booking and screenshot feedback/list.
4. Expected: unavailable/overlap feedback; no test02 saved; existing BF-002/BF-003 unchanged and two own records remain.
5. Fill **test03**, Studio A, **2026-11-17**, **13:00**, **60 minutes**, **5 people**. Select Create booking and screenshot feedback/list.
6. Expected: successful new **BF-004**, Confirmed, 13:00–14:00, 5 people; three own saved bookings including unchanged BF-002 and BF-003. The rejected attempt must not consume a saved booking ID.

The screenshot evidence should show account/release, attempted inputs or saved details, and feedback. This case does not include refresh; persistence can be an explicitly added checkpoint later rather than assumed from prior checks. Overall Pass requires both overlap rejection and adjacency acceptance. A rejected second attempt would fail the adjacency checkpoint if the stated setup is verified.

## Observed result

The learner reports rejection of the overlapping Test02 and successful creation of Test03 in the next interval. Both screenshots confirm Alex Rivera / Customer / release 1.1.

- The first shows actual draft title **Test02**, Studio A, 2026-11-17, 12:00, 60 minutes, 5 people, with “That room is unavailable for these times. Choose another time or room.” The saved list still contains only BF-002 and BF-003; Test01 is confirmed at 12:00–13:00 with 8 people.
- The second shows actual title **Test03**, **BF-004**, Confirmed, Studio A, 2026-11-17, **13:00–14:00**, **5 people**, plus creation feedback and a count of 3 shown / 3 total. BF-002 and BF-003 retain their earlier details.

Overall verdict: **Pass** for overlap rejection and exact end-touch adjacency acceptance in this fixture. “Open time” here specifically begins at the existing booking's end, so the observation supports the adjacency boundary rather than merely a separated free slot. Actual title casing differs from the proposed lowercase spelling and does not change the rule tested.

Evidence:

- [Overlap rejected](../evidence/session-03/BF-RUN-006_v1.1_overlap-rejected.png).
- [Adjacent booking accepted](../evidence/session-03/BF-RUN-006_v1.1_adjacency-accepted.png).

This adds one completed run and the fourth executed reviewed learner-authored case. No defect is reported. Refresh was not part of this case and is not established by these images. No 1.0 behavior, partial overlaps, opposite adjacency boundary, other-room comparison, or full scheduling correctness is claimed. Windows desktop is known; browser/version for this specific run was not independently confirmed.