Recover when another visitor takes the chosen slot
The last 10:30 appointment is taken while a visitor enters contact details. Submission reports Slot unavailable and resets the entire flow.
- Focused work estimate
- 2h 30m + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Concurrency UX · Accessibility · Recovery
Estimated field mix
- Accessibility50%
- Frontend30%
- API design20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
The fictional Riverside desk books appointments for permit paperwork and library assistance. Its browser flow was assembled from separate forms and dialogs. Work uses synthetic availability and booking adapters; actual appointments and personal records are excluded.
Setup prerequisites
- Synthetic services, slots, and booking API contract
- Keyboard and screen-reader access for a documented manual check
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- Conflict preserves contact values and service while clearing the unavailable slot.
- The conflict is announced once and focus moves to a useful recovery heading with alternatives.
- A replacement needs explicit confirmation and current availability revision data.
Implementation constraints
- Never automatically book a different time; availability remains server-authoritative.
Verification to include
- Conflict the slot, choose 11:00, and finish without re-entering contact details.
- Return no alternatives and fail refresh; explain the state without trapping focus or inventing availability.
Deliverables
- Slot-conflict recovery and accessible failure scenario
Rollout and recovery
Exercise synthetic capacity conflicts before pilot; pause booking if contact recovery or slot identity is unreliable.
Value of the work
For the engineer: Practice accessibility as complete interaction behavior, including recovery and asynchronous updates.
For the team: Inspect whether an engineer removes concrete barriers while preserving appointment integrity and supportability.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.