Step 1 of 6
Define the booking model
Slots, durations, and conflict rules must be explicit before building UI.
Define the booking spec. Specify: what is being booked (service/resource) and its schedulable hours; slot duration and how slots are computed for a given date; the booking record (user, resource, start/end datetime, status); the conflict rule (a slot with an active booking is unavailable); and cancellation policy (cancel frees the slot). State that conflicts are enforced at the database/backend level.
Expected after this step
A concrete slot and conflict model ready to implement.
Should not happen
- ✕A calendar UI where every slot always shows available
- ✕Bookings stored in local state only
- ✕Two users able to book the same slot
- ✕Cancel that does not free the slot
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !A calendar UI where every slot always shows available
- !Bookings stored in local state only
- !Two users able to book the same slot
- !Cancel that does not free the slot
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
The spec has no conflict rule. Add the exact rule for when a slot is unavailable and where it is enforced (backend query/constraint, not the UI).