Support calendar navigation across removed and disabled shifts
Roving focus points at a disabled shift after refresh. Define deterministic navigation across changing eligible targets.
- Focused work estimate
- 4h + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Keyboard · State machines
Estimated field mix
- Accessibility70%
- Frontend30%
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
Fictional studio Loom assigns editorial shifts. Build synthetic shifts and a local scheduling adapter; no real staff records are used.
Setup prerequisites
- Create synthetic shifts including overlaps and daylight-saving boundaries.
- Implement a local schedule revision adapter.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- CCAL-101 · Name staffing shifts independently of calendar color
- CCAL-102 · Provide a chronological agenda beside the staffing grid
- CCAL-103 · Describe staffing time-zone changes explicitly
- CCAL-104 · Move staffing shifts through a keyboard form
- CCAL-105 · Restore staffing focus after a shift is deleted
- CCAL-106 · Announce staffing conflicts without repeating the entire calendar
Acceptance criteria
- Only one navigation tab stop exists
- Disabled targets are skipped
- Removed focus resolves predictably
Implementation constraints
- Document arrow-key behavior without overriding text inputs.
Verification to include
- Navigate mixed availability
- Remove current target during refresh
Deliverables
- Navigation model and transition cases
Rollout and recovery
Switch to ordinary tab stops while repairing the model.
Value of the work
For the engineer: Practice focus models and accessible alternatives for spatial interfaces.
For the team: Inspect whether scheduling remains usable across input methods and failure states.
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.