Free workshop — waitlist seat-offer handoff
Fixture: capacity 20; one seat per existing member identity. Event: 12 Oct 2026, 14:00 Asia/Seoul. Registration closes 11 Oct, 18:00 in that zone. Payment, groups, priority access and capacity reductions are out of scope.
Purpose: offer cancelled seats in accepted queue order and reconfirm attendance intent. Joining the queue, receiving an offer and confirmed attendance are different states. Do not promise a vacancy date or admission.
Order: server-accepted registration order; break equal timestamps by the server intake sequence. A member has only one active waiting, held or confirmed entry for this event. Do not expose other applicants.
Capacity: confirmed seats + valid holds must never exceed 20. Held seats are unavailable to general registration. While an active queue exists, newcomers join its tail. Re-evaluate changed conditions before assignment.
New offer: only with a free seat, an active waiter and at least 24 hours before registration closes. Atomically hold one seat for the queue head. Expiry is offer creation + 24 hours. Latest new offer here: 10 Oct, 18:00. After that, stop both new offers and general registration, even if a seat is free.
Accept: verify recipient, event, current offer and valid hold. The server time checked inside the atomic transition must be strictly before both offer expiry and registration close. Client click time is not authoritative. Convert one hold into one confirmed seat.
Duplicates: acceptance retried for that already-confirmed offer returns the existing confirmation. Never create a hold from an expired offer or redirect its action to another active entry.
End: decline, withdrawal and expiry end the specific entry/offer and release its associated hold once. A confirmed cancellation releases its confirmed seat once. Expiry processing and acceptance use the same atomic decision boundary.
Rejoin: never restore old priority automatically. A person may explicitly apply again during the new-offer window and joins the tail with a new intake order. Old links continue to show the old closed state.
Notification: persist the offer first, then send email tied to it. Send request, delivery failure, opening and acceptance are separate records. Flag failures or unknown outcomes for operations; resend only the same offer without another hold or an automatic extension. Never treat successful sending as acceptance; do not resend after expiry.
Screen: show event/date, full response deadline with zone, current state and allowed actions together. Active offer: Accept/Decline. Confirmed: View registration/Cancel. Closed: reason and rejoin availability. Unknown acceptance outcome: query current registration; do not claim confirmation.
Audit: connect intake order, offer creation/expiry/end reason, seat counts before/after, acceptance decision time, notification results and operator actions. Operators cannot bypass order, capacity or expiry. Policy changes require a separate decision and document update.
Handoff: planning owns ordering/boundaries; design owns messages/actions and accessible status feedback; engineering owns atomic seat/offer transitions and notification retries; QA records inputs/expected/observed results for 12 cases; operations records delivery failures and inconsistent capacity.
Release gate: block release for duplicate holds, over-capacity confirmation, expired acceptance or old links acting on a new entry. Retest the same sequence. This fictional design has not been integration-tested against a live event service.