You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- iOS with an **iOS AlarmKit Alarm** should show **Alarm Status**.
210
218
- iOS without an available **iOS AlarmKit Alarm** but with notification permission should show **Notification Status**.
211
219
-**No Scheduled Notification** should be the user-facing empty state across platforms, even when future delivery may use an **Alarm**.
220
+
- A **Preparation Run** records **Preparation Action Events**, not timer ticks or automatic step transitions.
221
+
- A **Preparation Action Event** may represent starting preparation, skipping a preparation step, or finishing preparation.
222
+
- A **Preparation Run** begins when the user performs the starting **Preparation Action Event**.
223
+
- A skipped preparation step ends at the skip **Preparation Action Event** time; its unused planned duration is not treated as elapsed preparation time.
224
+
- The current step and completion state of a **Preparation Run** are derived from its starting action, user-performed **Preparation Action Events**, and the current time.
225
+
- Automatic step transitions are derived states, not **Preparation Action Events**.
226
+
- A **Preparation Run** must not outlive the scheduled commitment it belongs to.
212
227
- Active first-release **Analytics Purposes** are product improvement, debugging and operations, and experimentation.
213
228
- A first-release **Experiment** must not be used for marketing targeting, sensitive segmentation, or personalized treatment.
214
229
- Marketing and personalization are **Deferred Analytics Purposes**.
- "Time Sensitive" was too platform-specific for default user-facing status; resolved: fallback iOS delivery should be called notification.
261
276
- "Status label" was ambiguous across platforms; resolved: Android uses precise notification or notification status, while iOS uses alarm status only for **iOS AlarmKit Alarm**.
262
277
- "No scheduled alarm" was too capability-specific for an empty state; resolved: use **No Scheduled Notification** across platforms.
278
+
- "Step action events" was ambiguous as either user actions or automatic timer movement; resolved: the canonical term is **Preparation Action Event**, and automatic step transitions are derived rather than recorded as events.
263
279
- "Preparation chain" describes storage reconstruction, not product language; resolved: the domain concept is an ordered **Preparation** made of **Preparation Steps**.
264
280
- "Total duration" was ambiguous between **Preparation Duration** and the broader preparation-start timing calculation; resolved: **Preparation Duration** is steps only, while move time and **Schedule Spare Time** are separate inputs.
OnTime will model local preparation progress as a Preparation Run that starts at the user's start action and is adjusted by user-performed Preparation Action Events such as skipping a step or finishing preparation. The app will derive the current step, elapsed time, and completion state from the run start time, action events, current time, and the current schedule fingerprint instead of treating timer ticks or elapsed-time snapshots as the source of truth. This prevents sleep, background suspension, and delayed timers from making preparation progress drift while keeping the first implementation local to the app rather than expanding the backend API.
4
+
5
+
## Consequences
6
+
7
+
- Timer ticks may refresh UI state, but they must not be persisted as preparation history.
8
+
- Automatic step transitions are derived during restore, resume, and tick refresh; they are not stored as events.
9
+
- Stored Preparation Runs are valid only while the schedule fingerprint still matches and must be cleared when the schedule is finished or deleted.
0 commit comments