Make departure reminders honest about permission and schedule changes
A rider enables a reminder after denying notifications, then assumes an alert will arrive. Rescheduled departures also leave the old reminder behind.
- Focused work estimate
- 2h 45m + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Permissions · Scheduling · State machines
Estimated field mix
- Mobile100%
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 Northline commuter app plans bus and rail trips from synthetic timetable and alert feeds. Riders save journeys and choose optional reminders. The scope excludes ticket purchases, safety guarantees, and continuous location collection.
Setup prerequisites
- Synthetic timetable with explicit time zones and service dates
- Departure, alert, and permission adapters with failure fixtures
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- Reminder state distinguishes requested, scheduled, denied, canceled, and expired.
- Changing the departure revision cancels the old schedule before confirming its replacement.
- The app offers an in-app alternative when device notification capability is unavailable.
Implementation constraints
- Request permission only after an explicit reminder action and disclose the limits of delivery timing.
Verification to include
- Allow notifications, schedule a reminder, then change departure time; one current schedule remains.
- Deny permission and cancel the trip during rescheduling; no successful reminder claim or orphan schedule remains.
Deliverables
- Reminder state coordinator and permission-change cases
Rollout and recovery
Pilot opt-in reminders on emulators and test devices; disable new scheduling if duplicate reminders are observed.
Value of the work
For the engineer: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design.
For the team: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data.
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.