Private checkpoint and meaningful alerts

Use the host's supported private persistent storage or automation history. Keep only what is needed:

• Local travel date, route and configuration revision.
• Calendar gate result (office, home/leave, ambiguous, unavailable), evidence reference and checked time, without copying full events.
• Usual service identity and normalized facts, nearby practical alternatives, source links, source update times and observation times.
• Journey stage: planned, user-confirmed aboard, tracked-service arrived, user-confirmed arrival, cancelled or unresolved. Preserve explicit service changes and arrival confirmation; never infer boarding from the clock alone.
• Last user-visible alert's facts, recommendation, timestamp and send status.
• Unresolved calendar or live-source coverage failures and whether a warning was already sent.

Reset day-specific service facts at the local date boundary. Retain the last alert and unresolved failures long enough to deduplicate and report recovery. Do not put this data in Tessl or another public package.

Compare against the last observation to notice changes, and against the last alert to decide whether another message is useful. Notify for:

• Explicit cancellation or partial cancellation affecting the journey, a skipped destination or material timetable change.
• Expected departure or arrival delay reaching the configured threshold, or a further material deterioration since the last alert. Suggested default: 5 minutes; skip marginal fluctuations that do not change a decision.
• A verified incident that threatens this route and requires a practical choice, even before an individual prediction appears. State uncertainty.
• A better still-reachable alternative or a change that affects when the traveler must leave.
• Loss of an alternative previously recommended, or a genuine recovery that materially changes a previous warning.
• Missing calendar or live-data coverage that could otherwise leave the traveler relying on an unverified watch.

Do not notify for ordinary on-time status, every platform assignment, tiny estimate changes, stale incidents, unchanged warnings or non-office days without an explicitly confirmed active journey. A user's active-journey confirmation takes precedence over a conflicting calendar location until arrival or the configured cutoff. If persistence fails, use recent authorized alert history when available. If both are unavailable, flag the deduplication limit internally and avoid repeated nonurgent messages; still surface a new urgent cancellation or decision with current evidence. Never retry a send with uncertain delivery without checking its outcome.

Acceptance scenarios

Check these before claiming the watch is ready:

1. A weekday is Home and no active journey is confirmed: stop before rail queries and send nothing.
2. Office plus a morning outOfOffice event titled Commute: continue; do not mistake the travel block for leave.
3. Calendar fails: do not infer Office from the usual weekday. Give at most one material coverage warning.
4. The target is missing from a filtered board: inspect unfiltered data; do not announce cancellation without evidence.
5. Departure is 10 minutes late but arrival prediction is absent: do not invent the arrival. Label it unknown.
6. An earlier train is available but station access time is unknown: make the catchability condition explicit.
7. The same 10-minute delay appears on consecutive runs: one alert, not one per run. A further delay or lost alternative can warrant another.
8. Only cached snippets or a form are readable: status unavailable, never on time.
9. A current cancellation appears on the first eligible check: alert immediately; lack of an earlier baseline is no reason to wait.
10. A service is restored after an alert: notify only if the verified recovery changes the useful recommendation.
11. The scheduler rejects the cadence: report its supported limit; do not multiply tasks or polling loops.
12. A colleague installs the public skill: request their private settings; do not use another traveler's calendar or alert history.
13. At the normal arrival time, the tracked train's expected arrival slips by 20 minutes: continue within the configured late-arrival window and report the material change. Do not mark complete at the timetable arrival.
14. The traveler confirms being on a different service: verify and follow that service. A previous recommendation alone does not establish they took it.
15. An intermediate passing-point delay is observed but the destination forecast is absent: report only what is known, without treating that delay as a destination prediction.
16. Fresh data confirms destination arrival or the user says they arrived: end the day's journey alerts silently.